Proposal: "Views" for vehicles

[michael blunck]

This may be a bit ill-placed here, but after having used that "views" feature for "objects" a couple of days now, I wonder if it would be of similar impact for other objects in game, namely for vehicles?

In this way, we could easily get rid of the "livery" problem, i.e. having to resort to user-defined bit mask tricks (train prop25) or that "special" cargo class wizardry, when having to select a special livery.

IMO, this would be a more straightforward approach than (mis)using the "refit" mechanism for purely graphical variations. And it could be easily linked with CB19, if needed ("TEE", "S-Bahn", "InterCity", ...).

regards
Michael

[Eddi]

While drifting off topic, there's also an old request that vehicles be allowed to be assembled from multiple sprites

this could e.g. simplify attaching red lights.


not entirely sure if that is related at all, but sounds the right place to consider if one is rewriting the way vehicle graphics are specified anyway...

[andythenorth]

While drifting off topic, there's also an old request that vehicles be allowed to be assembled from multiple sprites

I can think of some good uses for that....but...
- isn't it a performance suck to composite sprites?
- it would severely break backwards OTTD compatibility for any grfs that made use of this.

[frosch]

This may be a bit ill-placed here, but after having used that "views" feature for "objects" a couple of days now, I wonder if it would be of similar impact for other objects in game, namely for vehicles?

In this way, we could easily get rid of the "livery" problem, i.e. having to resort to user-defined bit mask tricks (train prop25) or that "special" cargo class wizardry, when having to select a special livery.

IMO, this would be a more straightforward approach than (mis)using the "refit" mechanism for purely graphical variations. And it could be easily linked with CB19, if needed ("TEE", "S-Bahn", "InterCity", ...).

regards
Michael

What is the difference between "views" and "cargo subtypes". The latter are purely meant for different liveries, aren't they?
And why do you need property 25 for cargo subtypes?

[michael blunck]

["views" for vehicles(trains)]

What is the difference between "views" and "cargo subtypes". The latter are purely meant for different liveries, aren't they?

Both are meant for applying visual modifications to vehicles, by livery or by other graphical representations. The difference in selecting those graphical representation between "views" and "cargo subtypes" is that the latter needs both the refitting procedure and, in case of an engine without freight capacity, the use of a mock cargo. Which is, in principle, a hack. "Views" OTOH, would allow to select a different graphical representation in a direct manner in-place, i.e. from the buying menu. See attached sketch (left: current situation, right: sketch):

views for trains.png (16.22 KiB) Viewed 6953 times

And why do you need property 25 for cargo subtypes?

In the DB Set, I´m using prop25 in various combinations with cargo subtypes. I.e., for S-Bahn trains, if a coach is to be refitted to the sub-cargo "S-Bahn", I´m setting a specific bit in prop25 which in turn triggers the engine to change its livery as well. This works (and has always worked, both in TTDPatch and in OTTD), but it´s somewhat beneath the specification, because if something fundamental would be changed w/r to caching, it would break. Other than that, there´s no serious way to change the livery of an engine carrying no freight. Introducing "views" would implement this in a straightforward and clean way, IMO.

For grf authors, handling of different liveries for trains (i.e., engine and wagons) would become very simple then, by accessing the engine´s "views" property from the wagons in a varaction2 chain, possibly together with other vars.

An example for switching coaches between "generic" and "S-Bahn" in DBXL 0.9, using prop25 and cargo-subtypes:

Code: Select all

//------------------------------------------------------------------
// [X_SBAHN] - toggle Nah: <generic> | "S-Bahn"
//------------------------------------------------------------------

// Grafik, refit
def(1) refitted(
         ref(N_SBAHN) if(1) // S-Bahn LONG 
         ref(LN_) else     // generic LONG
)

// Grafik, S-Bahn Zeit?  
def(2) year(
         ref(1) ifyear(1979 .. 1995) // 1979 - 95 S-Bahn LONG
         ref(LN_) else    	          // generic LONG
)

// set Bit7 (OR)
def(3) setubit(7)

// unset Bit7 (AND)
def(4) clrubit(7)

// CB36: set Bit7 prop25
def(5) property(
         ref(3) if(_USER) // set Bit7 (toggle nah) 
         ref(0) else        
)

// CB36: unset Bit7 prop25
def(6) property(
         ref(4) if(_USER) // unset Bit7 (toggle nah)
         ref(0) else         
)

// callback, refit
def(7) refitted(
         ref(5) if(1) // S-Bahn  -> set bit7
         ref(6) else  // generic -> unset bit7
)

// callback if 1979 - 1995
def(8) year(
         ref(7) ifyear(1979 .. 1995) // 1979 - 1995 S-Bahn
         ref(6) else      	          // generic
)

// [E3] toggle
def(X_SBAHN) callback(
         ref(8) if(CB_PROP) // CB36 for prop25
         ref(2) else        // Grafik        
)

This would be simplified with the implementation of "views" to:

Code: Select all

//------------------------------------------------------------------
// [X_SBAHN] - toggle Nah: <generic> | "S-Bahn"
//------------------------------------------------------------------

// Grafik, S-Bahn or generic?
def(1) getviews(
    engine(
         ref(LN_) if(0)    	          // generic LONG
         ref(N_SBAHN) else // S-Bahn LONG 
    )
)

// [E3] toggle
def(X_SBAHN) year(
         ref(1) ifyear(1979 .. 1995) // 1979 - 1995 S-Bahn 
         ref(LN_) else      	          // generic
)

O/c, this is a more subtle example, but even the "basic" use of liveries would benefit from introducing "views".


Here´s what I think would be the needed additions to the specs:

in action0 trains:

Code: Select all

2B	B	Number of views

Number of views (2B)
Since ... trains may have "views", i.e. different graphical representations, e.g.
used to show different liveries or visual vehicle nodifications. 
Number of views may be 1 .. ?. Default value is 1.

Use vehicle varaction2 4B to access particular views of a train.

in varaction2 vehicles:

Code: Select all

4B	B	Vehicle views

Get vehicle views (4B)
Returned value stands for a particular view of a vehicle. Number and rank of
set-IDs must match the value given in the vehicle´s action0 prop2B, i.e. for a
vehicle with 4 views, prop4B may return values 0 .. 4. Since ....

@moderators,
Maybe split off all posts since Sat Dec 11, 2010 9:49 pm into a new thread named "Proposal: "Views" for vehicles]? Thank you.

regards
Michael

[eis_os]

And what if you have more then X views? Conceptional, I see here a totally mess... + a messy GUI.

From a gui standpoint you would need a drop down, and describing each subtype.
As soon as you have views, you will start to request a complete set of different parameters for each "subtype". eiyee

Note: I don't think there is storage for it in TTDPatch vehicle structure anyway... (in a sense to have this for all vehicle types)

[planetmaker]

And what if you have more then X views? Conceptional, I see here a totally mess... + a messy GUI.

Nah, it could be a scroll list similar to the way it was discussed and implemented for the 2xN views available for NewObjects.

[Eddi]

we had a lengthy discussion on IRC, and here's my proposal:

0) the concept of "cargo subtypes" should be removed.

1. they serve no gameplay purpose
2. this frees up the necessary space in the vehicle structure for the following
3. if done right, old stuff should be able to transparently be converted into this

1) additionally to "cargo refit", introduce a new refit type "gear refit", that is available independent of cargo.

1. especially, it is available for vehicles not carrying any cargo [engines], so they don't need a special "regearing" cargo slot, which may make vehicle sets incompatible with industry sets.
2. the refit gui will have two columns, one for the "cargo refit" and one for the "gear refit"
3. the availability of certain "gear refit" types may be determined via callback, and thus be based on cargo type, build year, current year, etc.

[Zephyris]

While drifting off topic, there's also an old request that vehicles be allowed to be assembled from multiple sprites

And continuing the off-topic drift I would be very keen to see composite sprites for vehicles. It would simplify coding more graphics for eGRVTS enormously. I would love to add more vehicles and cargo graphics support to that set but it is a combinatorial explosion, and the set is already over 7000 sprites making it tough to maintain and expand. Even just being able to overlay 3 sprites could reduce this by a factor of 10...

[eis_os]

we had a lengthy discussion on IRC, and here's my proposal:

0) the concept of "cargo subtypes" should be removed.

1. they serve no gameplay purpose
2. this frees up the necessary space in the vehicle structure for the following
3. if done right, old stuff should be able to transparently be converted into this

1) additionally to "cargo refit", introduce a new refit type "gear refit", that is available independent of cargo.

Sorry, can you explain me what you exactly mean with "cargo subtype"? Action3 uses cargo translation tables, you need this for transporting cargos with the right sprites.

1. especially, it is available for vehicles not carrying any cargo [engines], so they don't need a special "regearing" cargo slot, which may make vehicle sets incompatible with industry sets.
2. the refit gui will have two columns, one for the "cargo refit" and one for the "gear refit"
3. the availability of certain "gear refit" types may be determined via callback, and thus be based on cargo type, build year, current year, etc.

As mentioned, you seem to want different stats. For performance reasons TTDPatch does use various caching. As soon as you change the vehicle stats, all caching may be void. Specially a lot cargo code in TTDPatch doesn't know if it's a engine or a wagon at all.

Now I see here:
a) Draw X sprite on top (At least TTDPatch would need to traverse the whole action chain again)
b) You want a complete subtype for vehicles. (I don't mean cargo subtypes)
c) You want to screw the whole action processing.

Actually the current way of newgrf processing is a sprite number needs to be found for this vehicle, object or something. For houses/industries/objects we actually ask the action system, give me a pointer to a fixed structure I can traverse and paint back.

if you want to draw several sprites the whole drawing needs to be changed. So it would be newgrf driven then. Aka newgrf tells to draw sprite 231 then draw sprite 210 and then 222. That's a complete change how things internally work. A change Josef didn't liked when I wrote canals already...

[michael blunck]

And what if you have more then X views? Conceptional, I see here a totally mess... + a messy GUI.

The number of possible "views" is indeed a problem which has to be solved. For objects, this number has been defined as [1,2,4], based on directions of view, but o/c it doesn´t necissarily need to be used with directions in mind. This value could have been made a larger number (full range of a byte), but for larger numbers, the GUI question turns out to be the most crucial problem.

IMO, trains won´t have such many views, but OTOH, I´ve seen plane sets for which the "number of views" would be much larger, indeed.

From a coder´s POV, a dropdown menu would be the optimal solution. But that´s not what I had in mind when proposing views for objects. The idea here was to use a dropdown menu to choose an object and then being directly presented with buttons which you may immediately act on.

Now, for vehicles, the need for a second dropdown menu to choose from again, would not be an improvement about the current scheme, being forced to use the refit window to get a different graphical representation. Another point is that then there won´t be graphical representations of the views of the vehicle in question.

O/c, for a larger number of views, this approach seems to be questionable. The GUI has to be dynamically alterable and, possibly, the number of views have to be restricted to a much smaller number than 255.

we had a lengthy discussion on IRC, and here's my proposal:

0) the concept of "cargo subtypes" should be removed.
they serve no gameplay purpose

"Cargo subtypes" must stay. It´s an important concept of some industry sets, e.g. in ECS, where e.g. a factory producing VEHI could produce either "vehicles(ships)" (a "shipyard"), or "vehicles(locomotives)" (a "locomotive factory"). And, to reflect this, some vehicle sets make use of it as well, e.g. the DB Set.

E.g., its cargo subtypes for ECS´s GOOD are

- (packaged), (palletized), (containers), (liquid), (machinery), or for FOOD:
- (meat products), (canned fish), (frozen fish), (beer), ..., and for WDPR we have
- (timber), (wood chips)

There are more, e.g. for ECS and FIRS in the NewShips set.

All these subtypes constitute graphical modifications, and some of them are using CB15 to rescale capacities.

So, "cargo subtypes" is a sound refitting option. It makes absolutely no sense to remove it. OTOH, it´s not the method of choice if it comes to select between different "liveries" for engines w/o capacities, and to reference it from the train´s wagons/coaches.

1) additionally to "cargo refit", introduce a new refit type "gear refit", that is available independent of cargo.
especially, it is available for vehicles not carrying any cargo [engines], so they don't need a special "regearing" cargo slot, which may make vehicle sets incompatible with industry sets.

Sorry?

Firstly, I don´t like the term "gear refit" for trains. For German locomotives it is totally unknown of, and in the diverse US sets I don´t see a real use for it. In the extreme, you´d need only one single locomotive, make it "re-gearable" and you´re done.

Secondly, "re-gearing" is primarily used to change technical stats of a locomotive, but "views" aims at a different graphical representation in the first place. Only on a later stage (in a varaction2 chain) there might be the possibility to link a particular value of the views var with changes of properties.

Vice versa, "re-gearing" could change graphical representations as well, so both concepts are laterally reversed, so to speak.


In fact, IMO it boils down to having two different concepts for vehicles:

- refitting
- views

which might be related in terms of code, but quite different concept-wise.

IF it would be possible to "refit" vehicles with no capacity, one could envisage a unification of both concepts (I think in OTTD that´s already possible?) from a coder´s POV, but then the question of the GUI and the different concept still holds.

ATM, "re-gearing" now uses a dummy cargo, and I see no problem in using one of the existing cargo slots for such purpose. Obviously, there are vehicle sets which like to make use of it. In fact, IMO this is a wrong approach, and it may generate weird results when mixing such vehicle newgrf with industry newgrfs. But that´s a quite different kettle of fish.

the refit gui will have two columns, one for the "cargo refit" and one for the "gear refit"
the availability of certain "gear refit" types may be determined via callback, and thus be based on cargo type, build year, current year, etc.

The two main points of the "views" concept is to

- get rid of the extra refitting cycle (see coding example above),
- and being able to buy an engine with a certain "view" in situ.

Having to use a second dropdown menu in the buying window, or introducing a second dropdown menu in the refitting window would make the concept worthless.

The only problem I see, besides being short on space in the vehicle structure, is how to get even more extra texts into the purchase menu (i.e. those "Standard", "S-Bahn", "LH-Express", on the sketch above).

There are some possibilities:

- no extra text at all, just use CB23 (additional text in purchase screen) to describe what´s going on, depending on the actual view. Problem is that output of CB23 is positioned under the technical parameters of the engine, thus quite far apart from the extra view icons. As a quick solution, the puput of CB23 could be re-positioned,

- no extra text at all, include some small text into the icon, if any needed. Problem here is how to handle space for the extra icons (especially for larger numbers of views),

- a new callback, similar to CB19, but depending on views, not on refitting. Output could be positioned under the views icons, showing only text assigned to the actual view. In addition, output of this new callback would be added after the vehicle´s name in all appropriate windows (like output of CB19 is), which by none of the simple solutions above could be achieved.

In conclusion, introducing a new callback for this might be the most straightforward approach.

regards
Michael

[andythenorth]

"Cargo subtypes" must stay. It´s an important concept of some industry sets, e.g. in ECS, where e.g. a factory producing VEHI could produce either "vehicles(ships)" (a "shipyard"), or "vehicles(locomotives)" (a "locomotive factory").

It's subjective of course, but I think this adds nothing to gameplay except confusion. The intention seems to be to bring a little character and/or realism to the generic cargos. He may not make the connection that it's just vehicles.

I worry that it is confusing to players. Player 'Bob' goes looking for something to transport 'vehicles(ships)', but the greater part of vehicle set authors don't seem to be supporting or using subtypes this way, so likely Bob doesn't find anything, and scratches his head about how to transport this cargo.

FWIW I have no opinion currently on removing or keeping cargo subtypes.

They are used in several places in HEQS, but not as intended:
- they control different vehicle sprites (e.g. types of trailers)
- they control number of wagons and capacity (trams)

They will be used in FISH to control capacity of ships.

Pikka also uses them for quite different purposes to original intention.

In my opinion the current 'wrong' uses are a slightly broken hack. It's a very effective hack code-wise, but the GUI for refitting sucks, because Bob sees a long list made up of n entries where n = number of cargo refits * number subtype options. For me the usability of this sucks.

[The Irish]

I also think that you still need a refit option in order to allow players to change liveries of already bought vehicles. e.g. by a BR111 in S-Bahn livery, and after some years, switch to LH-Express if the train moves to different duties. From a players side, I find it easy enough with the refit to get my desired livery. I can see that this is a bit messy from a coding point of view though.

[Hyronymus]

I also think that you still need a refit option in order to allow players to change liveries of already bought vehicles. e.g. by a BR111 in S-Bahn livery, and after some years, switch to LH-Express if the train moves to different duties. From a players side, I find it easy enough with the refit to get my desired livery. I can see that this is a bit messy from a coding point of view though.

Nice topic bump!

However: can such a patch also include rotating depot images?

[Eddi]

no, that is something completely different. this is not about rotating vehicles at all. this is about having the vehicle look differently depending on some player-influenced conditions.

[Snail]

This is a *very* interesting proposal.

It seems the discussion has been over for almost a year now. However, the proposal of adding views for vehicles sounds very useful for vehicle sets that are planning multiple liveries for engines the players can choose from.

And what if you have more then X views? Conceptional, I see here a totally mess... + a messy GUI.

The number of possible "views" is indeed a problem which has to be solved. [...] This value could have been made a larger number (full range of a byte), but for larger numbers, the GUI question turns out to be the most crucial problem.

IMO, trains won´t have such many views

Well, at least the French set I'm developing will need as much as 8 views for certain locomotives. So, having a button for each view will not be practical.

From a coder´s POV, a dropdown menu would be the optimal solution. But that´s not what I had in mind when proposing views for objects. The idea here was to use a dropdown menu to choose an object and then being directly presented with buttons which you may immediately act on.

Now, for vehicles, the need for a second dropdown menu to choose from again, would not be an improvement about the current scheme, being forced to use the refit window to get a different graphical representation. Another point is that then there won´t be graphical representations of the views of the vehicle in question.

How about a dropdown menu with the possible views, connected to an image that changes in real-time that displaying the selected graphics, and perhaps some text (similar to CB23) that displays the description of the selected view (also changing in real-time)?

Something like this. When a vehicle is selected, if the vehicle supports multiple liveries, a dropdown menu appears, with the image of the currently selected livery (i.e. the default one, to start with):

view example 0.png (8.93 KiB) Viewed 5943 times

Then, if you click on the dropdown menu, all the possible liveries get displayed. As soon as you select one, the image on the right gets updated, together with the specs (if necessary) and the help text:

view example 1.png (8.57 KiB) Viewed 5943 times

Perhaps the graphics can be updated after you select the chosen variant.

In this case, the engine has three possible liveries, each with its own specs. The user would first select the "020 020T" engine, then the dropdown menu would appear, together with the picture of the currently selected livery. Then, by choosing the desired livery through the dropdown menu, the graphics in the view would change, as well as the specs and the CB23 text. The latter could even be placed on top of the specs, to have it closer to the dropdown menu.

As I said, the set I'm developing will include engines with 8 possible liveries (especially the early ones), so a dropdown menu will be better than having 8 buttons in the GUI. Hopefully, this system might make a dropdown menu feasible...

IMO, if we could have something of the like in TTD, it would greatly improve both the playability and the ease of coding the most complex trainsets.

First, would this be feasible? And, what do you guys think?

[Michi_cc]

In this case, the engine has three possible liveries, each with its own specs.

What you describe is something different than "views". The point of "views" in contrast to refits is to cater for graphical variations that do not differ in specs.

[Hyronymus]

Perhaps it helps if a clear definition of a view was put against a clear definition of a refit.

[Snail]

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...

[michael blunck]

This reminds me that I made anothor sketch of a possible GUI after Terkhen´s(?) implementation of the horizontal scroll menu in the train refitting window:

views for trains 2.png (16.96 KiB) Viewed 5901 times

regards
Michael