Difference between revisions of "Callback: Custom cargo production"
m (Bot: Automated text replacement (-variational action 2 +VarAction2)) |
(→Custom cargo production (2E): Link to house production algorithm description on Action0/Houses page.) |
||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 7: | Line 7: | ||
During the callback, the lowest byte of variable 10 contains the number of iterations happened so far and variable 18 contains a |
During the callback, the lowest byte of variable 10 contains the number of iterations happened so far and variable 18 contains a |
||
random value to help randomizing the production. (The old code randomizes production to make it look more natural, you can do the |
random value to help randomizing the production. (The old code randomizes production to make it look more natural, you can do the |
||
| + | same via a VarAction2 with nvar=0). Original passenger/mail generation algorithm is described [[Action0/Houses#Population_.280B.29_and_Mail_generation_multiplier_.280C.29|here]]. |
||
| − | same via a VarAction2 with nvar=0) |
||
| ⚫ | |||
| − | This is how the original passenger generation is done: In each periodic processing (i.e. every 256 ticks), a random value 0<=X<=255 |
||
| − | is generated for each house tile. If X isn't smaller than the population of the tile, no passengers are generated. Otherwise, X/8+1 |
||
| − | passengers are generated (rounded down). If there is a recession going on, the number of generated passengers is halved, but this |
||
| − | division gets rounded up instead of down. Mail generation happens in a similar manner, but with a new random value, and checking |
||
| − | against the mail generation multiplier instead of the population. |
||
| ⚫ | |||
| ⚫ | |||
| − | |||
| ⚫ | |||
cargo slot number, you have to return a climate-independent cargo ID. If your GRF has a cargo translation table, then this ID |
cargo slot number, you have to return a climate-independent cargo ID. If your GRF has a cargo translation table, then this ID |
||
is the index in that table; otherwise, it's the cargo bit. Trying to produce a cargo not currently present is not an error, but will be ignored. |
is the index in that table; otherwise, it's the cargo bit. Trying to produce a cargo not currently present is not an error, but will be ignored. |
||
Latest revision as of 12:00, 31 August 2014
Custom cargo production (2E)
This callback can be used to customize cargo production of house tiles. It is called every 256 ticks when the tile can produce cargo. Because a tile can produce many types of cargo, this callback is called in a loop until it returns 20FFh (the loop count is limited to 256 to avoid endless loops). If the returned value is not 20FFh, the high byte must be a cargo type and the low byte must be the amount to be distributed. You can return a cargo type more than once if needed, so you can distribute more than 255 units from it. During the callback, the lowest byte of variable 10 contains the number of iterations happened so far and variable 18 contains a random value to help randomizing the production. (The old code randomizes production to make it look more natural, you can do the same via a VarAction2 with nvar=0). Original passenger/mail generation algorithm is described here.
Uses 15 return bits.
GRFv≥7 From GRF version 7 and above, the interpretation of the high byte in the returned value changes: instead of a climate-dependent cargo slot number, you have to return a climate-independent cargo ID. If your GRF has a cargo translation table, then this ID is the index in that table; otherwise, it's the cargo bit. Trying to produce a cargo not currently present is not an error, but will be ignored.
