Feature Request: Allow creation of AllyTeams/Teams during runtime

[Arch-Shaman]

I'd like to see two new functions added for modders/gamedevs to be able to add team/allyteams during runtime:

CreateNewTeam(int allyTeamID) -> Creates a new team under allyTeamID CreateNewAllyTeam() -> Creates a new allyteam.

An example use case for this would be to create a second neutral-hostile team without needing to modify startscripts when you cannot (like modding on ZK) or for modoption based ais (like zombies in ZK).

[lhog]

From the first sight it's not as easy as I expected. First off the engine seems to expect that gaia team is always the last one. If new teams are added, then gaia team needs to move, but what if its ID was cached on widget/gadget side before? Or the engine internals need revisit to remove the aforementioned assumption.

Secondly, it's likely that the new network message will be required to notify about the new teams. I'll check with @marcushutchings

That said the ask is not unreasonable and worth doing eventually.

[marcushutchings]

Does Zero-K not support adding new AIs? This sounds like a game-side issue. If there's an issue with community-created AI support, then has this matter been brought to the attention of @sprunk and @GoogleFrog? It would make sense to establish what the problem is on the game side and understand why it cannot be solved there first. Then if there is a genuine limitation that requires engine changes, then we'll have a better understanding of what needs to be achieved and how it can be done.

[Arch-Shaman]

I discussed it with @sprunk in our #modding channel and they said to open a feature request issue.

[marcushutchings]

Thanks for the link. That makes more sense now. So the players choose a campaign scenario, but they won't know how many enemy teams that scenario is setup for them. The scenario needs to configure that during initialization. Would that be a reasonable understanding of the ask?

[Arch-Shaman]

Correct. Sorry for the miscommunication, very out of my element here.

[marcushutchings]

No worries. A request comes in, but we don't have the benfit of the full back story behind it and unable to tell whether this is a request is on a whim, or whether it is after much consideration, discussion, and exploration. I was worried that the expectation was going to turn into arbitrary adding of teams mid-game, (sim frame > -1) or something.

Interestingly, I think this does involve telling the server about the new team, but will need further investigation. The mod/game itself would also need to be prepared to handle the situation where the request gets rejected or fails - for example, if somehow one or more teams have too many units (say another mod spawns a ton at start up.. assuming that is possible) and the team unit limits cannot be lowered. In situations like that the engine cannot be expected to take remediation action because that would require a policy and policy requires context, which is something that lies firmly in game domain.

[marcushutchings]

If it helps: we're also on the Zero-K Discord, and keep a half-an-eye on the engine channel. ;)

[marcushutchings]

@lhog I suspect BAR will need this change as well in the future because co-op campaign is on the Steam roadmap.

[sprunk]

I suspect BAR will need this change as well in the future because co-op campaign is on the Steam roadmap.

Co-op doesn't need it as long as you don't support adding new teams (teams, not players) mid-game. The menu/lobby can add the teams beforehand if it knows how many people there are going to be. The difference compared to Shaman's use case is that Shaman is a modder so has no control over the lobby.

Even if you have control over the lobby, it's a hassle to make sure all places support it. This is the second use case. For example in BAR players need to add a chickens bot manually, which is bad UX. In case of ZK we add the bot automatically if the player has picked the chickens modoption but we need to replicate this behaviour in our equivalent of SPADS (for multiplayer) and the skirmish menu in lobby (for singleplayer), presumably BAR would have to go the same path (made worse by the fact you're considering making a new lobby, so that's potentially a third place) unless this feature exists.

I think this does involve telling the server about the new team, but will need further investigation.

Yes, the gameserver doesn't seem to know about events that happen via Lua so uses the initial setup but also performs some spoofing checks. There were issues related to the recently added Spring.AssignPlayerToTeam about that.

I was worried that the expectation was going to turn into arbitrary adding of teams mid-game, (sim frame > -1) or something.

This would be good if we got that "for free", but it's fairly easily workable around since most use cases know about extra teams right from the start.

[GoogleFrog]

It sounds like Shaman wants the power of preset AI teams from WC3. This is a tower defense map that puts an AI player in the last slot as soon as the battle is opened. The host can't remove it. For spring this would be some sort of system that allows mods to append the list of teams and allyteams at the point where the startscript is read. Nothing downstream would need to know the difference between teams that existed in the startscript and teams that the mod defined for addition (games could of course set customkeys to distinguish them). It's essentially an extension of Gaia - a list of teams and allyteams that the startscript didn't ask for.

There isn't anything stopping a game implementing this for themselves, but that would involve customising the lobby server as well as any player based hosting system (whether SP or MP) to read the information either from within the mod or from some kind of metadata. It would essentially lock the game to the particular infrastructure that it is compatible with. This seems bad. I don't think we want to go down the path of games requiring particular startscripts to even run correctly.

Adding allyteams and teams midgame would be nice for other reasons. For example we could make spectators able to join midgame.

[sprunk]

I stumbled upon my old post which has more info including some use cases https://springrts.com/phpbb/viewtopic.php?f=21&t=38500&p=588810#p588810