Page 2 of 3
Re: Heading for grf version 8
Posted: 23 Feb 2009 20:54
by George
DaleStan wrote:George wrote: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
Re: Heading for grf version 8
Posted: 25 Feb 2009 18:19
by 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.
Re: Heading for grf version 8
Posted: 25 Feb 2009 19:24
by George
peter1138 wrote: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.
Re: Heading for grf version 8
Posted: 25 Feb 2009 19:41
by peter1138
I didn't suggest removing cargo classes, though.
Re: Heading for grf version 8
Posted: 25 Feb 2009 21:05
by George
peter1138 wrote: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.
Re: Heading for grf version 8
Posted: 25 Feb 2009 21:45
by peter1138
No. Where did I suggest that properties 1D/1E (as we're talking of road vehicles) should be removed?
Re: Heading for grf version 8
Posted: 26 Feb 2009 03:04
by 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?
Re: Heading for grf version 8
Posted: 26 Feb 2009 04:31
by George
DaleStan wrote: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.
Re: Heading for grf version 8
Posted: 27 Feb 2009 04:24
by DaleStan
George wrote: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".
George wrote: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?
Re: Heading for grf version 8
Posted: 27 Feb 2009 04:56
by George
DaleStan wrote:George wrote: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
DaleStan wrote: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?
DaleStan wrote: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.
DaleStan wrote:George wrote: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
Re: Heading for grf version 8
Posted: 27 Feb 2009 21:42
by DaleStan
George wrote:DaleStan wrote: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?
George wrote:DaleStan wrote: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?
Re: Heading for grf version 8
Posted: 01 Mar 2009 06:45
by George
DaleStan wrote:George wrote:DaleStan wrote: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).
DaleStan wrote:George wrote:DaleStan wrote: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
Re: Heading for grf version 8
Posted: 01 Mar 2009 08:55
by wallyweb
George wrote:DaleStan wrote: ...
...
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.
Re: Heading for grf version 8
Posted: 01 Mar 2009 12:05
by michael blunck
[OT]
wallyweb wrote:
[...] 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
Re: Heading for grf version 8
Posted: 02 Mar 2009 01:46
by DaleStan
George wrote:DaleStan wrote:George wrote: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?
Re: Heading for grf version 8
Posted: 02 Mar 2009 04:19
by George
DaleStan wrote:George wrote:DaleStan wrote: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.
Re: Heading for grf version 8
Posted: 02 Mar 2009 06:24
by DaleStan
George wrote:DaleStan wrote: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?
Re: Heading for grf version 8
Posted: 02 Mar 2009 17:59
by George
DaleStan wrote:George wrote:DaleStan wrote: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.
Re: Heading for grf version 8
Posted: 02 Mar 2009 19:58
by DaleStan
George wrote: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.
George wrote: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".
Re: Heading for grf version 8
Posted: 02 Mar 2009 22:06
by michael blunck
DaleStan wrote:
[...] 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