Strange Addon Error

[JamesF1]

I'm having a small problem that I can't seem to get rid of.  I'm making an add-on, and I've got some resources in different PBOs.  I've got some ammo boxes defined in a particular PBO, which works fine, etc, and I've got some frequently-used mission-related scripts in another PBO.

One of the PBOs is a supply-drop script, of sorts... it attaches a parachute to one of the custom ammo boxes, and drops it (to be simplistic about it's purpose).  When the script is called ammo box is created with createVehicle, I get the following error:

Addon hmm_units (entry HMM_DropBox) not found in the list of active addons.
Warning Message: You cannot play/edit this mission; it is dependent on downloadable content that has been deleted.
hmm_units

Nothing strange about that... however, here's the weird part... the PBO mod-folder is loaded and the correct ammo box (class name "HMM_DropBox") still is created, attached to the 'chute, and still falls to the ground (with all the correct ammo, etc.).  Maybe I'm overlooking something, but why does the error still occur if the box is clearly loaded correctly?

Any help would be greatly appreciated.  I'm stumped with this one.

[i0n0s]

This is a warning that the HMM_DropBox is not in the addon-array of the mission.

You can use activateAddons to get around this.

[JamesF1]

While activateAddons does solve the problem (and thank you very much for pointing me to it ) - how do I solve this in a more 'permanent' way (i.e. the 'correct' way).

HMM_DropBox is included in the config.cpp of "HMM_Units", and HMM_Units is included thus (in mission.sqm):

Code: [Select]

addOns[]=
{
<various addons>
"HMM_Units",
<etc>
};
addOnsAuto[]=
{
<various addons>,
"HMM_Units",
<etc>
};
The HMM_DropBox class is included in the "HMM_Units" CfgPatches entry, too, in case that would have been a problem:

Code: [Select]

class CfgPatches
{
    class HMM_Units
    {
        units[] = {
            "HMM_WeaponsBox",
            "HMM_MagazinesBox",
            "HMM_OrdnanceBox",
            "HMM_DropBox",
            "HMM_MH6"
        };
        weapons[] = {
            "HMM_M4A1_AIM_SD",
            "HMM_Mk48"
        };
        requiredVersion = 0.1;
        requiredAddons[] = {"CAWeapons","CAWeapons2"};
    };
};Am I missing something?  Even tried changing the case in the mission add-ons (e.g. to "hmm_units"), but to no avail.

[Worldeater]

Wild guess: The PBO that contains the scripts seems to require the "HMM_Units" addon. Did you try to add "HMM_Units" to the list of requiredAddons[] in the script's PBO?

[JamesF1]

Alas, that wild guess was not the ticket

[Planck]

What does the config entry for "hmm_dropbox" look like?


Planck

[JamesF1]

Looks like this (a tonne of magazine classes removed, but they are all syntactically perfect, and functioning):

Code: [Select]

class HMM_DropBox: ReammoBox
{
    scope = 1;
    accuracy = 1000;
    displayName = "Supply Drop Box";
    model = "\ca\weapons\AmmoBoxes\USBasicAmmo.p3d";
    class TransportMagazines
    {
        <bunch of magazine classes>
     }; 
};
Changing the scope to 2 has no effect.

[Planck]

Is 'class ReammoBox;' listed in your config before it is inherited from later on?


Planck

[JamesF1]

Yup.  And it doesn't error on any of the other 'custom' ammo boxes which are in the mission, which are also defined in the same config, in the same manner.  It only errors on this one box, when the class is passed to createVehicle.

[DeanosBeano]

  scope = 1;  
 change that to Scope =2;

  i believe scope 1 will also create errors such as you have too.
  in other time when something is to be created by a script , you should create one somewhere off the map before you save the mission ( only possble if scope2 is used) doing this will guarantee all required addon inc the ones to be spawned from a script are loaded , this will also reduce Lag spikes .

the following  is from the wiki But  i dont think its totally correct in
 

#define private    0
#define protected  1
#define public     2

The meaning of each is as follows

private:

Only other classes inherit this class. It is not createVehicle'able, nor can the class be accessed via the Mission Editor.

private is a common method of grouping base characteristics together and inheriting all those common characteristics into a class that can be viewed or accessed.

public:

Any classes declared public are CamCreateabale, and selectable via the Editor.

protected:

Identical to public, except the class will not be listed in the mission editor.

[kju]

Scope should not the problem. The message indicates the said class not
being defined in units or weapon array of the cfgPatches class.

Please post the complete config in here:
http://pastebin.jonasscholz.de/

[JamesF1]

 scope = 1;  
 change that to Scope =2;

Makes absolutely no difference, already tried it   Also tested futher, you can definitely createVehicle objects with scope = 1 (didn't test with scope = 0).

The addon is loaded, as ammo boxes in the same config (which are scope=2) are placed and display without error.  The error only occurs when using createVehicle on the HMM_DropBox class (but the box is created successfully, despite the error).

Please post the complete config in here:
http://pastebin.jonasscholz.de/

Duly done (relevant parts highlighted)!  The config has changed slightly from when I first asked the question... for a start, the MH6 port from A1 is no longer in that config

Thanks for all the help, guys... I'm just baffled as to why the ammo crate works... but still gives an error anyway.

[kju]

Looks good.

Suggestions:
1) Do you have the create placed in a remote location in the mission.
2) Try to remove it, and the addons(auto) entries of your addon. Load the mission, place it again and save.
3) Make a new mission a place the crate and a characters. Check sqm and loading the mission.

[JamesF1]

Well, I have another PBO with some scripts in it (that's part of an internal add-on for my squad), and one of those scripts is a supply script that creates the crate... so it's not local to the mission folder/PBO itself.

[DeanosBeano]

 My bad on this specific problem , just had a long drive thought it was the ammobox was erroor not the HMM_units .
 I do stand by my theory in overall scenario that scope 1 is for base class and those inheriting should be scope 2 .

 Anyway back to your problem i dont have any errors creating the ammobox using your pasted config, so i guess its a simple case of how the mission is being set up or the way the addons are loaded or not.

 some off the wall ideas though just incase.

 could it be you havent binarised and there is no PBOprefix ?

 are you the one getting the error or is it a friend on aserver that actually doesnt have the addon  , it is possible for people to join servers without the ness addons , if the addon is only created inb a script ( another good example of why its good practice to place a dummy of any custom addons to be createvehicled before saving ) ?

  does the other pbo that has the scripts  had as a required addon hmm_units ?  

 finally , i have seen a few people with this problem since arma2 , i am beggining to wonder if there is some changes in arma2  config set up that we havent noticed yet .

 
 
 

  

[JamesF1]

I do stand by my theory in overall scenario that scope 1 is for base class and those inheriting should be scope 2 .

Ordinarily I'd agree with you - but in this case, the HMM_DropBox ammobox serves only to be used by a single script, so it's just easier (from my POV) than cluttering the in-game menu.

could it be you havent binarised and there is no PBOprefix ?

Nope, checked those.

are you the one getting the error or is it a friend on aserver that actually doesnt have the addon  , it is possible for people to join servers without the ness addons , if the addon is only created inb a script ( another good example of why its good practice to place a dummy of any custom addons to be createvehicled before saving ) ?

I get it, a friend (also with the addon) gets it, etc.

  does the other pbo that has the scripts  had as a required addon hmm_units ? 

Yes, but it made no difference to the problem even when removed.

finally , i have seen a few people with this problem since arma2 , i am beggining to wonder if there is some changes in arma2  config set up that we havent noticed yet .

Yeah, that's what I was thinking.  Strange that 'activateAddons' in the script would make it work, though, if that were the case.

Thanks very much for your help/suggestions   Looks like I'm just going to have to stick to calling activateAddons in the script, and hope it's sufficiently 'future-proof'!

[DeanosBeano]

 well it keeps looking like one of those something simple missing/somethings broken in the game to me which are always frustrating.

 

Looks like I'm just going to have to stick to calling activateAddons in the script, and hope it's sufficiently 'future-proof'!

I heard somewhere that using this in configs or was it if called  can overwrite the addons  activated in mission .sqm ?

  maybe one time someone will find time to sort all this out but for now sounds like you found a way .

 

[JamesF1]

I meant in the script (right before the createVehicle) rather than the config - but, at least now I know not to use it in a config 

[DeanosBeano]

 yeah i got you n that mate ,
 What i said was me thinking out loud dont worry , i believe some things can call from inits and it messes up in multiplayer.
 However i did come across something similar if not opposite to this once where someone wrongly used required addons and when the addon was loaded but not even used in a mission the addon was autosaved to the .sqm i dont know if its poss but it seemed they configured it that a core file  required there addon ( unnecessarily), there is obviously something somewhere that's changed in A2.

 

[DMarkwick]

I've got what might be a related issue. It's to do with the Fire&Smoke addon, a member over at BIS tried it out for me on his server, and he reported that, although the addon continued to function apparently normally, people did receive a "you cant play this mission, it requires JTD_FireAndSmoke" error ingame, when someone else did something that caused a spawn of a custom object. Even though everyone did indeed have that addon.