Engine options: proposal to let mods edit them in the lobby

[BrainDamage]

Currently there are certain engine options whom get added to the option list regardless if they make sense for the mod or not.

the following proposal lets modders fine tweak which options to show and their properties:

• remove engine options section/tab from the lobbies
• introduce a new tag in modoptions "engineoption:", which when present, the option instead of being written to the [MODOPTIONS] section, will be written to [GAME] instead, the option will have to list the full range of the engine option params, so it will be possible for example to remove lineage mode for commander ends just by not listing it, example:

  Code: Select all

  	{
  		key="engineoption:gamemode",
  		name="Game end mode",
  		desc="What it takes to eliminate a team",
  		type="list",
  		def="0",
  		items={
  
  			{key="0", name="Kill Everything", desc="Every last unit must be eliminated, no exceptions!"},
  
  		  {key="1", name="Commander Ends", desc="When the commander is dead, the game is lost for the player"},
  		}
  	},

• introduce a compatibility file on the engine side which would allow old mods to retain the normal engine settings unless told explicitly

the latter can be done in multiple ways, to mention some:

• include modoptions.lua in springcontent.sdz so it will be loaded unless the mod has already one ( the modder then could copy in his modoptions.lua file the engine option he wishes to be included )
• include engineoptions.lua as accessory file in springcontent.sdz and have such file to be auto-appended to modoptions.lua, mods can override it with a blank file to get rid of them or just copy the wanted options
• have a boolean option "dontincludeengineoptions" in modoptions.lua which default to false which toggles the include of default engine options ( all of them together), if modders wants only certain, they'll disable all of them and copy only the necessary

the following options could be still be hardcoded in the lobby ( imo ):

• lock game speed
• lock ingame alliances

if none is against the current proposal it could be adapted on next spring release since the amount of changes is really minimal on both engine & lobby side

[AF]

Over-engineering.

There's a solution thats both backwards compatible and requires no changes in most mods. Nor does it increase the complexity of the loading code for options, and it makes game options more consistent.

• Create a list of game options as mods such as THIS already do that define the existing options, and put it in one of the main spring archives like spring content or otacontent.
• Modify the spring engine to load from the mod options entry rather than [GAME]

This allows content devs to override and tweak the existing options, or not to have them at all if they so wish. Its also easier to implement, and requires less effort while increasing consistency and simplicity in the main file.

To do this engine side would require a handful of changes, basically inserting a small chunk of text into a handful of strings. So "GAME\\metal" becomes "GAME\\MODOPTIONS\\metal".

It also opens up an avenue for simplification of the lobby protocol since custom options and these options could both use the same protocol mechanism. This would also mean simplification of lobby/autohost code.

My one qualm is that perhaps it would be an ideal opportunity to deprecate MODOPTIONS in favour of calling it GAMEOPTIONS or just OPTIONS which would be more semantically correct and elss misleading. Of course with backwards compat checks

[BrainDamage]

There's a solution thats both backwards compatible and requires no changes in most mods. Nor does it increase the complexity of the loading code for options, and it makes game options more consistent.

that was my first idea, but it requires for the engine to reimlement all the options using lua, unless someone is gonna step up (you since you proposed it? ) it will end nowhere like many other "good" proposals from the past, the idea was designed to have minimal impact on both engine & lobby code, the "proper" solution would take much more time and has the big risk of being dropped midway.

[imbaczek]

adding a default ModOptions.lua to springcontent would work with even less hassle; no engine changes needed, no lobby changes needed (except hiding the hardcoded options tab.)

[AF]

It would not require re-implementation in lua. The only reason lua is involved is so that the options appear in the lobby, such as the following modoptions.lua below:

Code: Select all

local options = {
{
    key    = 'energy',
    name   = 'Energy',
    desc   = 'The amount of energy resources the player starts with',
    type   = 'number',
    def    = 1000,
    min    = 500,
    max    = 10000,
    step   = 0.05,  -- quantization is aligned to the def value
                    -- (step <= 0) means that there is no quantization
},
{
    key    = 'metal',
    name   = 'Metal',
    desc   = 'The amount of metal resources the player starts with',
    type   = 'number',
    def    = 1000,
    min    = 500,
    max    = 10000,
    step   = 0.05,
 },
}
return options

Which would make energy and metal show up in the lobby as mod options, but since no lua gadgets read them they're just there for show. The engine will then read these tags and hey presto!

I'd do ti right now but I have no means fo testing and building, nor do i know where I would look.

[Satirik]

adding a default ModOptions.lua to springcontent would work with even less hassle; no engine changes needed, no lobby changes needed (except hiding the hardcoded options tab.)

not really it would override the one from the mod and you'd loose the mod options or the mod one would override it and you wouldn't see the engine options, dunno which one is added first in the vfs but in both case it fails

[AF]

we could always put it into a defaultoptions.lua file and add an include directive in modoptions.lua, any mod with their own modoptions.lua would simply add their own include directive or the engine can parse both files.

[jK]

not really it would override the one from the mod and you'd loose the mod options or the mod one would override it and you wouldn't see the engine options, dunno which one is added first in the vfs but in both case it fails

First the mod overwrites the base content.
Also it what we want or not? Mods should be able to remove stuff like commends, startM, etc.

[AF]

tbh we should move the tags into MODOPTIONS anyway in the lobby and spring ven if we dont bother with lua and the ability to tweak them just yet simply for consistencies sake.

[Licho]

I would ditch all legacy settings and keep just current mod options system.
Old mods can be converted if someone really really wants to play them..

[AF]

Id support any attempt to do that

[Satirik]

not really it would override the one from the mod and you'd loose the mod options or the mod one would override it and you wouldn't see the engine options, dunno which one is added first in the vfs but in both case it fails

First the mod overwrites the base content.
Also it what we want or not? Mods should be able to remove stuff like commends, startM, etc.

but by doing that they would be removed by default ... and that's not backward compatible

[Licho]

Seriously, why backwards compatibility? Most old mods probably dont work under current engine.
Active mods can be fixed for new system in couple of minutes.
So why adding effort and cluttering things why keeping legacy support which nobody is likely to use?

If someone really really wants to play some 2 years old mod, he can use 2 years old engine and lobby.

[AF]

For which we may well have a solution implemented in the future for ultimate backwards compat anyway so I agree with licho here

[KDR_11k]

adding a default ModOptions.lua to springcontent would work with even less hassle; no engine changes needed, no lobby changes needed (except hiding the hardcoded options tab.)

And it would fail with any mod that has mod options, including BA...

Reimplementing this stuff in lua could be done, sure, it's just a lot of work duplicating code that's in the engine anyway. We can make huge plans or we could make a small change that would work just as well...

[Tobi]

+1, I don't see point of removing code only for it to be rewritten multiple times in a slower language, with more bugs cause it's new code, etc.

We have working code for all those options, it's trivial to read their setting from script.txt by changing TDF path to e.g. GAME\MODOPTIONS etc.

It's probably even more work to remove all traces of it from Spring then to just change from which tag they are read.

To make it work in BA/XTA etc. without forcing them to make a new release exactly on date of new spring release, just make Spring parse engineoptions.lua too and add this to springcontent.sdz. One can override this with empty file or with file with options removed from it if one doesn't want (some) engine options.

[AF]

they already release new versions within 48 hours of every new version of spring as it is anyway.

[Tobi]

No reason to force them to do that always.

Actually there's numerous reasons to NOT force them to rerelease after every Spring release.

[Tobi]

This is implemented now by BrainDamage and me (r6824):

* Read start script options from GAME\ModOptions section instead of GAME section.
* Unitsync GetModOptions method parses both EngineOptions.lua and ModOptions.lua now.
* Added EngineOptions.lua to springcontent.sdz, this contains backward compat engine options.
Ranges/descriptions/etc. can be overridden by mods by including EngineOptions.lua by themselves,
though remember that engine will always expect the tags to be set to particular type/range of values.

tl;dr lobbies need to be updated to not have hardcoded engine options anymore (see docs for which exactly)

[AF]

Hooray for Tobi and braindamage!