[HowTo] Check for addon presence

[VictorFarbau 0]

Note: this mainly applies to SP missions. To start using addons on MP servers makes no sense if you cannot verify that all clients have the required addons installed. In an MP environment you have to let users run into the "You cannot play/edit this mission; it is dependent on downloadable content [...]" message - unfortunately.

I am just posting this so people can easily find a reference to this if needed. Unlike this poor feller who never got a response back then.

If you want to check whether a certain addon is present and certain class names have been defined you might consider this method.

In the given example I want to use 2 planes, an AV8B and a MiG15. The MiG15 is an addon and I won't know whether the machine my mission runs on has this addon available. Solution ("isClass" statement suggested by Deadfast):

_myplanes = ["AV8B"];
IF (isClass(configFile >> "CfgPatches" >> "mig15bis")) THEN
{
    _myplanes = _myplanes + ["Mig15bis2"];
    player sidechat "Found addon Mig15!";
};

How do you know the name of the CfGPatches entry such as "mig15bis"? The way I do it is to create a new mission, place the addon in question and save the mission. After that I open the mission.sqm file and look for the related entry in the "addons[] = " section of the file. This should be the CfGPatches name you can check for later. "MiG15bis2" is a vehicle class name and those names that you will typically use in "createVehicle" statements are to be found in the "class ItemX" statements further down in the mission file.

So if the Mig addon is present, both planes can be spawned. If not only the AV8B will be used. Painless procedure. No more "Warning Message: You cannot play/edit this mission; it is dependent on downloadable content [...]".

If you're really smart you won't place any 3rd party object on your mission map by default. Also, remove all references to 3rd party stuff from your mission.sqm before publishing. Everything gets spawned based on availability. That way your mission runs in every configuration. In addition to the Arma stock addons the user determines the flavor by adding / removing addons himself now. He will love your mission/campaign for this.

Cheers,

VictorFarbau

Edited October 20, 2010 by VictorFarbau

[kylania 568]

The one drawback of this is you might have people with the mod playing with those without the mod. For weapons it'll look like the guy with the mod just isn't holding a weapon at all instead of whatever neat weapon they have. For vehicles however they simply won't exist for the players without the mod, which might cause problems.

[AZCoder 921]

I think providing alternatives in your scripts will make it work, as long as you are not boxed in to requiring an exact mod. For example, check if RH_AK103 exists, if yes add it to character, if not add OA version of AK107, or whatever. This post is interesting because I started using a custom script recently that adds particular RH guns to an ammo box if they exist, and if not, no worries.

[twirly 11]

@Victor....

This is interesting...I'm sure I can make use of this. Thanks for taking the time to post it.

[Deadfast 43]

A much better solution would be to check for the vehicle availability itself, rather than the CfgPatches entry:

if (isClass(configFile >> "CfgVehicles" >> "Mig15bis2")) then
{
    hint "Mig15bis2 available";
}
else
{
    hint "Mig15bis2 NOT available";
};

[5133p39 16]

But do not forget MultiPlayer - as kylania wrote here.

For MP compatible mission, you will have to check for addon availability on every player machine and of course on the server.

If ANY of those machines will be missing that addon, then you can't use it.

And to ensure JIP compatibility, you also have to show JIP player the "missing addon X" message (and kick him out after he clicks "ok, i'll go download it"), because the game might not do it by itself.

(at least as long as it is using any of the "optional" 3rd party addons)

Good idea anyway, and it is doable.

[AZCoder 921]

I would like to ask how you would know if the addon is the correct version on each client? Just because an addon exists does not mean each client has the latest class you want to utilize in a mission. Maybe a new version of Mig15bis comes out, and it adds class Mig15bis_camo1 that I want to put in the mission. I use a method like Deadfast wrote, because that guarantees a particular item is present. By the same token, I use Yoma's addon sync for some things. Anyone know how it determines if an addon needs updating? Does it go by date?

[VictorFarbau 0]

@Deadfast, IMO this not necessarily a better solution, it's just a different approach. Using the Mig15 example you're specifically testing for the presence of one inheriting class. The code above is counting the subclasses per parent. Both approaches lead to the same conclusion: a parent class or a specific class is present so I can use the addon (and all inherting classes).

@All, yes I need to add the MP note, something so obvious that it didn't appear to me.

[AZCoder 921]

@Victor: If you take your approach, and replace mig15bis with AV8B (as an example), you will get no results. If you were to put in CAAir, then it would work, but that doesn't mean AV8B exists. It only tests if the subclass of CfgPatches is present, but not all the child classes. So as I had posted earlier, if the mig15bis addon was updated with a unit class mig15bis_camo1, just testing the CfgPatches will not tell you if the unit class mig15bis_camo1 exists. However if you test for mig15bis_camo1 and it exists, then clearly the addon is present (unless a unit of the same class name exists in more than one addon).

If I am misunderstanding, please let me know :) I think this is a very good topic and I'm glad you started it.

Edited October 19, 2010 by AZCoder

[VictorFarbau 0]

@AZCoder - you are correct, if you want to know whether a specific class "mig15bis_camo1" exists then a boolean test as Deadfast suggested is required. For my purposes checking the parent class is usually enough so excuse my relaxed approach here :)

The question how to catch different addon revisions on client and server, really interesting. In order to avoid undefined states on clients probably a protocol would be required. I could imagine this:

The server defines an array of addon classnames that will be used though a global variable (e.g. "serveraddons"). Clients check local availability and update a second global array (e.g. "badaddons") with class names which are missing on 1 or more clients. After a timeout period the server compares both arrays and limits the "serveraddons" array to the smallest common denominator. Clients get a message asking them to look for updated addons that provide the missing classes.

Could be a start...

Cheers,

VictorFarbau

[AZCoder 921]

Thanks for the reply! Your post caught my attention because I started playing around with this concept about a week ago, and what you wrote about not using 3rd party addons as a requirement is good advice. It struck me that I could put F16's into my campaign if the proper addon is running, or use AV8's if not, so the player is free to choose.

[5133p39 16]

I would like to ask how you would know if the addon is the correct version on each client? Just because an addon exists does not mean each client has the latest class you want to utilize in a mission. Maybe a new version of Mig15bis comes out, and it adds class Mig15bis_camo1 that I want to put in the mission. I use a method like Deadfast wrote, because that guarantees a particular item is present. By the same token, I use Yoma's addon sync for some things. Anyone know how it determines if an addon needs updating? Does it go by date?

I don't know anything about Yoma's addon sync, but i imagine a good way to check for addon version would be something like this:

cfgPatches {
 class myCarAddon {
   [b]version=1.2345;[/b]
   units[] = {"myCar"};
   weapons[] = {};
   requiredVersion = "1.02";
   requiredAddons[] = {"CAWheeled"};
 };
};

and then in the script you can use:

_ver = getNumber(configFile >> "CfgPatches" >> "myCarAddon" >> "version");

...i thought addon makers are using this (or similar method) already, are they not?

[AZCoder 921]

Thanks! Your code sample filled in the missing blank in my head for accessing properties of the class. So now I figured out how to list the units:

_units = getArray (configFile >> "CfgPatches" >> "CAAir" >> "units");

Unfortunately I am not seeing version in any of the mods, BIS or otherwise. Just requiredVersion, and it seems to refer to the Arma2 patch necessary, or 0.1, LOL.

[Deadfast 43]

@Deadfast, IMO this not necessarily a better solution, it's just a different approach. Using the Mig15 example you're specifically testing for the presence of one inheriting class. The code above is counting the subclasses per parent. Both approaches lead to the same conclusion: a parent class or a specific class is present so I can use the addon (and all inherting classes).

That is incorrect. You are simply checking the number of entries inside the CfgPatches entry. That means units[], weapons[], requiredVersion, requiredAddons[], etc.

[VictorFarbau 0]

That is incorrect

What the heck... you're right of course. I am glad I brought this subject up so I could be corrected :) I should have counted units[] instead as I see it.

Cheers,

VictorFarbau

[AZCoder 921]

Just a word of caution. I looked at numerous mods yesterday, and the units array seems to be more of a nice to have. One mod left units empty and put that data in weapons, some list a few or none of the units, and even required addons was hit and miss.

[VictorFarbau 0]

Good point indeed AZcoder. Eventually the quality of the config file is not checked and garantueed. The config creator determines into which category he puts his stuff. And why would a weapons-mod use CfGVehicles if there is a CfGWeapons class? So you need to be very clear upfront what you're looking for. Methods to check for addon presence need to consider this.

I used the method in the first post (just count CfgPatches) to determine the presence of the ACE for my late VFAI mod. Depending on that I would add certain weapons etc. I guess for this purpose counting the patches was an ok method. Deadfast's code using "isClass" is in general a better method for sure. I will correct that.

So I took the MiG15 config, it reads:

class CfgPatches {
   class mig15bis {
       units[] = {"mig15bis"};
       weapons[] = {};
   };
};

Consequently, a

count (configFile >> "CfgPatches" >> "mig15bis")

returns "2" (= units[], weapons[]).

EDIT:

If I'd like to query the details of subclasses such as "units" then I need to use:

getArray (configFile >> "CfgPatches" >> "mig15bis" >> "units")

which returns ["mig15bis"]. But as mentioned before, the addon maker is free to use / mess up the config as he likes so it is not a reliable method to query certain subclasses in order to achieve certain tasks.

Bottom line for me: whenever I'd like to check for addon presence I basically have to have a look into its config file to be sure what I can check for.

I can still imagine that the method I coughed up in post #10 could work to ensure addon presence on both servers and clients. I'll try that in an MP mission soon.

VictorFarbau

Edited October 20, 2010 by VictorFarbau

[Nephris1 10]

I really like thatidea, as ucan adapt a mission for the presence of certain addons.

As i am playing a lot with ZeusAI, i treid to ask if that addon is present, but i guess i made sth wrong.

I used...

IF (isClass(configFile >> "CfgPatches" >> "zeu_sys_ai")) then  {       hint "Zeus available";  }  else  {       hint "Zeus NOT available";  }; 

....in a trigger.

Although the addon was loaded,my hint"Zeus NOT available" kicks in.

What am i doing wrong here?

From the refering config.cpp

class CfgPatches {
class zeu_sys_ai {
	authors[] = {"Solus", "India Kilo"};
	units[] = {};

[VictorFarbau 0]

I installed ZeusAI from this link. Went into the game, open the debug console and copied your code:

isClass(configFile >> "CfgPatches" >> "zeu_sys_ai")

Result: true

Maybe the addons are not loaded on your machine for some reason. Even with an empty units[] entry the class is detected fine by Arma2.

Cheers,

VictorFarbau

[Nephris1 10]

K....:confused:

Gonna check it once again.

If it works for ya the error must be 30cm infront of my monitor i guess,as always.