Fix ambiguities in transform example

[rparrett]

Objective

Fix these

 -- rotate_cube and move_cube
    conflict on: ["bevy_transform::components::transform::Transform", "transform::CubeState"]
 -- rotate_cube and scale_down_sphere_proportional_to_cube_travel_distance
    conflict on: ["bevy_transform::components::transform::Transform", "transform::CubeState"]
 -- move_cube and scale_down_sphere_proportional_to_cube_travel_distance
    conflict on: ["bevy_transform::components::transform::Transform", "transform::CubeState"]

The three systems in this example depend on the results of the others. This leads to minor but detectable differences in output between runs by automated screenshot diffing depending on the order of the schedule.

We don't necessarily need to be able to do this for every example, but I think this is a case where fixing it is easy / maybe the right thing to do anyway.

Solution

Chain the three systems

[hymm]

is the order just arbitrary?

[rparrett]

The order of the scaling operation isn't as important and it probably only needs to be ordered relative to the movement system.

I think move -> rotate is actually slightly important, as without this order the cube might not actually be facing the center. I'm guessing this would be pretty obvious at lower framerates but I haven't checked.

So I guess

(
    move_cube,
    rotate_cube.after(move_cube),
    scale_down_sphere_proportional_to_cube_travel_distance.after(move_cube),
),

would probably also be fine.

Fixing up ambiguities for the sake of it in examples probably isn't necessary but technically that setup could also use a .ambiguous_with(rotate_cube) on scale_down_sphere_proportional_to_cube_travel_distance if we really wanted to be correct.

Let me know if you'd prefer the ordering above.

[hymm]

Since it is just an example (and a stress test at that), I'm fine with the chain. It looks cleaner.