I already had two cases where I couldn’t schedule a flight due to aircraft performance though it should be fine.
I also have a case on yeager with an already scheduled flight:
If I select the flight number it shows aircraft performance not ok, though the aircraft is flying (scheduled the flight last week)…
In all the cases the flight is either slightly longer than the max payload distance or the runway slightly shorter than the max requirement. Nevertheless in all examples theflight should be possible to schedule.
It’s a known issue and I’ll look into it asap. It’s due to annoying rounding issues, so I’ll most likely add some tolerances to the performance checks.
My change so far (already implemented, just waiting for release) just adds a 1 km/h tolerance in cases like the NRT-SEA one where a 1 km/h rounding artefact causes the performance calculation to fail.
In order to optimize usage of the aircraft i wanted to add the short haul route Toronto - Hamilton (YYZ-YHM).
Here the fix seems to work, I’m now able to schedule the flight and don’t get the aircraft performance error.
But also with the fix, when pressing the optimal speed button - cruise speed remains at 930 km/h
I did test this and that’s how the rounding works.
What you see in the screenshot is the optimal speed / arrival combination.
If you move arrival time from 9.30 pm to 9.29 pm, the speed goes up to 1240 kmh. If you move the arrival time from 9.30 pm to 9.31 pm, the speed goes down to 744 kmh. The speed difference between 930 kmh and 840 kmh is 90 kmh, while the difference between 840 kmh and 744 kmh is 96 kmh, so it’s better performance at 930 kmh and 930 kmh is calculated and used by the system.
There is no way you can arrive at 9.29, 9.30 or 9.31 pm with speed of 840 kmh.
But that’s how the rounding now works. I suppose the true arrival time is something along the lines of 9.29:35 pm which rounds the arrival time to 9.30 pm and then the speed is calculated to match that arrival time which brings the speed up to 930 kmh. That’s why you cannot fix the speed and select optimal cruise speed even after clicking or deselecting the fix arrival time box.
Does this look weird and feel strange and artificial? Absolutely! Let’s see if Martin can maybe make some calculation improvements…as cases like this will repeat and many flights will not be flying at the standard speed on short haul routes, but at lower or higher speeds, and burn more fuel in turn, costing more money, without you actually changing anything yourself.
I would also have suggestion, if the destination is not reached at optimal cruise speed because of rounding, and the slower and higher speed are same deviation form the optimal speed, prefer the higher speed to the lower speed.
The deviation in both cases is 2 kmh from optimal speed. Prefer the higher speed to calculate the slot to the lower speed, in case the deviation is the same for both cases.
Another two suggestions which I would find very useful …
Make adjustable departure time to fit arrival time in one click, in the same way the arrival time is made to fit departure time.
Make the arrival time more prominent… It is somewhat confusing for the eyes (which are used to the old system) and the eyes fall on the “ready for next departure” time instead of on the box with arrival time. My suggestion would be to make arrival time stand out, for example making it bolder, or with somewhat gray background.
Got some ideas for that, as the topic has also been discussed on a German thread. Will likely also take another stab at the general visual representation with more and more functionality being crammed into this space.
Concerning the rounding issues: Not sure I’ll be able to come up with something elegant this week. But I’ll continue thinking about it. I am generally not a fan of “hard limits” these days, and this is a particularly hairy case of just that.
