Heading for grf version 8
Moderator: Graphics Moderators
Heading for grf version 8
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.
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
- Tycoon
- Posts: 4362
- Joined: 16 Apr 2003 16:09
- Skype: george-vb
- Location: Varna, Bulgaria
- Contact:
Re: Heading for grf version 8
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
<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
Re: Heading for grf version 8
That would require that the ground sprite have a bounding box -- something I'm pretty sure is not the case.George wrote:Extended version - to allow sprites sharing their bounding box with the GROUND sprite
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
- George
- Tycoon
- Posts: 4362
- Joined: 16 Apr 2003 16:09
- Skype: george-vb
- Location: Varna, Bulgaria
- Contact:
Re: Heading for grf version 8
I suppose you understand the point - to draw house sign over ground tile. Bounding box does not mean anything here.DaleStan wrote:That would require that the ground sprite have a bounding box -- something I'm pretty sure is not the case.George wrote:Extended version - to allow sprites sharing their bounding box with the GROUND sprite
Re: Heading for grf version 8
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.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
- George
- Tycoon
- Posts: 4362
- Joined: 16 Apr 2003 16:09
- Skype: george-vb
- Location: Varna, Bulgaria
- Contact:
Re: Heading for grf version 8
as usual, you understand it right, but can't show it Yes, you got the point correctly.DaleStan wrote: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.
P.S. And how hard would it be for you to make TTDP to store GRFs params in the save, as OTTD does?
Re: Heading for grf version 8
What about making variable B9 use translated cargo (for callback 15)?
It's a nodding donkey in my avatar, not me! I'm an oil rig.
Re: Heading for grf version 8
No. That would require reloading and recompiling all the GRFs on game load, and we no longer have the necessary access to malloc.George wrote:P.S. And how hard would it be for you to make TTDP to store GRFs params in the save, as OTTD does?
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.onodera wrote:What about making variable B9 use translated cargo (for callback 15)?
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Re: Heading for grf version 8
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.
As long as it's possible to determine the palette of the NewGRF so OpenTTD can load the right palette conversion algorithm.
Re: Heading for grf version 8
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.
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.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
- George
- Tycoon
- Posts: 4362
- Joined: 16 Apr 2003 16:09
- Skype: george-vb
- Location: Varna, Bulgaria
- Contact:
Re: Heading for grf version 8
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
Re: Heading for grf version 8
And why not all the cargo type propery for all vehicle types that have one?
He's like, some kind of OpenTTD developer.
-
- Tycoon
- Posts: 1828
- Joined: 10 Jul 2006 00:43
- Location: Spain
Re: Heading for grf version 8
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:
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
===================-----------------
Sorry if my english is too poor, I want learn it, but it isn't too easy.
- [list][*]Why use PNG screenshots in 8 bpp games.
[*]Caravan site New Industry. · Spain set. · Some spanish trains for locomotion[*]Favourites:GRVTS · ECS · FIRS
Re: Heading for grf version 8
Specifically, if you don't know for a fact that implementing your suggestion would require a new GRF version, then get out.frosch wrote:this is a technical newgrf discussion for developers and grfcoders, not a new suggestion topic for users.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
- George
- Tycoon
- Posts: 4362
- Joined: 16 Apr 2003 16:09
- Skype: george-vb
- Location: Varna, Bulgaria
- Contact:
Re: Heading for grf version 8
that's correct. All of thempeter1138 wrote:And why not all the cargo type propery for all vehicle types that have one?
- George
- Tycoon
- Posts: 4362
- Joined: 16 Apr 2003 16:09
- Skype: george-vb
- Location: Varna, Bulgaria
- Contact:
Re: Heading for grf version 8
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
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
Re: Heading for grf version 8
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.
Just a few days ago I decided against allowing callbacks to decide whether refitting is allowed.
r15541 wrote:(...)
-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.
frosch in fs#2673 wrote: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
- Tycoon
- Posts: 5658
- Joined: 31 Mar 2007 14:23
- Location: Lost in Music
Re: Heading for grf version 8
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.frosch wrote:frosch in fs#2673 wrote: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.
FIRS Industry Replacement Set (released) | HEQS Heavy Equipment Set (trucks, industrial trams and more) (finished)
Unsinkable Sam (ships) (preview released) | CHIPS Has Improved Players' Stations (finished)
Iron Horse ((trains) (released) | Termite (tracks for Iron Horse) (released) | Busy Bee (game script) (released)
Road Hog (road vehicles and trams) (released)
Unsinkable Sam (ships) (preview released) | CHIPS Has Improved Players' Stations (finished)
Iron Horse ((trains) (released) | Termite (tracks for Iron Horse) (released) | Busy Bee (game script) (released)
Road Hog (road vehicles and trams) (released)
- George
- Tycoon
- Posts: 4362
- Joined: 16 Apr 2003 16:09
- Skype: george-vb
- Location: Varna, Bulgaria
- Contact:
Re: Heading for grf version 8
Well, then I need prop 16 to be 8D, not D (this would require GRF version 8 ) to cover all the translation table.andythenorth wrote: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.frosch wrote:frosch in fs#2673 wrote: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.
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?
Re: Heading for grf version 8
No, that means you need to choose a better translation table order or you need to think harder about props 1D/1E.George wrote:Well, then I need prop 16 to be 8D, not D to cover all the translation table.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Who is online
Users browsing this forum: No registered users and 27 guests