(´・ω・｀)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 (https://forum.simutrans.com/index.php/topic,19512.0.html)
(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.
(https://i.imgur.com/LJjrFHD.png)
(2c) As described here (https://forum.simutrans.com/index.php/topic,19554.msg184961.html#msg184961), 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.
(https://i.imgur.com/F0EMGlj.png)
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:
(https://i.imgur.com/SP9NhOI.png)
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.
(https://i.imgur.com/88OmYHv.png)
(3b)Starting acceleration information is added to the spec tab.
Also made layout consistent with the depot dialog.
(https://i.imgur.com/z79pjb2.png)
(3c)Information on the livery scheme applied to the maintenance tab is displayed.
(https://i.imgur.com/MqqohIW.png)
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
(https://i.imgur.com/S4IGnMn.png)
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. (´・ω・｀)
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.
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.
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.
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.
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
| label | Clear |
| *tooltip | The purchase will be canceled and the cost will be fully refunded. |
case 2: resale cost = 0
| label | Dismantle |
| *tooltip | Dismantle all vehicles in the convoy. No costs will be refunded. |
case 3: Other than those above, it means, nominal cost > resale cost
| label | Sell |
| *tooltip | Sell 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?
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?
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.
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.
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.
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.
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
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.
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.
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...
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.
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.
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.
８) 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 ８) 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.
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.
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.
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.
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
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?
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.
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.
James, please have a look on the above pull request.
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:
(http://bridgewater-brunel.me.uk/screenshots/accel-info.png)
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.
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.
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.
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.
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.
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.
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.
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.
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.
Quote from: Ranran on July 22, 2020, 05:31:12 PMWhat is the "possible acceleration"? Is it as understandable to the player as I thought so?
It is the acceleration possible at current speed, weight and slope. If you come up with better name, you are welcome. I thought about current acceleration, but that is not good, as the train may be decelerating at the moment, or running at top (allowed) speed.
My intent is not to clutter the dialogs, but to show important (braking distance) or interesting (acceleration) values to player in easy way. So far nobody said which of the 3 acceleration and braking values seem to be most useful. Only ranran said that all acceleration info is useless, and said nothing about braking distance.
Quote from: Freahk on July 22, 2020, 05:08:34 PMAnd still it is more useful than the plain force or power values.
Print in gold please...
EDIT: If there is common feeling that too much information is shown, I can modify the patch to show exactly the same values as are shown now, only with fixed calculations.
EDIT2: When the acceleration graph would be available I'm fine with hiding acceleration values (or showing them in debug mode only).
I can see that giving a figure for acceleration is a complex matter and likely to be misleading if that complexity be not communicated. A graph is the ideal way of doing this, but this is likely to be a great deal of work to make a good UI for this.
It is helpful to fix the existing calculation if that is in error.
We definitely need to move away from having six lines of text dedicated to acceleration and braking in the convoy detail window - one line for braking and one for acceleration really is the maximum that is sensible there. If it is too much work to implement a system for players to select the acceleration and braking speed that interests them, probably the best alternative is to use the minimum of the maximum permissible and maximum possible speed for the convoy, irrespective of current way/signalling restrictions. Ideally, however, it would be possible to select between different speeds.
I will have to look into and test the depot dialogue size changes more thoroughly in due course.
Quote from: jamespetts on July 22, 2020, 08:50:34 PMprobably the best alternative is to use the minimum of the maximum permissible and maximum possible speed for the convoy, irrespective of current way/signalling restrictions
James, please can you give an example what is permissible and possible speed?
I think that it is good to use way and signalling limits as well. If I'm interested in proper spacing of signals, and the currently used track or signalling does not allow the train to run at full speed, I can take advantage of shorter blocks.
Should I prepare a patch with display like this?
starting acceleration X m/s/s (Y m/s/s if empty)
brakes from allowed speed in N meters.
QuoteIt is the acceleration possible at current speed, weight and slope.
Why do you check such information with convoy detail? It's strange and can't be helped. What is it useful for?
What is the value of the momentary acceleration?
Again, is it useful for any waytype? Do you carelessly interfere with the viewing of other information?
The slope is not as diverse as the reality, and there are only two types. Let's actually run and check to get that information. It's a troublesome. So I wonder what it is for.
Please compare with the real world. Field verification may be necessary, but it should be done in advance. It's silly to do a thing without system.
For example, convoy info has a speedometer. Why are you trying to show it in the convoy detail instead of there?
The same is true for brake information.
Quoteand said nothing about braking distance.
I just missed it as you do not answer about the m/s/s topic.
At least I don't think it is so important as it requires many lines in the convoy detail.
The same applies to acceleration. It takes time to open the convoy info and then the convoy detail to get that information.
Why do you put it so deep that you say that information is important?
Brake info is basically the information to check when assembling the convoy.
Next, if you want to compare the information of convoy operated on line, line management dialog is suitable.
Sorry, it's not in very good right now and I have some ideas to improve it, but I haven't gotten that far. The last change wasn't very satisfying, either, as I watched the actual work.
I don't know what the output weight ratio, the starting acceleration, or what is good, but I think it is necessary to be able to confirm such information of multiple convoys at the same time. At least it is hard to use even if there is information to use for comparison in convoy detail. And having more lines on GUI is a disadvantage. And there are many cases where the information is unnecessary.
For example, if a large ship is made up of many cabins, their information just prevents checking the cabin information.
Please note that what I say "the information is not important" is when it is placed in that dialog. Even so, it tries to display a lot of text, obscuring other information. This is my point.
When displaying the braking distance on the convoy, it is easier to see it along with the distance to the next station. It displays on the convoy dialog.
It also relates to weight and load factor, but that information is also in the convoy dialog. So I am confused why you try to show it in the convoy detail.
Btw, the ideal spec tab I first envisioned was something like a tabular format.
https://tetsudo-shimbun.com/archives/002/201903/large-5c9c1172ba0cf.jpg
The current Spec tab display is far from my ideal, and I wanted it to be more compact.
This is because the label "weight" is not written 10 times for 10 convoys, but only once.
And the adjacent numbers make it easier to compare.
QuoteA graph is the ideal way of doing this, but this is likely to be a great deal of work to make a good UI for this.
Adding graphs to the depot is complicated and more work. But it is possible to add to the charts already in the convoy dialog, and I will start it after Vladki's formula modification has been incorporated. Charts are not added to convoy detail. I also don't think convoy detail dialog is suitable for having that chart.
Quote from: Ranran on July 22, 2020, 10:56:11 PMWhy do you check such information with convoy detail? It's strange and can't be helped. What is it useful for? What is the value of the momentary acceleration?
Just for amusement ;) Originally I wanted to show the momentary acceleration, along with momentary power output and momentary tractive effort. But cnv->get_power_summary() and cnv->get_force_summary() are protected methods so I cannot call them from the dialog. Therefore I added only the possible acceleration. It still has some value: when convoy goes uphill it may drop below zero. In such case it shows that the convoy is unable to climb that slope if it cannot gain some speed in advance. And yes this is important for all waytypes.
Quote from: Ranran on July 22, 2020, 10:56:11 PMFor example, convoy info has a speedometer. Why are you trying to show it in the convoy detail instead of there?
Just because I want it there. If the other values depend on it I want to see it nearby. I even may close the convoy info window to reduce clutter on screen.
Quote from: Ranran on July 22, 2020, 10:56:11 PMI just missed it as you do not answer about the m/s/s topic.
I thought I said it already. IMHO neither m/s/s or km/h/s is something an average person is able to imagine. Just as kW and kN. What I do is to compare values of available vehicles with each other to see, which one is more powerful. The absolute value (and unit) is not important. It is the relative value. The only reason why I prefer m/s/s is that I can check with real world specs if I calculated the tractive_effort (in dat file) correctly. For player information a graph is much better (but again - it will be compared with others so the units themselves are not that important). Until we have graphs the distance and time needed to accelerate to max speed is most useful.
Quote from: Vladki on July 22, 2020, 09:56:27 PMWhy do you put it so deep that you say that information is important?
Coding laziness - I'm not good at GUI coding. And the convoy info dialog is much more complicated than convoy details. So it was easiest for me to put it there. And I felt that it is a good place. Definitely it is easier to access than as a tooltip in replace dialog. There is already the total power of convoy, etc... so I just added a few more lines. Or should we move all that into convoy info dialog? -> total convoy power, tractive effort, brake force, max axle load, livery, acceleration and brake distance?
Again I agree that 3 values for accel and brake distance are overkill. I was just not sure which one of them is the most useful. So far I feel that breaking from allowed speed is most useful in convoy details, while braking from top speed is suitable for depot dialog. Acceleration may be completely omitted from convoy info if considered useless. But both values should be shown normally in depot dialog (not as tooltip).
QuoteIt still has some value: when convoy goes uphill it may drop below zero. In such case it shows that the convoy is unable to climb that slope if it cannot gain some speed in advance.
Does that really happen in Simutrans Extended? Even a convoy that can only run on flat roads at 1km/h can climb steep slopes at 1km/h. I don't think what you're saying will happen. So it doesn't help that way.
Quotein advance
So why is it in the convoy details? You cannot open the convoy detail without departing from the depot. I don't think it's in advance.
QuoteAnd yes this is important for all waytypes.
I don't think so. I don't care about the acceleration of cars, planes, ships or postboys. Acceleration changes every 1 km/h. There is no value in having to get a value while monitoring it. Just add a useless line. For example, it is common for trains and cars to have a speedometer, but I have never seen an accelerometer. (It seems that a special sports car has a gravimeter.) You are trying to implement it.
I think that the debug display is enough.
QuoteI thought I said it already.
No, I think it only states that YOU want it.
Quote from: Ranran on June 21, 2020, 12:07:25 PM10) 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 ８) and 9), if this display is really needed, it is advisable to make it selectable via the display settings option.
You don't answer the question if it's easy for the normal player to understand. The only reason you need it to create a pakset is that you might need a debug display.
Also, the m/s/s display is completely unnecessary information for people in at least some regions. So I suggested to make it a display option but you ignored it. That way, you try to add a lot of unnecessary information and don't care if anyone finds it annoying. Try to go backwards from universal design.
Of course I might also make such a mistake. If so, please point out.
And James has already pointed this out.
Quote from: jamespetts on January 02, 2020, 11:08:21 AMThis is an interesting patch; thank you. I should note that doing this in km/h/s is almost certainly far clearer to a player than doing it in m/s2, as the former measure is related to something that the player can readily understand (km/h), whereas m/s is not a normal way of thinking about the speed of transport vehicles.
QuoteI agree that 3 values for accel and brake distance are overkill.
Generally, the value displayed in SPEC is the display at the time of capacity.
I think Brake can be combined with KN in one line.
There are too many lines about Speed.
Also, I should have pointed out that external influences are not specs.
Quote- always show the summary, even if the convoy has only one vehicle (before one-vehicle convoys did not show summary)
And you are trying to show it even if there is only one vehicle in the convoy, but the top show the total of convoys. In other words, it is matched with the display at the bottom.
If the convoy consists of one vehicle, the same content will be displayed TWICE (The order is different because you changed it.). You insist on wanting to display acceleration for railway convoys, and thus sticking to displaying useless information, ignoring adverse effects on others. ::'(
And you are adding a value to it that has nothing to do with the summary.
So arguing that it is not fit for the place, combined with multiple conflicts and conflicts and why it is not fit.
Quote from: Ranran on July 23, 2020, 12:46:40 AMGenerally, the value displayed in SPEC is the display at the time of capacity.
What is "the time of capacity"? I dont understand...
QuoteAlso, I should have pointed out that external influences are not specs.
Yes they are not specs, yet they are shown in specs tab: weight of cargo, friction (slope) - for each vehicle, and maybe something more. So it is not all static information anyway.
Quote
Quote
- always show the summary, even if the convoy has only one vehicle (before one-vehicle convoys did not show summary)
And you are trying to show it even if there is only one vehicle in the convoy, but the top show the total of convoys. In other words, it is matched with the display at the bottom.
If the convoy consists of one vehicle, the same content will be displayed TWICE (The order is different because you changed it.).
no it is not! E.g. the power and tracitve effort is multiplied by gear in convoy totals (on the top), but the original value (without gear) is in individual vehicle specs.
Acceleration and braking distance does not make sense for individual vehicles
QuoteYou insist on wanting to display acceleration for railway convoys, and thus sticking to displaying useless information, ignoring adverse effects on others. ::'(
Even a railway convoy can be a single vehicle. And then some interesting information will not be shown.
QuoteSo arguing that it is not fit for the place, combined with multiple conflicts and conflicts and why it is not fit.
Whatewer. I see that we two have a deep misunderstandig of each other. Maybe it is just because none of us is native english speaker and so we cannot express well enough for the other to understand. I give up. Please take my patch, keep the acceleration calculation in convoy.cc/convoy.h, and do whatever you want with the GUI. Show the information wherever you want in whatever way you desire. I'm not that good in GUI coding, so I leave it to you... Howg!
I have modified the patch - reduced the information in convoy details:
- starting accceleration in km/h/s a t current weight and empty (as it was before)
- braking distance from max speed
Display and calculation of all other vriants is commented out, so if anyone finds them interesting, you can just uncomment and use them, or copy & paste to more suitable place to be displayed.
QuoteWhat is "the time of capacity"? I dont understand...
The starting acceleration as a specification used in Japan is when the loading rate is 100%.
A low loading gets higher acceleration than the spec, but in overcrowded gets low acceleration. That is enough as a guide.
It is the most standard specification and will be easy for players to understand and accept.
I think it is enough. However, I don't think there is a problem with the additional display that is grouped on the same line. Because
it supplements the information without much inconvenience. That's not what you are doing.
QuoteYes they are not specs, yet they are shown in specs tab: weight of cargo, friction (slope) - for each vehicle, and maybe something more.
Again
QuoteAfter 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.
summary is a convoy summary. Do not show external factors there. As I've explained many times, there should be a GUI role and a display location suitable for each.
If the vehicle axle load array is something like {10, 9 ,12, 10, 10, 5, 7, 11, 3, 6}, the convoy max axle load will be 12. It is a summary that displays such a thing. It is not desirable to display different types of information there.
It's not a bad idea to display the total braking effort and add any additional information that comes with it.
But you added a few lines of supplements, which are no longer "summary". It is details. And the information of the constituent factors connected to the summary was moved down.
"allow speed" is the same. Where comes from? Is it due to the vehicles that make up convoy? NO, it's from way or signal or catenary, as I already explained. Again, It's neither a spec nor a summary of convoy. You make GUI messed up, ignoring roles and suitable places.
QuoteSo it is not all static information anyway.
Information that does not change at least between stations. (However, friction is excluded. See below)
The Axle load may or may not be related to the weight of the load in the extended specification (There are cases where the gross weight is divided by the axis or where the axis weight is set from the beginning.), and the reason for the Axle load is unknown without the current weight.
Convoy received an error that the axle weight was too heavy. This is the dialog to confirm it. Without that information, we don't know what caused the axle load excess. It doesn't happen often. It is enough to open this dialog when a problem occurs. I asked for this kind of explanation for what you added. You just tried to trick us by saying the wrong thing, like the slope example. Yes, everyone makes mistakes. But I asked several questions about their usefulness, but you didn't answer otherwise. You just enumerated that you want it or you can't it.
And the current weight information is in the brackets and not adding lines. What you are doing is the same as describing the weight in three lines: empty weight, current weight and maximum possible weight. Why didn't you do that? Isn't it inconsistent? It's all about the acceleration and braking information you're trying to display, right? I'm just pointing it out because what you're doing is so inconsistent. And I think it is enough to add a supplementary display on the same line as the brake force for the brake distance. What I asked was "why" you do it on multiple lines, or why put it there.
Possible acceleration - Maybe it's like a theoretical acceleration, like an accelerometer in flat. It is a "real-time" changing value that changes at every speed. Do players really want to "monitor" it? I talked about the role of the GUI a while ago, and is this the right dialog? Is there another parameter there that would be nice to have with monitoring? A graphical speedometer can be found in the convoy dialog.
And now you also add the speed there (as text, not as a bar), and give this GUI a monitoring function. So I asked if it was the role of convoy info. What is its usefulness? You try to mix the division of role of existing GUIs.
Let's go back to the example of the slope. Why did you find real-time acceleration useful for it? Equilibrium speed is used for such things in the real world. You try to make the player to monitor it what system can calculate "in advance".
Quotefriction (slope)
It is one of the ones inherited from the standard. In my opinion, I don't think the display is useful. It only gives a value like how the vehicle is leaning. I don't know what unit this is, and because it doesn't have units, it's hard for players to understand what it is, and it's inconsistent with other values. Perhaps the value that the player does not show much interest.
Originally there was a lot of information about the cargo, so in the last change I focused on separating it so I left it alone. The reason for this was trivial, as I still had suggestions for further improvements.
A simple temporary fix is to show it in debug mode only.
Quoteno it is not! E.g. the power and tracitve effort is multiplied by gear in convoy totals (on the top), but the original value (without gear) is in individual vehicle specs.
This was already pointed out when I implemented it in that thread, and it's just a bug. The sum of the locomotives known to have an output of 1000 kW is displayed as 500 kW for some reason. Did you think there are two types of "kW"? You were saying in another thread as if it was right, but I don't think so. kW is output. Not force. Do not apply simutransic gear. Why does the motor output change when it leaves the depot? You try to distinguish it and cause further confusion. So in the end it's not correct for you to repeat the same texts twice.
QuoteAcceleration and braking distance does not make sense for individual vehicles
"Starting" acceleration is a convoy spec. It is often used in EMU. It is a summary obtained by TF and weight. TF and weight are determined by the spec of the vehicles.
The braking distance is only supplemental information to the total brake force of the convoy. The deceleration rate is constant. Therefore, the deceleration distance from the maximum speed is sufficient, and it is within one line as a supplement.
I don't think it's good to add a value that changes in real time here. As already mentioned, it mixes convoy info and roles by adding monitoring functionality here.
QuoteWhatewer. I see that we two have a deep misunderstandig of each other.
Yeah, I had to go into more detail because you seemed to repeat weird answers or ignore them. In this thread too.
What I wanted to say is that most of the factors I point out interact with each other, making the dialog overall messed up.
There is no problem if you just add supplementary information. But you just stick with increasing the text and line anyway. So I proposed organizing and moving so that the player could easily see and understanding those.
QuoteMaybe it is just because none of us is native english speaker and so we cannot express well enough for the other to understand.
You once again ignored the m/s/s thing and replied only about the rest. You try to implement what was once rejected without any improvement. You ignored all opinions about it. In that way you have sought to prioritize the fulfillment of your selfish desires, which may not be geek's desires, over usability. So I asked you. The answer I asked is a simple question, is it plain or easy for the average player to understand? But you only explained that you want it and you want to do.
"I want a display for debugging and it is necessary for all type of vehicles" - It may not be profitable for the average player. So I didn't think you gave a reasonable answer. Added text that is not wanted by certain people, and the same text is repeated. I see no improvement. So I didn't think it was good.
At least you didn't change anything rather added more information, so it seems that what you were saying was correctly transmitted to me and my words are either not transmitted or you have ignored them. I was surprised when I saw it.
QuoteI give up. Please take my patch, keep the acceleration calculation in convoy.cc/convoy.h, and do whatever you want with the GUI. Show the information wherever you want in whatever way you desire. I'm not that good in GUI coding, so I leave it to you... Howg!
Fine, I didn't tell you to do that. You just ignored all my suggestions without answer any adequate reason. Nevertheless, why do I have to carry out your orders? It's so unfair. But you were a liar. interesting.
Although the modification of the formula is only two line modification so I fixed it and add physics charts (https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/accel-curve-chart).
I have been deprived of you a lot of time and motivation and gave me the opportunity to leave simutrans forum for a while. And you have made me realize that I have done something very inefficient so far. Thank you for that. I will enjoy the summer vacation with corona!
I explained in detail because you seem to be very dissatisfied because you leave it in the code. I'm sorry for the long and dirty sentences because I tried to convey it correctly even a little.
Looking at the last fix, you seem to have just added one line. The formula needs only two lines of modification. I suspect you are making a lot of useless changes unnecessarily. I don't know if it's efficient but it's a good idea to check. For example, calculation is performed even if it is not used. In the end, still unnecessary display is repeated on convoy detail. And I found calling those values directly from convoy_detail. I suspect you are trying to calculate and retain the values used to display the GUI even if we don't display it to the GUI.
And as I have said many times, simutrans extended does not exactly simulate real-world acceleration. They all behave like ancient electric trains.
Despite the contradiction, you stick to the display of real time acceleration value. Before that, I think it's better to stick to working like the real world.
In my personal opinion, I'm happy to have the correct accelerating behavior, rather than revealing that the DMU is accelerating strangely. You want the latter.
EDIT:Finally I posted a physics curve chart patch. It just waited for the formula to be corrected.
You were right about accuracy. I will fix it. - Done.
Quote from: Ranran on July 26, 2020, 09:18:12 PM
It is one of the ones inherited from the standard. In my opinion, I don't think the display is useful. It only gives a value like how the vehicle is leaning. I don't know what unit this is, and because it doesn't have units, it's hard for players to understand what it is, and it's inconsistent with other values. Perhaps the value that the player does not show much interest.
Slope friction is completely arbitrary to the best of my knowledge. When double heights were introduced I set the new single height slopes to have less friction, and the new double height slopes to have more friction than used previously. There wasn't any calculations involved just what seemed to work well in the game. If you were to try and out exact calculations in you'd have to consider what the vertical scale should be and what this was in relation to the horizontal scale used.
Quote from: Ranran on July 26, 2020, 09:18:12 PMI think it is enough. However, I don't think there is a problem with the additional display that is grouped on the same line. Because it supplements the information without much inconvenience. That's not what you are doing.
By grouping do you mean e.g. display of weight? I.e.:
weight: 13.0 t (10.0 t)I do not find that very clear, because there is no explanation of what does the vaule in brackets mean. Therefore I went for more explanatory multi-line display. So better it would be (as I did originally):
weight: 13.0 t (empty: 10.0 t)And even better would be:
weight: 13.0 t (empty: 10.0 t, full: 15.0 t)But the problem with other values was that I could not come up with nice short description so that it would fit into one line. So I went for multiple lines. I know it is not optimal, neither consistent, and as you see I removed most of the values you objected to. E.g. the "possible acceleration" - I showed it because I thought it might be interesting to someone. At least I had some fun watching this accelerometer ;-) Also it helped me to confirm if the acceleration formula is working well (possible acceleration was decreasing as the vehicles gained speed). But now it is removed so let's forget about it. OK? Same about current and allowed speed, and current braking distance.
Honestly I did not think about the convoy details as static specs, but as a place to put less important information that does not need to be in convoy dialog. Originally I did not want to modify the GUI at all, but when I was fixing the acceleration formula, I had to touch the convoy details (specs) and so I used that place to show other information that I was interested in.
Quote from: Ranran on July 26, 2020, 09:18:12 PMLet's go back to the example of the slope. Why did you find real-time acceleration useful for it?
Because some time ago there was a problem that road vehicles could not climb hills if stopped just before the hill. Well they crawled 1 km/h, but that was still a problem. So I thought that in such situation the "possible acceleration" would be 0 or negative, and could be used as indication that there is something wrong. But I agree there are other ways to find out about such vehicles.
Quote from: Ranran on July 26, 2020, 09:18:12 PMIt only gives a value like how the vehicle is leaning. I don't know what unit this is, and because it doesn't have units, it's hard for players to understand what it is, and it's inconsistent with other values. Perhaps the value that the player does not show much interest.
Althought that value is named friction, it enters the physics engine as sin_alpha (multiplied by 1000). For small angles it is equal to slope gradient in per mille.
About the display of power, tractive effort and gear - I did not change any of that, so please do not be personal about that. I agree it is not consistent to show the value multiplied by gear in one place and raw value somewhere else. But I'm not going to overhaul the whole convoy detail/specs window. I just added a few more values, and left the rest as is.
Quote from: Ranran on July 26, 2020, 09:18:12 PMYou once again ignored the m/s/s thing and replied only about the rest.
As you can see, there is no m/s/s in the last version of patch. Thinking more about it, I consider m/s/s and km/h/s equally useless. From the player point of view the most interesting information would be the distance needed to reach maximum speed. That is something you can use in planning - you know the distance between stops and see if the convoy can get to top speed before it has to stop in next station.
Quote from: Ranran on July 26, 2020, 09:18:12 PMI have been deprived of you a lot of time and motivation and gave me the opportunity to leave simutrans forum for a while.
Sorry about that. I didn't want to hurt your feelings in any way. I really like the improvements to the GUI you did, and it would be a big loss if you would go away. Once again, I'm very sorry about that.
Quote from: Ranran on July 26, 2020, 09:18:12 PMLooking at the last fix, you seem to have just added one line. The formula needs only two lines of modification. I suspect you are making a lot of useless changes unnecessarily. I don't know if it's efficient but it's a good idea to check. For example, calculation is performed even if it is not used. In the end, still unnecessary display is repeated on convoy detail. And I found calling those values directly from convoy_detail. I suspect you are trying to calculate and retain the values used to display the GUI even if we don't display it to the GUI.
I wanted to comment out all calculations whose results are not displayed. Can you point me more precisely which value is calculated but not shown?
Also many of the changes are just about efficiency. E.g. cnv->get_weight_summary() was called several times, now the value is stored and used for calculating and displaying weight, acceleration and braking distance. Same reason is for storing cnv->get_min_top_speed(), as it is used to calculate the braking distance.
Also I joined the calculation of time and distance to reach max speed into one function that returns both. They share quite a lot of code and can be efficiently calculated at once. But this function is called only from depot window. Due to its iterative nature it is not suitable for realtime display in convoy details. It would cause noticeable additional load.
Further I renamed the function convoy_t::calc_acceleration() because there already is convoi_t::calc_acceleration() which does something completely different.
Quote
And as I have said many times, simutrans extended does not exactly simulate real-world acceleration. They all behave like ancient electric trains.
Despite the contradiction, you stick to the display of real time acceleration value. Before that, I think it's better to stick to working like the real world.
In my personal opinion, I'm happy to have the correct accelerating behavior, rather than revealing that the DMU is accelerating strangely. You want the latter.
Maybe the physics engine used in simutrans is not perfect for diesel vehicles. I do not contradict that. All I want is that the values shown to the player are matching the physics engine used in simutrans. So if the calculation (shown in depot) says that it accelerates to full speed in 1 km, it should do so in 8 tiles. And as you can see I removed the "accelerometer". All I want about acceleration is to be able to use "max acceleration" from real world specs to calculate max. tractive effort, so that the vehicles behave at least approximately like they do in real world. So the display of starting acceleration is just a cross check for pakset developers, that they set the tractive effort correctly.
Hello all,
I'd like to move on with this patch to clean up my table so I can focus on other things.
First I'd like to apologise to Ranran if I have hurt his feelings. I'm really sorry, I did not intend to hurt anyone.
Now the patch is reduced to really only fix what was necessary:
1. the acceleration calculation itself, which I hope is now as precise as possible. Although there is still some error in the calculation of total time and distance needed to reach given speed. That is probably due to the iterative nature of the calculation, done in steps of 1 km/h, where in each step a constant acceleration is assumed. If anyone can find any mistakes in the calculation, please tell me.
2. the methods for acceleration calculation a renamed to avoid conflicts with previously existing methods in other classes. Also the iterative calculation of time and distance was joined into one function to optimize the computations. Thus the code for calling these methods had to be modified too.
3. convoy detail info (specs) is back to the current mode - only starting acceleration is shown. No display of braking distances, allowed or current speeds, current acceleration, etc. All of these are commented out in the code, so if anyone would find them useful, can uncomment them. If there would be a consensus what is useful, and where it should be shown, thay can be moved to other places in the convoy info dialog. The convoy totals, are shown only if the convoy has more than 1 vehicle, or the game is run in with -debug on command line. Friction (slope) is shown if >0 (used to be >1).
4. depot/replace dialog, all acceleration info is show as is (in a tooltip) - no change. Only important change is that the minimum window size is not 24 vehicles, but 680px - which is equivalent to 24 vehicles in pak128 (but 12 in pak256, and 18 in pak192). This is due to the dual column display of assembled convoy specs, which look weird in non-128 paks.
Pull Request here: https://github.com/jamespetts/simutrans-extended/pull/184
I'd like to do one more change - the time to gain full speed is now shown as float - which is imho useless, especially given the still bad precision. But there already exists simutranslator entry for it: "; %i km/h @ %.2f - %.2f sec". I'm not sure If I can remove or modify a translation text. Although in this case I think the translation is not necessary - it is just numbers and units and some interpunction.
Thank you for your work on this. I am currently prioritising the merging of the latest GUI from Standard on which Ranran has been working, which has been a long and difficult project so far because of library dependency issues.
Can I check whether this work is compatible with the latest code on that branch?
I have checked it only against "master". Which branch should I compare it to?
Quote from: Vladki on October 25, 2020, 01:35:52 PMAlso the iterative calculation of time and distance was joined into one function to optimize the computations.
Optimized computations as in a gain of performance?
Does this really improve anything? Modern compilers are quite tough and will usually inline such calls when it's worth it or use other kinds of optimizations.
It's often better to use clean code rather than "optimized" code, which the compiler will optimize for you anyways.
Surely, there are some optimizations that are definitely worth it.
Quote from: Vladki on October 25, 2020, 01:35:52 PMAll of these are commented out in the code, so if anyone would find them useful, can uncomment them.
That is unhappy. Imho those stats are very useful and at least acceleration to and braking from maximum speed should be shown in the depot as well as convoy details (spec tab) without any mouseover tooltips.
We are currently 4 people developing and testing the pak192.comic extended port. Except from myself they were all new to extended and all of them asked me how far the signal spacing should be, because they had no idea the brake distance was hidden in a mouseover tooltip in the depot, and only in the depot! Once sent out, you can't see it at all.
A configurable weight, v_is and v_target, which then is used to calculate time and distance would still be most useful and appreciated. That means calculating acceleration time and distance when v_is < v_target as well as calculating braking time and distance when v_is > v_target.
I agree this requires some GUI working, so might not be that easy to implement for someone who doesn't know the UI code (like you and me)
About friction (slope), iirc it can be negative when running down a slope, thus should also be shown in those cases.
Optimization was in the sense that, time and distance to max speed are calculated together at once in one function. Before it was two functions, which did almost identical calculations. So this is something that the compiler would not be able to optimize. This was mostly about code cleanup.
I can easily add display of some values to convoy details in debug mode. Which information exactly you would find useful? I'm reluctant to show them by default. I do not want to get again into discussion with Ranran about what is useful or not or if it should be in convoy info, detail, specs or somewhere else...
Fiddling with depot window tooltips would be much more complicated. And if Ranran is working on some GUI changes, I'd like to keep the changes minimal to be able to merge them.
BTW, you can see the braking distance in replace window tooltip too.
Fixed the friction display, so it shows as before, if friction != 1
Quote from: Vladki on October 25, 2020, 05:15:45 PMI can easily add display of some values to convoy details in debug mode.
I need them when playing the game, not when debugging.
Imho acceleration to maximum speed and brake distance are the best we can come up with for now.
Major effort might be put into the graph or a configurable v_is to v_target calculation, but as long as there is no such information provided, 0-vMax is most useful.
Quote from: Vladki on October 25, 2020, 05:15:45 PMBTW, you can see the braking distance in replace window tooltip too.
Well, a hacky any very unintuitive solution, but seems to be working.
I think you guys are getting ahead of yourselves.
First of all, the change to the depot dialog should take into account the upcoming variable font size.
With that in mind, it turns out that this dialog needs to be made more compact.
Increasing the amount of information can end up in vain effort.
I haven't made any changes to that dialog except for the replaced functions and font size and symbol inconsistencies on the GUI overhaul branch.
Still, it has a lot of problems with the above and the dialog is broken. That's the problem it had potentially.
Since fixed values are specified for the font size and line size, it is not adapted to changing the font size and the layout is broken. The characters are displayed outside the window. Full HD monitors may be too small to display a depot dialog.
It's too big compared to other dialogs, which ruins the font resizing feature. That's why this dialog needs to be compact.
(As I've already reported, a generic dialog dominated by text has a similar issue, but it's probably not difficult to fix.)
Ideally, as previously proposed, I plan to make the physics chart visible in the depot. It's almost done.
Add an acceleration chart to the convoy detail dialog and make the convoy detail dialog accessible from the depot.
If you open the dialog from the depot (if convoy is in the depot), the physics chart tab will open.
(https://i.imgur.com/29vIWZf.png)
(https://i.imgur.com/f5ogvaa.png)
Therefore, some physical information can be moved to that dialog and deleted from the depot dialog.
We could add some other physics information to the top of the graph on the Physics Charts tab.
I think you are trying to create competition and retrograde again like that.
QuoteI do not want to get again into discussion with Ranran about what is useful or not or if it should be in convoy info, detail, specs or somewhere else...
I don't want to talk to you either, but I don't want to work to resolve unnecessary conflicts either.
But I think it will take some time before they are implemented. Minimal efforts to improve the status quo should be welcomed.
What I mean is that putting a lot of effort into it results in wasting each other's time.
The depot is a different story.
It would be very nice to ge these informations there, but it it's really not possible, we'll need keep explaining that those informations are shown in the mouseover tooltip.
The main issue I got is the specs of existing vehicles.
We got a spec tab in the convoy detail window, where people would actually expect... well... convoy specifications. They do not expect to get those informations only when abusing the replace feature.
Adding two lines of information to that long list really doesn't hurt!
See an example image.
(https://cdn.discordapp.com/attachments/699953627095367720/770046359326687272/unknown.png)
90% of the space is used for the vehicle list (and it's still a few lines less than the whole list. Scrolling is fine, that's why it exists!). Adding two lines of information to that list really doesn't hurt anyone and if it really does, slightly reducing spacing between two vehicles or using a horizonal line instead, will save much more space than these two lines consume and it different vehicles will still look quite well seperated from each other.
If you really really really still don't want to "waste" those two lines of space, at least add that information as a tooltip, just as it it in the depot, although I strongly anticipate with this in favor for simply adding these two lines.
Edit: About the depot, showing 5 lines instead of 4 does not consume pretty much space compared to the images too.
If we need to save space, downscaling the images might be prefered over hiding essentially important informations. Te extended newcombers from pak192.comic really did not know that information existed before I told them.
First, consider the font size and image size as described above.
I don't think the current dialog is very easy to read. Changing it a little doesn't improve anything.
Secondly, you are aiming for an improvement from 5 to 6. But I think there is a difference that I am aiming for an improvement from 5 to 10.
I'm thinking of completely destroying the design of the dialog and overhauling it.
When the font gets bigger and the dialog gets bigger, it has to be tidy. Such a GUI, which displays information on only two or three vehicles on one screen, is a very bad design. Repeating the same text, useless whitespace, I want to get rid of it.
By the way, what are the two lines?
I totally agree with this!
A more tidy depot dialogue would be great. Especially on the bottom side, there seems to be a lot of unused lines, though it might be used under some special cirumstances.
I just do not agree with dropping or hiding essential informations. It's fine if there really is no way around it, but it should really tried to get that information displayed there directly, instead of hiding it.
Imho, the brake distance and acceleration distance are even more important than their base values in the convoy (force, power), because the latter is basically useless information to the player.
Another point is way wear factor.
It got it's own directly visible field in the depot, but did anyone ever do any kind of decision making based on it, or does understand how much a way will wear out when a vehicle with a specific way fear factor passes over it?
Well, i don't and I haven't heard of anyone so far.
Hide it in the weight tooltip of and you got space for at least the braking distance. It's most important, as tracks are usually already prepared with a specific signal spacing.
You might also consider to merge weight and axle load into one, hide away the way wear factor alongside rolling resistance and you got space to show braking distance as well as acceleration distance directly.
Not sure if this one is preferable over the previous one, but braking distance should definitely be shown in th the depot as well as in convoy details, except if there is really no way to do so.
I suspect I repeat myself, but the braking distance really is one of the most important specs, at least when the train is meant to operate in time interval, absolute block or track circuit block working method, which is the great majority of cases.
Quote from: Ranran on October 25, 2020, 10:04:35 PMMinimal efforts to improve the status quo should be welcomed.
And that is exactly the current status of my patch. It does not change the display, only the calculation (and the way the acceleration calculation is invoked).
I'd like to get this merged before the big GUI overhaul.
Regarding the accleration, and other graphs. I think they should be accessible only from the depot. All information in the covoy info/details is live, and gets recalculated quite often. Acceleration, and braking distance is iterative calculation, thus quite demanding. When I was testing the display of multiple braking distances in convoy details I could see noticeable increase in CPU load. One braking distance was acceptable.
Quote from: Freahk on October 25, 2020, 09:59:36 PMMajor effort might be put into the graph or a configurable v_is to v_target calculation, but as long as there is no such information provided, 0-vMax is most useful.
The function to calculate acceleration time and distance, and braking distance, take weight and speed as argument, and thus calculate acceleration from 0 to given speed, and braking distance from given speed to zero.
Acceleration calculation can be easily modified to give acceleration time/distance between any two speed, but I do not see much use for that. Braking distance calculation is done in other places too, so this would need touching many more places in the code.
I think the same issue Freahk pointed out about the reconstruction of "halt info" and "halt detail" can be said for "convoy info" and "convoy detail".
What I said in that thread can also be said to these. They were unified in standard but should not be unified in extended. And the convoy info dialog is tabbed by GUI overhaul. I think it is better to create a new tab in convoy info and move some information such as the current working method information there. Convoy info seems to be specialized in displaying the current state of the entire convoy. That's why I previously said some information wasn't appropriate to be there, but it's ready to put them by the GUI overhaul. You can put the convoy spec that you can see on the replace screen to the new tab on the "convoy info". The operation buttons are removed from the convoy detail and moved to convoy info.
I think it is appropriate to put the starting acceleration and acceleration distance information in the physics chart tab.
I agree with the braking distance at the depot dialog. As a simple correction, waywaer factor and the braking distance have been swapped. A pull request has been made with a recent depot dialog fix. please confirm.
I don't think the waywear factor makes much sense with the numbers as they are. I think it would be good to display how much way damage is predicted together with the revenue forecast and monthly fixed costs. I think that will be also improved by allowing access to the convoy detail from the depot.
Performance seems to have been significantly improved by incorporating it from the standard for some reason.
And as I advised earlier, I'm afraid you're always trying to do unnecessary calculations and save them to all convoys. For example, of ma = F, it is not necessary to calculate and hold m, a and F. I don't think adding one new piece of data to one GUI will hurt performance that much.
Quote from: Ranran on October 26, 2020, 08:31:36 AMAnd as I advised earlier, I'm afraid you're always trying to do unnecessary calculations and save them to all convoys. For example, of ma = F, it is not necessary to calculate and hold m, a and F.
Please can you show directly in the code, which calculations are not necessary? I was specifically trying to avoid such duplicate calls - if there were multiple calls to cnv->get_something(), I have replaced them with one call, and stored the return value for further use. In acceleration calculation the time and distance to reach top speed are calculated at once, instead of two very similar iterative calculation. I'm not calculating anything that is not displayed, or used in further calculations.
QuoteI don't think adding one new piece of data to one GUI will hurt performance that much.
Depends. E.g. starting acceleration is quite easy to calculate. Basicaly F(engine) - F(resistance) = ma. But the acceleration and braking distance calculations are iterative (how much time it takes accelerate from 0 to 1 km/h, how much time from 1 km/h to 2 km/h, etc, and sum it all up.) And that is noticeable. Not causing visible lag, but noticeable increase in CPU load, which may be put to more important task, or may be missing on weaker CPU. Therefore recalculating it every "step" is IMHO not a good idea.
regarding the way wear factor. I think it was discussed previously. IMHO a good solution would be to highlight if the wear of the vehicle is different than the default value calculated for its axle load. And then the difference should be shown. Typical example are 6-axle heavy locomotives Co'Co' like russian M62 taiga drum. Such engine causes higher wear than a Bo'Bo' or Bo'Bo'Bo (often seen in japan) with the same axle load. (Czech railways have more strict speed limits for Co'Co' engines in curves).