Viewing curve speed limits and calculating acceleration time/distance

[jamespetts]

The "accelerates to 100km/h in X seconds" is probably unworkable: there will be many convoys that cannot reach 100km/h at all (think of early freight trains and trams, for instance) and there will be many that take many, many minutes more to reach 100km/h than to reach 95km/h or even 99km/h; so this display does not give a useful general comparison between vehicles, nor does it provide (except in a few cases) a useful applied metric.

Ideally, one would have an adjustable applied metric (accelerates to Xkm/h in Ykm, with players able to alter either X or Y and the other of the two numbers being calculated), but I anticipate that this may be a lot more work for RanRan. However, it is better to have at least some comparison of acceleration than none.

[Sirius]

So what I suggest is the follwing two things:
1. Show "accelerates to <selectable speed> in ... seconds" in the depot for a given train, to get a rough overview of acceleration of a train.
2. Show calculated travel times for full and empy trains (maybe also not overcrowded full times) in between stations in the "times history" window.

The first just seems to be what you suggested
The second is just for completeness. Afaik it's WIP but don't know for sure.

[jamespetts]

Qayyum - a slider might be a fairly easy interaction for the player, but I suspect that it would be difficult to code as there is no existing control in Simutrans in the form of a slider.

Freahk - yes, there is some sense in that suggestion; but the question is whether Ranran is realistically able to code this within a reasonable time.

[Qayyum]

Maybe 'change numbers as convoy added'?

[Ranran(Hibernating)]

Thank you for your feedback. Ranran eats it and gets fat and more juicy.
Let's clear the issue one by one. Ranran are an army of used up freaks. (´・ω・｀)

About Bernd Gabriel's acceleration chart, I have made some jalapagonize to it. Please taste it, you sommeliers.





1) Acceleration chart is exclusive with other charts. Now the acceleration chart is a lonely wolf.
This is to resolve unit conflicts.


2) The x-axis of the acceleration display has been increased due to the benefit of 1). About 1 minute acceleration is displayed every 2.5 seconds.
Why 2.5 seconds? Good question. The x-axis has different colors alternately. Two axes are 5 seconds and four axes are 10 seconds.
And, when displaying Acceleration, the unit of the x-axis was hidden.
This is because the x-axis of the current lazy chart can start at a specific number, such as a specific year, but can only count in increments of one and try to display it all.
I thought it would take time to change this. So Ranran is also lazy. (´・ω・｀)


3) I have set a tooltip for these chart buttons since currently no tooltip has been set.
Note that since I do not speak English, the same text as the button is currently set as a dummy.
Anyone who speaks the right English can help with this edit.
The tooltip that should be displayed for "acceleration" would be something like:

Code Select Expand

This chart shows how the convoy accelerates for one minute.
(direct translation of my Japanese by Dr. google translate)

Code Select Expand


static const char cost_tooltip[BUTTON_COUNT][128] =
{
"Free Capacity",
"Transported",
"Average speed",
"Comfort",
"Revenue",
"Operation",
"Profit",
"Distance",
"Refunds"
//, "Maxspeed"
//, "Way toll"
, "This chart shows how the convoy accelerates for one minute."
};


4) This acceleration chart has been changed so that the direction of the graph is fixed regardless of the setting of left_to_right_graphs.


Hope for more feedback. Thank you.

[Qayyum]

Code Select Expand

This chart shows how the convoy accelerates for one minute.
Can be changed to this"

Code Select Expand

This chart shoes the behaviour of convoy when moving forward constantly from start of journey to one minute after, assuming no junctions.

[Ranran(Hibernating)]

This chart shoes the behaviour of convoy when moving forward constantly from start of journey to one minute after, assuming no junctions.

Thank you for the proofreading.
The content is correct, but I think it's too long to show in the tooltip. Is it possible to shorten it a little further?

[jamespetts]

Thank you for your work on this. One question about units again, if I may: does "one minute" here refer to a minute in real time or in-game time? The latter would be more useful, I think.

[Ranran(Hibernating)]

One question about units again, if I may: does "one minute" here refer to a minute in real time or in-game time? The latter would be more useful, I think.

I inferred that it was one minute from the acceleration display calculated from the traction force displayed in the depot. When confirmed in the game, it seems to match 1 minute in the game.

[jamespetts]

I inferred that it was one minute from the acceleration display calculated from the traction force displayed in the depot. When confirmed in the game, it seems to match 1 minute in the game.

Splendid, thank you for confirming: that is very helpful. This does look very interesting. It will not be practical for me to test this until I get home next week, but I should in the meantime be interested in others' feedback on how useful that this feature is likely to be. Since it has already been coded, it only needs to be slightly useful (and not cause any other problems) to be integrated.

The real question is whether the extra space taken in the convoy overview window with charts is worth the extra data: I should be interested in players' views on that question.

[Qayyum]

Code Select Expand

This chart shoes the behaviour of convoy when moving forward constantly from start of journey to one minute after, assuming no junctions.
To RanRan: Let me see...

Code Select Expand

This chart shows constant acceleration of convoy in one minute after departing. One minute in-game.

[Sirius]

The real question is whether the extra space taken in the convoy overview window with charts is worth the extra data: I should be interested in players' views on that question.

Generally, I think such a graph (velocity/time graph if I read it correctly) could be worth the space and we could hide the charts, just as the vehicle window does, so people with small resolutions are not too much affected by scrollbars or whatever.

However, what makes me unsure if it's worth is the fixed 1s x-axis, as I suspect that short time is not sufficient to compare characteristics of long-distance trains, which need longer to accelerate, especially for older steam or diesel trains.
Would it require much more work to add meaningful labels to the x-axis and scaling the x-axis by a calculated value?
It would be much more useful to display the graph up to a point where the acceleration becomes reasonably small (hardcoded threshold)

Additionally, I would suggest adding an acceleration/velocity diagram, as it was considered useful in the discussion and we get it nearly for free. The only thing we have to do is turning the values obtained by get_force_summary divided by mass into a graph.

[Qayyum]

Jamespetts, I think this feature is useful. I would use to determine how many wagons can I have at maximum, referring to the condition of route itself.

[Ranran(Hibernating)]

The real question is whether the extra space taken in the convoy overview window with charts is worth the extra data: I should be interested in players' views on that question.

The chart is foldable and no buttons are displayed when the chart is folded.
Somehow there is room for one button, but I'm guessing this was originally intended by Bernd Gabriel.
I think this "empty" is meaningful to show that the chart is exclusive. Also other charts show monthly data, acceleration chart is not based on that rule.

On the other hand, this chart may be unnecessary information for a specific waytype. For example, air waytype. I'm not convinced that this is unnecessary for ships, but I don't think it makes sense if player can't change its formation. We always have to accept its performance. If acceleration is abnormal, it is a pakset setting error.
Thus, it would be possible to remove it from the airplane convoy dialog.

However, what makes me unsure if it's worth is the fixed 1s x-axis, as I suspect that short time is not sufficient to compare characteristics of long-distance trains, which need longer to accelerate, especially for older steam or diesel trains.

I edited the gui_chart_t code of the x-axis so that I could change the settings of the x-axis labels. As a result, the x-axis has been expanded to 120 seconds.

However, varying the x-axis has some complexities and issues. X-axis scaling, axis labels do not look good etc.
Bernd's chart is influenced by changes in the maximum speed of the track/signal and the weight of the convoy. So it is necessary to calculate the maximum speed arrival time in the worst case in advance and determine the x axis first.
It's not impossible but takes more work.
The same scale may make it easier to see poor acceleration. I would like to ask everyone's opinion on whether 120 seconds is inadequate and in this regard.

Additionally, I would suggest adding an acceleration/velocity diagram, as it was considered useful in the discussion and we get it nearly for free. The only thing we have to do is turning the values obtained by get_force_summary divided by mass into a graph.

I don't think a(or F)-t graphs are useful; Acceleration is clear from the v-t graph; Strictly, time does not directly affect acceleration (or tractive force);
get_force_summary returns a value regardless of the maximum speed of convoy. In other words, it returns the full power value whether it is coasting or decelerating.
Bernd's chart is influenced by the current convoy status. In some cases, the maximum speed of the track is lower than the maximum speed of the convoy, in which case it does not accelerate (also in the chart), so we need to switch to a force for coasting to resolve the inconsistency. It takes a bit of work, but I don't think that chart is worth it for the reasons mentioned above, so I suggest the following F-v graph:



As I mentioned in a previous post, this is a graph often used to characterize motor vehicles. The upper line represents tractive effort, and the lower line represents running resistance. The difference between them is the accerelation force.



Judging from recent demands related to physical codes,

Fractional power and tractive effort values[*S]

Currently, it is only possible to specify power and tractive effort in units of kilowatts or kilonewtons. This is problematic for very low powered vehicles (e.g., bicycles, horses), as it is not possible to set realistic values for power. Internally, the physics engine can cope with fractional values of power and tractive effort, and it is possible to work around this to some extent for power by using "gear", but this is not effective for tractive effort.

It would thus be useful to be able to specify power and tractive effort as decimals of up to two decimal places (in the same way that weight can now be specified as a decimal). This should be relatively straightforward to implement, but does require some work in altering the memory structures to accommodate it.

I suppose it's time to make this change. As you can see from the chart above, the tractive force of the vehicle can currently only be specified in kN units, but it is actually calculated in N units. In real world, many vehicle specifications actually use finer units than kN.

[Sirius]

I don't think a(or F)-t graphs are useful;

I fear, I can't follow this. You are talking about an a/t or F/t diagram, while I suggested an a/v diagram.
The implemented f/v diagram is just the same as the suggested a/v diagram, apart from a constant factor, which is effectively a y-scaling, so I'm totally fine with that implementation.
Additionally, adding the running resistance to the graph is a good idea in my opinion.

However, varying the x-axis has some complexities and issues. X-axis scaling, axis labels do not look good etc.

That given, I would stick with the fixed 120s for now and change it later on if we encounter this to be insufficient for some vehicles.

[Ranran(Hibernating)]

while I suggested an a/v diagram.

Sorry, you said "we get it nearly for free" so I thought it meant a graph where the x axis is t. And I didn't think that you meant was to point to the same thing as I showed in Reply # 29.
The F-v chart I proposed is not related to Bernd's chart code. Because that chart gets convoy data for each delta_t.

I chose the y-axis to be F (do not subtract the resistance) instead of a because I wanted to show the effect of running resistance on high-speed vehicles.
Ideally, make labels for F and a on the y-axis, but that would take extra effort.

I think that the tractive effort chart will complement the acceleration of 120s over (not seen in the chart) to some extent.
The slowness of acceleration at high speed can be found by looking at the tractive effort chart.

And the speed after 60 seconds and 120 seconds can be used as one barometer to compare the performance of convoy. Therefore I like fixing the axis (for a convoy already in operation).

EDIT:
I added to the convoy info dialog this time, but The ideal is to be able to see the F-v graph when assembling the convoy at the depot. (maybe open another dialog or switch tabs)
Preferably, a graph showing the acceleration time up to the maximum time is also displayed there.
Now that we know that we can display two charts with one button, we should be able to show two charts, the maximum load and the minimum load.

[Ranran(Hibernating)]

One odd button margin seems to be for the "Refunds" button to appear under certain conditions.
So the extra space that James is concerned about can already be created by this "Refunds" button but I have never seen this "Refunds" button appear. 

I've looked into this and found that this "Refunds" button and record may not currently work.
I created a stuck in demo.sve and generated many refunds. You can check it here.
However, no convoy displaying "Refunds" button anywhere.

James - I'm not sure if this is a bug, but if it's a bug please separate this post.

[jamespetts]

Thank you for your work on this, and my apologies for not having had time to look into this hitherto - I have quite a long queue of things that I am slowly trying to get through as and when I have time.

Thank you for investigating the refunds issue. That does appear to be a bug on the face of it, although I have not had chance to look into that reproduction case at this stage.

One query is whether the acceleration button and refunds button conflict when the refunds button is displayed; perhaps you could look into that? That would be most helpful.

[Ranran(Hibernating)]

That does appear to be a bug on the face of it

The refunds button I mentioned above is about the convoy info dialog, but the refunds information also can be checked in the Line management dialog to see the total value of the convoy on the line.
However, refunds charts continue to show 0 on any line despite a large amount of refunds. I think this indicates that refunds may not be recorded correctly.

One query is whether the acceleration button and refunds button conflict when the refunds button is displayed; perhaps you could look into that?

After removing the refunds button-hiding code and testing, I get the following display:

Originally, this button is hidden when there is no refunds data, so there is a space here.


EDIT: No margin on the left side of chart buttons, now I fixed this.

[Matthew]

I tried to build Ranran's dig-the-acceleration-curve branch to test this new feature. It compiles and runs, but I can't see the Acceleration and Tractive Force buttons in the convoy window. Is this expected? I understand this is work-in-progress and maybe some parts are not on Github yet. 

Also, the convoy window had some new bad behaviour. If I followed a convoy and then moved the convoy window, then only the menu bar of the convoy window was visible. The other parts (data, charts, etc.) disappeared.

I can do full steps-to-reproduce for both points if you want.

P.S. The most likely reason for the problem is that I have made a mistake with Git or in Simutrans, of course!

[Ranran(Hibernating)]

Oh sorry, I think I have fixed it. It's my mistake. 
Thanks for testing and reporting. 

[Matthew]

Oh sorry, I think I have fixed it. It's my mistake. 
Thanks for testing and reporting. 

Thank you for replying so quickly! I tried compiling your dig-acceleration-curve-chart branch and testing it. But it crashed two times.

Steps to reproduce:
1. Open Simutrans-Extended and make a new map.
2. Build stables (horse depot) and two stops.
3. Open the stables and build a convoy between the stops.
4. Start the convoy and then open the convoy window.
With the normal version, it crashed here. I compiled a debug version and got a little further:
5. Click on 'Tractive Force'.
The debug version crashed here.

The simu.log file from the debug version is here. The Linux terminal had an extra error message:

Code Select Expand

*** stack smashing detected ***: <unknown> terminated
Aborted (core dumped)

I don't know where the core dump is placed. If it's helpful then I can upload it.

By the way I enjoy playing with the livery patch. 

[Ranran(Hibernating)]

I downloaded it from my repository and compiled it, but I couldn't reproduce the crash.


Do other self-built versions crash?

[Matthew]

I downloaded it from my repository and compiled it, but I couldn't reproduce the crash.

Ranran, thank you for the quick reply. I checked again that I was up to date with your dig-acceleration-curve-chart, changed back to the normal (not debug) config, deleted my /build folder, and recompiled. I still get a crash after the same steps to reproduce. I have tried pak128.Britain-Ex in 1750 with a post boy like your screenshot. I also tried pak128.Sweden-Ex, in case I had somehow corrupted my Britain-Ex. Every time I got a crash when I tried to open the convoy window.

The build number is #3919923.

Do other self-built versions crash?

This is a very good question. I am a newbie and it's very possible that I am making a mistake. Thank you for your patience.

Other self-built versions do not crash in this way, though. I compiled James' master branch up to last night (20-01-19 0500 GMT) and my build runs OK. My build had the same version number as last night's Bridgewater-Brunel build (#b4e7900). I am building with G++ on Linux. I have attached my config.default, in case there is a mistake or difference there (I added .txt so that the forum accepts it).

[Qayyum]

Matthew: Try download this to your computer where you run your game.

[Ranran(Hibernating)]

Matthew - Thank you for the report. Perhaps those files are useless for the cause of the crash in this case, but the information that it does not crash on other versions was a hint. So I came up with one of the possibilities and made a fix for it.
Well I guess it was caused by my lack of knowledge - my apology.

I suppose Bernd's acceleration chart code was originally coded to not be used under certain circumstances. So I've changed the code that would have to be skipped if it wasn't supported. (I removed it because I wanted to see the buried chart.  ) So I fixed it.
If it's fixed correctly, you won't be able to use this chart instead of causing the crash in your build.
I don't know what OS, compiler, lack of libraries, what makes it unavailable on your computer because I am not familiar with it. I would be grateful if anyone could give advice on this matter.

[Sirius]

I would be grateful if anyone could give advice on this matter.

It will be easyer to have a look at it if you told us your observations. To be preciese: Where in the physics code do you expect it to crash?

[jamespetts]

Ranran - thank you for your splendid work on this, and apologies for not having been able to look into this earlier. I have now had a chance to test this. I have not noticed any crashes when using this.

Ultimately, this is a useful feature well presented and it would be good to be able to incorporate this. However, there are one or two anomalies at present that need at least some further consideration.

First of all, the acceleration curve seems to be capped at the current way's speed limit, so, for aircraft on a taxiway, for instance, it gives acceleration only up to 32km/h: one has to wait until an aircraft is flying before one can see real acceleration. The same would presumably apply to a train in a depot with a low speed track.

Secondly, the curve seems to change over time for reasons that are not entirely clear, indicating a higher top speed as the vehicle accelerates. This may be an anomaly in the physics engine.

Thirdly, the tractive green rolling resistance (the translation texts should be altered from "running" to "rolling" resistance) is hard to understand and is almost always so small a number that the graph is unintelligible next to the much larger tractive effort figure.

Fourthly, "tractive force" should be renamed "tractive effort" for consistency with other uses.

Finally, for appearance, it would be preferable if the usually hidden refunds button could be moved to the right of the two always on acceleration/tractive effort buttons so as not to leave a gap in normal circumstances. This is a minor enough issue, however, that it can be left if the workload for this would be excessive.

Incidentally, do I recall correctly that you reported a bug relating to the refunds graph not appearing? If so, I should be grateful if you could start a separate thread for that with a reproduction case, or else I will never remember to try to fix it.

Thank you again for all your work on this: this is much appreciated, and apologies again for the delay in testing this.

[Sirius]

Thirdly, the tractive green rolling resistance (the translation texts should be altered from "running" to "rolling" resistance) is hard to understand and is almost always so small a number that the graph is unintelligible next to the much larger tractive effort figure.

The also quite common alternative to this would be subtracting the rolling resistance from the force, but to be honest I prefer the two different curves. This will clearly show when a quite fast vehicle is mostly restricted by air resistance rather than tractive force decrease.
In the end this may not be as important to at least most vehicles as I am not aware of any simuvehicle that has a streamlined version as an upgrade. However, maybe there are some.

[Ranran(Hibernating)]

Thank you for testing despite being busy.

First of all, the acceleration curve seems to be capped at the current way's speed limit, so, for aircraft on a taxiway, for instance, it gives acceleration only up to 32km/h: one has to wait until an aircraft is flying before one can see real acceleration. The same would presumably apply to a train in a depot with a low speed track.

This code was written by Bernd, but from my point of view, I think that current convoy is running in virtual space by calc_move() and getting the calculation result.
This includes the current status of convoy, ie the weight of the load, the friction it receives and the speed limits due to constraints(signal and ways etc.).
I think current loading weight of convoy is an item that needs to be considered. On the other hand, I don't think the effects of slope and speed limit of way and signal are necessary.
I suppose adding a process to eliminate them but include loading weight may be a more task.
During the calculation of calc_move(), I couldn't find out if the restriction of the trajectory (way and signal) had an effect. Perhaps it is necessary to change the value of convoy's adverse.speed, but I am afraid that doing this requires more knowledge and work.

Perhaps an easier solution would be to create a virtual empty convoy and display a graph of theoretical values together.

Secondly, the curve seems to change over time for reasons that are not entirely clear, indicating a higher top speed as the vehicle accelerates. This may be an anomaly in the physics engine.

I think it is influenced by slope.

Thirdly, the tractive green rolling resistance (the translation texts should be altered from "running" to "rolling" resistance) is hard to understand and is almost always so small a number that the graph is unintelligible next to the much larger tractive effort figure.

The green chart is the sum of rolling resistance and air resistance. Therefore, I translated the Japanese word "走行抵抗" directly and explained it as running resistance.
This may not be correct as an English expression, in which case it needs to be corrected to the appropriate word.

Fourthly, "tractive force" should be renamed "tractive effort" for consistency with other uses.

Finally, for appearance, it would be preferable if the usually hidden refunds button could be moved to the right of the two always on acceleration/tractive effort buttons so as not to leave a gap in normal circumstances.

I'll do it. EDIT: This implementation is complete.

Incidentally, do I recall correctly that you reported a bug relating to the refunds graph not appearing? If so, I should be grateful if you could start a separate thread for that with a reproduction case, or else I will never remember to try to fix it.

Please split reply # 51 into a new thread. The Refunds button is hidden when there is no recording, but currently it does not seem to be recording properly.Therefore, it seems that refunds button is always hidden.
EDIT: The Refunds button was intended to appear only on convoys that do not belong to the line. I overlooked that fact.
On the other hand, if it belongs to the line, are there no refunds for lines? There is no refunds record in the line management window too.

I prefer the two different curves.

I agree. Although some examples picture are shown above, vehicles above 100 km/h can see some effect of air resistance, and even if the value is close to 0, the player can know the fact that its effect is not concerned about.

[Matthew]

Matthew - Thank you for the report. Perhaps those files are useless for the cause of the crash in this case, but the information that it does not crash on other versions was a hint. So I came up with one of the possibilities and made a fix for it.
Well I guess it was caused by my lack of knowledge - my apology.

No apology is needed! You have made a patch and have been very helpful in helping me to use it. Thank you!

I suppose Bernd's acceleration chart code was originally coded to not be used under certain circumstances. So I've changed the code that would have to be skipped if it wasn't supported. (I removed it because I wanted to see the buried chart.  ) So I fixed it.
If it's fixed correctly, you won't be able to use this chart instead of causing the crash in your build.

I can see that you have used ifdef to try to avoid the problem. This is a very good idea. Unfortunately, the problem remains. When I open the convoy window, I get a crash. However, I now get a debug message in the terminal: 

Build #f33ad74 (today's dig-acceleration-curve-chart branch)

Code Select Expand

Debug: convoi::dump():
vehicle_count = 4
wait_lock = 0
owner_n = 0
akt_speed = 153
sp_soll = 1704
state = 6
statename = DRIVING
alte_direction = 0
jahresgewinn = 0
name = '(1) Friesian horses (pair)'
line_id = '0'
schedule = '0x5572b4b89920'
Segmentation fault (core dumped)

Not very helpful.  But that enabled me to find this in an old crash log:

Build #3919923 (dig-acceleration-curve-chart branch on 19 January in debug version)

Code Select Expand

Debug: convoi::dump():
vehicle_count = 2
wait_lock = 0
owner_n = 0
akt_speed = 153
sp_soll = 114
state = 6
statename = DRIVING
alte_direction = 0
jahresgewinn = 0
name = '(1) Friesian horses (pair)'
line_id = '0'
schedule = '0x55612655fcd0'
Message: gui_textarea_t::recalc_size(): reset size to 11,0
Message: event: 0,-16

This might not be related to the crash (it was not the last message in the log). But it is maybe related. Unfortunately, gui_textarea_t::recalc_size() is deep inside the GUI code. There seem to be many calls between this method and your (Ranran's) patch. I think the next step is for me to carefully trace how this method is called in the patch. I think this is too difficult for me now because I am still learning C++. Maybe I will come back to this when I have more knowledge. But I should try some easier problems first.

I don't know what OS, compiler, lack of libraries, what makes it unavailable on your computer because I am not familiar with it. I would be grateful if anyone could give advice on this matter.

I have now had a chance to test this. I have not noticed any crashes when using this.

On this point: Ranran and James, are you both using Visual Studio Community on Windows to build this branch? And are you compiling #f33ad74, please? Maybe I am just making a silly mistake like building the wrong patch!

Thirdly, the tractive green rolling resistance (the translation texts should be altered from "running" to "rolling" resistance) is hard to understand and is almost always so small a number that the graph is unintelligible next to the much larger tractive effort figure.

Fourthly, "tractive force" should be renamed "tractive effort" for consistency with other uses.

Ranran already started a thread about proof-reading. Shall we continue that discussion there?

Thank you again for all your work on this: this is much appreciated

It is appreciated here too. I hope my problems don't distract you both from incorporating the patch into James' 'official' build.

Matthew: Try download this to your computer where you run your game.

Thank you for your suggestion, Qayyum! As you said earlier, this feature would be a good way to determine how many wagons we can use.

[Ranran(Hibernating)]

I found a interesting thread when Bernd Gabriel implemented the acceleration curve chart 
https://forum.simutrans.com/index.php/topic,3657.msg35510.html#msg35510

[Ranran(Hibernating)]

I may have fixed the cause of the crash on linux, so it would be helpful if you could check.

Also added a waytoll graph. It is important to note that save data from previous dig-acceleration-curve-chart branch versions will not be available with this change.

EDIT:
I have adjusted chart button colors.


checklist
- Confirmation of switching operation of each chart display of cost / acceleration / tractive effort
- Whether to cause a crash when building on Linux
- Check changed chart color, finance dialog, convoy dialog, line management dialog
- Check the contents of the tooltip added to the chart button
- Whether the display of the theoretical acceleration value is correct

TODO:
- Add waytoll chart to line managemanet dialog? (This affects the layout of the line management window)

[Matthew]

I may have fixed the cause of the crash on linux, so it would be helpful if you could check.

Thank you for your work on this, Ranran.

Unfortunately, I still get a crash at the same point : opening the convoy window, on a new map with Pak128.Britain-Ex. Here is the backtrace information from GDB:

Code Select Expand

Debug: convoi::dump():
vehicle_count = 3
wait_lock = 0
owner_n = 0
akt_speed = 153
sp_soll = 3661
state = 6
statename = DRIVING
alte_direction = 4
jahresgewinn = 0
name = '(1) Hackney horses (pair)'
line_id = '0'
schedule = '0x5555561e4810'

Thread 1 "simutrans-exten" received signal SIGSEGV, Segmentation fault.
0x00005555556a3398 in button_t::init(button_t::type, char const*, scr_coord, scr_size) ()
(gdb) backtrace
#0  0x00005555556a3398 in button_t::init(button_t::type, char const*, scr_coord, scr_size) ()
#1  0x00005555556cfa95 in convoi_info_t::convoi_info_t(quickstone_tpl<convoi_t>) ()
#2  0x0000555555870df6 in convoi_t::show_info() ()
#3  0x00005555558f3a73 in tool_query_t::work(player_t*, koord3d) ()
#4  0x0000555555932693 in karte_t::call_work(tool_t*, player_t*, koord3d, bool&) ()
#5  0x00005555558c4457 in interaction_t::interactive_event(event_t const&) ()
#6  0x00005555558c4561 in interaction_t::process_event(event_t&) ()
#7  0x00005555558c4c1b in interaction_t::check_events() ()
#8  0x000055555594de54 in karte_t::interactive(unsigned int) ()
#9  0x00005555558d3864 in simu_main(int, char**) ()
#10 0x00005555558e93f2 in sysmain(int, char**) ()
#11 0x00007ffff6748b97 in __libc_start_main (main=0x5555555aaab0 <main>,
    argc=5, argv=0x7fffffffdfd8, init=<optimised out>, fini=<optimised out>,
    rtld_fini=<optimised out>, stack_end=0x7fffffffdfc8)
    at ../csu/libc-start.c:310
#12 0x00005555555aab1a in _start ()

Unfortunately, it seems to be a problem with buttons, your old enemy from the station window. 

[Ranran(Hibernating)]

Matthew - Thank you for testing and sorry for wasting your time.
I suppose I have identified the cause and fix. Check it out when you have time and it will help.