Starting from next major spring engine release ( at least 6 months from this post, version something like 0.83.x ), spring will stop handling hardcoded game end conditions

the Lua API to handle lineage and display old game end condition are removed as well

mods will need to use a gadget to implement game end/victory conditions

GameOver call-in will now return a list of winning allyteams
added new synced call-outs to declare GameOver and to kill a team
teams will be able to stay alive with 0 units by default, manually killing them will be necessary

a sample gadget that reimplements kill all units game end is being included in springcontent, LuaGadgets/LuaRules/Gadgets/game_end.lua
the gadgets has the following features:
never ending game and teams don't die even with 0 units option
teams die when they have 0 units ( same as current beaviour ) option
teams don't die when they have 0 units, but die when the whole allyteam has 0 units option
option to let dynamic alliances have shared victory

I strongly reccomend modders to set default game end condition to "allyzerounits" ( teams die when 0 units in the whole allyteam ), this because it will allow players who dropped out the game to be /take'd and when will rejoin, they'll be able to resume playing by getting their units being shared back

here's a code snippet to add the gameend's options to your modoptions file:


updated the wiki accordingly

some forum moderator please make this thread stick in Game & Mod and Lua sections of the forums

imo this should go above the topics section under "announcements", like the starting units one...

Oh that is very nice to see that Spring gets more Luaified

if you are already doing that why arent you all just doing it right

and making everything Lua?

Thanks BD!

I really like the ability to reconnect after a crash/disconnect already, and seeing this kind of integration really pushes the engine forward.

So, any gadget using the function Spring.SetUnitLineage will now crash?


Is the commander unitDef tag getting removed too? I see no use of it in your replacment gadget. Even if it no longer means anything to the engine, I'd like the commander tag to still be part of the "main" list of unit tags, instead of having to move it to a custom unitDef tag, if only because so many widgets and gadgets rely on UnitDefs[id].isCommander

I recall hearing long time about a unitDef tag that make some unit "do not count" for gameover, such as, a mod would mark mines with these, so that player lose when all they have left are mines. But I don't see it in your gadget. Then I can't find any info about it anymore, so I'm not even sure this tag was ever implemented.

If the first thing I do is morphing my startunit, do I lose the game? (Since morphing is destroying a unit then creating a new one) Where's the couple seconds grace between losing last unit and losing the game?

yes


I didn't, no idea if anyone has intention about doing such


there was no such thing in the engine's gameover logic, the only related stuff I can remember, is a gadget from KDR that selfd'ed all remaining units if they all had the "do not count tag" ( useful for mines, etc )


Probably, I didn't check so, try it?
morphing is quite mod specific btw, this is supposed to be a generic gadget, feel free to edit to fit your needs
out of curiosity, why the grace time after losing the last unit is so necessary? wouldn't be more correct instead to pass the info to the game end gadget that the unit is being morphed?
in the engine the grace was simply the effect of the check being done every slowupdate, so it could be anything between 1/30 to 16/30 fraction of a second ( at speed 1.0 ) according to the frame when the last unit died
EDIT: grammar and reference about speed 1.0

Oh, so it was a custom gadget relying on a custom tag? Nevermind then!




Well, a couple second grace is a more generic method. The standard CA morph gadget may not the only way to create a transitory period where the unit is missing. Inter gadget communication sounds nice in theory, but is iffy in practice, and would make porting gadgets from one mod to another harder. Every time a new person write a new morph-like behavior, it would be a pain to have to remember to also write special code to tell game_end to hold on for a bit, as opposed to having the game_end gadget transparently automagically handling it without even having to think about it.

Lastly, it feels much better to get to see your commander explosion death mushroom billows, than having the autohost instaquit the moment commander health reach zero.

- Sure, springie and spad code could be changed to let game run couple seconds before exiting.
- I could change my single player menu to add a couple second delay as well before it shows up.
- I could update my Lua load game gadget to workaround the transitory no unit state
- I could update the three gadget where I morph the start unit to workaround the transitory no unit state
- The gameover screen could be disabled, and new one implemented in Lua that doesn't appear before a few second.
- I'm only listing problems I can think from the top of my head in the one mod I'm familiar with, but:
- Ectera, all that multiplied by every Spring mod in existance

Or, a couple second grace, or at least delay, could be implemented once and for all where it belongs, in the default game_end logic.


LoL, so I imagined "a couple seconds" that were never there in the first place?

this already happends in spads case

anyway, now the sample gadget will take from 1 to 16 frames to detect a team died, so you can quickly replace units
gameover will be detected exactly 16 frames after the last allyteam died

I would also be against removing isCommander.

All mods written for the hardcoded logic will make sure that the team never falls to 0 units through morphing (always create a new unit BEFORE destroying the old one) anyway, any mod written afterthat can just adjust the game end logic anyway.

lolbump, maek resticky.

Does this also mean the removing of the "com ends" option?
If yes, it might be worth noting that lobby devs should remove it from lobbies as well.

yes

not necessary since it wasn't hardcoded since several years, engine uses same interface as mods to give to the lobbies the game end condition, and I simply removed it from engine options, so lobbies will automatically get the option removed

there is still a "com ends warning" widget in the engine test version, it should be removed?
LuaUI\Widgets\gui_comm_ends.lua

thanks knorke, will do!

When I perform a Spring.GameOver(WinningAllies)

Are the widget:GameOver() callin of every widget executed?

I would assume they are.

So would I have, except that I tried and ....

I am still waiting on this to be setup. I have heard nothing of this beyond that what I am looking for may be this:
https://github.com/spring/spring/blob/m ... me_end.lua

is this what you need z? if not what is missing?

https://github.com/spring/spring/blob/m ... me_end.lua
comment at top is wrong:


gadget would not work for me, it did not kill playerteams with 0 alive units. I just c&p'ed it into my mod "as is."
Added echos like this:

And it only spammed "team 2 - 80 units alive" with 2 being gaiea team.
It did not seem to check the actual player teams.
(the 80 is correct, i have some gaiea units)
When you do /cheat /give someunit after the game has started, it will start spam "team 0 - 1 units alive", only counting the newly spawned unit and ignoring the original startunits.
I tried changing the layer=0 but no sucess.

Seems like it does not catch the UnitCreated() of the startunits (in my mod you start with 2 units) because when inserting
gadget:UnitCreated(0, 0, teamID)
gadget:UnitCreated(0, 0, teamID)
in function gadget:Initialize(), then everything works correctly.
my startunits spawn gadget

Also does the "ignore gaiea" part still make sense? I think I read something about gaiea now being unkillable by KillTeam(tID)