Transport Tycoon Forums

New thread for shunting/coupling/decoupling feature.

How it works?
Decoupling is done in station, train simply leave some or all of its wagons in station.
Coupling is done in station too. There needs to be train in station waiting for engine. And there needs to be train close to station (max 1 pbs signal far) that is looking for train. The train outside the station will find its way to other train and they will couple.

Plan of development:
Currently working on - Global order list
future - NPF pathfinder, white block signals

Known issues:
NPF is not supported yet.
Block signals are not supported for coupling operation.
Assigning new arbitrary orders for decoupled/coupled trains is not supported yet.
Cargodist is not fully supported yet, it's connected to previous issue with orders.
Autoreplacing and cloning is sometimes not working in reversed state of train.
Timetables for decoupling/coupling need to be fixed.
Breakdown system with vehicle lifespan needs to be reworked.

source code available at github https://github.com/Palo123/OpenTTD-YPS/tree/Decouple

Ooh. This is pretty cool.

Regarding orders for the left-behind part, the best solution I can think of would involve a way to have "orphan" shared orders lists, which you can name. In fact decoupling "routes" from vehicles. (Similar to how it's done in Transport Fever.) When you have a named orders list, you can then insert an additional flag on the decouple order, "other half begins executing orders list B from position Y".

cap'n, my train blew up again

Hubba hubba.

Nice implementation, I like how you can get a locomotive close to the wagons and just have it couple back up. I can see how a patch to change reversing behaviour would compliment this.

Thanks for the update! You might want to put your GitHub address as well: not everybody uses Windows

I've tested your patch again, and I think it's brilliant. It works correctly so far, refusing to decouple those wagons that would change length as a result of being detached from their engine.
Also, I seem to understand you're already checking for attachment rules, and preventing two "uncompatible" consists from coupling? If so, it's really neat.

I've found that your patch works wonderfully together with my own way to do "push-pull" (i.e. swapping the graphics across wagons). It gives a very realistic final result, if not for the wagons changing graphics right upon decoupling and coupling (when they revert back to their default status). To correct for that, we'd need to enhance OTTD itself.


Now, I have a question about something that happened in my game. I sent a train composed by a coupling of 2 MUs to a station, then decoupled it, and ordered its former "head" to go to a depot. Then, I ordered another train of the same type to go pick up the decoupled half of the first, still waiting at the station.
The situation is as it appears on this picture:
* Train 2 is the decoupled half of the initial train; it's patiently waiting at the station;
* Train 3 is just outside of the station and has "Couple Any Train" as its order.

Now, as you can see, the signal in front of Train 3 is red, because Train 2 is waiting at the station. Because of this, Train 3 won't start. However, shouldn't it rather ignore the signal, advance at a low speed, and couple with Train 2? I can't understand why it's waiting instead...
I have to manually force the train to ignore the signal. When I do, Train 3 behaves exactly as it's supposed to: it advances, couples with Train 2, and then drives off.

Perhaps this thing of ignoring the signal should be automated. Would you need me to post a savegame or anything else to help you out with this?

le_harv wrote:Hubba hubba.

Nice implementation, I like how you can get a locomotive close to the wagons and just have it couple back up. I can see how a patch to change reversing behaviour would compliment this.

Reversing can be implemented in a trainset. The one I'm developing does it, and works very well with this patch:

I think he meant like, full train reversing. That'd be quite useful for stitching multiple trains together (there's probably a better term for this).

Snail wrote: Train 3 won't start. However, shouldn't it rather ignore the signal, advance at a low speed, and couple with Train 2? I can't understand why it's waiting instead...

Karn, I have the same problem. Sometimes ignoring the signal works, sometimes the coupling locomotive "waits for free path", without any reason I can see. I´m using all 2-directional path signals for the layout shown in the original thread:

viewtopic.php?p=1208457#p1208457

regards
Michael

Drury wrote:cap'n, my train blew up again

Interesting bug, thanks for reporting.
Btw you can save the train by stopping and starting or reversing locomotive before coupling
Edit: nvm, it's fixed now

Snail wrote: * Train 2 is the decoupled half of the initial train; it's patiently waiting at the station;
* Train 3 is just outside of the station and has "Couple Any Train" as its order.

Now, as you can see, the signal in front of Train 3 is red, because Train 2 is waiting at the station. Because of this, Train 3 won't start. However, shouldn't it rather ignore the signal, advance at a low speed, and couple with Train 2? I can't understand why it's waiting instead...
I have to manually force the train to ignore the signal. When I do, Train 3 behaves exactly as it's supposed to: it advances, couples with Train 2, and then drives off.

Perhaps this thing of ignoring the signal should be automated. Would you need me to post a savegame or anything else to help you out with this?

This is more complicated than it looks like.
Block signals are not supported, because it's more difficult to tell, what's inside the block. You can use pathfinder to look for train wanting to couple, but it doesn't tell you, if it's only train in the block. So then imagine multiple trains wanting to couple entering the block at the same time. Your case is simplified and ofcourse, it could be automated, but it would create more serious bugs when you play with it further in more complicated cases.
It's in know bugs and I can only suggest you for now to use path signals for coupling instead. I don't see quick way of fixing this.

My best idea for block signals is using white signal state, if there is right train in the station and nothing else in the block, but it's too much effort to code this. Altho I'm not sure, if block signals would be even useful in anything more complicated with more trains.

michael blunck wrote: Karn, I have the same problem. Sometimes ignoring the signal works, sometimes the coupling locomotive "waits for free path", without any reason I can see. I´m using all 2-directional path signals for the layout shown in the original thread

Could you please post screenshot or savegame?

Great work.
It is possible now not only to decouple, go around and couple from other end, but also to leave wagons for full load and couple different set of cars already loaded:
http://149.156.194.203/~mczapkie/Train/ ... pling1.png

I noticed, that normal decouple would not load cars, which are abandoned, is it bug or feature? (in my opinion it should load, we have "no loading" option for that).

Another problem: train cannot be decoupled, if station is too short.
By the way, similar to "load trough" patch, train should always try to proceed outside of the station, if station stopping position is set to "far". For example, if locomotive have to be detached, it should stick outside station, leaving first detached wagon in "far" position.

If talking about reversing mentioned by Snail: this approach is OK for single non-symetric vehicle, for example steam locomotive should go with tender forward, if reversed:
http://149.156.194.203/~mczapkie/Train/ ... pling0.png
but is useless for whole trainset.
Trainset should be reversed physically (first go last) not just due to aesthetic reasons, but to enable proper shunting operations.

McZapkie wrote:If talking about reversing mentioned by Snail: this approach is OK for single non-symetric vehicle, for example steam locomotive should go with tender forward, if reversed:
http://149.156.194.203/~mczapkie/Train/ ... pling0.png
but is useless for whole trainset.
Trainset should be reversed physically (first go last) not just due to aesthetic reasons, but to enable proper shunting operations.

My approach is only a workaround, and of course it doesn't work for non-symmetric consists with respect to wagon lengths.
OTTD itself should handle proper reversing, but that would require a specific patch.

McZapkie wrote:Great work.
It is possible now not only to decouple, go around and couple from other end, but also to leave wagons for full load and couple different set of cars already loaded:
http://149.156.194.203/~mczapkie/Train/ ... pling1.png

I noticed, that normal decouple would not load cars, which are abandoned, is it bug or feature? (in my opinion it should load, we have "no loading" option for that).

I see some misunderstanding here.
The second part of train gets the current_order + wait_for_couple order.
So after it's loaded, it waits to be coupled. When you don't set full_load, it will take what's available in station and then it will wait for locomotive.

McZapkie wrote:Another problem: train cannot be decoupled, if station is too short.

Decoupling longer train than station is not supported, because it's difficult to program. Let's not assume that my free time is endless and I can do this patch without compromises. Btw if anybody feels like he wants to contribute (with programming), it's welcome.
This picture shows, why it's difficult to couple train outside the station. You need to compute exact position to join a wagon from + offset if reversing switch length of front vehicle. In station you have just 2 simple cases without 45° and 90° options and you don't have to care (too much) about wagon lengths.

Karn wrote: I see some misunderstanding here.
The second part of train gets the current_order + wait_for_couple order.
So after it's loaded, it waits to be coupled. When you don't set full_load, it will take what's available in station and then it will wait for locomotive.

To be more precise:
if current order is default (load if any, unload if wanted), i.e. it is untouched, wagons are loaded with existing cargo, but are not loaded with any new cargo which appear at the station later.

McZapkie wrote:

Karn wrote: I see some misunderstanding here.
The second part of train gets the current_order + wait_for_couple order.
So after it's loaded, it waits to be coupled. When you don't set full_load, it will take what's available in station and then it will wait for locomotive.

To be more precise:
if current order is default (load if any, unload if wanted), i.e. it is untouched, wagons are loaded with existing cargo, but are not loaded with any new cargo which appear at the station later.

That's about, how it should behave in basics.
I don't think the station order should have more options, there are too many already. So I prefer keeping Waiting for couple as separate order. Altho if it's important, train could check, if next order (not only current) is waiting for couple and then couple the train. I can see benefits from this, but I don't know if it's more or less confusing than current behaviour.

Back to your question. Train can't load when it already finished its station order. Altho it could behave differently with full load - the locomotive could join the train earlier and leave station with about half loaded train. Is it useful to have such feature?

My only contribution here will be this question: What about cargo distribution?

I know that you're limited for time to work on this patch (which is pretty epic, I must say!) and a work around will be difficult.
But I've been playing around with it for 2 days now and the main issue I've seen is that passengers don't know where the empty carriages are going, so they don't get loaded.
Have you thought of any work arounds for it? The only one I could think of is if the carriages are to load any of its refitted cargo, regardless of desitation/route. Not sure how this works down to the game, but I thought I'd suggest it.

Btw, amazing patch

FulliAutomatix wrote:My only contribution here will be this question: What about cargo distribution?

I know that you're limited for time to work on this patch (which is pretty epic, I must say!) and a work around will be difficult.
But I've been playing around with it for 2 days now and the main issue I've seen is that passengers don't know where the empty carriages are going, so they don't get loaded.
Have you thought of any work arounds for it? The only one I could think of is if the carriages are to load any of its refitted cargo, regardless of desitation/route. Not sure how this works down to the game, but I thought I'd suggest it.

Btw, amazing patch

Question here is, what does cargodist care about. Is it just next hop, or whole route when it comes to orders? If it was just next hop, it could be pretty simplified, but I don't have such insight to be sure.

here's a pathfinder bug (?) that I've encountered once before

train engine reserves a path that loops through a dead end, but it intersects with itself so it gets stuck

Hi Karn,

Great set you made will create a lot of fun for the game.

A few months ago I made some overlap platforms they go well with your Realistic Train Shunting. As can see the Overlap platform which is fake allows a set of switchers (points) at the platforms.

The only fault I found so far when I send the engine to the Waypoint, which is the signal box .. if I did have that signal there, the train would continue down the track as far as it can go before returning to the train.

Does this even if I put a station there instead of the Waypoint and signal. But this could also be I getting the orders wrong.

If I can figure this out will be great at country terminal stations where there is only a single line.

Looks like I need to make a few more overlap platforms and a nice terminal end with buffers to go with it.

Cheers pal

another interesting behavior, when an engine gets autoreplaced and then couples to a train, the train flips instead of going straight ahead

it'd be cool if this was always the case if you uncheck "disallow reversing of trains at stations" in settings