Spring RTS Engine

I could have a use for custom handicap. Currently, as far as I know, handicap only impact resource production, which is worthless in a resourceless mod like Kernel Panic. Also, they have a weird inverted logic, or something confusing like that.

Some exemple of case uses could be:
- A KP game where ONS game mode is ON, where the leet player manually turns theirs off. Like, while all the other newbs keep their shields, I wanna play without. For the overall game, ONS mode is still on (for exemple my nodes still provide linking to my team's network), just for myself the shields are not there. Ideally, that kind of handicap would be hidden when ONS mode is not set. There would be a tick box, ticked by default, when ONS mode is enabled, and I would have to actively untick it manually myself, and that tickbox would not even show up if ONS gamemode set to 0.
- A KP game where game mode are all normal, but I feel like giving myself some extra challenge to enable the SoS mode just for myself: All the other people play the regular game, while myself, in addition to the regular game, also has to play SoulCatcher or I'll lose all my mobiles. That way I have an extra challenge, to counterbalance for exemple that the other team is full n00b. I would have to be able to set that all alone, without requesting host assistance. And instead of the tickbox, this team I would need a pick-a-number box.


Instead of having one handicap which is just one number and isn't even accessible by Lua ingame, I'd rather have something as complete as mod option or map option. That is, allow several handicaps, and have each own be either a dropdown list or a numeric value within range, with a default value and custom name for each one. In fact maybe even the name handicap should be dropped, cause the system might be used for stuff that have nothing to do with handicap. Ideally, we could even dream of abstracting the rest of the team & player info, maybe a mod would prefer the color to be a drop down list (for exemple Operation Polaris uses a discrete set of teamcolor, that are each a different kind of camo texture), many mod have one single faction making the faction choice irrelevant, but some mod may want to have each team be a cross-breed of two races, etc... So add a color picker and a drop down menu with icons in the list of possible key type.

So yeah, more than Custom Handicap, my request would be custom team attributes. Make them passed through extra custom entries in the[TEAM3] { ... } parts of the startscript. Make them accessible by something like Spring.GetTeamOptions(teamID)["keyname"].

let's be a little more general and call it PlayerOptions.lua. not a bad idea.

That is too restrictive. We need both:
- PlayerOptions.lua
- TeamOptions.lua

i'd suggest you to read what modoptions can and cannot do, it can already do what you asked

Brain Damage wrote:i'd suggest you to read what modoptions can and cannot do, it can already do what you asked

What? You can have per-player modoptions, with each option set by the individual player?

Brain Damage wrote:i'd suggest you to read what modoptions can and cannot do, it can already do what you asked

Point me to where I shall read about that.

Pxtl wrote:

Brain Damage wrote:i'd suggest you to read what modoptions can and cannot do, it can already do what you asked

What? You can have per-player modoptions, with each option set by the individual player?

Per-Player, team or allyteam.

So, in #sy Auswaschbar told me that it's already supported, all I need is to add: scope = 'team', in the keys of my ModOptions.lua

Then in #sy, BrainDamage retorted that:
- No lobby support that
- Even if they wanted, they couldn't because of the protocol.

I personnally could still have a use for this feature even before it's supported by multiplayer lobbies.

But I am still searching for the proper syntax to read them in a gadget.

I did try, added custom team keys manually in a script and attempted to get them with a Spring.GetModOptions()["keyname"] I was hoping it would return a table, but got a nil.

In short, since it only exists on paper, request is still valid.


Edit: Nevermind, BrainDamage helped me track it down.

The syntax to read them in a Lua is:
local _,_,_,_,_,_,SeventhOne=Spring.GetTeamInfo(teamID)
local Value=SeventhOne["keyname"]

Convoluted, but works. Thanks.

zwzsg wrote: Then in #sy, BrainDamage retorted that:
- No lobby support that
- Even if they wanted, they couldn't because of the protocol.

to be accurate, i said that it's possible to support, but it needs lobby devs to define a convention in order to show the options properly to the clients ( in multiplayer ) without turning stuff into a mess

I have just implemented and tested with success a noons (No ONS ) custom handicap key in KP, and will soon add at least one more.

If lobby don't support them any time soon, that's okay, I needed them mostly for single player anyway. And for multi I have a custom command that does the same: if you want to set a handicap on you, it implies your are leet enough to be able to enter /ons 0 in Spring's console.

So yeah, take your time to define your lobby convention, I'd rather have it done right and clean than rushed out, since there's no urgency as now the only advantage of lobby support would be to have it pickable through a nicer GUI.

Added handicap to GetTeamInfo return values.

So, I added a scope='team' to a modoption, to see how lobbies handled it. I expected them to ignore that scope line and just throw it amongst the other mod options. Instead, both TASClient and SpringLobby completly ignored the whole ModOptions.lua just because one entry had this scope='team'.


Well, not that I care that much, it works fine between my custom start script writers and Spring.exe, and that's all I need.