Bug: Infinite dodge time after multiple rewinds

[maciekwiso]

In a certain situation dodge timeout is not working properly and you get an infinite doge time out. It happened when I jumped off the wall, then used second jump. Then I used rewind to go back to before I used second jump, played it through. Used rewind again to go back to before I used second jump, and then dodge time out doesn't happen, you can hold on to your second jump forever.

[NitrOP7674]

Is this something you can reproduce easily?

Can you share a video of it happening?

[maciekwiso]

When the car is green it means I have dodge available. After second rewind dodge stays available forever. https://youtu.be/p7QbFixLby8

[NitrOP7674]

Ah thanks, I understand now. I guess there's bug with keeping track of the dodge timer when the jump isn't happening live the first time. I would assume this has always been like this, but have you noticed this as a regression (i.e. wasn't there in an older version)?

[NitrOP7674]

Yes, when I read the state I use the "jump inactive time" to determine how long it has been since the player jumped:

https://github.com/NitrOP7674/FreeplayCheckpoint/blob/a858fec4dc27f8ca6139189b6efd4921c413fc93/state.cpp#L108

There is no Setter for this field, so after rewinding, this method no longer works while recording. Because there is no Setter, I have to manually make the dodge timer expire via:

https://github.com/NitrOP7674/FreeplayCheckpoint/blob/a858fec4dc27f8ca6139189b6efd4921c413fc93/CheckpointPlugin.cpp#L611

and

https://github.com/NitrOP7674/FreeplayCheckpoint/blob/a858fec4dc27f8ca6139189b6efd4921c413fc93/CheckpointPlugin.cpp#L699-L710

I could possibly pass the dodgeExpiration back into where I save the state here:

https://github.com/NitrOP7674/FreeplayCheckpoint/blob/a858fec4dc27f8ca6139189b6efd4921c413fc93/CheckpointPlugin.cpp#L720

In order to capture the time remaining correctly.

(Also I doubt I get the timer perfectly accurate, as I don't take into consideration how long the user pressed the jump button for, etc. That's not really a high priority for me; I think what I'm doing now is "good enough" for 99.9% of users.)

[NitrOP7674]

Should be fixed in https://github.com/NitrOP7674/FreeplayCheckpoint/releases/tag/v1.7.0-pre6; would appreciate if you can test it out. I'm hoping to push this release to bakkesplugins.com soon.

[maciekwiso]

Works fine now

[maciekwiso]

Actually, deleting checkpoints stopped working for me. I can see checkpoint deleted text (well, actually part of the text goes beyond the screen) but the checkpoint is still there.

[NitrOP7674]

Actually, deleting checkpoints stopped working for me.

I'm not able to reproduce this. Note that the cpt_do_checkpoint button, if used right after deleting a checkpoint and then unfreezing, will load up that checkpoint (as a "quick checkpoint") even though it is deleted (you can verify by looking for the number indicator at the top right). Can you send another video and possibly share your saved checkpoints file?

actually part of the text goes beyond the screen

Oof, I have not optimized for different resolutions than my own, sorry. Maybe you can't see the number indicator mentioned above either?

[maciekwiso]

My bad. It works fine. It's a bit confusing but it's working fine. I can see the numbers fine, but when deleting I only see "Press again to de", the rest it cut off. I use standard 1920:1080 resolution.

[maciekwiso]

I had an idea to create a bakkesmod console command to vote to forfeit and then I could create a shortcut to be able to forfeit quicker. Someone on reddit suggested this: I think you can implement it easily. See forfeit related functions in TeamWrapper and TeamGameEventWrapper.

Would you be able to do that?