Heading for grf version 8

[frosch]

Hello,

this is a technical newgrf discussion for developers and grfcoders, not a new suggestion topic for users.

Below you will find a list of suggestions to improve usability and extensibility of certain aspects of newgrf. Some of them are incompatible with the current specs, so the grf version would need bumping to version 8.
Note that the only goal of this topic is to make existing stuff extensible and more useable (in an non-downwards-compatible way). Not to actually add new stuff. (that can be done, when the existing stuff becomes extensible)


1) Vehicle variable 42 field "cc":
Currently: Untranslated cargo.
Proposal: Translated cargo. The translation table of the grf the varaction2 belongs to will be used. 0xFF if the cargo is not part of it. (like var 47)
Grf-Version: Does this need bumping? IMO no, as the current behaviour is not useable at all. The change would fit into version 7. OTOH (according to Dalestan) it is a change, so bump needed.


2) 8 bit callbacks 10 - 14, 16 - 19, 1D, 20 - 21, 27, 36, 142, 14B - 14C:
Note: I do not expect a lot to know about 8 and 15 bit callbacks. So if you do neither, don't bother. This is just about removing the difference. Just comment about the changes wrt. the return values

2a) Extent all callbacks to 15 bit results. I.e. enforce unused bits to be zeroed for future use.
Grf-Version: Bump to version 8 would ensure compatibility with old grfs. But the bump is only useful, when the return values of new newgrfs would have to pass a range-check.

2b) Remove the 0xFF?? downwards-compatibility stuff to support full 15 bit callbacks. (Dalestan's suggestion)
Grf-Version: Bump needed.

Special cases:
2.1) Callback 16: Articulated vehicles
Currently: Bit 0-6 ID, bit 7 reverse flag, 0xFF stop
Proposal 1: Bit 0-13 ID, bit 14 reverse flag, 0x7FFF stop; 0x3F?? and 0x7F?? reserved (Note: 0x7FFF needs 2b))
Proposal 2: Bit 0-6 ID, bit 7 reverse flag, 0xFF stop; 0x7E/0xFE use ID from register 0x100
Grf-Version: Proposal 1 needs bump to version 8, proposal 2 not necessarily. (apart from general 8->15 bit bump)

2.2) Callback 19: Vehicle cargo subtype display
Currently OTTD: 0-0x3FF for texts, except special values 0x??FF
Currently TTDP: 8 bit, i.e. texts 0-0xFE
Proposal 1: Restrict the special value to 0x00FF
Proposal 2: Change the special value to 0x400 (like cb 28)
Grf-Version: IMO no bump needed for proposal 1, as other special values than 0x00FF are unlikely used. (apart from general 8->15 bit bump)

2.3) Callback 1D: Can wagon be attached
Currently OTTD: 0-0x3FF for texts, except special values 0x??FD - 0x??FF
Currently TTDP: 8 bit, i.e. texts 0-0xFE
Proposal 1: Restrict the special values to 0x00FD - 0x00FF
Proposal 2: Change special values to 0x400-0x402 (like cb 28)
Grf-Version: IMO no bump needed for proposal 1, as other special values than 0x00F? values are unlikely used. (apart from general 8->15 bit bump)

2.4) Callback 31, 37: Start/stop check, Industry Cargo sub-type display
Currently: 0-0x3FF for texts, except special values 0x??FF
Proposal 1: restrict the special value to 0x00FF
Proposal 2: Change the special value to 0x400 (like cb 28)
Grf-Version: IMO no bump needed for proposal 1, as other special values than 0x00FF are unlikely used. (apart from general 8->15 bit bump)

2.5) Callback 36: Change vehicle properties
Currently: 8 or 15 bit depending on property
Proposal: 15 bit, though not necessarily extending the allowed range. (apart from general 8->15 bit range check)


3) Boolean callbacks: 13, 17, 18 (partly), 21, 22, 3B, 3C
Currently: Return boolean, i.e. zero or non-zero.
Proposal: Return 0 or 1. Other values reserved.
Grf-Version: Needs bump to version 8


4) Callback 17: House construction check
Currently: Called for one tile, which would be part of the house.
Proposal: Always call for the north tile.
Grf-Version: No bump needed.



So as you might have noticed, there are two proposals for some. Usually one is nearer to the current specs, while the other is more different.

[George]

action 2 for houses and house tiles. Extended version - to allow sprites sharing their bounding box with the GROUND sprite

<Sprite-number> dec A sequential sprite number
<length> dec The total number of bytes used in this action
02 B Defines action 02
07/09 B feature 7=town buildings or 9=industry tiles
set-id B ID for this definition
num-sprites B Number of following building sprites (the groundsprite mustn't be counted). Must not be zero.
groundsprite D Ground sprite for the building (see format below)
-- for sprites sharing their bounding box with the ground sprite
xpixeloffset B x offset from the top left corner of the previous sprite
ypixeloffset B y offset from the top left corner of the previous sprite
80 B a literal 80h byte to distinguish from new-bounding-box definitions
buildingsprite D The sprite to be drawn. Unlike the basic format, zero isn't allowed here.
-- for sprites defining a new bounding box --
xofs B x-offset from northern tile corner (as a signed byte)
yofs B y-offset from northern tile corner (as a signed byte)
zofs B z-offset from the ground
xextent B size of sprite in x direction
yextent B size of sprite in y direction
zextent B size of sprite in z direction
-- for sprites sharing their bounding box with the previous sprite
xpixeloffset B x offset from the top left corner of the previous sprite
ypixeloffset B y offset from the top left corner of the previous sprite
80 B a literal 80h byte to distinguish from new-bounding-box definitions

[DaleStan]

Extended version - to allow sprites sharing their bounding box with the GROUND sprite

That would require that the ground sprite have a bounding box -- something I'm pretty sure is not the case.

[George]

Extended version - to allow sprites sharing their bounding box with the GROUND sprite

That would require that the ground sprite have a bounding box -- something I'm pretty sure is not the case.

I suppose you understand the point - to draw house sign over ground tile. Bounding box does not mean anything here.

[DaleStan]

No, I don't understand the point. If you want to have the ground tile made up of two sprites, just say that and make our lives so very much easier.

[George]

No, I don't understand the point. If you want to have the ground tile made up of two sprites, just say that and make our lives so very much easier.

as usual, you understand it right, but can't show it Yes, you got the point correctly.

P.S. And how hard would it be for you to make TTDP to store GRFs params in the save, as OTTD does?

[onodera]

What about making variable B9 use translated cargo (for callback 15)?

[DaleStan]

P.S. And how hard would it be for you to make TTDP to store GRFs params in the save, as OTTD does?

No. That would require reloading and recompiling all the GRFs on game load, and we no longer have the necessary access to malloc.

What about making variable B9 use translated cargo (for callback 15)?

And also no. In the first case there are about ten different variable B9s, and you failed to specify which one. And in the second place, all 80+x variables are direct memory access. You get whatever happens to be stored there. If you want processing, you use the 40+x or 60+x that has been provided for that purpose.

[Rubidium]

I'd like to propose to store the palette used to encode the NewGRF. For the authors it would probably easiest if it could be added automatically, although it could also be a byte in the Action 8.

As long as it's possible to determine the palette of the NewGRF so OpenTTD can load the right palette conversion algorithm.

[DaleStan]

GRFCodec cannot do this, as it may be given a PCX with a palette it does not recognize. The coders demonstrably won't -- the ability to check the host's desired palette has been present since dinosaurs roamed the earth, but I can't name a single GRF that uses that feature.


Check the real sprites for pixels that, in the Windows palette, are magic pinks. If any exist in a sprite containing colors other than 0, 1, and 2, assume DOS.

[George]

I'd like to suggest to change RV property 10 (Cargo type, see column 3 (type B) in CargoTypes) to be translation table entry number

[peter1138]

And why not all the cargo type propery for all vehicle types that have one?

[maquinista]

My suggestion: some support for electric and diesel locomotives, different running cost with electrified and not electrified track, different speeds... This could be done with callbacks, but I prefer variables of action 0 variables.
Also, It would be cool supporting (with Action 0 or callbacks) trains with Variable gauge axle. In Spanish set there are some trains with this feature, but They only can run in only one track type (maglev tracks are used as high speed lines with a replacement GRF for tracks). Also, these trains have different speeds, but this is less important.

In game this would be something like this:

Code: Select all

high speed tracks    conventional tracks
===================-----------------

[DaleStan]

this is a technical newgrf discussion for developers and grfcoders, not a new suggestion topic for users.

Specifically, if you don't know for a fact that implementing your suggestion would require a new GRF version, then get out.

[George]

And why not all the cargo type propery for all vehicle types that have one?

that's correct. All of them

[George]

What do you think about having callback 3D for vehicles too? Instead of property 16 for RVs for example?
This way it would be possible to have a better control of refit list. Value 1 would mean refitable, value 0 not. Of cause TT rule should be applied: "The lowest byte of var. 18 contains the ID of the cargo. If your GRF has a cargo translation table installed, you will get the index from that table"

P.S. I'm not sure if it requires GRFv8 or not

[frosch]

Hmm, duplicated request, so I have to answer here too.

Just a few days ago I decided against allowing callbacks to decide whether refitting is allowed.

(...)
-Fix [FS#2617]: When articulated parts have no available default cargo, use the cargo type of the first part for livery selection.
-Change: To decide whether a vehicle is refittable do not test its current capacity for being zero, but always use the 'capacity property'.
Note: The property is used unmodifed without calling CB 15/36. By setting it to a non-zero value and returning zero in the callback vehicles can be refitted to/from zero capacity for e.g. livery effects.
Note: It is intentional that you cannot control refittability by CB 36.

IMO that is: No way.

I explicitly excluded the ability to refuse refitting in r15541.
If this would be added, it would only be a matter of time until some grf restricts refitting to certain cargo types to certain dates or other circumstances. That would break cloning, autoreplace, autorenew, ... I.e. every gameplay feature related to vehicles.

[andythenorth]

IMO that is: No way.

I explicitly excluded the ability to refuse refitting in r15541.
If this would be added, it would only be a matter of time until some grf restricts refitting to certain cargo types to certain dates or other circumstances. That would break cloning, autoreplace, autorenew, ... I.e. every gameplay feature related to vehicles.

Good decision. From the point of view of designing a set, it's also helpful to have certain options *not* available. It means fewer decisions, less thinking, and fewer player requests for features to deal with.

[George]

IMO that is: No way.
I explicitly excluded the ability to refuse refitting in r15541.
If this would be added, it would only be a matter of time until some grf restricts refitting to certain cargo types to certain dates or other circumstances. That would break cloning, autoreplace, autorenew, ... I.e. every gameplay feature related to vehicles.

Good decision. From the point of view of designing a set, it's also helpful to have certain options *not* available. It means fewer decisions, less thinking, and fewer player requests for features to deal with.

Well, then I need prop 16 to be 8D, not D (this would require GRF version 8 ) to cover all the translation table.

P.S. And when I try to clone vehicle, that is no longer represented in the stock, I get the error massage. Why can't the same be done for the case when I can't clone vehicle because of CB result?

[DaleStan]

Well, then I need prop 16 to be 8D, not D to cover all the translation table.

No, that means you need to choose a better translation table order or you need to think harder about props 1D/1E.