Accessing map options before the map is loaded

[gajop]

I want to generate maps based on their map options. This would allow me to implement a proper "new map dialog" in the editor, for arbitrary map sizes. It would also allow us to create procedural map generation where the map size is also a parameter.

Spring internals assume map options are only available later, once the map is loaded. Is it possible to change this? Any suggestions how? Note that maps could have arbitrary number of options, depending on the procedural generation algorithm, so hardcoding things like the current mapseed is not an option.

Would it help if i committed my current procedural generation work to a branch? It's mostly just providing a Lua API to the current C++ engine imp, in the manner I talked about with hoko

[Kloot]

Spring internals assume map options are only available later, once the map is loaded.

No, they don't. Map options are available as soon as the setup-data (script) has been received.

The current "generator" which runs when the server starts also has access to them, it just doesn't use any.

[gajop]

Ah you could be partially correct.

I suppose map options aren't available when getting Spring starting positions.

Code: Select all

	// Loading the start positions executes the map's Lua.
	// This means start positions can NOT be influenced by map options.
	// (Which is OK, since unitsync does not have map options available either.)
	startGameSetup->LoadStartPositions();

The current map generation code was placed above this, so I don't think it could've had access to it(?).

[gajop]

So moving my map generation code further down the loading order allows me to use map options.
For example, I could put it here, and it would work:

Code: Select all

CReadMap* CReadMap::LoadMap(const std::string& mapName)
{
	CMapGenerator::MaybeGenerate();

[Silentwings]

Afaics the mapoptions are included in the setupscript that is passed to StartServer https://github.com/spring/spring/blob/d ... e.cpp#L214. I guess https://github.com/spring/spring/blob/d ... e.cpp#L222 parses them along with the rest of the setupscript, and from then on they are accessible (on the engine side).

I think "This means start positions can NOT be influenced by map options." on https://github.com/spring/spring/blob/d ... e.cpp#L239 is a requirement to avoid logical inconsistencies rather than a comment about the flow of the code.

(In short, Kloot is right.)