Fix Pathfollow direction and add Z forward option

[TokageItLab]

Fixes #53837.

The direction is changed, but some countermeasures are planned in the near future. See #72843, #72795 and #72753.

As long as #72843 will be merged, the change about the direction is not breaks compat. However, the following method changes are breaks compat. merged into this PR.

---

PathFollow2D:

• Rename: rotates set_rotates is_rotating -> rotation_enabled set_rotation_enabled is_rotation_enabled
• Remove: lookahead the DEAD PROPERTY💀

PathFollow2D/3D:

• Rename: cubic_interp set_cubic_interpolation get_cubic_interpolation -> cubic_interpolation_enabled set_cubic_interpolation_enabled is_cubic_interpolation_enabled

But, to avoid breaking the scene, old methods is made migratable as deprecated in _set() _get().

[fire]

I am supporting this, and this is a local change.

[TokageItLab]

Rebased, and integrated #72843.

[aaronfranke]

In general I support this PR. Adding this option is a good idea, and naming it model front is a very good sensible choice.

I was initially opposed to adding new constants when they had the GLTF_* names, but I now after discussion and with the new names I think they are very good and sensible. The constants in this PR are very descriptive and are self-consistent with each other.

[aaronfranke]

These changes seem unrelated to adding a new model front mode to look_at. I'm not sure why not split these changes into a separate PR.

[TokageItLab]

I talked to @akien-mga earlier and got his agreement that these method names are bad, but he seems to have a terrible aversion to changing method names in 4.x, so I decided to change only the cpp function names same as #74190 (comment). Binding method names have not been changed. If he does not like it, I will split it.

[aaronfranke]

I updated my PR #75875 to be identical to the Basis/Transform3D/Node3D changes in this PR, excluding the path/curve changes, with the below review comments applied, and with this line added to each method's documentation:

If [param use_model_front] is [code]true[/code], the +Z axis (asset front) is treated as forward (implies +X is left) and points toward the [param target] position. By default, the -Z axis (camera forward) is treated as forward (implies +X is right).

(I also marked you as author since I started by copying the contents of this PR exactly)

[aaronfranke]

I approve of these changes. In the event that the path/curve stuff is desired to be split off from the look_at stuff (pending decision from @akien-mga), I have this PR available that is mostly a subset of this one: #75875

[YuriSizov]

For the record, renaming method arguments is probably breaking compat too (for C# at least?)

[akien-mga]

For the record, renaming method arguments is probably breaking compat too (for C# at least?)

That's true, but I think we've already renamed a lot of method arguments in 4.1 already. If we want to preserve this level of compatibility for C# (I personally think it's too demanding), we'd need another dedicated compatibility system for it.

[akien-mga]

Thanks!

[YuriSizov]

Yeah, I agree. Just mentioning it so it's clear to anyone looking through the changes.

[raulsntos]

Renaming arguments in C# is a source breaking change, not a binary breaking change. This means, if you are using a library that was built against 4.0 that library will still continue to work in 4.1 without having to recompile it. A source breaking change is only an issue for the application/game code but it's usually easy to fix.

In this case, the code will break only if you are explicitly using the argument names:

void MyMethod(int one, int two, int three) { ... }

// This method call will not break if the arguments of MyMethod are renamed.
MyMethod(1, 2, 3);

// This method call will break if one of the arguments of MyMethod is renamed.
MyMethod(one: 1, two: 2, three: 3);

I'm more worried about binary breaking changes because it's a lot more disruptive.