Topic: Link livery_scheme and waytype

[Ranran]

(´・ω・｀)MERRY SOMETHING! Ranran is here to deliver a livery patch.

If I am trying to paint a bus, why are hovertravel and ffestinog railway options?

I was very empathize with it. So now I made a patch trying to solve this issue.

1. Enable to define waytype attribute for the livery scheme in the livery description of simuconf.tab.
ex)

Code: [Select]

livery_scheme[0] = British-Railways
livery_scheme_wt[0] = trackIf nothing is described, all waytypes are assumed.
Is livery_scheme_waytype preferred?

2. Only the livery scheme of the waytype that matches the depot is listed in the livery scheme selector on the depot dialog.


There is no change in the cumbersome livery scheme selector in the line management dialog. IMO, it is a different task.  That is, improvement of the line management dialog.
Prissi suggested tabbing the right side of the linemanagement dialog,  I thought it would be a good idea.
There is no connection between the station and the livery but it is closely related to the convoy list, so I think it is better to place the livery selector on the right, but currently there is not enough space on the right.



Different waytypes cannot be specified at the same time. If you want to represent a real company that operates multiple waytypes, do not define a waytype or duplicate the livery scheme and define a different waytype. Then the livery scheme list in the line management dialog is a little contaminated, but that would be insignificant.



Well, for this feature to work perfectly, the pakset author needs to define a waytype for the livery scheme.
Unfortunately, the only British transportation companies I know of are LNER and ScotRail. (´ ・ ω ・ ｀)
But for now, I classified and entered a temporary waytype value and uploaded it to my repository. You can use it to test this feature.
Note that some livery schemes have multiple waytypes, so they are not currently set to anything. (First-Group, Sheffield and WMPTE etc.) They are displayed in all depots.
However, as mentioned above, it is possible to duplicate a copy and specify a different waytype.
I split the L&BR into two for testing and assigned track and narrowgauge_track. So L&BR will not appear in the bus depot, but there will be two L&BRs in the non-clickable list of the linemanagement dialog.

Demo image:
In the example of 1951, the current version shows a lot of choices in any waytype depot.



This patch makes the list healthy like these.

Rail depot:

Road depot:

Ship depot:

Air depot:

Note: The ones displayed in all depots have no defined waytype.



Again, I am not familiar with transport company in the UK, so it needs to be confirmed the waytype settings in simuconf.tab.
I may have overlooked a scheme that has multiple waytypes or one waytype now but another waytype may be added in the future.



BTW, regardless of this patch, I found the number incorrectly, so the following needs to be fixed even if this patch is not accepted.

Code: [Select]

- livery[100][0] = L&BR-Standard
+ livery[101][0] = L&BR-Standard


The repository is here
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/link-waytype-and-livery-scheme

All I want for Christmas is ... TEST IT! (anytime when you have time) 

Thank you. (´・ω・｀)

[freddyhayward]

Instead of waytype attributes, could the depot GUI not simply loop through all available vehicles and list all liveries available for those vehicles? Using this behaviour, it could also filter available liveries available for the currently selected convoy.
this is what I mean in python pseudocode:

Code: [Select]

liveries  = []
if selected_convoy:
    vehicles = selected_convoy.get_vehicles()
else:
    vehicles = depot.get_available_vehicles()

for vehicle in vehicles:
    for livery in vehicle.get_available_liveries():
        if livery not in liveries:
            liveries.append(livery)


[Ranran]

Thank you for your thoughts.
I realized a issue when trying to implement this post by Vladki.

3. when picking vehicles in depot, info about available liveries would be very nice.

It is easy to list the "livery" that a vehicle has, but note that the data that each vehicle has is a livery name, not a livery scheme name (or index number).
For example in pak128.Britain-Ex, one vehicle shows to have a livery called "Centro". Then which livery scheme should I choose? - The answer is "WMPTE".
Yeah, I took a mean example. 

In the current livery scheme system, the livery scheme is the parent and the livery is the child.
Choose a parent in the depot or linemanager then the newest living child is given to the vehicle. But the child does not know who is the parent.
What you get by looping over the vehicle is the name string of the children, not the parent information(index or name).
If you are looking for a parent from a child, you must ask the parents in turn asking if this child is your child.

There is currently no function to get the livery scheme index from the livery name, but is it wise to run a loop that checks the livery names of all vehicles and gets the livery index? For example, if one vehicle has five liveries, have to go five times to find a parent (´・ω・｀)
We can also buy old vehicles, so we need to check many vehicles in the depot. And I think this search loop seems very wasteful as one vehicle may have many children with the same parent.
Considering the current configuration of the livery system, I decided to specify the waytype.


EDIT:
IMO, the depot GUI is not suitable for changing or checking the livery of individual vehicles. And I think that Ves's vehicle manager is suitable.
When you select a vehicle from the list, the vehicle livery is already fixed. If you want to change it, you need to sell it or use linemanager.
Also, stored vehicles do not display the correct liveries in the depot.

[Vladki]

I do not like limiting liveries to waytypes. It will limit addon creators who might want to make "fictional" liveries, e.g. British rail livery for bus replacement service. I think the best way would be to add reverse pointer to each livery, pointing back to its livery scheme. Then the depot could easily enumerate liveries of all displayed vehicles, as well as line window all vehicles in selected line.

Also I have observed, and do not know if it is a bug or not - vehicles do not change their livery e.g. from BR-green to BR-blue, when the new livery is available, but only when you manually reassign the livery again in line window. I thought it would happen automatically at some point. But now I understand, it can't happen without the knowlege of assigned livery scheme.

However I'd prefer if timeline for liveries could be completely turned off while keeping the timeline enabled for other purposes (e.g. vehicle timeline). And to be able to select any of avialable liveries (not just schemes), to partially replace the player colors in network games. This would need a dual selection (scheme + livery), with perhaps one or two special options - use current livery and keep it forever, and use current livery and repaint automatically to newer if available.

[jamespetts]

This is an interesting idea - thank you for this. May I ask whether this system allows one livery to have multiple waytypes (but not all waytypes) so that, for example, one could have a livery scheme for aircraft and road vehicles only?

As to Vladki's reference to liveries not updating automatically: this is intentional. When overhauls are implemented, the idea is that the livery will update on overhaul, which will help to give a visual indication of (approximately) when vehicles were last overhauled. It is also realistic that liveries change only at the point of overhaul normally (although players will be able, as now, manually to update the livery by re-selecting the scheme).

[Ranran]

May I ask whether this system allows one livery to have multiple waytypes (but not all waytypes) so that, for example, one could have a livery scheme for aircraft and road vehicles only?

Yes, I modified the code to support multiple waytype registrations.

The description method of the definition is as follows.

Code: [Select]

livery_scheme[38] = WMPTE
livery_scheme_wt[38][0] = road
livery_scheme_wt[38][1] = track
livery_scheme_wt[38][2] = tram_track



.

I do not like limiting liveries to waytypes. It will limit addon creators who might want to make "fictional" liveries, e.g. British rail livery for bus replacement service.

Even if the waytype is not limited, it is meaningless if there is no pak with the corresponding livery. The pakset author knows if it is available and players will not want to show useless options.
As for addon, I think it is the same in the current version. For example, Boeing airplanes are all over the world, so if you make a china airlines livery addon, there is currently no china airline available in britain-pakset. But you can add it by editing simuconf.tab. You can add a waytype of livery scheme by editing simuconf.tab too.

Then the depot could easily enumerate liveries of all displayed vehicles

I think that enumeration of the individual vehicle's livery in the depot is not suitable. It has various problems.
1. There is not enough space to display a lot because livery can register a lot. In addition to the livery name, we also need to indicate which "livery scheme" it belong to.
2. There is no point in displaying the livery belonging to the same livery scheme. In the current specification, only the latest livery applies.
3. One of the goals of this patch is to make the list slimmer and easier for players to select. Displaying individual liveries further expands the list and provides more options that are not applicable to some vehicles. We also need to prepare a translation for the livery.
4. The selector in the depot is very unsuitable for selecting vehicle-specific liveries. Because the vehicle information is displayed only when the mouse is over the vehicle panel. This means that no vehicle is selected when choosing a selector. This is the main reason why displaying the livery in the selector here is not suitable.
5. If the livery scheme timeline is turned off, which one of the same livery scheme will be selected? The amount of work to change the code is large because of inconsistency with current specifications. (´・ω・｀)

I understand the benefits of increasing the available livery in network play. The ability to select the vehicle's livery can be easily achieved with Ves's vehicle manager.
Because in the dialog specialized for vehicles, it is easy to get and rewrite the list of vehicles livery that the vehicle has.

[Vladki]

Maybe there's a little misunderstanding about enumeration...

What I had in mind is, that if there would be pointer from vehicle -> livery -> scheme, then it would be easy to iterate over visible vehicles in depot (or vehicles used in selected line/convoy) to find out which liveries to show in livery selector. No need to limit them by waytype, which would still show some useless liveries. Also it would be needed during overhaul to find the current livery that sould be applied. Showing available livery schemes in vehicle details would be a nice bonus. But at least the number of livery schemes is an improvement.

For multiplayer what would be most useful would be a way to specify default livery for all vehicles of given waytype for each player

[Phystam]

Hello, merry Christmas!
I hate to tell you, actually we do not use the livery type feature for pak256-Ex.
As you can see, JNR EMU series 103 has lots of color schemes to use. JNR should be listed in the livery scheme selector, but then you cannot select these colors in the current implementation. The livery scheme is useful to simulate changing liveries by timeline, but if multiple liveries are available at the same time, there is no way to select one from the livery list.
It is helpful for us to have the color selector.

[Ranran]

vehicle -> livery -> scheme

Perhaps it is not that simple. vehicle can have multiple liveries, and a livery can belong to multiple livery schemes.
I think it is necessary to round robin all the liveries and livery schemes by the number of showing vehicles and the liveries that vehicles have.
I will try to implement it that way.

As you can see, JNR EMU series 103 has lots of color schemes to use. JNR should be listed in the livery scheme selector, but then you cannot select these colors in the current implementation. The livery scheme is useful to simulate changing liveries by timeline, but if multiple liveries are available at the same time, there is no way to select one from the livery list.
It is helpful for us to have the color selector.

How can it be achieved in the depot dialog? I mean how can we select a livery list while selecting 103 series? When selecting the list, the mouse has already moved from the panel of 103 series, so the 103 series is no longer selected. The current depot dialog has no choice but to show all options for vehicles that can be displayed in that depot. The same result can be obtained by using the livery scheme instead of the 103 series color. The function you want may be easily achieved with another dialog. I think the depot dialog is not suitable for realizing it.
In my personal opinion, I prefer to see different colors displayed side by side because I can compare them. However, changing colors with upgrade, as mentioned earlier, is problematic.

I think that changing the livery without going through the livery scheme should be considered as a separate function.

[jamespetts]

I agree with Ranran that displaying individual liveries (rather than schemes) in the depot dialogue is likely to overload it.

Phystam - if you want to use the liveries feature to implement the various colour schemes in Pak.256-Ex, then what you need to do is define a livery scheme for each of the colours that you want to use. The livery system is flexible enough to allow for either multiple different liveries at the same time or multiple liveries in succession.

Use different livery schemes if you want multiple different liveries available at the same time. Use different liveries within a scheme if you want multiple consecutive verions of the same company's livery that evolve with time. You can, of course, have both at once. So, for example, you can define this as follows:

Code: [Select]

livery_scheme[0] = Yellow
retire_year[0] = 1990
retire_month[0] = 4
livery[0][0] = Bright-Yellow
intro_year[0][0] = 1900
intro_month[0][0] = 1
livery[0][1] = Dark-Yellow
intro_year[0][1] = 1950
intro_month[0][1] = 5

livery_scheme[1] = Blue
livery[1][0] = Navy-Blue
intro_year[1][0] = 1900
intro_month[1][0] = 1
livery[1][1] = Royal-Blue
intro_year[1][1] = 1960
intro_month[1][1] = 4

You can thus have a "blue" and "yellow" livery scheme, but (for example) the shades of blue and yellow can change over time. If you only wanted one shade for all time, you could simply define a single livery in each livery scheme.

As to limiting livery schemes to waytypes: provided that the default is that they are not limited by waytype, and the pakset author can choose which, if any, liveries are limited by waytype, then this is not a fundamentally bad idea, as the pakset author will know what to limit and what not to limit. However, it is potentially sub-optimal in some respects, since it will increase the maintenance overhead for pakset authors to have to keep the list of available waytypes for a livery in sync with the vehicles to which the livery has been applied. With a large number of livery schemes, as in Pak128.Britain-Ex, this is a lot of work, and there is much potential for it to go wrong (for example: the Great Western Railway operated 'buses for a short period in the 1920s. If I were to introduce any new 'buses in the GWR livery, I should have to remember to alter the GWR livery scheme to allow the road waytype; but it would be easy to forget to do this, leading to the GWR livery not being able to be selected for road vehicles).

Ideally, this process would happen automatically; it is certainly technically possible to do it this way as has been discussed, but it may be that it is too large a job to be feasible.

[Ranran]

I think I succeeded in automatically creating a list of available livery schemes.
This does not require editing simuconf.tab. 
I would appreciate it if you test it. (´・ω・｀)
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/auto-available-livery-scheme-list-creation

[jamespetts]

Excellent - I have just tested this and it works very well. Now incorporated - thank you!

[Vladki]

Ranran, you say that vehicle can have multiple liveries, and a livery can belong to multiple livery schemes. Are you sure that a livery can belong to multiple schemes? I thought it is the other way around. A scheme has multiple liveries, but a livery is part of exactly one scheme.

[Ranran]

I thought it is the other way around. A scheme has multiple liveries, but a livery is part of exactly one scheme.

What I said is like this picture:

Livery C belongs to Scheme1 and Scheme2.

Are you sure that a livery can belong to multiple schemes?

That is possible because the current specification is not restricted.
Children do not know their parents. Parents do not care about others' children. Parents only know their child.
This works correctly and currently does not cause any problems.