C++ skills & bored? Help us. (junior job :-))

[Tobi]

If anyone with some C++ skills is bored: I could use some help in making all simulation related spring classes registered in creg (Class Registration System). This needs to be done to make easy Serialization of the gamestate and hence resync and savegames possible.

Basically what needs to be done is that for every class the proper creg macros have to be added.

For an example, take a look at Loshandler.h and LosHandler.cpp before putting it in creg, and Loshandler.h and LosHandler.cpp after registering it in creg (look for CR_* macros).

As in this example, often a custom creg_Serialize function has to be written to write out C style heap-allocated arrays (e.g. unsigned short* array), or arrays of creg-registered structures.

Take a look at creg.h and ISerializer.h for creg documentation (and availble macros) and serializer interface.

I myself started on the classes in rts/Sim/Misc, so if you want to help feel free to take another directory . And post here so others dont accidentally fix up the same class.

I'd prefer any results as patches, tho for memberlists/serializer function I dont mind if you just copy paste it into this thread.

[jcnossen]

in resync branch?

[AF]

Would it be a good diea todo this with the AI stuff so that we can then add a save and load mechanism? That way the very last obstacle to a very basic save+load system is voercome, and us AI devs can start saving and loading our AIs

[Tobi]

in resync branch?

Yes.

In general if you have commit access, just put it in resync branch.

[Tobi]

Would it be a good diea todo this with the AI stuff so that we can then add a save and load mechanism? That way the very last obstacle to a very basic save+load system is voercome, and us AI devs can start saving and loading our AIs

The Spring creg stuff isn't exported and because of the complexity I doubt that's a good idea (then classes have to be insterted/removed on DLL load/unload, not sure how well that works). However, nothing stops you from using creg in your AI yourself and submitting a patch adding a Save() and Load() function (or one Serialize function) to the appropriate interface...

These functions could then be called from a custom serializer function of one of the Spring AI classes. Maybe I'll look at it myself once I arrived at the ExternalAI directory.

[AF]

I'd have done that a long time ago but I have no idea how it all works and get distracted by adding new info callbacks like slopemaps etc....

[Dragon45]

Heh, junior job is aka gruntwork

[malric]

Done some of the work for Rts/Sim/Weapons (sent patch as PM).

CR_BIND_DERIVED didn't seem to work for classes that don't have a void constructor, so I modified the macro and made it variadic macro. I have just linux so I wasn't able to test with Visual Studio, but I read it works with VS 2005.

@Dragon45 - if while doing gruntwork you learn some nice strange syntaxes for C, see the structure of the project and contribute to your favourite oss project - then it can be really pleasent. .

@Tobi - is there a way to test this ? I tried to compile and run, but I have a feeling it is not enough :D

[Tobi]

Done some of the work for Rts/Sim/Weapons (sent patch as PM).

Thanks!

CR_BIND_DERIVED didn't seem to work for classes that don't have a void constructor, so I modified the macro and made it variadic macro. I have just linux so I wasn't able to test with Visual Studio, but I read it works with VS 2005.

Since creg doesn't know what to pass as arguments to this constructor anyway, the classes have to be refactored a bit so they have a void constructor after which they can be serialized without crash (ie. this void ctor must allocate any memory if necessary, set pointers to NULL [for safety] etc.). The old ctor can be left for compatibility with other code.

@Tobi - is there a way to test this ? I tried to compile and run, but I have a feeling it is not enough :D

If it compiles it is enough for now, there isn't really an easy way to test it any more atm (I'll try to hack up a system to Serialize classes to logOutput or something soonish).

[malric]

Since creg doesn't know what to pass as arguments to this constructor anyway, the classes have to be refactored a bit so they have a void constructor after which they can be serialized without crash (ie. this void ctor must allocate any memory if necessary, set pointers to NULL [for safety] etc.). The old ctor can be left for compatibility with other code.

I assumed that creg will save/restore all the necessary fields (if registered as metadata). As the constructor I have seen did just simple assignement, I thought it was easier just to call them with NULL (or 0 depending on the case).

So this way the class stays the same, and in CR_BIND there will be some arguments that will be passed to satisfy the constructor.

The main problem I see in adding void constructor would be that people will not realize that they should be called with certain initialization (yes, maybe I'm paranoid, but...). Not to speak it will take longer for the grunts to modify the code (maybe we should say it's pewee work instead of grunt work )

[Tobi]

True, good point. Not sure MSVC supports this kind of variadic macros tho.
Guess I better take a proper look at it when I'm at home...

[jcnossen]

If it compiles it is enough for now, there isn't really an easy way to test it any more atm (I'll try to hack up a system to Serialize classes to logOutput or something soonish).

Ideally, you test it by replacing the save load system...
Unfortunately i dont have time, I really have to spend the coming 2 days on learning exams.

[Tobi]

Yeah that would be second step. (or more like Serialize to logOutput for debugging save load if it doesn't work)

[Tobi]

I'll continue on rts/Sim/MoveTypes, rts/Sim/Misc is basically finished here on my usb stick.

[malric]

True, good point. Not sure MSVC supports this kind of variadic macros tho.
Guess I better take a proper look at it when I'm at home...

I read on msdn that VS2005 supports them, so I'am optimistic.

And about testing, I also do not have that much time, so I prefer to help with smaller issues... (so I will let you make load/save ).

[Tobi]

These are finished:
rts/Sim/Misc
rts/Sim/MoveTypes
rts/Sim/Objects


I'll continue on rts/Sim/Path.

[malric]

rts/Sim/Weapons finished (with 1 problem).

Questions:

1. From creg.h:

Code: Select all

/** @def CR_DECLARE_SUB
 *  @author Tobi Vollebregt
 * Use this to declare a sub class. This should be put in the class definition
 * of the superclass, alongside CR_DECLARE(CSuperClass) (or CR_DECLARE_STRUCT). */
#define CR_DECLARE_SUB(cl) \
        struct cl##MemberRegistrator;

But CLosHandler it is not declared in CObject. Does the above comment refer just for 'inner' classes ? Or is the CObject case special ?

2. From creg.h

Code: Select all

/** @def CR_MEMBER
...
 * - a std::set/multiset included with STL_Set.h
 * - a std::list included with STL_List.h
...
 */

I had some errors in rts/Sim/Weapons. Does those lists include also lists like (in Weapon.h):

Code: Select all

        std::list<CWeaponProjectile*> incoming; 

[jcnossen]

1: Inner classes yes, not derived classes
2: That should work, as long as creg/STL_List.h is included, and CWeaponProjectile is also registered to creg. CInterceptHandler also uses std::list, if you want an example.

[malric]

2: That should work, as long as creg/STL_List.h is included, and CWeaponProjectile is also registered to creg. CInterceptHandler also uses std::list, if you want an example.

Thanks, it wasn't obvious for me that I have to include that file.

[jcnossen]

Do you agree with copying your changes to osrts as well? (LGPL)