Gradual reclaim

[Rafal99]

Units *.fbi files and sidedata.tdf are parsed here: \rts\Sim\Units\UnitDefHandler.cpp

Weapons *.tdf files here: \rts\Sim\Weapons\WeaponDefHandler.cpp

[PauloMorfeo]

... IMO there's no need for a "gradual" reclaim, ...

IMO there's no need for a "chunkal" reclaim!

Gradual for the win! Will probably be easier to code and make much more sense.

[Das Bruce]

... IMO there's no need for a "gradual" reclaim, ...

IMO there's no need for a "chunkal" reclaim!

Gradual for the win! Will probably be easier to code and make much more sense.

*sigh* Theres going to be both.

[Acidd_UK]

Units *.fbi files and sidedata.tdf are parsed here: \rts\Sim\Units\UnitDefHandler.cpp

Weapons *.tdf files here: \rts\Sim\Weapons\WeaponDefHandler.cpp

Thank you very much.

[Acidd_UK]

Ok, can anyone talk me thorugh how Spring initialises, loads the map/mod data and then bootstraps into the game?

I'm looking at
SpringApp->Run():
This calls

• SpringApp->Initialise():
  Initialises the graphics, mouse handler, global synched (gs) and unsynched (gu) memory, etc, then calls
  • SpringApp->CreateGameSetup():
    This creates a new instance of CGameSetup, the game setup class. It looks for the default start script produced by the multiplayer lobby and calls;
    
    • CGameSetup->Init():
      This hands itself off to an overloaded version of itself function. It gets passed the start script filename and it opens the contents of this file using an instance of the class TdfParser. It uses this to read the mod name, map name etc into class-local variables 'mapname' and 'baseMod'. It does similar things with the other game options, such as comm-ends/cont etc.
      It uses an instance of the virtual file system class (CVFSHandler* hpiHandler) to work out the map file's dependancies, uncompress them etc.
      It reads a load of game-related info esp about player numbers etc into the gs and gu.
      TdfParser and CReadMap::OpenTDF are used to read in the map information.
      Finally a big block of code reads in info about teams, starting resources, ais etc.
      So CGameSetup looks to read in the map data, but not the mod, and we return back up to
    SpringApp->CreateGameSetup() (continued):
    which does some clever stuff working uot if we're playing a demo, being the server etc and creates a new instance of the pre-game class;
    
    • CPreGame::CPreGame():
      This does some checking if the game has been properly set up yet and whether we are server or not. It then calls SelectMap(gameSetup->mapname) &;
      • SelectMod(gameSetup->baseMod)
        This does some clever stuff to work out the base mod name and puts the name of the base mod in "stupidGlobalModname" ( not my variable name ). This mod name is also returned out through the function parameter.
      CPreGame::CPreGame()(continued):
      This does a bit of other stuff, but nothing special then returns to;
    SpringApp::CreateGameSetup()(continued)
    this function returns after it made the new PreGame class to;
  SpringApp->Initialise()(continued):
  which immeditaely returns too, to;

SpringApp::Run()(continued):
This is the main control loop we started in. The flow then procees into the main game loop and I can't see where it has read in the mod data, or actually bootstrapped the main game - the main control loop here simply processes SDL events (mouse move, keypresses etc) and uses the Update() function to flip the GL graphics buffers to refresh the screen.

I'm obviously missing something here, perhaps to do with other things being threaded and thus not starting in obvious places? I really need help here cos I'm a bit stuck! Any dev input fleshing out the mod-related stuff that happens at game start would be greatly appreciated!

[ILMTitan]

A new CWeaponDefHandler is created in the CUnitDefHandler constructor.
A new CUnitDefHandler is created in the CGame constructor. This is also where activeController is set to the CGame.
A new CGame is created in CPreGame::Update under the correct conditions.

[Acidd_UK]

Cheers!

[Acidd_UK]

V0.1:

http://taspring.clan-sy.com/mantis/view.php?id=262

Now I just need to fix the resurrection exploit and it will be ready for merging, I think. Devs, please give me feedback on code quality, style etc.

[Das Bruce]

Good work.

[Acidd_UK]

V0.3 http://taspring.clan-sy.com/mantis/view.php?id=262

Devs pls examine - this is a release candidate.

[Caydr]

Hi, can't seem to get this to work. Based on the mantis topic, this is what I placed in reclaim.tdf in the gamedata directory:

Code: Select all

[RECLAIM]
{
multiReclaim=1;
reclaimMethod=0;
}

~~~

Ehh.... well, I just read the patch through.

Code: Select all

TdfParser reclaimOptions("gamedata/modrules.tdf");

So not reclaim.tdf, but modrules.tdf? I'll try that.

~~~~

Well I'll be damned, look at that. I actually solved something on my own for once. Could this be the dawn of a new era of humankind?

Yeah, so... it's modrules.tdf, not resources.tdf. Works perfectly. Should be put in changelog.

[Acidd_UK]

Sorry, didn't realise it was documented that way - I think it was reclaim.tdf originally, then it was decided modrules.tdf would be used for all global mod options like this. Sorry for the confusion

[Caydr]

np, great patch by the way.