Transport Tycoon Forums

Snail wrote:

Michi_cc wrote:The point of "views" in contrast to refits is to cater for graphical variations that do not differ in specs.

I see. So, would it be impossible to change the specs through this system? Couldn't they be changed through a callback?

Or perhaps it's conceptually different? If so, this system could be used to refit engines, which in principle can't be refitted because they carry no cargo...

there may be a possibility to have the current "view" accessible as a variable in CB36 and similar. whether that is a sensible idea or not needs to be discussed.

but then this would be a conflicting feature with cargo subtypes, which might cause new problems.

I've thought about this proposal for a while now, and i want to propose a spec for it:

1. A new property is introduced: "number of views", which can not be changed via a callback. sane value range to be decided. (max 254)
2. If this property is defined and non-zero, the semantics of action3 is changed, instead of "cargo-id", the "view" of the vehicle is used to resolve which (var)action2 is called. this means, properties are shared between all views, callbacks and graphics are separate.
3. an implicit view "0xFF" is always defined and used on the purchase menu (this mimics existing behaviour)
4. if the number of views is non-zero, a button grid is inserted into the purchase (or autoreplace) window to select a view which is used after purchase
5. the view cannot be changed after purchasing (use refitting instead if that is desired)
6. callbacks called for the purchase view get the currently selected view in var18/extra_callback_info2 (this applies to "cb0" (deciding graphics), cb16 (articulated parts), cb23 (purchase menu text), cb36 (alter properties), possibly some i forgot). if found useful, this can be extended for all views and callbacks (unless the callback uses var18 for other things)
7. a new callback is introduced to determine if a view is available, which is called from the purchase list to determine if the button for this view should be greyed out.

this should cater for (almost) all desires people would want to get from views: simple graphics changes, property changes and different number of articulated parts (currently impossible/"hacked" with short invisible parts)

Eddi wrote:I've thought about this proposal for a while now, and i want to propose a spec for it:
[...]

Something like this would be quite useful for my sets. It would make the players' life much easier.

With that spec, can AI/GS/OpenTTD query the NewGRF for the specs of a view without having to first construct a vehicle, and then check the properties of it?

i have no idea what AI/GS can do currently, so i can't judge whether that can be improved by this spec.

In Theory(tm), AI/GS should get the same information the player can get on the purchase menu.

AI/GS support is easy. Just report every view as separate engine to the AI, e.g. as "view << 16 | engineid".