peter1138 wrote:

Basically it sounds like we just need to do prop 25 (as used by var 42 byte 3) before prop 09.

Is there any other discrepancy in our CB36 execution order?

This comment was imported from FlySpray: https://bugs.openttd.org/task/1854#comment3691

OzTransLtd wrote:

Within CB36 (09 for speed, 0B for power), I use the following veh vars : 40, 41, 42, 60, C6 and FF(bit0); and within CB36 (25 veh property) : veh var 40 and random action 80/83.

I would say property 25 needs to be dealt with together with default veh pro 25 / veh var 42(byte3) and all other variables should be in place before CB36 gets called for properties other than 25.

Currently, I only use CB36 for 09, 0B and 25, but thinking of adding 1F.

This comment was imported from FlySpray: https://bugs.openttd.org/task/1854#comment3694

glx wrote:

"Cab Car attached, CB36 (for 09 speed) is called for cab car; 82 40 00 FF is checked and returns 0x00 [speed set to 32 km/h assuming cab car leads consist], it should return 0x02 (cab car is vehicle # 3 in consist), so that speed could be set to 128 km/h."

If I understand the specs correctly, you check var 40 for first vehicle of consist (the engine), so of course it returns 0x00.

This comment was imported from FlySpray: https://bugs.openttd.org/task/1854#comment3696

OzTransLtd wrote:

I'm sorry, another typo; should be 81 40 00 FF; although in TTDPatch it works with either type, i.e. 82 or 81. Basically, I check, whether vehicle (cab car) has been bought as lead engine; then, speed is either 32 or 128 km/h depending on veh var FF(bit0). If not bought as lead engine, default speed should apply (adjusted for slowest vehicle in train).

There is still a problem; I'll need to investigate further. Vehicle detail window shows the correct speed 32 km/h in one direction and 128 when direction reversed; the train, however, travels at 32 km/h regardless of direction.

This comment was imported from FlySpray: https://bugs.openttd.org/task/1854#comment3697

OzTransLtd wrote:

See .png; if train travels normal (veh var FF(bit0) = 0), speed settings are correct; if train travels in reverse direction (veh var FF(bit0) = 1), speed settings are mixed up, i.e. the displayed maximum speed is correct, but the actual travelling speed (at full throttle) is incorrect.

There seems to be a call of CB36 (09) twice, once for the vehicle detail window and once for the speed the train travels at. Between the 2 bit0 of FF gets flipped.

Further, it seems to be a bit of pot luck, who gets the chance to set the speed; it can be the engine, or the cab car. I can probably work with both of them, regardless who gets the call.

I hope this helps in getting this problem sorted out. BTW, don't confuse the shown liveries with the vehicle description; the description is all that counts, the livery is gimmick.

On a side note : the whole callback system lacks one result option. Today we have a) a positive callback result and b) fail the callback = use a default value/action. We don't have an abort the callback option = do whatever you would do, if the callback was never called or requested.

Attachments

• Bug Report #FS1854.png (64.85 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/1854#comment3698

peter1138 wrote:

The max speed displayed in the detail window comes from the same location used for limiting the speed in game. CB36 (09) is only called once per part.

It's not pot luck. All parts except those using wagon overrides get the ability to lower the maximum speed. It can't, however, be raised once it has been lowered.

If the callback was never called, then you'd get the default value, so failing the callback aborts it.

This comment was imported from FlySpray: https://bugs.openttd.org/task/1854#comment3699

glx wrote:

Are you using realistic acceleration ?

This comment was imported from FlySpray: https://bugs.openttd.org/task/1854#comment3703

OzTransLtd wrote:

Are you using realistic acceleration ? ...
I've been using r12365, with 'realistic acceleration for trains' = off (by accident). Turning it on, makes the problem go away; speed adjustments work in both directions as they should. Does fix r12369 have something to do with this ?

The max speed displayed in the detail window ...
That is fine with me; in fact I only need CB36(09) for the lead vehicle and can abort the call for any other vehicles.

All parts ... get the ability to lower the maximum speed. ...
All parts of an articulated vehicle ? I'm happy with it, if that is per train and instance; i.e. in depot (each time train is altered), at end-of-line or when being reversed.

Example :
. buy engine (speed of engine = 96 km/h) – speed set to 96 km/h
. add wagon (speed of wagon = 88 km/h) – speed set to 88.
. is van present, no = speed reduced by 20% to 69.
. van added (has no speed limit).
. is van present, yes = speed raised again to 88 km/h or set to 88 because of freight wagon, but not penalised.

This should and does work at present. The train speed is set to slowest vehicle in train (minus 20% if freight train and no van present).

If the callback was never called, then you'd get the default value, ...
Yes, that is fine.
... so failing the callback aborts it ...
but that may use the default value again and again.
You may not have this problem, but TTDPatch does. There, if you don't use CB36, you may set hp of a steam engine with tender to 5,000 hp (action-0, prop 0B). Then, you add CB36 for speed and hp jumps to 10,000 hp because CB36 for power (never ever touched) failed, adding 5,000 hp for each part of the engine. If CB36 was really aborted for all calls bar speed, then that would not happen. Currently I fail it, but then it uses the default, unless I let it fail for the engine part and return a callback result of 0 hp for the tender. So, 'abort' and 'fail' are 2 different things.

The whole issue comes to light with generic callbacks, like 34 and 18, which even span GRFs. Something to think about for another day ...

This comment was imported from FlySpray: https://bugs.openttd.org/task/1854#comment3704

peter1138 wrote:

All parts of an articulated vehicle ?
You're right, only the first part of an articulated vehicle can change the speed, currently.

You may not have this problem, but TTDPatch does.
Yes, that's the TTDPatch bug. Have you reported this description to them? I don't know if they're aware of what actually causes it.

This comment was imported from FlySpray: https://bugs.openttd.org/task/1854#comment3717

OzTransLtd wrote:

TTDPatch problem with CB36 doubling hp has been reported by Pikkabird in April 2007; not fixed but I have a workaround in place.

r12283 ...
I've done some testing with r12283; all issues seem to be solved. Veh var 42 is now set correctly, other veh vars have not given any problems, CB36 works now as expected and all speed settings are now correct, regardless of realistic acceleration being on/off. Thanks for the help and fixes, consider this one closed.

This comment was imported from FlySpray: https://bugs.openttd.org/task/1854#comment3726

glx closed the ticket.

Reason for closing: Fixed

In r12377.

This comment was imported from FlySpray: https://bugs.openttd.org/task/1854