spring / uberserver

uberserver, a matchmaking/chat lobby server for the spring rts project
https://springrts.com/wiki/Uberserver
Other
33 stars 38 forks source link

Please make FORCEJOINBATTLE server side implementation #121

Closed Licho1 closed 9 years ago

Licho1 commented 9 years ago

MatchMaking for ZK is released now. Problem is some clients dont understand/perform the command correctly (dont leave current battle or just ignore it)

This is extremely harmful to the system because players (which use ZKL) get moved to empty rooms, spring starts for them but they have no enemy -> rage..

Please revert to original implementation which faked LEAVEBATTLE and battlejoined .. that worked everywhere without issues..

Licho1 commented 9 years ago

Had to ban all non-ZKL lobbies until this is resolved.

shaun0x00 commented 9 years ago

ZK code is responsible for starting spring. It could wait until player has joined, but it does not. ZK code is responsible for attempting to move players. It knows which lobby client the players are using, but it is not using that information that allows to infer whether lobby client will comply or not.

Protocol is missing some commands for the proposed scenario. Implementing FORCEJOINBATTLE without consulting the community may make people angry once they start getting pulled into battle rooms because of bugs in ZK infra. This simple FORCEJOINBATTLE scheme can not work when there are multiple competing matchmakers.

abma commented 9 years ago

there was a discussion about FORCEJOINBATTLE in community:

http://springrts.com/phpbb/viewtopic.php?f=80&t=27730

idk details, also i didn't implement the command as it currently is.

question is: what to do with clients not supporting the 'm' compatibility flag, i guess kick them from the current battle.

zk should listen to the FORCEJOINBATTLEFAILED and only kick these players as their lobbies don't support the "m" compatibility flag / players opted out from matchmaking.

i don't see why there is a server change needed. fix zk implementation and use FORCEJOINBATTLEFAILED probably.

Licho1 commented 9 years ago

Some lobbies do support the flag but don't expect to be in room already and hence fail .. Also at the time command is executed its too long.. thats when battle is meant to start....

abma commented 9 years ago

sorry, i don't understand.

but don't expect to be in room already and hence fail ..

what does that mean? "fail" is to general. what exactly fails?

Also at the time command is executed its too long.. thats when battle is meant to start....

what does take to long?

Licho1 commented 9 years ago

Ok some clients implemented forcejoin but assume they are not already present in a battle room. If the command is sent and the client is in battle room, it wont change a room...

Also i didn't mean too long but too late.. Command is executed when countdown ends and its meant to start spring game .. If it discovers only then that some clients don't comply, it's too late...

db81 commented 9 years ago

Lobby devs are responsible for fixing bugs like assuming you're not in a room already. I don't think that's a good idea to work around that in uberserver.

Licho1 commented 9 years ago

Yeah but because there are many lobby clients and either one not supporting it will break matchmaking for all others, we have to kick "all unknown" lobbies... Which is hardly better than simply implementing command server side. It worked, it had no side effects, it was fully backwards compatbile.. why was it removed?

abma commented 9 years ago

imo: find/fix broken lobby clients.

whats with FORCEJOINBATTLEFAILED?

i don't see a lobby server bug, also it should probably give feedback if it failed to send to the client.