Allow user to move waypoint for whole package at once.

[SnappyComebacks]

Is your feature request related to a problem? Please describe.
If you have a package of many flights, moving waypoints only effects one flight at a time.

Describe the solution you'd like
Provide a way for the user to move all the waypoints in a stack (multiple flights within a package having the same waypoint location) at once.

[DanAlbert]

Should probably be optional since there are cases where you might want to put the other flights on a slightly different path. Probably a checkbox in the ATO panel or above the map? The PackageWaypoints class covers the waypoints that would be affected by this.

[Golfwingzero]

Additionally, for manually created packages, after creating the main flight waypoints, the subsequent escorts could have their waypoints (rejoin, etc) automatically match those of the main flight.

[ghosty141]

Whats the status on this? For SEAD + DEAD flights I find it really annoying having to drag 4 waypoints around and having to line them up. Is there a better way?

[Starfire13]

You have to drag each waypoint individually.

[DanAlbert]

Same as every other FR that doesn't have any activity. It needs a volunteer to do the work.

[ghosty141]

So I could technically do this since I'm a software dev who has experience with both qt and python but I'd need a bit of guidance and a rough overview to grasp the scope and difficulty of the issue.

[Starfire13]

There is a #developers-getting-started channel on the Discord for those needing help getting started with that. Drop on by and post what questions you have.

[DanAlbert]

The quick and dirty fix that is most obvious (if you move a IP, find the other IPs in the package and move all of them) would break very soon because of #270. The flight plans are getting less prescriptive, and there won't actually be anything stopping anyone from adding multiple IPs, in which case you won't know which IPs are the correlated ones that need to be moved. I wouldn't merge that fix because I don't want to be on the hook for redoing it.

One way to do this might be to make waypoints selectable, and multi-selectable. I don't know how to do that, so I won't be much help on the implementation side of that.

Another thing that might work would be adding tags to waypoints that would be set by any auto generated flight plan. If a flight plan generates a single IP waypoint, it could tag that waypoint as an IP. Moving a tagged waypoint could (optionally) move all other waypoints in the package with the same tag.

A bad UX that would definitely work would be to add a button to the waypoint menu (that menu does not exist, but clicking a waypoint probably should bring a up a dialog that lets you do things like edit altitude) that gives you a list of all the other waypoints in the package with a "move here" button next to each, so rather than the system needing to be smart enough to figure out which waypoints "match", the user can just pick which waypoints to move.

If you can think up other ways to do this, I can probably tell you whether they're viable, and probably give pointers on where to start.

Maybe a better question though: is there a problem with the auto generated waypoints that should be fixed instead?

[ghosty141]

I'm a newbie when it comes to liberation so take my points with a grain of salt :)

I mostly noticed this issue for SEAD flights where you need escorts, so you gotta drag 4 waypoints (which can be quite a lot if you count refueling, join, ingress, maybe egress). This is not a dealbreaker but something I found irritating as a new user since it seems like something normal and easily fixable. Obviously there is some nuance to it like with the issue you mentioned.

My idea:

1. If the package is selected in the list, the wpts of all flights are displayed
2. Add a waypoints tab to the package editor
3. In the package waypoint editor waypoints can be managed just like in a flight. They should be displayed in a different color than the flight ones on the map though so users can differentiate them.
4. Add an option for the flight waypoints editor to make a waypoint a "package waypoint" which points to an entry of the package waypoint list. For example via dropdown that gives a list of package waypoints.

This is far from a small change but it's the only way I can think of that doesn't have bad edge-cases. Basically the tags idea with a bit more fluff around it. I think it's "okay" since for casual users nothing will change, they can still manage their flight waypoints like the used to. For advanced users I think it's a neat change since it makes it far easier to plan bigger packages which can more easily be edited.

[Starfire13]

I mostly noticed this issue for SEAD flights where you need escorts

I would actually suggest SEAD is one mission type that you really don't want to use escorts for, because escorts overfly the package's target. Which will quite often result in your escort flights getting shot down. Generally, the only time I use escorts is for WW2 because overflying a flak battery is not quite so much a death sentence. For modern campaigns, I rely on CAP flights set up so they don't cross too far into SAM threat range.

That said, yes, moving waypoints around is a hassle. I typically spend more time setting up a turn than actually flying it, and a big part of that is adjusting all the flight waypoints by hand and setting up all the TOTs (and I have to remember to go toggle off the "ahead of package" checkbox for every single SEAD flight because the default one minute separation is too short since suppression isn't a thing, and it just makes things messy since I often have more than one SEAD flight in a package if I'm using HARMs, I'd rather set the offset timing manually on my own - 3 min for HARMs, 4 min 30 seconds for TALDs).

What I'd like is a way to modiy one flight's waypoints and then tell another flight (or flights) to "use that flight's waypoints as template". That way, you'd essentially only have to manually fix one flight per package. However, we don't want the waypoints for multiple flights to stack up perfectly as that will lead to collisions and general AI stupidity. So there'd have to be some level of fudginess to the precision. Easy to say, of course. Coding it is another matter.

[DanAlbert]

@ghosty141 I'm going to need some time to think over your suggestion. On first read I don't really understand it.

What I'd like is a way to modify one flight's waypoints and then tell another flight (or flights) to "use that flight's waypoints as template"

For the reasons I gave above, that's not viable.

[ghosty141]

A little mockup:

This way we circumvent the issue with knowing which waypoints must be grouped together (which you can't always determine without asking the user). It also has the benefit of not breaking if flight waypoints are added between others that are linked to the package.

[DanAlbert]

The mocks help, thanks.

Doesn't the user still need to set those up though? Alternatively, if that's how it's set up by default, they'd need to undo that to move a waypoint independently. Both of those sound like considerably more work for the user than just moving three or four waypoints. I'm either missing something or that wouldn't solve the core of the problem. It's not like people are changing the package waypoints many times per turn. You relocate the autogenerated waypoints to your liking once per turn and you're done. The problem here is that it must be done once per turn per flight instead of once per turn per package. Any setup cost here is going to make it more work than just not using the feature and moving everything once.

FWIW my "bad UX" suggestion is also more work (or at least not less work) than the status quo so that idea should probably go in the trash.

I should reiterate that a lot of this is in the progress of changing. The fact that all package IPs are colocated is a coincidence. That will not be the case once we're doing loadout-aware planning (why would you close to 40nm to fire a SLAM-ER? Why would your gun run begin 40nm away?). This is really just about join and split points, and tbqh I expect far fewer fewer packages to have those in the nearish future. I expect far more single-flight packages. If we're planning standoff attacks properly, we don't need escorts, low flying one-pass haul-ass viggen attacks don't need or want escorts, vipers can often self escort, etc.

[Starfire13]

nd tbqh I expect far fewer fewer packages to have those in the nearish future

Yeah, many of my packages are single flight packages. When I set up multi-flight packages, it's because I want flights to arrive precisely x number of minutes after other flights. For example, I want my DEAD flight's TOT to be 4 min 30 seconds after my TALD flight (because that means the missiles from my DEAD flight arrive as the TALDs are right over the target). Or I may set up 2 SEAD flights with a 3 minute separation so the first will kill the search radar and the second will kill the tracking radar (because the first flight will just spam all their HARMs at the SR). The other time I use multi-flight packages is if I'm throwing a whole bunch of planes at the same target (e.g. enemy carrier).

[ghosty141]

than just moving three or four waypoints.

Thinking about this, yeah sounds like multiple waypoint selection where moving them also keeps their relative position to each other might be the best way. Is there anything that would be problematic with it? From your previous reply it sounds like more of a technical issue that needs to be figured out. I might poke around it in the coming weeks.

[DanAlbert]

No, if you can figure out how to do it multi-select sounds great, and we'd probably use it for more stuff in the future. I've just got no idea how to do it :)

[ghosty141]

@DanAlbert how can I reach out for question I might have that are not specific to this issue? For example using python 3.12.1 like mentioned in the wiki it fails installing the requirements with ERROR: No matching distribution found for PySide6==6.4.1.

Something doesn't line up, cause PySide 6.4.1 requires Python <3.12, >=3.7 so 3.12.1 will not work. So either the wiki is out of date or the requirements.

[DanAlbert]

We're back to 3.11 because of problems with pyside6 in 3.12. I forgot to switch the wiki back.

[DanAlbert]

And the dev getting started channel in our discord is the place to go if you prefer that over GitHub.