News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

[patch] Depot dialog improvement and convoy detail dialog adjustment

Started by Ranran, March 17, 2020, 11:57:26 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ranran

(´・ω・`)This is Ranran's patch #3. 春のらんらんパッチ祭第3弾

Overview:
This is a consolidation of several patches posted earlier this year and further brush-ups. Contents are roughly divided into three groups.
(1) Add the tile occupancy bar
(2) Improvement of the depot dialog
(3) Adjustment of Convoy detail dialog

It seems that further improvement has occurred as a result of aging. Due to the amount of content, old content will be linked to it and new content will be posted in this thread. Please taste it. :)





Details:

(1) Tile occupancy bar
See below for some of the content and old disscussion:
[patch]Convoy length bar reloaded



(1a) Tile occupancy bar now supports automatic addition/removal of vehicles.
It informs you in advance of the number and length of vehicles that will increase or decrease by hovering over the vehicle panel.
For example, if 4 cars are added at the same time, the number of vehicles + 4 and the increased tile length for 4 cars will be displayed.


(1b) If the convoy assemble doesn't complete yet, you'll still see a little yellow bar to indicate the potential for tile growth.




(2) depot dialog

(2a) The displayable number has been increased because the display of selectable livery scheme has been changed to two columns.
(2b) If the vehicle has multiple liveries, the currently selected livery scheme will be highlighted. It should be noted that if the choice and the possession do not match, the first one will be chosen.



(2c) As described here, when upgrading a vehicle it will tell you in advance how the constraint will change.
(2d) Also, the number of vehicles being upgraded at the same time is shown in parentheses in the top "Vehicles".
Please check the link above for details.



(2e) Mouse over convoy vehicles to see a list of upgrade target vehicles.

Here, only the options are displayed, not the details. Here we will focus on how the role (shape of the vehicle bar) changes due to the upgrade.
Switch to upgrade mode to see the details.



(2e) Sell button now shows the sale amount. This is a commonly used technique to check execution.
The price at the time of purchase is displayed in "Cost:", but if it is different from the sale price, the character color will be royal blue. This indicates that the vehicle is not new.
(2f) tweak convoy information - overall layout looks like this:

Since acceleration and deceleration are a pair, these display units are generally unified. (For example, tractive force xx kN vs brake force xx kN, or acceleration x.x km/h/s vs deceleration x.x km/h/s.) So I unified with kN and lined up and down.







(3)Adjustment of Convoy detail dialog

(3a)If convoy is replacing, symbols and messages will be displayed at the top inside the maintenance tab.



(3b)Starting acceleration information is added to the spec tab.
Also made layout consistent with the depot dialog.



(3c)Information on the livery scheme applied to the maintenance tab is displayed.

Those displayed in brown indicate that a different livery scheme has been set from the livery scheme applied to convoy.
This implies that this livery may be rewritten if an overhaul is performed.
(That is, the livery of the vehicle L1 is the livery scheme currently set in convoy. But vehicle 1 is not.)




(4) Temporary measures were taken against the display bug of Replace dialog.
https://forum.simutrans.com/index.php/topic,18270.0.html






Translated words to be added:
Selectable livery schemes
Starting acceleration:
; %i km/h @ %.2f sec
; %i km/h @ %.2f - %.2f sec
; %i km/h @ %.2f sec -  %i km/h @ %.2f sec
no power at all
(%.*ft laden)
(%.*f-%.*ft laden)
Sell for %s





Github repository is here:
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/depot-dialog-improvement


Thank you for the feedback so far.
I hope this modification will improve your gameplay comfort.
I would be grateful if you could give us new feedback on these. Thank you. (´・ω・`)

Matthew

Ranran, thank you for making these improvements. But I think that you need to push them to Github, as I am not receiving any updated code.
(Signature being tested) If you enjoy playing Simutrans, then you might also enjoy watching Japan Railway Journal
Available in English and simplified Chinese
如果您喜欢玩Simutrans的话,那么说不定就想看《日本铁路之旅》(英语也有简体中文字幕)。

jamespetts

This looks very interesting - thank you for your work on this! I have not had a chance to test this yet, as I need to confirm that the fixes for private car routing are working properly without thread deadlocks before testing other code, but these definitely look like worthy improvements.

I should be grateful for anyone else's feedback/views on these patches.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ranran

Quote from: Matthew on March 17, 2020, 07:34:13 PMBut I think that you need to push them to Github, as I am not receiving any updated code.
No, the push was done correctly. Patches are being updated from late January to February, and changes made during that time have not been posted to older threads. Includes many changes as described here.

jamespetts

Thank you for your work on this: this does look good. I have now had a chance to test this, and it seems to be working well. Overall, the enhancements are a clear improvement.

One query that I have - and I should be grateful for others' feedback on this - is in relation to the sell button. I wonder whether it would be clearer if the sale price would be given as a tooltip rather than integrated into the button text itself. I suggest this because one would normally expect the buttons to describe the action to be performed when pressing them, and tooltips to give extra information about what happens when one presses the button, rather than for the button text itself to change with the context. However, I should be interested, as stated above, on others' views on this.

Thank you again for your work on this - this is a splendid improvement.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ranran

Thank you for your thoughts.

Quote from: jamespetts on April 10, 2020, 12:15:58 PMI suggest this because one would normally expect the buttons to describe the action to be performed when pressing them, and tooltips to give extra information about what happens when one presses the button, rather than for the button text itself to change with the context.
I suggest the following proposal based on this.

The sell button toggles between three different labels/tooltips based on convoy nominal value and resale value.

case 1: nominal cost = resale cost

labelClear
*tooltipThe purchase will be canceled and the cost will be fully refunded.

case 2: resale cost = 0

labelDismantle
*tooltipDismantle all vehicles in the convoy. No costs will be refunded.


case 3: Other than those above, it means, nominal cost > resale cost

labelSell
*tooltipSell the convoy for %s

*Note: The tooltip text needs to be proofread because it is a new translated term.


What do you think about this?

jamespetts

We do need in the future to distinguish between selling a vehicle (i.e. putting it up for sale to other players) and scrapping it, when this distinction be introduced. At that point, there would be two buttons: one to put the vehicle up for sale, and the other to return it for a full refund (when new and unused) or alternatively scrap it (when not new and unused).

The button that is now marked "sell" would at that time be replaced with a button stating either "Return for refund" or "scrap", and a new button marked "Offer for sale" would be added.

Until then, we might mark the existing "sell" button as "Return for refund" where the resale value is equal to the nominal cost, "sell" when the resale value is less than this but greater than (say) 10% of this, or "scrap" when the resale value is <= 10% of the nominal cost.

Do people think that this is clear enough?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

I would definitely not put a dismantle and sell/scrap at the same place to avoid confusion. The buttons should be:  [dismantle] [offer for sale] [refund/scrap]
I think in standard double click on vehicles dismantles the whole convoy, but I do not like that. Refund/scrap can be on the same button, as it will switch automatically according to if the vehicle is used or not.
Whether the sell/scrap price is shown on the button, tooltip, or where it used to be until now does not matter to me. If there are more buttons, there might not be enough space to show the price on it.

jamespetts

My apologies for not having replied to this earlier. I have now made some minor alterations to the text to add clarity and have incorporated this.

Ranran - I should be grateful if you could update Simutranslator accordingly. I should note that there were some merge conflicts in the Japanese translation file, which I resolved by reverting to that from the master branch, so you may need to re-add your Japanese translations for this.

Thank you very much for your work on this.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

Ranran, thank you for the various improvements of depot/replace window. But I'd like to ask to get rid of the tooltips, and put all information on display.
Especially I was looking for the brake distance - which is very important for signalling, and after long time I found that there is soooo much information hidden in tooltips.
Please don't hide it this way. It is really unpractical to move mouse over there and here and focus is exactly at some tiny text. I cant imagine checking thote tooltips with touchpad...

And speaking about brake distance - that deserves to be put in the (existing) convoy info window for even quicker access.

Ranran

Thank you for your feedback.

Counter-measure I thought about it:
1) Hide the way wear factor in the "Weight:"(or "Maintenance:") tooltip. Because the way wear is one of the maintenance information, and the "factor" is not intuitive, it is related to the actual value but not the actual value. IMO, It's unclear how much this number actually costs, and whether it's high or low. I think it's actually a weight*way wear factor. Also, this information is not needed for vehicles such as ships.
2) Then move "weight" and "max. axle load" up one step. The brake distance is displayed in an empty place.


Option-A) Place a light blue (!) Symbol on the right edge of the item for which the tooltip is displayed. (This symbol is intended for use as the lowest level of warning, ie information. This design can be freely created by the pakset author.)
Some people may find this annoying. Because it is not displayed only when certain conditions are met.
However, It can be erased from ships and floating vehicles.
This means 4-5 guide symbols are always displayed.


I would like to ask people for their opinion as to whether this change makes sense.

Vladki

First - I don't mind if the information would occupy 1 or 2 extra lines. If anything is hidden in tooltip, some symbol would be nice to attract attention.

Way wear factor - Perhaps showing a Yellow /!\  if the factor is higher than default, and blue (!) if it is lower than default.
way_wear_factor:{E} How much the vehicle "wears" the underlying way. The wear is intended to be measured in 10,000ths of a standard axle load of 8t.

So show warning if way_wear_factor > axle_load / 8 * 10000

Ranran

QuoteWay wear factor - Perhaps showing a Yellow /!\  if the factor is higher than default, and blue (!) if it is lower than default.
way_wear_factor:{E} How much the vehicle "wears" the underlying way. The wear is intended to be measured in 10,000ths of a standard axle load of 8t.

So show warning if way_wear_factor > axle_load / 8 * 10000
What are the default numbers based on?
Fixed values should not be used for things that are not universal. I think that it may change depending on various factors such as country, ie pakset, waytype, era.

Mariculous

I am wondering why there cannot be another line added so all data can be displayed without tooltips.
The current height of that area restricts the amount of different good types that can be displayed to 4 when mail or passengers are involved, which is usually enough for passenger/mail mixed trains but might not be sufficient in case of intercontinental shipping or cargo/mail backbone lines in general.

As Vladki mentioned while I was typing, there should be a hint if there is additional data available on mouseover.
I do not agree that this neccesarily has to be an icon, but I don't reject this as an option either.
In case of websites, you can frequently see such texts to be colored or underlined.

I am not sure if data in tooltips is generally a good idea, as tooltips are usually used to describe the meaining of the data rather than showing additional data.

Vladki

Quote from: Freahk on June 03, 2020, 10:28:34 AMI am not sure if data in tooltips is generally a good idea, as tooltips are usually used to describe the meaining of the data rather than showing additional data.
- exactly !!!

Please just add more lines instead of tooltips.

As to way wear - i was quoting: https://forum.simutrans.com/index.php/topic,15174.0.html
standard_axle_load = 8 is defined in simuconf.tab. Vehicles that do not have an explict way_wear_factor use that to calculate: way_wear_factor = axle_load/standard_axle_load * 10000
use get_standard_axle_load() to get the value form simuconf.tab.  Axle_load itself may be calculated from weight/axles...


Ranran

Quote from: Vladki on June 03, 2020, 01:25:13 PM- exactly !!!

Please just add more lines instead of tooltips.
I do not agree. Before adding more rows, you need to look at paksets other than 128 pixels. Depot dialogs other than 128px pakset are very uncomfortable. This is an extended specific issue.
I think this is probably happening when the depot code was chenged from standard. For example in 64px's pakset was almost broken, but I've fixed it several times so far.
For some reason, the width of the dialog is set to 24 vehicles, so the size changes greatly depending on the pakset size. The pakset size naturally affects the height as well.
In 256px pakset, it is too large and there is a lot of wasted space. It occupies so much space.
And one of the bugs is increasing the width of the depot dialog by adding more vehicles. Please connect over 25 vehicles to the convoy, you can confirm it.

Quote from: Freahk on June 03, 2020, 10:28:34 AMI am wondering why there cannot be another line added so all data can be displayed without tooltips.
I put the letters in the tooltip because I didn't want to put many letters in one cell.
The larger the number of characters, the greater the difference in appearance due to the pak set size.
It is more likely that there will be collision of letters or pictures, or wasted space.

Language differences need to be considered. Since English is a phonetic language, it is one of the languages that requires a large number of characters.

I think I mentioned somewhere about the kind of luggage Convoy has, but first of all, the space for the four buttons is wasted, so if you make it smaller you can add another line. But I'm not sure if it works with 64px pakset.
Then I wondered if this cargo display system could be integrated with another system and fixed along with a replace window bug, but it was more complicated than I thought so I didn't do it. It's easy if you just add one line.

There may be wasted space underneath, but I used that space for the upgrade list and the livery scheme list.
I don't know if that space was originally needed.

Vladki

Is the problem with depot window in pak256 caused only by bigger vehicle images, or by bigger fonts as well?
Currently the tooltips are very uncomfortable - not only they are hidden, they also disappear before you can read them. And the information they show is probably even more important than the one shown normally. E.g. brake distance is something players understand much better than brake force.

Anyway I'm working on improved convoy detail window. It shows starting acceleration in both km/h/s and m/s/s for empty convoi and the current load.
It also shows 3 braking distances - all at current load, and max speed, current speed, and max speed allowed by train, track and signalling.

How do you like that? Would some other information be more useful?
I wanted to show current power and tractive force, but that information is in protected class members.

Ranran

QuoteIs the problem with depot window in pak256 caused only by bigger vehicle images, or by bigger fonts as well?
In my opinion,
Simutrans did not consider such a large pakset; extended has been a fork made only for 128.britain-Ex for a long time, so it has not been designed and tested considering other sizes, and it has come up to now. The problem is excessive text, width calculation without considering the difference in image size.

For examples,
64px pakset has a large amount of text in a small depot dialog that can be overlapped or hidden. However, it is somewhat better than before. Conversely, the 256px pakset has too much dead space.
And 256 size is too small font and icon for the image.
In many GUIs, an image called View is placed in the upper right corner, which causes the GUI layout to change significantly.
The height generated by the view is about 10 lines with 128px pakset. Then, we placed 10 lines there. But with 256px pakset, 20 lines can be placed there, which creates 10 lines of dead space. (´・ω・`)
They were so humble and didn't say it, but unfortunately I was arrogant so expose it.
And note that the difference between 128px and 256px is greater than the difference between 64px and 128px. In the above example, 64px and 128px view size difference is 5 lines.
In this case, I don't really care.

And another, I want to zoom out the main game screen more. When the tiles are large the number of tiles that fit on one screen at the time of maximum zoom out is small. This is very inconvenient and uncomfortable to play.

I've been aware of these things all the time, but I can't afford to do that. I don't get any money for it. It's just a hobby. And I don't even have a clear idea for it.
But I don't want to make it worse, since I know the 256px size pakset is under development recently. I should also appreciate their feedback.
However, there are many things that are difficult to improve at present. (´・ω・`)
As I said, I don't think the old simutrans did not expect such a big pakset to be born.
Major changes may have to wait for the standard new GUI system or the introduction of variable font sizes, which can have some positive effects.



Thank you for your work.
I answer separately for the depot dialog and the convoy detail dialog to avoid confusion.

First about the convoy details dialog:

QuoteCurrently the tooltips are very uncomfortable
I think this is about the depot dialog as I haven't added any tooltips to the convoy detail dialog. But I think the changes you make are based on this thoughts.
I'm sorry to have to say something like this, frankly, I think this change is a bad design that goes backwards from universal design. (I'm not English native so I'm not confident in the expression here, but for what the GUI aims at)
1) Why is the signal speed limit on the convoy spec tab? It may be easier to understand with the current working method. Or write the speed with the signal symbol I made before.
Anyway, it's not good to add very long text or just add lines unnecessarily.
2) The same applies to starting acceleration. Repeating the same label twice is silly.
3) The same applies to brake infos. I wonder if you really need 3 lines.

4) I think that it is not so good that the information of brake force and break distance are separated.

QuoteAnyway I'm working on improved convoy detail window. It shows starting acceleration in both km/h/s and m/s/s for empty convoi and the current load.
5) The starting acceleration is not important information. And an odd display for some vehicles. Horses and ships and airplanes.
Most of the information about the starting acceleration is used only for "EMU" (Strictly speaking electric motor vehicle) in Japanese railways.
As I said, this is inaccurate information except in electric motor vehicles. How does the engine maintain a constant torque?
It doesn't make sense to stick to the starting acceleration, it just sends the wrong information.
DMUs and steam locomotives have very high starting acceleration when the theoretical values are applied. But that's only the first moment.
By the time the speed reached 1 km/h, much of that value had already been lost. And in reality, even if a propulsive force greater than frictional force is applied, the wheels will simply spin. s I have explained many times, the physics code of simutrans extended is treated like a train motor because it does not have the ability to draw such an acceleration curve. However, if you try to draw a curve that is closer to it, the rated speed should be very low.
For example, at 10 km/h, the acceleration will start to be lost. Otherwise it will have unrealistic acceleration like a electric train.
As such, the starting acceleration is very ambiguous information other than the electric train.
Even comparing two convoys, it is difficult to judge which one is better due to the difference in the stage at which acceleration decay begins. Providing only the starting acceleration information only confuses the player. I have tried to explain it many times though. (´・ω・`)

6) Displaying for a comparison value in such a dialog is also not useful.

7) I said a better solution is to show the acceleration graph. It shows the transition of the whole number, not the useless momentary number.

Fortunately, it turns out that the acceleration curve patch buried by freddy and wlindley suggestion could come back.
So, I was thinking of casting a resurrection spell in the near future.
When it is revived, it will be better visible in the convoy info dialog instead of the convoy detail.


QuoteIt shows starting acceleration in both km/h/s and m/s/s for empty convoi and the current load.
Next about this display method, it is a major reason I think why this change is goes backwards from universal design.
8) I don't think this large amount of text is worth this information. Both in the double unit and the above reason. And for Japanese, the information about m/s/s is only an obstacle.
I doubt this may not be limited to Japanese (or Asians) only.
And I really wonder if it makes sense to increase to two lines for that purpose.

9) As I said before, the unit system with different acceleration even though the speed is expressed in km/h is confusing. It will make the graph harder to read as well.

10) Who cares about the actual starting acceleration? I think it's just geeks and mechanics. Do normal humans stick to the unit of m/s/s? But I don't know about foreign countries.
Shinkansen runs at 360km/h. TGV runs at 320km/h. Yeah great.
But do ordinary people care about these starting accelerations? And do they too stick to the units of m/s/s?
Do they really think that it is easy to understand that the unit of m/s/s is used?
Please note that my emphasis is on the public's point of view, not geek's aspirations.
And for reason 8) and 9), if this display is really needed, it is advisable to make it selectable via the display settings option.


QuoteHow do you like that? Would some other information be more useful?
I wanted to show current power and tractive force, but that information is in protected class members.
The reason I don't like this change is for reasons other than those mentioned above:
It's unusually hard to read because it's just text, it's large amount, it's not aligned, and it's not very important information.
One of the goals of universal design is to reduce the differences between languages. That is why I am promoting the use of symbols. Also, the visibility is good and the GUI is become compact.
As prissi advised me, aligning in the old GUI code is manual. Therefore you cannot force it. It will be easily aligned once the standard new GUI system is incorporated into extended.



about the depot dialog:
I objected to increasing the rows for the reasons mentioned above, but not to changing the layout.
And again, using long texts is not desirable given the differences between languages and pakset sizes. So don't try to pack too much information/text in one label.
And there are two reasons why I'm not doing that work besides doing other work.
a) May conflict with the correction of your acceleration calculation
b) It is more efficient to do it together with the work to revive Bernd Gabriel's acceleration curve chart.



I'm sorry to say so many, but it's my personal opinion. You should also use the opinions of others. Note that I'm not an English speaker, so there is inaccuracy in context (especially technical terminology). Thank you.

Vladki

About the depot windows. I admit I have played with 128 size for long time. I have tried now pak64 and pak256 to see what wasted space are you talking about. Now I understand - it is the minimum width of depot window. I think this could and should be solved easily with just making the minimum width independent of pak size. Vertical space is not that big problem, and I think a few more lines are acceptable. Also the longer information (like the acceleration and breaking distance) could be put at the bottom, with the right column left empty to avoid overlap.

Acceleration units km/h/s vs. ms/s/s   From the player point of view, the most practical information is IMHO the distance needed to gain maximum speed. Neither km/h/s or m/s/s is important by itself (just as power, tractive force, rolling resistance, etc...). However these are useful to compare available vehicles relatively to each other. And in that case the chosen unit does not matter that much. For developing or debugging a pakset, m/s/s is better because it is used in official specs, so I can immediately see if the model has the expected acceleration or not. I also think about showing possible acceleration at current speed+slope. Would that be more interesting than starting acceleration?

Same applies to brake force and braking distance. The distance is what player needs to know - to space signals properly. Not the braking force alone.

Quote from: Ranran on June 21, 2020, 12:07:25 PMWhy is the signal speed limit on the convoy spec tab?
Just because I found the code place where to modify the spec tab, and did not want to touch too many places in the code. And I did not want to add more stuff to the general convoy info which is shown with other tabs.
I hope it should not be problem to move this information if others agree it should go there. However it is not only signal speed. It is minimum of: train max. speed, signal max. speed, track max. speed, corner max. speed. So using just the signal icon, is not imho appropriate. Could be solved with text: "Allowed speed" and a longer tooltip explaining all limits that are used. Imho this speed is most useful for the signal spacing.

Quote from: Ranran on June 21, 2020, 12:07:25 PM2) The same applies to starting acceleration. Repeating the same label twice is silly.
3) The same applies to brake infos. I wonder if you really need 3 lines.
I had it on one line, but it was getting too long, and not clear what it meant. It was like this:

Starting acceleration: 1.68 km/h/s (max. 1.76 km/h/s = 0.49 m/s/s)
Brakes from max. speed in 646 m (from current speed in 145 m)


Quote from: Ranran on June 21, 2020, 12:07:25 PM4) I think that it is not so good that the information of brake force and break distance are separated.
No problem moving it to be:

power 75 kW, 19 kN
starting acceleration .....
max. brake force: 21 kN
brakes from ...


Quote from: Ranran on June 21, 2020, 12:07:25 PM7) I said a better solution is to show the acceleration graph.
I agree, I just don't feel skilled enough to make it. And first we have to have the acceleration calculation right.

Ranran

QuoteI think this could and should be solved easily with just making the minimum width independent of pak size.
No, I don't think so.
QuoteFor some reason, the width of the dialog is set to 24 vehicles, so the size changes greatly depending on the pakset size.
As pointed out above, the number of vehicles has to accommodate the expanding window size.
So you have to put it in the scrollbar, so you can't just change the size calculation.
There should be something left in my repository where I left off trying to do it.

QuoteFrom the player point of view, the most practical information is IMHO the distance needed to gain maximum speed.
I tried to add the display, but the formula and display were buried along with Bernd Gabriel's acceleration curve chart. It will come with it when it is revived.


QuoteSame applies to brake force and braking distance. The distance is what player needs to know - to space signals properly. Not the braking force alone.
What I pointed out is the display method. The deceleration is basically constant so the graph is simple and I don't think it is good to graph it and I have no idea how to display it, but at least 3 lines with too many identical words It looks silly to repeat.
However, I wonder if break force is needed on the convoy detail tab when there is a brake distance display.


QuoteFor developing or debugging a pakset, m/s/s is better because it is used in official specs, so I can immediately see if the model has the expected acceleration or not.
It is advisable to add an option as it has no reason to display it at the same time.

QuoteJust because I found the code place where to modify the spec tab, and did not want to touch too many places in the code. And I did not want to add more stuff to the general convoy info which is shown with other tabs.
I hope it should not be problem to move this information if others agree it should go there. However it is not only signal speed. It is minimum of: train max. speed, signal max. speed, track max. speed, corner max. speed. So using just the signal icon, is not imho appropriate. Could be solved with text: "Allowed speed" and a longer tooltip explaining all limits that are used. Imho this speed is most useful for the signal spacing.
After all, it's not right there. Because that's where the convoy spec is displayed.
One vehicle of 55km/ was mixed in the vehicle of 100km/h. The convoy speed spec is 55km/h. It's a place to say that. That is the "convoy spec".
"Allowed speed" is the content that should be displayed at the top.
On the other hand, the odometer is not important and I think it could be moved to the maintenance tab.


QuoteI had it on one line, but it was getting too long, and not clear what it meant. It was like this:
As I explained, I don't think that display is very valuable in the first place. It's added by me, but it's only allowed to exist as the graph doesn't exist yet. When a graph is added it is no longer worth it, but rather confusing for the reasons mentioned above, which is just annoying.

Vladki

Quote from: Ranran on June 21, 2020, 01:47:13 PMFor some reason, the width of the dialog is set to 24 vehicles, so the size changes greatly depending on the pakset size.

As pointed out above, the number of vehicles has to accommodate the expanding window size.
So you have to put it in the scrollbar, so you can't just change the size calculation.
I think that is a leftover from standard which used to have hard limit on 24 vehicles in convoy. The dialog grows if the convoy is longer. however the scrollbar would be better in case the dialog needs to be bigger than your screen. I'll try...

Quote from: Ranran on June 21, 2020, 01:47:13 PMWhat I pointed out is the display method. The deceleration is basically constant so the graph is simple and I don't think it is good to graph it and I have no idea how to display it, but at least 3 lines with too many identical words It looks silly to repeat.
However, I wonder if break force is needed on the convoy detail tab when there is a brake distance display.
I agree that one braking distance would be enough (and that brake force and decceleration graph is useless). The question is, which of the 3 numbers I offered is most useful?  Same with acceleration...

Quote from: Ranran on June 21, 2020, 01:47:13 PMOn the other hand, the odometer is not important and I think it could be moved to the maintenance tab.
I think there is lot of information that is rarely used. Odometer may be useful when overhauls and maintenance breaks in depot are implemented.


Vladki

Here is a patch that makes the minimum depot window size independent on pakset size. The size is based on 24 vehicles in pak128 (or 12 vehicles in pak256). Thus the assembled convoy information can be arranged with this size in mind. Of course small differences may happen due to translations having different length.

https://github.com/vladki77/simutrans-extended/commit/a4f69634b220df8d04ef3185d20ae42f5840102a

Please cherry pick only this commit, not the whole branch, there is still work in progress

Ranran

QuoteOdometer may be useful when overhauls and maintenance breaks in depot are implemented.
I'm afraid but I don't think so. (´・ω・`)
Is this the vehicle average? Is the odometer of the oldest vehicle? Since the convoy was first assembled in the depot? Yes, all the numbers are useless. Especially when recombination system is implemented.
The vehicle that was present when it was first assembled may disappear due to recombination. In the real world, the overhaul period varies depending on the vehicle type and age. So this is useless, but just for your information like speed record or who painted the object.
Want to make sure this convoy is brand new (odometer=0)? Unfortunately, when you see this dialog, it's already used because it's out of the depot...

For example, an EMU will be managed collectively by one UNIT. But are locomotives and wagons managed together?

Vladki

Quote from: Ranran on June 22, 2020, 10:09:36 AMIs this the vehicle average? Is the odometer of the oldest vehicle? Since the convoy was first assembled in the depot? Yes, all the numbers are useless. Especially when recombination system is implemented.
I agreee - to be useful it would have to be independent counter for each vehicle.
EDIT: odometer is a property of convoy, so this would need bigger rewrite to keep it separately for each vehicle... I'd leave that to be implemented with maintenance depot visits and overhauls.

Vladki

Acceleration calculation finally fixed. Now the calculated distance agrees with simutrans convoy movements.
https://github.com/jamespetts/simutrans-extended/pull/184

The displayed info may be a bit too excessive now, but is useful for debugging. I'm open to suggestions.
My suggesiton would be - in convoy details show only:
speed: x km/h (max: y km/h)
allowed speed: z km/h    (perhaps with tooltip explaining that it is the speed allowed by convoy, signalling, way quality and way curvature)
breaking distance - most interesting is imho braking from allowed or current speed at current weight
acceleration - I'm not sure if it should be shown at all. It might be enough to show in depot dialog, but not as tooltip.

Depot dialog:
no technical specifications should be shown as tooltips. Only explanatory texts.

Vladki


jamespetts

Apologies for the delay in looking at this: I have been rather preoccupied. I have had a breif look at this. Can I check whether I have fully understood where all the changes have been made: I see some additional information in the convoy detail window:



Is that all the new information, or is there intended to be information anywhere else? If so, I will need to know where it is in order to try to track it down and test it specifically.

As for this information, I think that some work needs to be done to the display: there are many repeated lines that makes the window difficult to read and understand; I wonder whether there might e a system of displaying only one of these at a time and cycling between them?

I should be grateful for others' views on this.

Thank you for your work on this: it is much appreciated.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ranran

Quote from: jamespetts on July 21, 2020, 07:23:02 PMAs for this information, I think that some work needs to be done to the display: there are many repeated lines that makes the window difficult to read and understand; I wonder whether there might e a system of displaying only one of these at a time and cycling between them?

I should be grateful for others' views on this.
I also had the same impression as James. So I have already given many personal views on this around here.
Quote from: Ranran on June 21, 2020, 12:07:25 PMFirst about the convoy details dialog:
But it doesn't seem to have improved since that time.
And what really reflects the current state is not SPEC. At least in Japan.

Vladki

The changes are:
- fix of the acceleration calculation (in convoy.cc) - which is then used in convoy details, and depot / replace windows (in tooltip).

depot/replace window
- minimum width fixed to 680 pixels independent of pakset (instead of 24 vehicles)

Convoy details:
- always show the summary, even if the convoy has only one vehicle (before one-vehicle convoys did not show summary)
- added current, top and allowed speed to convoy details
- 3x acceleration: (current speed and weight, 0 speed and current weight, 0 speed and empty)
- 3x braking distance: (top speed, allowed speed, current speed)
- show friction if friction <>0 ( before friction=1 was hidden)

I agree that 3x accelleration and 3x braking distance is too much.

Maybe the acceleration makes sense only in depot/replace window. But I really dislike any specs being shown in tooltips - especially if the tooltip is so long that you cannot read (and understand it) before it disappears. I wanted a clear and easily acessible starting acceleration info in m/s/s to see if I have calculated correctly the tractive effort from real world specs which ususally give max acceleration in m/s/s. I don't care if it displayed in convoy details or depot, but please not as tooltip.

Braking distance - this is very important for proper signal placement, so this value should be easily accessible too. Again it is hidden as a tooltip in depot window. Also the question is which of the 3 values is most practical. Imho it is the allowed speed (allowed by convoy, track, signalling and corners). But that is up to discussion, which of the 3 values should be displayed.

Mariculous

Quote from: Vladki on July 22, 2020, 07:44:00 AMAlso the question is which of the 3 values is most practical. Imho it is the allowed speed (allowed by convoy, track, signalling and corners)
Based on James suggestion of "a system of displaying only one of these at a time and cycling between them", I'd suggest a setting which allows to set any number between 1 km/h and max speed, so players can that distance before leaving the depot and they can decide which signal spacing is needed at different places of the tracks.

The same principle should work well with acceleration: Let the player choose a value in between empty and loaded weight, as well as zero to maximum speed and display the acceleration at that specific speed.
In case of the convoy detail window, these values might default to the convoys current value.

Ranran

QuoteMaybe the acceleration makes sense only in depot/replace window.
I don't think acceleration is important information even in the depot window. Acceleration is just supplemental information on traction.
You take too much of that information. That is the difference between me and your view. But I've repeatedly explained why that information isn't important.
In my opinion, displaying multiple similar data to increase the list size is not desirable. And that acceleration is not always that value. That's why I hid it in the tooltip.

And when it comes to more useful information, it's visualized like a graph.


QuoteI wanted a clear and easily acessible starting acceleration info in m/s/s to see if I have calculated correctly the tractive effort from real world specs which ususally give max acceleration in m/s/s. I don't care if it displayed in convoy details or depot, but please not as tooltip.
If you need it for debugging, displaying in debug mode is sufficient. I also proposed an option in config for displaying m/s/s.


It is necessary to consider the division of duties between the convoy inforamtion dialog and the convoy detail dialog.
I think that the convoy info window focuses on information about the entire convoy, and the convoy detail focuses on information about the vehicles that make up the convoy. For some reason you are trying to add a lot of convoy information to the convoi detail. Instead of organizing information, it does the opposite.


EDIT:
Again, there is ambiguity in acceleration. As explained, higher starting acceleration does not mean higher overall acceleration. Vehicles with high real gear ratio will stall immediately. When observing acceleration to high speed, in most cases, a vehicle with a high gear ratio with a low acceleration accelerates faster.

In modern games pursuing the beauty of 3D graphics (eg transport fever), the acceleration may persist forever because it does not simulate such physical laws. But the good news is that simutrans extended simulates the decay of acceleration. In the former case, displaying acceleration is not a problem.
Without the graph, it is difficult for players to understand the overall acceleration information. Therefore, providing only inaccurate and ambiguous information only leads to confusion for the player. Player might confuse that a vehicle with high acceleration for low speeds is better. That's one of the reasons I don't want acceleration to come to the fore.
Also, the depot is not dedicated to the railway. The display may not be appropriate except on the railroad.

Vladki

Ranran, remember that it was you who added the acceleration info to the depot and convoy details in the first place? Just the formula you used was wrong. So the most important part of my patch is fix of the calculation. And as the fix was also about completely changing and renaming the functions that calculate acceleration, I had to modify the dialogs that call these functions too.

As you say, the starting acceleration itself is not very important - therefore I decided to show also possible acceleration at current speed, weight and slope.
And also that is the reason why acceleration is shown also as time/distance to reach top speed. Which is much more informative, but still hidden in a tooltip.

Quote from: Ranran on July 22, 2020, 11:57:40 AMI think that the convoy info window focuses on information about the entire convoy, and the convoy detail focuses on information about the vehicles that make up the convoy.

I disagree. In convoy detail tab I expect technical details that are not so important to be shown in the overview that is shown with all tabs. But feel free to move that information anywhere else. I just wanted to keep my changes in one place. Also one of the reasons is, that acceleration calculation uses other values shown in the convoy details as inputs, so code efficiency is also important. The values are recalculated very often and so I tried my best to avoid repeating the same function calls like get_vehicle_summary(), get_weight_summary(), etc.  During debugging I was in stage where opened convoy details caused significant load, but managed to reduce it.

Quote from: Freahk on July 22, 2020, 10:37:49 AMBased on James suggestion of "a system of displaying only one of these at a time and cycling between them", I'd suggest a setting which allows to set any number between 1 km/h and max speed, so players can that distance before leaving the depot and they can decide which signal spacing is needed at different places of the tracks.
That would be nice, but it is far beyond my knowledge of simutrans GUI coding.

Ranran

QuoteRanran, remember that it was you who added the acceleration info to the depot and convoy details in the first place?
What I added is the starting acceleration.
Does wikipedia or the train picture book show a lot of such multiple acceleration information? And can you call it SPEC?


QuoteAs you say, the starting acceleration itself is not very important - therefore I decided to show also possible acceleration at current speed, weight and slope.
I can't understand that theory. So I can't agree.
You are just confusing the dialog by adding less important information.
And that's just a temporary display as I said. If the graph is added it is no longer needed. I'm afraid but I think your efforts are useless.
I don't think it matters, and it's almost unnecessary except for (electric) train. So I don't know why you stick to it.
We have to sacrifice the display on the other waytype for the (electric) train. I don't think it's good.


QuoteAnd also that is the reason why acceleration is shown also as time/distance to reach top speed. Which is much more informative, but still hidden in a tooltip.
I have repeatedly pointed out that showing it in text is not a good idea. You are trying to convey important information inaccurately. When will the convoy stall? All you have to do is add uncertain information and make the whole display hard to see. So I explain that the graph is good. It makes it hard to see by moving down the vehicle information. As I said, this dialog focuses on the vehicles that make up convoy. And when I thought of moving those information to another tab, I thought it wasn't suitable for this dialog in the first place.
I think the graph patch will probably work just by removing the tooltip. However, since many changes have been made to the master branch since then, conflict is inevitable. I have no time to restart it right now and had to wait for your formula fix to be incorporated.


QuoteAlso one of the reasons is, that acceleration calculation uses other values shown in the convoy details as inputs, so code efficiency is also important. The values are recalculated very often and so I tried my best to avoid repeating the same function calls like get_vehicle_summary(), get_weight_summary(), etc.  During debugging I was in stage where opened convoy details caused significant load, but managed to reduce it.
Charts are in the convoy information dialog. An acceleration chart will be added there. That's also why those displays aren't right for the convoy detail dialog, and why I think what you're saying is incorrect.

Mariculous

Quote from: Ranran on July 22, 2020, 11:57:40 AMI don't think acceleration is important information even in the depot window.
And still it is more useful than the plain force or power values.
Acceleration at given speeds (and given weight) is indeed much more useful information.
A graph works well here, but an "accelerates from 0 to v in t seconds" or "... in d sdistance" might be just as useful.
In any case, braking distance is very important as pointed out already, so any way to display this immediately  is welcome. This information really should not be hiddden somewhere.

Quote from: Vladki on July 22, 2020, 03:03:37 PMn convoy detail tab I expect technical details that are not so important to be shown in the overview that is shown with all tabs
To be honest, that was my understanding of those categories either.


Btw. Transportfever does simulate force and power seperately and acceleration decreases with speed, although I am not sure how physically preciese their simulation is.

Ranran

Quote from: Freahk on July 22, 2020, 05:08:34 PMAnd still it is more useful than the plain force or power values.
I've already explained several reasons, I don't think acceleration notation fits all types of vehicles. And that is complementary information to the tractive force (and weight).


EDIT:
What is the "possible acceleration"? Is it as understandable to the player as I thought so?

Quote from: Freahk on July 22, 2020, 05:08:34 PMBtw. Transportfever does simulate force and power seperately and acceleration decreases with speed, although I am not sure how physically preciese their simulation is.
To be honest, it was so bad that I couldn't seem to observe it from. It looked like it was accelerating very monotonously.