FS#3764 - Refitting consists using cargo subtypes

Attached to Project: OpenTTD
Opened by frosch (frosch) - Monday, 12 April 2010, 20:21 GMT
Last edited by frosch (frosch) - Wednesday, 27 February 2013, 18:44 GMT
Type Bug
Category NewGRF
Status Assigned   Reopened
Assigned To frosch (frosch)
Operating System All
Severity Very Low
Priority Normal
Reported Version trunk
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 5
  • Serg Stepanov (GhostRybinsk) (2012-09-16)
  • Serge (trtycoon) (2012-09-15)
  • Vladimir Guryanov (Wowanxm) (2012-09-09)
  • George (George) (2012-09-09)
  • akasoft (akasoft) (2012-08-09)
Private No


When refitting a vehicle consist to a certain cargo type and subtype, all refittable vehicles are forced to the same cargo subtype, even if the vehicle does not have any subtypes.

The behaviour does not feel correct, though likely it conforms to TTDP and the specs. Needs further checking...
This task depends upon

Comment by FooBar (foobar) - Saturday, 21 July 2012, 16:47 GMT
It gets worse when two different items in a consist share a subtype string, but at different positions.

Example: train
subtype 0: stringA
subtype 1: stringB

Example: wagon
subtype 0: stringB
subtype 1: stringC

If the complete consist is selected in the refit window, only three options are provided, the duplicate string provided by the wagon is not displayed. When selecting stringB for refit, the whole vehicle is set to subtype 1, even though the wagons have stringB at subtype 0. So the wagons end up with a different subtype than selected by the user.

Similar behavoir is seen when there are no duplicate subtype strings. Same engine, but wagon now has stringC and stringD. When selecting stringB for refit with whole consist selected, the wagon is also refitted to subtype 1, even though it has no stringB refit altogether.

My suggestion: when refitting the whole consist, only refit vehicle parts that provide the exact same string as cargo subtype and leave parts that do not provide the string untouched. For each vehicle part, look up the correct subtype ID that matches the string. So in case of the first example, refitting to stringB will set the engine to subtype 1 and the wagon to subtype 0. In case of the second example, the engine will get subtype 1 and the wagon will remain untouched.
Comment by frosch (frosch) - Thursday, 09 August 2012, 19:10 GMT
 FS#5268  has a nice test GRF for this.
Comment by frosch (frosch) - Sunday, 24 February 2013, 17:36 GMT
For now the refit GUI will only offer choices which apply to all vehicles, as in "same text" and "same subtype ID".
If some subtypes are only available for some vehicles, the player has to select the vehicles specifically.

If this is not good enough it might be possible to display all refit options and make them only apply to vehicles with matching texts. But since text IDs are not shared between server and clients, passing text IDs is a bit tricky in commands (would require passing a reference vehicle and GRF local text ID). But since displaying refit options which do not apply to all selected vehicles is weird anyway, I left this out for now.

Comment by Daniel Plaumann (dandan) - Wednesday, 27 February 2013, 18:44 GMT
I am not very happy with this change (rev 25043) since it breaks the way I have been using cargo subtypes in the Japanese Train Set.

There, cargo subtypes are used to select livery refits for multiple unit trains. These trains are coded with a lead "locomotive" plus passenger and mail cars. When a cargo subtype for passengers is chosen for the locomotive, the passenger cars and mail cars simultaneously follow suit and show the same livery.

The player is of course not supposed to be able to choose liveries for passenger and mail cars separately. So with the new system, I don't even see how to implement this anymore. At any rate, the current grf is rendered unfunctional in this respect.
Comment by frosch (frosch) - Wednesday, 27 February 2013, 18:48 GMT
So, I looked at the KIHA 200 Series DMU of Japanese Train Set v2.1a.
It sets the subtypes only for the first articulated part, and makes the other parts follow the subtype of the front vehicle.

Is that how all trains in the set work, or are there other cases?

To me it looks like this is only an issue with the GUI, which only displays subtypes for vehicles, if all articulated parts share them.
It is not in conflict with the main point of this task, to not assign subtypes to vehicles which they do not list as options.
Comment by Daniel Plaumann (dandan) - Saturday, 02 March 2013, 12:51 GMT
The KIHA 200 is indeed special, since it is articulated. For that one it seems really broken right now.

With almost all other trains (say the 101 Series), where you attach MU wagons (passenger or mail), it is indeed purely a GUI issue. If you select the front vehicle, it works fine. Still, this is confusing for players and I would prefer a different solution.

I agree that this is not really related to the actual task. I did not fully understand this when I asked to reopen.
Comment by frosch (frosch) - Saturday, 08 June 2013, 12:25 GMT
 FS#5590  is somewhat related
Comment by George (George) - Thursday, 13 June 2013, 05:05 GMT
CB fail acts as stop cycle (Wiki does not specify what should happen if CB fails)
Because there are only 3FF values possible, theoretically this can be interpreted as "skip" to allow construction as:
switch (FEAT_TRAINS, SELF, wagon_cargo_subtype_text, cargo_subtype)
{ 0: string(STR_1);
4: string(STR_2);
7: string(STR_3);
8: return CB_RESULT_NO_TEXT;
that should generate a list of cargo subtypes
but with numbers 0, 4, 7 (required to have correct refit list of a train with different cargo subtypes for its wagons, whit some of cargo subtypes being the same, see  FS#5590 ).