There are some scenarios where, if the user has multiple road points selected, the gizmos can be displayed on a different roadpoint than the lane visualizers.
We believe the root cause is that Godot's list of editor selected nodes is not in a guaranteed\ order, while Godot's editor panel will always make the top/first node the "active" node in a selection (ie literally whatever higher upon the hierarchy view, even if it's a sibling at the same level). A workaround would be to essentially do a loop to see which node does/would show up first in the ordered view, traversing selections and finding their parent-child relationships. Though, it seems strange we can't more directly identify the internal concept of the "active object" like we can in blender's bpy module.
I deem this not launch blocking and rather a reflection that multi selections just aren't supported yet, and that we can improve/address this when we design more meaningful multi selection behaviors.
There are some scenarios where, if the user has multiple road points selected, the gizmos can be displayed on a different roadpoint than the lane visualizers.
We believe the root cause is that Godot's list of editor selected nodes is not in a guaranteed\ order, while Godot's editor panel will always make the top/first node the "active" node in a selection (ie literally whatever higher upon the hierarchy view, even if it's a sibling at the same level). A workaround would be to essentially do a loop to see which node does/would show up first in the ordered view, traversing selections and finding their parent-child relationships. Though, it seems strange we can't more directly identify the internal concept of the "active object" like we can in blender's bpy module.
I deem this not launch blocking and rather a reflection that multi selections just aren't supported yet, and that we can improve/address this when we design more meaningful multi selection behaviors.