The glorious NTP route is marred by one of its stand-out features - the Standedge Tunnel. There is a draw distance issue in this tunnel that needs to be resolved, because it totally breaks the immersion (where the natural focal point is the end of the tunnel), and breaks the belief that you are in a tunnel (even though you are actually in a continuous tunnel). This issue is discussed in this thread, for example: https://forums.dovetailgames.com/threads/pinocchio’s-nose.18060/#post-92944 What is actually happening in this tunnel is that you are seeing the all-white netherworld, at the edge of two tiles ahead of you (or just over one tile ahead if you are approaching the tile boundary). When you cross the tile boundary the tunnel appears to get smaller again, because your view of the netherworld suddenly advances by one whole tile (a large distance, as discussed below). You can see this from a different angle in the attached two pictures (look at the size of the "ring" at the very end of the tunnel, as pictured): You can also see that these images were taken with a framerate at 60fps. There is no appreciable load on the processor, because there is nothing much outside of the tunnel (except at the ends). It's "just" a draw distance issue. If the processor draws everything in neighbouring tiles there is x9 stuff to draw (there are 8 tiles around you, normally - in a completely open world). If you can see two tiles ahead, then x25 tiles need to be drawn, and x49 for three tiles ahead, and x81 for five, etc. I would normally suggest increasing the draw distance, by doubling it, to remove the bug, but even if you could do this, this could make things quite complex and slow at the tunnel ends... (maybe..., or maybe not, because a railway line is not a completely open world....). If Standedge Tunnel is built to scale, then the model is 4806m long (in real world units). I walked down the tunnel (which has a floor, unlike the LIRR Penn tunnel...) to take a closer look. It is made from 12 sections of straight tunnel, 11 of which are about 425m long, and one that is 120m long (at the Greenfield end). Each section join is surrounded by a pair of tunnel portals, which hide the join (maybe), and probably contain scripted objects that communicate messages across the tile boundary. I wanted to test the bug, to see if it was a rendering or performance issue - it isn't, as it's a hard set draw distance limit problem. Proposed Solutions: 1. Preferably, the draw distance, for the inner ten tile sections could be increased. If the draw distance is increased to five tiles (2125m) for the inner six tiles, and four tiles (1700m) for the pair that surround these, and three tiles (1675m) for the pair that surround the inner eight tiles, then this could fix the issue. The extra load on the processor would be minimal because there are not 80 tiles surrounding these central tunnel sections - it's built through a void space. I don't know if this is possible with DTG's set-up (but it should be, I think). 2. If you can't change the draw distance for individual tiles (as above), then you could take a "smoke and mirrors" approach. On MSB, the builder has filled the long tunnel with a sort of mist. This could work on NTP. 3. Or you could have "curtains" at each of the fake nine to eleven inner tunnel portals. These curtains would be black (or 80% black transparent, or gradient black, or a mixture) when they are in the distance, but when the curtain detects that you (or your camera) is within 10m, the curtain becomes transparent so that you then see the curtain that is 425 ahead of you, and you can pass through it when it is transparent without knowing it. 4. There are other solutions that are "mirror" based - similar to the curtain, but with an image projected onto it (or transmitted from it), where that image is taken from sets of cameras in the tunnel, on the other side of the curtain, that are looking at the curtain ahead. (So that you can see the tunnel portal slowing increasing in size as you pass through each tile). This requires a lot of work.... (calculations of POV and perspective), but it could work. It's complex though, because this is a two way tunnel, and every new bit of rolling stock would have to be coded in. (It would be very fun to do, if you had the time and inclination....). 5. Some combination of the above solutions. CONCLUSION This is worth fixing. The MSB fog/mist solution is quite nice - maybe just use that? But, if you (DTG) want a solution to the long tunnel problem, and you fix it now, then it can be re-used as a solution on future routes. It is worth fixing this. ASIDE: It would be nice if this tunnel had other internal features, such as the many adits and cross tunnels to the other two Standedge rail tunnels and the canal tunnel, plus some escape holes, storage spaces, leaking drips, etc. Not essential... but nice. But it's only worth it if the locos are given some light sources (from the headcode/markers or from the cab itself).