Overwriting configs.

[UNN 0]

Quote[/b] ]You cannot "force" an addon to be processed last. You can have as many dependancies as you want in your addon, if I make my addon dependant on only your addon my addon will be loaded after yours as it cant be loaded until it has that info. It doesnt matter if your addon have 23 dependancies and my addon only have 1.

Under certain circumstances you can force the addon processing order. But it appears to be related to default Arma addons only, so I would like to look into what it is about the Arma addons that allow them to work in such a way.

Quote[/b] ]You maybe already understand all this and I didnt understand your input.

Somehow, I did start to think of spaghetti when I was typing that reply

Quote[/b] ]Right now it actually seems quite simple to me.. With this info I can understand in what order addons are loaded and how to affect that.

But I still follow this thread because as you are testing it more indepth UNN you might come up with something new.

I think there are still some pieces missing, so if you’re ok with me spamming this thread, I will post anything of interest.

Quote[/b] ]I had another idea: what if you put a non-existent addon in the "requiredAddons" field? It would throw an error message, but I *think* the addon still loads. In this case, I would assume the engine would have to wait until the very end in order to load it?

I noticed the same thing with errors and addon loading. But yeah, I'd prefer not to use forced error messages. I'm going to take a look at the preloaded addons section of the Arma configs, to see if that holds the key.

Quote[/b] ]Okay, you seem to have a misunderstanding of what #define is. #define does a find and replace operation in your config. Nothing more.

It does not do any sort of code evaluation, any sort of config evaluation, or anything. All it does is a find/replace operation.

Quote[/b] ]#ifdef only checks if something has been #defined, it doesn't care what it has been defined as. Even this will still result in #ifdef evaluating as true:

Yeah, that was kind of my original point. That’s why I was looking into ways of explicitly defining, or not defining a #define variable.

Quote[/b] ]What exactly are you after? Are you trying to change addonA's config depending on whether addonB is loaded?

Basically I want to define or not define cfgVehicle classes depending on the presence of specific pbo's. It's really about reducing the "clutter" in the config of certain classes if they are not needed or supported with the current set of pbo's installed, in the addon directories.

Quote[/b] ]In that case, why not just overwrite / modify addonA's classes, inside of the config of addonB?

No it's a case on adding only the classes that can be used by the addons installed, omitting any classes that refer to addons not installed.

Quote[/b] ]If this is for scripting purposes, then there are many easy solutions. For my handsignals system in OFP, I had checks to see if the voices pbo was loaded or not. I'm sure you can think of many ways to do this as well.

From a script point of view it's easy enough to determine the presence of an addon. This specific problem is geared around configs only.

[VictorFarbau 0]

Here's the solution to ensure the last queue place:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">requiredAddons[] = {*.*};

Or maybe not   Then again, haven't tried it, you never know.

Is my understanding correct that all config files -regardless if they reside in the game addon or @mod addon directories- are loaded in one go and then processed in that mystical order being discussed here?

So far I naively believed that putting addons into @mod/addon folders would ensure prior loading of all game/addons... ? If there would only be straight documentation about this - I wouldn't feel like an idiot each time I deal with configs

VictorFarbau

[General Barron 0]

Here's the solution to ensure the last queue place:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">requiredAddons[] = {*.*};

Or maybe not Then again, haven't tried it, you never know.

Nah, I'm afraid the requiredAddons does not refer to an actual filename, but instead it refers to the cfgPatches name used in the addon's config.

Confusing? Yes. But it does make sense, because this way you can rename or merge pbos, and still keep backwards compatibility.

Quote[/b] ]Is my understanding correct that all config files -regardless if they reside in the game addon or @mod addon directories- are loaded in one go and then processed in that mystical order being discussed here?

Yes, that is basically what I'm getting at here. The load order of addons is, in a way, written into the addons themselves. Mod folders have very little to do with load order.

Quote[/b] ]Basically I want to define or not define cfgVehicle classes depending on the presence of specific pbo's.

Are you aware that it is possible to delete classes? I'm not sure if this will help in your case, but basically you can use addonA to delete classes declared in addonB. An example:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

class RscMsgBox

{

delete SubBackground;

delete Background;

class Top

{

delete title;

};

};

You may have to delete all sub-classes of a class first, before you can delete the class itself. Also, the 'access' parameter might influence whether you can delete the class or not. Oh, and one last thing, I don't think you can re-declare a class in the same config that you delete it in.

[UNN 0]

Quote[/b] ]Are you aware that it is possible to delete classes? I'm not sure if this will help in your case, but basically you can use addonA to delete classes declared in addonB.

No I didn't know, cheers. Will certainly be useful for something I want to do with dialogs. Not sure I can use it for the other problems though.

[shinRaiden 0]

Deleting could actually introduce more errors than it would fix. This is because if you delete the bogus class in your addon, but the class is not actually introduced until after your addon, it's a moot point.

As an aside, stringtables loading is completely independent of this whole mess. Stringtables files are loaded strictly by addon file name, independent of the config cfgPatches hierarchy.