Overwriting configs.

[andersson 285]

Can someone explain this?

I'm trying to change some small bits here and there. F.ex I tried to change the magasines for the AKS74U and the AKS74UN.

For some reason I couldnt change the mags for AKS74UN. AKS74U's magasines changed to whatever I wanted, I could change whatever I wanted for the AKS74UN except the magasines...

So I started digging in my addonfolders, disabling and activating until I found the problem. It was NWD_Ballistics.pbo.

I opened up that config and this is the part:<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">...more code

class AKS74U : AK74

{

distanceZoomMin = 228; // Real gun has flip-up sights for 200 or 400 m.

distanceZoomMax = 228; // Model has sights set to 400 m, but that's stupid.

};

class AKS74UN : AKS74U

{

magazines[] = {

"30Rnd_545x39_AKSD", "30Rnd_545x39_AK"

};

distanceZoomMin = 110;

distanceZoomMax = 110;

};

class G36a : Rifle

{

distanceZoomMin = 236; // adjusted for 2.5 inch (?) scope height

distanceZoomMax = 236; // zeroed to 200 m

};

...more code

I cant see any wrong with that..

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

{

class andy_fixes

{

units[] = {};

weapons[] = {};

requiredVersion = 1.09.5208;

requiredAddons[] = {"CAWeapons"};

};

};

class CfgWeapons

{

class ak74;

class AKS74U : AK74

{

magazines[] = {"30Rnd_545x39_AK"};

};

class AKS74UN : AKS74U

{

magazines[] = {"30Rnd_545x39_AKSD"};

};

};

I cant see any wrong with that either.. And my addon works when I disable NWD_Ballistics.pbo.

Now to the point, why isnt my addon overwriting his? My addon is in a modfolder after NWD_Ballistics.pbo.

And it doesnt matter if I load mine before or after..

How can another addon make all attempts to change the same values no-go? I can change whatever I want for the AKS74UN except the magasines..

[.kju 3245]

This is indeed strange.

Try to add "NWD_Ballistics" to your requiredAddons definition.

Makes your addon defendant to _Ballistics.pbo, it should be a

problem in your case.

[andersson 285]

Yes, thank you. It did solve my problem.

But this is not good... It work for me as I am fixing my arma because of small errors/compability-issues in addons here and there, so its ok that my addon is dependant.

There must be some logic behind this, if not its very nasty. Making addons behave different depending on what addons are used no matter loadorder.

This can explain people having doubt in loadorder.

I hope I missed something somewhere, but I doubt it.

I also found another addon, TrueInGameUI v1.1.pbo, that I cant change with another, later loaded, addon.

(An explanation on what I'm doing maybe. I'm fixing small bugs and making all addons compatible with each other in my addon-collection by making an addon that are loaded at the end that will overwrite some values. This works very good, except for those two cases.. One example; RHS-weapons now uses FDF-sounds (or whatever soundpack active) and six_tracers and the AWM recoil is also fixed. This is without changing the original addons. This is for my own private SP-game)

edit: It didnt help to add "TrueInGameUI" to make my change overwrite TrueInGameUI v1.1.pbo... It worked with NWD_Ballistics..

From TrueInGameUI:

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

class Ammo : RscIGText {

style = 0x01 + 0x100;

y = 0.001;

idc = 0;

text = "";

};

more code...

My config loaded after:<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class CfgPatches

{

class andy_fixes

{

units[] = {};

weapons[] = {};

requiredVersion = 1.09.5208;

requiredAddons[] = {"CAWeapons","NWD_Ballistics","CAUI", "CAFonts", "CAData", "CA_Anims_Char","TrueInGameUI"};

};

};

class CfgWeapons

{

class ak74;

class AKS74U : AK74

{

magazines[] = {"30Rnd_545x39_AK"};

};

class AKS74UN : AKS74U

{

magazines[] = {"30Rnd_545x39_AKSD"};

};

};

class RscIGText;

class RscInGameUI

{

class RscUnitInfoSoldier

{

class Ammo : RscIGText

{

style = 0x01 + 0x100;

y = 0.001;

// idc = 0;

// text = "";

};

};

};

If I do that small change in TrueInGameUI I can see my ammocounter. If I try to load over that setting from my, later loaded, addon nothing happens even if I add that addon into required addons (you can also see that I put all that addons dependencies into my addon just to make sure. I tried with only "TrueInGameUI" and "CAUI" first)

I must be doing something wrong here....

[.kju 3245]

This one is a fault on your side.

By commenting code, you don't make that change undone

somewhere else.

You have to overwrite the value again with the desired (default)

values.

The first example is strange indeed.

You can try to add the weapon classes you modify to the

weapons[]. However as far as I know, you only need to add cfgWeapon classes in there, if you create new classes and want

the editor detect these correctly and write the cfgPatches class

in the addons(Auto) array of the mission.sqm.

[andersson 285]

This one is a fault on your side.

Haha

Stupid me.. I see that now

But yes, the other example is strange..

[General Barron 0]

Quote[/b] ]There must be some logic behind this, if not its very nasty. Making addons behave different depending on what addons are used no matter loadorder.

This can explain people having doubt in loadorder.

I'm not trying to be rude, but I have to ask: what makes you think you are controlling the load order? What if "people's" assumptions about this are incorrect?

Addon load order is PRIMARILY determined by the requiredAddons[] field of the addon's cfgPatches section, regardless of the "order" of modfolders or addon names.

If there are two addons with exactly the same requiredAddons[], then this is really the only time when addon name determines the order of loading. I'm not sure if modfolder order in the shortcut have any effect on this as well.

One simple way to check the order of addons modifying the same class is by looking into your arma.rpt file after loading the game.

If this weren't true, you would have a hell of a time using mod folders, because you would have to know the dependencies of every single addon, plus their dependencies, and you'd have to make sure they are all put in the correct mod folders, loaded in the correct order, etc etc. The whole point of requiredAddons[] is so this load order is done automatically for you, by the engine.

---------------------

I have v1.16 of nwd_ballistics.pbo here, and this is the requiredAddons section:

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

Here is your requiredAddons section:

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

NWD_ballistics.pbo requires more addons than yours does. So, after CAWeapons is loaded, your addon loads, while NWD_ballistics.pbo is still waiting for CAweapons3 and AA10 to be loaded. So yours is always loaded before his.

[UNN 0]

Quote[/b] ]Addon load order is PRIMARILY determined by the requiredAddons[] field of the addon's cfgPatches section, regardless of the "order" of modfolders or addon names.

I'm not sure thats correct, at least in some cases. I tested the idea out using some config debug techniques.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">__EXEC (LoadFile "Addon A");

It's just a simple test, so it only reports the first addon config to be compiled. To determine the order of all the addons you would have to expand the code.

I made three addons, AddonOrderA.pbo,AddonOrderB.pbo and AddonOrderC.pbo. Each one reporting a message. Initially there were no required addons, the load order was by pbo name. So AddonOrderA.pbo was the first to display the message. When I renamed the pbo to AddonOrderD.pbo, B became the first to report back.

Using this assumption I removed the debug message from AddonOrderA.pbo and added this to the required addons entry:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">RequiredAddons[]={"AddonOrderC","AddonOrderB"};

Despite C taking precedent, addon B was the first to display the message.

I must admit I was surprised when you said requiredAddons field sets the order. I would have imagined that Arma reads all the available configs into memory first, before processing them? The required addons part falls under processing and is only checked once all the configs are in memory e.t.c If that is the case, then it’s down to the order configs are initially loaded into memory.

Like I said it was a quick test and may not apply to andersson's problem. But how the configs are compiled is still an interesting topic on it's own.

[andersson 285]

As I understand this the general assumption is that Modfolder priority is what matters. But I guess thats not the whole thruth after General Barron's input.

Addon load order is PRIMARILY determined by the requiredAddons[] field of the addon's cfgPatches section, regardless of the "order" of modfolders or addon names.

If there are two addons with exactly the same requiredAddons[], then this is really the only time when addon name determines the order of loading. I'm not sure if modfolder order in the shortcut have any effect on this as well.

I'm not 100% sure of this, but I believe I experience different result depending on which order I load my modfolders (same way as in Oblivion). But I have to do some testing to take it as a truth..

But if I understand you right there is no way to change addons loadorder except from altering them? So all addons I download have a loadorder that is totally dependent on what the authors put into requiredAddons[], and the modfolders is only used to have order and to more easilly load/not load certain addons?

If so then thats really bad news for me..

If load order is PRIMARILY determined by the requiredAddons[], what is the secondary?

The whole point of requiredAddons[] is so this load order is done automatically for you, by the engine.

I thought that the reason for that was, in some way, tell the engine what earlier loaded configs is relevant to the config loaded right now. But I dont know, thats what I thought.

If what you say is true then if I put all BI addons into requiredAddons[] I make sure my addon is loaded last and will overwrite all other configs?

Like I said it was a quick test and may not apply to andersson's problem. But how the configs are compiled is still an interesting topic on it's own.

My problem is not that interesting anymore as that will be solved when I understand how the config works. The compilation is a very interesting AND important topic. All the badly done configs that are in addons.. Addonmakers need to know more about this.

I'm not trying to be rude, ..

I dont take you as rude, I'm glad for your input. I hope you dont take me as rude/negative as I try to understand this. Its a discussion I hope will shed some light over this.

edit: did a quick test with loadorder. I put the modfolder that I have my addon in to load before the modfolder with NWD_Ballistic.pbo. IF the loadorder matters NWD_Ballistic.pbo should overwrite my config and I would be able to load the AKS74UN with non-SD mags.

Result, I couldnt. The loadorder in this case didnt matter.

For information; My requiredAddons[] isnt like the example above, I have more addons there now. But this still shows that only loadorder (a'la Oblivion) isnt enough.

[General Barron 0]

Quote[/b] ]I must admit I was surprised when you said requiredAddons field sets the order.

I didn't say this! It influences the order, but does not set it 100%.

Here is the easiest way for me to explain it. I don't know if this is how the engine handles things internally, but the end result is the same:

------------------

Take a simple example, where all addons are in one folder.

1) When loading, the engine first loads the config from dta\bin.

2) Next, the engine grabs the first addon (in alphabetical order) from the addons folder.

3) The engine checks the requiredAddons[] section of that addon's cfgPatches.

4) IF all the addons listed in requiredAddons[] have already been loaded,

5) THEN the engine adds the cfgPatches classname to its list of addons that have been loaded, and merges the addon's config into memory. If this addon uses classes that already exist in memory, they are modified/overwritten in memory at this stage. Also, if the addon relies on an external class that doesn't yet exist in memory, problems can arise at this stage.

6) ELSE the engine ignores the addon, moves on to the next addon (in alphabetical order), and goes back to step #3.

7) Once the engine hits the end of the addons folder, it loops back to the top of the addons folder and repeats the process, ignoring addons that have already been loaded.

8) The engine keeps looping thru the folder until all pbo's have been loaded.

------------------

This process will always load every addon, unless you have two addons that require each other. In this case, the engine throws you an error and won't load ("circular dependency").

If you want to throw mod folders into the mix,, use the same process but assume that the engine loops thru the default addon folder first, then the first mod folder, then the second mod folder, etc.

Basically, this means that you can force the engine to look at addon ZZZ.pbo before it looks at addon AAA.pbo, by putting them in different mod folders. It will still skip over an addon, regardless of folder, if it doesn't have all the requiredAddons[] loaded yet.

raedor was correct in the thread you linked to. ONLY if two pbo's have the SAME requiredAddons[] section will the mod folder order (and/or alphabetical order) matter. The LAST loaded pbo takes priority in this case.

Notice that the ORDER of requiredAddons[] doesn't matter, only the CONTENT.

Also, notice that the requiredAddons[] only "has" to be used for configs. What I mean is, if your addon requires models or sounds or scripts from another addon, you don't HAVE to put them in "requiredAddons"; everything will still work fine IF you have those addons installed. However, if you DON'T have those addons, your game will crash, so it is best practice to put them in requiredAddons[] as well, to prevent such errors.

-----------------

This may sound like a complicated process, but it is really quite simple. You are right though, most addon makers don't use the system properly, or even understand it. Really the only rule you need is this:

In your requiredAddons[] section, put the cfgPatches class of EVERY PBO that you use ANY resource from. This includes classes, textures, sounds, models, and anything else.

-----------------

The only problem arises when you are trying to cater for 3rd party content.

How do you handle things when you have 5 addons all trying to modify the same class? Easily if you know what those addons are.

But how do you handle it when you can't predict what those addons will be, because they may not exist yet or be created by you?

Basically, how do you make YOUR addon take priority over EVERYBODY ELSE'S addon?

Well, obviously you can't. Everyone else has access to the same tools you do, so you aren't special and you can't do that.

The best you can do is fill your requiredAddons[] with all of the BIS addons, and hope that everyone else doesn't start doing the same thing.

[andersson 285]

Thank you very much, that indeed explained alot and put all the bits and pieces together!

So modfolders do affect the end-result in a limited way, but requiredaddons[] is the clue.

-----------------

The only problem arises when you are trying to cater for 3rd party content.

How do you handle things when you have 5 addons all trying to modify the same class? Easily if you know what those addons are.

But how do you handle it when you can't predict what those addons will be, because they may not exist yet or be created by you?

Basically, how do you make YOUR addon take priority over EVERYBODY ELSE'S addon?

Well, obviously you can't. Everyone else has access to the same tools you do, so you aren't special and you can't do that.

The best you can do is fill your requiredAddons[] with all of the BIS addons, and hope that everyone else doesn't start doing the same thing.

This is a problem yes.. Not for me with my "fix-it-addon" as I can open up and do whatever necessary. But from a community perspective this can be a problem..

[UNN 0]

Quote[/b] ]didn't say this! It influences the order, but does not set it 100%.

Well originally you did say:

Quote[/b] ]Addon load order is PRIMARILY determined by the requiredAddons[] field of the addon's cfgPatches section

Which threw me a bit as from my point of view, the addon name e.t.c is primary (i.e. the first to be considered). Perhaps I took it out of context, as you may have been referring to anderssons specific enquiry, rather than Addons in general. But that’s not really important.

While anderssons example is different to the problem I face. I'm still not 100% convinced, so I want to do more tests.

I can't really see why the requiredaddons would do anything more than ask Arma to check for the presence of the corresponding cfgPatches entry in memory?

If I understand you correctly. What your saying is. Every time Arma encounters an entry in requiredaddons, it reloads the config for that addon and overwrites any previous config entries loaded?

Like I said, I'm just interested in how Arma handles all of this. To learn more, I need to do more tests. Only I have to decide what I actually want to test first, before I start devising anything. So I'm always looking for any information or examples, to help narrow it down.

Cheers

[andersson 285]

Please post your findings UNN, I'm not completely understanding this yet though I can now make it work. I need to test more to be sure.

I would like to grok it to use it in the best compatible way...

[General Barron 0]

Quote[/b] ]I can't really see why the requiredaddons would do anything more than ask Arma to check for the presence of the corresponding cfgPatches entry in memory?

If I understand you correctly. What your saying is. Every time Arma encounters an entry in requiredaddons, it reloads the config for that addon and overwrites any previous config entries loaded?

Hmm... no I must not have been clear. What I'm saying, is that the engine won't load an addon (i.e. read it's config into memory) until all its requiredAddons have been loaded.

So if addonA requires addonZ, then addonA will ALWAYS be loaded AFTER addonZ, no matter what the order of modfolders or pbo names for the addons are.

Now, in the above example, addonZ might require addonX and addonY. So before addonZ loads, it needs to wait for addonX and addonY to load. But those addons will require other addons, which require other addons, etc etc.

If all the above addons are trying to overwrite the same property in the same class, then addon load order makes a HUGE difference.

If mod folders determined addon load order, then you would be able to force addonA to load BEFORE addonX, Y, and Z, simply by putting them in different folders. But this is not the case, as seen in andersson's example. His addon was trying to overwrite the same properties as NWD's addon, but no matter where his addon was in a mod folder, NWD's always was loaded after his.

That is what I mean when I say:

Quote[/b] ]Addon load order is PRIMARILY determined by the requiredAddons[] field of the addon's cfgPatches section

The only time when other factors come into play (mod folder order and pbo name) is when the requiredAddons[] section holds the same addons (doesn't have to be the same order though).

In this case, both addons can be loaded at the same time, because their requiredAddons are all loaded at the same time, because they are identical. When this happens, *something* has to determine the order, which could be mod folder ordering, pbo name, or something "random" relating to the name/ordering of pbos in your addon folder.

Basically, if both addons have the same requiredAddons, then load order is just determined by which addons the engine runs into next after it has loaded all the requiredAddons. This depends on where the engine is in the addons folder when it finishes loading the required addons.

[UNN 0]

First off, let me explain my interest, just in case it's relevant. I want to overwrite existing classes in a slightly different way to anderssons example. Something like:

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

       {

       class MySoldier

               {

               units[] = {};

               weapons[] = {};

               requiredVersion = 0.1;

               requiredAddons[] = {CACharacters};

               };

       };

class cfgVehicles

       {

       class Man;

       class CAManBase : Man

               {

               weaponBone = "myweapon";

               };

       };

So from now on, once this addon is installed, anything inheriting from CAManBase will use the new weaponbone. It's just an example I'm not actually modifying the soldier selections. It probably is the same as anderssons problem, but in this case, less likely to be overwritten by another addon, but I still want to make sure.

There are three methods I can think of to debug config compilation and inheritance. The obvious one is changing something visible like a units name or weapon e.t.c The other two are:

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

class cfgVehicles

       {

       class SoldierWB;

       class AddonOrderA : SoldierWB

               {

               EXEC(LoadFIle "Addon A1");

               scope=2;

               };

       };

Which results in this output as the game loads:

And

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

class cfgVehicles

       {

       class SoldierWB;

       class AddonOrderA : SoldierWB

               {

               scope=Call Compile "LoadFile ""Addon B""";

               };

       };

Which results in this output as the game loads:

Please note I had to remove the two undersores that preceed EXEC, somehow it screwed up the forum post if I left then in.

As you can see, both the last two methods, output at different stages during the game load sequence. So I thought it worth mentioning as it could influence the way I interpret my test results.

Quote[/b] ]Hmm... no I must not have been clear. What I'm saying, is that the engine won't load an addon (i.e. read it's config into memory) until all its requiredAddons have been loaded.

So if addonA requires addonZ, then addonA will ALWAYS be loaded AFTER addonZ, no matter what the order of modfolders or pbo names for the addons are.

Now, in the above example, addonZ might require addonX and addonY. So before addonZ loads, it needs to wait for addonX and addonY to load. But those addons will require other addons, which require other addons, etc etc.

So using the debug methods I mentioned above, what would be a reasonable test to prove this?

If I placed this line in addonY:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">EXEC(LoadFIle "Addon Y");

And this line in addonZ:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">EXEC(LoadFIle "Addon Z");

I should expect to see addon Y processed before addon Z, because of the dependencies you mentioned above.

Does that sound like a reasonable assumption?

Cheers

[General Barron 0]

Quote[/b] ]

I should expect to see addon Y processed before addon Z, because of the dependencies you mentioned above.

Does that sound like a reasonable assumption?

Hmm... I have no idea, I've never seen your debugging methods. I didn't even know you could use __EXEC in un-RAPified configs.

I do see a possible flaw in your assumptions though. You are assuming that the config is preprocessed--meaning, all defines and macros are expanded--at the same time that it is merged into memory.

I don't see how this could be possible. The defines and macros can change things such as the requiredAddons, for example, so I'd think they MUST be parsed in a step BEFORE addon load order is determined.

For example, if I write:

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

#define MYADDONS {CA_core}

class cfgPatches

{

class myaddon

{

requiredAddons[] = MYADDONS;

.....

Then in this case, the preprocessor MUST be run over the config to process that #define, BEFORE the engine can read the requiredAddons[] section, so that it can determine whether or not to merge the config into memory.

[UNN 0]

Quote[/b] ]Hmm... I have no idea, I've never seen your debugging methods. I didn't even know you could use EXEC in un-RAPified configs.

EXEC is new to me, I've only started messing with it since reading some of your comments about #defines e.t.c That Q posted on the ACES forums. We were looking for a way to allow #IfDef to somehow respond to the presence of another addon.

Quote[/b] ]I do see a possible flaw in your assumptions though. You are assuming that the config is preprocessed--meaning, all defines and macros are expanded--at the same time that it is merged into memory.

I don't see how this could be possible. The defines and macros can change things such as the requiredAddons, for example, so I'd think they MUST be parsed in a step BEFORE addon load order is determined.

That was always at the back of mind and since you mentioned it, I noticed the EXEC message appeared before any standard Arma addon dependency message. Although I think it's safe to say the EXEC message, at least gives you an indication of the load sequence. Even if there processed in a different order.

As for the Call Compile method, that does come after processing the dependencies. In fact it's completely separate, but I guess that does not mean it reflects the processing order.

So I knocked up three separate addons, the first setting dependencies and the other two reporting the sequence of events from the EXEC and Call Compile perspective. Both followed the same order as the pbo name, regardless of how I sorted the addon dependencies list. Although like I said, it stil didn't guarantee an true picture of how configs are processed.

So I then modified the test addons, to look like this:

AddonOrderA.pbo:

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

       {

       class AddonOrderA

                {

                units[] = {"AddonOrderA"};

                weapons[] = {};

                requiredVersion = 0.1;

                requiredAddons[] = {"AddonOrderC","AddonOrderB"};

                };

       };

class cfgVehicles

       {

       class SoldierWB;

       class AddonOrderA : SoldierWB

                {

                displayname = "Addon A";

                };

       };

AddonOrderB.pbo:

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

       {

       class AddonOrderB

                {

                units[] = {"AddonOrder"};

                weapons[] = {};

                requiredVersion = 0.1;

                requiredAddons[] = {};

                };

       };

class cfgVehicles

       {

       class SoldierWB;

       class AddonOrder : SoldierWB

                {

                displayname = "Addon B";

                };

       };

AddonOrderC.pbo:

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

       {

       class AddonOrderC

                {

                units[] = {"AddonOrder"};

                weapons[] = {};

                requiredVersion = 0.1;

                requiredAddons[] = {};

                };

       };

class cfgVehicles

       {

       class SoldierWB;

       class AddonOrder : SoldierWB

                {

                displayname = "Addon C";

                };

       };

Not matter which way I order the requiredaddons in AddonOrderA.pbo, "Addon C" always appears in the mission editor, overwriting "Addon B".

I know this is still removed from anderssons problem, as I'm creating new classes instead of modifying existing default Arma classes. It just seemed like the next logical thing to test.

When I get a chance I will try and setup something closer to the original post and use separate Mod folders to.

[andersson 285]

Not matter which way I order the requiredaddons in AddonOrderA.pbo, "Addon C" always appears in the mission editor, overwriting "Addon B".

I believe that is because "Addon B" and "Addon C" have the same requiredaddons[], "Addon C" is loaded after because of order of name.

The requiredaddons[] for "Addon A" doesnt matter as that addon creates another unit then B or C (class AddonOrderA vs class AddonOrder).

Not tested but I think if you do it like this B will be loaded after C:

AddonOrderA.pbo:

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

{

class AddonOrderA

{

units[] = {"AddonOrderC","AddonOrderB"};

weapons[] = {};

requiredVersion = 0.1;

requiredAddons[] = {};

};

};

class cfgVehicles

{

class SoldierWB;

class AddonOrderA : SoldierWB

{

displayname = "Addon A";

};

};

AddonOrderB.pbo:

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

{

class AddonOrderB

{

units[] = {"AddonOrder"};

weapons[] = {};

requiredVersion = 0.1;

requiredAddons[] = {"AddonOrderC"};

};

};

class cfgVehicles

{

class SoldierWB;

class AddonOrder : SoldierWB

{

displayname = "Addon B";

};

};

AddonOrderC.pbo:

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

{

class AddonOrderC

{

units[] = {"AddonOrder"};

weapons[] = {};

requiredVersion = 0.1;

requiredAddons[] = {};

};

};

class cfgVehicles

{

class SoldierWB;

class AddonOrder : SoldierWB

{

displayname = "Addon B";

};

};

Now "Addon B" will wait for "Addon C" as that is required. "Addon A" is actually not part of the test as I see it(?)

I know this is still removed from anderssons problem, as I'm creating new classes instead of modifying existing default Arma classes. It just seemed like the next logical thing to test.

No, its not I'm trying to do everything. I'm overwriting arma values, 3d-party addons and a mix of that as some 3d-party addons overwrites arma..

F.ex, I have an addon that makes RHS-weapons to use six_tracers and FDF-sounds and also replaces arma weapons to RHS.

[.kju 3245]

Maybe send Suma a pm.

[UNN 0]

Quote[/b] ]No, its not I'm trying to do everything.

Well my point was more to do with the specific problem General Baron replied to. I've only tested the basics so far, all of which are different to the scenario that General Baron originally commented on. I was kind of covering my bases

Quote[/b] ]Maybe send Suma a pm.

I hope he has better things to worry about. Plus I don’t mind testing it from the ground up, probably helps in the long run.

[andersson 285]

@UNN, have you tried what I suggested regarding Addon A,B and C? I cant try it myself right now and I'm curious if my example worked

[UNN 0]

Yeah, cheers.

I did a quick test, I just wanted to try a couple more things out, before posting anything else.

[General Barron 0]

I came across this in the biki:

Quote[/b] ]

Talk:PreProcessor Commands

From Bohemia Interactive Community

Jump to: navigation, search

Isn't this where we mention EXEC? --Doolittle 18:40, 23 August 2007 (CEST)

No. EXEC are not done by preprocessor, they are evaluated by config parser. Preprocessor is not limited to config files, it is used for scripts as well. However, you have a point that those two should be documented somewhere.--Suma 21:18, 7 January 2008 (CET)

Anyway, I guess all I'm pointing out here is that a different process handles EXEC macros vs handling #include #define / etc.

I don't know if that is in any way relevant to the discussion here.

[UNN 0]

I managed to try out a few more things. Yeah, as soon as you start arranging the required addons in the way andersson posted, you start to see the shift in priority General Baron mentioned. But finding a definitive way of setting the order looks a little more complicated. But so far I've seen the following:

Addons with no entries in thier requiredaddons fields, or addons that require other addons that have no requiredaddon dependencies. Are processed in order of the *.pbo name.

As General Baron said, adding dependencies to default Arma addons will force that addon to be processed last. But it did not appear to be so clear cut (unless I missed something in the original reply) if another addon is introduced. If that addon shares any one of the default arma addons, in it's required addons field. The order will revert back to being sorted by *.pbo name. It does not appear to matter how many addons you add to a pbo's requireaddons field, as soon as one of them are matched, it reverts back.

I did some quick experiments with user defined cfgPatches, to see if I could force an addon to be processed last. By using unique (to the addon maker) entries in the requiredasddons section. But there are plenty more things to try out.

Quote[/b] ]I don't know if that is in any way relevant to the discussion here.

It's anderssons thread, but it sounds like we all have a general interest in the topic? So it's all relavant from my point of view.

Quote[/b] ]Anyway, I guess all I'm pointing out here is that a different process handles EXEC macros vs handling #include #define / etc.

EXEC is great for passing variables from scripts back to the config. For values being passed to script from a config, we can use the new Arma commands. The problem we were looking at on the ACES forum was mainly to do with #define and #IfDef. I think it stems from the fact that #IfDef only checks for a corresponding #define and does not care what has actually been defined. So if we did:

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

#define MYVALUE = EVAL (ReturnValue);

Then this test would return true, even though it's been passed a nil value from a script.

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

I’ve tried all sorts of combinations using #includes, $Stringtables, Scope and EVAL. But so far no luck I can't get #IfDef to return true or false depending on the presence of another pbo.

[andersson 285]

As General Baron said, adding dependencies to default Arma addons will force that addon to be processed last. But it did not appear to be so clear cut (unless I missed something in the original reply) if another addon is introduced. If that addon shares any one of the default arma addons, in it's required addons field. The order will revert back to being sorted by *.pbo name. It does not appear to matter how many addons you add to a pbo's requireaddons field, as soon as one of them are matched, it reverts back.

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.

As I see it now its the pbo-name order thats sets the initial loadorder, modfolders affect that. But arma doesnt process an addon if its dependant on another addon not yet loaded so it waits until all its dependancies are processed, and when that happens that addon is processed and the next addon not yet processed in nameorder have its turn. So if addon B and C waits for addon D and E (both are dependent on the same addons "requiredaddons["D","E"]) the loadorder will be: DEBC. IF you put addon B in a modfolder loaded after the rest of the addons the order will be DECB as then the modfolder changes the order of the pbonames.

So it "reverts" back to pbo name if two or more addons have the same requiredaddons. In my DEBC example without modfolder there is no reason for B to be loaded after C.

In short; arma primarily process by addon name, but some addons must wait for information from other addons. Modfolders affect the nameorder.

You maybe already understand all this and I didnt understand your input. 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.

And I can be wrong.. So I'm waiting to be corrected

[General Barron 0]

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?

It would be dirty, but it could work.

-----

Okay, I'm about to go off of andersson's original topic and start pursuing UNN's topic:

Quote[/b] ]EXEC is great for passing variables from scripts back to the config.

Can you please expand on this? Do you mean, you can get values back from the game in real-time? Can you give some examples?

Quote[/b] ]<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">EXEC (ReturnValue=nil)

#define MYVALUE = EVAL (ReturnValue);

Then this test would return true, even though it's been passed a nil value from a script.

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

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.

#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:

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

#ifdef SOMETHING

//this point will be reached

#endif

Preprocessor directives can NOT be used to do any form of runtime evaluation, they are ONLY used for find, replace, and paste operations.

Quote[/b] ]I’ve tried all sorts of combinations using #includes, $Stringtables, Scope and EVAL. But so far no luck I can't get #IfDef to return true or false depending on the presence of another pbo.

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

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

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.