godot
godot copied to clipboard
godotengine
PathFollow3D progress and progress_ratio properties not working after upgrading from 4.2.2 to 4.3
Tested versions
- Reproducible 4.3.stable
- Works in 4.2.2.stable
System information
Godot v4.2.2.stable - Debian GNU/Linux 12 (bookworm) 12 - X11 - GLES3 (Compatibility) - NVIDIA GeForce GTX 960 (nvidia) - AMD FX(tm)-6300 Six-Core Processor (6 Threads)
Issue description
PathFollow3D progress and progress_ratio properties are not working after upgrading from 4.2.2 to 4.3. Running my game on 4.2.2 again afterwards works as expected. In the inspector, I can manually adjust the properties and see the position move in the 3D view. The full project is shared on GitHub : https://github.com/Pixel-Gladiator/LaserBall3D Load it in 4.2.2 and the world resources populate as expected. Load it in 4.3 and the world resources populate in a single location. In both cases, world resources spawning off of a timer are added as expected. I've shared videos of what it used to look like and what it looks like now on YouTube https://www.youtube.com/channel/UCIIdIVhHBYRUmjfhPLQyY5Q
Steps to reproduce
Load it in 4.2.2 and the world resources populate as expected. Load it in 4.3 and the world resources populate in a single location. In both cases, world resources spawning off of a timer are created as expected.
Minimal reproduction project (MRP)
N/A
Please upload a minimal reproduction project, a full game project is not a minimal project, a minimal project makes things easier to test and confirm without having to dig through a lot of unnecessary information:
- A small Godot project which reproduces the issue, with no unnecessary files included. Be sure to not include the
.godotfolder in the archive (but keepproject.godot). - Having an MRP is very important for contributors to be able to reproduce the bug in the same way that you are experiencing it. When testing a potential fix for the issue, contributors will use the MRP to validate that the fix is working as intended.
- Drag and drop a ZIP archive to upload it (max 10 MB). Do not select another field until the project is done uploading.
- Note for C# users: If your issue is not C#-specific, please upload a minimal reproduction project written in GDScript. This will make it easier for contributors to reproduce the issue locally as not everyone has a .NET setup available.
That's a regression from #80233 (happens since 4.3.dev4), which made changing all relevant PathFollow3D properties result in deferred transform update, instead of updating the transform immediately (PathFollow3D::update_transform is always called with the default p_immediate = false).
cc @xiongyaohua
https://github.com/godotengine/godot/blob/a7598679cff6daffbec8f16314b853d87268fff5/scene/3d/path_3d.cpp#L463-L467 https://github.com/godotengine/godot/blob/a7598679cff6daffbec8f16314b853d87268fff5/scene/3d/path_3d.cpp#L415-L435 https://github.com/godotengine/godot/blob/a7598679cff6daffbec8f16314b853d87268fff5/scene/3d/path_3d.h#L127 https://github.com/godotengine/godot/blob/a7598679cff6daffbec8f16314b853d87268fff5/scene/3d/path_3d.cpp#L220-L228
Is there a workaround for now?
I also really need to know if there's a workaround for this. I need this feature and I can't use the 4.2 version as my engine due to needing the features of 4.3.
Actually, depending what you need, this workaround might not be too hard. The progress updates just fine, so feeding that into, say, curve.sample_baked_with_rotation(pathfollow.progress) will get you the whole Transform3D to play with.
What to do, then? Should that PR be reverted? Should the transform be updated immediately (likely yes)?
What to do, then? Should that PR be reverted? Should the transform be updated immediately (likely yes)?
Reverted no, it fixed some other issues. From https://github.com/godotengine/godot/pull/80233#issue-1835941578:
This PR fix the following minor issues on PathFollow3D.
- transform is not updated after setting new flags such as
use_model_front- transform is not updated when the parent Path3D changes
- correct_posture() behaves differently when assuming model front
- _update_transform() was in immediate mode, could leads to chained calls on scene instantiation.
Seems like the updates were made to be deferred because of the last bullet point. Aka the intent was to avoid many updates on scene instantiation, but deferring was made to happen always instead of only on instantiation... :upside_down_face:
So yes, always updating transform immediately should do as a simple hotfix. Somehow avoiding multiple updates on scene instantiation (according to the original intent) would be a nice bonus of course.
I trust your judgement. I believe this needs to be fixed ASAP, a lot of people I know personally rely on this logic.
yeah, make p_immediate=true as the default for update_transform() should fix the problem.
as a side note: force_update_transform() doesn't seem to work either. i don't really know if it's related or not.
I was going crazy today wondering why progress_ratio wasn't working and now I see it 🥇. Thanks for stopping my insanity from progressing.
Is there a workaround for now?
Subtracting delta from progress_ratio seems to work for now, but there is a noticeable delay in movement, at least for me.
Fantastic!
On Wed, Sep 11, 2024, 13:04 Rémi Verschelde @.***> wrote:
Closed #95612 https://github.com/godotengine/godot/issues/95612 as completed via #96140 https://github.com/godotengine/godot/pull/96140.
— Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/95612#event-14214146609, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGKE45J3PVQQ54Z6YUQBJYDZWAPS5AVCNFSM6AAAAABMTMQ3ZCVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJUGIYTIMJUGY3DAOI . You are receiving this because you commented.Message ID: @.***>
How can I get this fix locally? Sorry for the noob question, I've never had to track a needed fix for Godot before. Do I redownload 4.3?
Unless you're building Godot from source, it will be available from here https://godotengine.org/download/preview/ I don't think the fix is in Godot 4.4-dev2 though, based on when the commits for this fix and when dev2 released. I'd imagine Godot 4.4-dev3.
Thanks @AaronJMorand! How do I track which release it gets into? Sorry if this is an obvious question.
By the milestone (it says 4.4 in the top right) and also on the PR with the cherry pick labels (in this case 4.3)
I've also been bitten by the 4.3 path issue
There is still an issue in 4.4 dev3, after instantiating the object, initialising the path with a zero value skips immediate update, using a value close to zero however does update.
.progress_ratio = 0.0 .progress = 0.0 .force_transform_update() Does not force an update, using a value like 0.000001 does cause an update.
Because of this, objects that have the path3d and pathfollow3d as children, with the path3d set as TopLevel, and are copying transforms manually in script, do not start on their placed or spawned location. (I do it this way, and I imagine a lot of other people do to, because its really awkward and unintuitive to have a path3d as your top level object in the instance, and I only want to copy location and rotation because I use scaling to create flipped paths instead of creating a completely new set of paths )
I'd suggest some kind of .update() function or .set_progress_ratio(value, true) that immediately updates the transforms? Maybe just give us a check box under the Transform or Process tabs that lets the users decide if they want the classic 4.2 behaviour or the new 4.3 behaviour (expose p_immediate)? Should I open a new ticket about this on 4.4 dev3?
