Spring RTS Engine

Afaik the code Jools posted will only work for mods that are using some derivative (or ancestor) of BAs spawn gadget, but for *A at least you should be safe with that.

Qray. Please clarify why you need only the commander.

For JW ComEnders are Optional, but if they exist, there unitID is saved in
GG.ComEnders[teamID]

They are however rather middle to late game units, as they increase the risk a player takes (and are costly attention economic wise)

Sorry for the late sign of life from me, I was quite busy today and in the evening had an arrangement with a couple of friends for map testing in-game ... somehow the times when you're not at work are always the ones when you have the least time

First of all: thanks for all the replies!

Second, just to make the goal clear: it's for a gadget included in -up to now- two maps that optionally alters the game goal to "king of the hill": go in a defined zone of the map -> occupy it for a certain amount of time -> win (==when time is up for this team, all other teams are destroyed).
This should work pretty much independent of the mod, as long as it can be played on the maps.


Trying to go through the replies:

I am aware that not all mods have commanders; and for some KotH probably makes no sense at all - with or without com. Maybe I should have phrased this better in my first post.
But I was under the impression, that many mods besides BA have a com unit, too. But I might be wrong and it's only a few other (*A?!).

Why a commander for KotH: the easiest answer is that the script from Alchemist, which is the base of my additions/fixes, had this in...
And I have to say, needing a commander to occupy the hill zone makes the game play more fun than just having to get any unit in the zone to activate it (from that point on, any unit counts until control is lost == all units removed from zone).
This argument holds obviously only for mods, that have only a single com unit per team. If you can have/build more than one com, it fails mostly... maybe not completely.

Since the current gadget version works probably only for BA correctly, and in the map thread it was mentioned as one of the things that could be improved, I wanted to try so (among other fixes).
And I had hoped there would be a standard way to test for com.. which would have been an easy way to adjust it for more mods than just BA.


After reading all replies, I agree that catching the first spawned unit is a bad idea. Thinking about it, I tend to do it -at least partly- mod wise. This way, there would also be a way to just stop the script if a mod is played that has no com. Maybe check for the mod in a separate function.
A list of units per mod would be more foolproof, but I agree that a single list could be better in other respects.

Testing for supported mods could also be used to accept any unit in the zone if the mod has no com... but this would be a quite different game play and I am not sure it it is worth it.
Probably, not too many players are interested in this modification anyway (*)


All the hints how to find a com in different mods and pointers to code are very helpful! Thanks a lot, big help!

I surely also learned a bit more about other games. I guess I have to do some research now and have a look at several mods and see how games/things work there in detail.

Thanks again, qray.


---
footnote
(*) but me and a couple of friends had much fun playing this mode in a non-public BA mutator I had packed. So I improved the original script step by step and in the end thought I might share it publicly in the form of a map gadget

Haven't played your BA KotH but I've been playing lot's of DOTA2... seems like the entire notion of a KOTH game is that people need to hold the center for a specific length of time and so would be unlikely to try to move their King out of the Hill for as long as possible... this means that the way your game works you are highly likely to have the person holding the center lose their King and henceforth be denied the possibility of a win... but if you had one special unit (spawned by your map for each team) that you needed to escort into the scoring zone... and that this unit would re-spawn at your base if an opponent took the hill... the whole issue of "what's the Com unit" would be mute.

Neat idea to create an extra unit. Haven't thought about this option so far...
I guess partly since I don't have a clue yet how to make units but that's a minor detail that probably can be solved

Would alter the gameplay a bit, but not necessarily to the worse.

While I still like the idea, sleeping about it, I think that introducing an extra unit would open a completly new can of worms.
Would be a neat solution if introduced in a mod. But kind of mod-independent, it's probably not perfect (unit doesn't fit then the other units regarding looks, health, move speeds...).

So, I'll give the com finding a shot first.

You could also just check for units than can D-Gun (.canManualFire) or that can capture, but again, also decoys can do that in XTA, although not in BA I think.

By the way, that code to get the startunit (Spring.GetTeamRulesParam) is a general callin in Lua SyncedRead. I think it works for every mod. It would probably be sufficient for your purposes, I mean, it's not so often that your start unit isn't your commander.

Also, I think startunit doesn't equal the first unit. I think startunit as defined in engine is just a way to update what startunit was defined in lobby (meaning arm/core commander). if you remember the first mission in TA, there is no commander there at all, the first mission is to find your commander.

Please correct me if I am wrong.

Jools wrote:check for units than can D-Gun (.canManualFire) or that can capture

fails in zK,
KingRaptor posted something that works in zK.

By the way, that code to get the startunit (Spring.GetTeamRulesParam) is a general callin in Lua SyncedRead. I think it works for every mod

GetTeamRulesParam only reads what some gadget has written via SetTeamRulesParam.

Earlier this used to be so convenient with the universal .isCommander tag.

Jools wrote:Earlier this used to be so convenient with the universal .isCommander tag.

But it really wasn't, as games could still spawn a heap of crap at game start (like S44)

but only the S44 HQ building would have had isCommander=true, none of the extra infantry, trucks etc that you also get.

If all games could decide to use customParams.isCommander=true, that might be pro.

Moral of the story: either

1) Make your special mission general enough for all games (already done, current koth exists right now)

Or

2) Just make your commanderkoth into a BA mutator intended to be used with BA commander.

smoth wrote:Many things, KOTH included are project specific.

When we get into MODES of gameplay we are talking specific to certain projects. Not everything is going to work for all projects.

My KOTH works for every project (except the endgame animation bit where I pull an explosion). But then I don't care about commander, I just check which unit is closest to map center. And make KOTH starts only after somebody has killed somebody else's unit, to prevent advantage to whom spawn closest.

yeah, i had initially thought he was talking about yours z.