Bah, today is one of these days where you spend more time debugging some stupid problem then doing useful coding. In this case the bug is probably not even caused by me. The problem is that on destruction of a mesh wrapper there is a 'pure virtual method' called. Debugging this is hard since the program doesn't crash so you can't get a decent stack backtrace easily.
If all debugging fails I might have to do a 'binary CVS search'. That's the technique of going back in time with CVS trying to find the exact moment at which the bug occurs.
Wish me luck!
Update! The problem is solved now! Time to move on :-)
The new map is progressing nicely. Please don't expect too much of it. I'm not an artist. It is just going to be slightly more interesting then the current celtest map (partsys). It will contain a landscape and a few more areas to visit. Soon I'll start adding the game logic to it. That will require a bit of coding though. More in particular I need to:
So I have my work :-)
The celtest application and map are getting a bit old and primitive. I'm working on a replacement which will be a little bit more interesting. It will be more like a game with puzzle elements to better demonstrate the things you can do in CEL (like quests and so on). I'm making the map in blender using blend2cs.
It is always satisfying when things work as you intended. In this case I'm talking about the sequence stuff in the quest manager. Today I managed to get a first working sequence in the test quest for celtest. It doesn't do much. Just print out a bunch of numbers during one second. But it proves that the system works. Additionally even persistence works. I can save the state of the entire quest including the running sequences and then later load it again. The quest and sequences just resume where they left off. Pretty nice.
The work will now be in adding more sequence operations to the quest manager so that this actually becomes useful. Also it will be great to have a quest trigger that fires when a sequence finishes. That way you can delay switching of the 'dooropen' state in a quest until the door is actually fully open.
We got a nice offer from Pace University to donate the full Macintosh computer to Eric. If that deal goes through then we need to find a new purpose for the money that has been donated so far (around $1000 USD). One idea is to replace my linux computer which is slowly starting to have problems (bad HD and overheating problems). Also it is underpowered with respect to 3D hardware which means we can't easily test the more advanced renderer features on linux (most of the other CS team members are using Windows these days). And of course I wouldn't mind a new computer :-) But of course that means we need even more money then $1000.
I'm thinking about adding a nice new quest to celtest. Basically I would add a door entity to the world which is initially closed. If you approach the door you would get a message saying something along the lines of 'You need to find a key to open this door'. Then you have to go to another room, pick up a key and with that key you can open the door. I still have to do a bit of work before I can make such a quest but I'm not that far from this goal now. Basically the sequence stuff needs to work and I also have to work on a trigger for the inventory system.
Some time ago I came to an important realization. The persistence system in CEL is *almost* general enough so that you can do the following:
Not much is needed before this can work. It requires that game A and game B are pure CEL games. This means that they should have a behaviour layer that is a plugin (for example, the python behaviour layer or a custom one that is build as a plugin) and it requires that I add a little extension to the persistence system so that the SCF ID of the behaviour layer is saved too. That would allow us to dynamically load the behaviour layer plugin when the savefile is loaded.
Once this is done you would basically be able to run (for example) the CEL boulderdash game and then load a save file from Crystal Core in that. This is fun stuff :-)
I'm working fully on CEL now. The idea there is to create a full fledged quest manager which will be used for defining the story elements in Crystal Core. Basically the entire game logic and game structure will be defined with the quest manager in XML. The quest manager basically works but right now I'm working on adding sequences to it. I would have liked to use the existing engine sequence manager in CS but unfortunatelly the design of that doesn't make it easy for me to use that in CEL except for small and easy cases (like a fan that rotates or a light that goes on/off on proximity). But in all other cases (like doors that open and close in response to some quest element) we need to be able to save state and resume sequences in the middle later. This is not possible with the CS engine sequence manager. The new CEL sequence manager is part of the quest manager as it is closely tied to that and it will also reuse the triggers of that.
After this I hope I can incorporate some real working quests in Crystal Core. Hopefully Xotic will soon have some new levels so we can start to work on the first tech demo then.
I'll keep you posted.
This post has one purpose and one purpose only! That is to waste the time of everyone who reads it! If you read this then you fell in this trap!!!
Perhaps I should do more useful posts in the future...
|<< <||> >>|