The order of "LOAD"

[Ed the Bat]

My project uses a LOAD command in the GAMEINFO lump in order to load all of the individual modules. However, this can potentially cause me trouble, because all of those modules will be loaded before any and all other files. There are instances when I need other files to be loaded first. Is there any way I can control the order of the LOAD command? I could conveniently achieve what I'd like if these modules were simply loaded right before the one with the GAMEINFO lump, but not before everything else...

[Ed the Bat]

Been pondering this one again lately. The main issue, for me, is that I have a lot of separate modules, and using a launcher or command line prompt to add them would be a nasty task for the user, hence the automation of the LOAD command. The Wiki attests that files in such a command will be loaded before the one with the GAMEINFO lump, but it does not outright note that they will be loaded before ALL other external files (only the IWAD and zdoom.pk3 seem to precede them), which is not desirable in my case. If anyone knows of an alternate method for loading large batches of files, allowing me to forego this entire issue, help would be greatly appreciated.

[Graf Zahl]

You should rethink your project's organization. If it's that cluttered it'll make a very bad impression to your users. Why do you need this many different modules?

[Ed the Bat]

Each character gets a different module specifically to avoid clutter. If they're independent of one another, there's no reason to make their resources rely on one another.

[Gez]

If they are independent of each other, why do you want to load them all at once through GAMEINFO?

If they all have to be loaded together, then it's more convenient to have a single file. Heretic is independent from Strife, and yet ZDoom contains both the Heretic and the Strife classes together in zdoom.pk3.

[Ed the Bat]

If they are independent of each other, why do you want to load them all at once through GAMEINFO?

Because I might want to play as any one of them during any session. Being the project developer, I have all of them. No one else has to have them all.

If they all have to be loaded together...

They don't.

Heretic is independent from Strife, and yet ZDoom contains both the Heretic and the Strife classes together in zdoom.pk3.

Yes, but ZDoom also allows users to choose which of those two they want at one time, instead of putting them all upon someone at once.
*I* load them all at once, but no one else has to. They could simply not collect a given character pack, and the LOAD command will just skip over it.

[Graf Zahl]

Then why does load order even matter?

[Ed the Bat]

Because of my old nemesis, KEYCONF. Anything with 'clearplayerclasses' or 'setslot' in it will break everything if it's loaded after one of my character packs. I have to have my items loaded last.

[MG_Man]

I think KEYCONF setslot isn't necessary anymore since Weapon.SlotNumber in DECORATE is a thing.

For player classes you can use GAMEINFO

[Ed the Bat]

I think KEYCONF setslot isn't necessary anymore...

And yet people STILL USE IT TO THIS DAY. I can begrudgingly forgive projects from the era when it was the only option, but the ones who still use it make me legitimately angry. And since KEYCONF gets final say, it will override proper methods like PlayerSlot no matter what order the modules are loaded in. My only recourse is to fight fire with fire and add more KEYCONF commands, so long as they're loaded last.

For player classes you can use GAMEINFO

Which, again, will get overridden by KEYCONF commands, no matter the order.

[MG_Man]

Then why are you using KEYCONF? If it's your project as you said in the first post, then you can avoid using it completely.

[Ed the Bat]

...you can avoid using it completely.

No, because if any other map or project uses it, my project would become unplayable. If they use KEYCONF, the only way for me to override that is to use it myself.

[MG_Man]

I'd say that's their problem, then.

[GFD]

The people who actually use KEYCONF aren't the ones with the problems. It works fine for them. It's the people who try to make compatible mods that have problems

Why does KEYCONF have such high priority over weapon slots and the like anyway? Why does a mod need KEYCONF to override weapon slots from an earlier file with KEYCONF? It'd make a lot more sense if DECORATE defined weapon slots or similar could override KEYCONFs.
Maybe it's not possible with how KEYCONF is coded, though. That's some old code right there.

[Gez]

Why does a mod need KEYCONF to override weapon slots from an earlier file with KEYCONF? It'd make a lot more sense if DECORATE defined weapon slots or similar could override KEYCONFs.

Sure, it seems like it would be better this way, doesn't it? But there is a problem here: the vanilla classes and weapon slots are defined in zdoom.pk3 with the modern methods (DECORATE and MAPINFO). If these methods have priority over KEYCONF, then all the KEYCONF mods will no longer work; because the unmodded game will have priority over them.