Accessing certain variables from other vehicles in the chain

[Eddi]

There is an old open task where George asked for more information about neighbouring vehicles in a vehicle chain [rail or road]. the implementation of that request was not received very well, the devs rather demanded a more flexible approach. but allowing access to all 80+ variables in the chain was also out of the question, because it may cause crazy feedback effects. for example if you use the capacity of the next vehicle in the capacity callback, and for the next vehicle you use the capacity of the previous vehicle, this may cause unwanted/undefined/desyncable effects.

Here i have an approach giving some limited access using 60+ vars, which take a parameter. the parameter is a signed offset in the vehicle chain, i.e. FF is the previous vehicle, FE, FD etc. are the vehicles before that. 01 is the next vehicle, and 02, 03 etc. are the vehicles after that. 00 is the current vehicle, but that probably doesn't make a lot of sense . unless otherwise stated, result is 0 for out-of-bounds access (invalid vehicle).

currently implemented are: [updated]

• var 61: DirDifference similar to var 45 [B or F part, T part may be assembled using var 1C in nested varaction2]
• var 62: height difference (in pixels, i.e. 8 make a full height level)
• var 63: vehicle status (like var 80+32)
• var 64: the three variables above bitstuffed into one: xxyyzzhd, where xx, yy and zz (8 bits each) is the (signed) x-difference, d is 4 bits of DirDifference like in var 45, and h is 1 bit of VS_HIDDEN in bit 7 (appropriate mask is \dx00000080). (not sure how useful the coordinates are in the map-coordinate system, might be more useful to transform into a vehicle-coordinate-system first)
• var 65: engine-id (like var 80+46), 0xFFFFFFFF if invalid vehicle

(note: since this spec is not finalized, the variable numbers may change in the future, and not all variables will end up in the final spec)

patch is attached to the ticket above, a win32 binary is available here, kindly provided by Terkhen.

what is needed now is

• test grfs using these variables, to check their functionality for any issues (in the easiest case: implementation mistakes, in the worst case: desyncs)
• opinions of grf authors whether the approach is sensible, and whether some other variables might be useful/needed

[George]

currently implemented are:

• var 61: DirDifference similar to var 45 [B or F part, T part may be assembled using var 1C in nested varaction2]
• var 62: height difference (in pixels, i.e. 8 make a full height level)
• var 63: vehicle status (like var 80+32)

patch is attached to the ticket above, a win32 binary is available here, kindly provided by Terkhen.
what is needed now is

• test grfs using these variables, to check their functionality for any issues (in the easiest case: implementation mistakes, in the worst case: desyncs)
• opinions of grf authors whether the approach is sensible, and whether some other variables might be useful/needed

1) also useful things (I'd use)
The var to get the ID of the vehicle at offset
The possibility to know, that it is the depot / buy menu / vehicle window and return appropriate graphics
2) var 61 tested for trains. Seem to work. At least first test passed

[Eddi]

The var to get the ID of the vehicle at offset

does that have a matching 80+ variable? makes it easier to copy the code from there

The possibility to know, that it is the depot / buy menu / vehicle window and return appropriate graphics

that's a bit trickier. the idea was to provide this via "extra callback info" (var 10, IIRC), but i haven't researched the right places in the code yet where that must be hooked into.

2) var 61 tested for trains. Seem to work. At least first test passed

thanks, good to hear

[Yexo]

The var to get the ID of the vehicle at offset

does that have a matching 80+ variable? makes it easier to copy the code from there

Var C6.

[Leanden]

Graphically or gameplaywise, what does visible effect does it give? I assume this isn't related to the other topic we were discussing about cargo rates.

[Eddi]

check here or here for possible application.

[Leanden]

Just had a read and I like the concept, could make for some interesting graphical developments.

[Eddi]

updated the diff with the request above (var 65 like var C6) and updated the first post.

btw.: var C6 alone might not be useful enough, the GRF-ID of the vehicle is not known.

[George]

updated the diff with the request above (var 65 like var C6) and updated the first post.
btw.: var C6 alone might not be useful enough, the GRF-ID of the vehicle is not known.

more interesting question for now - does it support values above 256?

[Yexo]

No reason why it would not. Var C6 does support that too. In OpenTTD the 80+ variables are not directly linked to memory locations like in TTDPatch, and as such they support in some cases higher values, even while that's incompatible with TTDPatch.

[George]

One more problem found. There are different amount of turn stages between turning left and right, and it is different for different direction the train comes from.
I do not suggest to make tiles 15x15 in size but I would like to ask - would be hard to make a var to tell the number of steps before the turn? I mean how many steps (regardless speed) is left before the turn.
I can get almost the same effect by checking the DX and DY between the current wagon and the previous one (the test would be different for different direction of vehicles, making 1+8 checks for every wagon). But if the same result can be achieved with the game engine (that, from my POV should work faster), it would be much better.
Could you provide one more var for that?

[Eddi]

even if this could be done reliably, how do you propose this could deterministically be extended with airport-like state machines which could e.g. decide mid-tile whether to take a turn or go straight depending on a loading bay being occupied? what if the number suddenly changes because e.g. the player hits the "turn around" button?

i'm really not keen on implementing this

[George]

even if this could be done reliably, how do you propose this could deterministically be extended with airport-like state machines which could e.g. decide mid-tile whether to take a turn or go straight depending on a loading bay being occupied? what if the number suddenly changes because e.g. the player hits the "turn around" button?
i'm really not keen on implementing this

This may be a problem for the first engine in the consist, and we can decide to return FF for it. But for all the other engines/wagons it should be always known. And that would be enough to solve my problem.

[Eddi]

hm, that may be possible, i once thought of ways to make state machines useable for articulated vehicles, and one of the ways would be to store the last 8 (minus vehicle shortening property) positions the vehicles had in a shift-register. in each movement step, the last entry would get pushed to the next vehicle in the chain, and only the front vehicle actually interfaces with the state machine (possibly also the last vehicle for reserving/unreserving purposes)

in that case, the position data could get exposed via newgrf variables, each position delta has an x component, an y component, a z component (each +1,0 or -1) and a DirDifference.

but this would be a quite major patch, and would have to be synchronised with NewGRF (air-)ports, which is currently on hold because of its own conceptual state machine troubles.

[George]

hm, that may be possible

Any chance to have it available for testing?

[Eddi]

hm, i don't think so. at least not in the near and probably also not in the medium future.

in theory, you could calculate the turning point from var64, as long as only one turn was inbetween. you know the position and direction of this vehicle and the previous one in map positions, the intersection of these lines is the turning point. throw in a 2-turn (90°) or s-bend test, and you should have most of the common cases covered

[George]

hm, i don't think so. at least not in the near and probably also not in the medium future.
in theory, you could calculate the turning point from var64, as long as only one turn was inbetween. you know the position and direction of this vehicle and the previous one in map positions, the intersection of these lines is the turning point. throw in a 2-turn (90°) or s-bend test, and you should have most of the common cases covered

I know that I can do it with huge NFO code. I hoped for an easy way

[Eddi]

the sense of the patch wasn't really to make the coder's life easier, but to make values avaliable that otherwise wouldn't be. calculating entirely new values is probably out of scope.

[George]

the sense of the patch wasn't really to make the coder's life easier, but to make values avaliable that otherwise wouldn't be. calculating entirely new values is probably out of scope.

I hope you would agree, that checking 1 var instead of calculating it in NFO with about 44 lines of NFO code per vehicle is better solution, which definitely, takes less CPU (calculating value in code is faster, than interpreting the NFO to calculate the same value).

[Eddi]

The possibility to know, that it is the depot / buy menu / vehicle window and return appropriate graphics

I now have a very crude patch that i believe provides this information (bit 0 set in extra callback info 1, if called from GUI)

but it is completely untested, so i need response on whether that really does what it is supposed to do.

Edit: Additional patch that should use the GUI sprite in all appropriate places (vehicle details, vehicle list, etc.)