Aircraft queueing & planespeed

[PikkaBird]

Trains use 1.0 km/h as speed unit, which is 1/1.6 mph (approximately, as a mile is not exactly equal to 1.6 km).

No, Trains use 1.6*mph (and road vehicles use 3.2*mph). However, it appears than in their infinite wisdom, the OTTD coders have changed it so that OTTD thinks km/h is exactly mph*1.6.

If I code a train with a speed of 224 (140*1.6), it will show as 140 mph in both TTDP and OTTD, and as 225 km/h in TTDP (which is correct), but as 224 km/h in OTTD.

[PikkaBird]

Aside to the fact, that callback 0x36 is not handled in OpenTTD at all, the documentation (at the link you gave) says that only property 0C, ie. speed, can be adjusted.

Anyway, I will assume it is used for both 0C and 0D. I will have to figure out how exactly it should work though.

I did say respectively. Property 0D controls acceleration, and is not adjusted by the callback. Property 0C controls the speed that the aircraft is allowed to fly at, and is updated via the callback every time the movement state of the aircraft changes. Of course, OTTD probably has a completely different movement state system due to the new airports, but if it can be documented and made grf accessable I'm happy to update the grf to allow for that.

[hertogjan]

No, Trains use 1.6*mph (and road vehicles use 3.2*mph). However, it appears than in their infinite wisdom, the OTTD coders have changed it so that OTTD thinks km/h is exactly mph*1.6.

If I code a train with a speed of 224 (140*1.6), it will show as 140 mph in both TTDP and OTTD, and as 225 km/h in TTDP (which is correct), but as 224 km/h in OTTD.

You are wrong. You are confusing the speed values with the units. Since 1 mile is 1.6 km (approximately), 1.6 km/h is 1.0 mph, so 1.0 km/h is 1/1.6 mph, not 1.6 mph (or 1.6*mph as you write it).
However, this implies that the speed values relate as (speed in km/h) = 1.6 * (speed in mph).

I already got confused by the ttdpatch wiki before, since it states for instance

Speed in mph*1.6 (see below)

(for property 09). At first glance, I would read this as "speed in (mph*1.6)", i.e. speed in units of 1.6 mph, or units of approximately 2.56 km/h. Further below, it reads

Train speed is in units of mph*1.6, i.e. approximately km/h.

If you read the part of this sentence up to the comma, then one might think that indeed "Train speed is in units of 1.6 mph", but the last part, shows that the sentence should be interpreted as "Train speed is in units of mph, times 1.6" (i.e. take the value of the train speed in mph, and then multiply with 1.6) [1]. Indeed, when you take the value of the train speed in mph, and then multiply it with 1.6, you get the train speed in units approximately equal to km/h.
I would say that the wiki is wrong at this point, but one might also say that only the way it is formulated is confusing.

The same applies to road vehicles and ships, but this time the units are 1/3.2 mph, or approximately 0.5 km/h.

OpenTTD indeed takes the values from newgrf to be km/h. Indeed, OpenTTD does think that 1.0 mph is 1.6 km/h. That needs to be fixed. I already proposed the conversion factor 159/256 earlier [2], which is equal to 1/1.610; indeed fairly close to the number of miles in a km.

[1] Or, equivalently, one may read it as "Train speed is in units of miles per time unit equal to 1.6 hours".
[2] Rather than the current 10/16. I thought that it was changed already, but upon close inspection I saw it wasn't.

[richk67]

Clearly your network finances are so closely balanced that with income based on 1.6x you will go bust, and on 1.610x you are rolling in it.

Last time I checked OTTD was a game, not attempting to control the landing of a spacecraft on a football pitch 1 billion miles away. (is that 1.6billion km, or 1.61billion?)

[DaleStan]

If I code a train with a speed of 224 (140*1.6), it will show as 140 mph in both TTDP and OTTD, and as 225 km/h in TTDP (which is correct), but as 224 km/h in OTTD.

You are wrong.

Absolutely not. If Patch says a speed setting of 224 means 225 km/h, then it means 225 km/h. Absolutely and without question.

If you think TTDPatch is wrong there, then you may submit a bug report, but I seriously doubt something that has been around that long will be changed.

If, on the other hand, you think the wiki is wrong, well, it's a wiki. *GO* *FIX* *IT*!

And it has nothing to do with network finances. It has to do with Open refusing to honor some of the most basic promises made by the NFO spec. How would you like it if the statement "++i;" occasionally had no effect, and there was nothing you could do about it?

[richk67]

Its called sarcasm... point being, it isnt worth the mental effort being applied to it.

[peter1138]

Well, I can change it back if 0.563% accuracy really matters to you...

[bulb]

I did say respectively. Property 0D controls acceleration, and is not adjusted by the callback. Property 0C controls the speed that the aircraft is allowed to fly at, and is updated via the callback every time the movement state of the aircraft changes. Of course, OTTD probably has a completely different movement state system due to the new airports, but if it can be documented and made grf accessable I'm happy to update the grf to allow for that.

Ok. That makes more sense to me. Please, forgive me. I never wrote a newgrf and I am a bit slow in understanding it.

Anyway, even if OpenTTD has different states, it can probably map them to the TTDP ones for purpose of invoking the callback (I suppose there is not much point in differentiating between the various taxiing states, so I can map them to anywhere between 0x00 and 0x07).

However, I am still not sure how to handle the acceleration. What current patch does is treating it as change in game speed (in squares per loop) per loop, which is almost certainly wrong. However I can adjust it either so that the aircraft reaches the same speed (in mph) in the same time (but longer distance for higher planespeed setting), or over the same distance (and shorter time for higher planespeed setting). Could you please tell me which TTDP does?

Also what I am not sure from the descriptions is how the aircraft speed in the various points should be used. In flight it's not a problem -- the aircraft will accelerate until it reaches the speed given. However, for the landing phases I assume the aircraft speed should be clamped to that value. Ie. that I get the touch-down speed for the 0x16 (braking after touchdown) state. Than I would like to ask for the value in advance and slow down the aircraft smoothly so it enters the phase at at most the maximum speed for that phase.

[hertogjan]

If I code a train with a speed of 224 (140*1.6), it will show as 140 mph in both TTDP and OTTD, and as 225 km/h in TTDP (which is correct), but as 224 km/h in OTTD.

You are wrong.

Absolutely not. (...)

No. I was talking about whether the units would be 1.6 mph or 1/1.6 mph. Concerning that fact, PikkaBird was wrong, you were wrong, and the ttdpatch wiki is wrong. The intentions may be right, but as always with physics, if a statement is formulated poorly, it can be misunderstood.
As for the difference between 1/1.6 mph and 1.0 km/h, there is indeed a small discrepancy. I agree that this mistake exists in OpenTTD. It can be fixed. I will certainly do it for my physics patch.

[PikkaBird]

Well, I can change it back if 0.563% accuracy really matters to you...

Well, it doesn't really matter to me. But the difference is significant with the 140mph Class 91 in the UKRS, as it is otherwise known as an Intercity 225.

As for the difference between 1/1.6 mph and 1.0 km/h, there is indeed a small discrepancy. I agree that this mistake exists in OpenTTD. It can be fixed. I will certainly do it for my physics patch.

So you're saying you're going to change OTTD so that the units are km/h, and vehicles will have different top speeds in OTTD and TTDP in both km/h and miles per hour?

If, as you say, the wiki is wrong and the units are in km/h, then why does my train which is coded with a speed of 224 do 225km/h in TTDP?

[PikkaBird]

However, I am still not sure how to handle the acceleration. [...] Could you please tell me which TTDP does?

You'd have to ask patchman on that one.

Than I would like to ask for the value in advance and slow down the aircraft smoothly so it enters the phase at at most the maximum speed for that phase.

In TTDP, the plane will decelerate at the same rate as it accelerates, after it's movement state has changed. I doubt it would be possible to predict movement state changes (as apart from anything else, the movement state while landing depends on where other aircraft are).

Incidentally, I just realised that OTTDdoes still use the same movement state values as TTD, as av8 also uses the movement state to change sprites and that works correctly! So that's something that doesn't need to be updated.

[mart3p]

I have already started writing a patch myself to implement callback 0x36. This is working ok. It also adds deceleration to the aircraft controller.

The problem is that although OpenTTD translates its aircraft movement states to TTDPatch movement states, this translation is not complete (I wrote this code myself for the Planeset patch). TTDPatch movement state 0x14 (heading for the final approach entry point) is not yet implemented

Adding correct translation for this movement state has proved quite difficult. It has to be determined from the aircraft position data, but this is unique for each airport type. Even then, there is not an exact correspondent between the OpenTTD aircraft position data and TTDPatch movement states.

bulb: If you want, I will send you my patch. I don’t want to post it here as it’s unfinished and only partially working. Maybe I’ll find time to finish it.

[hertogjan]

As for the difference between 1/1.6 mph and 1.0 km/h, there is indeed a small discrepancy. I agree that this mistake exists in OpenTTD. It can be fixed. I will certainly do it for my physics patch.

So you're saying you're going to change OTTD so that the units are km/h, and vehicles will have different top speeds in OTTD and TTDP in both km/h and miles per hour?

If, as you say, the wiki is wrong and the units are in km/h, then why does my train which is coded with a speed of 224 do 225km/h in TTDP?

You are turning things around. OpenTTD's internal units are already km/h, since a long time. Before the fix, my patch loads your 140 mph train as 224 km/h (as 224 is the speed set in the grf) and displays it as 139 mph and 224 km/h. After the fix, it will load as 225 km/h, and display as 139 mph and 225 km/h. Actually 225 km/h is closer to 140 mph than to 139 mph, but the conversion for displaying units always rounds down. However, the train acts as if the maximum speed were 225 km/h (or with the new acceleration function, actually 62.50 m/s, which is equal). There may still be some small rounding errors, but they will never be larger than 1 km/h. They will not be noticable in the behaviour of the trains.
Actually, the numbers for the maximum tractive effort are even more off than the speeds [1], but I don't hear anybody complaining about that.

As for the wrongness of the wiki: The fact that it reads "speed in mph*1.6" is wrong. It should have been "speed in 1/1.6 mph" or "(speed in mph)*1.6". The fact that the wiki says that the units are approximately km/h (as opposed to exactly km/h) is correct. But, as I already mentioned many times before, the incorrectness is that 1.6 mph is not approximately 1.0 km/h.

[1] Comparing the numbers for UKRS between OpenTTD and the documentation on its website.

[peter1138]

No need, I reverted the change...

[hertogjan]

That is just bad because this way you are introducing even more rounding errors (and bugs).
I would opt for changing all internal speed units to cm/s. This will reduce rounding errors to a minimum.

[peter1138]

They're rounding errors which are "supposed to be there" so they're alright. Or something.

[hertogjan]

But you are making things even more complicated this way. For instance, all internal functions are based on the fact that the internal units are 1.0 km/h, not 1/1.6 mph. By your update, the vehicle speeds of the original vehicles are wrong (i.e. they show up incorrectly, as it is the case for all speeds). Please look at the update of the physics patch I will upload later this evening. It will show all numbers correctly.

[peter1138]

Actually they're not. They're all original, so work with the original units.
'Realistic' train acceleration also works with 1/1.6 mph units.

The reverted r4322 changed it to 1.0 km/h, but didn't touch any acceleration features...

[bulb]

bulb: If you want, I will send you my patch. I don't want to post it here as it's unfinished and only partially working. Maybe I'll find time to finish it.

That would be nice. I would try to combine it with the queueing and planespeed stuff. I'll try to put the stgit queue I started to use for it public somewhere, hopefully over the weekend.

[bulb]

In TTDP, the plane will decelerate at the same rate as it accelerates, after it's movement state has changed. I doubt it would be possible to predict movement state changes (as apart from anything else, the movement state while landing depends on where other aircraft are).

Um, yes. The decision point cleared for landing/clearance negative would be a problem. This is quite a bit easier.

For the breaking after touchdown phase I would leave the original code in so the aircraft slows down from whatever speed it has to zero over the runway length rather than slowing down too early or being stopped abruptly at the end.

Incidentally, I just realised that OTTDdoes still use the same movement state values as TTD, as av8 also uses the movement state to change sprites and that works correctly! So that's something that doesn't need to be updated.

In fact it does not. It has a function (MapAircraftMovementState in newgrf_engine.c line 288) that converts (one of the) OTTD state value(s) to the TTDP ones. It's the code mart3p is talking about.

The problem is that although OpenTTD translates its aircraft movement states to TTDPatch movement states, this translation is not complete (I wrote this code myself for the Planeset patch). TTDPatch movement state 0x14 (heading for the final approach entry point) is not yet implemented.

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.

On a side note I'd like to rename AMS_TTDP_FLIGHT_FINAL to AMS_TTDP_FLIGHT_PATTERN, as "final" evokes "final approach", which means the descent to runway, while this is "flying a pattern", ie. circling around the airport until the runway is clear.

Edit: Hm, the AMED_SLOWTURN is obviously an abuse, since that flag really should be set for the "en route" (to tower) state as well to avoid the ugly quick turn the aircraft makes when it comes to the tower. The flags are just a byte and it is full, but given how few of these structures exist, extending it to an int is only reasonable (operations with int are faster than operations with other integeral types on most CPUs).

Edit:Did more investigation of the logic and it actually won't work, because the airport entry state is reentered at the end of the pattern. Also the AMED_SLOWTURN seems to be actually implemented wrong (the code didn't look like it should work to me). In the end it might be easiest to add separate state for the pattern.