The stuff at start was mostly just meant to explain reason why for "maps and teams matter for regular games, too"
think most of these restrictions aren't suitable for games - they are too specific. They are probably more suitable for (skirmish) maps.
I think they are not too specific:
For example in most RTS if you select a four-player map then the lobby only provides four player-slots.
If a fifth player enters the room then he can not play. Select a map with more player-slots and more players can unspec.
Only allowing the amount of players that a map supports is imo basic RTS stuff.
(Can give more examples but post is already too long anyway)
Most of the time lobbies don't interact with mods directly, they ask unitsync instead for (constant) mod information. Executing arbitrary Lua code might also be difficult for some.
Yes, idea was that his communication would be via unitsync, too. Unitsync would execute the Lua code, just like it already does with modinfo.lua, mapinfo.lua, modoptions.lua etc.
(My knowledge of unitsync and lobbies is vague, so I hope that is how it works and makes sense)
For example startpositions of a map, currently works like:
1) unitsync reads them from mapinfo.lua
2) unitsync tells lobby: startpositions are at (120,800), (750,80) and (320,10)
3) lobby display that information
The trick is that if unitsync is executing the Lua code of the game.sdz then lobbies just have to re-read the mapinfo.lua so maybe lobby-side not much needs to change?
1) lobby sends to unitsync: "There are 2 players in room."
2) unitsync tells mapinfo.lua: #Spring.GetTeamList == 2
3) mapinfo.lua responds to unitsync: startpositions are now at (55,123), (70, 1080)
[note: only 2 and different then prev example]
4) unitsync tells lobby: startpositions are at (55,123), (70, 1080)
5) lobby display that information
From lobby perspective it is like someone clicked "refresh maplist" and mapinfo.lua got re-read, lobby still get gets mapinfo.lua data via unitsync.
New thing is that the "refreshing" happens more frequent and step (1) where lobby has to give room-info (player numbers etc) to unitsync.
Unitsync would need to provide analogs of this to the game:
Spring.GetPlayerList
Spring.GetTeamList
Spring.GetPlayerInfo
Spring.GetAIInfo
Spring.GetAllyTeamInfo
Spring.GetTeamInfo
Spring.GetTeamLuaAI
Spring.AreTeamsAllied
Game.version
Game.mapName
...
(not all needed at once, could slowly be expanded)
knorke: Find a way for lobbies and game-archive.sdz to talk back and forth to each other.
gajop: Seems like a good idea but would need the teams table anyway to specify at least some valid team configurations so people wouldn't need to guess valid player/AI slots, and similar.
There could be some protocol how mod can set back valid team configuration.
Like this the mod could even balance teams, if wished.
I'm just worried it might be too difficult to provide such lobby<->mod communication.
Probally.
But from naive non-lobby peopleperson perspective the "missioninfo.lua"-way does not seem easier to implent.
Realisticly one should note: not even validMaps.lua really works despite engine-side it is appearently fully implented and everything.
Last I checked TASclient was only lobby that used it.
(
http://springrts.com/phpbb/viewtopic.php?f=64&t=27491 )
Similiar little feedback had the idea of allowing lobbies to start the ingame mission-selector that some games
already have: http://springrts.com/phpbb/viewtopic.php?f=64&t=30376
Only CarRepairer added a button to weblobby but it did not quite work and was then removed again.
It needs opinion of unitsync/engine and lobby developers if they consider it worthwhile to work on these things, otherwise whole discussion goes nowhere.
Basically depends on them how complex this system can become and still have realistic chance of being implented.
Realistically on mod-side the mission-content is just as WIP as on lobby-side
For other random thoughts on missions made thread here:
http://springrts.com/phpbb/viewtopic.php?f=14&t=32249