netfox icon indicating copy to clipboard operation
netfox copied to clipboard

True Rollback

Open TheYellowArchitect opened this issue 5 months ago • 0 comments

Rollback currently works per entity. RollbackSynchronizer works by NodePath pretty much. If a rollbacked node unparents itself and adds a different parent to itself, the rollback to the tick it was still at the first parent fails, because it isn't moved there. Rollback synchronizes properties. So even if a functionality/API was made to load the state to the past, such nodes wouldn't rollback...

My specific use-case is an item system, where players pickup an item, and can activate it (so, all prediction) Let's assume that an item spawns a projectile. Picking up the item, is desirable to be instant (locally ofc via prediction) and next tick activating it, hence spawning the projectile.

Currently, how can the server even rollback/validate/confirm the item activation, if its on a different parent? So ideally, I would make 2 classes as "wrappers" for misc systems, to have true rollback:

ProjectileHistorian and ItemHistorian. Let's focus on ItemHistorian for this use-case. It keeps track of all items, in a Dictionary<ID, Node3D>. This ID is for our case the 12-string ID (in my project its a unique integer generated by the player ID) And it tracks its parent change at certain ticks, so rollback moves the item appropriately to whichever owner held it.

In a similar fashion, ProjectileHistorian can be implemented. So even if a projectile is destroyed and requested for rollback, you can just spawn a duplicate since you know its PackedScene.

In my project, I already have gloot working with netfox (dropped items becoming world items), but items are currently unrelated to rollback, so it muddies the entire project because only entities work via rollback, everything else doesn't (projectiles/items) so I cannot rollback to get the items.

I want to implement this system, but seeing that projectiles don't work via rollback

"Upon firing, sending a request to the server and waiting for the response with the projectile would introduce a delay. Doing a full-on state synchronization with MultiplayerSynchronizer or RollbackSynchronizer can be unfeasible with too many projectiles, and unnecessary, since most of the time, projectiles act and move the same way regardless of their surroundings."

and that netfox seems to be bugged (never more than 1 rollback per frame), and also seeing netfox is on maintenance, I lack the confidence to undertake such a big PR, especially when tiny PRs are still unreviewed.

Edit: Can I synchronize NodePaths? If yes, can I add dynamic properties (items) and not have problems? How would one use synchronized NodePaths to automatically add child on the parent nodepath property? I think that adding a RollbackSynchronizer to the item itself, with the properties being what the current parent is, would save me from making an ItemHistorian just for tracking item parents and moving items to parents at rollbacks.

TheYellowArchitect avatar Sep 24 '24 06:09 TheYellowArchitect