Heading for grf version 8

[George]

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.

Unfortunately, thinking about props 1D/1E is not a good idea, because vehicle sets and cargo sets are independent. So, from the point of view of vehicle set, cargo classes are predefined, and, in general, can be considerated unknown. For example, do you know, what class would fertiliser get in some new cargo set? I can't.
From this point of view, moving problematic cargoes to the first 32 entries in the table does not solve the problem - any cargo can become problematic.

Hope, you understand the problem?

P.S. My problematic cargo list
1-st query
0"WOOL" (piece to express)
1"RUBR" (liquid to piece)
2"CMNT" (bulk to piece)
3"FERT" (liquid to bulk)
4"DYES" (liquid to express)
5"CERA" (piece to express)
6"LVST" (different / piece to express)
7"FZDR" (piece to express)
8"GLAS" (piece to express)
2-nd query (piece 1-2)
9"STEL"
A"PLAS"
B"VEHI"
C"COPR"
D"WOOD"
E"TWOD"
F"PAPR"
10"WDPR"
11"BRCK"
12"FICR"
13"TOYS"
14"BATT"
15"CTCD"
16"BUBL"
17"PLST"

I have only 8 slots left! That's too little! I need some solution!

P.P.S. BUBL goes to 1-st query

[peter1138]

Here's a slight change on the idea that requires absolutely no GRF changes. Cargo types as used in Action 3 are already translated, so we could therefore say that any (valid) cargo type used in Action 3 for a vehicle will automatically be added to the vehicle's refit list.

[George]

Here's a slight change on the idea that requires absolutely no GRF changes. Cargo types as used in Action 3 are already translated, so we could therefore say that any (valid) cargo type used in Action 3 for a vehicle will automatically be added to the vehicle's refit list.

Unfortunately, vehicle also can transport unknown cargo according to its' cargo class.

[peter1138]

I didn't suggest removing cargo classes, though.

[George]

I didn't suggest removing cargo classes, though.

but with your suggestion a cargo, that is not represented in the table, would not be supported by action 3 and because of that can't be transported (no refit is available). At least I understood your suggestion as action 3 cargoes list being a refit list.

[peter1138]

No. Where did I suggest that properties 1D/1E (as we're talking of road vehicles) should be removed?

[DaleStan]

I still can't figure out why more refit control is beneficial. It seems to me that either:

1) You're trying micromanage, or
2) You're trying to avoid supporting cargos that do not yet exist.

I rather hope the first is your reason, because it should be quite obvious that the second reason will never get anything done. The first has its own problems. Specifically, you can't micromanage around cargos that do not yet exist. Since you can't micromanage all cargos, why put more than minor thought/work into the micromanagement of currently-existent cargos?

[George]

I still can't figure out why more refit control is beneficial. It seems to me that either:
1) You're trying micromanage, or
2) You're trying to avoid supporting cargos that do not yet exist.
I rather hope the first is your reason, because it should be quite obvious that the second reason will never get anything done. The first has its own problems. Specifically, you can't micromanage around cargos that do not yet exist. Since you can't micromanage all cargos, why put more than minor thought/work into the micromanagement of currently-existent cargos?

Well, let us call it micromanagement, but I would like to transport wood on log truck for Volvo truck, and on a flat bed truck for international truck. With the current code model it becomes a bit pain, because while they have the different cabin, the body ID is the same. The reason for that is that only 128 vehicles IDs can be used for attached articulated parts (CB 16 limitation).
According to selected schema

Code: Select all

// IDs usage table
// 00h - 2Fh: Truck bodies 
// 30h - 5Fh: Trailers
// 60h - 7Fh: - reserved -
// 80h - FFFFh: Trucks cabins

I have only 48 slots for Truck bodies. Currently I grouped bodies into BOX, DUMP, TANKER, SPECIAL. 48 / 4 is only 12 different variants. Too little imho. So I'm looking for a way to have more of them on one ID. Current problem to do that - a refit list.

[DaleStan]

I have only 48 slots for Truck bodies. Currently I grouped bodies into BOX, DUMP, TANKER, SPECIAL. 48 / 4 is only 12 different variants. Too little imho.

Then borrow IDs from SPECIAL and assign them to BOX, DUMP, and TANKER. Or whatever combination thereof gives you enough slots in each group. I'm unlikely to buy anything that involves splitting any portion of the ID space into any number of equally sized spaces. Make the spaces exactly as large as they need to be, and no larger. If the 128 slots are not sufficient, then for each slot, specify either its contents or the reason it cannot be used, and then list the extras that don't have a slot.

Also, it would help if I could figure out the difference between "body" and "trailer". Or maybe between "cabin" and "body", but I think the trouble I'm having is more likely to be "body"/"trailer".

I would like to transport wood on log truck for Volvo truck, and on a flat bed truck for international truck. With the current code model it becomes a bit pain, because while they have the different cabin, the body ID is the same.

So what you really want is to be able to change the refittablilty after the vehicle is attached to its head?

[George]

I have only 48 slots for Truck bodies. Currently I grouped bodies into BOX, DUMP, TANKER, SPECIAL. 48 / 4 is only 12 different variants. Too little imho.

Then borrow IDs from SPECIAL and assign them to BOX, DUMP, and TANKER.

How?
Here goes the current test GRF (not playable, but will make you understand what I mean. I did not do any trailer yet, currently only cabins and bodies

Or whatever combination thereof gives you enough slots in each group. I'm unlikely to buy anything that involves splitting any portion of the ID space into any number of equally sized spaces. Make the spaces exactly as large as they need to be, and no larger. If the 128 slots are not sufficient, then for each slot, specify either its contents or the reason it cannot be used, and then list the extras that don't have a slot.

And what should I do with that extras? Wait for GRF version 8 where CB 16 result bit 14 would be reverse flag, not bit 8?

Also, it would help if I could figure out the difference between "body" and "trailer". Or maybe between "cabin" and "body", but I think the trouble I'm having is more likely to be "body"/"trailer".

Body - the part of the truck, which carries cargo. Cabin - the part of the truck for a driver. Trailer - a vehicle that is connected to the truck.

I would like to transport wood on log truck for Volvo truck, and on a flat bed truck for international truck. With the current code model it becomes a bit pain, because while they have the different cabin, the body ID is the same.

So what you really want is to be able to change the refittablilty after the vehicle is attached to its head?

We may say so. But in fact I want a bit less. It would be enough to have the ability to define it before build. For example. Steel and paper are piece cargoes. I have flat bed transporter and drop truck. Lets say trucks with bodies ID 00 and 01. For International truck (ID 80, 81 ...) both of them should be transported in drop side truck (ARV IDs 81 + 01). For Volvo truck (ID 90, 91 ...) paper is transported in drop side truck (ARV IDs 91 + 01), but steel is transported on flat bed truck (ARV IDs 90 + 00). How to code this? And I would like to see refit list in purchase list too

[DaleStan]

Also, it would help if I could figure out the difference between "body" and "trailer". Or maybe between "cabin" and "body", but I think the trouble I'm having is more likely to be "body"/"trailer".

Body - the part of the truck, which carries cargo. Cabin - the part of the truck for a driver. Trailer - a vehicle that is connected to the truck.

No. What is the in-NFO functional difference between the three? Which ones carry cargo? Which ones have engines? Which ones have/do both? Which ones do something else entirely?

So what you really want is to be able to change the refittablilty after the vehicle is attached to its head?

We may say so. But in fact I want a bit less. It would be enough to have the ability to define it before build.

Define it depending on which conditions?

[George]

Also, it would help if I could figure out the difference between "body" and "trailer". Or maybe between "cabin" and "body", but I think the trouble I'm having is more likely to be "body"/"trailer".

Body - the part of the truck, which carries cargo. Cabin - the part of the truck for a driver. Trailer - a vehicle that is connected to the truck.

No. What is the in-NFO functional difference between the three? Which ones carry cargo? Which ones have engines? Which ones have/do both? Which ones do something else entirely?

Cabin has engine and 0 capacity. Because it is not attached, uses IDs above 80h.
A body can have 0 and non-0 capacity, has no engine. Can be attached to specific cabin.
The trailer is similar to the body, but, in theory, it is independent ARV, that can be attached to cabin + body. The same way as wagons are attached to engines in rail. Unfortunately this is not possible with the current engine, but may be possible in the future.
In the current terms there is no difference between trailer and body, but it will appear later (I hope).

So what you really want is to be able to change the refittablilty after the vehicle is attached to its head?

We may say so. But in fact I want a bit less. It would be enough to have the ability to define it before build.

Define it depending on which conditions?

Cabin ID

[wallyweb]

...

...

It would appear that there is some need for some definition of terms in English. Perhaps this will help end the confusion:
Truck: A vehicle for transporting cargo.
Cab: Part of a truck where the driver sits. It can be located just behind or just above the engine.
Bed: A flat part of a truck located just behind the cab. It is open at the top and may or may not have sides.
Box: A bed that has a roof. It is also referred to as a cube.
Van: A truck where the cab and box are built as one unit, usually with no separation between the two.
Tractor: A truck that has no bed. Instead it has a coupling unit for attaching a trailer.
Rig: A tractor with a trailer attached.
Train: A tractor pulling more than one trailer.
Tanker: A truck or a trailer with a tank instead of a bed or a box.
Tandem: A truck (not a tractor) with a bed or box or tank that also pulls a trailer.
Note that some of these terms are North American but they should be similar in other English speaking countries.

I hope this ends the confusion.

[michael blunck]

[OT]

[...] Note that some of these terms are North American and they could be different in other English speaking countries.

I hope this ends the confusion.

Usually, this is where the confusion starts.

regards
Michael

[DaleStan]

It would be enough to have the ability to define it before build.

Define it depending on which conditions?

Cabin ID

That information cannot be known until after the vehicle is built. How do you propose to define behaviour that depends on it before the vehicle is built?

[George]

Define it depending on which conditions?

Cabin ID

That information cannot be known until after the vehicle is built. How do you propose to define behaviour that depends on it before the vehicle is built?

I suppose this information should be (become) available, because CB 16 works in purchase list. The same for var 47 (current cargo). Even if ARV is not build, the calculation of capacity is based on this var. So, it should also be (become) available in purchase list.
Similar like vars 80-8F during CB 28. Even when industry is not build yet, some important information can be accessed. Here we have the same situation. Cabin ID and cargo ID are things wee need to have.

[DaleStan]

How do you propose to define behaviour that depends on it before the vehicle is built?

I suppose this information should be (become) available, because CB 16 works in purchase list.

CB 16 is called for which vehicle?
And you want to set the refittability for which vehicle?

Unless the answers to those two questions are the same, that's completely irrelevant.
And if they are the same, then you're setting refittability of a vehicle depending on its own ID, so why not just set it statically?

[George]

How do you propose to define behaviour that depends on it before the vehicle is built?

I suppose this information should be (become) available, because CB 16 works in purchase list.

CB 16 is called for which vehicle?
And you want to set the refittability for which vehicle?
Unless the answers to those two questions are the same, that's completely irrelevant.
And if they are the same, then you're setting refittability of a vehicle depending on its own ID, so why not just set it statically?

They are different vehicles. But they are not irrelevant, because they are are joined with CB 16.

Dale, what are trying to achieve? To say it is impossible with the current code? I know that. That it is impossible in general? Me doubts.

[DaleStan]

They are different vehicles. But they are not irrelevant, because they are are joined with CB 16.

Not until after the purchase action.
This is why, among other things, there were a lot of bugs related to capacity-in-purchase-list a while back.

Dale, what are trying to achieve? To say ... That it is impossible in general? Me doubts.

Then you needs to produce code that proves otherwise. "Code" as in "C++" or "x86 assembly", not as in "NFO".

[michael blunck]

[...] there were a lot of bugs related to capacity-in-purchase-list a while back.

Dale, this might be of interest in this context: http://devs.openttd.org/~frosch/doc/cap ... enture.txt

Don´t know if you´ve already seen it.

regards
Michael