Skip to content

fix: Queue RewindableAction mutations ahead of rollback loop#531

Merged
elementbound merged 4 commits intofoxssake:mainfrom
RevoluPowered:gordon/hotfix-mutation-processing
Nov 19, 2025
Merged

fix: Queue RewindableAction mutations ahead of rollback loop#531
elementbound merged 4 commits intofoxssake:mainfrom
RevoluPowered:gordon/hotfix-mutation-processing

Conversation

@RevoluPowered
Copy link
Copy Markdown
Contributor

@RevoluPowered RevoluPowered commented Nov 15, 2025

The problem:

  • rewindable action was spamming about mutations that happened early and the tick processing was trying to process a mutation for tick 15 continuously after the netfox instance began.
  • this meant that when sending inputs with rewindable actions the tick was never aligned even on the host to run the mutation for the rewindable action.
  • we had a lot of spam from the debugger that rewindable action tick was incorrect.

The solution in this PR (it may not be correct or perfect) but it does fix the samples and my own project and most importantly forest brawler now works properly.

More details:

  • On the server side with 4.5.1 stable the netfox examples have a bug where they reserve like tick 15 for example but the server is on tick 20. The issue is that the mutable action looks far too far back in history and spams that error. But I'm not sure if my behaviour is correct of course for the code in question. Tick 19 to tick 20 being processed and the mutable action rewind tries to mutate tick 15 This is on server only, no clients connected. When clients connect this happens more frequently and it seems to be keeping very very old mutable actions. Even just in on a host, without clients connected.

I added some debug logic to the error that was spamming this might explain what is going on more for those who are familiar with the code:
Screenshot 2025-11-15 at 22 50 22

[WRN][@271][#1][A@270|270>271][netfox::NetworkRollback] Trying to mutate object player #1:<CharacterBody3D#152622335660> in the past, for tick 15! p_tick(15) < tick(270)

The problem:
- rewindable action was spamming about mutations that happened early and the tick processing was trying to process a mutation for tick 15 continuously after the netfox instance began.
- this meant that when sending inputs with rewindable actions the tick was never aligned even on the host to run the mutation for the rewindable action.
- we had a lot of spam from the debugger that rewindable action tick was incorrect.

The solution in this PR (it may not be correct or perfect)
but it does fix the samples and my own project and most importantly forest brawler now works properly.
@RevoluPowered
Copy link
Copy Markdown
Contributor Author

I recommend this is tested with all samples first before merge by someone independent of me.

@elementbound
Copy link
Copy Markdown
Contributor

elementbound commented Nov 18, 2025

Did some investigations, this seems to be two issues.


First, the RewindableAction queued its mutations in NetworkRollback.after_loop(). I think the original idea was to queue the changes for the next rollback loop. However, this signal was still running inside the rollback loop. Trying to queue mutations for the past in the rollback loop prints a warning, since the tick won't be simulated in that loop, i.e. mutate() does nothing.

Moved this part into NetworkRollback.before_loop(), to queue all the mutations in advance, before running the loop.


In addition, RewindableAction also logged warnings about receiving ticks into the future. From my experiments, this happens only under extremely low latency, most probably in cases where the server time runs ahead of the client. Gave the warning a few ticks of leeway.

@elementbound elementbound changed the title Fix all samples with broken rewindable action fix: Queue RewindableAction mutations ahead of rollback loop Nov 18, 2025
@elementbound elementbound merged commit da82e7a into foxssake:main Nov 19, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants