Replacing speed overrides with fixed arrival times?

I am currently considering quite a drastic change to how scheduling works. Because I am so used to it at this point, I am going to employ the structure of Feature Roadmap posts :sweat_smile:

What?

Each flight assignment gets a fixed arrival time. Just to avoid misunderstandings: A flight assignment “assigns” a flight segment to a specific day of the week (and optionally to a specific aircraft) so that it actually shows up on an airline’s schedule.

The fixed arrival time replaces the optional speed overrides. The “speed override” is implicit, as any aircraft needs to fly a specific speed to match the planned flight time. The arrival time can then be customised (within limits) to hit particular slots or comply with other scheduling constraints.

Since nobody can or wants to actually specify an arrival time manually, default cruise speeds are used to compute an initial arrival time when a flight assignments is first created. Where this value comes from depends on the respective context

  • When doing flight planning for a particular aircraft, that aircraft’s cruise speed is used.
  • When doing scheduling for a flight number, an aircraft type or a specific speed needs to be selected. An option here would be to set a default arrival time on the flight segment when it is created (flight segment = segments of a flight number, so flight segments are created when a flight number is created) using a specific aircraft type or a more generic IATA aircraft code (as in “any A320” with default speeds defined per IATA aircraft code). This way, one doesn’t have to always specify a type whenever creating individual non-aircraft assignment for internal scheduling purposes.

Arrival times can be adjusted at any time, possibly using helper tools to get them in line with a different aircraft type’s ideal cruise speed.

To keep things consistent, we might replace departure offsets with concrete departure times as well.

Why?

The acute motivation for this comes from our recent correction of airport coordinates: Even though these changes shouldn’t affect flight plans as long as they aren’t modified, some players are reporting serious issues arising from changed arrival times and consequent losses of slots. The root issue is that arrival times are dynamic: Speed override or not, when the flight distance changes, the arrival time does, too.

Fixed arrival times alleviate this problem. No matter whether we have to change the position of an airport to fix data, an airport “moves” due to an upgrade in the real world or the speed of an aircraft type changes…flights and slots would remain unaffected and it would be solely at the players’ discretion to change them if they see a benefit in doing so.

Example: Changes outside of a player’s control force an aircraft to fly faster than its ideal speed. This change (within certain performance limits) would not affect the player at all, except for slightly higher fuel consumption. The player can now decide whether they want to adjust the arrival time to get back to optimum performance or whether they’ll leave it as is to keep a slot. The system will not change anything automatically.

Given that one of the most upvoted features in the roadmap category is Auto-Ops / Aircraft Pools, this change can also be seen as groundwork for that: With auto-ops, and consequent extensions to the game based on it, working with a bird’s eye view of an airline’s schedule rather than the flight plans of individual aircraft will become more important. In that context, it actually makes a lot of sense do to scheduling based on more generic aircraft classes and with fixed flight times, rather then tieing everything to concrete aircraft.

When?

This is actually a rather subtle change, but it has pretty far-reaching implications for the flight planning and scheduling UIs. Nevertheless, I am considering an immediate implementation, as it might arrive in time to prevent further issues arising from the new airport coordinates as long as people do not touch their flight plans in the meantime.

Please let me know what you think and how you would prefer the UI for this to look/work like!

Not sure if I understand the change well enough from the description, but my first question would be; how would this affect multiple types flying on one route? E.g. A350 flies1 flightnumber with a speed override of 950 kmh and an A321LR does the same at 820 kmh, which is outside of each others range, but currently possible. Would this still be possible?

That sounds very confusing, but it would still be possible, yes :smiley:

What would happen to the current speed overrides? We currently have a 5% +/- speed overrides offset and the new system would need to model those performance limits, or else there would not be just 2000 flights out of 1.4 million affected, but probably a number much much higher.

Word of advice: As with the last update there is no way to go back with placing old coordinates, maximum effort should be done to not repeat the same thing which would affect many more flights with speed overrides if this does not go as planned.

My suggestion: Please do a backup of the first server to be implemented first before applying update, then please check if everything is working as it should, whether the aircraft and flights with minimum/maximum speed overrides are not affected, and once all is okayed, then continue implementation to the other servers. If the update doesn’t go as planned and causes issues, there will be a backup to go to if things go not as planned.

Also you wrote about scheduling page, I don’t know how many people actually do scheduling through there, I believe most schedule though the aircraft flight plan pages so the speed is already known. The ability to select the arrival time would need to be available on that page as well, or it would break the gameplay for many people.

Also I would suggest an automatic calculator which the scheduling page (both within aircraft schedule scheduling and in scheduling standalone page) that would show basic arrival time (no former speed overrides), and minimum and maximum arrival time (if like maximum/minimum speed override was used).

3 Likes

I actually see very little risk of something going wrong here (I know, famous last words) as the arrival times are stored already, with and without speed overrides. So technically, we would “just” be removing the overrides and instead make the arrival times editable.

That’s also the reason why I am considering doing this right now, as quickly as possible. Because any flights so far untouched still have working arrival times stored in the database.

Also I just realized, on the aircraft transfer page, settings would need to change from “maintain speed override” to “maintain arrival time”, I do not know how the code behind it works, but I guess it would also need to remove the speed override portion of the flight plan and look up the arrival time instead and lock that in.

The behavior would flip around here, I guess. Instead of having to specify that you actually want to play it safe (“set speed overrides to maintain flight times”), the option would likely be inverted to read something like “update arrival times to match ideal speed of target aircraft”).

Alright, I think I’m going to go ahead with this. My biggest concern right now is whether I can find a suitable form component to set a time that’s a bit more compact but still as straight-foward as the current one.

Right now there’s a lot going wrong. Adjusting airport coordinates ends an desaster when it comes to switching a schedule from one to another aircraft.

For example: I’ve started to exchange leased A220 with owned ones. Flight times now are a few minutes shorter or longer what results in error filled schedules for the new aircraft. So up to 8 flight numbers per aircraft have to be adjusted manually just because of your idea to correct airport coordinates.

Luckely most of the A220 had been replaced before the patch. But starting to replace DH8 by DH8 Basics seems to become a full time job.

If you can, just wait a bit longer until you do any changes. Once I’ve added fixed arrival times, you shouldn’t have any problems anymore. But as soon as you touch the flights and new arrival times are computed, the damage is done.

Thanks for your immediate answer.
Take your time.
I’ll give priority to other projects.

Just one consideration, how would this change impact ORS scores. Currently, by leaving the flights as is, you might have a negative or positive impact as flight times have changed by over 5 minutes on some routes, this might give an edge (or penalty) for those airlines that don’t replan. Would in the new system the speed be automatically be overridden for all current flights to charge additional fuel costs for those already scheduled flights. Note: the 5 minute differentiation that I had on one of my routes when replanning would not have been possible with a speed override, as the distance was not great enough.

I like the idea of fixed arrival times. It’s logical and should make the UI more consise.

What about flights that become longer but are currently at max speed? They cannot increase the speed any further and will therefore become invalid.

Why change the coordinates for an existing world? Seems like little benefit for the risk of causing trouble.

Once a limit is reached, there’s little that can be done. But I am considering increasing the limits to +/- 10% or even 15% anyway, as the 5% we currently have often aren’t enough to hit a different slot on shorter distances.

It’s two-fold:

  1. Coordinates do sometimes change, either because an airport moves in the real world or we just messed up and need to fix it. So generally blocking all changes isn’t something I’d want to do in this case (we do it for some things like airport size, but only because the consequences would always be drastic).
  2. It’s for the sake of our future sanity…I’d hate to have 4.5k airports with two different sets of coordinates in old vs. new game worlds. Whenever I can avoid having differences between old and new game worlds, I’ll try to do so.

Discussion here