eis_os wrote:
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.
Eddi wrote:
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.
Eddi wrote:
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.
Eddi wrote:
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