News:

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

[patch] Depot dialog improvement and convoy detail dialog adjustment

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

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Vladki

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

jamespetts

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.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Vladki

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.

Ranran

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.

Vladki

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

Ranran

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

Vladki

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!

Vladki

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.

Ranran

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

kierongreen

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.

Vladki

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.

Vladki

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.

jamespetts

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?
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Vladki

I have checked it only against "master". Which branch should I compare it to?

Mariculous

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.


Vladki

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

Mariculous

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.

Ranran

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.



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.

Mariculous

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.

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.

Ranran

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?

Mariculous

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.

Vladki

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.

Ranran

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.

Vladki

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