The International Simutrans Forum

 

Author Topic: Schedule features: technical discussion  (Read 9249 times)

0 Members and 1 Guest are viewing this topic.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18557
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #70 on: September 19, 2018, 04:15:37 PM »
The stack priorites for coupling vehicles would be just the same, it is the "negative" stack priorities, ie what vehicles to uncouple that is what I am talking about.
Remember, we are only talking about uncoupling vehicles, not coupling vehicles, because I believe that is already taken care of with your approach. The only thing I want is that it is the correct car to be detached.

I am not sure that I fully understand this distinction here, as the consist order specifies only the makeup of the consist after recombination, so whether any given vehicle is coupled or uncoupled is indeterministic at the point when the consist orders are written.

I do not really understand what you mean by "negative" stack priorities: the stack is just an ordered list of vehicle type descriptors in slots. There is only one stack priority. The idea is that the algorithm simply checks (1) the existing consist; and (2) the vehicles available either loose or in joining consists to make up something that matches the description of the consist in the consist order, in order of priority. If vehicles are uncoupled it is because the algorithm has determined that they do not form part of the end state consist as specified in the consist order (and, in so far as there are stacks and lower priority vehicles are included, in so far as the relevant vehicles are available).

Offline Ves

  • Devotee
  • *
  • Posts: 1655
  • Languages: EN, SV, DK
Re: Schedule features: technical discussion
« Reply #71 on: September 19, 2018, 04:39:50 PM »
Yes, the consist order specifies the makeup of the convoy leaving the station, however, it needs to be calculated which vehicle to be detached somehow, and that is what I called the negative stack priority. It would simply be the difference between the makeup of the consist order before arrival and after departure. Those vehicles that where in the old consist order but not in the new, are the ones that is least suited in the stack of priorities.
What I am suggesting is that when it determines which those least suited vehicles are from the stack of priorities for the new consist orders, it should also look for the good inside the vehicles. If the good has this particular stop as its "intermediate _shunting" stop, it would be the least suited vehicle per definition, even though there might be another vehicle that would otherwise be the least suited.

That would mean that if the consist order of the convoy leaving the station is made up from as fast vehicles as possible, but the train, when approaching the station has a slow vehicle in it, it would drop of a fast vehicle, if that has the good with the "intermediate_shunting" set for this station.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18557
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #72 on: September 19, 2018, 10:38:22 PM »
My apologies if I am being a bit dim, but I still do not understand fully what you seek to achieve. Are there any circumstances in your preferred algorithm in which, in my example, a slow vehicle would continue down the main line if a fast vehicle were available? If not, how is this functionally different to simply silently and instantly re-arranging the goods inside the train at the junction station?

Offline Ves

  • Devotee
  • *
  • Posts: 1655
  • Languages: EN, SV, DK
Re: Schedule features: technical discussion
« Reply #73 on: September 19, 2018, 11:40:36 PM »
The end goal is that good should never have to rearrange.

Let me try to do an example:

Lines:
"Branch line X - B"
"Main line A - B - C - D"
"Branch line C - Y"

Consist orders:

"Branch line X - B"
X -> B - [Power unit] - [piece good] - [piece good]
Target at B:  "Main line A - B - C - D"

"Main line A - B - C - D"
A -> B - [Power unit] - [piece good, fastest possible] - [piece good, fastest possible]
Target at B:  none
B -> C - [Power unit] - [piece good, fastest possible] - [piece good, fastest possible] - [piece good, fastest possible] - [piece good, fastest possible]
Target at C:  "Branch line C - Y"
C -> D - [Power unit] - [piece good, fastest possible] - [piece good, fastest possible]

"Branch line C - Y"
C -> Y - [Power unit] - [piece good] - [piece good]

Vehicles:
Beside the power units, which we dont bother with in this example, we own:
[Piece good car, 40km/h]
[Piece good car, 40km/h]
[Piece good car, 80km/h]
[Piece good car, 80km/h]


So, the scenario:

The power unit on line "Branch line X - B" is at station "X", and according to its consist order, it is supposed to fit two piece good cars, with no further constraints or priorities. At station "X", these two cars are located: [Piece good car, 80km/h] and [Piece good car, 80km/h], which are the two fastest cars that we own.
The power unit departs from "X" with those two cars, which is full of piece good to "Y".

At station "A", the convoy is assembled for line "Main line A - B - C - D". It will consist of the power unit and [Piece good car, 40km/h] and [Piece good car, 40km/h], since there are no faster vehicles available at "A". Those two cars are running empty.
When the convoy arrives at station "B", it fullfills its consist order by fetching the missing vehicles from the branch line convoy, and it is now ready to travel to station "C" with all four cars.

At station "C", is where it gets difficult:
The consist order for line "Main line A - B - C - D" departure from "C" tells it to have only two cars attached, for which its priorities is to have the fastest cars possible.
However, the two fastest cars available are currently loaded with good to "Y", so they are disquallified, and hence given the lowest priority in any of the slots for the departure from "C" to "D".
That would result in the two slow cars becoming the "fastest" cars available, and therefore they are choosen to be kept in the convoy for the departure from "C" to "D".

Does this makes sense?


What would happen if the consist order from "C" to "D" looked like this (added one more car):
C -> D - [Power unit] - [piece good, fastest possible] - [piece good, fastest possible] - [piece good, fastest possible]
Answer: Since the cars loaded with good to "Y" only was given the lowest priority, one of those cars would get detached, and the other would remain in the convoy. That would be a player mistake.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18557
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #74 on: September 27, 2018, 10:01:50 PM »
Do I understand, then, that the answer to the first question in my previous post is "yes"? Do I understand correctly that the algorithm that you suggest is simply that any vehicle with goods loaded for a destination not served by the current schedule of the train connected to the consist order would, irrespective of the stack priorities in the consist order, be used in that consist only if nothing else is available?

I can foresee some real difficulties with this, at least many of which fit into the chaotic consequences category. Firstly, the schedule of the convoy on which the consist order is currently operating may not contain the final destination of the vehicle in question, as it may at a later stop be split from the current consist and re-combined with a different consist to reach its destination (and this may happen an unlimited number of times). In this case, I can foresee failures by the algorithm to attach the expected vehicles in the way that is intended by the player. Secondly, there is no "fastest available" datum in the consist orders. Instead, there is a datum for minimum speed. To get something like "fastest available", one would have to stack several different sets of rules, each with progressively lower minimum speeds. Thirdly, if you had imagined that this would work, not just on stack priorities, but on the actual rules themselves (as the reference to "fastest available" suggests), then it is not clear how this might work without creating the possibility of forming an unworkable train (e.g., one that is too heavy for its route) that is contrary to the player's intention and explicit instruction.

Offline ACarlotti

  • *
  • Posts: 421
Re: Schedule features: technical discussion
« Reply #75 on: September 27, 2018, 11:17:53 PM »
It seems to me that in the above scenario it should be possible for the player to choose the outcome. Depending on the exact context, it might be more important to avoid transferring the goods from one vehicle to another at the station, or it might be more important to ensure a higher mainline running speed.

I think a lot of potential issues with malformed convoys can be mitigated by allowing a convoy to leave some vehicles to be added to a later instance of the schedule (and possibly the entire train). So for the case of a too heavy train (too many vehicles are being routed onwards onto one portion of the schedule), the player would specify a weight limit for the consist and if the vehicles being allocated to that portion of the schedule amount to a greater total weight, then the excess vehicles would be allocated to a new convoy running to the same schedule, together perhaps with a portion of the next convoy to arrive on the route.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18557
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #76 on: September 28, 2018, 10:00:32 AM »
Can I ask what you would imagine the data structures/algorithm for this choice being and what exactly people would be choosing?

Offline Ves

  • Devotee
  • *
  • Posts: 1655
  • Languages: EN, SV, DK
Re: Schedule features: technical discussion
« Reply #77 on: September 30, 2018, 10:58:00 AM »
Do I understand, then, that the answer to the first question in my previous post is "yes"? Do I understand correctly that the algorithm that you suggest is simply that any vehicle with goods loaded for a destination not served by the current schedule of the train connected to the consist order would, irrespective of the stack priorities in the consist order, be used in that consist only if nothing else is available?
Yes, it means yes to both questions.

Quote
I can foresee some real difficulties with this, at least many of which fit into the chaotic consequences category. Firstly, the schedule of the convoy on which the consist order is currently operating may not contain the final destination of the vehicle in question, as it may at a later stop be split from the current consist and re-combined with a different consist to reach its destination (and this may happen an unlimited number of times). In this case, I can foresee failures by the algorithm to attach the expected vehicles in the way that is intended by the player.
I dont think I follow. The good must know at what station it expects to change convoy, respectively to unload and load into another convoy? If you mean that the player has made a mistake somewhere and not included a car that the good can travel in, then that is a player mistake.

Quote
Secondly, there is no "fastest available" datum in the consist orders. Instead, there is a datum for minimum speed. To get something like "fastest available", one would have to stack several different sets of rules, each with progressively lower minimum speeds.
No, I made it simple for the demonstration purposes. I believe there is "prefer high speed" though.

Quote
Thirdly, if you had imagined that this would work, not just on stack priorities, but on the actual rules themselves (as the reference to "fastest available" suggests), then it is not clear how this might work without creating the possibility of forming an unworkable train (e.g., one that is too heavy for its route) that is contrary to the player's intention and explicit instruction.
Planning. The player needs to anticipate what vehicles are to travel the network. And frankly, if the player knows that a bunch of heavy cars are loaded with a particular good, the player will automatically anticipate that it is those particular heavy cars that will end up at the destination too, no matter what is written into the consist orders.

That is even very intriguing gameplay I think: If you know you are sending good to a factory high up in the hills, make sure the cars you send to the initial factory has good braking abilities. If you know that you are sending good that is meant to travel long distance on the shared main line, make sure the cars are fast.

GUI-wise it is very easy to display to the player that any loaded good has the highest (or at least to a certain degree) priority.

It seems to me that in the above scenario it should be possible for the player to choose the outcome. Depending on the exact context, it might be more important to avoid transferring the goods from one vehicle to another at the station, or it might be more important to ensure a higher mainline running speed.

I think a lot of potential issues with malformed convoys can be mitigated by allowing a convoy to leave some vehicles to be added to a later instance of the schedule (and possibly the entire train). So for the case of a too heavy train (too many vehicles are being routed onwards onto one portion of the schedule), the player would specify a weight limit for the consist and if the vehicles being allocated to that portion of the schedule amount to a greater total weight, then the excess vehicles would be allocated to a new convoy running to the same schedule, together perhaps with a portion of the next convoy to arrive on the route.
The only issue I can find is if in that example the slots for the rest of the main line had also a "minimum 80kmh" tag, discarding the two slow cars that where remaining in the convoy. If no other mechanism in place, that would halt the convoy there, only to leave when the branch line returns with the two, now emtpy, cars.
This is what I would call a player error. The player has made the rules too narrow, and should either not have a "minimum 80kmh" tag for the last bit, OR should have made sure that it is in fact the two slow cars that get loaded in the first place, for instance by placing "minimum 80kmh" on the line B->A in the reverse direction, assuming they are all empty.

I believe, however, that it is meant to be able to have empty slots as well, which I assume would make it possible to have make convoys more flexible in length.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18557
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #78 on: May 18, 2019, 01:12:13 PM »
I am beginning the process of reviving work on this set of features, as the critical issues on the master branch now seem to have been resolved. The first task was to merge in the latest changes from the master branch (the relevant branch is vehicle-management). I have now done this and tested it to the very limited extent that it compiles and runs by loading the Pak128.Britain-Ex demo game without crashing.

I have not tested this any more extensively than that at this stage. There may be some benefit in giving some consideration to some of the currently ongoing discussions about train consists and reversing and how they might interwork with the features on this branch. There may be something to be said for those who are doing work of that sort to inspect this branch to make sure that what is being done does not conflict with the work here.

A summary of where we are with the coding work on this branch is that we have the data structures for a large feature set, and the logic for a very small proportion of that feature set (e.g. ignoring choose signals in the schedules) implemented. Some of the UI work has been done (by Ves), but I cannot remember how far that this had got. Ves had also started work on an interesting vehicle manager concept to integrate into this project.

The next stage, beyond more basic testing of the merge, is likely to be to undertake some more theoretical design work to check how well that this integrates with the features being discussed with respect to reversing and some of the ideas that I had posited a short while ago to-day regarding how to keep a track of how many guards that trains need for economic purposes. We are still at an early enough stage that we can change fairly substantially how these features are to work, as most of the logic has not been implemented yet (and it does not currently matter if we modify the data structures and break saved games since there are no significant saved games created with this branch at this stage), but we will need to be fairly decisive within a reasonable time about the final design before work can commence on any necessary changes to the data structures and the coding of the logic and GUI.

Generally, the best sequence for coding is data structures > GUI > logic: that way, the GUI can be written so as to modify the data structures, and the logic can be easily tested using the GUI. The GUI can be modified if necessary after the implementation of the logic.

I know that Ves has been working on the GUI for this; I wonder whether Ranran and Ves might like to collaborate for continuing this work? Ranran's work on the GUI recently has been most helpful  and there is much to be said for some degree of integration of this with some other project on which Ranran is working.

In any event, the immediate next steps are:

(1) basic testing; and
(2) further discussion.

I do encourage others to test the vehicle-management branch to check for any major anomalies introduced by the merge (bearing in mind that most of the logic has not been written yet so most of the features will not function).

Ves - are you able to bring your UI work up to date with the latest code by eliminating merge conflicts?

Offline Ves

  • Devotee
  • *
  • Posts: 1655
  • Languages: EN, SV, DK
Re: Schedule features: technical discussion
« Reply #79 on: May 18, 2019, 11:37:42 PM »
Yes I am currently updating my branch to be the same as your vehicle-management, although I do have some severe merge errors for some reasons that I need to resolve...

One note to my work is that I probably had misunderstood the broadcasted and recieved bitfields. Currently it is only a combobox where you can select a number, but as I understood it you should be able to select multiple numbers. I have an idea how to do that in the GUI, but first these merge conflicts....

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18557
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Schedule features: technical discussion
« Reply #80 on: May 19, 2019, 12:20:19 PM »
Excellent, thank you very much. Please let me know when you have completed the merging.

Offline Ves

  • Devotee
  • *
  • Posts: 1655
  • Languages: EN, SV, DK
Re: Schedule features: technical discussion
« Reply #81 on: May 19, 2019, 06:24:13 PM »
Well, I realize I have been making a mistake:

When coding the new Vehicle Manager, I did that in the same branch as the new schedule dialog without realizing that. That means that the Vehicle Manager will come over as well into the "main" veh-management branch.
Maybe that is not necesarily a problem, since the window is working fine in its current state, although unfinnished and only shows information.
The problem being however that I have had my setup target Win32 up until now, and when compiling it with x64 I get this error message when trying to open the window:

"Run-Time Check Failure #2 - Stack around the variable 'X' was corrupted"
I need to investigate that stack error. Any suggestion what might be causing that for 64 bit and not for 32 bit? For info 'X' is a char variable.


edit:
Oh, stupid me! I have just not given the char's enough space in certain cases!

Offline Ves

  • Devotee
  • *
  • Posts: 1655
  • Languages: EN, SV, DK
Re: Schedule features: technical discussion
« Reply #82 on: May 19, 2019, 10:13:22 PM »
So, Im finished merging and the branch can be found here:

https://github.com/VictorErik/Simutrans-Experimental-Ves/tree/veh-managment-gui

But as I said above, the Vehicle Manager is also on that branch. I will split it in two eventually so that work can be done to them separately in the future...
If you want to have the vehicle manager button in the pakset right away, you should add the menuconf.tab that is linked here:
https://github.com/VictorErik/saved-games/blob/master/veh-managment-gui/menuconf.tab
The button is located right next to the Line Management button, although the best position might still not be found.
Also, I dont have any graphics for the button, so it borrows the graphics from the online play button...

edit:
I have now updated the schedule window to have proper bitfield broadcasters and recievers. It works by typing in the numbers you want to activate in a text field, and the textfield then sets the correct bits. The list of stops also correctly shows what bits have been selected for the particular stops.
That window is now being worked on in this new branch derived from your vehicle-management:
https://github.com/VictorErik/Simutrans-Experimental-Ves/tree/veh-man-schedule-window
Note: You appear to already have my schedule window in your vehicle-manager branch, so there should be no merge problems with this and my vehicle manager if you wanted to have that as well.
Also note that the schedule window is rather messy now. I am thinking of how to group the settings the best way possible but there are maybe even more settings that will make it into the window eventually...
« Last Edit: May 20, 2019, 01:44:01 AM by Ves »