Articulated vehicles and the purchase menu

[FooBar]

While rewriting some articulated road vehicle, I came across the following discrepancy between the built vehicle and the purchase menu.

Consider the following case:
* A three part articulated vehicle
* Different capacities for each part (38, 27 and 38, total 103)
* Using callback 36 (change vehicle properties) and variable 40 (position in consist)

This works fine for the built vehicle (so far so good), however, this gives problems with displaying the correct capacity in the purchase menu.
One way to avoid this is not to have the articulated vehicle callback in the purchase menu, but (quoting Hirundu) this is not a good idea because if the vehicle pool is exhausted, vehicle building will fail halfway.

Now comes the actual problem with this if you have the articulated vehicle callback in the purchase menu:
* Variable 40 isn't available in the purchase menu
* I can return only a single value for cb 36 that applies to every vehicle part
* And basically the total vehicle capacity must be a multiple of the amount of vehicle parts and cannot be this 103 I had initially.

As this limitation doesn't apply to a built vehicle, it IMO shouldn't apply to the purchase menu either. Two possible solutions that come to mind:
* easy: always display the capacity property in the purchase menu, as the callback isn't reliable (this my break certain NewGRFs)
* more work: allow certain variable access (like var 40) in the purchase menu

This particular case is most likely not the only one with this problem. I haven't tested, but I suspect that the same will apply to other vehicle property callbacks.

Now I like to challenge you to either prove me wrong and show a working solution, or to come up with different suggestions to solve this problem This was also discussed in the context of NML on irc; here's a transcript of that conversation if you're interested.


EDIT: noticed something else... If you don't do any of the property callbacks, just define an articulated vehicle. The weight and power of the vehicle is that what is set in the vehicle properties, but the capacity of the vehicle is the value from the properties multiplied by the number of vehicle parts (weight and power are not multiplied). Seems a bit inconsistent.

[frosch]

Yes, this is the hardest part of articulated vehicles. Many GRFs fail with that

There are currently 3 things OTTD needs to know about an articulated vehicle in the purchase list:
a) Whether the vehicle is articulated. (Important for AIs.)
b) What are the cargotypes the vehicle can be refitted to. (Important for autoreplace/renew; and the GUI [0])
c) What is the capacity of the unrefitted vehicle. (Important for AIs and the GUI)

(The vehicle pool space checking uses a non-purchase list call to the articulated callback; so that is no issue)

I usually suggest this solution for vehicles carrying a single cargo (no mixed cargotypes).
1) Use a different vehicle ID for the front vehicle and the articulated parts.
2) Make the articulated parts report capacity 0 in the purchase list via CB 36.
3) Make the front part report the total capacity in the purchase list via CB 36.
4) If the front part does not carry any cargo usually (pure engine), you have to set the capacity property to a non-zero value, or the CB36 will not be called. You can set the capacity to zero via CB 36 after building.


My current long-term goal however is to completely trash all callbacks from the purchase list, and let OTTD make sandbox purchases of the vehicles. (so all variables would be available). This is needed for advanced features like template based autoreplacing, purchase+refit, AI sandboxes, ....


[0] Since very "clever" GRFs got the idea to show the refittability via additional text (i.e. the purchase list looks right, only autorenew/replace fails), OTTD checks the refittability of the vehicle after building, and displays an error message if the refittability differs from the purchase list info.

[FooBar]

Not really a fix I was hoping for, but thanks for your reply
I'd rather away your "long-term goal" and now live with a capacity being a multiple of the number of vehicle parts. While your suggestion may work fine, it's not very suitable as tutorial example (too complex code), but thanks anyway. I may look into it later when NML start enforcing me to use the new style callbacks.