Transport Tycoon Forums

The place to talk about Transport Tycoon
It is currently Tue Dec 11, 2018 10:22 am

All times are UTC




Post new topic  Reply to topic  [ 187 posts ]  Go to page Previous 1 2 3 4 5 610 Next
Author Message
PostPosted: Tue Jul 10, 2018 11:00 am 
Offline
Engineer
Engineer

Joined: Sun Oct 02, 2011 6:56 pm
Posts: 126
It is
<-- 321 - 321 - 321 - loco

The counting with this random action is not considered for reversing. That's one thing to fix for next version.

But it's difficult to say, if this is the reason of the crash. There are checks to prevent crashing with wrong counting. Example tiny NewGRF (maybe in PM?) would help a lot. It's quite unpredictable what else will change with changed counting.


Top
   
PostPosted: Tue Jul 10, 2018 11:10 am 
Offline
Tycoon
Tycoon

Joined: Wed Apr 27, 2005 7:09 am
Posts: 5237
Karn wrote:
It is
But it's difficult to say, if this is the reason of the crash. There are checks to prevent crashing with wrong counting. Example tiny NewGRF (maybe in PM?) would help a lot. It's quite unpredictable what else will change with changed counting.

I don´t think this was the reason for the crash, since I had that train running around between two cities for a couple of time. The crash exactly happend when I clicked the engine to sell it in a depot.

regards
Michael

_________________
Image


Top
   
PostPosted: Tue Jul 10, 2018 4:58 pm 
Offline
Tycoon
Tycoon

Joined: Wed Jan 17, 2007 12:14 am
Posts: 7226
michael blunck wrote:
Hm, can´t attach a .log file?
need to rename it to .txt
and bother orudge about it, because this has been a problem for years now...

_________________
You might not exactly be interested in Ferion, but if you are, have fun :)


Top
   
PostPosted: Tue Jul 10, 2018 7:55 pm 
Offline
Engineer
Engineer
User avatar

Joined: Mon Nov 24, 2014 9:13 pm
Posts: 76
Location: At a desk
Karn wrote:
As you can notice, there is one new element called USE_ORDERS_XYZ. This assume implementation of indenpendent global OrderList that orders can copy from.
This is advanced feature that is aimed to be implemented later. First goal is to implement everything above without USE_ORDERS_XYZ option.

Is this orders concept missing any feature that somebody would like to see? Once it's done, it's gonna be set in stone for this patch. Also something from above might change during implementation due to technical limits and some part being too hc.


What would EMPTY be? an empty order list without even wait for couple?
and KEEP_ORDERS would that mean the new train 2 would have a copy of train 1s orders?

rather than a global orders list I still think there is value in an orders stack, if train of length 5 has a set of orders with a wait for couple in the middle

1. goto station A
2. goto station B
3. wait for couple
4. goto station A

while a second train of length 1 will couple to the train at B, move it to location C and decouple:

1. goto station A
2. goto waypoint for station B
3. couple consist ANY_WITH_POWER PUSH_ORDERS
4. goto station C
5 decouple and keep 1 unit POP_ORDERS to second section

set them going and they will happily keep going through their orders, this will work with helper engines to climb up hills or cross areas of no electricity, as well as in cases where DMUs split up and go seperate routes before joining again on return (as per evepois suggestion).

ANY_WITH_POWER and ANY_WITHOUT_POWER can be used to only couple to wagons and/or trains

POP_ORDERS gives the split section the orders from the previous couple with PUSH_ORDERS, if you try to POP_ORDERS when the stack is empty you would get the same behavior as INHERIT_WAIT_FOR_COUPLE, a stack would work even with multiple train joins:

train 1 [1][1] ORDERS_STACK []
train 1 joins 2 [1][1][2][2] ORDERS_STACK [2]
train 1 joins 3 [1][1][2][2][3][3] ORDERS_STACK [2, 3]

train 1 then pops 3 [1][1][2][2] >< [3][3] ORDERS_STACK [2] 3 takes orders 3
train 1 then pops 2 [1][1] >< [2][2] ORDERS_STACK [] 2 takes orders 2

what is nice about it is you dont need any global orders list or a GUI but you can still create a relatively powerful sets of orders. :D

from this you could improve the implenetation to pair coupling to the front as pushing to front of the stack and coupling to the back as pushing to the back, then you can pop from the front or pop from the back.

That would be import if the user coupled 2 at the back and decoupled 3 from front [3][1][2] would not mean 3 takes 2's orders and 2 takes 3's orders

_________________
Image
Real life transport planner
My projects:Link to my UK Scenario|Scenario Builder GS
Do check out my 3D unity transport game: transporter


Top
   
PostPosted: Tue Jul 10, 2018 9:50 pm 
Offline
Engineer
Engineer

Joined: Sun Oct 02, 2011 6:56 pm
Posts: 126
jimbob wrote:
What would EMPTY be? an empty order list without even wait for couple?

Yes, it's intended for beginners that are overwhelmed with all this to just try something simple and their own. Or for someone who wants to follow specific train manually. Or maybe some kind of debugging. Other options are sophisticated so let's not scare off everyone. Maybe it won't be implemented if it's gonna cause trouble with crashing trains, it's a plan that maybe can happen.

jimbob wrote:
and KEEP_ORDERS would that mean the new train 2 would have a copy of train 1s orders?

Yes nb.2, that's for making the second part the main part. You probably don't need both orders to be KEEP_ORDERS at the same time, but why to bother with disabling it, maybe someone can find use for it.

jimbob wrote:
what is nice about it is you dont need any global orders list or a GUI but you can still create a relatively powerful sets of orders.

No GUI part is actually not good. I imagine the 98% of time you want to deal with orders is when you buy first train. If there is no GUI to edit the stack (which I guess can't be), you would have to edit orders at multiple places which will be annoying. Other bad part is, that it behaves as stack. People don't think as stacks, computers do. I see the global order list is not ideal and it's lot of work, but orders need to stay simple to people like this. For now is the USE_ORDERS_XYZ or STACK_PUSH just idea.

Global orders idea is implemented and proven to work in few other transport games. And even when it's not user friendly when there are many orders, it does the job.

I think we can agree, that whatever reasonable data structure replaces USE_ORDERS_XYZ (= STACK_PUSH/POP) entry in this system will solve this. I'll try to come up with another better idea, if there is one.


Top
   
PostPosted: Wed Jul 11, 2018 4:03 pm 
Offline
Engineer
Engineer

Joined: Sun Oct 02, 2011 6:56 pm
Posts: 126
New small feature implemented in v0.8.1. Wagons get copy of next stopping order from loco. It doesn't solve everything, but it gives a hint to cargodist, so it has more use cases.


Top
   
PostPosted: Wed Jul 11, 2018 7:45 pm 
Offline
Director
Director

Joined: Tue Jul 17, 2007 5:56 pm
Posts: 608
Karn wrote:
Is this orders concept missing any feature that somebody would like to see? Once it's done, it's gonna be set in stone for this patch. Also something from above might change during implementation due to technical limits and some part being too hc.


Disclaimer: I saw this thread some time ago, regarded the idea / patch as quite interesting, but didn´t have time to dive into it / write to this thread. But I thought a bit about orders, independent from your post. So what I write is more an idea from outside than a direct comment to your concept.

My starting point is: I play my games in a style where I specify in a quite exact manner what a train does when, i.e. I use timetables (my self written patch). Even with the added information ("not only I specify that the train should visit station X, I also specify when it is supposed to do so), I consider keeping a non-trivial train network running a quite complex task (e.g., avoid deadlocks, avoid trains block other trains for a long time).

Now, I consider shunting a really interesting feature, but in a non-trivial network, my feeling is that avoiding the situation that while shunting, different trains block each other in a unwanted way is a quite complex task, much more complex than with standard OpenTTD orders. For example, if the locomotive fetches the first three wagons of a train, moves them to a track outside the station, and couples them to a waiting train on another track, you need the following prerequesites for this:

- The track outside the station needs to be empty
- The second train must already have arrived
- The second train must have found an empty track

If for example, the locomotive is expected to move to the back of the train, you will have a similar set of prerequesites.

And my feeling is that in a non-trivial network, where things sometimes go wrong (e.g. second train got delayed, etc.), keeping things running in the light of such shunting orders (and the above examples are just the most simple ones) is quite difficult, i.e. the danger that you often have to manually fix things is quite high in my feeling. Especially, because OpenTTD stations are clearly limited with respect to the number of tracks - where in reality, you have shunting areas with a lot of parallel tracks, in OpenTTD, you are really restricted here.

So how can the order concept support you here?

An idea that came to my mind is, could it be senseful to move the concept of detailed orders from the vehicles to the stations? What I mean is something like the following:

- A station can have a set of "advanced" orders (whatever this means in detail)
- For this set of advanced orders, you define a set of entry points (tiles), where for incoming vehicles is decided wether (one of) the advanced orders is applicable.
- The advanced orders can have things like "if train is in group X, it should enter track Y if free, otherwise track Z if free, otherwise it should stay outside"
- With respect to shunting, these advanced orders can trigger a series of shunting operations for a train they take control of.
- Shunting orders also can have preconditions ("wait with doing this until condition X is met"), conditions ("if train X is here, couple the three wagons to it, otherwise move them to track Y and leave them there)
- The default orders would need less complexity (they specify only to go to that station, not what to do there in detail)
- Once a set of advanced orders is completed, it gives control back to a default order.
- If during shunting, a new train is arranged, the last advanced order might specify "assign order list X to that train, and start with the first order"
- If an entry point (see above) doesn´t take control over a train, just the usual default order is processed, no need to deal with the complexity described here

So, to conclude, when a train passes an entry tile, it is decided wether it should be subject to advanced orders. If yes, a series of advanced orders is processed, and after they give control back, the default orders will proceed.

Why I came to that idea?
- As described above, I felt that once you play with more complex shunting operations, you might need finer control about how things work in detail (e.g., which track to use?)
- But how can you keep the overview over everything in a particular station happens? Distributing shunting operations that might interfere with each other over several order lists doesn´t seem that clearly represented.
- Maybe mimic the real world concept of a traffic controller, i.e. an entity that controls everything happening in a particular region?
- And of course don´t invent anything someone who isn´t interested in such a complexity is forced to use.

As I have said, these are some more advanced ideas that came to my mind in the last days. I really don´t want to disturb your patch (and I know that it would be a lot of work to make that work), but at least I wanted to add some aspects ("how might this work in more complex networks with non-trivial shunting operations?") to the discussion.


Top
   
PostPosted: Thu Jul 12, 2018 4:57 pm 
Offline
Engineer
Engineer

Joined: Mon Mar 03, 2014 11:14 pm
Posts: 104
Location: Essex
Is portion working possible as the train could split and then the front train goes to one place and then the second portion goes to another place.

Is that possible at all?


Top
   
PostPosted: Thu Jul 12, 2018 6:34 pm 
Offline
Tycoon
Tycoon

Joined: Wed Apr 27, 2005 7:09 am
Posts: 5237
willsym22 wrote:
Is portion working possible as the train could split and then the front train goes to one place and then the second portion goes to another place.

Is that possible at all?

Not yet. Splitting and proceeding of the first part is already possible, but at the time being the second part keeps waiting at that station, to be coupled again.

regards
Michael

_________________
Image


Top
   
PostPosted: Fri Jul 13, 2018 10:04 am 
Offline
Tycoon
Tycoon
User avatar

Joined: Sat Nov 27, 2004 3:05 pm
Posts: 5380
Location: Canada
A couple of weeks ago I downloaded the Windows binary and it worked fine right out of the box.
Yesterday I downloaded the source and compiled it with MinGW. There was no decoupling.
A quick look in the binary package that I installed two weeks ago. It included a file (decouple_0.7.diff) which was not in yesterday's source download.
Is decouple_0.7.diff still the current patch and if not, where can I get the current one?

_________________
wallyweb on tt-forums: Screenshots - Projects - Releases
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018


Top
   
PostPosted: Fri Jul 13, 2018 10:20 am 
Offline
Engineer
Engineer

Joined: Sun Oct 02, 2011 6:56 pm
Posts: 126
wallyweb wrote:
A couple of weeks ago I downloaded the Windows binary and it worked fine right out of the box.
Yesterday I downloaded the source and compiled it with MinGW. There was no decoupling.
A quick look in the binary package that I installed two weeks ago. It included a file (decouple_0.7.diff) which was not in yesterday's source download.
Is decouple_0.7.diff still the current patch and if not, where can I get the current one?

There is decouple_0.8.1.diff in the zip that is the newest.
Other option is downloading source files from github link in the first post that are already patched.


Top
   
PostPosted: Fri Jul 13, 2018 2:13 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Sat Nov 27, 2004 3:05 pm
Posts: 5380
Location: Canada
Karn wrote:
Other option is downloading source files from github link in the first post that are already patched.
I thought that might be the case. Any chance that applying the patch to the github version was overlooked? That is the one that did not do shunting. It was probably something I did but I thought I would check.

_________________
wallyweb on tt-forums: Screenshots - Projects - Releases
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018


Top
   
PostPosted: Fri Jul 13, 2018 2:44 pm 
Offline
Engineer
Engineer

Joined: Sun Oct 02, 2011 6:56 pm
Posts: 126
wallyweb wrote:
Karn wrote:
Other option is downloading source files from github link in the first post that are already patched.
I thought that might be the case. Any chance that applying the patch to the github version was overlooked? That is the one that did not do shunting. It was probably something I did but I thought I would check.

Maybe github environment is confusing? It's easy to switch there to different branch or to official OpenTTD source, which does not include patch.

Anyway, the decouple.diff is there only for legal purposes (to provide source code with binaries). It's not very practical to find the right version to apply to it, since we don't have straightforward version control system right now. So if you are not interested in licenses and legal stuff, you can (and should for your own good) ignore decouple_xx.diff.

I suggest using only:
1) download source files from github repository from link and compile it yourself (make sure you didn't change branch or fork before downloading it)
or 2) download and trust my binaries posted in first post if you are windows user.

Does it work for you now?


Top
   
PostPosted: Fri Jul 13, 2018 4:17 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Sat Nov 27, 2004 3:05 pm
Posts: 5380
Location: Canada
Karn wrote:
1) download source files from github repository from link and compile it yourself (make sure you didn't change branch or fork before downloading it)
or 2) download and trust my binaries posted in first post if you are windows user.

I use Turtle Git. Seems I forgot to fill in the Branch box, :oops:
Quote:
Does it work for you now?
Yes it does. :D
Thanks for your help. :bow:

A curiosity question ... Has anybody tried to apply the diff from the Windows binary to NRT? ?(

_________________
wallyweb on tt-forums: Screenshots - Projects - Releases
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018


Top
   
PostPosted: Sun Jul 15, 2018 7:51 am 
Offline
Tycoon
Tycoon
User avatar

Joined: Sat Nov 27, 2004 3:05 pm
Posts: 5380
Location: Canada
Karn wrote:
wallyweb wrote:
Karn wrote:
Is this orders concept missing any feature that somebody would like to see?
I'm thinking of a scenario ...
Branch line serves a rural region with many grain farms.
Farmers truck their grain harvests to nearby small towns served by grain elevators on sidings.
Train leaves city marshaling yards with a string of 15 empty grain hoppers.
First station gets 3 empty hoppers.
Second station gets 4 empty hoppers
Third station gets 2 empty hoppers.
Fourth station gets 4 empty hoppers
Last station - train waits while last 2 empty hoppers are loaded.
Train departs with 2 loaded hoppers and respectively collects the previously dropped hoppers all now loaded.
Train returns to city and drops the 15 hoppers at harbour for unloading to a ship while the engine goes to the depot for service.
Yard switcher collects the empty hoppers and drops them at the marshaling yard
Our engine goes to the yard and connects to the empty hoppers and the cycle is repeated.

Will this be possible?

Yes.
So I began experimenting with the above scenario. I found some limitations (not bugs).
In reality a station siding where wagons are to be dropped only needs to be long enough to accommodate the dropped wagons.
In un-reality (Karn's patch) a station needs to be long enough to accommodate the entire train for the decouple to function.
A possible solution would be to have a main line (not siding) station that is long enough for the entire train from which the required number of wagons would be decoupled and then dropped onto a siding station.
The engine would then return to the mainline station to couple to the remaining wagons and then decouple the next number of wagons required by the next siding station.
Repeat until all sidings have been serviced.
I guess the question is can coupling and decoupling orders be paired?
I will now return to my lab to see if this works.

_________________
wallyweb on tt-forums: Screenshots - Projects - Releases
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018


Top
   
PostPosted: Sun Jul 15, 2018 10:20 am 
Offline
Tycoon
Tycoon
User avatar

Joined: Sat Nov 27, 2004 3:05 pm
Posts: 5380
Location: Canada
Problem #1:

*** CRASH!!! ***
Required documentation in the attached 7zip.
This is repeatable.
The first event was with a lot of no longer available Canadian GRFs and a bunch of not yet released (I've been busy ... ok?) GRFs.
The current event only has OGFX+Trains and ISR 1.0.2
The crash events were identical.

Problem #2: I'm running out of coffee!!! :evil:


Attachments:
Shunting Lab OGFX.7z [184.5 KiB]
Downloaded 16 times

_________________
wallyweb on tt-forums: Screenshots - Projects - Releases
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018
Top
   
PostPosted: Mon Jul 16, 2018 6:18 pm 
Offline
Engineer
Engineer

Joined: Sun Oct 02, 2011 6:56 pm
Posts: 126
ic111 wrote:
Karn wrote:
Is this orders concept missing any feature that somebody would like to see? Once it's done, it's gonna be set in stone for this patch. Also something from above might change during implementation due to technical limits and some part being too hc.


Disclaimer: I saw this thread some time ago, regarded the idea / patch as quite interesting, but didn´t have time to dive into it / write to this thread. But I thought a bit about orders, independent from your post. So what I write is more an idea from outside than a direct comment to your concept.

My starting point is: I play my games in a style where I specify in a quite exact manner what a train does when, i.e. I use timetables (my self written patch). Even with the added information ("not only I specify that the train should visit station X, I also specify when it is supposed to do so), I consider keeping a non-trivial train network running a quite complex task (e.g., avoid deadlocks, avoid trains block other trains for a long time).

Now, I consider shunting a really interesting feature, but in a non-trivial network, my feeling is that avoiding the situation that while shunting, different trains block each other in a unwanted way is a quite complex task, much more complex than with standard OpenTTD orders. For example, if the locomotive fetches the first three wagons of a train, moves them to a track outside the station, and couples them to a waiting train on another track, you need the following prerequesites for this:

- The track outside the station needs to be empty
- The second train must already have arrived
- The second train must have found an empty track

If for example, the locomotive is expected to move to the back of the train, you will have a similar set of prerequesites.

And my feeling is that in a non-trivial network, where things sometimes go wrong (e.g. second train got delayed, etc.), keeping things running in the light of such shunting orders (and the above examples are just the most simple ones) is quite difficult, i.e. the danger that you often have to manually fix things is quite high in my feeling. Especially, because OpenTTD stations are clearly limited with respect to the number of tracks - where in reality, you have shunting areas with a lot of parallel tracks, in OpenTTD, you are really restricted here.

So how can the order concept support you here?

An idea that came to my mind is, could it be senseful to move the concept of detailed orders from the vehicles to the stations? What I mean is something like the following:

- A station can have a set of "advanced" orders (whatever this means in detail)
- For this set of advanced orders, you define a set of entry points (tiles), where for incoming vehicles is decided wether (one of) the advanced orders is applicable.
- The advanced orders can have things like "if train is in group X, it should enter track Y if free, otherwise track Z if free, otherwise it should stay outside"
- With respect to shunting, these advanced orders can trigger a series of shunting operations for a train they take control of.
- Shunting orders also can have preconditions ("wait with doing this until condition X is met"), conditions ("if train X is here, couple the three wagons to it, otherwise move them to track Y and leave them there)
- The default orders would need less complexity (they specify only to go to that station, not what to do there in detail)
- Once a set of advanced orders is completed, it gives control back to a default order.
- If during shunting, a new train is arranged, the last advanced order might specify "assign order list X to that train, and start with the first order"
- If an entry point (see above) doesn´t take control over a train, just the usual default order is processed, no need to deal with the complexity described here

So, to conclude, when a train passes an entry tile, it is decided wether it should be subject to advanced orders. If yes, a series of advanced orders is processed, and after they give control back, the default orders will proceed.

Why I came to that idea?
- As described above, I felt that once you play with more complex shunting operations, you might need finer control about how things work in detail (e.g., which track to use?)
- But how can you keep the overview over everything in a particular station happens? Distributing shunting operations that might interfere with each other over several order lists doesn´t seem that clearly represented.
- Maybe mimic the real world concept of a traffic controller, i.e. an entity that controls everything happening in a particular region?
- And of course don´t invent anything someone who isn´t interested in such a complexity is forced to use.

As I have said, these are some more advanced ideas that came to my mind in the last days. I really don´t want to disturb your patch (and I know that it would be a lot of work to make that work), but at least I wanted to add some aspects ("how might this work in more complex networks with non-trivial shunting operations?") to the discussion.

Your idea with storing orders in station is very interesting. It would help with one of my goals - to have trains with certain names and orders leave station during the time in cycle depended on each other. Like in reality. I think it needs to be combined with global orders to give it real power.

I'm sceptical about too big complexity of such station orders tho. In reality, it's busy job for a person, who does this in real time. We might need real person to adjust it and plan it all the time, instead of simple machine orders. We could maybe turn this into station dispatcher simulator :D

wallyweb wrote:
Problem #1:
*** CRASH!!! ***

It'll be fixed in next release, there will be some waiting tho. I want to finish orders feature before uploading new version, so I don't create more work for myself with branching. I'm sorry for inconvenience.


Top
   
PostPosted: Mon Jul 16, 2018 7:00 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Sat Nov 27, 2004 3:05 pm
Posts: 5380
Location: Canada
Karn wrote:
wallyweb wrote:
Problem #1:
*** CRASH!!! ***

It'll be fixed in next release, there will be some waiting tho. I want to finish orders feature before uploading new version, so I don't create more work for myself with branching. I'm sorry for inconvenience.
Good to know you have a fix. I'll wait patiently for that next release. :bow:

_________________
wallyweb on tt-forums: Screenshots - Projects - Releases
wallyweb on Simuscape: Projects - Releases
Other Stuff: TTDPatch 2.6 "Nightly" download - cirdan's OpenTTD branch (New Map Features)
Screenshot Of The Month Contest Winner: August 2015 - Tied May 2016 - January 2018


Top
   
PostPosted: Mon Jul 16, 2018 7:43 pm 
Offline
Director
Director

Joined: Tue Jul 17, 2007 5:56 pm
Posts: 608
Karn wrote:
Your idea with storing orders in station is very interesting. It would help with one of my goals - to have trains with certain names and orders leave station during the time in cycle depended on each other. Like in reality. I think it needs to be combined with global orders to give it real power.

I'm sceptical about too big complexity of such station orders tho. In reality, it's busy job for a person, who does this in real time. We might need real person to adjust it and plan it all the time, instead of simple machine orders. We could maybe turn this into station dispatcher simulator :D


Yes, I know what you mean...

In my games, I already pretty much achieve your goal ("have trains with certain names and orders leave station during the time in cycle depended on each other") by using timetables. Of course, trains don't know about each other, but at least, as long as everything works as planned, they leave in the order I defined beforehand.

However, sometimes things don't work as desired, say, some train is late. Then (when playing with timetables), maybe its track is already blocked and it has to wait for an even longer time, and in the end, it travels completely off schedule.

Now my fear is, that if you really use shunting heavily, such effects happen much more often. And my idea would be to - by (a) experience beforehand, and (b) trial and error after you noticed that something went wrong, avoid such situations as much as possible by specificially preventing trains from doing certain things that are known to end bad.

So, my vision is that in most cases, the "simple" orders are sufficient, but that on the other hand, you have the toolkit to avoid certain unwanted situations in a quite specific way, by more sophisticated orders.

One example: Playing with timetables, a passenger train is seriously delayed, approaches a station, the last station before its final destination. If it proceeds to its final destination, it will travel back seriously delayed as well.

But, if it would skip the next two orders at that particular station, and travel back immediately, it would be on time again.

In reality, delays are sometimes resolved this way. In OpenTTD, I can do this manually if I notice, but not automatically.

So, for me it would be quite desirable if the station could tell the train "if you arrive with a delay of more than 30 days, I send you to track 3 instead of track 1, skip the next two orders, and you go back directly from here".

Why was the train delayed by 30 days? Maybe because at some previous station, the locomotive that is supposed to do some shunting before it passes was delayed by 10 days, and blocked the track it needs to proceed. Then, another slower train that is assumed to travel after it travelled before it, and the delay grew and grew.

So, maybe it would be desirable to tell that locomotive "if a train has reserved a path at tile X, don't start the shunting, you would block its way".


Top
   
PostPosted: Mon Jul 16, 2018 10:44 pm 
Offline
Engineer
Engineer

Joined: Thu May 25, 2017 6:42 pm
Posts: 3
Karn wrote:
Is this orders concept missing any feature that somebody would like to see? Once it's done, it's gonna be set in stone for this patch. Also something from above might change during implementation due to technical limits and some part being too hc.


Are there any possibilities of allowing decoupling on waypoints? It's the only way to have [realistic] side track shunting* capabilities for train depots I've thought of so far (assuming there are no other options).

Attachment:
File comment: Here's how it looks like currently, which forces a depot service (not bad for some, but I'm not interested in time tables* yet).

(I would like to see a turntable at some point, but we'll focus on what can be done at the moment)

Open TTD Shunting at Depot.gif
Open TTD Shunting at Depot.gif [ 2.45 MiB | Viewed 731 times ]


*And by that I mean something similar to what this is referencing:
Quote:
The game is also not programmed to make the slower train shunt on to a side track and allow the trains to pass unless you use time tables and waypoints to manually create this event.

https://wiki.openttd.org/Signals#Signal ... _real_life


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 187 posts ]  Go to page Previous 1 2 3 4 5 610 Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000-2018 phpBB Limited

Copyright © Owen Rudge/The Transport Tycoon Forums 2001-2018.
Hosted by Zernebok Hosting.