Define result of failed var 0x7E procedure calls

[Hirundo]

Background
In NFO, it is possible to perform subroutine calls using varaction2 variable 7E. See the link below for the current specification.
http://newgrf-specs.tt-wiki.net/wiki/Va ... procedures
If the called varaction2 does not end with a callback result (but with a real action2), the result is currently undefined.
This blocks certain features in NML, or at least makes coding them significantly harder. I won't delve into details here, as a detailed explanation / example is somewhat complicated.

Proposal
I propose to change the result of a 'failed' procedure call from undefined to 0xFFFF. This is not a valid callback result, these are limited to 15 bits.
So, it's possible to reliably distinguish a failed result inside the calling varaction2 and act accordingly

This is equivalent to the current situation in OpenTTD.
TTDP currently provides a semi-random result. Attached patch changes this, so it returns 0xFFFF as well.

Since the result is currently undefined, this change should not cause any compatibility issues.

[Yexo]

I propose to change the result of a 'failed' procedure call from undefined to 0xFFFF. This is not a valid callback result, these are limited to 15 bits..

This is unfortunatly not true. With the "nvar == 0" trick the called action2 can return a full 32bits.

[Hirundo]

I propose to change the result of a 'failed' procedure call from undefined to 0xFFFF. This is not a valid callback result, these are limited to 15 bits..

This is unfortunatly not true. With the "nvar == 0" trick the called action2 can return a full 32bits.

Callback results returned that way are still limited to 15 bits. Whether that's a good thing or not can be left open for debate.
See newgrf_spritegroup.cpp:177 for OpenTTD or the attached patch for TTDPatch.

[DaleStan]

Hirundo is correct. Var 1C may contain a full 32 bits, but the result itself is clamped to 15 bits. The only special thing the result can do with nvar==0 is contain the values 7F00-7FFF. (Which, if encoded as 00 FF through FF FF, would be interpreted as old-style callback results of 00-FF.) See also the documentation.

I can't say I understand how "don't do that then" is any harder in NML than it wold be in GrfMaker or NFO, but the patch looks fine to me. I'll try to shove it in sometime this weekend.

[andythenorth]

I'll try to shove it in sometime this weekend.

(Off topic)

/me waves at DaleStan -> you are missed!

[Yexo]

Hirundo is correct. Var 1C may contain a full 32 bits, but the result itself is clamped to 15 bits.

Indeed, I realized that after a quick discussion on IRC.

The only special thing the result can do with nvar==0 is contain the values 7F00-7FFF. (Which, if encoded as 00 FF through FF FF, would be interpreted as old-style callback results of 00-FF.) See also the documentation.

Could you please clarify when TTDPatch interprets a result as "old-style callback result"? OpenTTD only checks for bit 15: bit 15 set => callback result, bit 15 not set => reference to other (var)action2.
Although I've heard about the old-style callback result with 0xFF as high-byte instead of only bit 15 set, I can't find any reference to it in the documentation. As for OpenTTD code, the only references I could find to it is that bits 8..14 are ignored for some callbacks, but that doesn't include procedure calls.

[DaleStan]

Although I've heard about the old-style callback result with 0xFF as high-byte instead of only bit 15 set, I can't find any reference to it in the documentation. As for OpenTTD code, the only references I could find to it is that bits 8..14 are ignored for some callbacks, but that doesn't include procedure calls.

Way back in the old days of ... alpha 39, as it turns out:

For compatibility with earlier patch versions, FF in the high byte is taken to mean the same thing as 80, so 04 FF also has a callback result of 4. Note that if your grf file needs to be compatible with versions before TTDPatch 2.0.1 alpha 40, you must set the high byte to FF, and so can use only 8 bit results.

In the absence of documentation to the contrary, and supported by vague memories (but no search results, unfortunately), I assume this applies to all callback results, as I expect that neither callback processor knows at the time whether it's resolving a procedure call or returning a regular result.

[Yexo]

Thanks for that link and your explanation. This means there is a difference in behaviour between TTDPatch and OpenTTD.

Edit: and I've been proven wrong for a second time in this very topic. Thanks frosch . It turns out that OpenTTD actually behaves exactly the same, I just missed the part of the code that did it.

[DaleStan]

Committed to TTDPatch in r2367, but I can't log in to the tt-wiki, so I didn't update the specs.

[planetmaker]

Committed to TTDPatch in r2367, but I can't log in to the tt-wiki, so I didn't update the specs.

It uses your tt-forums login (and not the former ttdpatch-wiki's login).

EDIT: added info to wiki

[Hirundo]

Thanks for taking your time to review and commit this, DaleStan.