Attach and deattach cars

[HIHO]

Hi all!
I have a suggestion to add to the list of orders for trains one more task designed for detach and attach cars in depot.
Such order directly linked to reality.
In reality, cars detach and attach on the exchange offices( or depots).

My suggestion is to add next two commands (orders) for depot:
1) attach <the number of car> car + <type of cargo> + <car with or without cargo?> + <how many cargo in car?>
2) detach <the number of car> car + <type of cargo> + <car with or without cargo?> + <how many cargo in car?>

Thanks!)

[PikkaBird]

Suggested many times, either in depots or in stations.

However, I think when you think about the reasons why wagons are coupled and decoupled and train formations changed in real life, you will realise that those reasons don't apply to TTD at all. I have not yet heard an argument for order-based attaching and removing cars in OpenTTD other than "it's realistic" or "it's cool".

[HIHO]

I think it can be applyed, here is why.

The reasons why wagons are coupled and decoupled and train formations changed:

1) When you disconnect the wagons, the weight of trains decreases.
Therefore the train becomes light and can go for the more severe the site,
on a hilly terrain, and the wagons will be delivered by another train on another branch.

2) The length of train reduced after decoupled cars.
And that means you can get turns faster, decrease the strength of the Curvature (http://wiki.openttd.org/Game_mechanics -> Vehicle speeds -> Trains -> Curvature ).

3) Wagons can be delivered to the station without a locomotive.
Wagons will couple and decouple to several passing trains.

4) Because the weight of the empty wagon less, you can create a special train for empty wagons.
Such a train can pick up 60-100 for example wagons and to carry them back.

Thanks!)

[HIHO]

P.S. Wagon is a separate part of the railway, is not appendix to a locomotive.

[planetmaker]

To be honest: the only effect I see in such "feature" is that people would send a fully loaded train with wagons to the destination and would drive back an empty engine without wagons. And where in all the arguments you give is a gameplay advantage. All seems to me rather the same line of "it's realistic" while not giving any advantage ingame to the gameplay itself. And, btw, wagons never are delivered to a station without an engine

[kamnet]

Both "more realistic" and "cool" should not be reasons to discourage a feature. The REAL question is a) how difficult would this be to code and b) how many people will use it? In this case, I would say it is both difficult and of little use to most people. In a world where we have a limited supply of coders, there's a lot of other things I'd rather they work on.

[Alberth]

I think it can be applyed, here is why. <reasons omitted>

Ok, let's assume you can do this.

First question, how do you deal with the balancing issue? Trains all run independently, they are not synchronized by some global table (perhaps with time tables you can do this, but it would be quite difficult to say the least). As a result, trains arrive at the depot in random order.

You decouple some full wagons from a train. Fine. How do these wagons get to their destination?
By the same engine, by another engine?

How do you ensure there are actually wagons in the depot when an engine arrives?


Decoupling empty wagons is next to pointless. The engine has to return to the load place anyway, and it normally runs at top-speed even with the wagons attached. Transporting the wagons separately just creates additional balancing issues since you have to take care wagons exist at the loading spot.



As a second question, why not use a feeder system instead? Move the cargo between trains instead of wagons with cargo?
You still have a balancing issue but much simpler as you can say 'wait for full load'.

[Eddi]

why not use a feeder system instead?

you can have different balancing issues, they won't automatically be solved.

E.g you serve a FIRS steel mill (coal&ore), and have a coal and ore mine nearby. feeder trains are fine, but in the "trunk" line, you need to balance the amount of coal wagon with the amount of ore wagons (autorefit may help here, but it's kinda new and i don't have experience with it yet.). with shunting, this would trivially be solved, when the feeder trains transport 3 wagons each, and the trunk train can take 9 wagons, then it will automatically balance in the order the feeder trains appear (3+6 or 6+3 or even 9+0). with "normal" feeder system (full load any) you usually will end up with one cargo being half-empty.

[Alberth]

Where would the engine wait, in the depot?
That looks horrible imho, and a single engine waiting at the platform doesn't look much better, I think.

You should keep the cargo handling at the platform (instead of having some cargo in a wagon in a depot and some cargo at a platform), which means you need to communicate number of needed wagons between the engine at the platform and the depot, which sounds extremely complicated to me.

Auto-refit seems a much better option here, but like you I have not played a game with it, so I cannot confirm this to be the case.

[supermop]

I think the best use case would be in the early game, where locomotive costs are still prohibitive, and industry output still low: much like prototypical freight railways, leave cars at industries on a siding to slowly load while the locomotive runs off to do other work in the meantime.

[warman45]

there are two good gameplay reasons that i can think of to have this feature. whether or not it justifies the expenditure is for you to decide.

one may wish to move very large amounts of resources across the map in one long train instead of a large number of small trains. the individual does not wish to have a large number of empty cars and so instead would use this feature to load cars, send them to the main hub and send the empty train back to pick up more cars. this may be helpful early on and in Victorian era grf's where locomotives and hills are mutually exclusive terms.

another (better) reason is that an individual may wish to move many cars with a single locomotive. the locomotive moves some cars to a factory and leaves them there to load while it goes off and does the same somewhere else. in this way a single locomotive can move many empty cars to industries where they may take some time to load. this prevent having locomotives sitting at a station waiting for the cars to fill. another locomotive may do the same with full cars thus two locomotives could supply many industries (5 or more) especially if these industries do not produce a lot.

[Lukenwolf]

The last two posts are the best arguments I've heard so far, but still, I think the amount of programming it takes to implement something like this is prohibitive.

Realism is something that most people around here consider a dirty word. OTTD after all is a game, not a simulation. While there is some truth in that, I consider OTTD my little model railway and I don't even have to fork over a lot of cash to Märklin , so once in a while a spot of "more realistic" can't hurt.

There are some Pro's for a "shunting patch"

• That's the way a real railroad works. You rarely have trains carrying only one sort of cargo or going from the source to final destination non-stop. If you go to Ingolstadt Central station, you'll see gazillions of waggons with Audis on them, but even those are shunted and attached to different trains, depending on their destination. But in the OTTD realm, that would only make sense in connection with a *Dist patch, which hasn't yet been perfected. Fonso's CargoDist comes close, but no banana, yet...
• It would give something to do for pure shunting Loco's like the KöfII in the Generic European Trains set.
• It would look great, especially for people, who use OTTD as a sort of model railway that doesn't take up 3 square meters in the basement

But - there's always a but, isn't there Implementing that would amount to a major rewrite of OTTD, which makes it prohibitive, because of the little potential gains. Here are some Cons that spring to mind:

• You need shunting tracks. That leads to many potential problems, like shunting locos getting lost
• You would need to revamp the complete order system. Currently OTTD works like the drunken coachman - the ol' horse knows the way. The orders are know to the loco and the coaches just tag along. In a shunting scenario, each waggon would have it's own destination. That would make the system so complex, you'd lose the plot after 20 trains.
• Shunting is slow, so a concept like that would only work with a daylength patch
• Due to the complex nature, it would be very difficult to adequately react to changes in industry output or cargo acceptance

All in all, it's a nice idea, but nigh-on impossible to implement

[FLHerne]

As a CargoDist user, I'd have trains travelling from City A to City B, then dividing to serve towns/villages C, D & E. At present, I need either unnecessarily short trains between cities, unnecessarily long trains to villages, or a loss of through services into A from the villages. None of these are ideal (the third might be ok from an effectiveness POV, but I'm the kind of player who uses slower wagon types occasionally to get some variety )

[Lukenwolf]

FLHerne, your example is a good one, because that's actually what real rail roads do. The ICE from Berlin to cologne for instance. It travels from Berlin to Hamm, were it his split in half, with one half going on to cologne via Wuppertal, the other half via Essen and Düsseldorf.

In OTTD this would require major changes to the system:

• While travelling from Berlin to Hamm, the two ICE consists are ONE train
• After splitting up, you suddenly have TWO trains, which need different orders to go on via different routes to cologne and back to Hamm
• At Hamm one train has to wait for the other one. Sometimes it is the half that went via Wuppertal, but it can also be the half that went through the Ruhrpott How are you going to implement that?
• To couple the two halves, they have to enter the same platform of a station, which is prevented by the pathfinder. Also the game would register the coupling of the train as a crash

All of these things are currently not possible and would require an insane amount of changes in the code

[FLHerne]

that's actually what real rail roads do

I know, they do it at my local station (not with ICEs sadly )

• Get the game to see them as separate ones, with their own orderlists/number/group? (probably difficult...)
• As above
• Do it by shared orders/group: Have an order "Wait for/join train from Group x". Have the pathfinder check to see if a train from Group x is in the station (does/can it know what group a train is in, or just its length?) If so, route the train to that platform; if not, wait in a platform.
• Let the game force it past the last signal (at least UK signalling does force trains through reds with call-on indicators), but set a flag on that train that could be checked by the collision routine. If the collision routine detects this flag to be set, it would call a 'join trains' routine on the two trains it found to have 'collided'*.

*Note: Based on my sketchy understanding of C++ programming and effectively non-existent knowledge of OTTD code. May be entirely nonsensical, if so please ignore.

All of these things are currently not possible and would require an insane amount of changes in the code

Predictably, I suppose . Ah well...

[Expresso]

For cargo trains I have a suggestion, but it would require a complete revamp of the order system.

There could be two systems:
One which (basically) as it is now, for passenger service but allowing for attaching and detaching parts. Each having their own linear order list. This implies partially shared orders (not the entire order list is shared). A vehicle which has partially shared orders needs to know with which vehicle(s) it shares the orders in order to be able to couple/decouple with the other vehicle(s). Another option could be to have this automatically detected and couple/decouple pax trains as convenient.

The other is specific for cargo trains. In this system the wagons are dumb slaves to the cargo they carry around and the wagons want to get the cargo delivered and post requests for engines to move them to another station, closer to their destination. The engines have a list of stations they must attend and they are only allowed to move wagons between those stations. The engines could also have a minimum and maximum amount of wagons to carry around and whether they must be loaded or not. It could also have a station or depot assigned where it should wait.
This last option results in trains wandering around where they are needed and may help in creating lively shunt yards

[audigex]

I was thinking about this a while ago. It would get VERY messy if implemented in stations, I'd go so far as to say it would be unworkable. Depots could work, however, with a little thought.