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

If you've been over to SC4 Devotion's temporary front page of late, you'll notice there's discussion of a new site, SC4Evermore. RL has been very brutal for me over the past week, so I'm only just now getting around to officially announcing what's happening with SC4 Devotion and SC4Evermore (outside of the respective sites' homepages). What is SC4Evermore? SC4Evermore (or SC4E, for short, https://www.sc4evermore.com) is a new, download-focused SC4 site that I've started. Its primary goal is to create a stable platform through which SC4 custom content can be preserved and shared in an easier-to-access modern form. The initial first goal with the SC4Evermore project is to make available the files that were previously hosted on the SC4 Devotion LEX, prior to the last-minute webhost-mandated PHP 8.1 upgrade that took SC4D (in its familiar form) offline on June 11th, 2023. All of the files that were previously hosted on the temporary SC4D frontpage have been made available at SC4Evermore, and more will be coming in the days and weeks ahead. The name itself is a tribute to two community figures, Maxis' Wren Weburg (of Wren Insurance fame), who formerly ran a site called SC4ever, and the "SC4, Forevermore!" catchphrase used by popular BATer DuskTrooper. Symbolically, SC4E also happens to come directly after SC4D in alphabetical order. The new name also emphasizes that the site is intended to be a true community effort, and we look forward to sharing more details on this end in the near future. The SC4 Devotion Discord Server has also been rebranded to become the SC4Evermore Discord Server, and is in the process of being converted into a full Community Server, which will bring with it new functionality, including Forum Channels. Rather than running on custom or commercial software, SC4E is running on Joomla, since it is an actively-maintained, open-source content management system (CMS) with the necessary features and plugins to run a viable file exchange. Why aren't all of the LEX's files available already? And why didn't you just try to get the LEX back up and running? The LEX had 4198 files in its database prior to being taken offline, and many of those files had descriptions with information about dependencies and the like. Recreating all of that is going to take a lot of time, and it's been slower going of late due to the fact that, since the closure, heavy-duty RL has affected many of the key stakeholders involved. The LEX's custom software, while at least partially fixable, suffered from an onerous and ancient account system, which was a common source of complaints (see the frequent password/registration issues). Additionally, its key feature that helped make the dependency-heavy file ecosystem manageable, the Dependency Tracker, was very resource-intensive, and severely taxed our server (particularly in terms of RAM usage). Upgrading the server or changing webhosts is not an option at this time (and won't be until 2025), so there was a real need for something less intensive. To deal with the loss of the Dependency Tracker, offer a more streamlined and complaint-free distribution system, and curb server RAM usage, there has been an effort underway (spearheaded by Tyberius06, Ulisse Wolf, and myself) to repackage many key LEX files into a more convenient form that doesn't require exotic infrastructure, as evidenced by the LEX Legacy packs we've been compiling since SC4D was knocked down by the PHP issues. This also takes time, but we hope it will lead to a much better experience for users of SC4 custom content in the long term. We've been prioritizing more frequently-used files, especially dependency packages that also get used by many files on the STEX. What's happening with the SC4D Forums and Wiki? Both the SC4D Forums and wiki are back online (still operating on the sc4devotion.com domain, so the original links to them still work without issue). However, we have, for the time being, placed the Forums into a semi-archived, read-only state for everyone, except staff and members of custom content teams with established private development forums on the site. As mentioned, we will be adding Forum Threads to the Discord Server. The decision on the read-only/semi-archived state of the Forums is not a final one, but we will only consider a full reopening if we know it's going to attract enough activity to justify it (i.e. levels similar to that before the 2019 ownership change). The Wiki, operating on a fragile install of an older version of MediaWiki, has a number of issues, including certain articles being inaccessible or impossible to edit--something which cannot be fixed without doing a full reinstall of a newer version of MediaWiki that is fully compatible with PHP 8.1, and likely a manual reimport of all the articles and data currently on it (which was required previously with the 2019 migration). Why have I been having issues with incomplete downloads on SC4Evermore? One of the issues with running a file exchange which allows guest downloading without user accounts (which were a frequent source of complaints about SC4D and the LEX) is that it is a lot more susceptible to issues with bots. We've had numerous cases in the few days that SC4E has been open with bots downloading the same file repeatedly (and often large ones, at that), sometimes as many as hundreds of times in a row in a short time span, which seems to have had the effect of a mild DDoS attack. We're in the process of finding solutions to curtail this bot activity without introducing roadblocks that hamper the experience for legitimate users in other ways. We are in the process of trying to get CloudFlare protection working on the site (note that there may be some SSL/connection-related issues that render the site inaccessible at times, as we attempt to work out some issues with it). Thank you for your support, and we hope you find SC4Evermore to be a useful resource to further your enjoyment of SimCity 4! -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

OVERVIEW The Network Widening Mod (abbreviated NWM) is a mod which extends the game's Road and One-Way Road networks through override network technology to create a system of variable width surface streets. In effect, it is the surface street equivalent of the RealHighway (RHW) mod. The first release was the result of over 3 years of effort, which required overcoming a number of technical difficulties and conundrums, including the creation of new Traffic Simulator Plugins to properly handle the NWM, and difficulties with the existing Road Turning Lane plugin. This Overview Post Last Updated 07/27/2014 Since the NAM 31.0 release in March 2013, the NWM has been included in the NAM itself. It will no longer be offered as a separate download. NWM development is largely on hold until the NAM 34 development cycle. The NAM may be obtained from the following distribution sites: Simtropolis (STEX)---------- (coming soon) SC4 Devotion (LEX)--------Windows|Mac (coming soon) ModDB------------------------Windows|Mac (coming soon) Fixes None. More information coming to this post

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

Just attempted to replicate it, testing in all orientations. What you've shown would indicate either missing textures, missing models (there are some overhangs in that area), missing model exemplars, or bad IID references in the INRULs. However, after checking in-game, plus also checking the EU texture file for the RHW-2 to ensure it matches up with what's in the US set, everything is looking okay, so I'm at a loss as to the source of your issue as of now, unfortunately. -Tarkus

The underlying pattern for it looks like this: Eventually, we'll add a FLEXRamp option so it's possible to build it without memorizing the drag patterns. -Tarkus

0xF9590000-0xF959FFFF is all yours. -Tarkus

Fundamentally, the NAM and CAM weren't considered incompatible, particularly early in the going. CAM 1.0, released in 2007, did include its own set of Traffic Simulator Plugins, which were designed by the NAM Team's jplumbley, who worked with mott/mayormot a few months later to develop the NAM's old Simulators A and B. 2007 was kind of the Wild West as far as Traffic Simulator plugins went, and got even more so as the Traffic Simulator Wars raged from 2008 to 2010, prior to the NAM Team streamlining things and officially adopting z1's Simulator Z (all five flavors of it) as the official NAM Simulator with the release of NAM 28 in May 2010. jplumbley himself recommended that CAM users run the newer NAM Simulators instead of the CAM Simulators, and this was generally echoed by RippleJet and others involved with the CAM enterprise at the time. I don't think the CAM Traffic Simulators really had much of a userbase after that. Between Simulators A and B being incorporated into the NAM proper (starting with Version 23 in April 2008--they were first offered as a separate download in late 2007) and the end of the Traffic Simulator Wars, the NAM also still offered the original Standard, Better Pathfinding, and Perfect Pathfinding options, which were renamed as Simulators C, D, and E, respectively. Simulator C was essentially no different from the Maxis simulator, save for specifying a speed for the DirtRoad/RHW network, so the CAM options were in fact a step up from that (they actually used the same Pathfinding Heuristic value--0.0465--as the NAM's Simulator D/Better Pathfinding, as jplumbley didn't believe in Perfect Pathfinding). While the NAM officially only supported the simulators that were available under the team's banner at the time, up until 2009, pretty much every Traffic Simulator Plugin out there was considered at least NAM-compatible if it specified speed and capacity for the DirtRoad/RHW network--the CAM Simulators count in that regard. However, the expansion of the RHW into multi-tile networking and the introduction of the NWM started changing the standards after that point, especially as the userbase for those plugins grew rapidly. Simulators C, D, and E didn't meet those new standards at all, and B only partially did. (Z does--and actually, A does as well, albeit without Perfect Pathfinding.) CAM/NAM Traffic Simulator history aside . . . as Ulisse and I have been discussing, if unified settings can be agreed upon for the Neighbor Connection Demand Cap Relief for both CAM and non-CAM with NAM options, it should solve a lot of the issues and make something like this more viable. -Tarkus

Yes, generally, that pattern should work. rsc204's post earlier in this thread has lots of good details that may prove useful. -Tarkus

If you need just a handful, I can allot you a whole smaller range: 0xF9580000-0xF958FFFF -Tarkus

The "PIM-X'd" term actually dates even farther back, to the BSC Team's xxdita back in 2010. -Tarkus