Predicted Physics + Predicted Player Spawned Objects Not Spawning In the Right Location

[adammpolak]

ISSUE: For some reason the client-spawned bullets are spawned in the “wrong place” and then their position corrects

• I have a predicted Player object and am running predicted physics
• The client can use wasd to generate ICommandData
• The Player object can spawn bullets by hitting space bar (will be ICommandData shoot = 1)
• The bullet is spawned at an offset location at the end of the player’s “gun”
• InputSystem takes in wasd commands and generates ICommandData
• InputResponseMovementSystem reads commands and adjusts PhysicsVelocity.Linear and runs before BuildPhysicsWorld
• InputResponseSpawnSystem
• reads commands and creates the bullet
• and gives it a PhysicsVelocity of whatever the player is + the forwards direction
• runs after ExportPhysicsWorld
• records commands onto BeginSimulationEntityCommandBufferSystem

Here are the systems for the client:

Here are the systems in server

For some reason the client spawns the bullets “off” then they are “fixed” to where they should be. I assume this has to do with the server “correcting” what the client thought? It is exacerbated by a high velocity.

See video of the bullets being “wrong” then being updated:

DOTS NetCode Predicted Physics + Predicted Client Spawning Not Working

If the client is predicting physics, and it is “correct” because it is not interacting with anything, why would the bullet not spawn in the correct location?
When the player is not moving or moving very slowly this issue is not noticeable, it is when my player is moving quickly laterally. It is like the client is spawning the bullet where the player was? Or is it something else?

[timjohansson]

The system setup looks ok to me, so I would guess it is something in the spawning system.
When doing predicted spawning you have to take care to not run the spawn logic for rollbacks, and that is the most common issue causing problems like you describe. In our asteroids sample we use a cooldown which is not rolled back to make sure we do not spawn for the same tick multiple times - but it is an area we are working on improving and making easier

[adammpolak]

@timjohansson

The system setup looks ok to me, so I would guess it is something in the spawning system.
When doing predicted spawning you have to take care to not run the spawn logic for rollbacks, and that is the most common issue causing problems like you describe. In our asteroids sample we use a cooldown which is not rolled back to make sure we do not spawn for the same tick multiple times - but it is an area we are working on improving and making easier

Shoot I ripped off your asteroids approach, I will double check to make sure I did not mis-implement and report back.

[adammpolak]

For some reason now the predicted physics system are in the fixed step simulation group

I have not changed the code to create the physics singleton.

        Entity physicsSingleton = EntityManager.CreateEntity();
        EntityManager.AddComponentData(physicsSingleton, new PredictedPhysicsConfig {});

Why did this occur?

[CMarastoni]

IIRC the PredictedPhysicsSystemGroup move the physics systems once in the first update whence the PredictedPhysicsConfig entity is present.

            if (!m_SystemsMoved)
            {
                MovePhysicsSystems();

                m_SystemsMoved = true;

                if (physicsConfig.DisableWhenNoConnections)
                {
                    var query = GetEntityQuery(typeof(NetworkStreamConnection));
                    RequireForUpdate(query);
                }
            }

Looks like to me the system is not running.
And because it is inside the GhostPredictionSystemGroup that only happen if there are ghost to predict.
You can check that the condition are actually met and the method is that move the system is called?

[adammpolak]

@CMarastoni

IIRC the PredictedPhysicsSystemGroup move the physics systems once in the first update whence the PredictedPhysicsConfig entity is present.

            if (!m_SystemsMoved)
            {
                MovePhysicsSystems();

                m_SystemsMoved = true;

                if (physicsConfig.DisableWhenNoConnections)
                {
                    var query = GetEntityQuery(typeof(NetworkStreamConnection));
                    RequireForUpdate(query);
                }
            }

Looks like to me the system is not running.
And because it is inside the GhostPredictionSystemGroup that only happen if there are ghost to predict.
You can check that the condition are actually met and the method is that move the system is called?

• I was on my mac and it was working as expected, systems were moved to PredictedPhysicsSystemGroup

• I pushed my updates to github and then pulled and loaded the project on Windows

• Now on windows (no changes) the systems are no longer in the GhostPredictionSystemGroup

[CMarastoni]

@adammpolak

• I was on my mac and it was working as expected, systems were moved to PredictedPhysicsSystemGroup

• I pushed my updates to github and then pulled and loaded the project on Windows

• Now on windows (no changes) the systems are no longer in the GhostPredictionSystemGroup

This is indeed quite curious. We don’t have any platform specific code honestly.
Where are you calling the

Entity physicsSingleton = EntityManager.CreateEntity();
EntityManager.AddComponentData(physicsSingleton, new PredictedPhysicsConfig {});

Can you also verify that the PredictedPhysicsConfig singleton exist in both server and client worlds?

[adammpolak]

@CMarastoni

This is indeed quite curious. We don’t have any platform specific code honestly.
Where are you calling the

Can you also verify that the PredictedPhysicsConfig singleton exist in both server and client worlds?

Yes, it existed in both server and client worlds.

Changing to be put in FixedStepSimulationGroup instead of PredictedPhysicsSystem group fixed the issue.

Maybe there was some race condition in the windows that didn’t exist in mac? Regardless, it is fixed and working again now thank you.

[adammpolak]

@timjohansson

The system setup looks ok to me, so I would guess it is something in the spawning system.
When doing predicted spawning you have to take care to not run the spawn logic for rollbacks, and that is the most common issue causing problems like you describe. In our asteroids sample we use a cooldown which is not rolled back to make sure we do not spawn for the same tick multiple times - but it is an area we are working on improving and making easier

I realize I did not understand this as much as I did.

How can I prevent spawn logic for a rollback? I am assuming that is why the bullets are appearing where I was a few frames ago?

[EugenyN1]

The same problem seems to exist in the Asteroids example. The position of the player when receiving input (InputSystem) and when processing input and spawning bullets (SteeringSystem) do not match. (on client)

In the example (SteeringSystem.cs), I moved the line position.Value.xy += Velocity.Value * deltaTime; below input handling if (inputData.shoot != 0 && canShoot) { ... } for correct comparison.

attached Asteriods example and one more my example screenshots.