Why No Nyt Ai Services On The New Lirr?

It took an extraordinary effort to get the LIRR timetable as busy as it is - and we felt the time was best spent focusing on that - throwing more complexity in the Penn station area is already at the high end of an exponentially increasing curve of complexity that would likely introduce more difficult to find and difficult to fix issues in this already complex timetable.

This is by far the busiest timetable in the game, while the service counts are lower than London Brighton it's in a MUCH more condensed space on the most complex signalled network in the US.

Matt.

 

No plans to add it, no. And no it's not a trend. We always try to add what we can, but each timetable has to be evaluated individually and in this case, more time spent making LIRR services great was felt to be more important than cutting back on that to give some time for the AI moves.

It would have impacted performance, both FPS and ram of course but the time, complexity etc was more the concern here. We'd already written off including this timetable on Series S so I wasn't too concerned about the ram side of things and that's why all the statics are there populating the yard and penn station.

It's important to understand how much time is required to add those AI moves - it's easy to consider them short inconsequential things, and a couple of hours work to add them in at most - but that's entirely wrong, those simple moves would be relatively quick to author, and then potentially weeks to make it all work nicely again, that timetable i think is up in the 5-6 hours per simulation iteration timescale (most timetables are 1 hour) so you can see you're making one change per day basically for a normal working day. Rather than let Joe feel like he needed to be working every hour under the sun stressing out to deliver this (which, to be fair to him, he wanted to do) I descoped it because I would rather Joe is healthy.

Matt.

 

Timetables are one-person jobs. We have more than Joe working on timetables of course, but because it's all done in one file and because of how timetables are built - it really is a one person job.

Matt.

 

That would tie up two people and you might get maybe 10% improvement in productivity at best - more likely, it'd drop, because then you need to manage knowledge of it across the two people. When you're building a timetable you build up a good knowledge of what's going where, why, how it works, what you expect to see etc. So making changes becomes significantly easier for the author of the timetable than someone who didnt for example. Once the changes are done, you then do a simulation - which takes about 6 hours on LIRR i think, nobody can do anything productive in this time. Joe normally for example works on a different timetable during this time.

Once the simulation is done, you're then looking over the logs to see if anything went wrong and if so what, you're looking at the playback tool to get more detail on things that went wrong or to see if certain things happened the way you expected/wanted them.

Then you're making more changes as a result to fix issues, improve timings, add new stuff, then back to simulation.

We've never found a way for a second person to usefully contribute to the process. What we have done is built a little bank of timetable simulation PC's so that the 6 hours downtime waiting for a sim is done on a different PC and the developer is then free to work on a second project while they wait.

Most TT's are not 6 hour sims - but most are more than an hour, average would be 1-2 hours i'd say - so even on those timescales, there's plenty of time to work on a second timetable and then once the route a timetable finishes transfer the files and logs and then kick off sim on route 2 timetable.

The main thing getting in the way of that is just the confusion it can cause in the developers mind - so it only really works if they are different countries for example Joe has been working on the Cathcart timetable somewhat alternated with the LIRR one while LIRR has been off simulating, because they're so different.

We have radically improved the process of making timetables since Sand Patch, where only the most basic timetables were feasible (not even shunting really, I managed a whole two shunting services on Sand Patch Grade initially) and SPG still took about 10 weeks work for that incredibly basic timetable (each iteration of simulation was literally 24 hours at that point).

It wasn't until something like the latter stages of the freight timetable I did for NEC that we had "compilation" with checks - so I built half of the NEC freight timetable by literally guesswork - make some changes, save, sim - didnt work because an invalid path or wagons not quite where i had envisioned them being from 14 steps prior etc. Now, it's all done at edit time with the compiler, playback tool, 2D map, it's a revolution.

There's nothing you can do to fundamentally beat the fact that there's a huge amount of calculation involved in simming a timetable, and an immense amount of complexity to manage to make it all work.

Split that across two people is just not viable.

Matt.

 

I am fairly sure it's down to the number of individually managed rail vehicles and particularly the number of formations in use rather than number of services.

If you have one train do 500 services it is cheap.
If you have 500 trains each do one service, it's insane.

The reality is most timetables fall closer to the latter than the former if you model their movements prototypically. Personally, I used to make all my timetables closer to the former than the latter, reusing the absolute heck out of formations to keep FPS down and simulation times down. If you run the MSB freight - you'll notice there are only about 4 or 5 unique formations in the freight trains, and they get re-used over and over again, this makes it much more efficient both to simulate and to run, but obviously isn't accurate and if you're a wagon number spotter you'll see this a mile off

Matt.

 

The number of unique rail vehicles is the main factor, particularly moving ones, static in a yard isnt a big issue, but if you have lots of rail vehicles moving it takes a big hit. On my original LIRR timetable, I found framerates were terrible at one point - and by removing 2 cars off every train, it massively improved it. Same number of servies, same operations etc, just two cars removed from each formation.

The number of unique vehicles and formations also has a secondary impact - so if you can re-use your formations as much as possible, that also helps both ram and FPS - though that one is perhaps more ram.

Matt.

 

In the case of TSW - we have split trains into a "view" which contains the 3D model, and the "model" which contains the simulation and scripting elements. The "model" is very light on memory in comparison to the textures and mesh of the "view". Any train which is out of sight essentially has no view loaded at all, just the model is present in memory which optimises ram usage considerably.

When they are visible, while the cab is part of the model it is lodded separately and we drop it considerably unless you're near enough to see it.

There are also things like windscreen rain effects - quite memory intensive, so only visible when you get near enough to see them, otherwise turned off (thats why when you fly away and come back, they have reset).

When simulating a timetable - it's all entirely just the models, so memory is extremely optimal in that case.

Matt.

 

You resimulate it as often as you need to, basically. I know that's perhaps an unhelpful answer but it's because of the cause and effect nature of the whole thing. Let's say you have a train arriving to a station 10 minutes late, you look and find its because it was being held up by something else getting in front of it and you decide that it shouldn't, its like maybe your local nipped in front of the express when you reall want to stick a dependency in there and make it wait. Ok - that could have ripple impacts on the entire remainder of the timetable, so any other bugs you fix may not be what you think they are anymore. I'd do a cursory glance for the other things unlikely to be affected and then do a sim. As things get more complex, you are almost down to one bug, sim, one bug, sim because the minute you make any changes your true knowledge of what you're seeing is rapidly becoming quicksand.

I've seen timetables go from almost perfectly working, to utterly broken with every train running late with one small change. So it becomes something you have to use some experience on because you dont want to blindly make changes - you could make things worse, the nature of the fix might be different because of knockons etc. You also don't want to sim repeatedly, unnecessarily, especially if they're taking 2+ hours at a go. It's different while it's quick, you are much more better served doing more sims more frequently to ensure you're always working on the best data in that instance.

Depends on a huge number of factors. It took me about 20 weeks of abject pain and working double-hour days 7 days a week to get sandpatch first timetable i'd guess - yes, that really weak one. GWE probably ended up similar but that was significantly more complex.

I think the NEC freight was maybe 9 weeks of long days.

LIRR first timetable - the one that never made it out? countless. months. months and months. The one that actually got released? 6 hours. (2am to 8am to meet a build deadline).

Important to note that there were lots of tooling problems and differences compared to what you have now - such as the early timetables we had no compiler, so a 24 hour sim was the only way to know if you'd made a really dumb basic error. LIRR was because the despatcher had a slew of problems that came out because of the timetable.

On the other end of the spectrum, HRR took me 2 weeks start to finish. Munich Augsburg was 3 weeks. The Sand Patch Grade Freight addon maybe 4 or 5? Shunting is always going to make it take longer (but imho, so worth it). The newer tooling makes shunting significantly easier to do and a lot of that cme about because of the process to build the NEC freight timetable.

Yes, nothing is an island. So when you're simming a timetable and seeing x milliseconds per frame, you need to remember that full fat simugraph physics adds a bunch to that, along with general graphics and other stuff going on so you need to undershoot heavily.

Yes in fact from what I recall, it's even more fine grained than that, it's literally axles. So if you have a train of 100 x 4 axle cars, and 100 x 2 axle cars, the latter will run with significantly better performance. This is because the bullet physics system is looking fundamentally at moving axels on the rails and then considering the body's - so there's 1 body per axle, and one for the main body crudely - so a 4 axle car is going to have 5 physics elements, and a 2 axle car is going to have 3 - and even simming the timetable outside of graphics etc, that all needs to be taken into account.

The two are chalk and cheese - done by different people with different skillsets, so we'd never really evaluate them side by side.

If you want a new timetable and there's nobody to make it, you can't have a new timetable unless you stop them doing a different timetable.

Matt.

 

Most welcome - you ask good questions and I enjoy answering them