Coding newcargo compatibility

[Oracle]

I'm currently looking at improving the US Set's newcargo compatibility with other industry sets, and am not finding it easy, since cargo sets were fairly new last time I was looking at this (back in 2007) and I don't really know what's been changed since then, and how others have implemented newcargos in their sets. If anyone can give advice on the following (or related topics) then I would greatly appreciate it.

• How many commonly-used newcargo sets are there at present?
• Do sets generally use explicit specification with refit masks or cargo classes to handle newcargos? (I think I know the answer is refit masks but I'd appreciate clarity.)
• Do you check for newcargo sets using GRFIDs or other methods?
• How do you handle the possibility of multiple cargo sets being used?

All advice is gratefully received!

[OzTrans]

...

[PikkaBird]

OzTransLtd's approach (not using cargo classes, checking GRFIDs, having multiple CTTs) is rather eccentric and much more complex than it needs to be.

My advice would be to use cargo classes, and use them generously; make sure there's always at least one vehicle which can carry bulk, liquid, piece, etc, with no prop 29 restrictions. That will make your set compatible with practically all current and future cargo grfs. After you've created a general scheme with cargo classes, you can use the CTT and refit mask to refine things, to allow/disallow specific cargos or select cargo-specific graphics.

[andythenorth]

I would also add that FIRS has a *lot* of cargos, and it was never my intention that sets should provide graphical support for them. I know what it's like providing detailed graphics for every cargo, I don't enjoy it as coder or when drawing

Therefore nearly all of the FIRS cargos can be stuck in a box car, a tank car, or in crates on a flat or gondola.

The only special request I'd have is the heavy machinery cars should *definitely carry the three 'xxx Supplies' cargos. I pretty much had US Set in mind when I invented Engineering Supplies

cheers,

Andy

[PikkaBird]

Oh, also: Action 7 conditions 0B and 0C can be useful to check if a cargo is defined. I use this for the livestock cars in NARS, for example, rather than assuming there is livestock only in temperate and arctic.

Code: Select all

12120 * 9	 07 83 04 \7C "LVST" 01  // skip 1 if lvst is defined
12121 * 7	 00 00 01 01 1F 06 00    // deactivate car (climate = 0)

[Zephyris]

It depends how "detailed" you want the support to be; eGRVTS/GRVTS uses a method which is about as simple as possible - a cargo translation table, cargo class definition of compatible cargoes for each vehicle and graphics only for the original cargo types.

[Oracle]

Thank you all for the advice. PikkaBird's advice about having at least one vehicle able to carry each cargo class sounds extremely sensible, for future compatibility. I have two more questions that aren't quite clear from the documentation though:

- If a cargo in my translation table isn't defined, then am I right to assume that that bit has no effect?
- If I change the translation table, will it mess up saved games? (In other words, should I change the GRFID if I change the translation table?)

Thanks again!

[OzTrans]

...

[andythenorth]

This HEQS road vehicle shouldn't be built unless steel (STEL) is available as a cargo.

I've adapted the code Pikka posted above (changed action 0 to suit road vehicles), but it doesn't appear to work. What might I have done wrong?

Code: Select all

 -1 * 67	 00 01 1A 01 C1
    00 \w1-1-1920     // intro date
    02 20             // reliability decay speed
    03 \b35           // vehicle life
    04 19             // class life
    06 0F             // climate availability - use 0F for all, 00 none (to hide vehicle)
    07 05             // load amount
    08 \b77           // speed in mph * 3.2
    09 50             // running cost factor
    0A 48 4C 00 00    // running cost base
    0E FF             // sprite ID
    0F 00             // capacity
    10 09             // cargo type 
    11 5D             // cost factor
    12 19             // sound effect
    13 \b55           // power in 10 hp
    14 \b96           // weight in 1/4 tons
    15 \b19           // speed in mph * 0.8
    16 00 02 06 00    // Bit mask of cargo types available for refitting
    // flips 1D / 1E values: excludes grain, wheat, maize
    17 16             // Callback flags bit mask
    18 49             // coefficient of tractive effort (reduced for articulated mining truck with only 1 powered axle)
    1A 00             // Refit cost, using 25% of the purchase price cost base
    1B 00             // Retire vehicle early, this many years before the end of phase 2
    1C 02             // Miscellaneous vehicle flags
    1D 00 00          // Refittable cargo classes
    1E 00 00          // Non-refittable cargo classes
    1F 72 EC 0A 00    // Long format introduction date
-1 * 9    07 83 04 \7C "STEL" 01  // skip 1 if cargo is defined
-1 * 7    00 01 01 01 C1  06 00    // deactivate vehicle (climate = 0)

[Zephyris]

Nothing looks obviously wrong to me, though it has been a while since I have coded! A good bug-test would be to recode the logic in reverse. ie. start with the vehicle not available in any climates and if steel is defined then make it available in all climates. Sorry I cant be more help!

[OzTrans]

...

[andythenorth]

The problem could be, STEL is a TTO cargo type, that gets defined by the patch in temperate anyway and in turn checking it via \7C will always return true.

It seems to be that STEL is also defined in the other climates, or my code is just wrong. Hmm.

[UPDATE]. Resolved this. If the default cargo type is changed to FF, the cargo-dependent code works (and refit mask handles providing default cargo).

But, you do have a problem with the action-0 property 10 (cargo type). Steel is a temperate cargo, you can only set property 10 to 09 for temperate. In arctic and sub-tropical you need to use FF and let STEL be refittable via cargo class or refit mask. Otherwise, you'll get paper and water respectively.

Yep, I do get paper / water as you indicated. Hopefully I can find a way to turn off the vehicle if steel is not defined by a newgrf in those climates. [NOW WORKS]

Refitting works ok far as I know - the mask is defined against the HEQS translation table and appears to work

And, what about capacity ? It is set to zero.

Tractor unit of an articulated RV...no cargo carried

[George]

OzTransLtd's approach (not using cargo classes, checking GRFIDs, having multiple CTTs) is rather eccentric and much more complex than it needs to be.
My advice would be to use cargo classes, and use them generously; make sure there's always at least one vehicle which can carry bulk, liquid, piece, etc, with no prop 29 restrictions. That will make your set compatible with practically all current and future cargo grfs. After you've created a general scheme with cargo classes, you can use the CTT and refit mask to refine things, to allow/disallow specific cargos or select cargo-specific graphics.

Agree with Pikka!
I use one CTT for all the sets and landscapes. Like this

Code: Select all

  197 * 1018	 00 08 01 FD 00 09 "DYES" "STEL" "RUBR" "VEHI" "COPR" "WOOD" "TWOD" "WDPR" "BRCK"
                 "CMNT" "FICR" "TOYS" "BATT" "SWET" "BUBL" "FZDR" "FERT" "__11" "__12" "__13" "__14"
                 "__15" "__16" "__17" "__18" "__19" "__1A" "__1B" "__1C" "__1D" "__1E" "__1F" "PASS"
                 "MAIL" "GOOD" "TOUR" "__24" "__25" "__26" "__27" "__28" "__29" "__2A" "__2B" "__2C"
                 "__2D" "__2E" "__2F" "COAL" "WATR" "SAND" "GLAS" "VALU" "GOLD" "DIAM" "CERA" "__38"
                 "__39" "__3A" "__3B" "__3C" "__3D" "__3E" "__3F" "OIL_" "POTA" "DYES" "RFPR" "PETR"
                 "SULP" "__46" "__47" "__48" "__49" "__4A" "__4B" "__4C" "__4D" "__4E" "__4F" "IORE"
                 "CORE" "STEL" "PLAS" "RUBR" "VEHI" "COPR" "__57" "__58" "__59" "__5A" "__5B" "__5C"
                 "__5D" "__5E" "__5F" "WOOD" "TWOD" "PAPR" "WDPR" "__64" "__65" "__66" "__67" "__68"
                 "__69" "__6A" "__6B" "__6C" "__6D" "__6E" "__6F" "BRCK" "CMNT" "LIME" "CLAY" "GRVL"
                 "__75" "__76" "__77" "__78" "__79" "__7A" "__7B" "__7C" "__7D" "__7E" "__7F" "LVST"
                 "CERE" "GRAI" "WHET" "MAIZ" "FOOD" "FRUT" "FISH" "WOOL" "FERT" "OLSD" "FICR" "__8C"
                 "__8D" "__8E" "__8F" "SUGR" "TOYS" "BATT" "SWET" "TOFF" "COLA" "CTCD" "BUBL" "PLST"
                 "FZDR" "__9A" "__9B" "__9C" "__9D" "__9E" "__9F" "__A0" "__A1" "__A2" "__A3" "__A4"
                 "__A5" "__A6" "__A7" "__A8" "__A9" "__AA" "__AB" "__AC" "__AD" "__AE" "__AF" "__B0"
                 "__B1" "__B2" "__B3" "__B4" "__B5" "__B6" "__B7" "__B8" "__B9" "__BA" "__BB" "__BC"
                 "__BD" "__BE" "__BF" "__C0" "__C1" "__C2" "__C3" "__C4" "__C5" "__C6" "__C7" "__C8"
                 "__C9" "__CA" "__CB" "__CC" "__CD" "__CE" "__CF" "__D0" "__D1" "__D2" "__D3" "__D4"
                 "__D5" "__D6" "__D7" "__D8" "__D9" "__DA" "__DB" "__DC" "__DD" "__DE" "__DF" "__E0"
                 "__E1" "__E2" "__E3" "__E4" "__E5" "__E6" "__E7" "__E8" "__E9" "__EA" "__EB" "__EC"
                 "__ED" "__EE" "__EF" "__F0" "__F1" "__F2" "__F3" "__F4" "__F5" "__F6" "__F7" "__F8"
                 "__F9" "__FA" "__FB" "__FC"

Entries like "__xx" are unused, first 32 are for "special cargoes", others are working well with cargo classes
This way I support ECS, PBI.