Mod-definable lobby game options

[Gnomre]

I'd like a way to set up a profile of some sorts to change default values and such of the 'built-in' game options in lobbies. I don't really care if it's an extension of modinfo.tdf or a new tdf or lua or whatever file as long as you pick a format and stick with it.

We should be able to disable/adjust these things to suit individual games. For example, the "Limit D-gun" option is only applicable to the TA-based mods which use the dgun, it has no bearing in SWIW or S44 or Gundam or most other mods. Being able to hide it on a per-game basis would be ideal.

Additionally, changing the 'suggested default' of the resource sliders should be allowed to us. 1k/1k isn't always ideal, but it's easier to balance around that atm than to tell users "oh yeah and don't forget to change this to x because we can't change the values for you and that's how the game is meant to be played." Setting a minimum, maximum, and default value for the resources would be ideal, but it's fine if the lobby saves the previous game's setup (it should do this on a per-mod basis if it doesn't already). There should probably also be a way to hide one or both resource bars for any games that may only make use of one.

For extra icing, being able to change the names of the "Energy" and "Metal" strings would be great. Same applies for the word 'commander' in game end condition settings, and any other TA-based phrasing.

Finally, I'd like a way to disable particular units from showing up in the disabled unit list (without disabling them in game) besides the apparent hacky way of converting their FBIs to luadefs.

[Warlord Zsinj]

This would definitely help to move the lobby towards a more general-purpose lobby that can be used by all mods, and is not purely geared towards Alphabet-Soup mods.

[rattle]

^

It'd be good if the lobbies would take same direction as spring, that is putting a distance to TA by being more uniform.

[AF]

In AFLobby all these options are presented in the same way together, there is no distinction between the mod lua options and the defaults.

Ideally these default options would be moved into the *A mods as lua based options and removed from the engine.

[Satirik]

mmmh or just be able to enable or disable the default options ... and you could do whatever you want in the mod options ...

[Argh]

+1 to the idea of just disabling it via the mod options, it'd keep backwards-compatibility issues down...

[KDR_11k]

Disabling the default options would be nice, the metal and energy sliders do nothing for THIS or Fibre anyway so all they do is confuse and make the mod look like a hack.

In fact I'd prefer if these things were converted to gadgets and modrules that the mod would have to include, that way mods could also enforce com ends or remove the setting (Fibre, for example, shouldn't be played with com ends as the buildings a player made should remain capturable by whoever comes along). These rules shouldn't be hardcoded.

[Peet]

In fact I'd prefer if these things were converted to gadgets and modrules that the mod would have to include, that way mods could also enforce com ends or remove the setting (Fibre, for example, shouldn't be played with com ends as the buildings a player made should remain capturable by whoever comes along). These rules shouldn't be hardcoded.

Definitely, though every mod would need to implement this.

[Gnomre]

You could just stick them in one of (or is it just one now? ) the base files to maintain compatibility.

[zwzsg]

I agree with Gnome.

For Kernel Panic, I want to change the name of the end condition to:
- Kill the kernel
- Kill all sockets and kernel
- Kill all units
Plus ressources sliders are irrelevant, etc...

Which I could do by making all socket commanders, however the end condition that says kill the comm would be the one that is kill all socket and kernel, and the one that says lineage would be the kill the kernel one, which would just make things very confusing.

It is also very annoying that the first tab present all the useless option (for a non TA mod), while all the useful option (for a mod that is more than TA rebalance) are in the second tab no one can be arsed to check.

And as Gnome said, having them tdf or lua or whatever mod defined, while putting a copy of the needed tdf or lua or whatever in the TA base file shipped by Spring, would mean the engine and lobby remains untainted while the old mod remains compatible? Well, save for the non-TA mods that still use those option and whose maintener isn't around anymore.

[aegis]

bump

[AF]

Battlehub does not distinguish between default options and custom options GUI wise save for the internals of how they're implemented.

If you can devise an API that would sort out this whole mess then Im sure itll be used once its implemented by lobby developers.

[koshi]

Why not just drop those options altogether, forcing all modmakers to provide appropiate modoptions? I don't see the need for an additional api that lets modmakers change those options' names when the functionality is already there

[AF]

This would break backwards compatibility.

However if the spring engine included a default set of option rules that implemented the existing options that could be overridden then this would be the best way of doing it.

[koshi]

This would break backwards compatibility.

Like every other release does, no?

However if the spring engine included a default set of option rules that implemented the existing options that could be overridden then this would be the best way of doing it.

Agreed. No need to expose the overriding beyond unitsync tho. Imo it would suffice if lobbies got the modoptions howeverwhichway they were defined, no need to know if they're defaults or overridden ones.

[AF]

I would also argue that we should remove the correspondign default tags in script.txt from the engine.

Instead the backwards compat default lua options that implement them should look for the tags not the engine itself in order to make the code more flexible and keep as much of the code in one place.

[REVENGE]

With regards to this issue, it think it would be best if we keep the current options and layout as a default config, and then allow all of the different options to be mod configurable. This includes stuff like the range of the limited dgun, which is (I'm assuming) an arbitrary value at the moment. If a mod file doesn't have definitions for these options, then use the default set. Otherwise, use the mod defined set.

[Pressure Line]

This includes stuff like the range of the limited dgun, which is (I'm assuming) an arbitrary value at the moment.

afaik its proportional to map size, but i could be wrong (although it makes sense, whats appropriate for DSD isn't for Small Divide, and vice versa)

[smoth]

Comm ends - Doable via mod options
Resource sliders - we don't have sliders with mod options but can be done.

I honestly feel that mod options should supplant the default game options. Any of the current game options should not be hardwired into the engine and the content developer should implement these things if he/she wants it. Some things I support being done in engine but this request has my full support. Spring needs to be more than just TA and the ta guys could cover most of this stuff with mod options.

as far as backwards compatibility. It would take one of the lua guys about 10-20 minutes I am sure and this stuff could be covered in mod options. I am not for breaking things but this isn't so much breaking as it is properly implementing them. Having someone create the mod options files to replace the current options before removing this ota hold over crap would ensure that compatibility is kept while still upgrading the current functionality.

[FLOZi]

Comm ends - Doable via mod options
Resource sliders - we don't have sliders with mod options but can be done.

I honestly feel that mod options should supplant the default game options. Any of the current game options should not be hardwired into the engine and the content developer should implement these things if he/she wants it. Some things I support being done in engine but this request has my full support. Spring needs to be more than just TA and the ta guys could cover most of this stuff with mod options.

as far as backwards compatibility. It would take one of the lua guys about 10-20 minutes I am sure and this stuff could be covered in mod options. I am not for breaking things but this isn't so much breaking as it is properly implementing them. Having someone create the mod options files to replace the current options before removing this ota hold over crap would ensure that compatibility is kept while still upgrading the current functionality.

+9001