How to make Display Boards showing information from Time table about arrival and departures from specific platform?
Hi DTG Matt , I am having issues getting some trains to load passengers after a stop at a terminus station. For a full description of the issue, see this topic. Any chance you could let me know if this is a known issue and if there's a workaround I can use? I've now been stuck since Sunday to make further progress on my 2024 Main Spessart Bahn timetable and I 'm slowly getting out of ideas to fix it, other than scrapping the RB88/RE87 layer.
So after further fiddling I found adding the DLC input of the vehicle somehow breaks the timetables with layers?
This falls in the category of "silly mistakes," but if a service fails to ever reach a station, make sure the Go To Condition is set to Within, not Overlap. Assuming the train is shorter than the platform, it can never overlap the platform and the order will fail to complete. This caused me some headache today and I thought I'd mention it for anyone searching this thread for a similar issue.
I'm having an issue where only "spawn on foot" is showing up, and I keep getting a "warning message" for services that interline with each other saying it's a slow path find. What does that mean?
Slow path find doesn't mean services interfere with one another. It means it took the Editor a while to find the best route from one waypoint to another. That usually happens if two waypoints are very far away from one another or there are many different possible routes between them. Adding a Go Via or two can help, as can selecting the "mainline only" checkbox on instructions or specifying an "initial path find direction". That said, it's only a warning, not an error. Your timetable will still work, it'll just take a little longer to compile it.
Has anyone else been having a weird bug where a train slows down to 2 mph entering a station and then gets stuck for no reason? The signal ahead is green.
I'm not sure, this is what the log says: LogTSWAI: TS2AIController::LogTargetConditionStatus: [TOD] +08:47:54.900, [TargetSpeedCondition] Stop Destination, [Service] Train 4205: Grand Central - Wakefield, [Location] Lat: 40.82488, Lon: -73.91638, [CurrentVelocity] 0.00m/s
Ok for those of you that are doing timetable, I highly suggest not selecting front or back for stop markers because that's gonna break the AI. Not sure why that happens.
Would anyone happen to know how to use the start time, date and simulation time function? I'm trying to start my timetable at 0100 AM Doing it this way causes the simulation.bat file to start at 23:00 hours, which is incorrect.
The Simulation Start Time, is a Date/Time field, that is relative to your time zone. For example at the moment it says 4PM your time zone. The format is YYYY.MM.DD-HH.MM.SS +/-HHMM - from UTC. This is the International Date Format. Now the Frontend Starting time is not relative to your time zone, it's time you want it to be in the route. So if you want 1am, your Frontend Starting time should be 01:00:00 Because you're 5 hours behind, your Simulation start time would be the the day before, at 2024.02.18-20.00.00 -0500. You could also try changing the Simulation Start Time to 2024.02.19-01.00.00 +0000 (I've not tried that so not sure if that'll work) Note: You must put the same time in your scenario definition as your timetable. Also if this is scenario, you can change the Simulation time to something shorter than 10 hours as it's currently set. Maybe an hour longer than the length of the scenario. If it's a timetable, set to 36 hours to allow it to simulate properly and diagnose any issues of trains running over the 24 hour period.
Hey guys, I got some problems when simulating my timetable for BRO. Only 6 services are completed, 69 still running and 292 did not even start. Would be glad if someone could help. I'll attach the replay screenshots: Link to Log file (too big to attach)
Matt's very first post in this thread explains how to use the log and replay tool to diagnose this sort of thing. Did you try and do that?
Yes, but all the timings are correct and the expression "TargetSpeedCondition\] Stop signal" didn't bring any result.
"Stop Off Path" is another one that you should look for if this sort of thing happens. When that occurs, that usually means something is wrong with a "Go To" instruction and the simulation can't complete it. That train is then stuck forever. "RE_18_82346_Lr" has a "Stop Off Path" TargetSpeedCondition, starting at 03:47. Try finding the instruction that causes the problem. If it's a "GoTo" instruction at a platform marker that's set to "overlap", try setting it to "within" instead. That usually resolves this issue for me.
Thanks, I'll try that now. Simulation is in progress... So, it kinda helped a bit. Now I got the following service numbers: Completed: 6 > 88 Still running: 69 > 65 Not started: 292 > 214 The weird thing is, that I did your step for every Service, but it only made a huge difference on most of the RB 58 services. I still don't get, what the problem could be...
We can't see much on this screenshot but I'd investigate RE_18_32300, as it seems to be the first service that gets stuck (thick line doesn't end). As mkraehe#6051 said: check the individual instructions of this service and see which instruction has a simulated arrival or completion time of 0:00:00, which means the issue happened at or just before this instruction. Don't forget eventual bad dependencies. If it's not a clear error (e.g. location not correct), right click the instruction before this one and select 'view on playback'. Then go the playback tab and let it run (on a faster speed of e.g. 15x) until the train gets stuck. Pause the simulation, press space and look for what 's blocking the service. If it's another service then repeat this process for that service until you've found the bad instruction. Fix it (and eventual copies of it in other services) and resimulate.
Yeah, it's perfectly normal that new errors pop up after fixing old ones - trains will get held up by one issue before they have a chance to reach another problematic instruction. You'll simply need to keep repeating the process (find the first train that has a problem - figure out what the problem is - fix it and any copies of it - resimulate) until everything works.
I do wish there was a way to simulate parts of the problematic timetable so we aren't stuck simulating all day for a simple problem.
You can simulate less than the full timetable: reduce the simulation time in the timetable settings. You won't get a finished log file, but you do get datatracks for the services that started so you can manually sort out issues. I don't recommend this, but if you want to speed up finding the cause issues you can try it this way. This is why it's best to make gradual changes, test them thoroughly and only then start copying services or instructions.
That's the way to do it. My two hour test timetable is really quick to simulate, even though it's quite busy.
You can also use the .kill command by placing an empty file in the same folder, with the same name, as your timetable. This will leave you with the data tracks and log file, just make sure you remove the .kill file after it has ended!
My approach on my timetable: breadth-first, then depth. So I first did each type of service pattern once to get the needed times correct, then one full hour so I can identify any blocked path problems. The full timetable will only come once I know that everything I have works and can be repeated x-times. The spreadsheet helped identify stops where I cannot allow dispatch beyond because it would otherwise block AI trains from entering the mainline. In those cases, I didn't have a timing problem but the player service blocked the route too far ahead of itself, preventing those AI services from entering that area long before the player service.
I wish I new this command before. It's so useful instead of having to wait until the timetable has completely finished. I didn't immediately find any other documentation on the .kill command, so some pointers that are a bit more clear: if your timetable is called My_Timetable then you have to place an empty My_Timetable.kill file (just make one via e.g. Notepad++) inside the content folder of your Timetable (next to My_Timetable.uasset). Thank you very much for this pointer!
I just make a copy of the timetable file and then rename it. That has the same effect, but isn't the best practise way of doing it.
Does anyone else frequently get "longer than expected" errors like the following? Code: TS2Editor: Service 1F17 Ore to London Victoria longer than expected at instruction 0. Expected length 16050.72cm, actual length 16119.41cm I have hundreds in my timetable. Some are partway through a train's instructions and don't seem to be a problem, while others (like that quoted above) are at the start of instructions when a new service changes direction from the previous service. This generates a lot of "Unable to acquire initial track section" errors before it eventually works. Is this normal, or am I doing something wrong?
I have them too but have not encountered issues because of them. If path finding is an issue, try moving the stopping point a bit so you account for a slightly longer formation and the back has definitely passed the initial main signal of the return service. I'm surprised that a difference of only 69cm causes issues, I have differences of more than 20 meters on long freight formations.
FYI: "Spawn on foot" in custom timetables is now broken since the June 3rd patch. It was previously possible as long as you define all formations within your plugin. I have raised a ticket with DTG support.
I have an issue with creating services for Ruhr Sieg Nord in the editor. I created a new plugin and started creating a timetable following the official tutarial on YouTube. While trying to create services the following issue appeared: Once I add a "Load/Unload" instruction for a passenger service and compile the timetable an error appears. It says, that the "Load/Unload" instruction does not know where the doors of the train sould open because the platforms do not provide this information. At first I thougt I just picked the wrong spawning location for my formation, but it turned out to be an issue at every station on the RSN route. Is there any possibility to solve this problem (or maybe to somehow manually tell the "Load/Unload" instruction on which side the doors should open)?
Have you used a "Stop At" instruction at the platform before the "Load/Unload" so it looks like, Stop At P1 -> Load/Unload P1 -> Stop At P2 -> Load/Unload P2 -> etc In the Load/Unload menu there is an option to specify "Door side" (Auto, Left, right, Both).
I have two questions; Is there a way to force a specific destination to display as the "passenger terminal" even though the service ends at a yard? And I keep having backwards stop markers (the red yellow and green track highlights) for some odd reason.
I am having an issue. After I simulate, I play in editor and its like nothing happened. It completely ignores the data track. Also, the has valid data track option is grayed out.
Was the simulation running through without hitting the time limit? Only if it was fully simulated, the valid data track will be set. And only if you absolutely changed nothing at all that requires compilation. As soon as you do that, even if you revert that change, the valid data track setting will be gone.
It seems like a layer was broken and didnt simulate the service. I removed it and am currently running a re-simulation now.
Question regarding yards junctions switches, can they be switched by the ai service? Or is there an option to enable Ai changing the junctions automatically?
Since a few weeks I am getting more and more issues with random services failing to open or close their doors while simulating the timetable. As my timetable takes over three hours to simulate now, I tend to let it simulate overnight and automatically shutdown the pc after it's finished. This makes opening the log file feel like playing Russian roulette, because about 75% of the time it simulates fine, but once in a while the timetable has failed to simulate properly because one service failed to close its doors. I have encountered this so far with the NRM DB BR 425, MSB DB BR 766/146.2 and MTB DB BR 642. It's always a different service that fails, so I can't point it to one instruction not set up properly. Has there anything changed that might be causing these issues? Is there something I can do to prevent it? Has anyone else encountered this issue?
I have this issue on my RSN timetable with 628s in Hagen Platform 4, some will work just fine and others will get stuck. Since they're AI services, I ended up just setting it so it doesn't open the doors. Weirdly though, it will sometimes not work when it arrives, but when it forms the next service the doors will open just fine. It's quite frustrating to deal with and really lengthens the timetable making process.
How can I fix this error. the first service starts at 00:00:05 when I change the day it is still one day difference
Any reason why you are stimulating the timetable for 36 hours. The service is being simulated twice. I'd caution going over 24 hours Simulation Time. Also check your Simulation Start Time if you would your timetable to start at 00:00. Set this to 2024.09.17-00.00.00 +0000 (it will change to the correct start time in your time zone).
