Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refitting consists using cargo subtypes #3764

Closed
DorpsGek opened this issue Apr 12, 2010 · 9 comments
Closed

Refitting consists using cargo subtypes #3764

DorpsGek opened this issue Apr 12, 2010 · 9 comments
Labels
bug Something isn't working component: NewGRF This issue is related to NewGRFs flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) stale Stale issues

Comments

@DorpsGek
Copy link
Member

frosch opened the ticket and wrote:

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

Reported version: trunk
Operating system: All


This issue was imported from FlySpray: https://bugs.openttd.org/task/3764
@DorpsGek
Copy link
Member Author

foobar wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3764#comment11406

@DorpsGek
Copy link
Member Author

DorpsGek commented Aug 9, 2012

frosch wrote:

#5268 has a nice test GRF for this.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3764#comment11434

@DorpsGek
Copy link
Member Author

frosch wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3764#comment12038

@DorpsGek
Copy link
Member Author

dandan wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3764#comment12059

@DorpsGek
Copy link
Member Author

frosch wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3764#comment12060

@DorpsGek
Copy link
Member Author

DorpsGek commented Mar 2, 2013

dandan wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3764#comment12070

@DorpsGek
Copy link
Member Author

DorpsGek commented Jun 8, 2013

frosch wrote:

#5590 is somewhat related


This comment was imported from FlySpray: https://bugs.openttd.org/task/3764#comment12293

@DorpsGek
Copy link
Member Author

George wrote:

NOTE:
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;
cb_fails;
}
that should generate a list of cargo subtypes
STR_1
STR_2
STR_3
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 #5590).


This comment was imported from FlySpray: https://bugs.openttd.org/task/3764#comment12304

@DorpsGek DorpsGek added flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) component: NewGRF This issue is related to NewGRFs bug labels Apr 7, 2018
@andythenorth andythenorth added the stale Stale issues label Jan 5, 2019
@andythenorth
Copy link
Contributor

Thanks for this. There's been no activity on this for some time, and as it stands, it doesn't look likely that it will go any further. I'm closing it as we try to keep the issue count low for OpenTTD, it helps us focus on things that are important and fun. Feel free to discuss in irc or request re-opening if you disagree. Thanks for contributing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working component: NewGRF This issue is related to NewGRFs flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) stale Stale issues
Projects
None yet
Development

No branches or pull requests

3 participants