Avoiding Conflicts between Addon Version and Script Version of a Project

[Loyalguard]

This post involves addon config and scripting issues, as well as mission scripting issues...but posted here as addon configs/scripts are of most interest to me at this point...

As part of my new project (Chernarus Electrical Grid), I am considering a "script only" as well as an "addon" version (there are no new classes, just scripts).  So, if a mission maker wants to include the grid in his mission without requiring addons he can do so...and if a player/server wants to have the electrical grid without it being in the mission they can do that as well.  As such, I have 2 questions...

One of the obvious requirements of releasing two different "packages" like this would be to avoid any potential conflicts caused by the script version being present in a mission AND the player/server having the addon installed and loaded.  My primary plan do to do this would be to initialize a global variable in the addon version that would be checked by the script version.  If the gv is nil, then activate the script version.  If the gv is not nil, skip the script version.  i.e.

in addon version:

Code: [Select]

CEG_addon = true;
First line in script version:

Code: [Select]

If (!isNil "CEG_addon") then {exitWith};
As a basis for the above, I am assuming that the addon is initialized BEFORE scripts executed from the init.sqf are executed.  I believe this to be correct, but if it is not then the above would need to re-worked.

So, Question 1: Is the above method best/correct?

I think the above would resolve 95% of all potential conflicts...that is, if addon version is present then do not use script version.  But, I am also using custom dialogs and sounds in the project...so this brings me to the second area of interest...what should I do to avoid conflicts with these?

Currently, there are only #include statements in the description.ext that point to the files that define the constants and dialog class definitions as well as the sound class definitions.

i.e.

in Description.ext:

Code: [Select]

class CfgSounds
{
 sounds[] = {};   
 #include "CEG\Sounds\CEG_Sounds.hpp"
 
 //Insert other custom sounds or #include lines for your mission here.
};

...

//Dialogs
#include "CEG\Dialogs\CEG_Dialogs.hpp"
So, Question 2: Since I cannot stop the engine from pre-processing these includes on startup (I don't think), in the case of the script and addon versions both present, what do I need to do prevent errors/conflicts with sound and class definitions?  Do I have to re-name them in one of the versions in order to avoid member already defined errors?  Do I need to do anything, that is, can the same class names be defined in a description.ext AND an addon without conflict?

Question 3: If there is anything else I need to consider to avoid conflicts, please let me know!  Thanks!

[i0n0s]

Answer 1:
If the addon is present, you can find it in cfgPatches>>AddonName

[Loyalguard]

Aha, thanks, so instead of checking for the variable, something like this instead (assuming my addon class name was "CEG"):

Code: [Select]

// If CEG_addon is not present then exit script immediately.

if (isClass (configFile >> "cfgPatches" >> "CEG")) exitWith {};


[Wolfrug]

Answer 2: Yes, sounds defined in the description.ext can be doubly defined in a config.cpp without conflict (at least in ArmA, not sure in Arma 2 actually). I did this with RUG DSAI (ran both the script and the addon together) and it seemed to work just fine. I'm not sure which sound takes precedent - if you try it for fun, do let us know (i.e. if the description.ext sound or the addon sound is the one played, if named the same).

Wolfrug out.