Animation tracks at runtime not in same order as within editor.

[KnightNine]

Tested versions

v4.2.rc.custom_build [d34f1ec4b]

System information

Windows 10 v4.2.rc.custom_build [d34f1ec4b]

Issue description

Not sure if anyone noticed this or if it's already fixed in newer versions but the order of animation tracks does not persist when the scene is loaded in my project. The animation tracks that have to do with materials get pushed to the bottom making it hard to get/set the keyframes in these tracks by their index.

E.g. Here is an animation in my project, I marked the keyframe values of the first section/group. The following groups have the same keyframe values except for rotation:

Then I wrote this code to get the order at runtime:

        var anim : Animation = anim_player.get_animation("Impact").duplicate()

        var test_val_arr = []
        var i = 0
        while i < anim.get_track_count():
            var j = 0
            var track_vals = []
            while j < anim.track_get_key_count(i):
                track_vals.append(anim.bezier_track_get_key_value(i,j))

                j+=1
            test_val_arr.append(track_vals)
            i+=1

        print(test_val_arr)

This prints out:

As you can see the [1,0] tracks are all pushed to the back of the array.

Steps to reproduce

In an AnimationPlayer node: Create an animation for several mesh nodes that modifies their materials and their transforms. take note of the order of the tracks in the editor. See that they are different at runtime using the code above.

Minimal reproduction project (MRP)

should be easy enough to test.

[AThousandShips]

Can you try on an official build or a more recent branch? You're on a custom branch that's some 6 months old

[TokageItLab]

Similarly, bone index could not match the visual order of the editor and the index, but I think this kind of problem just needs to use find method.

AnimationTree had a problem where the order would change every time it was saved and it caused needless diffs in git by creating meaningless scene change even if there is no change actually, that was a clear bug caused by the HashMap. However in this case, AnimationTrack is a Vector, so the order should not change randomly.

The order may not match the visual order, depending on the insertion order or something, which may be a bit annoying from a usability point of view, but from a programming point of view, there is no clear reason why it should match the visual one. Also the editor's track list could be rearranged by filtering and sorting, so it should not re-index them each time.