JGR's Patch Pack

Forum for technical discussions regarding development. If you have a general suggestion, problem or comment, please use one of the other forums.

Moderator: OpenTTD Developers

User avatar
JGR
Tycoon
Tycoon
Posts: 2557
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: JGR's Patch Pack

Post by JGR »

Denswillow wrote:I`ve got a crash with this patch pack.
Thanks for the bug report, I'm working on fixes at the moment.
This is due to articulated trams attempting to reverse on custom bridge heads with single tram pieces which extend in the entrance direction on to a road bridge.
In this case the bridge and trams were created by an AI. Have a look just south-east of Schweinhorst.

Edit: This is fixed and in the next release, however this does not fix articulated trams which are already in an invalid (separated) state.
Ex TTDPatch Coder
Patch Pack, Github
Davie_UCF
Traffic Manager
Traffic Manager
Posts: 155
Joined: 11 Sep 2004 19:55
Location: Colchester, Essex, United Kingdom

Re: JGR's Patch Pack

Post by Davie_UCF »

Hey guys.

Making timetables is rather tedious, having to make things add up so they depart when you want to. Is there no way in OpenTTD or this patch pack where you can manually type in the departure times, so you can put a service to leave a terminus on the hour for example?
East of England/East Anglia scenario/map released!! http://www.tt-forums.net/viewtopic.php?p=205440#205440
ino
Traffic Manager
Traffic Manager
Posts: 152
Joined: 09 Apr 2017 14:58

Re: JGR's Patch Pack

Post by ino »

Davie_UCF wrote:Hey guys.

Making timetables is rather tedious, having to make things add up so they depart when you want to. Is there no way in OpenTTD or this patch pack where you can manually type in the departure times, so you can put a service to leave a terminus on the hour for example?

I wrote this and request for it to be merged into this patch pack a few week ago. It is merged, and should be in the next version of this patch pack (I hope).
Cadde
Transport Coordinator
Transport Coordinator
Posts: 290
Joined: 07 Oct 2004 12:51

Re: JGR's Patch Pack

Post by Cadde »

ino wrote:I wrote this and request for it to be merged into this patch pack a few week ago. It is merged, and should be in the next version of this patch pack (I hope).
Wow!
Does this mean i can now click any order in the timetable and set it's time right there? Also, does it mean that using the "start date" doesn't immediately clear the whole schedule?

I am asking for neither but i would be happy to have them. As well as the ability to duplicate a timetable once set up as so:

Station/travel : wait/travel time
A : 10
* : 15
B : 4
* : 36
C : 4
* : 54
D : 12
* : 47
E : 4
* : 42

Pressing a "DUPLICATE" button would now result in:



Station/travel : wait/travel time
A : 10
* : 15
B : 4
* : 36
C : 4
* : 54
D : 12
* : 47
E : 4
* : 42
A : 10
* : 15
B : 4
* : 36
C : 4
* : 54
D : 12
* : 47
E : 4
* : 42

... Or some other super awesome way to copy->paste stuff in orders and timetables. That's my dream!

Why? You may ask...
Because then i can set up timetables for 24 hour loops where a train will visit a depot every 12 hours for instance. That is, instead of going "A->E->Depot" every time i could go "A->E->A->E->A->E->DEPOT->A->E->A->E->A->E->DEPOT" with ease, without having to manually fill in every order...
... And departure boards would still work as well as the schedule would be filled all the way through rather than stopping on a conditional.
ino
Traffic Manager
Traffic Manager
Posts: 152
Joined: 09 Apr 2017 14:58

Re: JGR's Patch Pack

Post by ino »

I hope I am not stepping on JGR boundary here.

The current implementation is that it allows you to set departure cycle and departure time offset. e.g. If you set departure cycle to 60 minutes and set the departure time offset to 0, 15, and 40, then the train will leave the first station on the hour, at past 15, and past 40. See this image for the feature in action : https://imgur.com/y2mk0Qj This patch just set the timetable start date of the vehicle arriving at the first station to the next available time. This eliminate the need to set up 24/12 hours timetable. You can just leave it as it is, or even using automated timetable XD. (It also works in days rather than minutes if you don't use wall clock)

You currently cannot set the scheduled time for anything other than the first waiting order. This is not implementation limitation, but rather I cannot think of a UI to do that without being confusing and fragile. It is also a feature I want (being able to release train on schedule on both end of the terminus etc.), so if you have any idea regarding UI feel free to post.


Regarding depot, I kinda understand your point, but in my play I just have it service either end of the terminus. I usually end up having siding for trains to wait for its schedue anyway.

------------------
CONTENT ADDED 2017-06-26: Scheduled Dispatch Patch

Feature:
  • Add a feature to allow a vehicle to be releases from the first item in the order that can be waited on (Station/Depot with wait time set) on scheduled
  • Double-clicking item in time table now allow you to change the time for that entry
How it works:

This patch can be use by both wall-clock and non-wall-clock setting. Setting should be preserved across, but different in day length/minute length may left to inaccurate display.

It allow you to define a schedule "duration" (default: 24hrs/30days) and "start" (default: 00:00/first day of that month). Inside that time, you can define a departure "slot". Vehicle arriving at the first station will departs at the next available slot. If no vehicle is available, a "slot" will be missed (though no notification is generated). Delay setting can allow slightly late vehicle to still take the past slot.

Quirks:

1. If you manipulate day length setting, or in other unforeseen circumstance and the dispatcher engine thinks that it already has vehicle scheduled in very far future, thus it will not release any vehicle until that time is reached, then you can press "Reset Last Dispatch" to reset the last dispatch time.

2. While start time and slots requires you to enter the absolute time, it is actually not required. Start date are automatically calculate to be the latest date/time possible. Ex: time is now 18:42, duration is 120 minutes, and you enter start date of 01:00, then start date will be set to 17:00 automatically. Slots work in the same way: if the start date is 18:00, duration is 60 minutes, then if you enter slot of 00:10 you will get a slot of 18:10 automatically.

Example:

If you want a vehicle to leave every half an hour from the first stop, here is a step by step:

1. Make sure your vehicle is fully timetabled and auto separation is not enabled. Automate timetable can be enabled.
2. In scheduled dispatch window, press enable, then press duration and set it to 30 (minutes)
3. Press "Add Departure Slot" and enter 00:00 (or just 0 if you have text field entry enabled).
4. The start time should be on the hour by default, but if not just change it.
5. You are done.
Last edited by ino on 26 Jun 2017 18:35, edited 3 times in total.
User avatar
JGR
Tycoon
Tycoon
Posts: 2557
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: JGR's Patch Pack

Post by JGR »

ino wrote:I hope I am not stepping on JGR boundary here...
Don't worry about that.

It will be in the next release, hopefully it won't be too much longer before I get around to that.
Ex TTDPatch Coder
Patch Pack, Github
Davie_UCF
Traffic Manager
Traffic Manager
Posts: 155
Joined: 11 Sep 2004 19:55
Location: Colchester, Essex, United Kingdom

Re: JGR's Patch Pack

Post by Davie_UCF »

Fantastic news guys!

I've been drawn more to realistic timetables and struggle to play the old way now! Just find those departure boards so satisfying.

Love for it to be easier to know where a train can pass another.
East of England/East Anglia scenario/map released!! http://www.tt-forums.net/viewtopic.php?p=205440#205440
Cadde
Transport Coordinator
Transport Coordinator
Posts: 290
Joined: 07 Oct 2004 12:51

Re: JGR's Patch Pack

Post by Cadde »

ino wrote:The current implementation is that it allows you to set departure cycle and departure time offset. e.g. If you set departure cycle to 60 minutes and set the departure time offset to 0, 15, and 40, then the train will leave the first station on the hour, at past 15, and past 40. See this image for the feature in action : https://imgur.com/y2mk0Qj This patch just set the timetable start date of the vehicle arriving at the first station to the next available time. This eliminate the need to set up 24/12 hours timetable. You can just leave it as it is, or even using automated timetable XD. (It also works in days rather than minutes if you don't use wall clock)

You currently cannot set the scheduled time for anything other than the first waiting order. This is not implementation limitation, but rather I cannot think of a UI to do that without being confusing and fragile. It is also a feature I want (being able to release train on schedule on both end of the terminus etc.), so if you have any idea regarding UI feel free to post.


Regarding depot, I kinda understand your point, but in my play I just have it service either end of the terminus. I usually end up having siding for trains to wait for its schedue anyway.
Ah, that makes it much clearer!
Unfortunately it doesn't help me with my problem then as i understand it. I need schedules for every stop as i am running single track (two way) lines where possible and those single tracks can still service a bunch of trains as long as they wait at double (or more) track stations along the way for the oncoming train(s) to pass first. It's all about saving monies as i am running a punishing economy where profits per route isn't that great to begin with. Where every nickel counts.

I would LOVE to run with vehicle breakdowns just to add some flare to the game but because of how limited (or unusable) timetables and orders are, it's not happening currently. And maybe i didn't mention it but i modified the reliability decay on 2cc in NML to 1 rather than the default 20. Thus, reliability drops 20 times slower, meaning servicing only makes sense once every 20 hours or so rather than on every end of the line.
Besides, i have 2 train depots IN TOTAL on my 2048x2048 map. Building a train depot costs a LOT in my game. Basically, i want to keep the number of necessary depots to a minimum as well.

Anyways, great patch addition for sure and i am not going to smear your great addition with my own problems.
I don't do C++ myself even though i technically could. If i did then i would definitely add copy->pasting to timetables along with many other features. Because of the MANY limitations in OTTD and the fact i don't do C++, i've even considered writing my own game in my language of choice.
User avatar
JGR
Tycoon
Tycoon
Posts: 2557
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: JGR's Patch Pack

Post by JGR »

You can try it out in the release in the first post or on Github now.
Ex TTDPatch Coder
Patch Pack, Github
Davie_UCF
Traffic Manager
Traffic Manager
Posts: 155
Joined: 11 Sep 2004 19:55
Location: Colchester, Essex, United Kingdom

Re: JGR's Patch Pack

Post by Davie_UCF »

I can't get scheduled dispatch to work. What do I need to do if I want trains in a group to leave every half hour from the first stop?
East of England/East Anglia scenario/map released!! http://www.tt-forums.net/viewtopic.php?p=205440#205440
ino
Traffic Manager
Traffic Manager
Posts: 152
Joined: 09 Apr 2017 14:58

Re: JGR's Patch Pack

Post by ino »

Davie_UCF wrote:I can't get scheduled dispatch to work. What do I need to do if I want trains in a group to leave every half hour from the first stop?
Assuming you have wall clock enabled:

1. Make sure your vehicle is fully timetabled and auto separation is not enabled
2. In scheduled dispatch window, press enable, then press duration and set it to 30.
3. Press "add departure slot" and enter 00:00 (or 0000 if you have text field entry enabled) It actually wants a next departure time within the start time to start time plus duration, but the value get normalized if it is outside that range.
4. The start time should be on the hour by default, but if not just change it.

Hope this helps

EDIT:
Cadde wrote:I need schedules for every stop as i am running single track (two way) lines where possible and those single tracks can still service a bunch of trains as long as they wait at double (or more) track stations along the way for the oncoming train(s) to pass first. It's all about saving monies as i am running a punishing economy where profits per route isn't that great to begin with. Where every nickel counts.
Unless I am understanding something wrong, single-track line can be run quite efficiently using vanilla OTTD, or using slots added in this patch pack in 0.19.0 (Slots would allow some advanced routing e.g. allow train in same direction to follow each other immediately). Precise timetable would only reduce waiting time. I have played with many single track using scheduled dispatch and if you are very organised (I have full timetable in paper for planning) it should not be a problem. I even have a few fully saturated single-track line running without problem.

IMO, traditional timetable tends to slips a lot and can be messed up easily. Scheduled dispatch allow a proper "reset" to be performed, so that entire timetable and various sync point you create are still valid even though some junction reconstruction messed up timetable of all running trains.

Cadde wrote:If i did then i would definitely add copy->pasting to timetables along with many other features.
Technically, copy->pasting timetables is quite easy to implement. But except that specific use case I do not see any other use case. Even in that case, I think that copied timetable should still be in sync with original, etc, etc. You can see this gets complicated very fast. It is one thing if you intend to use it yourself, but publishing is the other thing entirely IMO.
Cadde
Transport Coordinator
Transport Coordinator
Posts: 290
Joined: 07 Oct 2004 12:51

Re: JGR's Patch Pack

Post by Cadde »

ino wrote:Unless I am understanding something wrong, single-track line can be run quite efficiently using vanilla OTTD, or using slots added in this patch pack in 0.19.0 (Slots would allow some advanced routing e.g. allow train in same direction to follow each other immediately). Precise timetable would only reduce waiting time. I have played with many single track using scheduled dispatch and if you are very organised (I have full timetable in paper for planning) it should not be a problem. I even have a few fully saturated single-track line running without problem.

IMO, traditional timetable tends to slips a lot and can be messed up easily. Scheduled dispatch allow a proper "reset" to be performed, so that entire timetable and various sync point you create are still valid even though some junction reconstruction messed up timetable of all running trains.
Yes, if you only have to care about trains getting from A to B eventually then vanilla OTTD without timetables can still operate on single tracks efficiently. But as soon as you put express vs snail cargo into the mix it gets complicated at best. That's why i use timetables as a guide for exactly when and where a train is going to pass at a station etc.

Maybe i need to figure out how slots work and also figure out a different approach to using timetables at all.
Mind you, my single track line is currently occupied by 6 trains permanently in a figure eight configuration.
2 slow passenger trains that conveniently meet at a station in the center in opposite directions at roughly the same time. They spend some time waiting in each loop to ensure they arrive at the center at exactly the same time. If one of them managed to enter the loop before the other one has passed, they would not be able to proceed. I would have to manually resolve.
2 express passenger trains that have terminals at diagonally opposite ends who skips any stations except the center one. These leave as soon as there's a gap left by the two slower passenger trains.
2 freight trains that follow the slow passenger trains as closely as possible and terminates at the same stations as the express trains. These will have to give way to passenger trains or i would get zero payment for passengers.

Neither of the passenger trains have any room for any waiting once they go. Once they have passengers loaded they have to move as quickly as they can until they don't have passengers anymore. At the ends of the loops i am unloading all passengers so the time ticker stops ticking on the cargo until i pick them up again and keep on moving. (btw, time is too limited in the game IMH. Being represented by a byte for cargoes just doesn't cut it. 637.5 minutes before the cargo calculations end is just not long enough!)

I am not running your default cargo payment calculations mind you. If passengers are delayed for whatever reason, which is also distance sensitive, then i don't get paid at all.
See here: download/file.php?id=198369
From this thread: viewtopic.php?f=26&t=76518

If all these conditions could be met using signals alone then i would be a very happy camper. But your little patch surely is going to make it easier to set up the timetables and reduce lateness if there's any disturbances on the line. But other than that little thing, i don't see how it improves the situation that much as it operates like a clock until you disturb it and it's set up to correct itself by waiting an excessive amount of time (no loading) at the "ends" of the loop. I would still love to run with required maintenance but only every 24 hours, not every 3 hours as that feels so unnatural and wasteful to me.
ino wrote:Technically, copy->pasting timetables is quite easy to implement. But except that specific use case I do not see any other use case. Even in that case, I think that copied timetable should still be in sync with original, etc, etc. You can see this gets complicated very fast. It is one thing if you intend to use it yourself, but publishing is the other thing entirely IMO.
I don't get what you mean by in sync? I am talking about taking the whole current order list and making a duplicate of it at the press of a button. So if i set up a time table that takes 3 hours to complete, then i can press that duplicate button 4 times to make it a 24 hour timetable. Then i can manually remove the last 3 hours of the timetable to deal with going to depot instead. At that point, i would alter the town and industry GRF's to have highs and lows in production. The number of passengers for instance would be reduced during nights so that would be the perfect time to send passenger trains to depot for maintenance.
Even if it was just a hidden little button somewhere that did this i would be very happy.

But even better yet would be if one could press a button that puts the current order and timetable into clipboard. The clipboard contents would hold mostly raw data. Station ID's and their XY's, the vehicle's parameters, current schedule and it's lateness and such.
Then another button to append that raw data back into the vehicle's orders.
Because then i could use an external application to do everything i wanted with that vehicles orders. Such as pre-emptively assign guesstimated travel times for those distances rather than using autofill. And i could adjust the timetable as the vehicle is early or late using the terminals and waiting points etc.

Or in other words, as long as i don't have to do C++ i can do quite a lot of things. Sure, i can technically make C++ happen but i'd rather eat a bag of razor blades.
Cadde
Transport Coordinator
Transport Coordinator
Posts: 290
Joined: 07 Oct 2004 12:51

Re: JGR's Patch Pack

Post by Cadde »

Ok, i've played around with the scheduled dispatch feature and i'd say i like it. The functionality as such is great to have.
I like how you've added information about how many vehicles are needed to satisfy the duration. And the fact that one can use automate on the timetable and just leave the rest to the scheduled dispatch feature is pretty neat!

But unfortunately, there's a few issues i have with it currently...
  • It's somewhat unintuitive. It took me longer than i expected to know how it's used. I guess with some documentation it would be alright but i had to just try it and hope for the best at first.
  • The "Delay" button has the same tooltip as the "Start date" button.
  • Departure boards become practically useless when using this feature. I have a proposed solution for that below.
  • Having just one point to adjust from makes it difficult at best to make it so vehicles meet at the middle. Optimally, one would be able to set scheduled dispatches on select stops rather than just the starting one.
How i imagine departure boards can be fixed
Instead of setting the start date on the vehicle in question, how about setting the travel time of the last order so that the expected arrival time matches the slot? This travel time is adjusted EVERY time the vehicle departs from the last item in the order list.
If there's shared vehicles, this would be kinda difficult though. So another alternative is to ensure that the timetable for the vehicles at least matches the duration of the scheduled dispatch by altering the last travel time no matter what. But then, if possible, make it so that once a vehicle arrives at the first station it's early/late stat is set?

Either way, setting the start date and using automated timetables makes departure boards useless. I would very much like to be able to see just when a train will arrive at a particular station so i can adjust the departures accordingly to avoid conflicts. Otherwise i might just as well use regular timetables again.

---------------------------------------

Also, i understand how slots work now. But it's not going to help me as, like i said, i have to ensure the track is clear all the way to the end for my "express" cargo. My passenger trains are obviously express at all times. But my freight train is also considered express when they carry food. That is, at the middle station in my figure eight loop, the freight trains also pick up food. They mustn't want for anything until they reach the final stop in their respective branches. Then and only then will they make way for passenger trains on their way back towards the center station.
EDIT: Oh and once loaded with perishable cargo, they need to go. If i could ensure they only fill up once the track is clear ahead then that would be swell too. But i really don't want to make any ugly solutions for that purpose. Remember that i only have one depot nearby and that setting the train on a siding could work but wouldn't look and/or behave the way i want.
I didn't mention before, but my map is mountainous as well! Here's the heightmap: https://puu.sh/wuk2C/9bd48adde2.png

Allow me to illustrate:
Image

All lines are single track. The express endpoints have 3 tracks, one bi-directional for snail passengers, one terminal for express passengers and one ro-ro for freight.
The express passenger trains only stop in the center as i said.

So basically, if i relied on signals to ensure trains could pass each other then there would be trains loaded with passengers or food waiting and that would either severely reduce or completely nullify any income i could make off the route because of how my income mod GRF is set up.
Basically, the trains just barely make it in time to not start losing income due to expiring cargo.
The only solution i can see for that particular loop is strict timetabling and unloading passengers on the snail line when the train is about to stay for more than 4 minutes at a station. Currently they wait a bit extra to allow them to recover from any disturbances. The whole loop runs on a six hour duration.

So, if i were to start using maintenance in that loop i would really need to be able to duplicate the very fine tuned schedules i have for the whole 24 hour duration where the trains would go to depot once in those 4 segments. All strictly timetabled of course.
Butt... I can see how it would be sorta possible to achieve that with scheduled dispatches and a conditional as long as the scheduled dispatches allow me to set the dispatches for each stop rather than the whole order. ;)
ino
Traffic Manager
Traffic Manager
Posts: 152
Joined: 09 Apr 2017 14:58

Re: JGR's Patch Pack

Post by ino »

Woah that sure is a wall of text.
Cadde wrote:It's somewhat unintuitive. It took me longer than i expected to know how it's used. I guess with some documentation it would be alright but i had to just try it and hope for the best at first.
I sucks at UI. I know it is quite intuitive. By all means please throw suggestion.
Cadde wrote:The "Delay" button has the same tooltip as the "Start date" button.
Thanks. Will fix.
Cadde wrote:Departure boards become practically useless when using this feature. I have a proposed solution for that below.
Your idea does not works for the same reason you state. Having length match would also not fix the departure board properly as you can have much more vehicle than it is required. I have a few idea now, will see what I can do about it. (It involves fixing the departure board instead)
Cadde wrote:Having just one point to adjust from makes it difficult at best to make it so vehicles meet at the middle. Optimally, one would be able to set scheduled dispatches on select stops rather than just the starting one.
I have said it already, it is NOT hard from implementation standpoint. It is the UI that is problematic. And things get complicated very fast after that. I could implement a schedule for every stops tomorrow from the operation point of view. (Just for reference, I spent like 80% of development time for that patch on the UI elements alone). Moreover, I still cannot figure out how to calculate the number of required vehicles efficiently (O(n log n) or better) with multiple scheduled points either.

----

I do not know how other developer/patch developer/JGR thinks, but IMO a published patch SHOULD be beneficial to a lot of people. Simple copy-pasting is not. Ability to copy-paste from external program is, but is quite complicated IMO (there are too many edge cases). Ability to define a reference timetable and refer to it multiple time in vehicle timetable also is, but is even more complicated. Simple copy-paste is not hard to implement and is quite straightforward. You says you have background in programming and have a lot of feature you want to implement. I would really suggest you try to implement it yourself. Then you can customized it however you want without other people inferring. People have vast different expectations when they come to how each feature should be implemented.

Regarding your game, I still don't understand. Traditional timetable works, and scheduled dispatch is just a compliment to timetable. Why wouldn't it work for you? You have timetable on all vehicle designed to pass each other at loops already, schedule dispatch would just make it much more certain that your train would arrive at loop exactly when you want?
Cadde
Transport Coordinator
Transport Coordinator
Posts: 290
Joined: 07 Oct 2004 12:51

Re: JGR's Patch Pack

Post by Cadde »

ino wrote:Woah that sure is a wall of text.
I have been known to do that yes.
ino wrote:I sucks at UI. I know it is quite intuitive. By all means please throw suggestion.
I get it, i suck at it too. And i would suck even more at it in OTTD so kudos!

Rather than calling it "slots", i would call it "possible start dates" in it's current implementation. But that's too long for the button so the tooltip could reflect this instead. But this one is not that important.
Rather than calling it "duration" i would call it "cycle" with a tooltip that reads "Repeats this pattern of start <dates/times> on arrival at the first station in the orders". (where <dates/times> is dependant on the current game setting "show time in minutes rather than days")
Fixing the "delay" button tooltip should suffice. But maybe call it "Maximum delay" ?
Replacing "Start Date" with "Base <Date/Time>" might help. Changing the tooltip to read "Sets the base offset <date/time> for this dispatch cycle. All start <dates/times> are adjusted in accordance with this."
And the "Reset last dispatched" button, i haven't even tried it yet. But i assume it resets the late counter on the last vehicle to arrive at the first order? Question is if this button is even needed?
ino wrote:Your idea does not works for the same reason you state. Having length match would also not fix the departure board properly as you can have much more vehicle than it is required. I have a few idea now, will see what I can do about it. (It involves fixing the departure board instead)
I fail to see how the second option i state wouldn't fix it? If the timetable order is fixed at the duration of the dispatch then all vehicles being dispatched (by forcibly setting their early/late counter on arrival at first order) means the departure board would show the trains arriving every base+slot(s) times down the line.

Here, let's try my idea manually. First, this is the "ideal" situation using dispatches.

Image

The train is on a 20 minute timetable (which in reality takes 14 + some ticks minutes to complete), the scheduled dispatch is on a 20 minute cycle. All is well, if the train would stop for 6 or 7 minutes it would get adjusted to the next slot accordingly. Whereas without dispatches it would be 1 or 2 minutes late.
But now, let's change the timetable (say one uses automated timetables or the timetable wasn't set up the same as the duration of the dispatch schedule) so that travel time is ACTUAL.

Image

The departure boards show all incorrect information. The timetable on the train also shows incorrect information.

Correcting this manually is "easy" but... Manual! But let's do it!
I will take over control as the "dispatcher". Then i will adjust the last travel time so that the train will arrive at NORTH on 20:20 like it should.

Image

It's already looking great. Both the timetable and the arrival is spot on. As the train calls in to NORTH, the departure boards will adjust accordingly.

===================================================================================================================
But after departing NORTH, let's simulate a late condition: (This is my second attempt btw, i normally don't have leftover ticks in my timetables, but this time i am actually going to do it using ticks to simulate what end result i want from the dispatcher.)

Image

Here's my process, first gathering facts and then adjusting accordingly... This one is very easy because the train is already technically "on time". It's start date is in sync.
  • A 20 minute timetable is supposed to take exactly 1480 ticks.
  • The actual travel time around the loop is 1054 ticks (14.24324324 minutes)
  • We are therefore 426 ticks (5.756756757 minutes) early arriving at NORTH every time when not delayed.
  • We are currently (above screenshot) 552 ticks (7.459459459 minutes) late.
  • Since we will arrive 426 ticks early in normal conditions, our actual lateness (should we have arrived on 01:40) is 126 ticks. (1.702702703 minutes)
  • Now, we want to SKIP to 02:00 because we are late. We missed our "slot". All we have to do really is add 1480 ticks (20 minutes) to the travel time here.
    Image
  • And as the train has arrived at the station at this point, we can change it back to it's regular timetable with 723 ticks in the last travel time.
    Image
That's what i want the dispatcher to do. As you can see, the departure boards are pretty much unaffected by this little modification.
In other words, if the train was SUPPOSED to arrive on the dot but didn't, then add as many durations to the lateness of the train as necessary to make it skip.

===================================================================================================================
Now, let's get even trickier! What if the train isn't even set to arrive at the correct time?
Image

As you can see, the train is set to arrive at 03:28 next. I want it to "arrive" (timetable wise that is) on 03:40 (it missed the 03:20 slot) So i will have to add 12 minutes (888 ticks) to the last travel time, or in other words. Make it take 1611 ticks rather than 723 ticks.
Image

We are just about to arrive, as you can see from the departure boards in this BRIEF (where the aim is for it to be even briefer) moment of adjustment, the times are not really lining up.
But as the train arrives at the station, we set the travel time back to what it needs to be to complete a 20 minute cycle.
Image

And voila! The timetable is purrfect!
If the dispatcher could do these adjustments just as the train has arrived at the stop then that would be swell. Always ensuring that no matter WHAT, the last travel order(s) before a dispatch operation is ensuring the timetable matches the duration of the dispatcher. Or whatever divisor thereof if the slots call for it.
And of course, setting the early/lateness of the train appropriately.

If i were the dispatcher and i had to do it manually then that's how i would have done it. To me it doesn't matter if there's one train or a hundred trains on that schedule. I would like them to have timetables that are as close as possible to their next arrival and then they would adjust accordingly.
I get why you think it shouldn't work if the duration is say 60 minutes rather than 20 minutes. It takes less than 20 minutes for the train in my example to complete the cycle. Basically, i want the dispatcher to be smart enough about it to where it can figure this out. Because i want the departure boards to be useful again, even when one has chosen "automate". As it is now, i have to not use automate and still manually set the last travel time... Which is manual work regardless. The only benefit of using the dispatcher is the "slot skipping" on the fly capability. And to be frank, i don't really care too much about that ability anyways as i generally end up with perfect (no conflict) timetables rather quickly without too much manual work. The real PITA is getting a good baseline round trip time. Which is why copy-pasting the orders with their XYZ coordinates as well as some details about the train(s) that will fulfill that order would be helpful, then i could guesstimate using C# (because C++ is really pointless to me) just how long the slowest and heaviest train should take to go around the loop if it encountered no restrictions on the way. It wouldn't be a perfect guesstimation but it would be a baseline that i can then use to ensure they departed when there would be no conflicts down the line. Then i can just press Automate to get an actual timetable filled out for the current load. And of course, adjust the last travel time after that to make it line up neatly in departures.

I have said it already, it is NOT hard from implementation standpoint. It is the UI that is problematic. And things get complicated very fast after that. I could implement a schedule for every stops tomorrow from the operation point of view. (Just for reference, I spent like 80% of development time for that patch on the UI elements alone). Moreover, I still cannot figure out how to calculate the number of required vehicles efficiently (O(n log n) or better) with multiple scheduled points either.
I know all about UI, trust me. I suck at it too and i can only imagine how painful it is to do that in OTTD and on C++ to boot.
As for the number of required vehicles, as i see it. It should be based on their current timetable. The assumption that the timetable will take 20 minutes and you've set the duration to 60 minutes with 6 slots means there's going to be a slot every 10 minutes (guesstimate here ofc) means that you need 20 / 10 = 2 vehicles to satisfy it. It then doesn't matter how many dispatch orders there are... assuming the timetable itself reflects this, which it would if the travel time before each dispatch order was adjusted accordingly... as it's just a matter of taking the timetabled duration and dividing it by the average minutes between slots on the first order.
Unless of course (which is quite possible) i am completely mistaken...
You says you have background in programming and have a lot of feature you want to implement. I would really suggest you try to implement it yourself. Then you can customized it however you want without other people inferring.
And as i said, i'd rather eat a bag of razors. The extent of "programming" i have done in OTTD is disabling stuff i don't want and rewriting a few formulas that i felt were wrong.
I would never in my wildest dreams consider adding something to the game. If it were C# or any other SANE environment and every statement wasn't "like_do_this_thing_that_it_does(20 << 4 % 5 * 1337)" then maybe.
There's just so many insane practices inside OTTD that i try to avoid it as much as possible. And that is ON TOP of it being C++ which in of itself is a very poorly organized and overcomplicated way of doing things.

Heck, even Minecraft in it's obfuscated form is easier for me to understand and work with than OTTD sources.
Regarding your game, I still don't understand. Traditional timetable works, and scheduled dispatch is just a compliment to timetable. Why wouldn't it work for you? You have timetable on all vehicle designed to pass each other at loops already, schedule dispatch would just make it much more certain that your train would arrive at loop exactly when you want?
Well yes, it works but it doesn't add anything because i still have to manually set all that up. I really truly honestly don't see the point at that point, it just adds another complexity on top of everything i've done.
The timetables are set up so that regardless of how late the trains are, they will eventually work their way back to what timetable they should have. And the departure boards reflect this in real time.

What i meant though is, neither signals nor dispatches solves the main issue. The trains have to pass each other at EXACT times in the center and in case of freight, at the points before the center.
But if the dispatch feature had multiple dispatch orders per timetable then it would definitely be useful as i could at least exploit that feature while setting up. Then it could hang around anyways because there's no harm.

One danger of using the dispatcher feature is that IF say train A of the trains that's supposed to meet in the middle is late but train B isn't. Then train A is going to skip a slot while B hasn't. This means B will go up the loop and get stuck in a mexican standoff with the delayed train, whom also can't move as the only platforms they are allowed to go on is the passenger platforms, not the freight ones. (routing restrictions)

Now, sure... I could make train B wait in the middle using some signal restriction logic as well. But then that would in turn mess up all other trains that's supposed to stop at the middle.

In other words, i am better off having some slack in the timetables and do my darndest to ensure they are NEVER disturbed in the first place. And if i change the parameters of their timetables in a NEGATIVE manner, then i have to re-do it all from scratch.

... But, if you can show me an example of how all the limitations i have in that loop could be solved with less work than manually filling up the timetables and setting start dates then i am of course forever grateful!
There's just too many parameters for me to see any other solution than meticulously setting the timetables up so no train ever has to wait for another to pass while they are in "express mode".
The problem could easily be solved if i went from single to double tracks. But that would cut a LOT into the profit margins i have due to track maintenance.
ino
Traffic Manager
Traffic Manager
Posts: 152
Joined: 09 Apr 2017 14:58

Re: JGR's Patch Pack

Post by ino »

I admit I did not read that entire wall of text this time (or last time, for that matter). This is probably the last post I will made regarding this subject with you. Note that this is purely my opinion and is not of JGR's.

1. Your method of manipulating timetable for departure board fall off entirely if your schedule is not evenly spaced. Say for duration of an hour, if you have departure at :00, :15, :40, then obviously there are not same cycle every time. And I did say I have another approach in mind already. Either way, it is not going to be done and release soon. You know how to program, so you must know that anything that seems "simple" usually is not very simple at all in code.

1.1 And your way is not even how real world dispatcher do it. You have scheduled arrival time and departure time. You cannot take all your time travelling because there might be other train needing to use that piece of track. But that is irrelevant here as OTTD train does not slow down to arrive at the exact time anyway.

2. Required number of vehicle calculation isn't even that simple to begin with, nor will it ever be. It is better to not do show this number at all if you cannot calculate it accurately IMO as it can be damaging if it is lower than the actual value. Remember that departure may not be evenly spaced out. The current algorithm is here: https://github.com/JGRennison/OpenTTD-p ... #L120-L144 It is pretty straightforward without C++ "magic".

3. In my very personal opinion, if you have to rely on timetable to make sure train does not deadlock then something is seriously wrong. Timetable is only to ensure that things go smoothly, but if anything happen the signal system need to prevent conflicting train movement. Even though in real world human operators are responsible for this, I find that using various tricks with PBS and routefinding restriction (long reserve, reserve through, and slots) make this quite possible. We may never agree on this and everything I say won't be valid for your game.
User avatar
JGR
Tycoon
Tycoon
Posts: 2557
Joined: 08 Aug 2005 13:46
Location: Ipswich

Re: JGR's Patch Pack

Post by JGR »

At present departure boards do not know about the scheduled dispatch feature. This should not be too onerous to correct, and ought to be simpler and more robust than making timetable length adjustments.
ino wrote:...I could implement a schedule for every stops tomorrow from the operation point of view. (Just for reference, I spent like 80% of development time for that patch on the UI elements alone). Moreover, I still cannot figure out how to calculate the number of required vehicles efficiently (O(n log n) or better) with multiple scheduled points either.
Not calculating/displaying a vehicle count estimate when there is more than one scheduled dispatch order would be entirely reasonable IMO.
Cadde wrote:It's somewhat unintuitive. It took me longer than i expected to know how it's used. I guess with some documentation it would be alright but i had to just try it and hope for the best at first.
This is difficult to avoid, especially for niche advanced-user features like this.
Cadde wrote:But even better yet would be if one could press a button that puts the current order and timetable into clipboard. The clipboard contents would hold mostly raw data. Station ID's and their XY's, the vehicle's parameters, current schedule and it's lateness and such.
Then another button to append that raw data back into the vehicle's orders.
I'd rather not do this, personally. I don't really want to turn the game into something that you need to use a spreadsheet to operate.
Cadde wrote:If one of them managed to enter the loop before the other one has passed, they would not be able to proceed. I would have to manually resolve.
This is asking for trouble. I'd suggest that you look to make your layout deadlock-free first, and then timetable it to minimise waiting as a secondary priority.
Cadde wrote:Or in other words, as long as i don't have to do C++ i can do quite a lot of things. Sure, i can technically make C++ happen but i'd rather eat a bag of razor blades.
That is fair enough, however developers (C++ and otherwise) only have finite quantities of free time which they therefore need to prioritise.
Ex TTDPatch Coder
Patch Pack, Github
Cadde
Transport Coordinator
Transport Coordinator
Posts: 290
Joined: 07 Oct 2004 12:51

Re: JGR's Patch Pack

Post by Cadde »

JGR wrote:
Cadde wrote:But even better yet would be if one could press a button that puts the current order and timetable into clipboard. The clipboard contents would hold mostly raw data. Station ID's and their XY's, the vehicle's parameters, current schedule and it's lateness and such.
Then another button to append that raw data back into the vehicle's orders.
I'd rather not do this, personally. I don't really want to turn the game into something that you need to use a spreadsheet to operate.
And yet here i am, using a spreadsheet to help with calculations for timetables. ;)
Also, i thought OTTD was just a side quest to EvE Online? :P
JGR wrote:This is asking for trouble. I'd suggest that you look to make your layout deadlock-free first, and then timetable it to minimise waiting as a secondary priority.
Yes, you are right. Even with a perfect timetable i should make it deadlock free first and foremost. But i need to get better at using the new signal features first.
BTW, is there any way to reserve through before a train has left a station but NOT while it's waiting for it's time slot?

Also, i am not suggesting anyone goes out of their way for my wishes. If people ask for feedback and i feel like giving it, i will give it.
Usually in the form of text walls.
ino
Traffic Manager
Traffic Manager
Posts: 152
Joined: 09 Apr 2017 14:58

Re: JGR's Patch Pack

Post by ino »

I have added a (complete?) documentation to Scheduled Dispatch to this post. Perhaps it should also be linked from the front page?

I have a feature request. I would perhaps go around to implement this eventually but maybe someone already has something like this in progress. I want ability to make train (and it's shared order group) a color similar to RouteMarker patch. However, instead of having marker signal I think it should be integrated into trace-restrict. This would allow me to, say, mark express train as Red, semi-express train as Blue, local train as Green, freight train (which, in my game, never stops at passenger station) as Gray. So large station where train can pass each other can have simpler signalling. My current methods is to just next order/current order/last visited station to identify type of train, but in some piece of track this does not work perfectly and I have to resort to waypoints. Group name does not work because in large station so many line converges, which is, of course, from different group.

--------------
Cadde wrote:And yet here i am, using a spreadsheet to help with calculations for timetables. ;)
A lot of people do that, including me. However, as JGR said, it is not an OTTD functionality.
Cadde wrote:BTW, is there any way to reserve through before a train has left a station but NOT while it's waiting for it's time slot?.
You mean to canceled a previously reserve path? I do not think that can be done. However, if you describe how you want your train to behave (preferably without wall of text) people might be able to help signal it.
User avatar
Gwyd
Chief Executive
Chief Executive
Posts: 721
Joined: 17 Apr 2017 16:52
Location: Western Ile-de-France Region

Re: JGR's Patch Pack

Post by Gwyd »

I've successfully used different groups to tell trains where they can go. I set the way finding restriction for a signal "If group is not (allowed group a) then
Deny
If group is (allowed group b)
Allow (undo previous deny)
Or if...."
This system works perfectly well for me, splitting fast and slow trains, and deciding where trains go at termini. It also allows track plans to be "less obvious" to the wayfinder or more realistic.
Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: No registered users and 8 guests