Changing physics on an entity without doing a physics update can cause issues (like revive sliding)

personally I always wished we had a physicstweener because the current methods to change physics size on-the-run really suck since the target gets teleported to 0,0,0 each call

Edited February 27 by Well-met

6 hours ago, Well-met said:

personally I always wished we had a physicstweener because the current methods to change physics size on-the-run really suck since the target gets teleported to 0,0,0 each call

That.. probably has to do with the second thing I mentioned, where another physics component is created and the old one is replaced, instead of modifying the existing one. I guess it could make some sense, it's making a new one, therefore it's initializing which by default could mean 0, 0, 0 for the physics component specifically, if it doesn't check for Transform coordinates and grab those on the engine.

It's not always done like this though, some functions use the ChangeTo[something]Physics functions rather than the Make[something]Physics. If the need is to get a clean physics component state, there should be something that does so properly, rather than replacing and garbage collecting the old one.

I thought I did make sure to check, but to be extra sure, I'll double check if doing things this way is what causes the weird sliding behavior mentioned in the report, and make another comment here.

 

That said, having more tools like a physicstweener as you said, would be nice.

Edited February 28 by hoxi

On 2/28/2026 at 12:09 AM, hoxi said:

I thought I did make sure to check, but to be extra sure, I'll double check if doing things this way is what causes the weird sliding behavior mentioned in the report, and make another comment here.

Even if not making a new physics component and garbage collecting the old one, the issue I reported here (like pushing a player in the process of reviving causing them to slide), still happens. So regardless it seems like, some sort of physics update is needed.

 

There's even cases like this where it's kinda acknowledged:

inst.Physics:SetMass(1)
inst.Physics:SetDamping(0) --might have been changed by quaker
inst.Physics:SetCollisionGroup(COLLISION.ITEMS)
inst.Physics:Teleport(inst.Transform:GetWorldPosition()) --force physics to wakeup

Or silently acknowledged, like in the same file that does the MakeCharacterPhysics call for the player being revived, but in this case for when turning into a ghost:

MakeGhostPhysics(inst, 1, .5)
inst.Physics:Teleport(x, y, z)

 

So ideally, the revive slide issue should be addressed, given that the transition into a ghost does it fine, and the other stuff should probably be addressed too.

I do feel like a function like Physics:ClearParameters() or Physics:Reset() or so could be useful, but regardless, there shouldn't be cases of making a new engine component and throwing out the old one, that feels like asking for trouble.

And I guess there needs to be notes for exceptions like the revive state and turning into ghost states having to force wake up physics because those states otherwise don't do anything related to physics until they're exited.

Edited March 3 by hoxi