Closed Licho1 closed 9 years ago
Had to ban all non-ZKL lobbies until this is resolved.
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.
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.
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....
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?
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...
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.
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?
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.
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..