Limitation of cargo_subtype refitting option

[TadeuszD]

Starting from OTTD version 1.4.0 new limitations was added to the cargo subtype refitting option. For example, if I have two types of wagons with cargo_subtype elements defined by strings:

Code: Select all

STR_ABDHMNU_2CLASS      :- 2-nd class (Bdhmnu)
STR_ABDHMNU_1CLASS      :- 1-st class (Adhmnu)
...
STR_AB9MNOPUZ_2CLASS    :- 2-nd class (B9mnopuz)
STR_AB9MNOPUZ_1CLASS    :- 1-st class (A9mnopuz)

...there is no posibility to select all these wagons and refit it to 1-st or 2-nd class using one mouse click. Now I must select wagons according to its type and refit it separately.
The "one click refit option" works only if cargo_subtype strings defined for both types of wagons are exactly the same, for example:

Code: Select all

STR_2CLASS      :- 2-nd class (UIC type: B...)
STR_1CLASS      :- 1-st class (UIC type: A...)

But this solution breaks some features of my set. Unified strings are a little unclear...

My question is - is there any solution to "inform" OTTD, that two different cargo_subtype strings means the same refitting option? Or, is there possibility to use this short and unified version of cargo_subtype string in the train refit window and display the full version of cargo_subtype string in the train description window?

[planetmaker]

If the types are called differently, then they are considered different. If you want to refit several vehicles, only those options common to all are displayed as the results otherwise are unpredictable to the user and might be very much unexpected. So if you want them to be the same, call them the same. See also FS#3764. The assumption that the order of subtypes between different vehicles matches up to the same actual sub-type, is one which breaks down very easily, e.g. when comparing two different cargo wagons like one with and the other without refrigeration.

Related changes to cargo subtype:

summary: (svn r25058) -Add: tree nodes in the refit GUI for subtype refits.
summary: (svn r25044) -Change: Collapse subtypes in the refit GUI and only expand them after selecting the cargo type.
summary: (svn r25043) -Change [FS#3764]: Only display subtypes in the refit GUI which are available for all selected vehicles. Also add a generic list item to refit while keeping the subtypes of individual vehicles.
summary: (svn r25041) -Remove [FS#3764-ish]: ordered refit with subtypes, since the cases where it worked were corner cases rather than the general case.
summary: (svn r25040) -Add: a mode to CmdRefitVehicle to preserve the current subtype, also when refitting multiple vehicles.

[TadeuszD]

If the types are called differently, then they are considered different. If you want to refit several vehicles, only those options common to all are displayed as the results otherwise are unpredictable to the user and might be very much unexpected. So if you want them to be the same, call them the same. See also FS#3764.

Thanks for quick answer!
Now I have new question... What happens if two wagon have sub-type options defined by strings:

Code: Select all

0: return STR_A
1: return STR_B
2: return STR_C
return CB_RESULT_NO_TEXT;

and

Code: Select all

0: return STR_A
1: return STR_C
return CB_RESULT_NO_TEXT;

Do all wagons receive correct cargo_subtype property (2 for first and 1 for second wagon) if player chose common sub-type option defined by string STR_C?
In FS#3764 I found interesting comment added by George (George - Thursday, 13 June 2013, 05:05 GMT). Will be (or is now?) this behavior implemented in OTTD?

[planetmaker]

If the types are called differently, then they are considered different. If you want to refit several vehicles, only those options common to all are displayed as the results otherwise are unpredictable to the user and might be very much unexpected. So if you want them to be the same, call them the same. See also FS#3764.

Thanks for quick answer!
Now I have new question... What happens if two wagon have sub-type options defined by strings:

Code: Select all

0: return STR_A
1: return STR_B
2: return STR_C
return CB_RESULT_NO_TEXT;

and

Code: Select all

0: return STR_A
1: return STR_C
return CB_RESULT_NO_TEXT;

Do all wagons receive correct cargo_subtype property (2 for first and 1 for second wagon) if player chose common sub-type option defined by string STR_C?

My understanding is that's how it should currently work.

In FS#3764 I found interesting comment added by George (George - Thursday, 13 June 2013, 05:05 GMT). Will be (or is now?) this behavior implemented in OTTD?

I can't say that I quite understand the intention how the "cycle" should work - it will call CB_FAILED for value1 and stop. That switch defines 4 values with an explicit callback result and a callback failure for all others. I'm not sure it shall work with gaps in the subtype values (it's undefined behaviour at best).

[TadeuszD]

Thank you for explanation.
I'm going to implement new cargo_subtype rules in my train set.