Open DormantCode opened 2 years ago
I also noticed turning physics ticks/s up to 240 reduces the rate of offset change but doesn't stop it
I'm not a PathFollow expert, so maybe I'm wrong, but it doesn't seem possible to me to use both move_and_slide
(who changes the position) at the same time as Path Follow which also changes the position.
Did you try on 3.X?
I wondered if I might just be asking a bit much of the physics going in with this, moving the player around & rendering work ideal relative to the PF which is why I didn't notice this til now, I feel like if I could figure out how to force the pathfollow to update fully (moving player & collision children gxforms with it) and run the move_and_slide collision test immediately after it should be functionally the same as doing it static, but not sure how I'd go about that. Calling move deferred also doesn't help. I also tried just checking test_move and it matches the move_and_slide issue (which I expected but worth a look)
While writing this also thought to try calling move_and_slide on the player from the pathfollow's _physics_process after updating offset (ofc remembered to disable it from player while reparented) which didn't help
Rebuilt the minimal on 3.5.beta.custom_build [685d4b473] and [2d03d06ad], both show the same issue
https://gitlab.com/DormantCode/path_follow_lag_minimal_3x.git path_follow_lag_minimal_3x.zip
Rebuilt the minimal on 3.5.beta ... both show the same issue
This seems to confirm what I said.
The official way to use a CharacterBody
on a moving platform is to use an AnimationPlayer
or a Tween
(configured to be in the physics frame) to move an AnimatableBody
. You can for example, tween between Path Point instead of using a PF.
Note: I tried to the the same with a Path Follow
(use an Animatable
inside it with a CharacterBody
outside) but it didn't work. I don't know if the implementation can allow this, maybe @groud can say if it can be.
@Calinou As far as I understand, there is no bug here.
I forgot to update on this, AnimationPlayer & Tween also didn't help, with PF or custom following (at the time, haven't tried it in a while,) but I found a way around this which is to use _physics_process on only the parent platform, and _process on the player whenever on board
Godot version
4.0.alpha,custom_build [3b57c2ce6]
System information
Linux 5.17.2-arch3-1 x86_64
Issue description
I have A CharacterBody3D that reparents to a long-distance moving platform, I wanted to be able to use local collision siblings for limiting movement
The issue is that when the PathFollow3D is moving, all physics bodies lag behind where their position should be, with offset increasing linearly with speed. The "visible collision shapes" as well as any mesh instances update as you'd expect but the actual collision physics don't
I tried with StaticBody3D, RigidDynamicBody3D, CharacterBody3D & Area3D all showed the issue. Tried changing process priority of the problem bodies to -1, also no joy. Offset is being updated on _physics_process, also tried doing it on call_deferred, same issue
I don't think it's the characterbody penetrating through the collision on a tick either because I imagine that would boot you to the other side once the offset gets wider than the actual collision shape. It's not "spongey" on my full implementation and you can still move consistently around the shape (eg a sphere,) it's just behind / ahead of where it should be
If anyone can confirm it's a bug or offer a workaround / way to manually sync physics state I'll greatly appreciate it :)
Steps to reproduce
Have a character & physics body collision sibling on a moving pathfollow3d, try moving the character into the physics body while the follower is moving
Minimal reproduction project
https://gitlab.com/DormantCode/path_follow_lag_minimal path_follow_lag_minimal.zip