You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be nice if people could see that a game will be unrated because of certain lobby settings during the lobby phase. Obviously we can’t predict if there will be desyncs or disconnects, but if the game is modded or a bad map is selected we could certainly show it as unrated.
We should add a field validity to the game_info message that will contain certain validity strings (we would probably have to figure out some better names since the naming of the enum is currently pretty inconsistent).
Adding this would require some reworking of when the validity is calculated as it’s currently only computed once when the game is launched. We would probably want to break a certain subset of those validity checks out into checks that are recomputed whenever the game_info message is requested. Those pre-launch validity checks should not make writes to the database since they aren’t final yet, so some of the code will have to be refactored.
Examples of validity states that should always be checked:
bad map
bad mod
wrong victory condition
has AI
These validity states could only be checked when the game is full as they may fail and pass again as players join:
uneven teams
single player
The text was updated successfully, but these errors were encountered:
It would be nice if people could see that a game will be unrated because of certain lobby settings during the lobby phase. Obviously we can’t predict if there will be desyncs or disconnects, but if the game is modded or a bad map is selected we could certainly show it as unrated.
We should add a field
validity
to thegame_info
message that will contain certain validity strings (we would probably have to figure out some better names since the naming of the enum is currently pretty inconsistent).Adding this would require some reworking of when the validity is calculated as it’s currently only computed once when the game is launched. We would probably want to break a certain subset of those validity checks out into checks that are recomputed whenever the game_info message is requested. Those pre-launch validity checks should not make writes to the database since they aren’t final yet, so some of the code will have to be refactored.
Examples of validity states that should always be checked:
These validity states could only be checked when the game is full as they may fail and pass again as players join:
The text was updated successfully, but these errors were encountered: