Am I the only one having trouble organizing the plugin folder?

[Flat Raver 59]

Gosh golly, it's a mess for me. I'm trying to make sure that the loading process works as smoothly as possible, but it just doesn't work. I try organizing by function (first, mods, then dependencies, then lots and BATs), but that doesn't meld well with all these automatic installers. They keep insisting to be sorted by creator, if even by that. Help me, please.

[CorinaMarie 29,922]

Many peeps have found useful advice in the Show us how you manage your plugin folder thread.

[Flat Raver 59]

Thanks, I guess. I've been on and off again playing this game, and I always struggle with getting the right content in. If it's not missing dependencies, it's the menus getting bloated with testing lots for props I needed for that one lot. Often, I find myself giving up on it time and time again.

[CorinaMarie 29,922]

My plugin folder is like 50 or 60 mb so I've no trouble at all organizing it.

I'm sure the gurus will be along with some advice tho.

[SecretMbr_735754 2,158]

One thing I've become more focused on in organizing Plugins is the loading sequence.   I looked through the "show us how you manage your plugins" and didn't see any significant mention of it, but its important so that everything you've installed is optimized and operating correctly. 

So here's the link to an article on SC4D I found:

https://www.sc4devotion.com/forums/index.php?topic=10542.0

Here on Simtropolis the only thread I found is minimal:

https://community.simtropolis.com/forums/topic/38537-file-load-order/

From the Wikipedia: http://www.wiki.sc4devotion.com/index.php?title=Plugin_Loading_Order

"In any single directory it will load loose files first, then subdirectories, and then .dat files. The order algorithm is just an alphabetic sort, with non-alphanumericals at the end."
 
First it loads the files in %InstallDir%\  (The directory SC4 is installed in)
Then it loads %InstallDir%\Plugins\  (The Plugins folder in the install directory)
Then %LocalDir%\Plugins\  (The SimCity 4 directory in the user's documents folder)

[Flat Raver 59]

How much does the loading order matter? This is probably the thing I struggle with the most; do I load NAM after or before CAM? How about LRM? Do I load props and textures after or befor BATs?

[SecretMbr_735754 2,158]

7 hours ago, Flat Raver said:

How much does the loading order matter? This is probably the thing I struggle with the most; do I load NAM after or before CAM? How about LRM? Do I load props and textures after or befor BATs?

I've never used the CAM or the LRM, but the NAM installer does organize its folders according to the logic of loading sequence and checks for duplicates and conflicts with the Cleanitol program.   I was hoping somebody with more experience with the loading order would come and post a bit of an expert opinion.    I'm still mostly struggling myself to build the Plugins the best I can from the information I linked above.    Some mods may potentially override others and just waste space, there could be duplicate dependencies wasting space, and sometimes the program will crash if there's a major conflict between installed plugins, so I'd say its high priority before organizing the stuff you want to use just for building and designing a city.

[Fantozzi 4,069]

8 hours ago, Flat Raver said:

How much does the loading order matter? This is probably the thing I struggle with the most; do I load NAM after or before CAM? How about LRM? Do I load props and textures after or befor BATs?

First - organizing plugin folder foremost is for you to have easy accessing and finding quickly everything. It's a little bit like your wardrobe. If you put everything on a pile - the trowsers, the underwear, the socks - to find a chique outfit in the morning, the right socks with the right trowsers, will be a challenge. Therefore there is no general advise - it depends on your needs, where you looking for the ties (do you have one - so where one person puts the ties you may put the baseball caps instead) and so on.

Second - load order. On many things load order doesn't matter. Rule of thumb is: everything that is additional and new and doesn't alter or change already existing things load order doesn't matter. Everything that alters or change or modify things already there - load order does matter. So most bats you download add something wthout changing something = load order doesn't matter. All terrain mods changing terrain = load order matters.All reskins of automata = changing = load order matters.

Create a folder you can be shure it always is last = Z____mods. Put those overriding stuff in there.

Third - now looking on NAM, CAM and LRM. All three change already existing things = load order matters. Bull's eye! Problem begins where they affect the same stuff - network f.e. they want to override same pack of data, each one another part and a little different - so they need a specific load order. You can't put them simply all in your mods-folder but one has to be before the other - thinking: what should override what. The last ist the always superior - what loads last is the most dominant. Second rule - and this is not of thumb.

Now shure you have to know - CAM alters network capacities. Therefore it is in conflict with NAM that alters network capapcities too. CAM for the higher grow stages for those gigantic skyscrapers to grow on level 13,14,15 needs much more capacity on the networks to keep the cities working. NAM does almost the same. NAM works with the traffic controller and some pathfinding fixes. CAM not.

This means - loading CAM after NAM will break those features of NAM. NAM loading after CAM will break nothing in CAM. Basically it's recommended to make CAM one of the first mods to load - so don't put it in the ZZZZ_mods folder - better leaving it where it is. The developer already named the folder a___CAM. The reason isn't easy to explain. Most changes to the base game lots - like the IRM f.e. - will override the CAM settings. Even if you loose CAM-effects on them - they mostly still will work with the CAM. Many users make this mistake - they install the CAM and then they install tons of stuff not made for the CAM. The result is - the game will still work without much problems. It's simply the CAM won't have much effect. His influence on the stuff gets weaker and weaker. So basically the CAM is a very patient non-demanding mod.

Now the LRM. It has to change the street lights - so it has to change informations also contained in the NAM. It has to be dominant to NAM. Will this harm NAM? No, it's only visual changes of the NAM.

So with this - there's only one right load order on these - 1. CAM, 2. NAM, 3. LRM. NAM+LRM down in your plugin-folder (making them very dominant with LRM the most dominant), CAM very up in your plugin-folder making it less dominant.

[rsc204 21,868]

8 hours ago, Flat Raver said:

How much does the loading order matter? This is probably the thing I struggle with the most;

Either not at all or absolutely essential to a mod working, but this depends on the mod itself.

It breaks down mostly like this (there are always exceptions):

• Lots, Buildings and the like have no special load order requirements.
• Dependencies, such as Textures, Props etc also have no special load order needs.
• Anything that simply overrides the Maxis content, will do so placed anywhere in the Plugins folder.
• Anything that needs to override something else, must load later than the files they are overriding.
  Examples include a re-lot which replaces the original or a set of override textures.
• The most common example is things needing to load after the NAM. I.e. any mod that changes how the NAM works/looks. Such mods must be in a folder starting with the prefix:
  "z____" (that's four underscores).
  Most recent mods are setup this way for you automatically, otherwise just rename the folder.

Quote

do I load NAM after or before CAM? How about LRM?

Now if you had read the manual/readme for either of those mods, you should know the answer. I can't stress enough how important it is to know what you are installing, especially for most complex mods that have very specific load order requirements. If a mod alters something else (rather than adding new content), ignore the readme at your peril.

The answer is, CAM only alters the Maxis files, but does not alter the NAM, so CAM loads first. LRM changes the lights used for both Maxis and the NAM, thus it must load after the NAM.

Quote

Do I load props and textures after or befor BATs?

See above, the load order of content that doesn't alter other content's behaviour is not important. Just find a system that helps you to organise it. Installers will fight you on this, making you move things about when they are done.

I sympathise that this process is long and takes a lot of work, one of the communities best aspects, the sheer amount of choice, is also one of the biggest hurdles. But there is no magical solution to that, ultimately you can build such a suite over many years, adding things slowly and keeping on top of it. The mistake many make is trying to install too much too quickly, leaving an unsolvable mess behind. A plugins folder can be copy/pasted and will work, you only need set it up once if you do it right. So keep a backup somewhere, you never know, then just take it easy. Those who've been doing this from the beginning have the luxury of staggered releases to get things together. But it's much harder for those late to the party, but perseverance and having a system that works will at least prevent having to toss away everything because it gets out of control. Even if that means you have to come back to it having had a break from the game.

Just now, Fantozzi said:

Create a folder you can be shure it always is last = ZZZZ_mods. Put those overriding stuff in there.

It's not that simple, such a folder will load after most things, but underscores and other characters are a law unto themselves. For example, this wouldn't load after z___NAM, which would prevent files in there loading after the NAM

[Fantozzi 4,069]

30 minutes ago, rsc204 said:

It's not that simple

Ah, sorry ... you're right. Fixed typing. Also, to make it clear - you can put your reskins and terrain mods etc all in there to keep them together to find them easily. But @rsc204 is right - still this can't substitute to make some thoughts. F.e. - it's of no sense to keep 3 different reskins of the ambulance car there. As they will override each other still only the last one will be the most dominant and so the working one. So a last mod folder don't solve this problem but keeping overrides/repaints/reskins all together (and not spread out over the plugin-folder) makes it easier to recognize and manage conficts amongst them.

[jeffryfisher 2,176]

18 hours ago, RandyE said:

[from elsewhere] "...The order algorithm is just an alphabetic sort, with non-alphanumericals at the end."

I think that statement has been contradicted. The sorting is strictly by upper-case ASCII code value, which sometimes differs from Windoze dir order. ASCII also puts some symbols ahead of, some after the alphabet, so !name comes early, and ~name comes late.

What I keep forgetting are the files-versus-folders rule and the .dat delay rule. I use Rivit's dataNode to see what's overriding what. I sure hope it's exact.

[rsc204 21,868]

12 hours ago, Fantozzi said:

Also, to make it clear - you can put your reskins and terrain mods etc all in there to keep them together to find them easily. But @rsc204 is right - still this can't substitute to make some thoughts.

Perhaps a better name for such a folder (one I keep in my setup) is simply z____LoadAfterNAM, then another z_____LoadLast. Windows won't list them in the order SC4 uses, so don't pay too much attention to it, but assuming all folders starting with a z, each new underscore will make a folder load later than the last. So in this setup, the load order would be:

• z___NAM (i.e. the NAM)
• z____LoadAfterNAM
• z_____LoadLast

It doesn't really matter what names you use, the order is dictated by the prefix here (red).

Then if you have multiple mods that load after the NAM, they are all in one place, you can use this folder along with further subfolders to organise things. Actually, a numbered prefix is a great solution for easily being able to reorder mods that may conflict with each other to work together. I.e.

• 10 Mod one
• 20 Mod two
• 30 Mod three

Why are these numbers 10 apart? Well that way there is room for 9 more folders between each for later if need be. Perhaps a little overkill, but it causes no harm so why not make it future proof. But the real benefit of this system is getting mods to play nicely together or just troubleshooting issues with them.

Say Mod two isn't working, you are seeing Mod three instead,  you could rename it to "40 Mod two" to load later.

Or say Mod two was showing, where you wanted to see Mod one, again just rename to "5 Mod two" to load it earlier.

It takes all the complication out the process, whatever is in the folders will load based on the numerical order of them, which is easy to follow. Hopefully some of these examples will be useful.

[SecretMbr_735754 2,158]

1 hour ago, jeffryfisher said:

I think that statement has been contradicted. The sorting is strictly by upper-case ASCII code value, which sometimes differs from Windoze dir order. ASCII also puts some symbols ahead of, some after the alphabet, so !name comes early, and ~name comes late.

What I keep forgetting are the files-versus-folders rule and the .dat delay rule. I use Rivit's dataNode to see what's overriding what. I sure hope it's exact.

I quoted your whole comment not to 'overrule' what anybody else has said, but because it seems very important in getting down to the nitty-gritty of how the program identifies a file/folder.  Windows has also used different sets of character codes, file and dir name structures over the years, don't know if that matters, but I'm going to use DataNode and make an experimental Plugin folder structure with a variety of file and folder names to see what is being loaded.   I think I can test if DataNode is exact by switching, removing, adding to see if it is consistent in what it reports.   As well I can at least verify what has been asserted here regarding loading order.

[Flat Raver 59]

13 hours ago, Fantozzi said:

First - organizing plugin folder foremost is for you to have easy accessing and finding quickly everything. It's a little bit like your wardrobe. If you put everything on a pile - the trowsers, the underwear, the socks - to find a chique outfit in the morning, the right socks with the right trowsers, will be a challenge. Therefore there is no general advise - it depends on your needs, where you looking for the ties (do you have one - so where one person puts the ties you may put the baseball caps instead) and so on.

Second - load order. On many things load order doesn't matter. Rule of thumb is: everything that is additional and new and doesn't alter or change already existing things load order doesn't matter. Everything that alters or change or modify things already there - load order does matter. So most bats you download add something wthout changing something = load order doesn't matter. All terrain mods changing terrain = load order matters.All reskins of automata = changing = load order matters.

Create a folder you can be shure it always is last = Z____mods. Put those overriding stuff in there.

Third - now looking on NAM, CAM and LRM. All three change already existing things = load order matters. Bull's eye! Problem begins where they affect the same stuff - network f.e. they want to override same pack of data, each one another part and a little different - so they need a specific load order. You can't put them simply all in your mods-folder but one has to be before the other - thinking: what should override what. The last ist the always superior - what loads last is the most dominant. Second rule - and this is not of thumb.

Now shure you have to know - CAM alters network capacities. Therefore it is in conflict with NAM that alters network capapcities too. CAM for the higher grow stages for those gigantic skyscrapers to grow on level 13,14,15 needs much more capacity on the networks to keep the cities working. NAM does almost the same. NAM works with the traffic controller and some pathfinding fixes. CAM not.

This means - loading CAM after NAM will break those features of NAM. NAM loading after CAM will break nothing in CAM. Basically it's recommended to make CAM one of the first mods to load - so don't put it in the ZZZZ_mods folder - better leaving it where it is. The developer already named the folder a___CAM. The reason isn't easy to explain. Most changes to the base game lots - like the IRM f.e. - will override the CAM settings. Even if you loose CAM-effects on them - they mostly still will work with the CAM. Many users make this mistake - they install the CAM and then they install tons of stuff not made for the CAM. The result is - the game will still work without much problems. It's simply the CAM won't have much effect. His influence on the stuff gets weaker and weaker. So basically the CAM is a very patient non-demanding mod.

Now the LRM. It has to change the street lights - so it has to change informations also contained in the NAM. It has to be dominant to NAM. Will this harm NAM? No, it's only visual changes of the NAM.

So with this - there's only one right load order on these - 1. CAM, 2. NAM, 3. LRM. NAM+LRM down in your plugin-folder (making them very dominant with LRM the most dominant), CAM very up in your plugin-folder making it less dominant.

This needs to put into the FAQ, pronto!

2 hours ago, rsc204 said:

Perhaps a better name for such a folder (one I keep in my setup) is simply z____LoadAfterNAM, then another z_____LoadLast. Windows won't list them in the order SC4 uses, so don't pay too much attention to it, but assuming all folders starting with a z, each new underscore will make a folder load later than the last. So in this setup, the load order would be:

• z___NAM (i.e. the NAM)
• z____LoadAfterNAM
• z_____LoadLast

It doesn't really matter what names you use, the order is dictated by the prefix here (red).

Then if you have multiple mods that load after the NAM, they are all in one place, you can use this folder along with further subfolders to organise things. Actually, a numbered prefix is a great solution for easily being able to reorder mods that may conflict with each other to work together. I.e.

• 10 Mod one
• 20 Mod two
• 30 Mod three

Why are these numbers 10 apart? Well that way there is room for 9 more folders between each for later if need be. Perhaps a little overkill, but it causes no harm so why not make it future proof. But the real benefit of this system is getting mods to play nicely together or just troubleshooting issues with them.

Say Mod two isn't working, you are seeing Mod three instead,  you could rename it to "40 Mod two" to load later.

Or say Mod two was showing, where you wanted to see Mod one, again just rename to "5 Mod two" to load it earlier.

It takes all the complication out the process, whatever is in the folders will load based on the numerical order of them, which is easy to follow. Hopefully some of these examples will be useful.

Okay, but I don't see it specified exactly what I'm supposed to put in z____LoadAfterNAM, and what to put in z_____LoadLast. I'm presuming terrain mods needs to be loaded after LRM and the DarkNite mod.

[CorinaMarie 29,922]

2 minutes ago, Flat Raver said:

Okay, but I don't see it specified exactly what I'm supposed to put in z____LoadAfterNAM, and what to put in z_____LoadLast.

Based on what RSC said:

2 hours ago, rsc204 said:

Say Mod two isn't working, you are seeing Mod three instead,  you could rename it to "40 Mod two" to load later.

Or say Mod two was showing, where you wanted to see Mod one, again just rename to "5 Mod two" to load it earlier.

I get the impression there isn't any definitive answer to that. It'll really depend on which mods you are using and you will likely have to experiment.

 

[rsc204 21,868]

26 minutes ago, Flat Raver said:

Okay, but I don't see it specified exactly what I'm supposed to put in z____LoadAfterNAM, and what to put in z_____LoadLast. I'm presuming terrain mods needs to be loaded after LRM and the DarkNite mod.

Well that's because it's impossible to provide a definitive list here, it would simply never end.

If a mod needs to load after the NAM it should go in z____LoadAfterNAM. How do you know if a mod overrides the NAM, well first off any half decent creator will tell you in the description/readme of their mod. But more simply, if a mod alters the way the NAM looks or behaves, you can be sure it's overriding the NAM, which means it must load later. So LRM is altering the lights which are a feature of both the base game and NAM. Therefore it's a good candidate to place in such a folder.

Terrain Mods actually have no specific load order needs. The LRM doesn't alter the terrain after all, lights are something completely different. Darknite also has nothing to do with the terrain settings either. A terrain mod simply overrides the settings from the vanilla game, so follows this rule:

13 hours ago, rsc204 said:

Anything that simply overrides the Maxis content, will do so placed anywhere in the Plugins folder.

Darknight is much the same, it overrides the Maxis settings, but this is not further altered by the NAM or other mods.

Now it's easy of course for me to chortle on about what works how, because I know the relationship of all these things. So I do understand why you are asking these questions and can appreciate it's not always obvious at first glance to know what to do. But a few simple rules will help you when trying out a new mod, to make it find the right home in your Plugins folders.

Unless the readme/files tell you to do so, assume a file has no special load requirements in the first instance. Find it a logical home in plugins and don't pay too much special attention to it. Open the game and check, have the changes the mod is supposed to make worked?

So let's follow through with DarkNite as an example. You'll find it is working (assuming you've no other mods that mess with it), great, now we know it doesn't need to go anywhere special and can move on.

Now what about LRM? So we place the files into Plugins without doing anything special, then test in-game. Now this is trickier, at first glance, depending on where you look, it may seem like LRM is correctly working. But if you scratch the surface, what's actually happening is that Maxis content IS being overridden, but NAM content ISN'T. What does that tell us, simply that we need to load it later to also override the NAM content, which isn't working now. Since it should be obvious the lights not working are from the NAM, this means we know it should move to the z____LoadAfterNAM folder. Now when you test it, you will find it should be working everywhere (of course there may be unsupported pieces, no mod is perfect).

I hope by walking through the process, it allows you to grasp how to best troubleshoot these issues. The good news too is that this is simply not necessary for 99% of the mods you download and install. As a user, if you can differentiate between those mods that simply add new buildings, models, props, textures etc and those that alter the way existing things work, it makes life a lot easier. Because the former don't need to go through such a process for the most part, just organising. Only when you have one of the more complex types of mod should you install it all by itself - i.e. don't try installing other mods at the same time, it confuses any problems that may arise. - using this process.

If at any point the results are unclear, not working or you just get lost, don't spend ages fretting over it. Just pop on the forums, open a new thread and ask for help. Almost certainly someone will know the answer and be able to advise you.

[Fantozzi 4,069]

6 hours ago, Flat Raver said:

I'm presuming terrain mods needs to be loaded after LRM and the DarkNite mod.

The reasons to put them in z____[whatevercomeslast] folder are two - not to have to think about if there's something else that could override them and so not to make it scientific (one may call this lazyness) and the other to keep those 'reskin/modifiying' type of mods together.  To my knowledge they don't touch each other so order amongst them doesn't matter. And there even maybe no need to load them very last and maybe the terrain mod could be even loaded first or third or number 48 as nothing else affects the textures.

But this way I need much knowledge if there are other mods that may affect the same data in my folder. There maybe 40.000 mods out there from different eras of modding. And to know everyone of them is really a task. So - as I don't have this knowledge and still to be shure I put them at the end. To simplify things. With a knowledge of all the IDs of all the mods or an extensive research with DataNode you could think of a very complex load order where every single mod has its exact position in the loading process. Question would be: why spending so much time creating such an intolerant and unflexible system when you can create a working solution without much efford and enjoy playing the game instead.

 

 

[huzman 445]

Right on you folks!!! In just two days you given everybody great insights and tips about the famous folder. Thanks! Gracias! Merci! Danke! and all.

[markussaage 762]

Throwing my two cents in here... From my experience the best approach to organize the plugins is to learn, how SimCity 4 loads them in the first place. And this can be done by using this:

In the included Readme! you'll find the basics, how to use this tool. It's awesome. This shows you, after scanning your plugins folder, how SimCity 4 will load your files, and with this information you start to rebuild you folders and files inside the plugins folder. You're also able to find damaged or broken files/dependencies etc etc... It's an awesome auditing tool.
It helped me eliminate all my errors, and now I can play the game without any trouble, CtDs etc at all...

Kind regards!

[APSMS 1,893]

I'm not even sure, to be honest, how I was able to learn all the information about SC4 in the first place.

I keep my stuff marginally organized by author, and for one-offs, by purpose, though there's a great many mods that are unorganized due to poor documentation on my part (well some of it is the author's fault since files without a readme become significantly more difficult to sort if I don't know who made it).

I've tried using DataNode before and I think my PC just doesn't like it, because it always freezes on me. When I have gotten it to work, it was extremely useful. I still need to go back and figure out what I was doing that made it work, since there are a number of missing models that I know I've just yet to install, but can't figure out what they are.

[jeffryfisher 2,176]

On 9/30/2017 at 1:31 PM, rsc204 said:

a numbered prefix is a great solution for easily being able to reorder mods

Maybe I'm an iconoclast, but I hate the lengthening underscores being used by installers (I find it tedious to count them). Therefore, I'm already doing the equivalent of numbering: I prefix each of my plugins folders with a letter of the alphabet, and I have almost no files "loose" in the same level as a folder.

Now that bit about all .DAT files being postponed until after all other file types... Disturbing on its own, it could also mean that dat-packing some folders but not others would change load order. It also raises the question of load-order of objects found within a dat-pack file... Maybe the dat-packer sorts those on the way in.

1 hour ago, APSMS said:

I've tried using DataNode before and I think my PC just doesn't like it, because it always freezes on me.

How long was the freeze? If it is set to automatically load your plugins, then it could be unresponsive for several minutes, just like loading the game and your first city.

[markussaage 762]

1 hour ago, jeffryfisher said:

Now that bit about all .DAT files being postponed until after all other file types... Disturbing on its own, it could also mean that dat-packing some folders but not others would change load order. It also raises the question of load-order of objects found within a dat-pack file... Maybe the dat-packer sorts those on the way in.

I can tell for sure, that .DAT packed files and folders take a lot less time for the game to be loaded, and, they're always be loaded LAST by the game. Without .DAT-packing my plugins loading a city would take 20-25 minutes for me, before I could play... No, I am not willing to wait that long... no way...

[rsc204 21,868]

7 hours ago, jeffryfisher said:

Maybe I'm an iconoclast, but I hate the lengthening underscores being used by installers (I find it tedious to count them).

The main reason for this is that the NAM changed the playing field, with the introduction of the z___NAM folder. This was to counteract all the support requests where people were complaining the NAM wasn't working, when in fact third party mods were to blame. But this has caused problems elsewhere, firstly many mods that previously loaded after NAM and need to so they work, no longer do by default. Users wrongly assume they are broken and no longer working, but most such mods just need a folder name change. In some ways the introduction of this folder has caused a "Load Order Arms Race", with many modders/mods fighting to be the last to load.

As a modder, if I create something that must load after the NAM, I have no choice but to use a prefix of z____ for it's placement. My mod simply will not work if I do not do this.

However, users are their own worst enemy sometimes. The #1 problem with my texture mods, which override the NAM? Altering the default installed z____MGB Mods folder, because users wanted to use their system, breaking the mod in the process. Given this is clearly documented in the Readmes, which I pour hours into and advised by the installer not to change, such support queries are frustrating.

As for counting underscores, why don't you simply look in Windows File Manager? Although the order will likely be reversed (from load order for SC4), at a glance you can see what will load when, there is no need to count anything. Despite a complex setup of intermingled mods, I still need only 4 such folders (not counting z___NAM).

• z___RVT Mods
• z____MGB Mods
• One that loads after the above.
• Then one final "Load Last" folder.
   Useful when modding, so I can be 100% certain something I'm messing with, will appear 1st time. Not useful for most

Everything else is handled with subfolders, although speaking of which, I try to keep these to the bear minimum. Because, many subfolders will slow down the startup process and IMO is messy. A well organised file cabinet shouldn't be nested 20 folders deep, neither should files on a computer. By datpacking many subfolders too, I keep this side pretty well organised.

You may argue the NAM should reverse the z___NAM folder. I'd argue it's not the folder name that caused problems, it was simply changing something that was previously established. Doing that again and once more altering the playing field, is just not worth it IMO. If you really think about it, load order issues will exist, no matter what it's called. So why go through another round of changes, complicating matters all over.

7 hours ago, jeffryfisher said:

Now that bit about all .DAT files being postponed until after all other file types... Disturbing on its own, it could also mean that dat-packing some folders but not others would change load order.

It does mean that. But, you have to consider that load order only affects a small minority of the files in Plugins. Most simply don't matter. How many such mods are going to be SC4Desc, SC4Model or SC4Lot files?, not many I suspect. Plus it should be pretty easy to fix if you see problems. Then for the big mods like Texture replacements, T21s and the like, because they pretty much all need to be in DAT files, this is a non-issue. Hence it's really not a major problem, although it's useful to keep this behaviour in mind.

7 hours ago, jeffryfisher said:

It also raises the question of load-order of objects found within a dat-pack file... Maybe the dat-packer sorts those on the way in.

It doesn't need too, if two objects DAT-packed have the same ID, it will use the load order of the files being packed, keeping only the one which loads later. So a DAT-packed file will never have conflicting items inside it.

This is not to be confused with a .DAT file where a user has manually altered the contents, in which scenario you absolutely can have conflicts (I've seen this in the wild).

[jeffryfisher 2,176]

13 hours ago, rsc204 said:

the NAM changed the playing field, with the introduction of the z___NAM folder

Indeed. One of the first things I do after installing each NAM is to rename it "u NAM ##" (which puts it after its cousin, "s NAM ##"). That leaves me six more letters of the alphabet for mods to appear after the NAM. PEG mods are the trickiest. I have both "f PEG" and "w PEG" folders, splitting some mods across them (e.g. so I get the NAM controller and PEG ports).

I've spent a lot of time in DataNode (plus some in iLives) sorting collisions between CAM, IRM, airports, PEG, NAM, RUM, slope and miscellaneous small mods. I've burnt up 13 letters of the alphabet in the process, but I think I have them operating harmoniously... maybe. At least I can load my cities without crashing or brown boxes, and I can run time off their clocks with the worst problems being dirty industry and chronically depressed commerce, which I'll take to other threads.

 

13 hours ago, rsc204 said:

if two objects DAT-packed have the same ID, it will use the load order of the files being packed

Yeah, that's effectively what I was hoping for as "sorting on the way in". I'm glad to know we don't need to worry about it.

 

14 hours ago, rsc204 said:

The #1 problem with my texture mods, which override the NAM? Altering the default installed z____MGB Mods folder,

Whenever I see anything like that, I toss it into my "z textures" folder and then look in DataNode to see if the textures there are all getting along.