crakinshot wrote:(small bump).
Hi,
In reply to last post: I think it could work with cargodest, but you'd have to assign a destination to each wagon. i.e a wagon is going from A-B-C. During B, however, it is decoupled, waits, coupled, and then continues to C.
General comment: I like the idea of shunting and coupling, and by implication bigger depo's. Personally, I've been following OpenTTD for a while, and I've been wanting a reason (task) to join in, and this seems to be it. Here are my views. There are two problems here: Shunting and Train Composition; they are different in practice, but can be combined. Personally, once you have Shunting you can do the rest far more easily.
The basics of shunting is that a train needs to transfer from one track to another, like so.
This requires
- Remove train 'flipping' - current mechanism to change direction
- Train Reversing - a train at least appears to be reversing
- Correct Path Finding - given that Yafp might not find a path if it requires stopping and reversing, some work might be needed.
Once you have that mechanism you can go onto the more complex stuff. Specifically, like in reality, if shunting train wants to pass a Danger signal (red) it needs permission from the signal box. Similarly, in OTTD, you'd need an update of the signaling system or at least the train mechanics so that a train could enter into a block already occupied, without the trains crashing. Anther feature which would be nice would be track labelling. So, in the order you'd have "Goto STATION, on PLATFORM 3" OR "Goto STATION, on any pratform" OR "Goto STATION, use platforms 3-to-5". You'd then derive that so you'd have "Goto TARGET, use TRACK CONDITION"... so then you can apply it to stations or depo yards. The general idea here being, rather than break the track mechanics you'd simply use the already (high customisable) station mechanic for the 'shunting Yards'.
Dynamic train composition is very different. You could essentially add the feature in pretty quick if everything happens in the existing depos. The main difficulty is the wagon labelling and making it easy to use. Also, I can imagine how it could go very wrong if designed incorrectly. For instance, do you explicitly reference the wagons, or do you go with a more implicit method. For instance, you can have a train leave 4 coal wagons at a Station/depo and then have another train pickup ANY/AMOUNT coal wagons from said station and take them to a destination. This way you're not breaking the CargoDest mechanic, just expanding upon it. Rather than the cargo being left at a station/depo you've left the wagons. Almost exactly the same thing, especially if its all done in a depo. Of course, it would get complicated if you actually had a huge shunting yard, where the wagons are real. BUT, given what I've already mentioned about the shunting yards being stations, once the wagons have stopped and have been decoupled, they are 'in the station' as cargo ready to be taken to a destination.
Not a good solution, but one that probably would make it easier (for the user) to have several trains transfer wagons to a destination.
Well just some thoughts. I'll definiatly have a go at getting the OpenTTD code compiling and play around to see how it all works. Anyone else seriously thinking or working on shunting/decoupling?
Hmm, good points there. My conceptual appoach to shunting would be like this:
-Shunting unit. Defined same way as train, but without wagons or coaches. Only motive power. Has a programmable order list, which it runs with loop in auto-mode, like normal train. It could be also manually overridden to do single, user defined runs. Would serve as line-running train's motive power, in certain services, where, for example, tractive power is changed from electric to diesel or backwards. Programming is done via gui.
-Consist. Defined same way as train, but without motive power, and hasn't got any programming in it. Just a bunch of wagons/coaches, which form a consist. Has a unique name, which it can be called on programming.
-Consist group. Consists which form a certain service, for example, coal loading/unloading circulation, are defined to group, and they are more easy to address, so adressing single consists is not always necessary, for example on long routes where there is 4 consists running on trains, and so addressing a single consist is impossible on a case like that, because single consist's location wouldn't be there where it would be wanted.
-Shunting safe point. Point, located such way on railyard it does not interfere with mainline traffic, or if located on mainline, mainline traffic should be low. Shunting unit can reverse it's moving direction (but not the normal turn-the-graphics and whole train way!) here. Only direction of moving is changed. Shunting safe points could be stacked, and every shunting safe point should have a nearby shunting area (along with paraller run-around track), which is used to run around specific consist, for example when there is a terminus waiting ahead to which consist must be reversed so that it can be run out from it, without any futher reversing, or for another example, when there is a change of train direction, or traction from diesel to electric in a train.
-Shunting area. Resembles current stations, but platform isn't usually used by trains, it is used by shunting units. Shunting area is a temporary wainting area for "consist run-around", when driving direction or
having the consist pushed from back is needed.
-Waiting area. Resembles current stations, but platform is used for arriving consists on arriving trains, and for waiting consists to depart, and when "line-running" locomotive has orders to pick up consists, they go with them.
-Loading area. Same thing as stations, but platforms are for consist waiting for full/half/etc load or unload..
Here's demonstration map for shunting unit coding.
Code example..:
(defined shunting unit SU1 and 5-wagon petrol consist)
Code: Select all
couple consist "petrol" #coupling to the consist itself, consist just created at depot
go to SA1 #move consist to shunting area, shunting unit on head
decouple consist "petrol" #decoupling
go to SSP2 via SSP1 #shunting unit goes to Shunting safe point 2 via Shunting safe point 1, via paraller track
go SA1+couple to consist "petrol" #shunting unit goes from previous position to Shunting area 1, and couples to consist from opposite direction
go to SSP2 #shunting unit moves consist to Shunting safe point 2
Push-go (load) to "petrol1" #shunting unit pushes consist to petrol1-loading point from Shunting safe point 2
decouple consist "petrol" #decoupling
go to Depot #go back to depot to wait
And so. This method would be fairly easy to program with gui.
Next piece of code would be waiting loop for bringing back the loaded consist from petrol loading station, and having it transferred to waiting area WA1..
Code: Select all
(Waiting loop)
1 if consist "petrol" state is full, then go to get_petrol else go to 2
2 go to 1
Real waiting loop could have had many more if-beginning stuff... But then get_petrol:
Code: Select all
go to SSP2 #goes near petrol
go to "petrol1"+couple to consist "petrol" #explains itself
go to WA1 #goes to waiting area 1
decouple consist "petrol" #explains itself
go to Depot #explains itself
And then, consist "petrol" could be addressed by some other shunting unit, or it can be coupled to some train, which heads somewhere else.
Any comments, is this anything even near possible to implement? Gui for programming list is a must thing to have, in my concept.
Unfortunately, i am not into coding, but on conceptual level, i have ideas.