Flann

I'd like to give my sincerest thanks to the Simtrop team for getting the site back online and keeping our community alive! Your efforts are greatly appreciated.

It's going to be a case by case thing. Some of the bridges have S3D geometry favorable to reskinning by adding a new textured plane to the model. Others will not have satisfactory results. Try looking at the bridge models in wireframe mode.

This is Szeged. The name of this next one has two words.

No, not really. This has been somewhat of a pain point for doing this sort of work until very recently. Previously we got by with either storing an unhealthy amount of hexadecimal IDs in our brains, or we'd run override texture sets that had "burned in" IIDs in our plugins, or we'd reference the network code, or peek into the texture dats to find what we needed. Nowadays, however, we just use this excellent query DLL which is able to tell you what the ID of a network tile is.

You can't switch directly between different height levels of RHW. It is necessary to use a special transition piece, called FLEX Height. See this documentation for more details - https://www.sc4nam.com/docs/feature-guides/realhighway-mod/#transitioning-to-other-networks

Well, I can confirm that it works with @rsc204's suggestions, assuming the RUL code is properly incorporated into the appropriate files. We use a special compiler program to do this rather than edit the files directly. However, it also breaks the OWR-1 starter, so, an alternate RUL1 definition would need to be found.

Because this is identical to the OWR-1 starter definition except for the IID, the possibilities are: Your changes were not properly added to the RUL1 file Your changes were properly added to the RUL1 file but the because it's the same as the existing one, the game is preferring the one which comes first or last in the file (I'm not sure what the load order preference is).

Indeed, there is quite a lot to it and unfortunately a dearth of easily digestible how-to guides. Fortunately, the most important topics are covered in great detail on the old SC4D wiki. These articles will teach you how the game works but you'll probably need some help to put it all together. As you have discovered, you must learn quite a few things to accomplish adding a new override network. You are also correct that such a mod would not be possible to release as a standalone package. The code that makes the networks work ultimately must be compiled down to a handful of files, and only one copy can be active in a given installation. Stewardship of the network related features thus must be centralized. This is the responsibility of the NAM team. Ultimately, to make your idea a reality that could be shared, you'd have to coordinate (join) the NAM team and then there'd probably be a discussion on the merits of the feature and how to implement it if folks agree it should be added.

The key to understanding RUL0 is that the checktype lines tagged with 'optional' cause the game to place the network component that correspond to the specified flags. If the underlying flags involve two networks, this combination must be defined somewhere in RUL1. When this concept is used to create starters and other flex pieces, the RUL1 definitions are known as false intersections (or falsies). In order for your RUL0 item to work, you must define a new falsie in RUL1 which calls up a new network texture. From there, you can define RUL2 rules to cause the network to propagate along the OWR network. The SAM 11 starter falsie is defined here https://github.com/NAMTeam/Network-Addon-Mod/blob/9ac972aa2fa57f5059e28d916ada681402f6cfb1/Controller/RUL1/04_Street/08_Street_OneWayRoad.txt#L252

To me, this is not a good compromise unless categories of the competing sets actually have the same meaning. If the solution is "call it whatever you like", then we actually haven't defined anything, we have not settled on a system, and there would be no shared understanding of how the tilesets are supposed to work. Without that consensus, how could it ever be possible to actually implement the community styles broadly? Remember, work will need to be done to actually get content assigned to new styles. If that work is not done using a common system, we'll end up with two or more similar classification schemes masquerading as one, and the tilesets won't behaver as expected. For that reason, I still insist we work to find just one common styles system. For several reasons, I believe the logical system proposed in Option A is better. Here's why I like it: It groups similar architectural styles together eliminates the need to have a deep understanding of architecture. The use of a representative city and era as shorthand for a grouping of styles is a continuation of the the system Maxis used in the original game. It is transparent about its relationship to time, recognizing the importance of the historical era in organizing architectural styles. For me, the ideal solution is to adopt the logic of Option A while ensuring that there aren't any regions or styles overlooked in the final set. If that means that the list has to be expanded a bit, or that some styles are sparsely populated, to me these are acceptable compromises to make to ensure that good representation is achieved. I would rather we have a lengthier list of styles under a common system than two competing systems.

I don't think a style must have a lot of existing content to be useful. I imagine it will be common to have multiple styles active when playing. I also imagine it will be quite common to have a plugins folder with some or even most of the styles empty. The major benefit achieved with having a broader selection of styles is better control over what grows at any time. I'm trying to judge the options here like so: 1: How obvious is it what will grow when I have that style on? 2: How easy is it to classify any given building into one of the styles? Is it obvious or is there some ambiguity.

I think the gist of it is that we had 20 years of only having 4 tilesets, so if we don't replace them completely, they'll continue to be a hodge-podge of different styles. See the below posts for a better explanation:

Maybe more descriptive, but keep in mind that it is the name that we will see, and for me the names in A are decidedly more obvious. City plus era is immediately evocative, whereas the styles presented in Option B are less clear and an odd mix of regions and architecture styles. For example, I find the four different European styles (west, east, north, central) to be excessive and unclear, but I think that Paris 1895, Berlin 1915, Rotterdam 1975, etc. more readily provide a sense of place that I can imagine in my head.

Those are the Heretic Slope Side Walls

A little late, but I dug up a screenshot I posted a few years ago of this city under construction that shows the context of the station I posted.

If indeed the menu lag and other undesirable effects (e.g., lag when switching to/from underground views) seemingly caused by having a large number of plugins is really related to exceeding a file handle limit, then I think your approach might be superior. I have been operating under the assumption that datpacking down to as few files as possible is optimal in terms of performance. But if it turns out that we just need to keep the number of files below a threshold, then I like this approach and wonder if it could be implemented into sc4pac.

While I may have had the tiniest hand in one of the last updates, I really can't take credit for JDatPacker, that's all memo! Now, as to your approach to datpacking sc4pac plugins, I like a few things here. For one, it seems smart to operate within each package. That's a clever workaround to respect sc4pac's workings. I also appreciate that you've made it a bit smarter when it comes to running the datpacker multiple times. I'm not sure if I'll switch strategy just yet, but I'm considering it. As a point of comparison, here is how I manage sc4pac and datpacking: Point the sc4pac profile at a "staging" plugins folder within the sc4 userdir, e.g., "plugins-unpacked" Install non sc4pac mods in the staging folder as well Drop a copy of JDatPacker into the userdir (so that it can be dedicated to this specific userdir, and I never have to change the directory settings) Periodically run JDatPacker to pack the plugins in the "staging" folder and save them into the actual plugins folder It automatically overrides the packed files Edit: One thing that sucks about my method is that the datpacker doesn't help me move the symlinks to .dll mods that sc4pac installs, or dll mods in general.

Very nice work. Thanks for putting this together and for the write up. This will be a big help in specifying dependencies correctly and make it easier to integrate new and existing plugins with sc4pac.

Hello, welcome to Simtropolis @MazakMan98!

Sometimes it just takes the simulator some time to confirm that jobs are reachable from those residential zones. I bet if you let it run for a bit it would resolve itself.

Not possible - the R4 and R5 curves use network flags which are not possible to create via dragging the network tools.

Not possible at the moment. I do think it would be a cool feature.

I'd be fine if it was just 180-flora I think it's technically precise enough and anyone writing metadata probably has enough experience to not get confused by the terminology. That said, if there must be a compromise, I think 180-flora-fauna-mmp makes a decent tradeoff between conciseness and clarity and also matches the way the mods are organized on SC4E. 180-ploppables introduces ambiguity about what the menu could contain. Lots of things are ploppable, for example lots ...