Override-once-only files?

[Wiimeiser 436]

It's common knowledge that only one controller file can exist at a time, and only one will ever be loaded, but does anything else exhibit this behavior? From my experiments, this happens with anything that modifies zones as well, ReZone Plus is incompatible with the NAM, for starters...

[CorinaMarie 29,571]

A little out of my league, but I'll give it my best guess until the experts get here.

Yes, tree and seaport controllers must only be one of each or you get CTD. I'm not sure, but there might be airport controllers too. For other things if they share the same IID then whichever loads last would be the active one. That could bork things already in place before the one with the same IID was added. I'm not familiar with ReZone Plus so we'll have to wait for the gurus to pop in.

[Wiimeiser 436]

FYI there's no crash, it's just that whichever one of the two loads last reverts the other's changes. What exactly does the NAM's alternate zone view do anyway?

[CorinaMarie 29,571]

1 hour ago, Wiimeiser said:

What exactly does the NAM's alternate zone view do anyway?

The two things I remember offhand are that it shows the subway tubes and stations and does not hide the trees.

[rsc204 21,806]

In the two cases you refer to, there is nothing beyond the normal behaviour of overrides happening. The game only loads the RUL (controller files) by referencing the file's IDs. So whilst you can have more than one such file, the last one to load will be what you see. In the case of the NAM, it's controller overrides the one in the SimCity DAT files.

SC4 as a whole cannot take two identically ID'd objects and "merge" their functions. Yes you could make that work theoretically with RUL files, you just make it an option to load additional ID'd files that act as expansion modules. But if we look at your other example, the zones view, such things would be next to impossible to implement code wise, so more than one would work together. How could the code possibly determine which bits of two files to select between for one "combined" file? Hence Maxis gave us a system of overrides, which is hugely flexible and allows us to change many, many things.

But there are cases too where you can not override default exemplars, the most well known would be the IH Census exemplar, which is why you must DATPack the I-HT fix. Best guess, code in the main .exe prevents overrides from affecting it's operation or being loaded.

I've personally noted that duplicate network settings that conflict from Slope/Tunnel mods can cause CTDs, although it doesn't seem widely known/understood. In this case, we can override the default game behaviour, but further overrides of the override them seem to cause problems. Honestly, beyond noting the issue and fixing it for my own game, it's hard to pin down the exact reasons for why.

[jeffryfisher 2,176]

7 hours ago, rsc204 said:

there are cases too where you can not override default exemplars, the most well known would be the IH Census exemplar, which is why you must DATPack the I-HT fix.

It was my understanding that you could override its direct effect via simple plugin, but having redundant census exemplars would screw up the census (population would be counted for each rather than for just the last one), which would run you into caps too soon, which would hurt your cities. Thus the census exemplar needed to be replaced in SimCity1.dat rather than overridden in plugins.

Actually, if I understand it completely, even packed the fix does override the default, hence its z-naming prior to packing, but by putting the override inside SimCity1.dat, it happens in time to avoid the redundant pop counting bug.

[rsc204 21,806]

1 hour ago, jeffryfisher said:

It was my understanding that you could override its direct effect via simple plugin

Nope, that's not correct. Every documented attempt to override this exemplar has ended with the conclusion that the fix was not working this way. I.e., R$$$ sims still don't find jobs in I-HT buildings. It only seems to work when the fix is merged into SimCity_1.DAT.

1 hour ago, jeffryfisher said:

Actually, if I understand it completely, even packed the fix does override the default, hence its z-naming prior to packing, but by putting the override inside SimCity1.dat, it happens in time to avoid the redundant pop counting bug.

The only reason it has a z prefix before packing, is due to the way DATPacker works. If two identically IDd exemplars exist to be packed together, the last to load will be kept, but any other duplicates discarded. So the prefix is simply to ensure the patched version is the one that gets kept when packing.