News:

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

[Project] Convoy Coupling Feature

Started by THLeaderH, June 24, 2019, 10:58:17 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

THLeaderH

Hello, everyone.

I've written the code of the convoy coupling feature for almost half a year. In this project, convoys can couple and uncouple with other convoy. The demo video shows how to set the schedule and how the convoys behave.


Since coding is unfinished, I do not submit the patch on this forum yet. However, you can get my WIP code from my CUCP branch.

Convoy coupling is popular in Japan because it has some advantages.

  • The capacity of a train can be increased only in congested district by coupling an auxiliary convoy.
  • It is possible to provide direct access to a branch line without transfer.
  • Platform length in vacant section does not have to be too long.
There has been a lot of requests for convoy coupling in Japanese simutrans community.

This project realizes convoy coupling, not disassembling of trains. In my opinion, there are three levels in convoy coupling.

  • Increasing or decreasing convoy length outside depots. e.g.) Adding 5-cars length auxiliary convoy to 10-cars length convoy at a station.
  • Coupling convoys which have different destinations. e.g.) Convoy α's destination is station A, and Convoy β's destination is station B. α and β go together between station C and station D.
  • Disassembling and reassembling of trains outside depots. e.g.) switching yard station.
In my convoy coupling project, level 1 and 2 are possible, but level 3 is impossible. Implementing level 3 can be too complicated, but level 2 can be simple enough.

Let me define "parent convoy" and "child convoy". At coupling point, the parent convoy waits for the child convoy to couple with. The parent convoy arrives first at the coupling point, and the child convoy arrives there later. Parent convoys always go front, and children follows back. A parent convoy can have only one child, but a child can be the parent of other convoy. For example, convoy A is the parent of convoy B, convoy B is the child of convoy A and the parent of convoy C, and convoy C is the child of convoy B. As a result, convoy A, B, and C go together. This enables coupling of more than two convoys.

When you schedule convoy coupling, first, you define the schedule of parent convoy as usual. Coupling section is specified in the child convoy schedule. You can set coupling section using dedicated dialogue as it is described in the demo video.
When a parent convoy arrives at the coupling station, the parent waits for the child convoy. Then, the child faces a signal in front of the coupling station. Normal block_reserver() fails because there are parent convoy in the next section, but the child knows that the next stations is coupling point. The child checks whether there is a parent convoy. If so, the child enters the section and couples with the parent convoy. Once they are coupled, the parent convoy controls movement and loading of the child convoy. After arriving at uncoupling point, the parent releases the child, and they move separately again.

The implementation is roughly done except for the schedule validation in the line schedule window. If you're interested in this project, please compile the code of my CUCP branch and have a try 8)

Leartin

This seems quite complicated for the player. I think there would be a way to achieve something similar to this by using logic easier to understand to the player, albeit it's probably a lot more work in the backend.

1) Remove binary platform occupation. If there is enough space in a station to fit the full train, that train should be allowed to enter, even if part of the station is already occupied by a different train.
2) Whenever two trains are in the same platform, have the same next destination, and that next destination has a platform long enough to hold both at once, couple them until they reach the next station.
3) Use time-based schedules to make trains wait for each other. At best, have a "wait for any other train" with time limit.

The way your coupling works, I would be worried for deadlocks.
For example, what happens to the child if it arrives at the coupling point, but there is no parent to pick it up yet? What happens if there are other trains on the line, and one of them blocks the child from entering the platform, while being blocked by the parent on the platform, which is waiting for the child? What if you had three rural lines and you wanted to combine any two of them bevor they enter a busier section, how could you do it? It all would have to be planned were meticulously, and any mistake may have grave consequence, so it would only ever be possible to be used in a "model railway" game, not in a "normally growing" game.

Probably the way I suggest it is too hard to implement or something, so let's just go with "Perhaps you could make this system more flexible?"

Ters

I don't think I've ever encountered this concept, although it makes sense under certain circumstances. The closest I have encountered are that cars are added and removed as the train moves along.

For passenger trains, this is no longer done, as it is too expensive to hook up single cars (screw couplers). It is better to just have all the necessary cars for the entire journey. Multiple-units might connect easier, but I don't think that is done either. That might be because the only places multiple-unit lines converge also have better capacity on the merged side. The one exception is very short, so they are rather looking into increasing track capacity. The fact that every line may soon be run by different companies won't make it more likely that merging trains may happen.

For freight, this is now only done for of merging of trains, sort of like this feature, but one locomotive is generally left behind and it is always because they have the same destination. The train isn't split back up until the return journey. In some cases, the locomotive might be kept after merging, but turned off to save costs (or it is just hitching a ride to a depot for routine maintenance), or relocated if both really are needed (freight trains, which apparently do not have multiple control cables through them).

ACarlotti

It is quite common in the UK for trains serving London to split to serve multiple routes away from London. This is because most of the mainline approaches to London terminal stations have little or no spare capacity. Some trains also split without serving multiple routes, either because many of the more rural stations near the end of the route aren't big enough for a full length train, or there is not as much demand, making it more efficient to use the limited stock of multiple units at the London end of the route as much as possible. I think in almost all cases these are multiple units, although you could join two separate push-pull trains in the same way. (One exception to this is the sleeper trains - there are two services departing London towards Scotland, which divide into a total of five services in Scotland.)

Quote from: Leartin on June 24, 2019, 02:43:41 PM1) Remove binary platform occupation. If there is enough space in a station to fit the full train, that train should be allowed to enter, even if part of the station is already occupied by a different train.
There are some issues with that - what if one train needs to overtake the over? Or it's a terminal station, and the one already there needs to depart first?

DrSuperGood

Outside of model railway cosmetics I do not see this feature being used much.

That sort of line configuration is discouraged if one intends to maximize profit. Additionally it is very prone to causing 1 of the lines to stall since it will have to wait for the orther to progress.

Extended, where such mechanics make more sense, will eventually receive its own version of this feature but implemented in a different way.

Matthew

This patch looks like it might make a great new feature for Simutrans. Thank you THLeaderH! I can definitely think of places in my network where it could be used. For example, a long, thin (low-density) 'tail' at the end of a busy main line, where it might make sense for the small rural train to be joined to a bigger unit once it reaches the 'terminus' of the busy main line, without messing up the mainline scheduling.

However, I only play Extended, where the hard-working coding team (ACarlotti, DrSuperGood, Ves, wlindley, and of course James Petts) have already started work on an alternative implementation that can also handle Level 3 switching.

Maybe there is some way for these two branches to fruitfully 'pollinate' one another's work???  :question:
(Signature being tested) If you enjoy playing Simutrans, then you might also enjoy watching Japan Railway Journal
Available in English and simplified Chinese
如果您喜欢玩Simutrans的话,那么说不定就想看《日本铁路之旅》(英语也有简体中文字幕)。

jamespetts

This is very interesting. As has been pointed out earlier, there is a more in-depth version in development for Extended that deals with what is described here as level 3 functionality, but, as this is a large project, it is likely to be a while before this is implemented.

This is evidently aimed at Standard; I have not played Standard for some considerable time, so I cannot say whether this functionality (as limited here) would be useful in an economic sense for players of Standard, but I am aware that this feature in particular is likely to be very much in demand from Japenese Simutrans players.

What is done here is very different to the planned implementation in Extended, so I suspect that there is not much scope for re-using this code there, but it is interesting to see people work on this feature. I note in particular the amount of work that has evidently gone into this, the video having been uploaded in February, and commits having been made periodically since then.
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.

Ters

Quote from: DrSuperGood on June 24, 2019, 06:04:17 PMThat sort of line configuration is discouraged if one intends to maximize profit. Additionally it is very prone to causing 1 of the lines to stall since it will have to wait for the orther to progress.
If it wasn't for the second part, I don't see why this won't help increase profits. It would lead to more trains per track. Most payment modes don't care how much you detour through other stations (as long as you stop at them), and none care how long it takes.

THLeaderH

Quote from: Leartin on June 24, 2019, 02:43:41 PM
The way your coupling works, I would be worried for deadlocks.
For example, what happens to the child if it arrives at the coupling point, but there is no parent to pick it up yet? What happens if there are other trains on the line, and one of them blocks the child from entering the platform, while being blocked by the parent on the platform, which is waiting for the child? What if you had three rural lines and you wanted to combine any two of them bevor they enter a busier section, how could you do it? It all would have to be planned were meticulously, and any mistake may have grave consequence, so it would only ever be possible to be used in a "model railway" game, not in a "normally growing" game.
If a child arrived earlier than the parent, the child ignores coupling and goes forward as single convoy. In this case, the parent which arrives late waits for the next child convoy. With max_waiting_time_for_coupling, the parent departs solely if the child does not arrive for some duration. So, this situation itself does not cause a permanent deadlock.
However, this greatly reduces line capacity and ruins advantages of convoy coupling. Thus, ensuring that the parent arrives at the coupling point earlier than the child is quite important. There are two possible way for this. First is controlling train order precisely with time scheduling. This is why I posted the time scheduling patch on this forum before. Although this is an approach that is taken in the real world, I do not think this is suitable for simutrans because it needs very careful and precise time scheduling merely to do a convoy coupling. Second is controlling train order with signals. In my current implementation, choose signals have a role on this. A choose signal have an option "Require parent convoy to enter". If a child convoy tries to pass a choose signal with this option, the child convoy finds a platform where a parent convoy waits. If there are no platform where a parent exists, the child wait before the choose signal until a parent arrives. If the choose signal with this option is built before the truck merging point, it ensures that the parent arrives at the platform earlier than the child. Of course, other signals than choose signals can do the similar things, but what is important is that this method does not require any careful and precise time scheduling. Just putting a signal is enough.

THLeaderH

I learned from Leartin's suggestion and totally remade the schedule settings method of convoy coupling. A new version of convoy coupling demo video is uploaded.


To set a coupling schedule, check "Wait for child" option in the parent convoy's coupling point, and check "Find parent" option in the child convoy's coupling point. A parent convoy waits for a child at a stop with "Wait for child" option. A child tries to find a parent convoy at a stop with "Find parent" option. You do not have to specify uncoupling point because a parent convoy automatically releases its child under the following conditions.

  • schedule entry mismatch between a parent and a child.
  • insufficient platform length of the next stop.
Therefore, the platform length must be sufficient for entire coupling convoys and schedule entries must be exactly same in the coupling section.

"Require parent convoy to enter" option for choose signals works as it was in the previous version.

Coding is still unfinished. I'm working on implementing some corner cases.

Isaac Eiland-Hall

This is really cool. I don't know about the economic side of things, but as generally a -freeplay player (I derive joy from trying to transport every passenger or good in a timely manner), this seems like it would be helpful for busy corridors. Also, it's just flat-out awesome. :)

An_dz

Very nice and the UI is somewhat simple. But I have some questions:

1. What would happen if no parent or child exists in the schedule?

2. What would happen if I disable the "Wait for parent" checkbox in the signal?

3. How is the behaviour of maximum waiting time if they differ between parent and child?

4. How is the behaviour of minimum load? Does it check for the whole convoy or each for their own?

And the schedule list UI could add something to let the user know the train will wait for a child or parent at that point, but that can wait for when the code is more mature.

THLeaderH

Quote from: An_dz on June 28, 2019, 06:19:53 AM
Very nice and the UI is somewhat simple. But I have some questions:

1. What would happen if no parent or child exists in the schedule?

2. What would happen if I disable the "Wait for parent" checkbox in the signal?

3. How is the behaviour of maximum waiting time if they differ between parent and child?

4. How is the behaviour of minimum load? Does it check for the whole convoy or each for their own?

And the schedule list UI could add something to let the user know the train will wait for a child or parent at that point, but that can wait for when the code is more mature.

Thank you for your interest.

1. If only "Wait for child" is set for parent and there is no child convoy, the parent convoy keeps waiting at the coupling point. If only "Find parent" is set for parent and there is no parent convoy, the child convoy stops and departs the coupling point as usual, except for the case that there is a choose signal with "Require parent convoy to enter" option. Maximum coupling waiting time for parent convoys is the maximum waiting time of the schedule entry.

2. When a child convoy passes a choose signal whose checkbox is disabled, the convoy tries to find a waiting parent convoy. If the child can find the parent, the child enters the platform where the parent is waiting and does coupling. If the child cannot find the parent, the child chooses one vacant platform and enters. In this case, the child does not couple with other convoy.

3. The difference of maximum waiting time and minimum loading amount between parent and child results in uncoupling. This uncoupling condition can be useful to uncouple convoys intentionally.

4. Minimum load is applied for each convoy. A coupled train departs after all convoys satisfy the minimum load condition.

Leartin

When boarding a train, those pax which go to the nearest station enter first, then those for the next nearest station, and so on.
How does that work with coupled trains - how are those pax distributed?

I think ideally, you'd want to have a look at the stations after the trains decouple for where to place the pax for shared stations.
1.) Get the available space in the coupled convoi in a variable.
2.) For each shared station, reduce that variable by the number of pax waiting for it.
2b) If the variable becomes lower than 0, abort. It does not matter which part of the coupled convoi gets boarded, fill it randomly*
3) Once you run out of shared stations, look at the stations after that on both routes. Fill the pax to those stations in the appropriate part of the convoi, but in total no more than your variable indicates. Once you reach that number, go to the next step.
4) Go back and fill the pax for the shared stations randomly*.
*randomly is not meant to be with RNG, more like "whatever is convenient"

Example: You have two trains "toD" and "toF" coupled together in station A. They will go together to B, then toD splits off for C and D, while toF goes to E and F. Both have a capacity of 50pax, the train is empty. There are 30 people waiting for each station.
1) The available space in the coupled convoi is 100
2) There are 30 pax going to shared B, so reduce it to 70
3a) There are 30 pax going to C, so put them in toD. (70-30=40)
3b) There are 30 pax going to E, so put them in toE. (40-30=10)
3c) There are 30 pax going to D, but only 10 slots left, so put those 10 pax in D.
4) The 30 pax going to B can be filled in now. There are 10 empty slots in toD and 20 empty slots in toE, so those get occupied

Just like the other suggestion, I'm not sure how feasable it is. For the model-railway aspect, it might even be irrelevant. Still, it might play a huge role in how usable this is for gameplay. Certainly, a train waiting on full load, with pax in the station that could use it, but don't, because pax already in the train are using the wrong seats would be quite annoying (albeit realistic)




THLeaderH

#14
There are a lot of desired functions for this project and it is assumed to increase. Implementing all desired functions in a single patch makes the patch huge, unmaintainable, and unable to release. Therefore, I divide the project into several sections and today I submit the first section of the project as a patch. The patch is zipped and attached on this post because the raw patch file exceeds 64KB limit of  the attachments.

The first section contains

  • Schedule setting GUI
  • Convoy coupling process
  • Convoy order control with choose signal ("Require parent convoy to enter" option)
  • Platform length check only when the child passes a choose signal before coupling.

There is a minor change in the uncoupling condition. In the submitted version, only pos difference of the schedule entries results in uncoupling. If the pos is same and loading conditions are different, the coupled convoy lefts the station after the loading conditions are satisfied for all individual convoys.

The next section should contains

  • More sophisticated passenger loading algorithm
  • Coupling with heading convoy
  • Platform length check under more conditions if desired
  • Button in the schedule window to copy schedule from other lines

Bug fixes of first section's feature will be applied to the first section patch. I think the first section itself is playable and does not cause fatal inconvenience even if the future sections are not applied.

THLeaderH

Here are some updates for the patches.

~section1 version2~ (CUCP_r8776_sec1_ver2.patch)

  • FIX: do not destruct when coupling
  • CHG: button texts of the schedule window and convoy info window
  • FIX: recalculate min_top_speed and is_electric after coupling and uncoupling. If at least one convoy is electric, the whole coupling convoy is treated as electric.

~section2 version2~ (CUCP_r8776_sec2_ver2.patch)
Section2 patch is a diff from section1 patch, and section2 patch starts from version2 because sec1_ver2 is submitted. Section2 offers coupling of heading convoy. If the convoy comes in front of the waiting convoy, section2 enables them to couple. In section1, the waiting convoy always becomes a parent, but in section2, the convoy which arrives later can be a parent.
In this version of sec2, there is a problem that the convoy jumps after it couples with the heading convoy like the video of this tweet.
To couple with a convoy that comes from front, the convoy has to stop at the middle of the platform. However, current simutrans forces trains to proceed to the front end of the platform by treating the convoy length 8888 when it searches the route. In the section2 patch, the actual convoy length is passed and trains are allowed to stop at the middle of the platform. Allowing trains to stop at the middle is to be discussed if it is desired, but it is needed for coupling with the convoy which comes from front.

Although section2 makes it possible to couple with the heading convoy, section1 alone works and can be played.

THLeaderH

Quote from: Leartin on July 17, 2019, 02:09:49 PM
But since I mentioned it earlier: How do you feel about completely powerless convois that can only be pulled by another convoi, to simulate a switched loco? I'm pretty sure players would try to do that anyways, perhaps with "invisible" vehicles of veeeery low power, just so a convoi counts as powered even though it behaves like an unpowered one.
This was posted on other thread, but I answer here since this is a completely convoy coupling related question.

I do not object allowing completely powerless convoys. However, the biggest problem is how we can bring the powerless convoy to the coupling point. In my implementation, convoy coupling is combination of convoys, not reassembling of cars. Needless to say, a convoy needs a locomotive to move. Therefore, to allow a powerless convoy, a depot has to provide the way to couple convoys in the depot, but I worry that the depot window becomes too complicated if we do so.

THLeaderH

Thanks to testing by Japanese players, a lot of bugs were found and fixed. I upload a new version of Convoy coupling feature patch. The attached zip file contains both section1 and section2. The changes from the previous version are as follows.

~section 1~

  • FIX: coupled convoy must not be withdrawn
  • FIX: coupled convoy might split when passing choose signal
  • FIX: advance schedule for all coupling convoys when passing waypoints
  • FIX: initialize convoi_t::coupling_convoi
  • ADD: # mark for coupling entries in schedule windows

~section 2~

  • FIX: do not set state LOADING when the convoy is coupled
  • FIX: ease jumping after coupling with heading convoy
  • FIX: clear next_initial_direction after the departure
  • FIX: waiting time of schedule entries does not work 
  • FIX: stop point for coupling might be wrong when the parent convoy has 2 cars

Compared to section 1, section 2 patch adds coupling with a facing convoy. Section 2 still has a problem that convoys might jump after coupling, but the jumping is now less than one tile. Convoy coupling patch works even with section 1 patch alone.

THLeaderH

There are some more bug fixes and I upload version 4 patch here. The attached zip file contains both section1 and section2. The changes from the previous version are as follows.

~section 1~

  • FIX: Inconsistent behavior of coupling when the convoy passes a choose signal.
  • FIX: Top speed might not be properly calculated.
  • FIX: Coupling point cannot be detected when the previous schedule entry is a waypoint. 

~section 2~

  • FIX: Coupling failure with a single vehicle convoy.

Flemmbrav

Nice feature! Love to see this happening.

There are two things i'd like to see improved (r8811 and OTRP v22_3):

- The game crashes when i doubleclick on a vehicle
- Constraints should be enforced still, it's a bit weird to be able to couple things on the tracks i can't couple in the depot, isn't it?

Mariculous

First, I already love this work. I had a simmilar idea, so I found this thread.
However, my idea was a little bit more like Leartins, as I suspect your implementation to be pretty deadlock prone and kind of complicated, as already mentioned.
Additionally  I don't see how lines decoupling parts of the train at both ends of the line are supposed to work. I must admit, this is rare in real life (at least in Germany) but it has its use cases and is for example used at some Rhein-Ruhr Express Lines, where trains use the main  line in double traction.
At either end of the main line, one train will continue, while the other is waiting and will couple with the next train coming in the opposite direction.

When we already get this great feature, this should be possible imho.

However, I don't agree exactly with Leartins point 1 and the "make it all automatic" approach.
Quote
1) Remove binary platform occupation. If there is enough space in a station to fit the full train, that train should be allowed to enter, even if part of the station is already occupied by a different train.
2) Whenever two trains are in the same platform, have the same next destination, and that next destination has a platform long enough to hold both at once, couple them until they reach the next station.

Point 1 is pretty deadlock prone e.g. in case of one short train using a platform as a terminus while the other uses it to pass-throug, this will cause both trains waiting for clearance. The latter should not have entered the platform.
Point 2 is not that critical but it will also be extremely hard to manage, as not all trains have the same travel times at the exact same route due to different accelerations and maximum speeds, which can in some cases make a very huge difference, so we really don't want any automatic train partnership.

I agree with point 3, however, I would not re-implement time schedules in this patch but instead call it a good synergy with the time schedule patch or extendeds time schedule feature.

That being said, based on the implemenatation that can be seeen in the second video, I would suggest the following:
1. By default trains should only enter unoccupied platforms. (I guess this is the case in the implementation but I don't know from the video)

2. Schedules at stations can be explicitly set to "couple with line B" if line B has the same route as line A from that station to at least the next station. Maybe a "couple with anyone" option would also be useful, which will couple with any other train that has "couple with anyone" set at that station and shares the same route for at least one station after that station.

For the reasons given above, I sometimes don't want any other line than the specified line to couple with my train. Aditionally, I guess it is much easyer to set the coupling only once instead of setting the wait for

I will call two trains with such a setup "potentially coupleable trains"
Potentially, because we should check for constraints in that case, not allowing to couple trains that could not be created in the depot [extended only: but reversing one or both trains if neccessary]
I will call two trains "coupleable", if these are potentially coupleable and the constraints match.

If a train with such a "couple" order arrives at the last signal before the station, it will check the following:
- Is there a coupleable train at the set platform and that one is long enough for both?
   start coupling.

Otherwise, if we have a choose signal:
- is there a coupleable train at any other platform that is long enough for both?
   start coupling.

Otherwise (no ccoupleable train found that was at a platform long enough for both at any considered platform):
- use normal signals behavior to enter an unoccupyed station.

Also, I would drop that parent/child thing including the "wait for parent" option at the choose signal, as in most cases it does not matter which train is the first and which one is the last.
If you need this for technical reasons, the first one to enter that station is the parent, while the other one ist the child.
For the few cases where you want to explicitly define a fixed order of trains enterin the platform, you could add something like a "enter second" checkbox to the schedule, in which case the train will wait until there is a coupleable train at the station.

[Extended only: Additionally, as reversing in stations takes some time in extended, coupling should also take a short while]

However, as James mentioned, there will be an other implementation of this for extended.
I really hope its usability will be at least nearly as good as the one of this patch.

Vladki

#21
Automatic joining of trains that happen to share a part of their journey is not something you really want. In real world the (de)coupling takes some time (brake check, MU systems check), sometimes it is easier to send the two trains one after another. So this should be done only when explicitly requested.

fam621

Quote from: THLeaderH on June 27, 2019, 03:17:25 PM
I learned from Leartin's suggestion and totally remade the schedule settings method of convoy coupling. A new version of convoy coupling demo video is uploaded.


To set a coupling schedule, check "Wait for child" option in the parent convoy's coupling point, and check "Find parent" option in the child convoy's coupling point. A parent convoy waits for a child at a stop with "Wait for child" option. A child tries to find a parent convoy at a stop with "Find parent" option. You do not have to specify uncoupling point because a parent convoy automatically releases its child under the following conditions.

  • schedule entry mismatch between a parent and a child.
  • insufficient platform length of the next stop.
Therefore, the platform length must be sufficient for entire coupling convoys and schedule entries must be exactly same in the coupling section.

"Require parent convoy to enter" option for choose signals works as it was in the previous version.

Coding is still unfinished. I'm working on implementing some corner cases.

This is an amazing feature which you are making and I do with to get a chance to use it in Extended. However, my question to you is that, if one train comes before another, is that train just going to wait for the other train at a signal outside of a station and possibly cause delays to trains behind it or will it be able to be cleared into the platform and wait for the other train and thus preventing delays.

Mariculous

#23
From the current description and videos, the parent will wait at the platfirm, while the child will only wait at a signal that is set up for waiting.

That is why I suggested to drop the parent/
child hirarchy and instead add an optimally trinary "wait for other train" option, allowing "don't wait", "wait at platform" or "wait at signal".

fam621

Quote from: Freahk on September 28, 2019, 05:04:07 PM
From the current description and videos, the parent will wait at the platfirm, while the child will only wait at a signal that is set up for waiting.

That is why I suggested to drop the parent/
child hirarchy and instead add an optimally trinary "wait for other train" option, allowing "don't wait", "wait at platform" or "wait at signal".

In future patches could there be the options of either "wait for other train", "wait at signal" or "wait at platform" be possibly implemented?

fam621

Quote from: thegamer7893 on September 28, 2019, 10:23:27 AM
This is an amazing feature which you are making and I do with to get a chance to use it in Extended. However, my question to you is that, if one train comes before another, is that train just going to wait for the other train at a signal outside of a station and possibly cause delays to trains behind it or will it be able to be cleared into the platform and wait for the other train and thus preventing delays.

Any progress since last post?

ASV62

Before watching the coupling in action I don't think it's based on route schedules, and I think of a trainsets group table, which you can define segmented formation into groups, then defines actions for groups.
Based on route schedules making two routes sharing same schedule running in coupled form is quite neat, I assume if trains in Route A can't catch up with the train previously coupled in Route B, it would couple with the next train from Route B anyway.
But based on gameplay situation it'd cause problem, let say route A formations jammed at the coupling stop waiting for route B formation to come, halting the system.
I think some actions should be arranged for that, if there's no route B trains coming, after certain amount of waiting time can Route A depart no matter what, continung the journey with no Route B coupled with it?
and when in coupled situation how train info displays the details of payloads?

People who was born with this kind of lifestyle is an artist, while talents are philosophist ....

Andyh

Apologies in advance for bumping this topic, but it seemed the most appropriate approach.


I have been experimenting with this coupling function in the context of North American style freight operations.  In other words freight cars are picked up and dropped off spurs and sidings along a lengthy single-track route.  I think it's a very exciting functionality that goes way beyond mere "model railways".  Specifically in the North American context it allow for much more realistic, prototypical operations and critically it helps avoid congestion on single-tracks (which predominate in North American railroading).


With some trial and error I have got it to work fairly well in joining two convoys but it runs into major problems when 3 or more are involved.  Maybe the intent was never for the patch to work for more than two convoys but I'm curious as to whether with some tweaks it can be expanded in that direction (or, maybe it already works for 3 or more convoys and I'm doing something wrong.) Here are the main issues:


The biggest issue: when 2 convoys (a main convoy and a sub convoy) are coupled and I try to connect another sub-convoy, the original sub-convoy becomes detached.  At that point it becomes unresponsive to any commands.  The "Go to Depot", "Remove Now" and "Retire" buttons are all grayed out and although the convoy remains on the map it cannot be used at all.


Another problem is that once convoys are combined it is not possible to access its schedule.  This makes it really difficult to sort out problems/conflicts/signaling issues/reservation problems etc.