Aircraft queueing & planespeed

[mart3p]

I am not sure about the difference between AMS_TTDP_FLIGHT_APPROACH (0x10) and AMS_TTDP_FLIGHT_FINAL (0x14), but they differ from AMS_TTDP_FLIGHT_TO_TOWER by the fact that the AirportMovingData has AMED_SLOWTURN flag on.

Maybe AMS_TTDP_FLIGHT_APPROACH is differentiated by the fact that the position has a decision, ie. that the AirportFTA for the position has a next. However I'll probably just add a flag to the AirportMovementData, as I think about using it in the AircraftController when handling helicopters.

In TTDPatch 0x14 (AMS_TTDP_FLIGHT_FINAL) is the “holding pattern”, 0x10 (AMS_TTDP_FLIGHT_APPROACH) is a short level flight before the decent begins.

In OpenTTD there is no easy way to differentiate these states. In the existing trunk code, these states are never returned by varaction 2 var 0xE2, 0x12 (AMS_TTDP_FLIGHT_TO_TOWER) will be returned instead.

The patch I have sent you improves on this; 0x14 is returned for both 0x14 and 0x10. State 0x10 occurs for such a short time that I doubt it makes much difference. As you say implementing 0x10 would probably need an additional flag.

[PikkaBird]

FWIW, av8 always returns the same callback results for 0x14 and 0x10, so replacing them both with one value shouldn't cause a problem with the current grf.

[bulb]

Hello folks,

I now have a slightly tweaked patch from mart3p implementing the aircraft speed adjustment by callback 0x36 and a plane-speed patch which is significantly smaller than the original.

I, however, have two problems:

1. I am not sure whether I should speed-up aircraft on the ground as well as in the air. My patch does, because it keeps the same values in cur_speed and changes what they mean, while the original patch didn't, because it multiplied the values of cur_speed (so when they are clamped, they were the same game speed).
2. While I enabled the action D getting patch variable 0x10 (plane speed), there seems to be something else missing too, as the running cost values don't adjust when I load av8 with different planespeed setting. The value is indeed looked up, saved into parameter 3 and conditional on that parameter is run, but no visible change of running cost.

[bulb]

Hello folks,

NOTE: I have replaced the patches with newer versions on 2007-02-04T12:20Z (UTC).

NOTE: These patches are based on rev. 8544. Since I don't like changing history, I will post updated patches in separate posts.

I have a planespeed patch working. Series of 3 patches (based on trunk rev. 8544) is attached. The patches should be applied in order:

1. speed-callback.patch
2. plane-speed.patch
3. taxiing-speed.patch

Please, read them, try them out and tell me your impressions.

I ported the queueing patch, but it really desires thorough rewrite, so I am not posting that yet. The current form of the patch significantly reduces the overall throughput of an airport, which is certainly not good. Besides it required some reordering in game initialization which is not good either, so I'll have to do vehicle pool clean-up for it.

These are NOT final patches in any case. I still have some ideas for polishing them and tweaking etc. They are here for review.

[mart3p]

bulb: I've had a look at your patches (although I haven't had a chance to try them yet). You've done a good job with determining the TTDPatch movement states. Using the 'previous_pos' is a much better idea than my look-up table (which didn't quite work right anyway).

Did you get Action D patch variable 0x10 working? It looks alright in the code.

[bulb]

bulb: I've had a look at your patches (although I haven't had a chance to try them yet). You've done a good job with determining the TTDPatch movement states. Using the 'previous_pos' is a much better idea than my look-up table (which didn't quite work right anyway).

I just tried some things and this worked. I actually don't like it too much. It assumes something, that is actually true but there is no indication that it is supposed to be. Therefore some day someone can uncospiciously break that assumption.

Otherwise I would probably add some parameters to the airport movement state tables. I would like to change them a bit anyway, if nothing else than to make the hold patterns nicer. The current hold patterns are really ugly. Straight-in approach would not be bad either and the big airports should probably use right pattern (aircraft turning to the right) to avoid the take-off and landing paths crossing.

Did you get Action D patch variable 0x10 working? It looks alright in the code.

Yes, I did. I had to also add a flag to the patch flags, otherwise AV8 reset the value it read to 1.

Now I want to try implementing the queueing, using a different approach from scratch. Then I was thinking about a more advanced air traffic control with short and long approach paths. The aircraft would try to reserve the runway before turning to base. If it was free, it would turn immediately, while if it was not, it would fly a little further and try again at the approach point. This should avoid the cases when the aircraft approaches as the runway is about to be vacated and has to make a full extra circle.

I should probably get attention of someone with commit bit first and try to get the planespeed in trunk . It makes aircraft so much more playable.

[Celestar]

I'll have a look at the patches tomorrow, but I've myself added some stuff to the UpdateAircraftSpeed. Somehow we need to sync all that stuff (more coming with real airplane speeds and stuff)

Celestar

[bulb]

I'll have a look at the patches tomorrow, but I've myself added some stuff to the UpdateAircraftSpeed. Somehow we need to sync all that stuff (more coming with real airplane speeds and stuff)

I based the patches on trunk rev 8544. I have them in a stgit queue here, so I can import newer version and update them easily if you want.

Your change in 8611 is similar to what I did. However since I then make the limit variable, I prefer using the parameter to select which limit to apply rather than the limit value itself.

I currently change the taxiing limit, so it's not too high with realistic planespeed (aircraft taxiing at full cruise speed (Farman F60 Gohiath from AV8 has cruise speed 11!) does not feel right), but I was also thinking about changing the breakdown speed (27 = ~347km/h, which means DC3 in AV8 still flies full speed with break-down and the next propeler aircraft (AW27 and Constellation) slow down just a tiny bit.). I'd suggest the break-down speed should be 8 + (max_speed - 8)/3 or something like that.

[DaleStan]

Patch uses 5/8 of full speed. I recommend doing the same for balance reasons.

[PikkaBird]

Patch uses 5/8 of full speed. I recommend doing the same for balance reasons.

With a minimum speed at all times of 80mph (largely because aircraft landing at <80mph get stuck in TTD...).

[bulb]

Patch uses 5/8 of full speed. I recommend doing the same for balance reasons.

With a minimum speed at all times of 80mph (largely because aircraft landing at <80mph get stuck in TTD...).

Well, I wanted something where faster aircraft would slow down more, but if TTDP uses 5/8, using the same certainly makes sense.

As for minimum speed 80 mph (~70 knots) it feels way too much with realistic planespeed. OTTD currently uses 96 mph maximum taxiing speed with default planespeed. For the realistic speed 40 mph (~35 knots) or 1/8 max whichever is less felt good to me. It changes the balance a little (airports have smaller throughput), but that's why it can be turned on or off (with minimum 16 mph, at 8 mph the aircraft also tended to get stuck).

In reality, maximum recommended taxiing speed for big aircraft is usually about 30knots.

I was also thinking about changing the patterns somewhat to make them nicer (currently the aircraft are changing direction too often in the pattern), which would probably also make them shorter and improve the throughput a little.

[PikkaBird]

As for minimum speed 80 mph (~70 knots) it feels way too much...

Oops, sorry, that's "minimum speed in flight", not including taxiing. All aircraft in TTD taxi at 15mph (and use, iirc, a completely different movement schema than that used while flying - they're not slowed down to 1/4 speed even without the planespeed patch).

When broken down in flight, a plane in TTDPatch will fly at either:
- breakdown speed, prop 0C * 5/8.
- callback 36 speed, if the callback 36 speed is less than the breakdown speed.
- 80 mph, if the breakdown speed is less than 80 mph.

[bulb]

Oops, sorry, that's "minimum speed in flight", not including taxiing. All aircraft in TTD taxi at 15mph (and use, iirc, a completely different movement schema than that used while flying - they're not slowed down to 1/4 speed even without the planespeed patch).

In OTTD it can't be 15, as the internal unit is kept the same as the grf one, that is 8 mph. It currently is 24 mph real (96 mph, but the slow-down applies in OTTD even to taxiing). I tried different settings and 40 mph felt good with the realistic speed (I kept the original setting for 1/4 speed, so it was something like 12 for 1/4, 9 for 1/3, 7 for 3/4 and 5 for full speed).

When broken down in flight, a plane in TTDPatch will fly at either:
- breakdown speed, prop 0C * 5/8.
- callback 36 speed, if the callback 36 speed is less than the breakdown speed.
- 80 mph, if the breakdown speed is less than 80 mph.

I would rather do it without the minimum for OTTD (or rather with minimum 16 mph), otherwise the zepelin won't slow down at all when broken down.

[bulb]

Hello folks,

Here is updated version that should apply cleanly against trunk as of revision 8660. I also added switch to change aircraft break-down speed to 5/8 max speed (as PikkaBird says TTDP has). It is a separate option in patches configuration (I can change it to single 'better planespeed handling' switch if desired).

The patches are as last time

1. speed-callback.patch: This adds handling for aircraft speed callback, so aircraft slow down before landing and so on.
2. plane-speed.patch: This adds the aircraft speed setting.
3. taxiing-speed.patch: This now adds two "patches", one that makes taxiing speed depend on aircraft maximum speed, with upper limit, and another that makes aircraft breakdown speed 5/8 of max speed rather than constant.

I now consider the patches ready for inclusion. Unless there are objections, of course. I posted them to flyspray as patch http://bugs.openttd.org/task/611

Note: Whoever will merge it, please replace the SDT_VAR with SDT_CONDVAR with appropriate versions. Thanks.

(edit) Note: The patches are to be applied with the -p1 option to patch.

[Quark]

Please make sure that planespeed correctly work with goods transfer in economy.c — when I was looking in rev.7326 I has some uncertainty about it. For example, how speeduped plane affect real profit when it's middle vehicle in transfer chain?

[richk67]

Transfers are generally broken. I have a fix for transfers, that is awaiting final review before trunk commit. It makes transfers really useable, and gives sensible results.

[OSkar000]

Hello folks,

Here is updated version that should apply cleanly against trunk as of revision 8660. I also added switch to change aircraft break-down speed to 5/8 max speed (as PikkaBird says TTDP has). It is a separate option in patches configuration (I can change it to single 'better planespeed handling' switch if desired).

The patches are as last time

1. speed-callback.patch: This adds handling for aircraft speed callback, so aircraft slow down before landing and so on.
2. plane-speed.patch: This adds the aircraft speed setting.
3. taxiing-speed.patch: This now adds two "patches", one that makes taxiing speed depend on aircraft maximum speed, with upper limit, and another that makes aircraft breakdown speed 5/8 of max speed rather than constant.

I now consider the patches ready for inclusion. Unless there are objections, of course. I posted them to flyspray as patch http://bugs.openttd.org/task/611

Note: Whoever will merge it, please replace the SDT_VAR with SDT_CONDVAR with appropriate versions. Thanks.

How do i apply this patch? TortoiseMerge doesnt like the patch so i can't test it.

[bulb]

How do i apply this patch? TortoiseMerge doesnt like the patch so i can't test it.

Then TortoiseMerge should not claim it can apply patches and you should file a bug. Anything like 'Index' is not supposed to exist in a patch. It is probably unique to subversion.

You will have to apply the patch with GNU Patch, either from GNU Win32 or Cygwin.

Note, that since the patches are generated with stacked git, it must be applied with -p1, (unlike patches generated by subversion, which must be applied with -p0). Unfortunately there is no stacks functionality for subversion (and judging from how stgit uses git, it'd be quite hard to implement it in svk) and any other such tool (quilt, mq, patchy git) would generate -p1 patches as well (you can't generate -p0 patch with plain diff, so this is for compatibility).

[OSkar000]

How do i apply this patch? TortoiseMerge doesnt like the patch so i can't test it.

Then TortoiseMerge should not claim it can apply patches and you should file a bug. Anything like 'Index' is not supposed to exist in a patch. It is probably unique to subversion.

You will have to apply the patch with GNU Patch, either from GNU Win32 or Cygwin.

Note, that since the patches are generated with stacked git, it must be applied with -p1, (unlike patches generated by subversion, which must be applied with -p0). Unfortunately there is no stacks functionality for subversion (and judging from how stgit uses git, it'd be quite hard to implement it in svk) and any other such tool (quilt, mq, patchy git) would generate -p1 patches as well (you can't generate -p0 patch with plain diff, so this is for compatibility).

Thanks!

That solved the problem.

The patch seems to work good but I've only played with i for less then an hour so I'm not done testing it yet.

[bulb]

Please make sure that planespeed correctly work with goods transfer in economy.c — when I was looking in rev.7326 I has some uncertainty about it. For example, how speeduped plane affect real profit when it's middle vehicle in transfer chain?

The question is what it means "correctly". The transport time is shorter and counts as what it really is. Therefore the payment per cargo unit and square is higher. I think that it should be that way and that aircraft should be rebalanced via higher cost and higher running cost. If the speedup is 4 times, the aircraft will carry payload for little less than 4 times as many unit-squares and earn a little more per unit-square, so it should have roughly 4 times higher running cost to rebalance. However, PikkaBird said that the running cost should be up to the aircraft set designer and in his set the running costs are just a little more than twice higher with planespeed 4 than with planespeed 1.