Transport Tycoon Forums

andythenorth wrote:George - sorry, think you're wrong about Plastic. I'm not going to screw around giving players *broken industry chains* just to keep the vehicle graphics tidy. *If* that's what you're implying - that's how I read your point anyway. True apologies if I've misunderstood you.

The idea is to separate liquid and not liquid plastic for Vehicles set.


As for wrong chains - shouldn't the sets use the same bit if they intend the same cargo (same name) with different label? IMHO it would the best way for GRF coder to do.

From this point of view, the old ECS mistake with swapping FOOD and PAPER is thing to fix I should change it in ECS while changing from ECS v1 to ECS v2.

George wrote:shouldn't the sets use the same bit if they intend the same cargo (same name) with different label?

What do you mean by "bit"? If you mean prop 08, then how does this help GRFs that use a cargo translation table?

George wrote:

wallyweb wrote:

George wrote: http://bugs.openttd.org/task/2553#comment6383

Hmmm ... this bug would seem to be related to vehicle length and not cargo refitting.

sorry, this one http://bugs.openttd.org/task/2673

Now that makes good sense. Unfortunately it appears to be implemented in OTTD and not in TTDPatch.

DaleStan wrote:

George wrote:shouldn't the sets use the same bit if they intend the same cargo (same name) with different label?

What do you mean by "bit"? If you mean prop 08, then how does this help GRFs that use a cargo translation table?

It would prevent 2 cargoes with the same name to appear in one game, wouldn't it?

Okay, I'm going to put these suggestions, moving forward.

1) Vehicles should get a new, 64 bit length property for allowed cargos. If this property is set, then the current refit bitmask becomes a (64 bit?) disallowed cargos mask. If this property is not set, the current refit bitmask stays as a 32 bit XOR mask.

2) Cargo type B should be deprecated, and its use in action 0s be replaced by the cargo translation table / cargo type A. The defining element of a cargo should be the ID (within a grf) and the label (across grfs).

3) In the meantime, GRF creators should make it a habit to check if a cargo is already defined (using action 7/9/D) before redefining it. This avoids the situation George describes where the same cargo is defined twice with a different bit. Using GRM to check/reserve cargo bits is also a good idea (but would be unnecessary if suggestion 2 was enacted).

George wrote:

DaleStan wrote:

George wrote:shouldn't the sets use the same bit if they intend the same cargo (same name) with different label?

What do you mean by "bit"? If you mean prop 08, then how does this help GRFs that use a cargo translation table?

It would prevent 2 cargoes with the same name to appear in one game, wouldn't it?

First, that's an impossible task. What happens if someone wants to support both Copper Ore (TTD Cargo, bit 0E) and Fish (ECS cargo, bit 0E)?
Second, are you quite sure it's "same bit", and neither "same ID" (type B) nor "same bit and ID"? Not that any of the three options makes this task any less impossible.

PikkaBird wrote:1) Vehicles should get a new, 64 bit length property for allowed cargos. If this property is set, then the current refit bitmask becomes a (64 bit?) disallowed cargos mask.

No property's size may depend on the settedness of another property. A 64+32 bit property, where the 32 is the high 32 of the 64-bit allowed mask, is possible, but I think I'd prefer either two 64-bit properties or one 64+64 property, overriding the current 32-bit mask.
I think. I'll have to think about the unpleasant side-effects, unpleasant NFO-stupidity, and what (if anything) can be done to prevent/mitigate them.

PikkaBird wrote:2) Cargo type B should be deprecated, and its use in action 3 ...

The wiki suggests that type B is not used in action 3.

DaleStan wrote:

PikkaBird wrote:2) Cargo type B should be deprecated, and its use in action 3 ...

The wiki suggests that type B is not used in action 3.

Er, yes, sorry. Vehicle Property 15/10/0C.

Well, I changed my opinion towards george's suggestion in FS#2673, as it won't cause more trouble as is already present for articulated vehicles. And in the mean time there is an error message blaming newgrfs

So I also prefer a callback over a new property:

Vehicle callback 14E (no activation bit):
Called in purchase/refit list and on construction/refitting for every available cargotype, i.e. up to 32 times. (Will need some caching for the gui, to be specified later)
Var 10: Cargo label
Var 18: Bit 0-15 Cargo class, 16-31 reserved

Result:
Callback failed: Use the old 3 properties
Result bits 0-7:
0 = not refittable
1..255 = refittable; the cargo returning the highest number (first wins) will become the default cargo
Result bits 8-14: reserved

That should solve the problems with type-B-cargo as default and refitmask being limited to first 32 items of cargo translation table.

Maybe the cargo label in var 10 is a bit over the top, and the type-A-cargo would be enough.

frosch wrote:Vehicle callback 14E

Sounds good.

frosch wrote:Maybe the cargo label in var 10 is a bit over the top, and the type-A-cargo would be enough.

Type-A-cargo should == the position of the label in the grf's cargo translation table, so there's no real benefit to one over the other. Returning the number rather than the label would be more consistent with other action 2s, and would allow for checking ranges rather than one label at a time.

fine, ranges are a good reason to use type-A

so
Var 10:
Bit 0-7 type A
Bit 8-15 reseved
Bit 16-31 cargoclasses

Var 18: reserved

frosch wrote:(Will need some caching for the gui, to be specified later)

Since this is logically a static property, just one that happens to be too hard to specify in an action 0, I think appropriate real-vehicle cache time is "as long as possible without causing desyncs". So, call at vehicle construction, game load, and multiplayer-join.
On the other hand, it is called from the purchase list too, so if someone has a very good reason why this should non-static, we can think about other solutions.

Purchase-list cache time might be "until another vehicle is selected"? I'm not sure how hard that would be, except that I am sure that information would have to be attached to the window.

EDIT: Actually, we only need this in the GUI; it doesn't have to hang around after the window closes. So scratch the per-vehicle storage, I'd say.

I am not sure, how static that value shall be. The complete refit mask is only needed in a few places.

But after looking at the code, maybe the "default cargo" type should be slightly more static. It is needed a lot more often; and esp. in a lot more complicated cases. E.g. a vehicle not able to carry any cargo is not available to players (except train engines).

That would suggest to only call the callback on engine introduction (for both default cargo and refit mask, to keep them consistent) and maybe once a year, and store it for the rest of the game (in the savegame; so it survives joining and loading of newgrfs)

Edit:
In any case storing per buildable engine instead of per vehicle should be sufficient. I.e. the callback would only be called "in the purchase list" wrt. action3.

Edit2:
Hmm, as vehicle can also get refitted by orders, and breaking orders is - uhm - gamekilling. Maybe only call the callback on engine introduction resp. gamestart.
(Maybe I just forgot why I disliked the original FS task )

frosch wrote:18 of Aug, 2009[23:55] frosch TWOD is no default cargo

Are you sure? I thought it is default label, defined by TTDPatch for wood in tropics. And I supposed it should be the same in OTTD.

According to the source there are three climates that contain WOOD, and none that contain TWOD. (Guess which commands I ran just as soon as I saw frosch's edit.)

patches/grfinit.asm:950, BTW, is (with some prepended whitespace)

Hehe, guess which commands I ran just before that edit

Btw. I left the comments about the climates in the row for "WOOD".
So if noone knows where "TWOD" originates from, those comments maybe should be removed, too.

frosch wrote:Hehe, guess which commands I ran just before that edit
Btw. I left the comments about the climates in the row for "WOOD".
So if noone knows where "TWOD" originates from, those comments maybe should be removed, too.

TWOD was my suggestion to one of TTDP devs (can't remember whom) to show the higher price of wood in tropic (and make vehs have smaller or larger capacity because of that). It was acceped and stated as done, but I never had the idea to test it, while LV set provided support for TWOD labelled cargo.

Well, I have some patch for more than a week. As I haven't yet created a testgrf myself, maybe someone else would like to volunteer for that

Details for callback 0x14E:
Called on game start for every engine for every cargo (up to 32 times per engine).
The callback is called like a purchase-list callback. So you cannot access most variables, nor variables of the related vehicle.
Variable 10: Bits 0-7 cargo type A; 8-15 reserved, mask out; 16-31 cargo classes.
Variable 18: Reserved
Return value: Bits 0-7 Priority, Bits 8-14 reserved, set to zero

If the engine is not refittable for a cargo, return priority 0. Else the returned value will specify which cargo will become the default cargo. The highest priority wins. If two cargos get the same priority, the first one will be choosen.
If the callback fails, the usual properties "include classes", "exclude classes" and "xor-mask" define the refittability for that cargo. The callback will be called for all cargos nevertheless.

Pitfall:
If you return 0 ("not refittable") or fail for all cargos, the "default cargo" property will take effect. So better set it to 0xFF ("first refittable"), else you might end up with a vehicle carrying an unexpected cargo.

frosch wrote:Hmm, as vehicle can also get refitted by orders, and breaking orders is - uhm - gamekilling.

Actually, isn't breaking refit orders already possible, by returning 0 from the refit callback? Or does zero have a meaning I've forgotten in that context?