[testing] 3.6.0.2: Users may join unavailable slots after 'reload last game'

[tomreyn]

When you host a game with a map for 8 players but have no users connected, yet, then click on the Reload last game button and this gives you a game with less slots, such as a 4 player map, then when clients connect to your game they may end up on a slot which is not available on this map, i.e. somewhere on slots 4 to 7.

[tomreyn]

This affects 3.6.0.3, too.

[softcoder]

What exactly do you suggest should be the behaviour?

[tomreyn]

When you reload a game, then only as many network slots as there are start positions on the selected map should be available.

Another option would be to always make 8 network slots available as it is now when you "reload last game" (independent of the map you have selected). In this case, however, players should first get connected to slots which map to an existing start position. All players which are not in a slot which translates into a start position on the map should still be listed, possibly greyed out or even in red. Currently these players are not listed, there is only non-obvious indication that a user has connected to one of these extra slots, and these users are unable to switch to other slots then, forcing them to reconnect and try their luck to end up in one of the usable slots then.

[softcoder]

ok try out svn. If a user is in a slot that is not longer valid, then no-one can take that slot there-after, so they should easily be able to join a new valid slot.

[tomreyn]

This happened again and this time I actually took a screenshot, since I guess it says more than a 100 words - and because I assume we may have been discussing different things here.

Code: [Select]

[img]http://megaglest.pzt.me/dx/subdomain/megaglest/img/5/2/0/5202.jpg[/img]
This situation seems to occur after "Reload last game" was used (I'm not sure whether it only occurs then), and when the server admin switches things around on the server, such as replacing a network slot by a CPU player, while a new client is in the process of joining.

The text on the image is not exactly right: This forth slot used to be open earlier (due to Reload last game loading an 8 player map), but it was probably closed before the new player started joining.

This is not an off-by-one, we're had situations where a 4 player map was set, and there were free network slots (0 and 1 were taken, 2 and 3 were free, all others closed due to a 4 player map) and a new player joined on slot 6 and could not move away from there. Also reconnecting does often not help in the first attempt - you may end up in the same closed slot again, and the server admin may even miss you are there because only this one button is displayed - not even a player name.

[Ishmaru]

Hust a random observation but 3 peninsula is an Annex map. Not saying its wrong to put it on mg just wondering if its a cause or symptom of problem stated?

[tomreyn]

I think that's just a coincidence, most likely it's not related. I accidentially downloaded this map onto my MegaGlest user maps directory when Annex was stiill using the same masterserver as MegaGlest.

[softcoder]

The change is svn closes an invalid network slot AFTER it has no connection any longer. That change should fix this, I suggest you try it out.

[tomreyn]

This issue still persists. Here's how to reproduce it on r3505:

• Start a game server, announcing to masterserver with eight slots, of which at least one of slots 4 to 7 needs to be a network slot.

• Wait >= 5 seconds.

• Switch to a 4 player map with these slots:

Code: [Select]

0. Human
1. Network
2. Network
3. Closed

• Wait >= 5 seconds.

• Close both network slots and, at the same time, have a new player connect to the server. The new player will end up in one of the higher slots which are not actually available, and will only show up with "Not ready" as seen on the screenshot above, i.e. there is no full player info available (no player name).

[softcoder]

Ok try again, this scenario was different from the original bug reported.

Thanks