Are the entity indices consistent across different clients?

[idle burrow]

I'm trying to develop a lockstep game using DOTS and I've encountered an issue. In a deterministic scenario, are the entity indices generated by different clients consistent? Is it guaranteed that the indices of later-generated entities will be greater than those generated earlier?

[twilit dirge]

I am under the impression that, as long as you control scene loading properly (i.e. the order in which they're loaded into your world), yes

they won't always be greater though, since destroyed entity indices can be re-used

we have lockstep working, though there is one issue in particular that I identified:

Frame step controlling is difficult because, to my knowledge, you can not precisely control the framerate of the main thread, nor can you step independently from the main thread.

Ideally the frame steps happen around the exact time the network tells us we should step, but because you can not control the main thread timing, you can miss a frame which introduces extra latency.

but that issue is not related to DOTS though

as for other determinism issues, I remember @hollow pelican found an issue in the Unity Transforms hierarchy processing which is not deterministic in certain cases of nested hierarchies

[idle burrow]

Thanks,

You can control the frame step by adjusting the interval of FixedUpdate.

Unity Transforms hierarchy processing is not deterministic, so just add components to a list during editing. Then, execute them in the order specified by the list.

[fading oracle]

I'm not sure I'd rely on the index I think it could be quite fragile if you have client only effects etc

[idle burrow]

In general, the index is not typically used. However, in rare cases such as when two entities have exactly the same position, the index can be used for handling.

[twilit dirge]

no, what i mean is this, with a simple implementation, green is where you check if the frame has to step, and it's not yet the case so you start to do rendering
then the actual step should happen at blue, but you cant because you're in the middle of main thread & engine stuff
then red is the latency introduced because of this effect, the time before you actually step the blue frame

not saying it's not solvable but if latency is a thing for you, you should be aware of it

[twilit dirge]

not sure you get what i mean, it's related to the way it processes parent hierarchies that share chunks

see this
https://github.com/Dreaming381/Latios-Framework-Documentation/blob/main/Optimization Adventures/Part 9 - Transform Hierarchy 1.md#a-race-condition-in-the-wild

[twilit dirge]

we have a separate world for the simulation for this reason (also makes things a little easier to debug, less unexpected surprises ^^)

[lusty current]

Yes, I am also going this route of having separate simulation/presentation world for deteministic lockstep.
It also allows for simulation ticks processing to be spread over multiple presentation frames.

[acoustic slate]

if the client misses a single entity creation (loses sync or some other reason) they wont be able to recover the game state unless you can (re-)create everything missing in order to keep the entity indices in sync

[fading oracle]

If it's true lock step you shouldn't miss anything