News:

Do you need help?
Simutrans Wiki Manual can help you to play and extend Simutrans. In 9 languages.

Station-to-station journey time measurement feature of lines

Started by suitougreentea, November 17, 2017, 01:32:24 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

suitougreentea

Hello,

I've made an additional feature which I think is good to be included in Simutrans Extended.
This adds [Measure Time] button in Line Management window. When clicked, a new window opens and here you can measure and view station-to-station traveling time. It is very much useful in collecting timing data, which is essential in creating some complex timetables. I've attached a screenshot of how it is working.

The source code is uploaded at my line-time-measurement branch. You can browse from https://github.com/suitougreentea/simutrans-extended/tree/line-time-measurement .
I am new to C++, let alone modifying Simutrans code, so there may be some bugs, memory leaks, illegal code styles, and more. If you find any, please report.

Additionally, I'm also developing a timetable creation helper tool for Extended, which is still under development.
The screenshot is here: https://twitter.com/suitougreentea/status/931075058864340992
I will post a new topic about it when it is ready.

Thanks,

Jando

That sounds fantastic if I understand you right.

I often want to know the travel time between two end stations for example (including loading times), but without any waiting time taken into account like the service frequency does. That sort of information is very useful indeed. many thanks!

jamespetts

Thank you very much for that - it is always appreciated when people work on coding for Simutrans-Extended.

I have now had a chance to undertake a little testing, and have created a branch (line-time-measurement) on my own Github with this code. On that branch, I have fixed one bug that occurred when the convoy had a waypoint on it. I have tested for memory leaks, but cannot detect any.

One or two queries and issues at this stage. Firstly, the start/stop button and also the buttons to move the screen to the stations in question appear only to work when double-clicked (at least in Windows). This will need to be changed to allow single-click usage to be consistent with elsewhere.

Secondly, may I ask why it is necessary for the player to start measuring (and presumably for new measurements to be created when this is done), rather than for the existing point to point timings used for the passenger/goods routing being used?

Finally, you will need to add a .dat file with any new translation texts in the standard Simutranslator format so that this can be uploaded to Simutranslator to allow translations of the new texts to other languages.

Aside from these things, however, this seems as though it may be of great benefit to players. Thank you very much for coding this.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

suitougreentea

Thank you all for the reply. Also thank you very much for testing, jamespetts.

For Jando:
In fact I have not investigated much about in-game measurement logic which I used (especially about exactly when measurement starts and ends). So I don't know yet about whether it includes loading time, but probably not (at least time of adjoining stations).


For jamespetts:
First, the problem that buttons needs double-click or more might come from the issue that they don't handle clicks just when redraw occurs and re-registered some buttons in the window, but I have no idea how to solve it....

Second, I made new variables for the measurement because it takes time for measured journey time to converge if any of the features of the line is refreshed (such as modifying routes, changing convoys used, ... whatever affects journey time). Previously I thought of implementing reset button of average_journey_time, but I didn't decide to do it because it is used in pathfinding (in path_explorer.cc).

Last, yes, some translation stuff is needed. I will try.

jamespetts

Thank you for your reply. I do not think that the issue with respect to the mouse click responsiveness is confined to just redrawing the window, since it also affects clicking on the buttons that should move the viewport to the location of the station in question. I am afraid that I am not familiar enough with the GUI code to be able to know what might cause this, so you will have to do some investigation (and perhaps comparison with other GUI elements to see how things are done differently there to avoid this problem).

I am not sure that I fully understand your answer relating to re-measuring journey times: my apologies. It will always take time for measured journey times to be updated when a route feature changes, as the actual measurement takes time; but what I do not understand is why measuring separately just for the line time measurement feature takes less time than the existing journey time measurements used in routing. Was there a reason that you thought that a separate system for re-measuring these times for this GUI feature only would take less time to update than using the existing means of recording point to point journey times?

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

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

Follow Simutrans-Extended on Facebook.

Ves

Wow this looks like an amazing addition! Thank you for developing it! :)

nuhgl

This looks awesome!

Thanks for developing this.
Your diagram planning tool seems also very useful!

I always had a problem running quite busy single track operation.
But with these tool, I could have precise planned timetable for such an operation.

Edit: I am having some issue to just run Diagram Viewer.


Should I set up some environment perhaps? like NET framework
Sorry for my limited knowledge for general computing.

jamespetts

Incidentally, a user's report of unexpected behaviour here is a good illustration of one of the potential uses of this feature; and it is also a good illustration of the benefits of using the existing point to point timings, as only then will it be possible for the player to be sure that the times shown are the ones actually used for routing.
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.

suitougreentea

Thank you all for replying and I'm sorry that I am late for responding your comments.

For nuhgl:
Thanks for trying the software! To launch the app, drop a .simtt file (an example file is included in the archive) to .exe . Hope that helps.

For jamespetts:
Thanks for replying. As for GUI, I will investigate on that, but it may take time, since I have much to do outside of working on this patch. It is so much appreciated if someone find the cause earlier.

As for re-measuring, the following hopefully instantiates my intention:
Let's assume that currently the entry of average_journey_time is [10:00], and now time is improved to 8:00.
With current implementation, start measuring (with empty average_journey_time_for_measurement) and soon journey time indicates 8:00.
If I use existing timings, first the entry become [10:00, 8:00] (=> average 9:00), [10:00, 8:00, 8:00] => 8:40, ..., taking long time for average to converge into 8:00, and it is difficult to know real improved journey time.
I apologize for my bad writing in English; I am not so good at. I hope this makes sense.

jamespetts

Thank you for that explanation - the intention does make more sense now. I wonder whether there might be some benefit to giving players the option to show either the current average times or the latest measured times? Because the current average times are used in routing, this might be very useful for diagnosing problems of the sort to which I linked above.
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.

suitougreentea

I agree. Giving an option would be so useful.
I am going to work on reviewing data structure and some translation/GUI stuff.

jamespetts

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.

AP

It sounds like a really useful feature, but I have a few questions about how it works (which may influence how players use it):

Does the time measurement feature rely on trains having already traversed the line? That is, is it an average of actual timings, or is it a theoretical simulation based on what the vehicles assigned to the line would achieve (mindful of curves and gradients etc).

If it's a theoretical timing, it can be used presumably when doing the initial set up of the line. If not its more about "tweaking" so youd have to allow for "test running" each line.

If it's an average, over what period is the average taken?

What happens if you have mixed speed trains assigned to the same line?  (presumably this becomes rather inadvisable...) Is it reporting the median timing, or the mean?

How does it handle some trains on a line being full and heavy, others empty and light, on the same line?  For example if the traffic is all in one direction and the trains travel back empty. Or for that matter, routes which have an altitude difference. In both cases, the timings will be different in each direction.

Will it give timings to "waypoints" where the train doesn't actually stop?  So e.g. by setting them at regular intervals along the route, one can find out where to put passing loops on a single line? Because that present that task is particularly onerous (unless the line is dead straight).



Vladki

Hello all, I have a few suggestions and questions. I hope I will not derail this topic too much, but it seems to be related.

First is about scheduling convoys. When I have more convoys on one line (passenger), and they start to bunch up, I look at the line windows and check service frequency. Then I set the wait for time to the same value (or slightly longer to cope with some congestion).
Similar result can be achieved by using convoy's average trip time divided by number of convoys on the line. But, once I set the waiting times, these values will change, to include the waiting times. This makes it impossible to later adjust the waiting times, if convoys or ways are upgraded, and the interval can be shortened. So I would like to see in these two windows a "netto" round trip time, which is cleared of waiting for schedule (and waiting for load - see below).

A question - how many round trips / departures / months are averaged in the line frequency / convoy trip time? I just want to know, how long is this value affected by some random blockage (that may have been resolved manually).

Second thought is about cargo (or even passengers) routing. It can be seen on the "sandbox server". There are two supermarkets supplied by the same orchard, farm, grain mill, etc... Usually there is one truck for each connection - i.e. one truck taking flour from the mill to one shop and another truck to deliver to the other shop. Same for fruits and vegetables. Trucks are set to wait for 100% load. Sometimes (probably if the trucks get stuck somewhere, or the shop stops ordering goods for a while), the direct connection will have longer journey time then taking detour via the other shop and some other supplier (e.g. mill -> shop1 -> orchard -> shop2). Thus one of the trucks will wait forever, as the cargo for its destination will be loaded on the other truck. The journey time will never fix itself. One has to remove the requirement to load 100% and let the truck run empty for a while to fix the journey time.

I have seen similar funny routing also in the demo game, when I tried to add a new convoy (and line) to help with overcrowded stations. Cargo was bouncing there and back in funny ways. Something like this: A (load) - B - C - D (transfer) - C - B (unload). So I was thinking that the journey times used for path finding, should not include time when the convoy is waiting for load.

I'm not sure if this should be applied to passengers. One not really obvious thing is, that routing cargo/pax to a vehicle that is waiting for load will make it depart sooner...

So, what do you think about it? Is it something that could be added to your patch?

suitougreentea

Thank you for your all response and I apologize for late reply.

I still have no progress about this patch, but I came up with a better idea (at least for me).
How about storing 3 most recent journey times, in addition to whole average, in each entry of journey_times_map?
The plan no longer needs a variable only for measurement and they give a reasonable average measured more recently.
The interface will show 1 most recent time, average of 3 most recent times, and whole average time.

It needs the structure of journey_times_map to change (to something like koordhashtable_tpl<id_pair, average_time> where average_time is what I have to newly define), but by doing this I can show reasonable average "per convoy" journey times as well, which is good when a line has different class of convoys and journey time differs respectively.

How do you think about this idea, jamespetts?

Followings are answers to the questions raised.

QuoteDoes the time measurement feature rely on trains having already traversed the line? That is, is it an average of actual timings, or is it a theoretical simulation based on what the vehicles assigned to the line would achieve (mindful of curves and gradients etc).
It measures actual timings. A measured time is shown and accumulated as temporary data when a vehicle arrives at a station after start measurement.

QuoteIf it's an average, over what period is the average taken?
This needs more investigation, but so far it seems that the range is from departure to arrival.

QuoteWhat happens if you have mixed speed trains assigned to the same line?  (presumably this becomes rather inadvisable...) Is it reporting the median timing, or the mean?
Mean.

QuoteHow does it handle some trains on a line being full and heavy, others empty and light, on the same line?  For example if the traffic is all in one direction and the trains travel back empty. Or for that matter, routes which have an altitude difference. In both cases, the timings will be different in each direction.
Currently it simply calculates the average. But measured times of different directions (such as A->B and B->A) are stored as different data.

QuoteWill it give timings to "waypoints" where the train doesn't actually stop?  So e.g. by setting them at regular intervals along the route, one can find out where to put passing loops on a single line? Because that present that task is particularly onerous (unless the line is dead straight).
As far as I know (I am simply borrowing a measurement method originally in game used for routing), it does not give timings to waypoints. But currently waypoints are listed as well in GUI and this is what I have to fix.


QuoteSo I would like to see in these two windows a "netto" round trip time, which is cleared of waiting for schedule (and waiting for load - see below).
This seems good. It can be obtained from every station-to-station times and some additional loading/reversing time? I am not sure yet.

QuoteA question - how many round trips / departures / months are averaged in the line frequency / convoy trip time? I just want to know, how long is this value affected by some random blockage (that may have been resolved manually).
It seems it collects all data since line/convoy is created but it has a "reduce" system so that data is not stored infinitely. However I am not sure yet as well; needs investigation.

QuoteI'm not sure if this should be applied to passengers. One not really obvious thing is, that routing cargo/pax to a vehicle that is waiting for load will make it depart sooner...

So, what do you think about it? Is it something that could be added to your patch?
This seems to be out of my patch. It might be good to suggest it as a new thread.

jamespetts

Thank you for your thoughts. There would be benefit to a system that does not require measurement of times specifically for the UI feature, but we must be very careful not to make average_tpl (or whatever is used as the value of the koordhashtable) too large, as these journey time maps are used in the performance critical path explorer, so memory bandwidth is a real issue.

Currently, each average_tpl<uint32> can fit into 64 bits, having as it does only two 32-bit values (the total and the count). Storing the last three journey times plus the average would suggest the usage of another 96 bits (i.e., a further 3 32 bit integers), making for 160 bits in total for the values in this hashtable, and I worry how this might affect performance on extremely large maps (imagine a very heavily developed map with c. 750 cities running on an online server using a VPS). Although the path explorer is multi-threaded as of 2016, the multi-threading system used only allows the path explorer to run on one thread at a time (with other things running on the main thread), so there is a limit to how much that this system can scale.
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.

suitougreentea

I see. Certainly the plan would affect performance more or less.
With regard to the original aim of this patch, it is redundant to have times between stations not neighboring.
Is it a good idea that the game has separate data for measuring after all (but it only stores ones between neighboring stations)?
In my current plan each entry has history of 3 latest trips, so memory usage is (number of stations in schedule) * 96bit per line/convoy.
It immediately resets to empty when schedule has been changed.

jamespetts

Quote from: suitougreentea on November 27, 2017, 02:35:32 AM
I see. Certainly the plan would affect performance more or less. With regard to the original aim of this patch, it is redundant to have times between stations not neighboring. Is it a good idea that the game has separate data for measuring after all (but it only stores ones between neighboring stations)?
In my current plan each entry has history of 3 latest trips, so memory usage is (number of stations in schedule) * 96bit per line/convoy.
It immediately resets to empty when schedule has been changed.

Recording data for measuring purposes that are not used in the path explorer is likely to have a significantly lesser impact on performance than altering those times that are stored. You might store the last three trips in one place, and then use the existing average timings either separately or in combination for the display.
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.

suitougreentea

I updated line-time-measurement branch. Some note:


  • Removed average_journey_times_for_measurement and added journey_time_history for each convoy/line; GUI also changed (see screenshot attached)
  • journey_time_history now saved to savedata (EX_SAVE_MINOR changed)
  • departure_point_t moved to schedule.h and changed structure (I am not sure whether these works are both appropriate)
  • introduce times_history_data_t in schedule.h (concern is same as above, is it good to define in schedule.h?)
  • Work on translation still not yet started
  • For the problem that clicking button is sometimes not effective: It happens when the button is removed and re-registered during pressed (between clicking and releasing). I will change the code so that buttons are re-registered not very often.
  • Comments are not sufficient (especially GUI code)
  • In connection with this feature, I fixed bugs about convoy's time measurement (Currently I only fixed bugs of actual/estimated journey time; is there anything which should as well be replaced into increment_index_until_next_halt()? see https://github.com/suitougreentea/simutrans-extended/commit/f43266c6cae971a38ebb13e2d654294a523f2fa5)

jamespetts

Excellent, thank you very much for this. I am currently away from home and not able to review this, but I will look into this when I have a chance (it might be a few days, as I need to prioritise some bugs that have been reported by people playing on the server).

Thank you again.
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.

jamespetts

Thank you for your work on this. I am in the process of reviewing this now. I have merged this and pushed it to the journey-time-measurement-2 branch of my Github repository.

I had to change the saving/loading code as I had incremented the minor save version number for other purposes to 1 already, so this needed to be set to 2. Also, I had to amend the code to take account of the fact that the minor save number is reset to 0 whenever the major number is incremented, which requires checking that the version is either exactly 13 and with a revision of exactly or greater than 2, or the version is exactly or greater than 14. I should be grateful if you could bear this in mind when writing any future code.

I also notice that we have some new .cc files added, but they do not appear in the makefile: it is important that references to these files are added to the makefile, or else compilation using GCC and MinGW32 will fail. I should be grateful if you could add these to the makefile.

Further, I notice that there are some additional translation texts: these will need a .dat file in order to be added to Simutranslator to allow people to translate these new texts into various languages. On the topic of the text, I suspect that "unidirectional" would be a clearer opposite to "bidirectional" than "normal direction".

Additionally, I notice that you changed:


journey_times_history.access(this_departure)->set(latest_journey_time);


to


journey_times_history.access(this_departure)->put(latest_journey_time);


and similarly


line_history.access(this_departure)->set(latest_journey_time);


to


line_history.access(this_departure)->put(latest_journey_time);


May I ask what the intention of this change was?

One issue that I notice is that, when one is looking at another player's convoy, the timing history button is not greyed out, but clicking it has no effect. This ought to be greyed out, I think.

Onto some more positive points: the performance profiler shows that there is no noticeable performance impact from this patch, which is very good. Also, the feature seems to be very useful, and also very usable: this is definitely an improvement on the first attempt. I daresay that this will significantly enhance people's abilities to plan their networks - this is a very useful feature.

If you are able to fix the issues that I describe above, I shall be happy to incorporate this.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

suitougreentea

Thank you very much for reviewing. Unfortunately I don't have much time to update this now, but I hope I can start working on it within 2 weeks.

I renamed the unary function set() to put() when I added a binary function which requires index as well as time, used by rdwr().
Now set(index, time) simply sets history[index] to time, put(time) sets history[0] to time and shifts all following values. I think these namings are more appropriate than before.

Besides this, I agree with you on all other things you pointed out. I will fix them when I have time.

jamespetts

Excellent, thank you. Do let me know when you have updated your code.
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.

nuhgl




journey-time-measurement-2 branches and
SimuDia of suitougreentea working fine! :)


Again Thanks very much for this feature and SimuDia app.
Now I could successfully run frequent suburban all-stop service with 12 mins interval on single track.


I am wondering when journey-time-measurement-2 branches will merge into master?



suitougreentea

Thank you very much for trying my patch and app!

QuoteI am wondering when journey-time-measurement-2 branches will merge into master?

It depends on my busyness. Unfortunately it takes about 2 weeks before I can resume working on this patch.

Ves

I tried this today and it looks very promising! Although I could not get the external aplication to take my ingame lines, Im really looking forward to when this is part of the game! :)
One thing that you could add to the ingame window is the distances between the stops. That will help with several things:
* It adds information to the player to get an estimate by how long the line is and how far the stops are between each other.
* When planning the line and choosing vehicles, you have the range value of the vehicles. Showing the distances in window will greatly help the player choose what vehicles to use, or wether the line needs replanning.


suitougreentea

It was fortunate I got enough time to update this. I pushed some fixes proposed to journey-time-measurement-2 branch.



QuoteOne thing that you could add to the ingame window is the distances between the stops.

It seems like a good idea, but which do you want?


  • simple distance between stops: it is very easy to be implemented, but not so useful when the path detours
  • length of path between stops: more useful for planning schedules, but the implementation is more complex since it needs a "measurement" as well

jamespetts

Quote from: suitougreentea on December 23, 2017, 04:14:31 PM
It was fortunate I got enough time to update this. I pushed some fixes proposed to journey-time-measurement-2 branch.

Splendid, thank you! I am currently staying away from home for Christmas, so it is not so easy to work on the code (I am focussing on pakset work for the season), but I will have a chance to test this when I get back home in the second week of January.

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

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

Follow Simutrans-Extended on Facebook.

jamespetts

Apologies for the delay - I have just had time now to have a look at this. I have merged this with the latest code on the master branch and uploaded it to my journey-time-measurement-2 branch.

Generally, this appears to be working well - but one thing that I notice that does not seem quite right is that, often, averages will be incorrectly calculated; not the average of three times, but the lowest of the three. I can upload a saved game in which this can be reproduced if it would be helpful, but I found that this behaviour was so common (at least half of the lines) that it may well not be necessary to use a specific saved game.
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.

suitougreentea

Thank you for reviewing. I think the issue of average comes from the granularity of time - it is now tenth of a minute. I can fix this hopefully in a few days.

jamespetts

Quote from: suitougreentea on January 08, 2018, 05:04:34 PM
Thank you for reviewing. I think the issue of average comes from the granularity of time - it is now tenth of a minute. I can fix this hopefully in a few days.

Thank you for clarifying - that does seem consistent with what I can see. I will merge this into the master branch now, but an update to bring this to a minute's resolution would be appreciated.

Thank you very much for your work on this - I anticipate this being appreciated by players.
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.

suitougreentea

I am very grateful for your support. I will work on the fix for average as soon as possible.

One thing: I forgot to push base-texts for this patch. (It is .gitignore'd?) I attached it to this post.

jamespetts

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.

suitougreentea

I have fixed resolution of average time. The updated code is at journey-time-measurement-2 branch.

jamespetts

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.