Tarkus

Having been through webhost-related issues, I know what a pain they can be, though my problematic host (which the SC4D Forums and Wiki are still on--SC4E has thankfully moved) merely forced PHP upgrades on basically no notice and broke our software. That seems positively delightful compared to getting completely wiped over a billing error, which is unfathomably atrocious. In any case, I'm very glad and relieved to see ST back to life after all that. As announced two days ago, the SC4D Forums are back long-term--the "interim" tag has been removed from the re-opening. -Tarkus

First off, welcome to Simtropolis! You've definitely hit on one of the more vexing series of tradeoffs we've had to try to work around over the years, with regards to network capacity and DIPs, and one that partly harkens back to the "Traffic Simulator Wars" of the late-00s/early-10s. The original ITCE values from Maxis were 0.7, 0.8, 0.9, so the intersection tile itself actually reduced capacity. The discussions about changing the profile of the ITCE values started in 2007, when the NWM was in early planning stages, and mott and jplumbley were in their research phase, which led to NAM Simulators A and B being developed with future NWM compatibility in mind. At the time, the most pressing concern was related to network capacity--namely, equalizing the per-tile capacities and speeds of Road, OWR, and Avenue. (z1 later buffed the OWR to have higher per-tile capacity and speed with one of the early updates to Simulator Z, based on the green wave phenomenon.) However, the renewed interest in simulator settings and optimization led to experiments and development with the ITCE, the Congestion vs. Speed curve, and other areas. jplumbley thought that the notion that the intersection tile itself was the highest point of congestion in the ITCE didn't make sense, as the actual congestion at intersections is on their approaches. For Simulator A, he changed it to 1.5, 0.9, 0.95. At the time, we didn't know that the TLAs' crossover paths would cause those networks to invoke the ITCE (let alone about DIPs). Once the TLA ITCE effect and DIPs were discovered, z1's Simulator Z platform was the basis of all the NAM's simulator plugins. He thought jplumbley's first value of 1.5 was too extreme, so settled on 1.25 (pre-DIPs, I believe it was 1.0), but even before upping the first value, he had tended to believe the second and third values were not creating enough of a congestion penalty to accurately simulate traffic light/stop sign queuing. From what I recall from back then, he had a steep dropoff between the first and second values even before the first value was raised to the current 1.25, and he was concerned that not having that steep dropoff would negatively impact the simulation. The general explanation that's been used to rationalize certain NWM networks/FTLs being buffed at intersections, as well as the ITCE-induced congestion spiking near transitions from base networks to NWM/FTL transitions, has been that: a) the additional lanes minimize the delays caused by turning traffic, and in particular, left turn traffic (right turn traffic in LHD) having to yield to oncoming traffic, and blocking the passage of traffic going other directions through the intersection b) as the traffic volume generally drops off to some extent as one gets farther from a major intersection that has turn lanes (mostly if there's development near that intersection), the overall effect to congestion for having an FTL will still be neutral at worst (i.e., it's still there but has been pushed backward, as you've noted), but potentially slightly positive at best (the increased capacity is at the highest-volume point, and the dropoff at the transition is at a lower-volume point where the effect will not be as extreme) Is this ideal? No, but all the options currently available to us have significant tradeoffs, and we've generally felt this set of tradeoffs is the best compromise under the circumstances. Can you raise the second and third ITCE values yourself? Yes, certainly, with an "at your own risk" caveat, since you're running a modified simulator that differs slightly from what the NAM has provided and supports. The extreme dropoff to 0.2 and 0.4 for the second and third values has been a source of controversy among some users, and back when the Traffic Simulator Configuration Tool (TSCT) still existed and was supported, there was an option to dial that back. When Simulator Z 3.0 debuted with NAM 45 (September 2022), we discontinued the TSCT, as not only would it have required a fair bit of reprogramming (made somewhat more difficult by the state of the original source code from over a decade prior), z1 found the simulator properties and their effects on both pathfinding quality and system performance to be more sensitive than previously thought. In fact, he found that setting the capacities above a certain level actually hampered both quality and performance, which meant the Medium, High, and Ultra versions actually performed measurably worse than the Low and Classic versions. Given the recent advancements resulting from DLL modding, it's possible we may eventually arrive at a better solution, though there's still considerable challenges to overcome before we can really consider that prospect, as the areas that would need to be modified remain uncharted territory. Barring any eventual ability to add true new networks (which appears would be extraordinary difficult to do--see here), the other thought would be to allow overrides of network capacity/speed on an IID-level basis (i.e., explicitly stating that a TLA-3 tile has a certain capacity, rather than defaulting to base network capacity x ITCE), by some mechanism such as exemplars or by supporting new properties in path files. This would probably be beneficial even in the case that we are able to add true new networks down the road (pun fully intended). -Tarkus

The data structure the savegame file format uses to store network data on each tile/cell is the real killer. The Construction States part of the Network Subfile uses the first 13 bits (Bits 0 through 12) of the 32-bit/4-byte (DWORD) value to store the actual network designations of the tile. Initially, that might led one to believe the other 19 bits are free for the taking, but unfortunately, they're not, as they're used to describe other network properties. i.e., if the network tile has a valid path file, if it is part of a bridge, aspects of how it is rendered, etc. That aspect right there caps the number of true networks at 13. There's quite a few other places in the game that also enforce that 13-network cap, but that part of the savegame format is perhaps the most prominent limitation. A lot of other spots use 4 bits to represent the network type . . . this would theoretically allow 16, but the Construction States property and likely other spots in the game's code and file formats place additional constraints by consuming those otherwise seemingly open spaces for other purposes. That does not mean that it's impossible, but it makes things several orders of magnitude more difficult. -Tarkus

Just replied to you over in NAM Support. Pasting it here:

Correct, these do not exist. Big issue with anything elevated is of course the model work, and aside from some menu/UI stuff Chrisim has done since his return, FLUPs development is stalled, and may remain that way until/unless DLL development is able to make the new draggable Subway-based system not be so incessantly temperamental. -Tarkus

0xF95B0000-0xF95BFFFF is all yours. -Tarkus

One of the main reasons updated video tutorials are in short supply is that the NAM is in a constant state of flux, and there's a high probability that any new, updated tutorials could join the ranks of the outdated in fairly short order. This often makes it difficult to justify the time investment in making a tutorial video in the first place. We're in an especially transitory state right now, with the start of the DLL Era and the ongoing efforts to kill off traditional puzzle pieces, alongside the resultant stream of changes to the menu/UI. While there's definitely demand for tutorial videos, the logistics often don't support their creation. -Tarkus

The release of the original Cities: Skylines in 2015 ended up wounding SC4's popularity pretty substantially, simply because C:S was the first city-sim since SC4 to not be a complete disaster at launch. 10 years ago, this would have been a straightforward question to answer. As far as 2026 goes, however, it's more complicated. C:S itself is now almost 11 years old. Its sequel is now nearing 3 years, and unlike the original, C:S2 had a disastrous launch and a number of scandals since, ultimately leading to Paradox cutting ties with developer Colossal Order. That whole franchise lost a lot of the goodwill that had been showered upon it. Meanwhile, we're still here discussing SC4. The SC4 forum post stats @Cyclone Boom shared for ST look about like those of SC4 Devotion's forums did 10 years ago. Traditional forums in and of themselves have undergone a decline in past decade, with Reddit, Discord, and social media all taking a substantial bite out of their activity, regardless of topic. While accordingly, ST post stats may not be quite as accurate a barometer of SC4 popularity and community health as they may have once been, it's worth noting that the monthly SC4 forum posts at are fairly consistently hovering around that 775 posts per month mark, with occasional peaks and valleys, and the STEX upload stats are remaining fairly consistent as well. That's still a pretty solid indication that SC4 isn't getting any less popular (or more dead). The main SC4 subreddit, /r/simcity4, has generally been trending upward with its stats, and there's been perhaps more mainstream gaming media coverage of SC4 in the past couple years, because of the DLL mod advancements. SC4 survived getting "wounded" by C:S's launch, and while it's fairly obvious it's not going to get back to mid-00s "Golden Era" levels of activity without something truly miraculous happening, the overall trend seems to be that the current activity levels are being sustained at minimum, and possibly inching slightly upward. -Tarkus

Regarding the installer, there's still discussion what form it'll take. Before RL went completely berserk for me (which it continues to be), I had been working on a revival of the .exe-based NSIS installer, and there was a rough internal build made with it. The Java installer would need to be redesigned in order for it to be feasibly used for the DLL Era NAM, since trying to handle a file architecture that requires installation into multiple directories is rather awkward at best currently, and would likely lead to a lot of installation errors and support requests if deployed as-is. One of the main reasons for using it--macOS support--is also null and void now, since the NAM's now-required DLL cannot run on that platform. Going back to NSIS would remove the Java requirement, allow for more intricate file architectures to be supported, potentially ease reinstall/upgrade processes, and while the codebase reduction has made it less of an issue, it can also automate the 4GB Patch routine. There were still some noticeable teething issues with the internal build, however (including some odd Linux problems). Either option (NSIS or Java) is going to require work before we can release a traditional installer again. -Tarkus

First off, welcome to Simtropolis! To answer a few points: The only NWM networks that have any sort of turn lane support at this juncture are those in the TLA and AVE families (TLA-3/5/7, AVE-2/6, and of course, the Maxis Avenue, which would be AVE-4 if using similar nomenclature). The ARD-3 can hook into the Type 110 setups, as there is a transition for doing so, but using the modular FLEX Turn Lane (FTL) features, not via QuickTurn. While expanding turn lane functionality to the RD and OWR families is in the cards, it's fairly low on the priority list right now. Additionally, it doesn't look like you have any RD-6 anywhere in any of the screenshots . . . the elevated network you have is the elevated viaduct form of the Maxis Avenue network (which is part of the NAM's Draggable Viaducts system). The RD-6 does not have elevated viaducts--nor do any of the NWM networks. That is also in the plans, but there is other NWM functionality that's in front of it in the developmental queue. NRD-4 (and pretty much all of the single-tile NWM networks, save for the OWR-1) uses some trickery involving dummy paths and a property in the Traffic Simulator Plugin to receive a 25% boost over base network capacity (in this case, Road). While at first glance, this might seem below what it should be, given that the number of lanes is doubled going from Road/RD-2 to NRD-4, the property in question (the Intersection & Turn Capacity Effect, or ITCE) also affects the capacity of intersections, and not just those with NWM networks. The 25% figure is a compromise, designed to allow some bonus to the NWM networks without causing deleterious effects elsewhere. The simulator calculates capacity on a per-tile basis, not a per-lane basis, so that's the best we can do at this juncture. The NWM has technically been in development almost as long as the RHW (project was founded at the end of 2006, whereas the RHW's beginnings are in 2005). Surprisingly, while the RHW may be more challenging for the end user when compared to the NWM, the NWM is actually an order of magnitude more difficult to work on as a NAM developer, and there's been periods of time where we simply couldn't progress with it without first having to solve some larger issue. A lot of the RHW's functionality involves grade-separated crossings--far simpler to path than NWM intersections with all the turning motions, and there's not nearly as many T-intersections with which to contend. (T-intersections, especially larger ones, can get really gnarly because of asymmetry, and the game's default tendency to reuse +-intersection components as part of the T-intersections often makes NWM situations even messier.) NWM development is actually a huge focus internally right now, as we've finally built up a framework internally to streamline portions of the process, though things ended up getting paused as a result of both some developmental and Real Life complications. (The developmental ones seem to be mostly resolved now; the Real Life ones are still a work-in-progress right now.) Once things finally start moving again, I suspect you'll enjoy some of the new stuff we have in the works. -Tarkus

0xF95A0000-0xF95AFFFF is all yours. -Tarkus

The old Road/RHW, OWR/RHW, and Avenue/RHW puzzle pieces (and the Rail/RHW ones, for that matter) are still in NAM 49--however, the menu buttons to access them are no longer installed by default, and haven't been since NAM 44 (March 2022). You can install them by checking the "Legacy Puzzle Piece Menu Buttons" box in the installer, which can be found under 2 Network Features > RealHighway > a_Legacy Support > Legacy Puzzle Piece Menu Buttons. The actual models, paths, and exemplars that reference them are still installed by default, however, so that users who had previously built setups with them will still find them in working order even without the menu buttons to access them. (In fact, if you built a stretch of RHW with the original Version 1.2/12/0.12 release from November 2005, there's still the path and texture files at the right IIDs for it to function with NAM 49, as well as code to update it automatically to the new scheme.) There's a few reasons these menu buttons were relegated to "legacy/deprecated" status and made non-default. First off, there's newer, easier-to-use ways to build your own interchanges, even if you're not going the super-easy route and using the QuickChange Xpress full interchange setups. As we've developed more and more advanced draggable functionality and FLEX Pieces (which are ploppable like puzzle pieces, but dynamic rather than static, in that they can interact with their surroundings, rather than being stuck in one form), it's possible to build setups like what you've shown without using any of the items from the old Road/RHW, OWR/RHW, or Avenue/RHW menu buttons. For example, I built this setup very quickly using the FLEXRamps, FLEX Height Transitions, and the Draggable Road Viaducts system--all of the components I used to build this were introduced between NAM 31 and NAM 33 (2013-2015). For the actual portion where the Road Viaduct intersects the two MIS Ramps and crosses over the RHW-4, all I did was drag the Road network out from the Road FLEX Height Transitions (under the Draggable Road Viaducts menu). Secondly, over the 18 years I've been a part of the NAM Team, we've very regularly gotten feedback that puzzle pieces are "fiddly" and "annoying" (among other adjectives), and that the TAB Rings are too long and there's too many menu buttons. The RHW, in particular, tended to be singled out in its initial phases of rapid expansion. Since all the draggable and FLEX content we've been developing since is dynamic, it's possible to get the same functionality and much more with a smaller footprint in terms of both the menu and TAB Rings. In fact, a decade ago, we more or less banned the creation of new puzzle pieces in the NAM, unless there was an extremely good justification to make an exception (i.e., the functionality couldn't exist in draggable or FLEX form), because we were committed to tamping down on menu bloat and improving the user experience. The number of traditional puzzle pieces added to the NAM since that moratorium was enacted can be counted on one hand, and recent developments may actually render some of those obsolete, too. As we've brought more draggable/FLEX implementations online, we've relegated more puzzle pieces to that "legacy/deprecated" status, where they're not actually necessary to do certain things anymore. Keeping the old puzzle pieces around in addition to the new buttons for the draggable/FLEX content actually makes the "menu bloat" situation that much worse. Additionally, some users who aren't aware of the new draggable/FLEX content ended up inadvertently using the old, deprecated puzzle content when it was still on the menu by default, and tried to do things with it that are only possible with the draggable/FLEX versions, leading to support issues. Making the deprecated puzzle piece menu buttons such that they're not installed by default fixes the menu bloat system, and guides users toward the newer, better-supported draggable/FLEX forms, but still gives the really old-school users who absolutely insist on still having them around an option to do so. -Tarkus

If you're downloading the traditional NAM installer, the transit stations are all still in there and IIRC, installed by default. It's only on sc4pac that they're separate. -Tarkus

Not at present. RRW's Viaducts are limited in their ability to interact with other viaducts at this time. -Tarkus

Also reminds me of the 2013 April Fools' prank, with the NAM Team being bought out by EA in the wake of the release debacles of both SC2013 and NAM 31: Doesn't seem the comments were archived, unfortunately, though did manage to catch a rather fortuitously-timed status update referencing it. The original text from the prank: -Tarkus