Unexplained rollbacks with PreSpawnedObjects

[cBournhonesque]

Okay, going back to this rollback issue, I think I've narrowed it down enough to share: I might be running into an edge case bug with PreSpawnedPlayerObjects, probably.

To summarize: my game is using projectiles that are really fast moving. There projectiles are pre-spawned by the client that shoots. Whenever the projectiles are stopped, they get deleted that frame. There's three types of behaviors I'm seeing with this, two of which are failure points:

• If the projectiles get destroyed really early (in the video example, when I shoot the wall I'm in front of) no rollbacks are triggered but an error is printed

  ERROR lightyear::shared::replication::receive: Received despawn for an entity that does not exist

This error gets printed by both clients.

• If the projectiles get destroyed late enough, there's no errors and no rollbacks (this is the case where everything works correctly!)
• There's a middle ground between the first and second case where no errors are printed but a rollback is triggered in the client that fired the shot (this should not happen) on some of the projectile components (which component this is triggered for changes per game boot) due to a missing history_value in the case where the confirmed entity exists

See https://discord.com/channels/691052431525675048/1189344685546811564/1282437035604312187

[cBournhonesque]

• For ERROR lightyear::shared::replication::receive: Received despawn for an entity that does not exist. Not 100% sure what is happening.
  • I think the entity is spawned/destroyed within a replication_interval, so the server just spawns a Despawn message for the entity but it didn't send a Spawn message. (Spawn messages are sent every replication_interval so if the entity was despawned before we run the system we wouldn't send any Spawn, but Despawn messages are buffered via observer whenever the ReplicationTarget component is removed, so we would always send a despawn no matter what, even if no Spawned was sent.
  • it's not a huge problem, but we'll have to think eventually about how to handle it. Maybe send a message with both spawn and despawn in the same message? Or just don't send the despawn at all?