Should we make the lobby client disappear when the game starts and appear when the game exists?

[gajop]

No description provided.

[ashdnazg]

I'm of the thought that hiding running processes is bad.
If you want to prevent the player from using the lobby while ingame, make a big window with "Game in progress" and disable UI.

[TurBoss]

what about integrate the lobby in our games? so it only be necesary to hide the needed windows
and users could chat in game with others etc..

thats my plan for JauriaRTS 🎯

[ashdnazg]

I think the last thing you want people to do during a game is to chat with random lobby folks.

[gajop]

How would one persist the lobby connection if we wanted to close the lobby (not just disappear, but also kill the process)? I think lobby connection persistence is important for multiplayer, not just for the user experience of that player, but also for everyone else. Seeing people go offline before each game would be very odd.

[ashdnazg]

Something to the effect of moving Chobby to LuaIntro and keeping LuaIntro running in the bg throughout the game.

[gajop]

So basically:

1. Chobby starts in LuaIntro
2. Start game and leave Chobby while the connection is open (requires engine change to keep socket alive and transfer ownership from LuaIntro to LuaUI)
3. Get back to Chobby (LuaIntro) and preserve the connection (same change required as above)

Without considering the Lua socket ownership transfer issue, wouldn't this also mean that both Chobby and the game are the same "game archive"? That would be a bad idea for distribution purposes. Also wouldn't this mean that a game couldn't have its own LuaIntro?

Essentially, the question is if it's even possible to transfer from game A's (Chobby) LuaIntro into game's B (e.g. ZK) LuaIntro and then actual game?

[ashdnazg]

Ah, that's the revolutionary part!
If we order the things correctly, you should be able to keep LuaIntro alive, even during restart.
In essence early enough in LuaIntro it should be possible to even tweak the script.

So LuaIntro will be read from Archive A,
In it you tweak the script and then once game starts you allow the engine to actually continue startup - loading the game/map archives etc.
When game ends we will remove the archives from the VFS and restart (without killing LuaIntro)

I don't think any ownership transfer is needed - LuaIntro's update can keep being called during the game.

[gajop]

Related #104 : there might be technical issues from running two Springs

[gajop]

The ultimate lack of ability to play with different engines without restarting may be what puts a nail in the coffin to this idea.

[GoogleFrog]

I don't think different engines is required. I like the idea, at least as an option.

[gajop]

For this release I will implement it as an EXPERIMENTAL option that disconnects you

[gajop]

I think if we want to have only one window open at a time (game or lobby), we might as well not have it run as a hidden process, hidden lua state or anything similar.

I would propose the following solution:

1. Lobby starts the game and closes itself completely (Spring.Reload if same engine, Spring.Restart if different)
2. Before closing itself, it saves the lobby UI state on disk and separately serializes all recent chat messages. It also sends a message to the server to notify it that a restart is imminent, and that the server should keep it appear as still connected for a few minutes at least (disconnection detection can be done with the help of autohost too)
3. Game starts and connects to the lobby server (chonsole + liblobby auto connect), and the connection is then alive again.
4. Game ends and the game uses the provides start script to go back into the lobby and provides the new chat info as well

[ashdnazg]

What are the pros/cons of this solution?

[gajop]

That comment was a bit hastily ended as I was leaving the train, so to expand:
I wish to compare this solution to the two mentioned alternatives 1) background process and 2) same-process lua menu state.

1. Background process gives us a lot of flexibility, but introduces complicated distribution, and OS-specific issues. It basically adds another "moving part" in the whole mechanism, and is best avoided if possible. The benefit of the background process is that it could also be used for steam-specific things if we run into GPL limitations.
2. Lua menu state requires drastic engine changes, while this doesn't require any. Lua menu also runs alongside the game, causing potential performance issues (weak parallelism in Spring and anyway Chobby isn't lightweight enough not to have an impact). Lua menu requires same engine version, while here it's optional. The main con of the proposal is that it requires a server change by adding capability to keep users officially connected while they're switching lobby<->game. I think this change is much easier to do than lua menu state and most importantly keeps the lobby and game clearly separated as far as execution goes (lua menu state really feels like we're just hiding the lobby inside the same process)

[ashdnazg]

@gajop the server change is exactly the reason why I prefer an engine solution:

1. we currently have two servers which means two places where unnecessary complications may happen. (did you ask both servers' devs if such a change is easier?)
2. I really think having another lua env is not too complex to implement, we already have at least 5 I know of running in every game.

[GoogleFrog]

I prefer the extra persistent lua state to the solution that relies on game and server changes to implement hacky connectivity. If the persistent lua state is able to draw over games then we could have an implementation of ingame PM or friend-arrival notifications without changing any game code. We would also be able to have games implement a menu button which switches back to the lobby. We would effectively get a game-lobby interaction as nice as that in Dota 2.

Switching back to the lobby is useful, for example in Dota 2 if someone disconnects you may want to go to the lobby to check whether they reconnect. The same could happen for any Spring game.

[ForbodingAngel]

Hiding the lobby or not allowing me to see it while ingame is a bad idea. I have multiple screens, and the lobby stays on one of them when I am playing. This is so that I can help players having issues, or help players that want to know how to join my game, etc etc etc.

[RafaelLinux]

I have two monitors too, but I do not use it when playing Spring, sincerely, and if to hide/close Chobby makes it not to take 50% of my CPU, I do prefer this proposal. ;)

[gajop]

I think it's not very hard to provide ingame PM, friend notifications and similar things by just using liblobby + chonsole, (e.g. https://github.com/gajop/chonsole/blob/master/exts/lobby.lua), that looks similar to WoW.

@ForbodingAngel Both my and hokomoko's solution hide the lobby (as a separate window), where my reconnects you ingame immediately after your game starts, and hoko's keeps the menu running in a background lua state. Mine can restart the program (providing multi-engine support), where hoko's keeps everything in the same process.

The problem with a persistent Lua state is that it kills multi-engine support. I don't understand why I'm the only one expressing concern with this - what is a critical feature of the Spring ecosystem -> I've no intention of enforcing a single engine version for all games again. If anyone can provide a solution that would solve multi-engine support, I would agree to do it as LuaMenu state.

Anyway, from a technical standpoint, this issue relates/conflicts with #53 and #60 . We need to resolve it before attempting to do those two, which would just be wasted effort in that case.

[abma]

If anyone can provide a solution that would solve multi-engine support, I would agree to do it as LuaMenu state.

not sure how ugly this is... the lobby instance of spring could proxy the lobby connection to the second instance, so the connection stays / info could be shown in both instances.

i.e. the lobby instance of spring opens a defined (server) tcp port and the second instance connects to it.

[gajop]

That's not possible with the LuaMenu state proposal which assumes only one Spring instance for both lobby (LuaMenu that runs in the bkg) and game

[ashdnazg]

If anyone can provide a solution that would solve multi-engine support

If you want to play a game using a different engine it obviously won't be able to do so in the same instance.

tl;dr: Chobby doesn't have to do everything seamlessly. Make it do the most frequent scenario (playing a game on the same engine) exceptionally well (same window, no multiple instances) and handle the rest in a passable manner.

I think the solution is to mix&match these options:

1. If you want to play with old engines, use a different lobby. I don't see why there should be infinite backward compatibility, and making Chobby a jack of all trades has the risk of it becoming a master of none.
2. If you want to use an engine which supports the current version of Chobby, Chobby starts this engine, exits and you can play the game.
3. If we're in the future, you're using Chobby on a new engine but trying to play a game on an engine that doesn't support the current version of Chobby, we can add a feature to spring which re-runs Chobby when it closes/crashes. That means you will play without in-game lobby connection in this specific scenario.

[GoogleFrog]

I agree with the above. I don't think it is important to support varying engine versions.

[gajop]

This has now been practically decided as a certain someone put all the work it required.