#Prediction tearing issue

1 messages · Page 1 of 1 (latest)

fathom minnow
#

I have owner predicted character.
Using it's IInputComponentData I predictively spawn other owner predicted ghost (which gets set same owner as said character).
This other predicted ghost is using lookup to modify LocalTransform of same character.

When this is interpolated to other client - it's all looking smooth.
But when this is predicted by client - first frames of LocalTransform modification are really teary. LocalToWorld goes forward and back multiple times for a first couple of ticks and then goes back to normal.

Any idea what is cause of this and how to avoid it?

#

To spawn ghost I use BeginSimulationEntityCommandBufferSystem

fathom minnow
#

This also only happen with ping simulation.
Disabled ping simulation makes it smooth as interpolated

fathom minnow
#

Modification of local transform looks like this:
ref var lt = ref localTransformLookup.GetRefRW(data.character);
lt.Position += data.movement * deltaTime;

#

system is updated in PredictedSimulationSystemGroup

lusty imp
#

Okay, but why are you making a new entity that additionally modifies the position of the character?

fathom minnow
#

Specifically, this is to avoid storing literally everything that can potentially be applied to character on character

#

while dash seems like a core character thing, things like knockbacks aren't

#

that's why I tried to decouple it to separate ghost, but yeah...

#

miserably failed

#

in order to support this fully

lusty imp
#

This is what I've done: Sample input on client to determine if dash button is pressed. On both server and client, apply scalar dash speed onto movement vector. Then final movement vector is applied to the character

fathom minnow
#

I will need to modify last known snapshot at predicted spawn time

#

and add predicted entity spawn to it

#

so that it gets rolled back between frames

#

otherwise it just kills itself before snapshot with it even reaches client

lusty imp
#

I would imagine things like knockback are interpolated spawn.

fathom minnow
#

they are

#

once again - this seems like a dead approach

lusty imp
#

Then why are you doing it in predicted?

fathom minnow
#

not suitable for prediction

fathom minnow
#

but instead create it as separate prefab and add to character

lusty imp
#

Characters are going to generally be giant entities regardless.

fathom minnow
#

true

#

but still

#

I just tried to make it work

#

it didn't

#

so...

#

yeah

lusty imp
#

I think instead of applying the movement onto the character's transform directly, modify the velocity vector that is fed into Rival physics update. For me, everything works if only rival is touching the ultimate character position.
Player control and external forces like knockback from explosions all feed into the movement vector in the predicted loop which is then used by rival to determine position.

fathom minnow
#

so it gets finished in one prediction loop

#

never rolled back to initial state

#

and it's practically cancelled after 1 frame

#

because everything else is rolled back

#

technically it can be avoided with usage of NetworkTick

#

instead

lusty imp
#

Is your component containing the dash trigger in a command buffer?

fathom minnow
#

but if I do this, I lose the ability to affect time

fathom minnow
lusty imp
#

Yea, a network tick is going to be how you do this

#

command buffers only work on the command target, not any other entity

fathom minnow
#

or vice versa

#

intially dash speed was one, but then mid execution it slowed down

lusty imp
#

The character has a network tick field in a component that says "start time of tick". The movement code then checks if the current simulated server tick is within probable range for that tick for dashing and applys a dashing effect.

#

This is independant of any other effect. The player can move over a region that slows down movement and it'll get properly applied, dashing or not.

fathom minnow
lusty imp
#

Then a job that handles changing the dash duration will move the dash tick forward.

#

In my implementation, that will also increase the cooldown which probably isn't intended so a separate "dash cooldown start" and "dash duration start" will be needed.

#

An effect that reduces the dash duration will .Add() to the dash duration start. And a job that applies the dashing movement speed will appropriately check if the dashing effect is currently valid

#

That or you can decrease the dash duration but I intend for character data (e.g. movement speed) to be constant.

fathom minnow
#

🤔

#

so if duration is reduced, start tick is added

lusty imp
#

Moved back I mean. Sorry

fathom minnow
#

if increased, end tick

lusty imp
#

Moving the tick backwards uses up the duration. Moving it forward extends the duration.

fathom minnow
#

yeah, I'm just thinking whether it will keep the total movement same precisely

#

basically what I do to test everything is correct:

  1. I define dash velocity to the amount it's exactly 5 units length for 0.25s of duration
  2. check whether end position is 5 units from starting
lusty imp
#

Ultimately, the server will determine the total distance. If the client predicts that the character moves into a region where there's more dashing possible but the server says it didn't, you'll have teleporation.

fathom minnow
lusty imp
#

My dash is determined by duration, not distance

#

You can get the distance traveled by multiplying duration by dash velocity though.

fathom minnow
#

This is not specifically for dash, but more for NetworkTick calculations in general, where time can matter

lusty imp
#

Yea, my authoring data is in terms of network tick. Which is constant at 60hz.

#

You assume that each tick is 1/60 sec (or whatever frequency the server is running at). And the total distance traveled will be constant as well.

fathom minnow
#

in case of catch up

lusty imp
#

No. It shouldn't. Server ticks at least.

fathom minnow
#

it shouldc

#

if server will stutter for a sec

#

and will increase delta time to run multiple ticks in update

#

your logic will corrupt

#

for me it was enough to disable burst to witness how logic gets broken at 30 fps in editor

#

kek

lusty imp
#

Hrm, how do I test this

#

Well, delta time is implemented inside rival. All these values are constants.

fathom minnow