This weeks work has been focussed on completing the factoring out of my first reward (debugprint.) This work took significantly longer than initially expected, but I believe that I have learnt a lot from the experience and am confident that the process of factoring out the remaining rewards will be trivial.
I am now putting together a test program that makes use of all rewards, so that I can test the new implementation of each. This program will later serve as the basis of the quest tutorial. From my work with the system I believe there is a firm need for a singular collated example of all rewards and triggers to increase the community's usage of this feature and look forward to providing this.
Finally, I will be posting shortly after this post a formalised list of deliverables. My current progress is behind the initial deadlines set out in my project proposal. At the time I underestimated that time I needed to become familiar with the CS/CEL architecture. However, I believe that I have also overestimated the time needed to implement a behaviour tree. Therefore, I am still confident that all of the promised deliverables will be accomplished in the timeframe of the GSoC program. In addition, a number of other requests have been made for modifications to quest that I hope to cover once the promised refactor and BT implementation is completed. My intention for this post is to update it periodically to show my progress.
That is all for this week, as always please feel free to contact me if you have any suggestions, queries or complaints.
Kind Regards, Sam
My minor projects late last week and this weekend have come to an end succesfully. I now feel comfortable working with the SCF, Quests and smart pointers. Thank you to everyone on the mailing lists and irc channel that have helped me overcome this initial hurdle.
I have now begun coding the deliverables promised and have made a start on factoring the reward debug message out of quests. My cel workspace now contains a new project plgrewards that compiles a dll containing plugins for each of the rewards and I intend to create something similar for the triggers shortly. I have a busy weekend ahead of me but believe that significant progress will be made on the refactor over the next week / week and a half.
I also intend to publish a formalised list of deliverables with estimated deadlines. I believe there is some way to publish to the blog so that this list will remain as the top post, if so I will periodically update that post to announce deliverables submitted and to show my progress.
As always please feel free to question, poke or criticise me either openly here, in irc, the mailing list or privately by email. I appreciate any and all input on this project.
Kind Regards, Sam
We are underway and I am long overdue in posting an entry here so there is much to discuss.
What have I been doing:
Planning! I have been getting very familiar with lighter2 and determining where change would be most appreciated. This has been a slow task as much of lighter2 is un-commented (or at least, the comments are not very detailed). Also, I have had to learn much about the CS app framework, the instance tracking classes used in CS and the i* classes used throughout lighter2. Conceptually, I reached a good place to actually propose some changes to Scott my mentor last week and we met to discuss just that.
What is the current status:
At present, we have identified the following concerns or features that need attention in lighter2 and would pertain to my proposal and my areas of expertise -
Conceptually, any light-mapping application can be thought of as a bootstrap. The rendering system will use the light maps to render the world but the light-mapping application needs a rendering system (or at least part of one) to construct the light maps. Therefore, lighter2 naturally depends on some components of the CS library (mostly viewing and projection calculations and geometry loading components).
Some of the conceptual components of lighter2 (like the 'scene' and 'segment' classes) should be part of the CS library. I have not examined the library itself too deeply to see if it provides these components but Scott suggested that they are in fact copies of classes from the library. This is conceptually undesirable but there may be reasons for it. More discussion of this is in order.
What conclusions can be drawn:
From all of this I've identified some requirements for this project -
So what are the plans:
I'm going to start moving forward with changes now. Here's the initial proposal of work in the order it will be undertaken (this may change in a typical design-build fasion) -
At this point we will reevaluate and decide what is to be done next. Additional project tasks may include:
What's described here will constitute the bulk of this project and work will begin immediately. I intend to reevaluate progress as I go and learn more about CS and lighter2. All comments are welcome and encouraged as there are a plethora of assumptions underlying these ideas and any number of them could prove to be wrong. The collective knowledge of the CS community can do far better to identify these problems than I can digging through the mountains of code and documentation. My time is better served now making changes rather than fact-checking!
Thanks to all for reading this! I will post more as I go.
So my exams finished on Friday past and I am now fully committed to the project. My work since then has focussed on reading, I have consumed everything I can find relevant to my project in the hope of solidifying my understanding of CS and CEL before I begin coding.
For anyone following my progress that is concerned about the issues I was having with merging with trunk and the black screen on walktut. These difficulties have been overcome. The merging problem was solved by using svnmerge.py instead of the windows executable provided by the same group. The black screen problems were then solved, with a correct merge to trunk, a fresh checkout of CrystalSpace and the latest (14.02) precompiled version of cswin32libs.
My intention over the next couple of days is to code a few minor self projects, to ensure I fully understand the SCF and current implementation of Quests.
Finally, as some of you will have noticed I have started to lurk on the irc channel whilst working. So if anyone has any questions or suggestions, please feel free to harass me on there. I am still fairly new to irc and not generally used to having message clients running, so I apologise if I am slow to reply but will be very grateful for your input.
Until Next Week, Sam
Hello CrystalSpace Community,
As many of you will know the GSoC 2009 coding period has officially begun and whilst, due to my final exam commitments, I am unable to start full time just yet I have begun some preliminary work on formalising the deliverables for the Quest refactor and setting up my working environment from the CrystalSpace SVN trunk and my assigned CEL branch.
It is my intention to make this blog a weekly update, starting today and continuing every Wednesday throughout the development period to keep the community up to date with the work I am doing.
For now, if anyone has any comments on the existing Quest implementation be they positive or negative please contribute to the CEL mailing list conversation [Cel-main] Quest Refactor . The biggest current issue is to wether we should factor out sequences and instead implement them with a standardised start-finish protocol. Any opinions or comments on this suggestion are greatly appreciated.
I look forward to debating these issues further.
|<< <||Current||> >>|
This is the long description for the blog named 'Blog All'.
This blog (blog #1) is actually a very special blog! It automatically aggregates all posts from all other blogs. This allows you to easily track everything that is posted on this system. You can hide this blog from the public by unchecking 'Include in public blog list' in the blogs admin.