Winner (sometimes) incorrectly set after forfeits #15
Comments
|
this is unrelated, but I've been messing around with Yeah. Just fun things. |
|
I know that I added the forfeit handling for the case of forfeiting during a replay and then quiting, since that would prevent you from getting the game end screen. At least it seems like an odd case to catch forfeiting while winning. It seems you're comfortable reading code, so if you're able to find a fix for both cases feel free to make a PR. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem:
If you're ahead in score in game, and you forfeit in a game state that doesn't immediately end the game, you are incorrectly declared the winner.
To reproduce:
a) You're able to forfeit
b) Scoring a goal or having a goal scored on you (when you're in the "Replay" state)
Result: "You won!" is printed instead of "You lost!"
I suspect it affects more than just 1s, it's just easiest to reproduce in 1s.
So, the related line is here which hooks
HandleForfeitChangedwhich leads to this
Deja-Vu/DejaVu.cpp
Line 754 in 57387c8
Which works. Then it heads to
GameOver();-> which leads toSetRecord();And here is the beginning of the related code.
My theory is that since
Function TAGame.GameEvent_Soccar_TA.OnMatchWinnerSet(and related *GameWinnerSet functions) doesn't get called until the end of the game or match (like when the match is transitioning into the end screen), the value for thewinningTeamdoesn't get updated before this runs... (and it must be updated after goals get scored since the value will be equal to your team value if you're ahead in score (or else it would've been some default value) no matter what team you're on). In my testing, if you forfeit and the game immediately ends, then (I guess) the winner is set beforeSetRecord()is called, and it reports a loss as expected.I would propose not caring about checking for forfeiting, if it's ultimately inconsequential, and the "GameOver" state is always, reliably reachable. Otherwise, I'd check for: while
Function TAGame.GameEvent_TA.OnCanVoteForfeitChangedis still active (since it's set once when you can forfeit, and set again when you can't --- during a match), andFunction TAGame.VoteActor_TA.EventStartedis called in that time (which, as far as I know means your team is forfeiting... since I think when you're able to forfeit, the only voting allowed to be done is forfeiting... unless I'm missing a corner case... I don't think there's anything else to vote on ... tangent: the only other things to vote on are while you're in the post-game screen, like rematch), untilFunction TAGame.VoteActor_TA.Passedwould mean that the vote passed, and you would have your status set to LOST regardless.addendum: Curiously, I went into 1s, went up 2-1, and while I could forfeit, I let the opponent score, and forfeited during the replay time... and I didn't see a corresponding match winning message.
my bakkesmod.log for when that happened:
it seems here's the related section of the dejavu.log
The text was updated successfully, but these errors were encountered: