Enable show origin transformations through interactions with the takeoff markers

[isti115]

This is a very minimal working prototype that needs more testing / consideration to decide what other special cases need to be handled.

Can be experimented with at: http://live.skybrush.donko.hu/(feat/takeoff-position-selection)

For example currently there's something weird going on if the user tries to manipulate the takeoff positions after a show is unloaded.

Also, the behavior should probably be different in the generic mission context. Maybe for the time being we should just completely disable the interactions unless we are in show mode and just deal with the rest later.

[vasarhelyi]

Comments from testing:

• the general UX is great, much better than before, drone selection is not disturbed in practice, but moving show layout is much easier and much more transparent, yeppp
• if I press X to delete the show, the convex hull disappears but the show takeoff positions remain there, but if I move them they disappear when I release the mouse button after moving. They should disappear with the convex hull at the moment of show clear...
• if I load a 10-drone show, select convex hull (together with the 10 takeoff pos) and then load a 50-drone show then only the first 10 drones will be selected. would be better to clear selection completely when a new show is loaded, or extend it to all takeoff positions)

extra:

• Would be nice to "lock" the show somehow to prevent accidental motion, but this is another independent (but related) feature request I guess with a longer history...

[isti115]

• if I load a 10-drone show, select convex hull (together with the 10 takeoff pos) and then load a 50-drone show then only the first 10 drones will be selected. would be better to clear selection completely when a new show is loaded, or extend it to all takeoff positions)

Thank you very much for the testing, this is the exact kind of issue that I was hoping to discover before going further down this route and having to switch directions later. 👍 I'll move on to trying to implement this based on "virtualized selections", which will hopefully avoid this problem completely.

[isti115]

I have pushed a work in progress version of the virtualized selection based implementation, which doesn't have issues when switching between shows with different number of drones, but still has the weird behavior when home positions are manipulated while no show is loaded. (The cause of which is that manipulating the show origin in any way results in setupMissionFromShow being called, which in turn clears the takeoff grid.)

They should disappear with the convex hull at the moment of show clear...
— @vasarhelyi ∙ 2026-03-09

Looking at it purely from a theoretical standpoint, clearing the mission when unloading the show seems like a reasonable thing to do, but there may be practical reasons to avoid doing so. For example, currently the mapping is kept when a mission is unloaded, which could help in certain situations (unloading a show can be the result of a single misclick, as there's no confirmation) and even persist between restarts of Live.

Also, as this has already been the case for a long time, some people might be used to seeing the previous takeoff grid and getting rid of it would potentially disturb their workflow.

[ntamas]

@isti115 Did we reach a conclusion with this PR in the dev meetings, do we need anything else to move forward with the implementation?

[isti115]

I think that we have decided that it is acceptable to get rid of the takeoff markers (that is, clear the home position list in the state) when a show is unloaded, but I haven't yet found a clean way to implement it. Doing this step in the clearLoadedShow action wouldn't suffice, since the positions would still persist when closing and reopening live, which essentially "unloads" the show, but without calling this action. On the other hand, I would like to avoid having to blacklist mission.homePositions for redux-persist, as it makes sense to preserve them in the generic mission context, where mission items are kept too. Maybe we need to handle this conditionally during state restoration depending on the active MissionType, but that doesn't really feel right to me either. 🤔

The other approach I can think of right now would be to let the home positions stay in the state instead of removing them completely, and restrict their visibility / interactability depending on whether there's a show loaded at the moment.

[ntamas]

The other approach I can think of right now would be to let the home positions stay in the state instead of removing them completely, and restrict their visibility / interactability depending on whether there's a show loaded at the moment.

This sounds good to me, assuming that we can restrict the behaviour to "show" mode. (It is not a problem in "mission" mode, is it?).