Bugs bugs bugs..

I caught some sickness, hence the late blog. I'm back on track now. This doesn't mean that nothing has been done though.

While trying to fix the trigger problem mentioned in the previous blog enty (causing the server to crash because it would reference actors removed from the system), I identified several other issues. Most of them were easily fixed, but one in particular was especially hard to get nailed. It had to do with the way that boost::python converts shard_ptr from python to c++. This is done (when passing by copy or const reference) by creating a new shared_ptr that points to the same pointer but has a custom deleter. This deleter keeps a reference to the python object in order for python to find the python object when passing the shared pointer back to python. The deleter will not delete the pointer itself, but just deref the shared_ptr kept in python. This means that we could not compare shared pointers that we got from python to c++ calls, because they were entirely new ones for each call! This took me quite a while to figure out.

I've also managed to get consistent naming for the scripting and c++ calls, and documented the global functions for scripts.

Projections on the floor works now, but unfortunately they drift a little. Need to figure that out.

Yesterday I drew a very simple animated man in blender. He has the animations: run, stand, beginrun. Now you can control him instead of the tank as requested by Simon. I still need some tweaking before it looks okey though, but it is a step in the right direction.

Simon has been working on creating a set of states for the finite state machine. Especially for the tortoise model. This means that it will patrol a little and attack any players within a given radius. Pretty nice I think. We've discussed how to make it easier to model the behaviour without scripting a lot of states. For now the way to go is to add paramters to the actors that the state can query. From these parameters the state machine can figure out how to behave e.g. aggression = 200 -> go attack.

Debugging, debugging, debugging..

Simon has begun implementing a simple test level. This also means that he finds a lot of bugs and missing "must have" features in order to get his job done. I created a scale associated to an actor on order to make it scaled on the client side. This is very useful for rendering trigger areas. I enabled correct loading of config files, because when i tried to connect to a server Simon created I discovered that it didn't read the config file but just fell back to localhost. Now you can override the material used on the client from server side. You can enable rendering of triggers. Currently only as a semi-transparent sphere or cube, but soon as a projection on the "floor". Also made a bunch of other fixes. Unfortunatly Simon identified a problem with the way triggers behave when listening actors are deleted. This can make the server crash and has to be resolved. I haven't figured out the best solution yet though. The script api docs generator is done now and most of the script api has been documented. Still missing the global functions though. But things are slowly forming.

Small feature update

Implemented some of the missing features as described in the previous blog. Now you can right click on an actor and get the world position of the click point. Furthermore I implemented a debug section in the scene file where you can globally override selected attributes on other elements of the scene file, such as 'showAABB', showName' etc. I've also begun the rendering of triggers, but they are not quite done yet. Finally, I've made some documention strings for the script bindings, but this is a very cumbersome job and will be made in stages. But we severely need some API docs, so it will have to be done soon.

Saturday meetup

This saturday me and Simon met in order to do some syncronuous hacking on SteamWinter. Actually, we didn't hack much but found a much better way to define levels using the .scene files. More specific the triggering markup was way too complicated to understand and needed a brush over. Further more, we identified some other features/bugs that need fixing before we can actually make the simple level required as a part of a flight2 release. I've already done some of the stuff:

• Make areatrigger into sphere and boxtrigger
• Make 'system' a valid target for a trigger. Used when it is not an actor that is interested in a trigger event
• Revised .scene format
• Show names properly and not a generated name as previously
• Print version number to console upon start (only linux for now)

The are no missing part before we can actually make a simple level, but these are the things that should get implemented as soon as possible to easy the level editing:

• Visualization of trigger areas
• A debug mode flag indicating that all names and triggers should be rendered
• Document the script bindings!
• Build time printed to console on windows
• Click to get world position
• Tutorial of creating a simple scene

After that I'll release flight2.... probably with some flight3 features as well.

Flight3 status..

Even though flight2 hasn't really been released yet, I've begun to implement flight3 features. The only missing flight2 part is the "create small test level" part. This part is mostly handled by Simon. Since I don't wanna get bored I've just started the flight3 stuff :)

Flight3 is all about editor. Currently I've corrected the way the move tool works - Made a meshviewer - and more importantly added support for remote properties in addition to the already existing remote method calls (on the transparant proxy objects). This really paves the way for a nice editor, since properties are easy to make dropdowns etc. for.

Next steps is to create more tools, and the ability to write results to a .scene file. I believe the latter part will be the hardest one to implement.

AI is coming..

Finally I got some AI running. For this initial AI I settled for an event driven hierarchical finite state machine since it provides at lot of possibilities to the AI script writer. You can create your own states in script or in c++. I've also spend some time to get it to run on windows and I think I'm nearly there.

I've verified that the windows package now installs with all the correct dlls.. pwfeeww. One of my friends, Simon, has begun to create a simple level just to explore the fleksibility of the framework. He has already found quite a few things that need to be improved, but that is just great. Also, one of my other friends, Bue, has made a patch to the server console to make it autoscroll. This is really great, since scrolling each time a log line is output becomes very annoying and impossible if many lines are written out.

When I've got the state machine to run nicely on windows, I'll get to the editor part of the framework. This is very exciting, because that'll speed up level creation and hopefully motivate other people to make some simple levels. But is also quite a large task.

Status update

I've been on vacation the last week, so haven't had much time to hack. Anyway, I used some of my relaxing time to think about the design of the new AI framework.

I have several things that should be possible: Easy extensible through scripting, possible to define AI through XML scene files, possible to handle AI in c++. I thought a lot about it and think I've finally found the correct design. So now it is time to hack, yay.

I've also used some time to get steamwinter running on a clean windows install. It seems that every person that have tried it so far have had VC2005 installed + some other tools. These come with a bunch of DLLs that tanxoid need. The package I had created did not distrubute these DLLs. To make things worse Microsoft decided to create something called Side by Side DLLs (SxS) that should make the DLL hell disappear. Well, the solution they came up with it not exactly elegant, and I've been fiddling around with DLL manifests and the like a lot to get things to work. I still haven't verified that it works yet, since I need a clean Windows install, but a friend has a clean install and I'll get him to test it as soon as possible.

I just cannot understand why people are so excited about VC2005... I really think it sucks donkey balls big time.