The International Simutrans Forum

 

Author Topic: Viewing curve speed limits and calculating acceleration time/distance  (Read 3730 times)

0 Members and 1 Guest are viewing this topic.

Offline Matthew

  • *
  • Posts: 353
    • Japan Railway Journal
  • Languages: EN, some ZH, DE & SQ
Re: Viewing curve speed limits and calculating acceleration time/distance
« Reply #70 on: January 30, 2020, 11:15:30 PM »
Matthew - Thank you for testing and sorry for wasting your time.

You are only wasting my time because you are increasing that chance that I enjoy Simutrans more and play more! Is playing Simutrans wasting time??? Actually, I am worried that I am wasting your time, because it's very possible that these crashes are caused by a mistake on my part. I am still new. Maybe I am doing something wrong.

Quote
I suppose I have identified the cause and fix. Check it out when you have time and it will help.

Thank you for trying again. That fix does not seem to have been successful, but we have some more data. Running a build including #c955a9f04, I still get a crash at the same point. Here is the simu.log:

Code: [Select]
Debug: interaction_t::process_event: calling interactive_event
Message: interaction_t::interactive_event(event_t &ev): calling a tool
Message: tool_query_t(): checking map square 156,17,0
Message: tool_query_t(): index 2
Debug: convoi::dump():
vehicle_count = 3
wait_lock = 0
owner_n = 0
akt_speed = 153
sp_soll = 1072
state = 6
statename = DRIVING
alte_direction = 2
jahresgewinn = 0
name = '(1) Hackney horses (pair)'
line_id = '0'
schedule = '0x555570eb4400'
Message: gui_textarea_t::recalc_size(): reset size to 11,0

And the GDB backtrace:

Code: [Select]
Message: gui_textarea_t::recalc_size(): reset size to 11,0

Thread 1 "simutrans-exten" received signal SIGSEGV, Segmentation fault.
0x00005555556bd2b3 in button_t::set_typ (this=0x5555579fbe38, t=button_t::box_state) at gui/components/gui_button.cc:127
127 set_size( scr_size(gui_theme_t::gui_button_size.w, max(D_BUTTON_HEIGHT,LINESPACE)) );
(gdb) backtrace
#0  0x00005555556bd2b3 in button_t::set_typ (this=0x5555579fbe38, t=button_t::box_state) at gui/components/gui_button.cc:127
#1  0x00005555556bcf5e in button_t::init (this=0x5555579fbe38, type_par=button_t::box_state,
    text_par=0x555555a2c720 "Sends the convoi to the last depot it departed from!", pos_par=..., size_par=...)
    at gui/components/gui_button.cc:74
#2  0x00005555556e79b5 in convoi_info_t::convoi_info_t(quickstone_tpl<convoi_t>) ()
#3  0x00005555558bb4c6 in convoi_t::show_info() ()
#4  0x00005555559c5a41 in vehicle_t::show_info (this=0x5555a5463220) at vehicle/simvehicle.cc:2962
#5  0x000055555593d436 in tool_query_t::work (this=0x55555793eea0, player=0x555598aaafc0, pos=...) at simtool.cc:384
#6  0x000055555599668a in karte_t::call_work (this=0x55555a38a580, tool=0x55555793eea0, player=0x555598aaafc0, pos=...,
    suspended=@0x7fffffffb27a: false) at simworld.cc:10155
#7  0x0000555555918785 in interaction_t::interactive_event (this=0x55557fc5bf40, ev=...) at siminteraction.cc:240
#8  0x000055555591918a in interaction_t::process_event (this=0x55557fc5bf40, ev=...) at siminteraction.cc:417
#9  0x00005555559192b1 in interaction_t::check_events (this=0x55557fc5bf40) at siminteraction.cc:439
#10 0x0000555555997eab in karte_t::interactive (this=0x55555a38a580, quit_month=2147483647) at simworld.cc:10464
#11 0x0000555555926d88 in simu_main (argc=5, argv=0x7fffffffdfd8) at simmain.cc:1382
#12 0x000055555593aebc in sysmain (argc=5, argv=0x7fffffffdfd8) at simsys.cc:825
#13 0x0000555555a14f32 in main (argc=5, argv=0x7fffffffdfd8) at simsys_s2.cc:792

Earlier, I ran the debug build of the previous version (not including #c955a9f04) in GDB. It is more successful. I can open the convoy window!  :) I can also see the lovely new acceleration chart. However, I get a crash when I open the tractive effort chart. The terminal report is this:

Code: [Select]
Debug: main_view_t::display: starting ...
Debug: main_view_t::display: display pointer
*** stack smashing detected ***: <unknown> terminated

Thread 1 "simutrans-exten" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

Here is the backtrace for another crash with that debug build:

Code: [Select]
Message: interaction_t::interactive_event(event_t &ev): calling a tool
Message: tool_query_t(): checking map square 79,173,0
Message: tool_query_t(): index 3
Message: gui_textarea_t::recalc_size(): reset size to 11,0
Message: event: 0,-16
Message: gui_textarea_t::recalc_size(): reset size to 146,11
*** stack smashing detected ***: <unknown> terminated

Thread 1 "simutrans-exten" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) backtrace
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007ffff6767801 in __GI_abort () at abort.c:79
#2  0x00007ffff67b0897 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff68dd988 "*** %s ***: %s terminated\n")
    at ../sysdeps/posix/libc_fatal.c:181
#3  0x00007ffff685bcd1 in __GI___fortify_fail_abort (need_backtrace=need_backtrace@entry=false,
    msg=msg@entry=0x7ffff68dd966 "stack smashing detected") at fortify_fail.c:33
#4  0x00007ffff685bc92 in __stack_chk_fail () at stack_chk_fail.c:29
#5  0x00005555559b98df in number_to_string (p=0x7fffffffacf6 "", f=0, decimals=180) at utils/simstring.cc:208
#6  0x3030303030303030 in ?? ()
#7  0x3030303030303030 in ?? ()
#8  0x3030303030303030 in ?? ()
#9  0x0000303030303030 in ?? ()
#10 0x0000000100426284 in ?? ()
#11 0x0235023b0243e500 in ?? ()
#12 0x40f4e5e15569000e in ?? ()
#13 0xffffffff0000023b in ?? ()
#14 0xffffffff00000019 in ?? ()
#15 0x0000025000000000 in ?? ()
#16 0x0000004e00000000 in ?? ()
#17 0x0000000000000064 in ?? ()
#18 0x00005555a4a1a308 in ?? ()
#19 0x0000000000000000 in ?? ()

Hopefully I will be able to test the debug build of the new commit at the weekend.

Offline Ranran

  • Devotee
  • *
  • Posts: 1077
  • Languages: ja
Re: Viewing curve speed limits and calculating acceleration time/distance
« Reply #71 on: January 31, 2020, 11:33:30 AM »
Matthew - Thank you for testing. The part related to the button appears to have a problem, but currently has no idea...



I have added a theoretical high to the acceleration chart. This represents an acceleration graph with no load and unaffected by speed limits and slopes.




I changed the "Access charges" chart button to violet because orange has some of duplication.

In the finance dialogue, the expression "Access charges" is used. Is the expression "Access charge" correct in the convoy info dialog?
As you can see in the image above, "Access charges" is caught by the character limit, but I think "Access charge" will fit.

Finance originally modified Road toll with translation files. Does it change "Way toll" to "Access charge" via tab file in that case?

Offline Freahk

  • Devotee
  • *
  • Posts: 1172
  • Languages: DE, EN
Re: Viewing curve speed limits and calculating acceleration time/distance
« Reply #72 on: January 31, 2020, 12:29:21 PM »
I have added a theoretical high to the acceleration chart. This represents an acceleration graph with no load and unaffected by speed limits and slopes.
That's awesome, however imho the theoretical max load acceleration rather than min load is the most important figure for comparisation.

I changed the "Access charges" chart button to violet because orange has some of duplication.
Maybe we should use the same color for any stat of the same "type", i.e. ones that can technically be displayed at the same time and where it makes sense to do so.
I guess the same principle is currently already used for the minimap options.

In this case it would be some thing like (discussable):
Total Capacity, Transported
Average Speed
Comfort
Revenue, Running Costs, Profit, Access charges
Distance
Acceleration
Tractive Effort

Offline Ranran

  • Devotee
  • *
  • Posts: 1077
  • Languages: ja
Re: Viewing curve speed limits and calculating acceleration time/distance
« Reply #73 on: January 31, 2020, 12:58:00 PM »
however imho the theoretical max load acceleration rather than min load is the most important figure for comparisation.
I agree, it's make sense. I would change that way.

In this case it would be some thing like (discussable):
Total Capacity, Transported
Average Speed
Comfort
Revenue, Running Costs, Profit, Access charges
Distance
Acceleration
Tractive Effort
I changed the color of some charts in this way when I changed the station chart. However, multiple charts are complicatedly involved, and it is troublesome to avoid conflicts. This time, I think the same can be said for convoy and finance. The finance window has many red-based colors. Which color do you think you should change?

Offline Freahk

  • Devotee
  • *
  • Posts: 1172
  • Languages: DE, EN
Re: Viewing curve speed limits and calculating acceleration time/distance
« Reply #74 on: January 31, 2020, 01:20:59 PM »
Indeed the color is important to the graph in a different way than it is to the minimap, so we may want to set a border color to any selected button that has the same color as the curve in the graph, whilst the main color of the buttons is the same for any button of the same group of compatible informations.

e.g. main colors
Total Capacity, Transported: Orange
Revenue, Running Costs, Profit, Access charges: Blue
Average Speed, Comfort, Distance, Acceleration, Tractive Effort: unique colors or all grey

Borders (on selection):
Revenue: Green
Running Costs: Red
Profit: Blue
Access charges: Orange

Any other border color can remain the same as the main color as it's unique anyways.

In any event, Buttons should be properly ordered by their type of information, so we should swap the position of "Distance" and "Access charges" and move the "average speed" closer to "Acceleration" and "Tractive effort", as these three are whilst technically incompatible still more or less related.

So I would suggest the following order:
Revenue, Running Costs, Profit, Access charges,
Total Capacity, Transported, Distance, Comfort,
Acceleration, Tractive Effort, Average Speed

I know the number of buttons per line is size dependant but I guess allignung the same type of information to the same line in default window scale is not a bad thing.
« Last Edit: January 31, 2020, 01:32:01 PM by Freahk »

Offline Ranran

  • Devotee
  • *
  • Posts: 1077
  • Languages: ja
Re: Viewing curve speed limits and calculating acceleration time/distance
« Reply #75 on: January 31, 2020, 01:37:53 PM »
I agree that similar kind information should be adjacent and more important information should be placed ahead. I was thinking a little about it.

Basically, the button layout code is from standard, which is arranged in numerical order of the record. To change this,
(1) Specify and place each one
(2) Create and assign an array that registered the location of each button
(3) Replace data when reading from old save depending on save version

Perhaps (2) is wise?

About color uniformity,
Does it make sense to swap the colors of "Cash flow" and "Operating profit" in the Finance window?
That is, match the color of "profit" in the convoy info dialog.

Offline Freahk

  • Devotee
  • *
  • Posts: 1172
  • Languages: DE, EN
Re: Viewing curve speed limits and calculating acceleration time/distance
« Reply #76 on: January 31, 2020, 01:52:30 PM »
Perhaps (2) is wise?
A mapping is quite straight forward, simple, efficient and does not break compatibility, so i guess yes, that is wise.

About color uniformity,
Does it make sense to swap the colors of "Cash flow" and "Operating profit" in the Finance window?
That is, match the color of "profit" in the convoy info dialog.
Absolutely! The same type of data should have the same color in any aspect where it is listed, thus e.g. Operating Profit should have the same color in vehicle window, line window and finance window (and any further if I forgot one)
« Last Edit: January 31, 2020, 02:19:18 PM by Freahk »

Offline Ranran

  • Devotee
  • *
  • Posts: 1077
  • Languages: ja
[patch] Revival of Physics curve chart
« Reply #77 on: July 27, 2020, 10:42:28 AM »
I wondered if some work would be needed for this repair work, but it was completed soon. So finally I post it. (Pull request #223)
This patch was frozen because I was unable to address a crashing issue on linux last time.
But then, with the clue as to the problem caused by another patch, it turned out that it was most likely caused by the tooltip character limit.
I just fixed it and resolved the conflict with the master branch. (Please note that those tooltips were added by this patch and were not originally there. And I recommend that you revise the help text to explain this to players.)
I would appreciate if someone could check this on linux to see if it caused a crash.
Adieu (´・ω・`)

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19970
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Viewing curve speed limits and calculating acceleration time/distance
« Reply #78 on: July 29, 2020, 01:51:13 PM »
Thank you for this.

I have now had an opportunity to test this a little further. I notice one anomaly at this stage: I am not sure how easy that it is to fix. This relates to the tractive effort graph: both numbers (the tractive effort and rolling resistance) seem to reduce to zero when the vehicle reaches its maximum speed. However, the x axis on the graph is not truncated to this point, but shows a large amount of useless data to the right of this point. One particularly bad example is convoy no. 22 on demo.sve, where about a quarter of the graph is occupied with zero data. Ideally, the graph would end at the highest speed attainable and before the values drop to zero. In the current state, it is very difficult to read the resistance graph, since the value on the right hand side is always given as zero, so that the only way to read any values on the graph is to mouse-over them.

Also, I notice that there are no tooltips for the buttons in the convoy window, but this is equally the case in the current master branch. Had it been intended to implement these?

Thank you again for your work on this.

Offline Ranran

  • Devotee
  • *
  • Posts: 1077
  • Languages: ja
Re: Viewing curve speed limits and calculating acceleration time/distance
« Reply #79 on: August 02, 2020, 02:58:06 PM »
Quote
I am not sure how easy that it is to fix.
I'm worried that the code for it creates some complexity, as it hacks and displays an existing chart code.

Quote
Ideally, the graph would end at the highest speed attainable and before the values drop to zero.
I made that change.

Quote
Also, I notice that there are no tooltips for the buttons in the convoy window, but this is equally the case in the current master branch. Had it been intended to implement these?
Yes, I tried to add it while I was making this patch before. But I made the array size too small. I think that was the cause of the crash on Linux.
I didn't add it this time because it didn't originally exist. If it doesn't crash in Linux, it's clear that it was the cause.

Offline Freahk

  • Devotee
  • *
  • Posts: 1172
  • Languages: DE, EN
Re: Viewing curve speed limits and calculating acceleration time/distance
« Reply #80 on: August 02, 2020, 03:25:37 PM »
I think that was the cause of the crash on Linux.
lalala std::array is nice, we all should like the stdlib.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19970
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Viewing curve speed limits and calculating acceleration time/distance
« Reply #81 on: August 02, 2020, 07:40:22 PM »
lalala std::array is nice, we all should like the stdlib.

The problem with the std collection classes is that they are often slower than the Simutrans equivalents (this is definitely true of the hashtable), and this can make a big difference to performance whenever they are used in performance critical parts of the code.

The Simutrans vector_tpl is sufficient for most cases where an array is needed.

Offline Freahk

  • Devotee
  • *
  • Posts: 1172
  • Languages: DE, EN
Re: Viewing curve speed limits and calculating acceleration time/distance
« Reply #82 on: August 03, 2020, 09:20:45 AM »
This is definitely not true for std::array. It is equally fast as plain C arrays, though the operator[] doesn't do boundary checks by default for performance reasons.
It can however be compiled to do these checks, which plain arrays (e.g. something like int[256]) cannot do on its own.

Whenevever an array is needed, you don't want to use vector_tpl, as it's not an array but a vector.
The standard equivalent to vector_tpl is simply called std::vector and it's pretty fast either. I would not expect any performance penalty compared to vector_tpl here either.

About std::map, it's still much more complicated here. In the first place, std::map is not the equivalent of hashtable_tpl, because std::map is ordered, hashtable_tpl is not (within a single bucket it is, but generally it's not.)
The actual equivalent is std::unordered_map, which is usually roughly 3-times faster than std::map, though it cannot be said that generally either.
On top of this, you definitely can not even generally say "simutrans implementation is definitely faster than the standard one"

Hashtables are always a tradeoff in between memory consumption and performance.
Simutrans implementation makes use of a fixed size of 101 buckets, which semselves are linked lists.
So with a small number of elements, you will most likely never iterate any of these lists. The has will tell you in which bucket you can find the data and the data will most often be the very first element of the list.
Though, even if there is only a single element stored in the hashtable, there will be 101 lists, of which 100 are empty and one contains exactly on element. This waste of memory is obviously very fast when it comes to any kind of operation.

On the other hand, if you insert 101 million elments into a single simutrans hashtable, there will be on average 1 million elements per list, so your performance will be simmilar to accessing from or inserting to a 1 million element long linked list.
Even std::map will be much faster here, not to mention std::unordered_map will be even faster.
« Last Edit: August 03, 2020, 10:12:44 AM by Freahk »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19970
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Viewing curve speed limits and calculating acceleration time/distance
« Reply #83 on: August 03, 2020, 11:23:41 AM »
That is interesting, although I should note that my performance comparisons were with std::unordered_map, not std::map.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19970
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Viewing curve speed limits and calculating acceleration time/distance
« Reply #84 on: August 03, 2020, 05:26:41 PM »
Ranran - thank you for this. I have now had a chance to test the latest version. What I notice is that the graph is truncated but that the scale of the chart is not updated to match that truncation such that there is still a considerable amount of wasted space on the right of the chart. Would updating the scale of the chart dynamically so that the truncated lines end up on the far right of the chart no matter where the truncation takes place be challenging or is it something that can readily be achieved?

Thank you again for your work on this.

Offline Freahk

  • Devotee
  • *
  • Posts: 1172
  • Languages: DE, EN
Re: Viewing curve speed limits and calculating acceleration time/distance
« Reply #85 on: August 03, 2020, 06:46:54 PM »
I don't know. This was suggested before, but Ranran said it would be very difficult.
I assume the idea behind this was to have fixed speed steps in between two data points but a variable number of data points. I have no idea of the involved graphics code, so I can't say anything about this nor work out an idea to solve this.

The other way round might be easier. Have a fixed number of data points but variable speed steps in between these.
You could simply get the maximum speed and display data of every vMax/datapoints increment of speed.

I am quite sure I have seen something like this before in one of the graphs you presented.
Why was this replaced by the current figure with a lot of empty space?
If it was because of odd speed steps, like 225/24=9.375 km/h, this could be solved by rounding these steps up in 5 km/h steps or something, so at least there will be less wasted space.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19970
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
I notice that Ranran has pushed some changes that appear to be making progress towards truncating the graphs, but the trunction seems to be off by one so far. I shall be interested to learn of progress in relation to this.

Offline Ranran

  • Devotee
  • *
  • Posts: 1077
  • Languages: ja
Label must be an integer. Otherwise it will be difficult to set the x-axis label and see the graph. So I set the proper axis and then quit the process.

As already mentioned, it hacks and displays existing systems like an overtaking patch, so it inserts a lot of code to resolve inconsistencies in order to be consistent with existing systems. I'm afraid that this will compromise readability and maintainability.
For example, it doesn't depend on this graph orientation option.
extended has a different orientation than standard from the default orientation of the graph.
So this means the graph of maximum speed on the left. It is the exact opposite of a general f-v/v-t graph.
If this is cut off in the middle, the label value and position and the drawing position of the graph must be adjusted.
If you want to fix this in the future, you need to be careful if the left_to_right_graphs option is changed and it still works.
That way many cat and mouse games are executed.
Quote
I notice that Ranran has pushed some changes
Anyway i implemented it. I apologize for the late report.

And unfortunate news. I made a mistake in the judgment formula that aborting the chart display last time. That is, the chart was aborted one step before the actual display.

Quote
the trunction seems to be off by one so far.
Therefore, it is a correct specification that the chart should be 0 at the end. This is because the acceleration force of a vehicle with a maximum speed of 120 km/h returns 0 when the maximum speed is 120 km/h. That is the current physics code. If not, it will accelerate to 121 km/h.

EDIT:
There is currently a bug with incorrect x-axis labels. (One shift)
« Last Edit: Yesterday at 03:44:58 PM by Ranran »

Offline freddyhayward

  • Devotee
  • *
  • Posts: 286
  • Languages: EN
This branch still crashes on linux due to the use of char *.