There's probably going to be multiple of these over time, but thanks to cadeshr6s I've had a good example to work through and thought i'd use it to showcase the approach as there's lots of common stuff here to get started. The ultimate problem was quite straight forward, but I'll use the opportunity to show looking in to other areas and findings from the log etc. I use a toolset called BareGrep and BareTail which can be downloaded from Bare Metal Software, i've paid for the paid-versions of them but there are free versions that are perfectly usable. There are also other tools out there that do a similar job, i've just not found one that works as slickly or as fast as these do. BareGrep is for working on finished log files, BareTail is for working on a log that is continuously updating - Grep offers some quite advanced functionality for the bold and the brave, BareTail is simpler but whats cool is that it's doing it as the log file is updating so you can get real time updates on the progress of the simulation. Anyway - those are the tools I use, in this case it's going to be BareTail I grabbed shots from as that's mostly what I use for debugging timetable simulation logs. So - cadeshr6s asked me in another thread to help understand why their timetable wasn't working and couldn't see what the issue was. Not much more info needed than that to be honest, timetables kinda work or they don't - the trains aren't appearing when you run the game, why? I started by loading it into the Playback tool (I'll cover how you access that shortly) to see how the data tracks are looking. That doesnt look happy at all - all those services are apparently taking many hours to complete. I also found this oddity which i've never seen before - notice the bright white line is broken, that should NEVER happen at all! Something is clearly wrong with the data track, so i'm going to do a resimulate on the timetable in a mo but let's look at the log first - remember a sim is going to cost you maybe an hour or two of time so it's worth understanding as much as you can first. Finding 612 and 614 on the playback tool output, you can see they're both dots (means they arent doing anything) and they're both at exactly the same point vertically - which means they're doing nothing at exactly the same time. Gut feeling? Portal spawns are simultaneously happening, which won't work. Let's dig in and see more. They also provided me with the log file from their last simulation of the timetable so I started with a quick look at that. One of my first ports of call with any simulation log is to look for a very simple expression "TargetSpeedCondition\] Stop signal" - this is looking for lines where a train is unable to move because it's blocked by a signal. It's the single most basic issue that can cause problems, and in this case i'm looking for if there are notable problems - and as you can see, there's one train causing problems here. ICE_614_AI is stuck and can't move. Why? Click on the line and in BareTail it will jump the log to show you the detail near that line (you may need to click it to zoom it up so you can read it) Ok lots of jumbled info there but the key thing to look for is "Status for Service ICE_614_AI: pending route 0 from [GUID] to 84_117, depends on service ICE_612_AI to release one or more sections" That's crucial. There's another train that has the same sections, ICE_612_AI. We know that 614_AI is trying to get from wherever that GUID is to signal 84_117 via route 0 in the routing table, and it can't because of that train being in the way. So, next step is to look at those two services. Continued...
Next I looked at the timetable itself - both ICE_614_AI and ICE_612_AI do indeed have the exact same start time, at the exact same portal. Here's ICE_612_AI: Notice also that whee the one below has a few minutes from the first time (13:37:20) to the first actual service (13:41) in the case of ICE_612_AI it's actually got a couple of hours gap - that means that our ICE is going to spawn from the portal, drive to the station and sit there for about 2 hours blocking it. That doesn't feel right... and looking at the other services, including ICE_614_AI it's actually only intended to be a few minutes difference consistently - my bet is that ICE_612_AI is actually supposed to spawn at 12:37 for a 12:41 platform departure. I made that change, and then kicked off a simulation. I ran that in the batch file to kick the sim off (batch file must live in your base editor install folder - mine's in the old SmithfieldMOD folder as that's what it used to be called and I haven't reinstalled since - yours is probably TrainSimWorldMOD or something like that). After a while the sim finished, so it was time to do a quick look to see how the sim went. First up COPY the log file immediately to another filename, because otherwise next time you run the editor you might lose it and need to waste another hour doing a re-sim to get the log back... very little is more frustrating than that... This is where my logs are saved, usually called TS2Prototype.log First thing I look for in a log is to see how it did overall. Look for "total services..." and find this block *near* the end of the log file: That's a brilliant start - that means all 615 services in the timetable found their way to their completion points. Fundamentally the timetable worked, whether it worked well or not is a separate concern but... it worked. If a timetable sim works like this, then it will dump out how well the timings matched up. If it didn't work, you'll get a status dump of every service and what it was doing, which you can use in your diagnosis to figure out what is wrong. The key there is to find the FIRST thing that went wrong, fix that and resimulate - because once one thing goes wrong, the chances are good that everything else is just tripping over it. Timings in the log are showing a few issues. The ones that say "service X ends at HH:MM:SS later than the next service Y scheduled start at HH:MM:SS" are bad - these are the services that will spawn you on foot. You MUST fix those to have a good player experience. Either the train is being held up and running late, so fix that, OR the train just has an unrealistic start time so put a valid time in - you now know what that time should be. Eg in the example above, ICE_812_AI2 is a service which has a scheduled start time if 20:36:00 but the previous service ICE_812 isn't finishing until 20:36:09 - 9 seconds too late. Now, technically, an AI service doesn't matter for this error... but... it's much nicer if you clean your errors up in the log so that you know ANY errors need looking at and not trying to remember whats acceptable and what's not etc. The other type of timing issue shown above are the ones that say "... is later than the scheduled completion time for instruction (x)" - these are saying the train can't make a station stop at the schedule you've given it. This *doesnt* affect the ability to play the service but DOES mean the player likely can't meet the schedule you've set. Whether you fix this is up to you and your conscience Bear in mind - if you add some minutes/seconds to this, you might puff the rest of the timetable out and turn one of these into 15 of the critical issues above in a single move... just in case you were wondering why you might NOT want to always fix these, you can find yourself in a bit of a spiral where each fix creates three new problems later on. Once you have the "services completed" note above with "0 were still running, 0 had not started" however you have a VALID DATA TRACK and the tick will be checked in the timetable, this is what then means that the timetable will fundamentally be available for use in the game normally. The next thing i look at is the player experience - and of the key indicators of that is being held up at red lights. I search for "stopped for" and it shows entries like this: Every time a train is held at a signal for a minute, and subsequently for each minute it remains held, it will put an entry in the log noting this. This is one of my benchmarks for player experience - if you find services held up for long times you have a bad timetable and need to fix the routing, the timings, or whatever, so you can solve each of those problems. That said - railways DO have red lights... so... maybe don't fix ALL of them... my general rule is "does this red light make sense?" if you're genuinely being held up for another train and it makes sense, then it's fine (unless it's taking too long...). If it's entry to a 6 track station, and you're held up for 10 minutes because the platform you want is occupied and the rest are free... just route to a different platform and make the delay go away ) It helps if you can find out what train it is though, and why. The next line of log after each of these entries has that detail - so in BareTail i'm just clicking on it and... Again you might need to click to expand it. This is train RE7_17436 and it's been stopped for 5 minutes (300 seconds) but its target speed condition is "Stop arrived at instruction" - this probably means there's actually a 5 minute stop here. That's not necessarily a bug at all, check to see if its what you intended and move on. We've had instances where a typo in a departure time in the timetable has held a train at a platform for a few hours - and this is where you'd see that, double check it and notice the issue. Continued...
Another example: In this case train RE4_26440 has been held up at a red signal ("target speed condition" is "Stop signal") for 2 minutes (120 seconds) - that's not bad, what you'd do now is check to make sure it's for a sensible reason. There's lots of options for finessing the times here, unticking a dispatch-beyond where a service is snatching the path way ahead for example - e.g. on Dresden Reisa, trains coming off the Meissen branch will snatch the path into Coswig LONG before they are anywhere near it. This results in trains on the mainline being held up in both directions for minutes at a time while a branchline train makes its way out. This is why you find trains coming off the branch are always coming on to a red light - it's held back from dispatching onto the mainline until you actually get there, and then it will set the path up if it can and route you out. That single change removed a TON of these lines in the log and made everything flow much nicer. Ok... let's go see how the timetable looks in the playback tool - so how do you actually get into it and what does it do? The playback tool is a data track visualiser. So the first thing you need is a data track from simulating the timetable. It does NOT need to be a fully working datatrack, just run the sim, let it finish, and whatever you have you can look at in the playback tool. In the window with the timetable open, go to Window and select Playback. Broad overview then... This is looking healthier. Lots of trains doing their thing and taking about the right time to do it. We have one major issue here with a train that needs looking at though - train ICE_872_AI2 has a problem. I've not dug into what that is, but that would need looking at. The rest seem fine and largely seem unaffected, which is handy! You can look services up, so for example if you type 26407 into the search window top left and find service RE4_26407, double click on it to get it open, then right click on it and select Show On Playback: If the playback window is open (which it should be if you're following along) you now see this: The service is highlighted in bright white, and if you click and drag your mouse along the timeline you'll see you are following the service on its path! All the other AI trains will do likewise so you can see EXACTLY what is going on at any given moment in time. Do you have a red light you want to understand the explanation for? Find the service in the playback tool, and watch it. Once it's stopped at the red light you can press the SPACE key to un-link from it and then you can free-pan the map around, see whats causing the red and then as you move the slider around see how things change and what the sequence of events is to determine if you're happy with that, or if you want to adjust things. You can zoom into the timetline view with mousewheel, pan it left and right by holding right mouse button and dragging. When you're focused on a particular service (its highlighted bright white) you cannot pan the map view around but you can zoom in and out, press space to unlink and then you can pan around (but the view will then no longer follow the train). Next step is to see if trains spawn in the 3D world as we want them to. Looks like at 08:12:43 there's a meet of two trains here so let's see if we can see that in the game. Note: Timings are not going to match up exactly, so when testing I usually spawn in at a round 5 minute interval prior to it to give things some time. One of the causes for this is that trains all start stationary, not at speed, so thye're going to take a moment to get moving. However, it should all be *roughly* like this (if you spawned at 00:00:00 and let it run for 8 hours 12 minutes and 43 seconds, it would be *exactly* like this.. the approximation is because you're spawning in later on and it needs to figure things out. Continued...
Using the console, let's set a start date: and then we'll move the camera to the station in question in the 3D view and ensure "current camera location" is ticked, and press play. The game spawns in at 08:10 and nothing is in sight, that's fine - check on the map and there are some trains moving, let's see what happens. Here you are - 08:13:10 we have our meet up of trains. About right. Ok, so conclusions and next steps, advice for this and other authors: First up is the timetable uses one formation per service which is incredibly wasteful and will cause a bigger drain on memory as well as some small impact on framerate. You should try and re-use formations as much as possible - this timetable is basically lots of trains going portal->journey->portal - so once a train has gone into the portal, it's technically available to do another one of those runs after it's arrival time, so do that - link things up and cut down the formation numbers. Second - this timetable makes use of many bits of DLC but there's no dependencies set up and no layers set up which means it's going to be difficult for everyone to use and if you dont own all of the required bits of content may well crash. Split the timetable into layers and set up the RequiresDLC plugin fields on each one. Really, the base layer should only be used for the stock that came with the route and anything else goes into its own layer. You can also tidy up a timetable with layers too - there's no limit to the number of layers you have so even the base layer could be split up to say ICE, IC, RE and RB layers without any dependencies set up (since they're base stock). This makes it easier to find, maintain and mange things and you will find it a bit faster in the editor too than having the entire thing in one block. Third - Those start times really need to be fixed. to clean the last bit of the log up. For your portal services you could just remove the times and have them auto-start after say a 2 minute delay, then it won't even worry about any timing issues for them and just have them hold for a minimum 2 minutes and then head off - which would be a good solution for almost all the issues of this type in the log file. Final recommendations - ALWAYS delete the data tracks before resimulating the timetable, just to avoid any problems. It SHOULDNT cause any issues but i've had odd wierdisms in the past and this timetable had a very weird issue as I outlined at the start. If you remove it entirely, it definitely can't get in the way. Do this with UE4 closed, and in explorer, find the data tracks one folder underneath the timetable file, in my case: D:\Epic\SmithfieldMOD\TS2Prototype\Plugins\Cadesh_RROTimetable2023\Content\DataTracks Just delete everything in there. Resim the timetable and it'll recreate them. If you're not confident, back up first, then delete, re-sim, be happy, wipe backup ... and finally... so you are now armed with a TAIL tool to live-watch your log file as it simulates, and you've spotted that 5 minutes into the simulation it's dead. It's stuck. There's obviously a train problem that needs fixing. If you now press CTRL C to abort the tool, it will NOT save the datatracks so you can't benefit from the playback tool to help you diagnose it. You do NOT need to waste an hour of your life waiting for it to eventually fail naturally however - go to the folder where the timetable file is and make a new file with the .kill extension and the same filename as the timetable... for example: Within a couple of seconds the file is noticed by the simulator and the simulation will begin to CLEANLY shut down, including saving data tracks. Within a minute or so it's all done. Before you get excited and go look at your log file however, do yourself the BIGGEST favour on the planet and either delete the kill file or move it somewhere else.. I cannot tell you the number of times I've sat here puzzling over why my timetable re-simulations are just immediately terminating before realising.. duh, I left the kill file there... be better, don't be Matt. I think that's all i've got for this one for now - this timetable is working, but still has some more kinks to iron out on it and hopefully cadeshr6s is now armed with the knowledge to continue on. Final FINAL note: This isn't just reserved to full service mode timetables. This whole process works for your scenarios as well - it can be a really fast way to check all the train flows are right to do a quick sim of the timetable (which will probably only take a few minutes) and then use the playback tool to see if everything played out the way you wanted it to. This only covers train movements of course, not player instructions, subtitles, objectives etc - but getting all this right quickly can mean you have more time to a) get more stuff in and looking awesome and b) spend more time on those objectives, knowing that this bit is at least all squared up, without having to play it over and over again to find out! Hope this helps you start diagnosing issues on your timetables better, as always ping any questions and i'll try to answer.
Hi Matt, Quick question, when you say “Run a sim of the timetable” so that it appears in the playback tool, do you mean clicking the play button to enter the 3d world and let the ai drive around and complete their tasks or is there another button that i’m missing to sim the timetable? thanks
Commiserations to cadeshr6s for being the one whose timetabling hiccups are now exposed to everyone else and congratulations on being the first one to appear in a Matt TSW tutorial. I've always found it's a great learning experience when thing go wrong.Tagging matinakbary to either include a link to this thread or include the info in his document.
I hope no offense was taken, the goal was to help people understand how to diagnose problems and use the tools that are built in, along with understanding and interpreting the log file - I was actually impressed at how much you HAD done to be honest and the fact that it basically worked except for one bug was pretty incredible. Matt.
No run the batch file to do a simulation of the timetable, not done in the editor (and editor must be shut down) - I posted the content of the batch file in the thread. Matt.
Having the editor shut down is something i missed initially. Was scratching my head as to why the playback wasnt working but, by chance running the simulation .bat outside of the editor resolved the issue. My timetable was also initally set as looping but this caused wierd issues with services at the end of the day (ECS moves from Penzance back to Long Rock moving back to their original starting positions). Most were getting spurious red signals, which, according to the log, the dispatcher wouldnt let the train pass. As there is no real purpose for my timetable to loop (a period of a few hours overnight where no trains run anyway) i turned off looping and the issues were resolved immediately and all serivces completed successfully.
It's alright Matt Thank you, I'm working on the real timetable with some access to internal data as a train engineer
Hello ! Could you help me please figure out how to solve this issue... I made scenario (S-Bahn Vorarlberg) Lustenau to Bludenz via Lindau-Insel... There's an issue with signal after Hard-Fussach that it's stays red... ("contact signaller" didn't help)... here are a files for editor... Sorry about misspelling in archive...
Its the incomplete couple instruction thats the problem, uncouples dont have eto go anywhere, but a couple MUST know what its coupling to
Can you move formations between layers? - I have a loco on layer B that brings some cement wagons out of the vault to Tees Yard. - It drops them off for another loco to take away and goes into the TMD. - I have a shunter on layer A that forms a mixed freight train in Tees Yard. Can I couple that loco from layer B onto the wagons shunted on layer A? Layer A is for freight included in the base route (steel/coal), Layer B is for services using stock that comes with the 31 (ie the cement tankers)
If you want some screenshots; "FRGT02" is a single Class 37 spawning in Thornaby Depot* "Tees08" is a Class 08 spawning in Thornaby Depot "Wagons03" is a rake of empty HEA Hoppers spawning in a siding in the yard "Loco" is a single locomotive "CementEmpties" is a rake of empty cement wagons (there was no pre-made formation for what I wanted that I could find and I couldn't be bothered to make my own) * The formation coming from off screen is a rake of steel wagons previously shunted by another 08. What I want is the loco that dropped off CementEmpties to come and take the formation made by Tees08. If you're wondering, Tees08 is on the TVL layer cos I want it to do other things after this.
No, if things need to interact they must be on the same layer - because one or both layers might not exist and then you have a problem. Consider layers as indivisible components with no sharing between them. Matt.
If on same layer, then no problems as I have one with a similar thing. 2 rakes of a pair of 20s with loaded 12BBAs (1 slabs, 1 coils) arrive from Lackenby, and then are shunted to form a 24 wagon service whilst the locos go to stable. a pair of 37s arrive from "the North" with 24 empty BBAs, and the loco runs around to take the loaded service out, whilst the 20s then take half of the empty wagons each away to Lackenby. it all works, once I got the dependencies sorted, so nothing conflicts in the light loco movements
How to couple to a formation that was part of a previous service and is now standing on a platform in the station? The simulated timetable will have the service that is supposed to couple standing in front of a red shunting signal. What am I missing?
My understanding is that if the timetable schedules a coupling for that service you should be able to contact the signaller for permission to proceed with caution through the red.
Two ways to approach an occupied block - one is to simply "couple to" that formation from outside the block - it'll see that the block is occupied, but its occupied by the thing you want to couple to, and then allow a tab to get into it. Alternatively there is an explicit call on dependency you can set up which will allow you to "stop at" in front of the vehicles, then do the couple while in-section (perhaps more prototypical). I can't remember exactly how you set up a call on dependency though so try the couple-to first, that's the easiest option. Matt.
Would be wonderful if you could try and find that out. I've got a few places in the S-Bahn Dresden timetable where I need to stable several trains in the same siding.
You could always get it to couple, and then uncouple, so that it would see them as 2 separate trains, but in same siding.
Never end a service with an uncouple either - good chance it'll explode if you then start the new service fresh as it may not spawn in exactly the same place, if it happens to overlap a little... Diesel Legends of Great Western i'm looking at you. Matt.
I'm first talking about the AI. It does not get the permission to enter the block despite the couple to. Does the dispatcher consider the available space on the platform before allowing you to enter?
The following works for me, using the Call on Dependency Matt mentioned: The lower service arrives first at the platform with a regular stop instruction (using the stop marker, i.e. going to the end of the platform), the upper service has an exact stop point set a couple of meters behind the first service. Once the load/unload completed on the lower service the dependency link becomes active and activates the stop instruction from the other service. To prevent the second service getting held at the red signal because the platform is occupied by the first service, you need to enable the "Call on Dependency" flag on the exact stop node (see screenshot below). I would assume that this setup would still work if you leave away the couple instruction.
Put your own content in your own plugins, while things *look* like they make sense in the editor adding them to the stock plugins, they actually wont on the file system because most of the content isn't there, it's buried in pak files. Always put your own content in your own plugins. Matt.
Thank you!! Sadly this wasn't explained in today's stream but it was mentioned, I just couldn't figure out how to create one. Looking into that now.
I tried to get coupling working but the ICE to couple to the other ICE is held in front of the last shunting signal (number 48) despite using the call on dependency. Previously, I tried it with couple to but that didn't work either. The AI train just won't get permission to enter the occupied block. The log file shows that the ICE 153_1 service did request a pass on danger at the main signal and that apparently was granted. But the shunt signal didn't get the memo. I've attached my plugin as well as the log of the simulation run which I aborted at some point because the service didn't proceed anymore.
I cannot get my batch file to run, it starts up the simulation tool but then hangs on "TS2Editor: Display: Load Asset Registry". I've attached screenshot showing what the path in the batch file looks like.
How long did you let it run for? It will hang at that text for some time, potentially 5+ minutes depending on your computer specs.
hi, I have this now, but I won't be going anywhere, like changing trains and times, etc post is a little wrong it says in the middle of the groove i [Kassel-Würzburg
Quick question I want to create a timetable for DRA and I can't seem to pick a location for my services, nor can I open the route map. Does anyone know why and how it can be fixed?
Hey Matt, Sorry to bother you, but now I have a problem: I tried to create a timetable from 6:30AM - 7:00AM. The overall process went smoothly, but the playback time progress bar did not display the relevant vehicle node information, and the time was still displayed 22:00, so I can only modify the time below or click the node -> show on playback method to use playback. Is there any incorrect setting that causes the problem?
Sorry to bother you matt, I asked a question above but didn't get a reply, in the meantime I've found out for myself what the problem is. But the cause of the problem that triggered it is very strange: why does the Simulation Start Time of the timetable need to additionally record the time zone of the system and offset the time zone back to UTC+0 when the simulation program starts? For example: my computer's time zone is set to UTC+8, and then I went to schedule the timetable service according to this plan: 6:30AM - 7:00AM, simulating half an hour of timetable service. So I changed the time to 06:30 in Simulation Start Time, leaving the date and timezone unchanged (I can't change the timezone either, once I change it to +0100 and hit compile, it changes back),then I closed the editor and ran the bat program, and I noticed that it shows the time period being simulated as 22:30 - 23:00! Opening the editor, playback likewise only shows 22:30-23:00. you can see in the timetable detail window on the right hand side that I set it to 06:30. If I change the time to 14:30, which is 06:30 + 8 hours, and simulate again, now the simulator is really simulating the 06:30-7:00 time period! This is a really strange design, neither the forums nor the youtube videos seem to mention this, the simulation program only runs on UTC+0 time, yet there is no way to change the timezone setting in the settings, it's so weird!
Am I correct in thinking if I set it up like this, the signal will be held at red until the train stops in the platform, at which point the path will be reserved while it's loading/unloading?
FYI: with TRAVIC you can visualize real world train taffic on a map (and also play/replay in 30x). This helped me to understand how many trains running at the same time and where they sleep during nights.
Another issue - I've spawned a 101 and a 150 (in place of a 142) at Thornaby depot but neither actually move on their own, even if I set the local time to after the start time the trains just act as if they have no instructions.
If you haven't simulated the timetable, make sure the timetable is set as play in editor and then use console command: ts2.dbg.ForceTimetableStartWithIncompleteData 1 Before hitting play
Thanks. ANyone know about that MagicLeap error I got when I tried to simulate it? EDIT: Seems it's because it was on 2 lines in the Batch file.
Would it be possible to get a simple description of what various issues mean in the timetable simulation log, and if possible, solutions to fix them? I face various issues with trains getting stuck off path (despite being on path) or at a marker. The off-path issues are sometimes down to portals just not accepting 3x of the same unit (such as a 12-car 423).
