News:

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

Schedule features: technical discussion

Started by jamespetts, January 22, 2018, 11:15:36 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ves

Thanks, but how do I manipulate the entry? How do I set the condition trigger to, say 5?

jamespetts

Are you referring to how to set and read the bitfields (of which condition_trigger) is one? If so, then you need to use the following methods as defined in schedule.h:


bool is_flag_set(schedule_entry_flag flag) const { return flag & flags; }

void set_flag(schedule_entry_flag flag) { flags |= flag; }

void clear_flag(schedule_entry_flag flag) { flags &= ~flag; }


So, if you want to check whether the condition trigger is set for a schedule entry called "kittens_entry", you would do as follows:


bool is_set = kittens_entry.is_flag_set(condition_trigger);


If you want to set the target_id_condition_trigger field, you need only set it directly from the relevant schedule_entry_t object, so, for example:


kittens_entry.target_id_condition_trigger = 5;


Does this assist?
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

Thanks, yes that does help.

Could you perhaps clarify what is the difference between:

"condition_bitfield_receiver"
and
"condition_bitfield_broadcaster"

Which one is used for what?

I have a new schedule window with some new functions, however the layout is currently horrible. It is only so you can start testing the features. The consist order management it self I have not yet begun with, I need to think what the window needs to look like and start from there somewhere.
I will upload the new schedule window soon to github!

jamespetts

Thank you - that is very helpful.

The condition bitfield broadcaster is the identity of the signal(s) sent to convoys upon the reaching of the relevant point in the schedule. The condition bitfield receiver is the identity of the signal(s) to which that convoy should respond at that particular point in its schedule. Does this make sense?
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

Thanks. So to rephrase it:

So when the convoy is waiting for a conditional trigger, it is waiting for the correct value from the condition_bitfield_reciever?

And directly when the convoy stops at a schedule entry, it automatically broadcasts the value set in condition_bitfield_broadcaster to other convoys?

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.

Ves

So, a first incarnation of the new schedule window is ready:

I believe the condition triggers are setup correctly, you could perhaps take a look and check that they are altered correctly.
The "lay over" and "force range stop" buttons are also in place, and they appear to be working. Again, please have a look :)
The button "modify convoy" is non functional. It only serves a function to take up space in the window to see where things might have their places.

I have altered the order of the left hand side stuff, for instance moved the "maximum wait time" to be furtherst down. It is my believe that that should be able to be used together with all modes of "wait for..."
I would like to alter the way you specify the wait for time. Currently the clock comes alive when you press the wait for time button, but I would rather have the clock come alive by a button down next to the departures/month text somewhere. Then it would be more obvious that the player decides that "this" station should wait for time, and "this" and "this" etc, and you can alter the time even if another station is selected. The "Shift value" I would like to have a douplicate in the upper left hand section, so when the "use same shift...." is unpressed, the original one in the lower section gets greyed out and the upper one gets active. Then if the "use same shift..." is ticked again, its vice versa.

Now, in the schedule entries, I have made some alterations:
I built upon the syntax "[somethingsomething]" and it is currently the initials of the commands which is showed. Im not sure if that is the best way, I could not think of any symbols that might be better suited. Now as initials, they can be used together with translator::translate, so people can translate that into their own language if wanted. However, I think that the condition triggers looks very nice with [->4] and [4->], which means reciever respectively broadcaster. It should become quite obvious once you start play around with the buttons.

Now the layout is not really finish as well as the window needs resized, but I think it is something like this I would do. There are room for more buttons and text if needed.
The couple and uncouple commands along with the specific line and convoy target id trigger I have not touched upon yet, I had an idea that some of this either was done automatically by the GUI, alternatively if it is needed, the commands could live in the modify convoy window, to have more overview there. Or do you think otherwise?

What more functions exists in this manner that would fit well into the schedule window?

Github: https://github.com/VictorErik/Simutrans-Experimental-Ves/tree/consist-order-gui

jamespetts

Thank you very much for your work on this: this is most helpful.

In relation to the specification of "Wait for time", it appears that the "wait for time" button is not currently working properly, as the "Departures/month; shift" number entry fields are not activated when this is first pressed. The suggestion in relation to the placement/number of the number entry fields for the spacing shift seems sensible.

In relation to the couple/uncouple parameters, these will need to be able to be set manually in the GUI (but you might think it better to have the settings for this in the "Modify convoy" window; but I will leave that to your discretion).

As to your last question, can you elaborate on what you mean by functions existing in this manner?

Thank you again for your work - it is much appreciated. I have now incorporated this into the vehicle-management branch.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Ves

Thank you. I have however not altered the function of the "wait for time" at all, only where it is located!

Ok, I suspected that the coulpe and uncouple command needs to be set manually by the player, but i think that should take place in the modify convoy window.

What I meant was that I still dont feel like I have a proper overview of what new functions exists or are about to exist. I dont want to miss create the GUI for a function just because I didnt know about it! :)

jamespetts

Ahh, I see! If you have any specific questions, do ask, and I will endeavour to assist.
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

So, I guess time has finally come to start looking more into this. I have had lots of things to do in the spring, and the summer has been exceptionally hot here (30+ degrees in Denmark for 50+ days is extreme!) but I have made some progress on a new window called "vehicle manager" window. It currently lists vehicles in different ways making it possible to select multiple vehicles across lines and convoys for different actions, but is not near completion just yet.

If you want to check it out in its current state, check it out here. The commits has some texts explaining the current progress and features:
https://github.com/VictorErik/Simutrans-Experimental-Ves/tree/veh-managment-gui

Im sorry if I am repeating some earlier questions or thoughts :)

1) Magic numbers:
The previous windows I have coded ("vehicle_class_manager_t", "line_class_manager_t" and now "vehicle_manager_t") it has been quite easy to figure out what magical numbers each window has, ie the previous "window" plus the amount of, for instance players or convoys:

...
magic_vehicle_manager_t = magic_pwd_t + MAX_PLAYER_COUNT,
...

...
magic_class_manager = magic_info_pointer + 65536,
magic_line_class_manager = magic_class_manager + 65536,
...


However, if Im not mistaken, the "consist order manager", would need to exist one for each stop in a schedule, but how many is that? Am I safe to assume that there might be only 65536 combinations of stops and schedules, or what do you think?

2) Who "owns" the "consist order manager"?
With the three previous windows it was pretty easy to figure out who owns the window:
"vehicle_class_manager_t" is owned by the convoihandle_t(I realize that the name is actually confusing, should be renamed to "convoy_class_manager_t"),
vehicle_class_manager_t::vehicle_class_manager_t(convoihandle_t cnv)
"line_class_manager_t" is owned by the linehandle_t, and
line_class_manager_t::line_class_manager_t(linehandle_t line)
"vehicle_manager_t" is owned by the player_t.
vehicle_manager_t::vehicle_manager_t(player_t *player_) :

3) Suggestion on layout:
When the player is planning the consist order rearrangements, there is no way for the consist order window to know what the convoy(s) looks like or even if there will be different kinds of convoys. Therefore, the consistorder window cannot display what the old convoy looks like, as well as it cannot display what the new convoy(s) will look like. The only thing it will know with certainty is whatever the player is typing into the window.
Therefore I would suggest to have two fields, one coupling field and one decoupling field. Below there is a vehicle selection field containing an example of all currently owned vehicles (perhaps also buyable vehicles?) as well as some "wildcard" vehicles where the player can specify features that the convoy will be looking for to attach or detach vehicles.

How does that sound?

jamespetts

Thank you very much for continuing work on this - I should probably resume work on the substantive aspects of this branch soon again, too, as the critical bugs seem to have been dealt with and it seems that the passenger generation issues that remain are unlikely to be able to be dealt with separately from a major code overhaul involving working with town growth, short of some relatively minor changes to the configuration settings the first round of which I have already made.

The next major task with this branch is to bring it up to date with the current master branch, which has had quite a lot of changes since this was last worked on. I anticipate that there will be a number of merge conflicts, but I am not yet sure how significant that they are likely to be and how much work that it is likely to take to resolve them.

To address your questions - I am afraid that I have never delved deeply enough into the GUI code to be able to answer your questions 1 and 2: I do not know how the magic number system works nor about the ownership hierarchy for windows.

As to the third question, we need to remember the quite detailed discussion above (which I have had to re-read to remind myself of) about how consist orders are going to work. As discussed above, the system is that the consist orders will consist of a description of the end-state convoy after the consist order has taken effect. This list will either be a list of (1) specific vehicle types; or (2) abstract rules about vehicles (must carry piece goods, must have a minimum speed of 55km/h, must have a minimum capacity of 20 crates, etc.) (the list might also be a combination of both). Thus, there is no "coupling" or "uncoupling" field: rather, there is an ordered set of vehicle types, either specific or abstract. For specific vehicle types, the actual graphics for this type of vehicle should be used. For abstract types, a special abstract graphic should be developed and used (I suggest a grey outline of some sort; if we want to be more sophisticated, we might have a few different outlines depending on the nature of the rules, e.g., one for locomotives, one for passenger carriages, one for freight wagons, one for miscellaneous, etc.).

I suggest that a good, easy way of doing this is a simple button for a player to add a blank vehicle slot, and then controls to turn that blank vehicle slot into a vehicle slot populated by some rules or a vehicle slot populated by a specific vehicle type. We also need a way to let players select each vehicle slot (and show which is currently selected) in order that players can easily change an existing vehicle slot.

We also need to deal in the UI for consist orders with the question of splitting, and, specifically, which set of vehicles after the split retains the original schedule and which is assigned the new schedule.

Does this assist?
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.

Phystam

Thank you for your great work!

I tried to compile the branch of ves, but it failed with fatal error.
It seems that there is no "vehiclehandle_t.h" file, so please add it.

ACarlotti

Quote from: jamespetts on September 03, 2018, 10:53:38 PMThus, there is no "coupling" or "uncoupling" field
In this discussion (regarding the implications for the path explorer) we were suggesting coupling and uncoupling could be separate actions that can, if necessary, occur on repeated instances of the station halt in the schedule.

In the coupling case the consist order would be either redundant, or could be used for picking up loose vehicles (if that is a desired feature; I can't currently remember any reason to have it). In the uncoupling case I think it could be useful to have it behave symmetrically - i.e. the player can specify the vehicles desired in both the continuing portion and the detached portion.

The logic that actually determines how a convoy divides is likely to be quite complicated, since it will have to further take into account the coupling constraints (and perhaps orientation of the vehicles), along with considerations of what happens if the consist order is ambiguous or cannot be met. However, this seems to be a largely separate issue to that of creating the gui.

One further thing about the gui: At some point I hope to merge in the recently developed new gui system for Standard, and then for the remaining Extended guis to be adapted to also use the new system. However this is probably some time of (perhaps about a year away?) and so these gui features shouldn't wait for that.

Phystam

#49
(I use gcc compiler for mingw 64bit version)

I copied "convoihandle_t.h" to create "vehiclehandle_t.h", and then I got a error of undefined definition of vehicle_manager_t::rdwr() and consist_order_t::rdwr().
I added 2 lines in Makefile at l477:

SOURCES += dataobj/consist_order_t.cc
SOURCES += gui/vehicle_manager.cc

And I faced another error "display_fillbox_wh_clip(...)" in vehicle_manager.cc. The function take only 6 arguments, but it has 7 arguments.
I removed one of the color parts, And I could compiled successfully.
However I cannot run the binary, simutrans shows:

FATAL ERROR: loadsave_t::rdwr_bool() - expected "<bool>", got "</eins"
Aborting program execution ...


What's wrong?

___

EDIT:
I cleared this error by deleting simutrans-extended.xml.

jamespetts

ACarlotti - from what I understood of the thread to which you refer, the split and join commands were to be part of the schedule, not of the consist order. The data structure as implemented for the consist orders is here, which does indeed implement the target convoy model discussed in this thread. The coupling/uncoupling is dealt with in the schedule entry data structure, which has specific data members for this.

Thus, in the schedule, one would specify flags for coupling/uncoupling and the target convoys, and in the consist orders, one would specify the desired end state of the convoy in the manner described above.

I do not think that any of this is inconsistent with your suggestion in the thread to which you have referred, although it has been a few months now since I looked at this in detail.

Phystam - do I understand that you have now managed to get the compilation to work? I should note that some updating will be required for this branch to bring it up to date with the latest changes on the master branch, including version number changes that will break any existing saved games from this branch, so do not use this for actual playing at this stage.
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

Oh gosh, vehiclehandle_t was an experiment of mine that I had forgot to clean up. Every reference to that file should have been deleted, also in the Solution Explorer. I have made a new commit where all that is done.
The gcc compiler stuff  is also correct, and I have added those to the file (although the "consist_order_t"-one is James creation  ;D )
And thanks for pointing out the "display_fillbox_wh_clip(...)" too. It compiled without problems on MSVS 2015!
Hopefully it should work out of the box this time.
Be aware that the vehicles cannot really sort in the right hand window, since there is no "Odometer" parameter of individual vehicles yet, but Im anticipating James might create that some time in the future :)
The basic layout is as it should be, and I am thinking of adding some filters, especially for the right hand window, so one can make interresting vehicles pop out for easy selection.
The lower tabs might also be subject to change, dependent on what information and what actions it will be possible to perform to individual vehicles.

---

QuoteOne further thing about the gui: At some point I hope to merge in the recently developed new gui system for Standard, and then for the remaining Extended guis to be adapted to also use the new system. However this is probably some time of (perhaps about a year away?) and so these gui features shouldn't wait for that.
I have seen that you are merging GUI stuff from standard over, and I am eagerly anticipating the merging of the gui_convoy_assembler, because I would really like to make some adaptions to it to make it fit the consist order window. But you might be right, that is only very recently changed in standard, so I might do some adjustments first..

QuoteAs to the third question, we need to remember the quite detailed discussion above (which I have had to re-read to remind myself of) about how consist orders are going to work. As discussed above, the system is that the consist orders will consist of a description of the end-state convoy after the consist order has taken effect. This list will either be a list of (1) specific vehicle types; or (2) abstract rules about vehicles (must carry piece goods, must have a minimum speed of 55km/h, must have a minimum capacity of 20 crates, etc.) (the list might also be a combination of both). Thus, there is no "coupling" or "uncoupling" field: rather, there is an ordered set of vehicle types, either specific or abstract. For specific vehicle types, the actual graphics for this type of vehicle should be used. For abstract types, a special abstract graphic should be developed and used (I suggest a grey outline of some sort; if we want to be more sophisticated, we might have a few different outlines depending on the nature of the rules, e.g., one for locomotives, one for passenger carriages, one for freight wagons, one for miscellaneous, etc.).

I suggest that a good, easy way of doing this is a simple button for a player to add a blank vehicle slot, and then controls to turn that blank vehicle slot into a vehicle slot populated by some rules or a vehicle slot populated by a specific vehicle type. We also need a way to let players select each vehicle slot (and show which is currently selected) in order that players can easily change an existing vehicle slot.

We also need to deal in the UI for consist orders with the question of splitting, and, specifically, which set of vehicles after the split retains the original schedule and which is assigned the new schedule.
I am still struggling to extensively understand, and I will try to explain with the following examples:

1) The player creates a line without any convoys assigned to it.
The player presses the consist order window on one of the schedule entries.
What is then displayed in the consist order window? There cannot be displayed a convoy, since there is no convoy associated with the line...

2) The player buys a bunch of vehicles and putts them together in different kinds of convoys
The player creates one line and assign all the different kinds of convoys to that line.
The player presses the consist order window on one of the schedule entries.
What is supposed to now be displayed in the consist order window? There are already different kinds of convoys, should they all be displayed? What if the player creates yet another different kind of convoy and assign to the same line, how should the window react to that?

Im really sorry if Im thickheaded, I try to understand as much as possible  :o

ACarlotti

James: Having read your post, I think I agree that there is no inconsistency

Ves:
In your examples I don't think there would be a consist order window - I envisage these existing only for uncoupling events (and possibly coupling too; I'm unsure here).
In the case where new consist orders are created (for uncoupling and possibly coupling events) I think a sensible default would be to use the output of a previous consist order (if one exists), with no vehicles allocated to the uncoupled (or coupled) portions by default (so the 'through' portion is given the same consist order). If no previous consist order exists then you could take the consist order corresponding to the convoys currently preceding this event on the line (if any exist and they are all the same), or alternatively use empty and 'wildcard' consist orders (I think it would be useful to be able to easily specify a consist order that accepts any vehicles in any order and quantity).

Ves

Quote from: ACarlotti on September 04, 2018, 03:12:20 PM
Ves:
In your examples I don't think there would be a consist order window - I envisage these existing only for uncoupling events (and possibly coupling too; I'm unsure here).
In the case where new consist orders are created (for uncoupling and possibly coupling events) I think a sensible default would be to use the output of a previous consist order (if one exists), with no vehicles allocated to the uncoupled (or coupled) portions by default (so the 'through' portion is given the same consist order). If no previous consist order exists then you could take the consist order corresponding to the convoys currently preceding this event on the line (if any exist and they are all the same), or alternatively use empty and 'wildcard' consist orders (I think it would be useful to be able to easily specify a consist order that accepts any vehicles in any order and quantity).
Thanks, however the window (in lack of better words I have called it the "consist order" window, maybe "consist manager" is better?) that the player opens is only the ultimate edge case to demonstrate that there needs to be something to show the player when you want to plan a coupling or uncoupling event, if it is not, as I suggested earlier, two fields with what the line should desire for whatever convoy that happens to run that line entering that station, to get coupled and uncoupled.
It would be fine if it shows a blank dummy consist order, or a "wildcard" consist order, where the player can manipulate that, and preprogram a detachement of some cars. Then whenever a real convoy gets onto that line, the convoy updates its own existing consist order with the additions from the "wildcard" consist order. But I get the impression that this is not the way it will be working?

jamespetts

There seems to be some misunderstanding of how consist orders are intended to work. The consist order is intended to describe the makeup of the consist after any (implicit) shunting operation has been applied to it. It does not matter what the makeup of the consist before the consist order was (except that the vehicles to form the new consist will, if they match the descriptions, be taken preferentially from the old consist rather than from loose vehicles available at the station/depot). There is thus no explicit couple/uncouple in the consist order itself: what, if any, coupling and uncoupling is (implicitly) done will depend on the extent to which whatever the current consist makeup happens to be differs from whatever is specified as the post-shunting consist makeup in the consist order.

Thus, in the cases that you describe, the consist order window would not show any specific consist until the player selected some vehicles. There may be cases in which the code can infer that there is only one prior formation (e.g., there is only one consist makeup running on a particular route), in which case this can be presumptively selected as the new consist order, and able to be edited by the player.

Incidentally, as to the term "consist mangager", "consist orders" (note the plural) is preferable, because "consist manager" implies general management of consists, whereas consist orders relate to orders given specifically to change the makeup of any given consist.

Does this assist?
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

Thank you, it does indeed assist, I think I understood something now:

The player opens the window, which is empty, and manually selects vehicles to populate the consist order as it is supposed to look like when the convoy is leaving the stop? Any vehicle present in an convoy on that line, which is not specified (directly or by wildcards) in the consist order will get detached automatically (if the "uncoupling flag" for that stop is selected) and sent to other lines or in the layover state?
If the player let the consist order window remain blank, theoretically the convoy would disintegrate, putting all vehicles in layover state, leaving no convoy behind to further travel the schedule?

That is way different than what I had imagined (as you probably knew...)!

I could imagine with this approach that you don't build convoys as such in the depot anymore, but rather let them assemble them selfs from pools of layover state vehicles and vehicles from other convoys.
Also this probably generally will make lines with (mostly) similar convoys, due to them being self constructed. Unless you allow for conditional consist orders, but that might be overkill...
I know there are the wildcards to have variation, but I don't remember: is it possible to have a vehicle slot as "either/or"? Like this:
Either "class 50" or "class 60"

The challenges GUI-wise is to help the player keep focus on what is important.
When a good train with lots of boxcars is running a long line with multiple drop off points where just one, or a couple of cars, get detached at each stop, the window will show the long string of vehicles in the convoy when you open the manager (since we make it remember between stops, and let's say you already "assembled" the train in a previous consist order). The important decision is what cars are being dropped if, not all the cars that should continue further. What tool will the player have to help identify the correct boxcar for detachment in the consist order (say the consist order is built up heavily using wildcards, which means that the car we want to detach got attached using a wildcard in the first place)?

With this information I believe I'm ready to start the task of creating the window.
I will give it the same magic amount number as the lines already have, and then work on some way of identifying the selected stop and pass that on to the window.
I just need to be able to alter the correct consist order, would there perhaps be a dummy consist order that the line can fill out and then give to the convoys being attached to the line?

ACarlotti

Quote from: jamespetts on September 05, 2018, 09:10:34 PMcoupling and uncoupling is (implicitly) done
Ah, I think this might conflict with the understanding I had following the discussion of routing. Although perhaps the answer is that there are two different types of consist changes:
1) Adding/removing loose empty vehicles to a train - this I think can be done in the manner you describe.
2) Coupling/uncoupling loaded vehicles - for the sake of being able to route passengers/goods over such connections, I think this would need to be an explicit join/split command involving two different schedules (i.e. one schedule merging into or splitting of another 'through' schedule).

I cannot remember right now any reasons for requiring option 1 that cannot be done using option 2, and I feel the latter might require less change to the relation between vehicles and convoys and on-track locations. But I'm probably forgetting some detail.

Quote from: Ves on September 05, 2018, 11:01:44 PMThe important decision is what cars are being dropped if, not all the cars that should continue further.
This is where the route-by-contents option that I described in the path-explorer thread would probably be particularly useful.

jamespetts

Looking back at the other thread, I do not think that we ever actually concluded the discussion of the routing by contents idea. The last post about the function of the feature (rather than its UI) appears to be my post to this effect,

QuoteA system for loading wagons/carriages based on where they end up would be optimum, but the current plans for the convoy re-combination feature will not allow a simple determination of which specific vehicle will go to which specific portion, given that: (1) the vehicles to form each new portion are specified in consist orders; (2) the consist orders choose which vehicles to add on the basis of a list of various factors in order of priority; and (3) if there are any loose vehicles to be added, it is practically indeterministic (given that one would need to know where any other vehicle on the network is at any given time in the future to work this out) which other vehicles might be available for coupling in priority over those in the current train.

There was no substantive reply to this. The data structures were then implemented on the basis of the original plan as there was no solution to this issue presented.

As stated previously, the consist orders comprise only a description of the makeup of the convoy after recombination. Couple/uncouple commands are part of the schedule, not the consist order.

To answer Ves's questions - the either/or choices are intended to be implemented by the feature of having stackable vehicle slots as discussed above. As to whether a convoy should be allowed to disintegrate entirely - that may raise complex issues with routing, so the GUI should be capable of disabling this capability if this is found to be unworkable.

Incidentally, the window need not always start blank. There is no harm in starting in some cases with a default consist makeup based on one of the consists in the current line, which might be easier for players to interpret than a blank window. Indeed, if one were to be very sophisticated, one might have a system for automatically deducing rules or having stacked slots to describe any of the consists on the line, although this might be a bit difficult to implement.

The lines will not necessarily all have similar convoys; one might, for example, have a consist order providing that locomotive type A should be at the front of the convoy, stacked with locomotive type B. A being at the top of the stack would be the priority; but there might not be enough of type A in service to attach all to the convoy, so sometimes type B might end up being used instead.

In terms of the consist orders, there is no idea of choosing a "correct" wagon to detach (or, indeed, choosing a particular wagon to detach at all). The idea is that the consist order represents only a description of the vehicle types that make up the consist after the application of the consist order. The individual vehicles (as distinct to the vehicle types and numbers of each) are not distinguished. The idea is that goods/passengers will have to re-arrange themselves automatically on the train to be in the correct portion for their destinations at the time of execution of the consist order. This represents a probably necessary simplification of reality to constrain what might otherwise be chaos level of complexity which would make it impossible to code any workable algorithm.

I hope that this answers the necessary questions - please let me know if anything remains unclear.
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

Quote from: jamespetts on September 06, 2018, 11:07:07 PM
To answer Ves's questions - the either/or choices are intended to be implemented by the feature of having stackable vehicle slots as discussed above. As to whether a convoy should be allowed to disintegrate entirely - that may raise complex issues with routing, so the GUI should be capable of disabling this capability if this is found to be unworkable.
Ok.

Quote
Incidentally, the window need not always start blank. There is no harm in starting in some cases with a default consist makeup based on one of the consists in the current line, which might be easier for players to interpret than a blank window. Indeed, if one were to be very sophisticated, one might have a system for automatically deducing rules or having stacked slots to describe any of the consists on the line, although this might be a bit difficult to implement.
I was thinking the exact same thing!

However, there need to be a default state when there are no vehicles what so ever attached to the line.

Quote
The lines will not necessarily all have similar convoys; one might, for example, have a consist order providing that locomotive type A should be at the front of the convoy, stacked with locomotive type B. A being at the top of the stack would be the priority; but there might not be enough of type A in service to attach all to the convoy, so sometimes type B might end up being used instead.
Yes, I realized that.

Quote
In terms of the consist orders, there is no idea of choosing a "correct" wagon to detach (or, indeed, choosing a particular wagon to detach at all). The idea is that the consist order represents only a description of the vehicle types that make up the consist after the application of the consist order. The individual vehicles (as distinct to the vehicle types and numbers of each) are not distinguished. The idea is that goods/passengers will have to re-arrange themselves automatically on the train to be in the correct portion for their destinations at the time of execution of the consist order. This represents a probably necessary simplification of reality to constrain what might otherwise be chaos level of complexity which would make it impossible to code any workable algorithm.
Dont you think this might raize some issues?
What if there are more good onboard the convoy that needs to be dropped of than the car is big? Say that you picked up a big car full of cargo, but at the drop of point, it is a small car that gets detached. Then all cargo from the big car wont fit into the small car and it will have to be either dropped of at the station, or get carried further away together with the convoy. That could possibly lead to quite some frustration by the player, since that is in some way out of the hands of the player.
And then we are not even talking about all the model railroaders (like me ;D) that are going to follow a particular car from its departure point to its destination. They will notice if it is not the same car that gets attached and then detached. Also in debugging purposes, when the player wants to debug why something doesnt work as expected, they might do that by tracking cars through the network. Then it might be heavily confusing if it is another car that gets detached than the player anticipates.

May I propose a theoretical solution? thanks!  ;D
The good must already know which route through the network it needs to travel. When a vehicle gets loaded with good, could that information not be copied to the vehicle the good loads into? So basicly, when the convoy enters the dropoffpoint, it chooses the cars that fit the description AND has that station in its travel plan.
Or really, it maybe even doesnt have to be copied anywhere: When the convoy lands at a drop off point, it finds the vehicles that fit the missing wildcard description, then goes into each vehicle that fits and check its cargo to find out what station the cargo had found a route through, and then compares it to the station the convoy have just landed in.

Now I dont really know how vehicles get loaded in Simutrans, but would it not be possible to also there check the consist orders and predict which car is to travel the given routes?
For vehicles with no cargo in them, it does indeed not matter in the same way which vehicle gets detached, I think.

I know you wrote that this is extremely complicated stuff to program. This is, however, something that I believe would be worthwhile to resolve in the long run.

ACarlotti

Quote from: jamespetts on September 06, 2018, 11:07:07 PM
Quote from: jamespetts on February 14, 2018, 12:23:03 AMA system for loading wagons/carriages based on where they end up would be optimum, but the current plans for the convoy re-combination feature will not allow a simple determination of which specific vehicle will go to which specific portion, given that: (1) the vehicles to form each new portion are specified in consist orders; (2) the consist orders choose which vehicles to add on the basis of a list of various factors in order of priority; and (3) if there are any loose vehicles to be added, it is practically indeterministic (given that one would need to know where any other vehicle on the network is at any given time in the future to work this out) which other vehicles might be available for coupling in priority over those in the current train.
There was no substantive reply to this. The data structures were then implemented on the basis of the original plan as there was no solution to this issue presented.

Since this was almost seven months ago, I cannot be too sure of my reasons for not responding, but I imagine that I might have been busy at the time, and in any case I thought I had already explained an alternative model. I think I misunderstood your statement as meaning "The current design won't allow this but I could rework the design to solve this" when you actualy intended "The current design won't allow this and I don't see how to solve that - please explain how you might solve it".


I'll attempt to answer that implicit question now (on the basis of 'better late than never).

One key difference between the model that you were envisaging and the model that I was envisaging is that I was envisaging have explicit orders to either (a) join with another scheduled convoy, (b) divide to form another scheduled convoy, (c) attach loose vehicles, or (d) detach loose vehicles. On this basis, as I described in the thread above, it is possible to work out deterministically which schedule any vehicles will end up over a period of time until they have encountered an event of type (a) or (c) followed by an event of type (b) or (d). (With some exceptions if both routing by contents and dividing according to a vehicle types both applied to the schedule).

I remain convinced that this sort of model is superior for several reasons:
1) It is (as far as I can see) more deterministic. There is less scope for loose vehicles to accidentally interfere with the make-up of a consist, and this issue can be avoided altogether if players are only splitting/joining scheduled convoys.
2) It allows for better control of which vehicles actually go to which locations (assuming that consist orders for dividing are able to preferentially detach segments from the front or rear of the train instead of using a random mixture of vehicles, which seems like a reasonable thing to assume).
3) Due to (2), this allows for better simulation of the time taken to join/divide or shunt, and in particualr to differentiate between the case of two EMU units dividing into two separate trains, and a mixed goods train shunting for a long period to split a train appropriately.
4) Due to (2), it is also possible to more accurately simulate transfer times for passengers/goods that can remain in the same vehicle throughout, compared with those who have to move between different vehicles during their journey, for one reason or another.

I am also yet to be convinced (or was convinced ages ago and subsequently forgot why) of the need for loose vehicles. It seems to me that that might introduce more issues with modifying the code to support vehicles that aren't art of scheduled convoys, and removes any control of where loose vehicles end up (which may be semi-realistic in some cases, but probably not in all cases).


Quote from: jamespetts on September 06, 2018, 11:07:07 PMThis represents a probably necessary simplification of reality to constrain what might otherwise be chaos level of complexity which would make it impossible to code any workable algorithm.
I don't think the ccomplexity is as bad as you see it. Sure, if players make particularly complicated schedules then it will become difficult to work out where vehicles will go to. But with this level of complexity it would also be difficult for passengers/goods to board the correct vehicle immediately in real life. I don't think it is unreasonable to penalise layers with lengthy loading times due to being unable to solve this complexity because (at least with explicit join/divide orders instead of generic reassemble orders) the lack of solution only arises after several layers of joins and divides. On the other hand, in most reasonable cases we could also reward players for providing direct through connections on individual vehicle by reducing the loading/unloading time required at each station. You seem to be just giving up on this benefit because you don't see it as a (partially) solvable problem in the way that I do.


It is clear to me that more discussion was and is needed about how best to model convoy reassembly. I think we both either failed to notice or failed to further investigate the differences in our points of view following the conversation back in February. I still feel that there are substantial benefits to my proposed model (or at least, the model I had in mind that I attempted to propose), while the only benefits I am currently aware of for your model are that you have already started implementing the requried data structures in code.

I think a good question for me to start with is: What do you see your model being able to do (of benefit) that you don't think mine can? Perhaps we do not yet have the mutual understanding to answer that sort of question, but we can at least try.

(Incidentally, I believe we live within a few of hours of each other - you can probably verify this more easily than me. If we continue to fail to reach a mutual understanding of this rather complex issue via the forum, then perhaps an attempt to do so in person could be more fruitful.)

jamespetts

Thank you both for your replies. There seem perhaps to be some misunderstandings, and it is useful that these have been identified relatively early: if we can avoid errors or devise a more workable system, this would be helpful.

Ves - the problem that I envisage with what you imagine is that the consist orders alone do not determine which specific vehicles are detached/attached at a particular schedule point: it is the consist orders plus what vehicles are available at the schedule point in question. Thus, it is possible to have a consist order that means that a particular vehicle in a convoy might only be detached if a vehicle of a description higher in the stack is present at the schedule point in question. If no such vehicle is present, the vehicle in the convoy might remain attached. Thus, the only way of knowing which specific vehicles will detach is to know where every vehicle in the network will be at the moment that the consist order is executed, which is obviously unworkable.

In terms of what happens if there is not enough space in the remaining vehicles: the only workable solution that I can think of is to unload the excess at the transfer station.

A. Carlotti - my apologies for the misunderstanding - I did indeed intend the second of the meanings: there not being a reply meant that there was no solution to this issue apparent. A question if I may regarding the difference in the model that you imagine and the model that I had designed: the first sentence of the description is, I think, missing a noun which is critical for the understanding of what you mean: what precisely had you envisaged would be the thing that would have explicit orders to join/detach/etc.? The system that I had planned and the data structures for which I had implemented already envisaged a system in which couple and uncouple are orders in a schedule entry for a specific stop: what had you imagined to be different to this?

Do you imagine that the consist orders would, instead of describing the end state of the consist after shunting, contain orders of the sort "detach vehicle X; attach vehicles Y and Z"? I had purposely avoided that because it requires the players to be able to work out far more precisely what vehicles will be where at what times in order to do this, and also makes it much harder to introduce abstraction: if there is a general rule that allows vehicles V, W, or X to attach at station 1, a "detach vehicle X" command at station 2 is problematic if vehicles V or W are attached (and a "detach vehicle V, W or X" command is also problematic if the consist already contained several examples of V and W at station 1).

As to loose vehicles, this is necessary simply because it is necessary to simulate vehicles in a depot or at a station that do not have any schedule assigned to them but are waiting to be picked up by a convoy that does have a schedule attached to it. Imagine a pick-up goods train, for example: a pair of cattle wagons at a country station being loaded with a few cows ready for their trip to the market town is not a train that has a schedule of its own.

Does this clarify matters?
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.

ACarlotti

Quote from: jamespetts on September 09, 2018, 01:26:14 PM
Thus, it is possible to have a consist order that means that a particular vehicle in a convoy might only be detached if a vehicle of a description higher in the stack is present at the schedule point in question. If no such vehicle is present, the vehicle in the convoy might remain attached.
I think this would be unhelpful for vehicles carrying a load - if you've already loaded up your coal wagons you're not going to shift the coal around just because you've found a slightly better coal wagon you could use. I can see the value in doing this for locomotives, and perhaps also for empty vehicles. However, an alternative model for doing this would be to have the vehicles detached and then, if no better vehicles were available, reattaching the same vehicles again. This would mean that such exchanges only happen when the player explicitly allows this in writing the schedule(s). In the case that there is no (or reduced) net change to the consist during the stop, it should be possible to determine that no shunting was actually necessary and reduce the shunting/waiting time accordingly.

Quote
In terms of what happens if there is not enough space in the remaining vehicles: the only workable solution that I can think of is to unload the excess at the transfer station.
Agreed. Though we should try to design the system such that this scenario can be avoided as much as is reasonably possible.

Quote
A. Carlotti - my apologies for the misunderstanding - I did indeed intend the second of the meanings: there not being a reply meant that there was no solution to this issue apparent. A question if I may regarding the difference in the model that you imagine and the model that I had designed: the first sentence of the description is, I think, missing a noun which is critical for the understanding of what you mean: what precisely had you envisaged would be the thing that would have explicit orders to join/detach/etc.?
Quote from: ACarlotti on September 07, 2018, 06:32:14 AMCorrection: I was envisaging (convoy) schedule entries having explicit orders to ...

Quote
The system that I had planned and the data structures for which I had implemented already envisaged a system in which couple and uncouple are orders in a schedule entry for a specific stop: what had you imagined to be different to this?
I'm having difficulty undertanding how this can be consistent with what you wrote previously:
Quote from: jamespetts on September 05, 2018, 09:10:34 PMThere is thus no explicit couple/uncouple in the consist order itself: what, if any, coupling and uncoupling is (implicitly) done will depend on the extent to which whatever the current consist makeup happens to be differs from whatever is specified as the post-shunting consist makeup in the consist order.
From this I gained the impression that vehicles could be both detached and attached due to a single consist order (and associated schedule entry). On the other hand, for my model I suggest that each schedule entry should permit at most one coupling or decoupling operation.

Quote
Do you imagine that the consist orders would, instead of describing the end state of the consist after shunting, contain orders of the sort "detach vehicle X; attach vehicles Y and Z"? I had purposely avoided that because it requires the players to be able to work out far more precisely what vehicles will be where at what times in order to do this, and also makes it much harder to introduce abstraction: if there is a general rule that allows vehicles V, W, or X to attach at station 1, a "detach vehicle X" command at station 2 is problematic if vehicles V or W are attached (and a "detach vehicle V, W or X" command is also problematic if the consist already contained several examples of V and W at station 1).
I imagine that consist orders could be used to specify (however loosely or precisely is desired) the makeup of the two portions result for an uncoupling operation (where the second portion could, depending on interpretation, form either a new convoy or a collection of loose vehicles). So if the vehicles to be set down are known then these can be specified and the remaining convoy left unspecified in the consist order; conversely if we don't know what consist we have but we know what we want to have going forward, then the consist order would specify the desired convoy and leave the detached portion unspecified. To ensure that the correct vehicles (if there are equivalent ones present) are detached, I imagine consist orders being able to specify that vehicles are chosen according to their position in the convoy (e.g. for EMUs detaching) or according to their load (e.g. for a mixed goods train arriving at a junction and splitting to multiple schedules).

Quote
As to loose vehicles, this is necessary simply because it is necessary to simulate vehicles in a depot or at a station that do not have any schedule assigned to them but are waiting to be picked up by a convoy that does have a schedule attached to it. Imagine a pick-up goods train, for example: a pair of cattle wagons at a country station being loaded with a few cows ready for their trip to the market town is not a train that has a schedule of its own.
If the cows are already being loaded, then it must be known that the wagons will be travelling towards a particular destination (or to some intermeiate transfer point). I don't think this can be known if they are loose vehicles with no schedule. The way I would imagine this scenario to work is that there is a schedule which consists of a convoy of vehicles which have been loaded and are waiting to join a mixed train. The mixed train, upon arrival at the station, could then join with that convoy of cow wagons, and then detach any that are necessary to remain within weight/length limits ... ah but that won't work with my plan of having all detach events at a stop preceding all join events with a consist order for the join event which specifies some maximum properties of the resulting train; if not all wagons can be joined, then the remaining ones will continue waiting at the station as part of their original convoy/schedule. It may also be useful to incorporate routing by contents functionality here so that loaded vehicles are only attached to trains heading in a suitable direction, without the player having to work out suitable (initial) routes in advance.

Quote
Does this clarify matters?
I think it's too early to say. But I hope these are the beginnings of progress.

jamespetts

I suspect that there may still be some misunderstandings, especially regarding the nature of schedule entries as against consist orders and the function of loose vehicles (which I had perhaps defined too narrowly in my previous post).

First of all, there is an important difference between a datum in a schedule entry and a consist order: a datum (such as "uncouple") in a schedule entry is a generic datum that applies to the whole train. It is just a single bit of data: a boolean flag. It specifies that the train should do some uncoupling at the stop, but no more. As discussed earlier in the thread, it is important for the schedule itself to remain a lightweight structure, as it is copied by value frequently.

This is why consist orders are an adjunct to, but not actually part of, the schedule. Consist orders consist of vehicle-specific instructions. The data structure that I have written is simply an ordered list of ordered lists of either vehicle types or rules about what vehicle types to choose. For example, a consist order might be:

1.
(a) LNER A3 class; or
(b) LNER A4 class;
2.
(a) LNER A3 class tender; or
(b) LNER A4 class tender;
3. Third class passenger carriage of at least 110 comfort and 160km/h maximum speed;
4. Third class passenger carriage of at least 110 comfort, 160km/h maximum speed and a minimum payload of 64 passengers;
...
7. LNER restaurant car;
8. First class passenger carriage of at least 110 comfort and 160km/h maximum speed;
...
9. LNER mail carriage;
10. LNER full brake.

The idea is that the algorithm would then automatically work out what train to form and what order to put the vehicles in based on what is available, what is already in the train, and what can couple to what in what order. The first carriage, for example, might therefore be a brake ended carriage, whereas the subsequent carriages would not be (and this could be enforced with the minimum payload, as specified here).

The principle behind this system is that the player does not have to think about exactly how the vehicles will be ordered and arranged; as much of this as possible will be automated. The player can make higher level, more abstract decisions.

Thus, there is a general (one bit) uncouple command in a schedule entry applying to a whole train; but there are no (vehicle specific) couple/uncouple commands in the consist order.

As a result of this, which specific vehicle will be added or removed at which specific stop is not realistically determinable before the consist order command is executed, as, because the data stored are at a high level of abstraction, this depends on many contingent matters.

As to loose vehicles - these are not just (as I perhaps mistakenly stated earlier) for loading vehicles, but for vehicles in some degree of short term storage - vehicles which may be required for any passing train of a sort that requires them. Again, the idea is that players should not have to plan meticulously precisely which vehicle will be where at what time in order to make their schedules work: it should be possible for vehicle combinations to be a complex emergent property of the state of the network, whether previous trains are running on time, whether new vehicles introduced recently have reached a particular point on the network, whether more than usual existing vehicles are in for maintenance and so forth. I also envisage one day being able to add logic to allow players to have the consist order automatically change the number of vehicles in a train based on things like the number of passengers waiting at the current or next stop for this particular service (as was often done in reality).

In relation to cows, the idea for this (I cannot recall whether or not this was discussed above) was that it would be assumed that some railway company operative had planned things and knew that the wagon in question would be joined to the particular train, and the loading time back calculated to the latest of the arrival of the cows and the arrival of the wagon to determine how much, if any, waiting time remained.

Does this make the intentions any clearer?
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

I think that I understand the basics of what you want James, not that I understand it at the code base level that you and ACarlotti is discussing.

But I got cought by this comment of yours:
QuoteAs a result of this, which specific vehicle will be added or removed at which specific stop is not realistically determinable before the consist order command is executed, as, because the data stored are at a high level of abstraction, this depends on many contingent matters.

To rephrase it, you are saying that no one, even not the game itself, knows what vehicle will be the one to be uncoupled until at the immediate point the convoy is at the station and the consist order is looked up. I higly anticipate that instead there is some algorithm that will interpret the consist order, deciding which vehicle fits the missing description best and then excecute the uncoupling of that vehicle.
What I am wondering is, why it would be so difficult to look into its cargo hold and take information from the cargo? The specific convoy excecuting the consist order must be known to the consist order. The station where the order is excecuted must also be known.

The cargo information could be used along in the algorithm to decide what vehicles to detach. Hopefully that would mean that you never would have the issue with leaving good at the station, which I would find quite frustrating. First of all principally, but also what if the station has no cargo capacity? If the player eventually get the ability to select what stations to load at, the player might decide never to be able to load at transfer stations, but if alot of good is unloaded there because the wrong car is detached, then troubble would appear.

jamespetts

Quote from: Ves on September 18, 2018, 10:40:33 PM
I think that I understand the basics of what you want James, not that I understand it at the code base level that you and ACarlotti is discussing.

But I got cought by this comment of yours:
To rephrase it, you are saying that no one, even not the game itself, knows what vehicle will be the one to be uncoupled until at the immediate point the convoy is at the station and the consist order is looked up. I higly anticipate that instead there is some algorithm that will interpret the consist order, deciding which vehicle fits the missing description best and then excecute the uncoupling of that vehicle.

That is, in general terms, the idea.

Quote
What I am wondering is, why it would be so difficult to look into its cargo hold and take information from the cargo? The specific convoy excecuting the consist order must be known to the consist order. The station where the order is excecuted must also be known.

The cargo information could be used along in the algorithm to decide what vehicles to detach. Hopefully that would mean that you never would have the issue with leaving good at the station, which I would find quite frustrating. First of all principally, but also what if the station has no cargo capacity? If the player eventually get the ability to select what stations to load at, the player might decide never to be able to load at transfer stations, but if alot of good is unloaded there because the wrong car is detached, then troubble would appear.

I am afraid that I am not entirely following this. Can you elaborate a little on what sort of logic that you had in mind? The difficulty is not that it is hard to distinguish between, for example, one van carrying goods for London and another van carrying goods for Southampton; but rather, when the goods are loaded into any given van, there is no way of knowing whether goods for London should be loaded into the same or a different van than goods for Southampton (or what to do if the only space on which to load goods for Southampton is in a van carrying goods for London), and therefore it is readily possible that any given van might have goods for both Southampton and London, and then the algorithm will separate the vans so that some vans go to London and some go to Southampton. (One might even imagine a more complex situation in which the train would be going to both London and Southampton, but some vans detach at Southampton and continue to Brighton instead of London, in which case, it is acceptable to load London goods and Southampton goods in the same van provided that it is not one of the vans going to Brighton - but there is no way of knowing at the time of loading which vans will be the ones going to Brighton as this may depend on how many of what sort of loose vans are at Southampton, and possibly, if further logic be added, how many goods need to be loaded at Southampton bound for Brighton).

The idea is that the amount of goods that would be loaded/unloaded would never depend on which specific vehicle is detached: the idea is that the game logic would deal with this entirely automatically, and goods would only be unloaded from the train (as opposed to seamlessly and instantly loaded/unloaded form particular wagons) if there is not enough space in the correct portion of the train.

Does this make sense now?
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

Thanks for the explanation, I agree that principally the most difficult part must be the loading of the good.

However, it should be possible:

I believe the good must know of all existing consist orders, or at least all consist orders that it is supposed to get in contact with during its travel.
I also suppose that good will get a new parameter, something like "intermediate_shunting", so the good knows at what station it is supposed to drop off, but still stay inside a convoy, unlike the existing "intermediate_stop" where the good are supposed to be unloaded in order to be loaded onto another convoy.
Currently it seems like good are loaded into a train from one end, at least cars with freight image seems to load up from one end. There should already be a mechanism in place to load the convoy in specific order.

So the question the good should ask before boarding a vehicle is: does this vehicle fit into each consist order "slot" throughout the jurney of the good? If it doesnt, it should ask the next vehicle.
Principaly, already from within the industry, when the good is attempted to be created, it should check all consist orders and see if there is a particular vehicle that fits all consist order "slots". If none, then the good should not be created.

jamespetts

This is an interesting idea, but the difficulty comes with stacked slots: the vehicle might fit a slot that is not at the top of a stack of slots, and whether or not the vehicle type higher in the stack will be used instead at a given consist order will depend on indeterministic factors as described 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.

Ves

Quote from: jamespetts on September 19, 2018, 10:59:34 AM
This is an interesting idea, but the difficulty comes with stacked slots: the vehicle might fit a slot that is not at the top of a stack of slots, and whether or not the vehicle type higher in the stack will be used instead at a given consist order will depend on indeterministic factors as described above.

I dont understand what you mean with stacked slots. If you talk about wildcard slots, where the player has specified some ability of the vehicle, it should not matter, since this implementation only works if the disassemble algorithm I talked about two posts ago takes the cargo into consideration. In other words, what the cargo desires should be prioritized above whatever ability the player chooses.

As far as I can tell, it should work.

If you talk about wether a player specifies only one vehicle to detach, when in fact there where two vehicles that where supposed to be detached, that would be a player error and responsibility.

jamespetts

I am trying to work out how what you imagine would ultimately work - do you imagine that the stack priorities would not be respected where a specific vehicle in a particular convoy happens to have cargo bound for a destination? This could lead to very unpredictable results, as the ultimate makeup of the consist would then depend, not on the availability of vehicles, but on into which vehicles that cargo had happened to have been loaded. Imagine a train with high speed goods vans and low speed goods vans travelling along a branch line, being remarshalled into a train with preferably all high speed goods vans when it gets to the junction and carries on up the main line, but which is allowed to continue with low speed goods vans if there are not enough high speed goods vans available. If cargo bound for a destination along the mainline had been loaded into one of the low speed goods vans somewhere along the branch line, then with what I understand of the system that you propose, the low speed goods vans would be retained in the train whether or not the higher speed goods vans were available at the junction - is that correct?

Incidentally, it may well not be possible to ensure that the goods for the main line destinations are loaded onto the high speed goods vans on the branch line, as goods for other destinations on the branch line or at the junction station may completely fill up the high speed goods vans earlier, before the goods for the main line destination come to be loaded.
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

Quote from: jamespetts on September 19, 2018, 01:12:05 PM
I am trying to work out how what you imagine would ultimately work - do you imagine that the stack priorities would not be respected where a specific vehicle in a particular convoy happens to have cargo bound for a destination?
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.

Quote
This could lead to very unpredictable results, as the ultimate makeup of the consist would then depend, not on the availability of vehicles, but on into which vehicles that cargo had happened to have been loaded. Imagine a train with high speed goods vans and low speed goods vans travelling along a branch line, being remarshalled into a train with preferably all high speed goods vans when it gets to the junction and carries on up the main line, but which is allowed to continue with low speed goods vans if there are not enough high speed goods vans available. If cargo bound for a destination along the mainline had been loaded into one of the low speed goods vans somewhere along the branch line, then with what I understand of the system that you propose, the low speed goods vans would be retained in the train whether or not the higher speed goods vans were available at the junction - is that correct?
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.
Following your example, no it would still be the high speed cars that gets attached, leaving the loaded slow good cars behind. The player would have to design the network to make sure that the slow speed vehicles also would have a chance to get onto the mainline.


Quote
Incidentally, it may well not be possible to ensure that the goods for the main line destinations are loaded onto the high speed goods vans on the branch line, as goods for other destinations on the branch line or at the junction station may completely fill up the high speed goods vans earlier, before the goods for the main line destination come to be loaded.
But that is a player layout design, and bad vehicle management if empty cars get excess travel.