Improvement of the convoy detail window

[Ranran(retired)]

Gentlemen and gentlemen, and boys and boys. Welcome to teriyaki house. I kept you waiting for a long time. 
Ranran took a break for a while and nurtured the spirit. 
So I am now refreshed and restart the cooking of this patch. (´・ω・｀)

Please relish the new UI seasoned by Ranran. 

Convoy detail window has been greatly Ranranized by introduction of convoy formation picture this time.

As you can see, it was again divided into three tabs. But unfortunately there is no added button so it works fine. 


IMO, at present, the convoy detail window is easily polluted with cargo information and is inconvenient.
Extended is more informative than the standard, and further implementation of the planned overhaul will cause more mess.

So I divided the information into three groups.
(1) Information on vehicle specifications
(2) Vehicle capacity and cargo information
(3) Information on vehicle maintenance


Upper area:
Some information has been moved into the tabs to make the tab area wider.
Added display of tile length.
The number of vehicles was added to the number of station tiles. (This is the same as the depot window)
Many texts are shared with the depot dialog so there is almost no need to add a translation.


Convoy formation picture:
From top to bottom
- Cars number: Purple numbers indicate vehicles currently having upgradable targets. Bidirectional convoy is numbered in reverse on return trip. The locomotives on the front side are numbered L1, L2....
- Shaped vehicle bar: The shape corresponds to whether or not it can be at the front/rear and bidirectionality. The color will be displayed for maintenance.
- Loading status bar: Gray means can not be loaded, Yellow means empty, Orange means full loading, Dark purple is overcrowding, other than that is lime green.
If there are multiple classes, the bar will be split.
- Goods category symbol.

[General tab]

This is intended to make it easier to look at the whole spec.
I don't speak English so I don't know what name is appropriate for this tab. Is "specs" suitable for this?
The vehicle number is displayed to make it easy to understand the correspondence with the formation picture above.

BUG FIX:
It has been integrated because there was a duplicate display on tilting equipment this way so far.



[Cargo tab]

This tab displays the same image as the formation picture.
A loading bar is displayed, which corresponds to the color of the goods.
However, this bar was regrettable and could not be sorted by goods. (´・ω・｀)
It would be helpful if you could get help on this issue.


The ratio to overcrowding capacity is visualized.



[Maintenance tab]

This tab displays the same image as the formation picture.
Information about upgrade is here. Information on overhauls should be put here too.
You can also check the information of the applied livery scheme.




How's it?

The github repository is here.
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/basic-constraint-extension
Now you can taste this code. 

I would appreciate your feedback. Thank you.

(´・ω・｀)らんらん♪

[Matthew]

Gentlemen and gentlemen, and boys and boys.

This is the truth, but hopefully it will change sometime soon.

Welcome to teriyaki house.

JA: どうもありがとう!

EN: Thank you so much!

The smell coming from the kitchen is soooooo good! 
The menu even has pictures and the food looks fantastic. 

I know that we must wait until this patch has finished cooking, but I think it will be very enjoyable when it is ready! 

Upper area:
Added display of tile length.

The tile length display is helpful.

[General tab]
<snip>
This is intended to make it easier to look at the whole spec.
Is "specs" suitable for this?

The Oxford Advanced Learners Dictionary says "specs" are "a detailed description of something, especially the design and materials needed to produce something".

The OALD says that "specs" is North American English. I think Extended uses British English, so it should be "spec". However, a quick look at some recent data suggests that both are now used in British English.

[Cargo tab]
This tab displays the same image as the formation picture.

This also looks very clear and helpful.

As the formation picture already provides the information, perhaps the on-map graphic for each vehicle could be displayed here? IMHO it would look nicer, though it would not add any more information.

[Maintenance tab]
This tab displays the same image as the formation picture.
Information about upgrade is here. Information on overhauls should be put here too.

This area (and the picture in the Upper Area) are the most important parts of the whole patch, because (as you said) they prepare the UI for the convoy maintenance, re-combination & overhaul system. If players become familiar to the new graphical symbols now, then it will be easier for us to adapt to the new depot UI later. So this patch is more than a fix to one window: it's a contribution to the top current development projects.

You can also check the information of the applied livery scheme.

This is especially helpful as I don't this information is available anywhere else.

I would appreciate your feedback. Thank you.

As well as the detailed comments, I would also like to note one big error and to suggest a couple of possible extensions.

I don't speak English so I don't know what name is appropriate for this tab.

I completely disagree!  Based on your posts in this forum, you can certainly write technical English, which is what is needed here. If your English is adequate for an international engineering project, then you have already reached a high standard. 
(I taught English for many years and this is my professional opinion based on the available evidence).

The overall design of this window looks very good. However, if you are moving to a design with tabs, would it be helpful to delete the Convoy Details windows and place all this information as tabs in the main Convoy Information window? The disadvantage of this plan is that you would have to move some buttons. I know that the buttons and you have had a bad relationship in the past. Maybe you can patch up the relationship...? 

Another idea would be adding a drop-down box to change the livery of the vehicle(s) in the Maintenance tab. The current livery drop-down box (in the Lines Window) does not work unless players use very short stop names.

But these two ideas are extension requests. The changes in Ranran's patch seem to me to be entirely helpful.

[Ranran(retired)]

Thank you for your feed back.

The Oxford Advanced Learners Dictionary says "specs" are "a detailed description of something, especially the design and materials needed to produce something".

The OALD says that "specs" is North American English. I think Extended uses British English, so it should be "spec". However, a quick look at some recent data suggests that both are now used in British English.

Gneral tab has been changed to cd_spec_tab to be translatable individually. (cd stands for convoy detail.)

As the formation picture already provides the information, perhaps the on-map graphic for each vehicle could be displayed here? IMHO it would look nicer, though it would not add any more information.

The first layout I came up with was to arrange the vehicles side by side and create a table under them that shows the value of the specs.
It will be a horizontal layout in long convoy.
That is, tons of "Weight", "Capacity" things are displayed only once.
But the biggest problem was that the name of the vehicle was quite long. It will not fit in the table. (´・ω・｀)

The result is a layout that follows the current one.

There are some reasons for not using vehicle pictures in tabs other than spec tab.

First of all the size of the vehicle breaks the layout.

When the vehicle is large, the area on the right is largely cut.

The numbers were added because it was difficult to distinguish when the freight wagons or passenger cars of the same appearance are connected in series, but I thought that it would be easier to understand the relationship if it was combined with the Formation picture and the picture above.

For example, it is intended to be easy to identify when one of the wagons is outdated.
When the overhaul function is added, it is assumed that the vehicle requiring the overhaul is immediately identified by the color.

Based on your posts in this forum, you can certainly write technical English, which is what is needed here. If your English is adequate for an international engineering project, then you have already reached a high standard.

It is mainly due to my ghost translator - Dr.GoogleTranslate.  However, she needs to be aware that she is not good at translating Japanese. 
In many cases, there is no subject in Japanese, so it is necessary to add a subject and have him translate. Sometimes I break up into sentences and then restructure it.  She sometimes makes funny translations so I change sentences at that time.
Also, there is a big gap between everyday conversations and technical terms and often she can not even understand.

However, if you are moving to a design with tabs, would it be helpful to delete the Convoy Details windows and place all this information as tabs in the main Convoy Information window?

I know that the convoy detail window has been integrated into the convoy information window in the current standard.
However, I think there are advantages to being split into two tabs. You can open two windows at the same time and check them side by side.
Also, extended has much more information than standard. And convoy information window mainly gathers information of the whole one convoy. For example, the cargo information displayed there is cargo information of the convoy total.
The convoy detail window focuses on the vehicles that make up the convoy. For example, the cargo information displayed there is a cargo for each vehicle.
In that way, I think that there is currently a clear differentiation between the two windows.
However, the point that I am currently unhappy with the convoy detail window is that I can not return to the convoy information window from that window. 

[jamespetts]

I am now getting round to looking through the backlog of splendid Ranran GUI (and other) patches - my apologies for not having had a chance to look into these before. The screenshots do look quite splendid.

I am afraid that I do not have time to test this one properly this evening, and I believe that this and its related patches are very much worth some thorough testing, as they look most promising.

One thing that will help me to organise my testing work is to know how the various branches relate to each other; I notice that this and the basic couple constraint are related, but there is also a mixed load prohibition sub-branch of the basic couple constraint branch, so the picutre seems quite complex.

Would it be possible to have a brief summary of the outstanding Ranran patches and how they relate to each other so that I can plan and organise my testing of these efficiently? It would help to have a suggestion as to the best order in which to test them. I assume for these purposes that the more recent acceleration curve patch is independent of the others, and I have already tested and reported back on this.

This is splendid work from what I can see so far, and my apologies again most profuse for not having been able to test this to date: I did want to make sure that I dedicated sufficient time to doing so to do it justice.

[Ranran(retired)]

(1) basic-coupling-extention
　　　┃
(2) Improvement of the convoy detail window
　　　┃
(3) upgradable-symbol
　　　┃
　　　┣━(4) mixed-load-prohibition
　　　┃　　　　　　　┃
　　　┃　　　　　　　┗・・・・・ (9) upgrade target display on the depot dialog
　　　┃　　　　　　　　　　　　　　　　　↑
　　　┗━(5) coupling-group 　 　　　　　 ┃
　　　　　　　　　　　　　　　　　　　　　┃
(6) Improvement of the depot dialog ━━━━━┛
↑　　　　↑
┃　　(6')  display-the-starting-acceleration
┃
(7)display-which-livery-scheme-this-vehicle-has

EDIT: add some patch


Since makeobj and pakset need to be updated, I think it's better to think of (1)～(4) as a series of patches, rather than splitting them into multiple pieces.
(5) is stuck so please ignore it.
I think (3) is a small patch that focuses on changing the appearance of the GUI.
(4) is also a small change.
(1) and (2) are closely related core parts. I think we need to focus on testing here but I also forget a lot of content. (´・ω・｀)
The improvement of the display system of (2) makes it clear that (1) is functioning properly.
(9) is a future plan. This uses the symbol in (3) and the formation picture in (1).
(6) is ongoing and includes improvements such as acceleration display. It is started independently.

The currently available branch is here.
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/mixed-load-prohibition

I resolved the conflict last night by merging the master branch of the james repository. It may still be incomplete (I suppose I still need to do an extended_revision conflict fix), but as far as I checked yesterday it's possible to start the game and testing those features.

Testing requires a pakset paked with a new makeobj. In addition, it is necessary to change the dat of pakset.
If you want to test immediately, please download pak128.Britain-Ex which was paked for testing from my Google drive. This is as of July last year and is not up to date.
Vehicles that have been updated since then will need to make new changes, which may take some time.
Britain-Ex branch I am working on is here.
https://github.com/Ranran-the-JuicyPork/simutrans-pak128.britain/tree/extend-coupling-constraint

[jamespetts]

Thank you very much for this: this is helpful. Because there is so much to test here, I will do the best that I can to give sensible observations from various rounds of testing.

The first round of testing is conducted with the existing pakset without it being recompiled. Observations are in no particular order at this stage.

(1) Loading and saving of current and somewhat older saved games appears to work correctly, suggesting that versioning is correct.
(2) The overall appearance of the convoy detail window is much improved.
(3) The range of vehicles with an unlimited range is given as 0km, whereas it should state "unlimited" whenever the number is zero.
(4) The graph in the cargo section dealing with loading is splendid.
(5) The word "cargo" would be better changed to "payload", since it is inapposite for passengers.
(6) The detail window seems to appear in the top left hand corner of the screen whenever it is invoked, rather than next to the window as is the default behaviour.
(7) The warning icon next to the obsolescence increase looks very good.
( 8) The symbols for vehicles indicating their coupling status look very good and are likely to be very useful for rail vehicles especially.
(10) The name of the livery scheme, rather than the individual livery, should be given, as the names of individual liveries were never intended to be displayed in the game and there are no translation texts for them, nor code to allow for this translation.
(11) The livery scheme name would make more sense in "Spec" than "Maintenance".
(12) I get a crash (segfault) that I cannot reproduce in the master branch when selecting "show out of production" in an aircraft hanger at 210,35 from the current Stephenson-Stevens server game (after switching to the player "Eastern Oceanic Enterprise").
(13) Building a rail depot in 1883 on a fresh game causes a segfault crash (this may not occur with the recompiled pakset; but we should not have crashes even without the recompiled pakset)
(14) Attempting to build a locomotive and then switching to the passenger carriages tab in demo.sve with the un-recompiled pakset causes a crash/segfault.

As a result of the segfaults, I switched to testing with the compiled pakset that you provided. Further observations with this pakset are as follows.

(1) I am not sure that the "upgrade is not available yet" is useful, since players and their transport companies do not have an oracle to tell them what the future will hold; it is inconsistent with the rest of the depot window not giving information about the future, and I think that it would be better removed. The "upgrade available" icon, however, is excellent and will be extremely useful.
(2) It would be helpful to show the upgrade icons in the upper pane of the window next to the vehicles in the assembled convoy if possible, but this is not essential if this would be too much work.
(3) The goods symbols in the convoy detail window are a delight and help to make it much clearer.
(4) The base profit per km when full is shown in red when the number is zero. This suggests that there is something wrong; but this includes vehicles with no cargo capacity, such as tenders and locomotives. I suggest not having this figure in red where the cargo capacity is zero.
(5) The mixed load prohibition is an excellent idea. I have not had a chance to test this beyond checking for it being noted in the UI (we are missing a translation text for this, but I expect that you know that), but this will enhance the game.
(6) I cannot reproduce the crashes to which I refer above with the recompiled pakset.
(7) The upgrade indications in the convoy detail window are very useful, but it would be helpful to have the capital cost of the upgrade shown there as well as the maintenance cost of the upgraded vehicle.

I have not yet tested the coupling constraint features in the pakset as I thought that it would be better to test these basic points before moving onto things that require updating in the pakset.

Incidentally, the idea of a group constraint looks interesting - may I ask where you are stuck with that? You may have posted it when I was inactive and I may thus have missed it: my apologies.

In any event, thank you for your excellent work on this. This really does enhance the UI both functionally and aesthetically.

[Ranran(retired)]

Thank you for testing. I have made some fixes.

About the first round of testing:

(3) The range of vehicles with an unlimited range is given as 0km, whereas it should state "unlimited" whenever the number is zero.

Thank you for point it out. I seem to have made a mistake in the conditional expression trying to hide this when the range is 0. I tried to reduce the number of rows as much as possible.
Is it better not to turn off range display in any case?

(5) The word "cargo" would be better changed to "payload", since it is inapposite for passengers.

Change completed.

(6) The detail window seems to appear in the top left hand corner of the screen whenever it is invoked, rather than next to the window as is the default behaviour.

This seems to work the same in the current version. I don't think anything has changed in this regard. Also I do not know the code on how to operate the opening position of dialog.

(12) I get a crash (segfault) that I cannot reproduce in the master branch when selecting "show out of production" in an aircraft hanger at 210,35 from the current Stephenson-Stevens server game (after switching to the player "Eastern Oceanic Enterprise").
(13) Building a rail depot in 1883 on a fresh game causes a segfault crash (this may not occur with the recompiled pakset; but we should not have crashes even without the recompiled pakset)
(14) Attempting to build a locomotive and then switching to the passenger carriages tab in demo.sve with the un-recompiled pakset causes a crash/segfault.

These would have caused a crash if there was no upgradeable icon associated with patch # 3. I think I have fixed it, please confirm.

(10) The name of the livery scheme, rather than the individual livery, should be given, as the names of individual liveries were never intended to be displayed in the game and there are no translation texts for them, nor code to allow for this translation.

I thought that it would be better to integrate this change with another patch before proceeding. So I comment out this part once.
My plan determines whether the current livery matches the livery scheme set in the convoy or its line, and changes the font color.
If they match, check if it will be changed by overhaul and change the font color. That is, whether it is an old livery.

Apart from that, there are requests to change the livery individually as discussed in other threads.
If player turn off the timeline or  may want to continue using the old livery.

I think that overhaul does not require a livery update if no livery scheme is selected for line or convoy. If convoy has a variety of different livery schemes, it may be that the player intended to do so. There are some cases where old liveries continue to be used. For example, the company split and one kept using it, while the other chose another. As other threads discussed, in the real world, it sometimes choose old liveries to please fans. (In this case the players themselves are pleased )

(11) The livery scheme name would make more sense in "Spec" than "Maintenance".

I think if the livery is likely to change due to the overhaul, on the maintenance display is also useful. And I am planning a change as described above.
On the "Spec" tab, we can see the livery appearance, so I think it is necessary here too. So I changed it to show in both.

Further observations with this pakset are as follows.

(1) I am not sure that the "upgrade is not available yet" is useful, since players and their transport companies do not have an oracle to tell them what the future will hold; it is inconsistent with the rest of the depot window not giving information about the future, and I think that it would be better removed. The "upgrade available" icon, however, is excellent and will be extremely useful.

I think the end-of-production date announcement is information about the future. People who know the history of the vehicle know. But anyone who doesn't know it can get the information. It just takes time. If one has already played a future period in another game, may know that. But they cannot throw away that knowledge.
We can also find out by checking at the dat file. For example, vehicle upgrade information for pak.britain-EX is available on the github repository. Hiding such information has no meaning in the modern information society. It just inconveniences certain players.
Such discussions are often seen in Japanese games, and I have agreed with such thoughts since I saw such an opinion there.

However, on the other hand, the display of the future seems a little annoying, so I think it is better to make it smaller or increase the transparency.

(2) It would be helpful to show the upgrade icons in the upper pane of the window next to the vehicles in the assembled convoy if possible, but this is not essential if this would be too much work.

Because the width of the upper panel is 1/2, the icons may feel a little noisy. Also, it looks like a misleading arrangement because the vehicle is facing diagonally.

For consistency with the panel below, the upgrade icon should be in the upper right corner of the formation picture, but it doesn't seem to have enough space. Placing the upgrade icon in the lower panel in the upper left corner might be misleading because it is close to the formation picture in the upper panel.
EDIT (Jan. 30): The vehicle list shows the number of possessions at the upper left, so the upper left display is impossible. That was the reason I added the upgrade symbol in the lower right. (´・ω・｀)

An alternative is to display the vehicle number at the top and change its color. Standard has the display of the vehicle number of the upper panel. (It is only displayed when the mouse hovers though.) This style is consistent because it is used in the convoy formation picture of the convoy detail dialog

(4) The base profit per km when full is shown in red when the number is zero. This suggests that there is something wrong; but this includes vehicles with no cargo capacity, such as tenders and locomotives. I suggest not having this figure in red where the cargo capacity is zero.

This is exactly from the standard. Looking at that part of the code, you will find the following description:

Code Select Expand


// Revenue for moving 1 unit 1000 meters -- comes in 1/4096 of simcent, convert to simcents
// Excludes TPO/catering revenue, class and comfort effects.  FIXME --neroden
sint64 fare = v->get_cargo_type()->get_total_fare(1000); // Class needs to be added here (Ves?)

The information currently displayed there is inaccurate, but I am afraid that I can't correct it because I don't know much about the fare calculation.
Anyway, the red display has been removed.

(5) The mixed load prohibition is an excellent idea. I have not had a chance to test this beyond checking for it being noted in the UI (we are missing a translation text for this, but I expect that you know that), but this will enhance the game.

I re-uploaded the test save I previously uploaded to my google drive. Please start convoy in the depot at the right bellow and observe for a while.

(7) The upgrade indications in the convoy detail window are very useful, but it would be helpful to have the capital cost of the upgrade shown there as well as the maintenance cost of the upgraded vehicle.

The upgrade cost was already listed next to the name, but it might not have been possible to see it without enlarging the dialog.
Therefore increased the line there listed upgrade capital and maintenance costs of the upgraded vehicle.



Additional changes:
The vehicle age is displayed next to the date of manufacture.

Incidentally, the idea of a group constraint looks interesting - may I ask where you are stuck with that? You may have posted it when I was inactive and I may thus have missed it: my apologies.

In the experimental version I prototyped, the "string" of group_name was registered in the vehicle like "livery name". Vehicle has its own group_name and multiple group_constraint [prev/next]. Then, compare the groups of other vehicles with each other and give a loose coupling permission. (The constraint_group constraint of the vehicle is compared with the group to which the vehicle belongs.)
In other words, constraint and constraint_group exist in parallel and vehicle can have two names. (group name can be duplicated)
When this system is implemented, existing constraints will be specific to "any" and unique constraints.
ACarlotti's proposal was to integrate them. It seems more efficient. However, I don't know much about how to register the name of an object. (´・ω・｀)

[jamespetts]

Thank you for your futher work on this and detailed reply. I will not have time to test further until the evening/week-end, but some brief observations at this stage, again, in no particular order.

1. As to displaying the future: there may be a case for removing the "available until" date (unless perhaps this is coming within the next year); but I should be interested in feedback from players on this potentially complex issue.

2. In relation to liveries and livery schemes: the idea was that overhauls would update the vehicle to a different livery scheme if the current livery scheme had become obsolete so as to maintain an up to date livery on vehicles at all times. A good way of doing this might be, if there are multiple possible schemes, to check what other livery schemes that the player is using and update the livery scheme to whichever one of those available for the vehicle that the player uses the most. We do want to avoid out of date liveries remaining after overhauls if at all possible. However, the idea of using different coloured text for showing that the currently applied livery is an out of date livery in the scheme is a good idea. Perhaps it would be even better to have a different colour again for when the whole scheme is obsolete?

3. In terms of the range display, I think that it is better to retain "range: unlimited" so that players looking for range information can find it clearly rather than having to search through everything to see whether it is there or not.

4. As to coupling groups - I recall the discussion now. I favour a somewhat different solution, based more closely on the way constraint system, in which one has different classes of constraints which may be combined and the different classes have different logic associated with them. This would allow for a more powerful and flexible system that would better replicate real world systems. But perhaps that is something for another day - the basic system that you have been working on is also useful.

[Phystam]

FANTASTIC! I will test your complete patch using pak256!
(But I have to add constraint_group features for each type of vehicles.)
Thank you for your great work.

[Ranran(retired)]

1. As to displaying the future: there may be a case for removing the "available until" date (unless perhaps this is coming within the next year); but I should be interested in feedback from players on this potentially complex issue.

Ideally, you should set future display on/off setting in simuconf.tab.
As mentioned earlier, hiding information can be a handicap, but some people prefer it. Especially for the first play. However, on the other hand, in network games, the difference in knowledge can be a handicap. Therefore, I think it is fair to disclose information.
I just recently experienced this kind of inconvenience at transport fever 2. (Sadly there are few Japanese vehicles in it. So my knowledge was primitive.) (´・ω・｀)

A good way of doing this might be, if there are multiple possible schemes, to check what other livery schemes that the player is using and update the livery scheme to whichever one of those available for the vehicle that the player uses the most.

As an easy way to change it, it's a good idea to remember the scheme you chose last time and add it to the default options.
There was an idea in Vladki's request that players could set a default scheme for each waytype, but I think this has the issue that the livery scheme may be abolished.
In that case, the selection scheme may be reset without the player knows it, and may not be a very reliable system.
Secondly, I think there is an issue that the current selector always selects something because there are no empty choices. In most cases, a default choice that does not apply is selected. Obviously, with the current spec, the choice at the bottom of the list will have the highest count.
Is there any problem with adding empty choices?

Perhaps it would be even better to have a different colour again for when the whole scheme is obsolete?

If the meaning of the vehicle display color is consistent, it will be easy for players to understand. So the old one is royal blue and navy if the delivery scheme is abolished. Or navy(obsolete) and red/grey(can not be selected).

4. As to coupling groups - I recall the discussion now. I favour a somewhat different solution, based more closely on the way constraint system, in which one has different classes of constraints which may be combined and the different classes have different logic associated with them. This would allow for a more powerful and flexible system that would better replicate real world systems. But perhaps that is something for another day - the basic system that you have been working on is also useful.

Group coupling simplifies the coupling rather. For example, consolidate the 10 constraints currently described into one group.
This will greatly simplify the work of pakset. Also, when adding a vehicle, the trouble of renewing is saved. Also, the current constraint is too severe and vulnerable to errors. This can be problematic when considering constraints in recombination. Thus I think this is for basic design.

(But I have to add constraint_group features for each type of vehicles.)

Note that the constraint_group feature has nothing to do with the patch currently in progress, and progress has been stuck.
But testing the features will be very helpful. 

[Mariculous]

1. As to displaying the future: there may be a case for removing the "available until" date (unless perhaps this is coming within the next year); but I should be interested in feedback from players on this potentially complex issue.

I don't agree.
One could, for sure argue that one could not know the future before in the real world.
However, most often vehicles were "discontinued" because there were simply no new orders for that vehicle.
Thus, I don't even think that setting the "built until" date to real worlds date of the last produced vehicle of that type, not allowing to purchas the vehicle after that date, was a good design decision for the above reason.

Another aspect that I don't like about that intransparency of hiding the "available until" date is, that people could simply look it up in the code anyway or after playing the timeline a few times, some players will even know the dates, so removing it does not give any advantage whilst being quite annoying imho.

[Ves]

Regarding the liveries and their subliveries, I had thought for the vehicle manager to simply name them like this:.

Code Select Expand


British Railways 1948-1951

British Railways 1951-1956

British Railways 1956-1966

British Railways 1966-1979

British Railways 1979-1986

... taking the intro dates, as well as the livery expiration date, as start- and endpoints for each sub-livery.

Wouldnt this be a universal good way of doing it?

[jamespetts]

I have now had a chance to test this further - I can confirm that issues 3, 5, 10 and (second) 4 are resolved, and 6 is confirmed to be the same issue on the master branch. I notice that the livery name and reference has been removed from the convoy detail window for the time being, which is probably sensible for the time being until this can be considered further in a different branch.

As to displaying the future, perhaps it is sensible to have this as a simuconf.tab option; something like show_future_vehicle_information=1, which, if disabled, would suppress information about vehicle upgrades and discontinuation dates until 1 year before the upgrade becomes available or the production is to be discontinued. That is probably the better way of catering for varying tastes in this context.

In relation to the pakset, can I check whether the pakset itself (as opposed to makeobj) needs any changes other than:

(1) the upgrade symbols;
(2) the goods category symbols; and
(3) the mixed load prohibition,

and that the coupling constraint feature is optional, pakset authors being free to continue to use the old system if they choose?

In any event, this is splendid work.

Edit: I should also note that I have tested the mixed load prohibition, and this seems to work well, although it is missing a translation text. Can I ask for you to list all the texts that are missing translations so that we can consider how best to translate these? That would be very helpful.

[Ranran(retired)]

Thank you for testing.

In relation to the pakset, can I check whether the pakset itself (as opposed to makeobj) needs any changes other than:

(1) the upgrade symbols;
(2) the goods category symbols; and
(3) the mixed load prohibition,

(1) Not displayed if there is no symbol. It works as before. It is convenient for the player to have a symbol because it can be a simple one such as an upward arrow.
(2) If pakset has no goods symbol, no freight category symbol is displayed.
However, passengers, mail, and special (unique) freight display their symbol.

(3) mixed_load_prohibition = 1 must be described only for vehicles for which mixing load is to be prohibited. For example, bulk open wagon or tank wagon with one container. If there is no mixed_load_prohibition description, the behavior will be the same as before.

I should also note that I have tested the mixed load prohibition, and this seems to work well, although it is missing a translation text. Can I ask for you to list all the texts that are missing translations so that we can consider how best to translate these? That would be very helpful.

Texts that need translation for other languages are added to en.tab so that I don't forget them. There are the ones added at the bottom of en.tab.
But it always creates conflicts when merging. (´・ω・｀)
However James made me realize that I didn't add the mixed_load_prohibition English text, so I added the its English text now.

Code Select Expand

helptxt_can_be_at_rear
End vehicle
helptxt_intermediate
Intermediate vehicle
helptxt_powered_vehicle
Powered vehicle
helptxt_unpowered_vehicle
Unpowered vehicle
Select vehicles to make up a convoy
Select vehicles to make up a convoy
Vehicle bar shape legend:
Legend:
cd_spec_tab
Spec
cd_payload_tab
Payload
cd_maintenance_tab
Maintenance
No load setting
No load setting
Applied livery scheme: %s
Applied livery scheme: %s
%i month
%i month
%i months
%i months
(mixed_load_prohibition)
(Mixed load prohibition)
Upgrade available
Upgrade available
Upgrade is not available yet
Upgrade is not available yet
Upgrade will be available in the near future
Upgrade will be available in the near future
Shunting. %s left
Shunting. %s left
Changing direction. %s left
Changing direction. %s left

These English must be verified to be correct English. Some have been calibrated once by James.

EDIT:

and that the coupling constraint feature is optional, pakset authors being free to continue to use the old system if they choose?

The behavior of convoy itself is almost the same as before, but you may see some strange (but I don't think it's out of the rules) formation picuture. I think this point needs to be observed carefully.

EDIT2:
When an old makeobj is used (for example, when prev = any is not described in wagon of next = any), the operation of brake van differs from before.
Because it doesn't have a constraint setting on the front side, it is considered a vehicle that can come to the rear when reversing in the new system.


EDIT3&4:
Add forgotten translation items

[jamespetts]

Thank you for the clarification - may I ask briefly about what the strange behaviour is that you mention under edit 1?

[Ranran(retired)]

Thank you for the clarification - may I ask briefly about what the strange behaviour is that you mention under edit 1?

I mean, for example, the wagon shown in the picture of EDIT2. It shows that it can't be at rear but can be at front front side of the vehicle can be at the tail end when it's reversed, but rear side cannot be at the tail end.
This is just an exact representation of dat's description, but on older systems we didn't feel this weirdness, and it was supported by the movement of brake van.
Previously, there was no constraint[prev] = any, so if you update the pakset and do not pak with a new makeobj, the vehicle that is originally an intermediate car will display like that.

[Phystam]

I just now finished modifying pak256 for Ranran's patch. You can download and play pak256 with Ranran's patch.
It seems that it works correctly.
Link here: https://www.dropbox.com/s/4i24c4o2dcq535j/pak256-ranran.zip?dl=0

[Ranran(retired)]

I want to display the weight, including the load of the vehicle, as a decimal rather than an integer ton. Because the empty weight display shows decimal places, it is inconsistent and inaccurate. (´・ω・｀)

While sum_weight is calculated in kg, vehicle_t::get_sum_weight() converts to an integer ton when using an existing function to get it. I want to change it and fix it to show decimal places, is this change acceptable?
The details of the change are this commit.
I think all the places where vehicle_t::get_sum_weight() is called have been checked and fixed.

As to displaying the future, perhaps it is sensible to have this as a simuconf.tab option; something like show_future_vehicle_information=1, which, if disabled, would suppress information about vehicle upgrades and discontinuation dates until 1 year before the upgrade becomes available or the production is to be discontinued. That is probably the better way of catering for varying tastes in this context.

If there is a condition of one year ago, I think it is a more realistic and good option. The implementation looks easy and is heavily involved in the GUI that will be changed this time, so I implemented it together. 
The default settings are the same as before. I added only parameter to simuconf.tab.
show_future_vehicle_information = 1
Please write English description in simuconf.tab 

Note that the previous test version saved game may have a negative effect on startup. Because the version is not officially released, the revision number of test version has not changed. Saved game from previous test versions (mixed-load-something) are no longer available. If it still fails to start, delete setting-extended-debug.xml (if you used the debug version).


Migrated to new branch:
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/basic-coupling-patches
Temporarily reset en.tab but this is intended.


@Phystam-Thanks for testing
There is still a lot of validation needed, but testing with different paksets is helpful.

EDIT:
It could have been a confusing branch name. But the coupling group is not included and has no plans.

[Ranran(retired)]

Regarding the liveries and their subliveries, I had thought for the vehicle manager to simply name them like this:.

Code Select Expand


British Railways 1948-1951

British Railways 1951-1956

British Railways 1956-1966

British Railways 1966-1979

British Railways 1979-1986

... taking the intro dates, as well as the livery expiration date, as start- and endpoints for each sub-livery.

Wouldnt this be a universal good way of doing it?

I believe there are many examples that do not fit this and that this expression is not appropriate.
First of all, at present, individual livery can set the appearance date, but do not set the retire date.
Does the next livery intro date always represent the retire date of the previous livery? I do not think so.


A━━C━━┓ 　　　　　　　  ┏ H
　＼　　　 E━━━F━━G━━┫
B━━D━━┛ 　　　　　　　  ┗ I

Vehicles do not have to have all the liveries in their livery scheme.
So you can make vehicles that follow different transition routes.
For example, some may skip from A to E. One may transition from A to C, but one may transition from A to D.
An example where the relationship between Livery scheme and livery becomes like this should be allowed.
There should be many real-world examples.

I think at least displaying the livery retirement year is misleading.

[Ves]

Oh, you proved me wrong! True, vehicles can skip subliveries, I had forgotten that... however, still every vehicle has its own sub-livery timeline. For every vehicle, a newer version of a sub-livery will always obsolete the previous one, and the previous one will always be active until the newer one is available. Even if there would be multiple sub-liveries potentially in between (and available to other vehicles). Therefore, my suggestion would still work on a strictly per vehicle basis, but not to describe every existing sub-livery. For that to work, you are right that, in the very least, the "retirement" part should be omitted.

[jamespetts]

I have now incorporated this set of patches into the master branch, and likewise merged the pakset changes for Pak128.Britain-Ex. Therefore, these splendid improvements should be available in to-morrow's nightly build.

I have added the simuconf.tab documentation in relation to the show_future_vehicle_information setting as requested: thank you for adding this feature.

This will need a new makeobj; the Linux version will be automatically complied with the nightly, but the Windows version will need one that I have compiled myself. I have not yet set up my new computer with FileZilla and it is rather late in the evening to do so now, so I will not be able to upload the modified Windows makeobj until that has been done.

I should be grateful if people could test this feature in the running game from to-morrow onwards and let Ranran and me know whether there are any problems with this.

I am very grateful to Ranran for his splendid work on this, and I imagine that many other players will be, too.

There may be minor things that yet need to be done to this, but this seems to be in a complete enough state that it is ready to be committed now so that players can enjoy the benefits of the improved UI. I have also committed the relevant changes to Pak128.Britain-Ex.



As to the discussion regarding livery dates, one possibility (although this will need further consideration) is to have bespoke date ranges per vehicle to match the liveries of the scheme coded in the vehicle. Thus, for example, a vehicle might have:

"British Railways 1948 - 1956
British Railways 1956 - 1966"

instead of the complete set based on the liveries defined.

[Ranran(retired)]

James - Thank you for incorporating this patch.
I was surprised because I still thought a lot of validation is needed.
pak128.britain has undergone many changes since the summer, so there may be a lack of additional parameters. I will proceed with confirmation on that.
The first thing I have to apologize for is, en.tab was intended to be restored before implementation, so the addition is currently missing.
The contents were summarized in Reply # 13.

Code Select Expand


helptxt_can_be_at_rear
End vehicle
helptxt_intermediate
Intermediate vehicle
helptxt_powered_vehicle
Powered vehicle
helptxt_unpowered_vehicle
Unpowered vehicle
Select vehicles to make up a convoy
Select vehicles to make up a convoy
Vehicle bar shape legend:
Legend:
cd_spec_tab
Spec
cd_payload_tab
Payload
cd_maintenance_tab
Maintenance
No load setting
No load setting
Applied livery scheme: %s
Applied livery scheme: %s
%i month
%i month
%i months
%i months
(mixed_load_prohibition)
(Mixed load prohibition)
Upgrade available
Upgrade available
Upgrade is not available yet
Upgrade is not available yet
Upgrade will be available in the near future
Upgrade will be available in the near future
Shunting. %s left
Shunting. %s left
Changing direction. %s left
Changing direction. %s left


Anyway, I hope you enjoy this wonderful game more.  Thank you.

[freddyhayward]

There was a compiler error which is fixed here: https://github.com/jamespetts/simutrans-extended/pull/136/commits/e56765aa0e5c9b07c14c32ea95f21e81f998691a

[jamespetts]

I have now incorporated Freddy's fix - thank you to Freddy for that.

Ranran - I had spent some time last night testing this and in particular testing this with the updated pakset. I think that I have gone as far as I sensibly can with testing myself. There may be further refinements to be implemented following deployment, but the feature set seemed mature enough to deploy at this stage and let the community of Simutrans players enjoy it; they will find any further refinements that need to be made more quickly than those of us who are able to compile ourselves can.

As to en.tab, I believe that these texts are already present. However, I do notice that some signalling help texts were removed; was this intentional? If not, I should be grateful if you could restore them so that I can merge the restored versions back into the master branch.

Thank you again for your work on this.

[CK]

While I do like this update, there seems to be one issue:
Hovering over a vehicle upgrade in the replace vehicle window now causes the game to crash to desktop. I'm not entirely sure whether it is related to this, but it is certainly correlated with this update.

Steps to reproduce:

• Build vehicle with eventual upgrade
• Wait for upgrade to become available
• Go to vehicle replace window, select 'upgrade' in the bottom right of the window
• Hover over upgrade
• Game CTDs

[Ranran(retired)]

Thank you for your report and I 'm sorry for the inconvenience.
I believe this has been fixed. I threw a pull request.
https://github.com/jamespetts/simutrans-extended/pull/137

@freddyhayward - Thank you for the correction. This is very helpful.

@James - The removal of help texts is not my intention.

EDIT:
I added a fix for a bug where the upgrade information was not displayed correctly in the maintenance tab of the convoy detail dialog.

EDIT2:
I have restored two files that may have been lost.
signals_help.txt and signals_tips.txt, right?

[jamespetts]

Yes, those are the correct files. Thank you for the fixes: now incorporated.

[CK]

The bug appears to have been fixed. Thanks!

[Mariculous]

Frankly, I think that all cars, boats, and airplanes should be /__/.

I guess that's discussable.
/__/ clearly states "unidirectional" but the information if that vehicle can be at the front or end is missing. The <__) clearly states "can always be at the end and if driving forwards, also at the front", which is also correct and implies it cannot move backwards, at least not without a special cab bus behind, which does not exist.


However, I think the current bars are quite unintuitive.
Without reading the Legend one would moreover expect the following:
The arrows and parenthesis are directional symbols, thus they imply a direction: "<", "(" forward, ">", ")" backward
A straight line "|" or a slash is a non-directional symbol, thus I would not expect it to imply a unidirectional vehicle.

Arrows "<", ">" and straight line "|" are "end of vehicle" symbols, which means they CAN be at the end of a train, they don't neccessarily have to be at the end.
Parenthesis "(", ")" and rotated tilde "~" (rather than slash) are intermediate vehicle symbols.
Powered/unpowered remains as-is.


The above will imply the following ruleset, which is imho much more intuitive:
Vehicles will show at the front:
- "<" if it can be at the front when moving forwards (has_front_cab)
- "(" if it is a unidirectional vehicle that can not be at the front
- "~" if it is a bidirectional vehicle that cannot be at the front.
- "|" if it is a bidirectional vehicle that can be at the "front", when moving the opposite direction.
- ">" and ")" don't make sense at the front (would imply unidirectional vehicles that can only move backwards)

Vehicles will show at the end:
- "<" if it is a unidirectional vehicle that can be at the end (when moving forwards)
- "(" if it is a unidirectional vehicle that cannot be at the end.
- "~" if it is a bidirectional vehicle that cannot be at the end.
- "|" if it is a bidirectional vehicle that can be at the end.
- ">" if it i can be at the  "back" when moving the opposite direction.
- ")" doesn't make sense again

Note that the implied direction of "<" has a slightly different meaning depending on its position: "<" at the front is permisive. It will allow movement in that direction when at the front of the train. "<" at the back is prohibitive. It will allow the vehicle to be at the end but will prevent backward movement.

Examples of individual vehicles:
<__> Cab at both sides, bidirectional. E.g. old trams or most modern locomotives
<__< Cab at the front, unidirectional can be at the end. E.g. Busses
<__( Cab at the front, unidirectional, cannot be at the end. E.g. trailer trucks
<__~ Cab at the front, bidirectional, cannot be at the end E.g. the first car of a multiple unit.
<__| Cab at the front, can be at the end. E.g. trucks that can pull an additional car or ships with adddons.

(__< can not be at the front, unidirectional, can be at the backside. E.g. truck trailers
(__( can not be at the front not at the end, unidirectional. E.g. intermediate car of a unidirectional tram.
(__> Does not exist
(__~ Does not exist
(__|  Does not exist

~__> cannot be at the front, bidirectional, cab at the end. E.g. the end of a multiple unit.
~__< Does not exist
~__( Does not exist
~__~ cannot be at the front nor at the end, bidirectional E.g. intermediate car of a multiple unit
~__| cannot be at the front but at the end, bidirectional E.g. brake van

Note that here "the front" is in the original moving direction, which will be the end in backward movement. For sure it can never be at the front when moving forward as it does not have a cab there.
|__> Can be at the front, cab at the end. E.g. a cab car of a train.
|__< Does not exist
|__( Does not exist
|__~ can be at the front, bidirectional, cannot be at the end. E.g. paired rail cars like Eurostart E300s first car behind the locomotive.
|__| can be at the front and at the end, bidirectional. E.g. braked rail carriages.

A few composition examples:
-Unidirectional multiple unit like some modern trams: <__( (__( (__<
-Bidirectional multiple unit like some other modern trams: <__~ ~__~ ~__>

-Old unidirectional steam engine hauled train train with tender, unbraked cars and brake car: <__( (__< ~__~ ~__|

-Modern unidirectional conventional train like loco+cars: <__> |__| |__| (cars itself are not uni directional and can be at the end.
-Modern bidirectional conventional train like loco+cars+cab: <__> |__| |__>

[Vladki]

Ooohh, Freahk please, do not redefine the symbols.... I think we should not litter this topic with discussion. This topic should be reference for pak creators with clear definitions. I think we should go back to discussion here (and many above posts should be moved there as well): https://forum.simutrans.com/index.php/topic,15766.msg180025.html#msg180025

Think backwards - what do we want to achieve?
1. communicate the train composition to player clearly, so that he knows how the train will behave when reversing (and recombination if ever implemented)
2. improve the reversal algorithm, which is imho sub optimal, and does not work well in some combinations.
3. it would be nice to be able to rotate vehicles in depot.

The more I look at it, the more I think that it is not necessary to distinguish between unidirectional vehicle /__/ and bidirectional with front cab only <__). The difference between /__/ and <__) is so subtle that it is imho not worth bothering. E.g. you cannot connect two buses back to back to make push-pull unit because of constraints, but you can do that with steam engines.

I think that there should be only 3 signs:
1. Vehicle can be at front when running forwards: < and when running backwards > ... (i.e.) has drivers cab.   (we have new options for that)
2. Vehicle can be at rear when running forward: ) and when runnig backwards (  ...  (i.e.) is a brake wan or brake wan not needed. (constraint=none)
3. This end of vehicle can not be at the end of train: | ... (constraint=any)
4. For future recombination a note if the train can be disconnected there or not would be useful, but we can ignore that for now.

[Ranran(retired)]

I encourage you to read the original discussion first.

[Ranran(retired)]

I found that convoy could leave the depot if the leading vehicle does not have the cab in some cases in the new system, so I fix this issue and throw a pull request.

Text will be added to indicate this error, so check it and calibrate if necessary.

Code Select Expand

Cannot start: no cab at the front of the convoy.

Also added some Japanese translations.

[jamespetts]

I have merged the discussion relating to this feature extracted from the thread relating to the .dat file reference, as it is better suited to this thread.

I have also merged Ranran's latest changes into the master branch - thank you for that.

[Mariculous]

I encourage you to read the original discussion first.

I have read the whoe thread but I could not find any information about it apart from

- Shaped vehicle bar: The shape corresponds to whether or not it can be at the front/rear and bidirectionality. The color will be displayed for maintenance.

I know there is an ingame legend, but I think symbols were chosen quite unintuitively.

Think backwards - what do we want to achieve?
1. communicate the train composition to player clearly, so that he knows how the train will behave when reversing (and recombination if ever implemented)
2. improve the reversal algorithm, which is imho sub optimal, and does not work well in some combinations.
3. it would be nice to be able to rotate vehicles in depot.

1. check,
- if there is any unidirectional vehicle in the convoy, the whole convoy has to reverse.
- if there is no cab at the end, all vehicles from the front up to the first one with a cab on the backside will move to the back.
- if there is a cab at the end (and no unidirectional vehicle), the convoy will simply reverse without any reordering.
One can read this information from my suggestion just as good as from the current one.

2. See 1.

3. check,
Mirroring a bidirectional vehicle will also simply mirror its symbols.
Mirroring unidirectional vehicles doe not make sense as these would only be allowed to move "backwards" after mirroring with vehicles also added in backwards order, thus it's equivalent to moving forwards without being mirrored. This is the reason why I said above - ")" doesn't make sense.

The more I look at it, the more I think that it is not necessary to distinguish between unidirectional vehicle /__/ and bidirectional with front cab only <__).

There is a slight difference that can have a huge effect:
Many steam engines could in reality not move backwards at all on their own or just with some huge restrictions. However, they could for sure couple to the usual cars, which could also couple to a cab car variant but the steam engine could not make use of that cab car because it could not move backwards.

The isue is even slightly more difficult in reality: Some locomotives that have a cab on both sides cannot push trains with a cab car because they don't have the equipment to communicate to the cab car.
So to be preciese, we would need a can_use_cab_car flag rather than a unidirectional flag. That flag would then be the distinguishment in between "normal" variants of an engine and a push-pull variant.

In any case, we need to display that unidirectional information to the player, otherwise the player will not know why the whole train reverses while there is a cab at the end.

[Ves]

- if there is any unidirectional vehicle in the convoy, the whole convoy has to reverse.

This cannot be true: Tender steam engines are unidirectional, and surely the entire train should not turn around just because of that. The most sensible thing would be to turn every unidirectional vehicle around, and dont tuch the bidirectional vehicles, letting them run backwards.