Martin, Can we please have an option in the settings to disable the automatic allocation of the fixed arrival times. Its a real nussance to dealloocate the fixed arrivals when rescheduling. Please make it an option in the settings.
2 Likes
Definitely this proposal would be a massive QOL update. Maybe a toggle button when planning would also be an option.
This would be a fairly simple change for me to do, but keep in mind the implications: With a setting like this, every time you opened an existing flight segment for scheduling that already has different arrival times, these customisations would immediately be lost. So before saving the settings, you’d have to manually reconstruct them.
An alternative would be to leave fixed arrival times disabled when all flight days have an arrival time = the default arrival time. This could in fact be the default behavior, no extra setting required.
Except if it is set now its set of the input is the same as default it does not select the arrival time.
This eliminates the great amount of now blocked flight numbers as when you delete a flight it goes in S mode resulting you can see the flight number anymore. (Only via Scheduling).
So by default off till it is used would ne my idea.
1 Like
The fixed arrival times feature is good. But I would personally like to use the speed override function instead in most cases.
As is alot of my planes fly faster then their normal cruise speed by a few km/h. If I change the departure time the arrival time doesnt change and the plane simply slows down or speeds up unless I manually reset it. I would like to be able to turn this on or off.
I would like to be able to select arrival time and if that doesnt fit be able to move it by either adjusting departure or speed but have the option to leave the aircraft at it’s economical cruise speed.
It’s on my list to allow locking the actual flight time instead of the arrival time. Which, technically, is a “speed override”. So in a sense, we would have come full circle: We had “speed overrides” initially, which should have been “fixed flight duration” to begin with. Then I switched to fixed arrival times to address a particular problem (flight times changing due to changes in the simulation…be it data, performance or whatever). And finally I might switch back to fixed flight duration OR fixed arrival time, depending on use-case.
But before I do that, I’d like to look into another tiny but possibly impactful change that I was made aware of the other day in a completely unrelated topic:
I am referring to the part highlighted in bold. We do in fact have that, albeit as a static duration that’s added to all flights, irrespective of aircraft type, airport size or any other factor. This, imo, explains a lot of the rounding issues that people see in their cruise speeds. With cruise speeds deviating from the default for no apparent reason. I would really like to change this to something that makes more sense. A plane will, generally, fly along the great circle path. And I don’t see us modelling actual airways anytime soon. But additional distance for approach, ascend and descend could and should easily be added. And they should likely depend on the route flown and possibly even the aircraft type. For a Britten-Norman that flies a 15km flight between two island airstrips, the flight profile is likely fairly close to a “straight line” and there is absolutely no point in adding another 30 minutes of flight time.
Now that I actually spell it out…this basically feels like a bug 
I am actually looking into this today and might require some input.
One change I did today (not deployed yet) is that when a flight is selected for scheduling, arrival times are only fixed when they differ from the computed value (given the current departure time and aircraft speed).
With this in place, the basic four scenarios one encounters when scheduling flights should work fairly well:
- No slot restrictions: schedule the flight as desired
- Departure slot unavailable: schedule flight, then move it via departure time and/or offsets to find a free slot (arrival time slides accordingly)
- Arrival slot unavailable: schedule flight, then find an arrival time within a free slot (arrival time now fixed and will stay fixed when coming back to adjust the flight)
- Departure and arrival slots unavailable: schedule flight, adjust departure via departure time and/or offsets, then set a fixed arrival time (essentially steps 2 and 3 in sequence)
In my head, this all makes sense. But that’s because I assume the intended use of speed overrides, namely “always fly at optimum cruise speed, only deviate when necessary”.
But as the reactions to the scheduling UI changes have shown, there seems to be a fairly large crowd that just cranks up speed to the maximum and wants to stay at that speed when looking for slots. My initial thought was to just offer an option to “lock the flight time”. So when you have a flight with a fixed arrival time (any flight deviating from optimum cruise speed) you could change the departure time and the arrival would slide accordingly despite the fixed arrival time.
There are a couple of things I don’t like about this approach: Firstly, it’s unintuitive in regards to the “fixed arrival” setting as it’s an obvious contradiction. Secondly, I figure a user would expect it to work the other way around too, so when you change the arrival time, the departure time slides with it. In principle, this would work. But only up to a point, because departure offsets are limited to +/- 60 minutes and modifying the actual base departure time of the flight segment in this way feels odd. In addition, this would definitely require extra steps when one actually needs to adjust departure and arrival times separately.
So now I am somewhat uncertain about whether the already implemented change (only tick the “fixed arrival” checkboxes when the time is actually different from the default) already suffices for the majority of scenarios (since it’s more common to schedule new flights than to modify existing ones) or whether more functionality is needed for other use-cases.
Looking forward to your feedback
The previously mentioned change (arrival times are only fixed when they differ from the computed value) is now live (see change-log).
Still looking forward to anyone’s feedback on my discussion above, though
Just wanted to say thank you for the change. Small change but way better now!
As I’m not using max speed as default, I’m pretty happy with the current implementation.
3 Likes
Thank you as well.
Such a small change but what a massive improvement in usability.
2 Likes
Can’t be said enough. Real quality of life improvement.
2 Likes