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.
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.
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.
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.)
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.
- 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.
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?
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.
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.
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.