BAS OH58 Problems

[beowulf2014]

I' ve noticed a very weird thing with these AND also with the 21VBCargo Addons....they "embed" themselves into missions without you wanting them to so that even if you didnt use that addon in your mission if you dont put that name into the .sqm file or someone wants to play your mission without that addon then it pops up and tells you Cannot load mission missing "put addon here". Is there away to stop this other than unbpoing it and fixing the config or something? Also I noticed when I tried to use the "vrs.sqs" script with it added that it crashes my game when the vehicle respawns! Now I have been succesfull in respawning everything from the Commanche to the M109ADATS with the script but that BAS one doesnt like it. lol
Any ideas?

[deaddog]

Did you ever put an addon unit in a map, save it, then later decided to remove it?  If so, then you have to manually remove the addon entry in the addons section of the mission.sqm file.  That's ALL the addon sections:  addons, auto addons, Intro and Outro addons as well.

If you already knew that then that's not your problem  

Also, some addons require other addons to work.  It gets to be a mess with addons sometimes.  

[beowulf2014]

Yes i did know that but i appreciate the input. the problem persists with addons like 88.pbo
21VBGlide.pbo etc...its really weird.
Not the only one experiencing this though. 35 members in my group and we all have these problems

[VUSN042]

Just a thought...

The problem could be that the addon defines classes that are named identically to those defined in other addons.  When duplicated classnames appear in an addon used in your mission, OFP could be getting confused with the class registration of another addon that you haven't actually used in that mission.

In general, you can just ignore the error message and continue, it's really just a class registration problem (so far as I've been able to tell) and not critical.

I've had this problem myself.

[Messiah]

but the BAS tag should eliminate that problem

[beowulf2014]

also on servers even if your not using that addon what it does is boot you out of the server even if the addon isnt in the map. its weird that way

[Tomb]

  I don't have any problems re. spawning bas-birds?!

If their cpp contains the requiredAddons[] = {tmb_something}; , then this might be the bug.

At least I've had trouble with this "requiredAddons..." (also other addons using these cpp requirements).
But then again, at other times it works just fine!

 :hmm: Here's a valid shot - take it or leave it :


As the game engine reads through a mission file, it reads which addons it needs to pre-load to get the mission running.
Now, as SOME addons aren't >DIRECTLY needed in the preLoad, the game engine doesn't read these PBO files - it only reads thru those addons that is used on the map when the mission begins.

Right, and if some addon needs a pilot/driver/weapon or alike, I'm not sure the OFP engine reads these PBO's unless off course that particular driver/pilot is visible on the map right away when the mission is starting.
And then you have a possible bug - that is if your CPU back home is one of these tired old women in need of a "pensioners inn" soon!   ;D

Dunno, its just a guess - but I think it is related to such stuff. And it doesn't exactly get any easier when the addon use a huge amount of eventHandlers, internal scripts etc.  

 :-X Not much to do about it, me think m8  :-\


laterz  

[Killswitch]

The problem is with the config.cpp of those addons, and yes, it's due to a missing and/or improper requiredAddons[] specification.

In the case of the BAS_Kiowapack.pbo, the CfgPatches part of the config.cpp looks like this:

Code: [Select]

class CfgPatches
{
   class BAS_Kiowapack
   {
      units[] = {BAS_KiowaWarrior,BAS_KiowaWarrior1,BAS_KiowaWarrior2,BAS_KiowaWarrior3,BAS_KiowaWarrior4,BAS_KiowaWarrior5,BAS_KiowaWarrior6,BAS_KiowaWarrior7,BAS_TH57};
      weapons[] = {BASOHHellfireLauncher,BASOHHellfireLauncher1,BASOHStingerLauncher,BASOHStingerLauncher1,BASOHXM296,BASOHzuni7,BASOHzun14,BASOHzuniSmoke,BASOHzuniSmoke1,BASOHzuniIllum,BASOHzuniIllum1};
      requiredVersion = 1.90;
      class KioGlowWhite{units[]={KioGlowWhite};};
      class KioGlowRed{units[]={KioGlowRed};};
      class KioGlowFire{units[]={KioGlowFire};};
      class KioSmoke{units[]={KioSmoke};};
   };

};
However, it *should* be like this:

Code: [Select]

class CfgPatches
{
   class BAS_Kiowapack
   {
      units[] = {BAS_KiowaWarrior,BAS_KiowaWarrior1,BAS_KiowaWarrior2,BAS_KiowaWarrior3,BAS_KiowaWarrior4,BAS_KiowaWarrior5,BAS_KiowaWarrior6,BAS_KiowaWarrior7,BAS_TH57};
      weapons[] = {BASOHHellfireLauncher,BASOHHellfireLauncher1,BASOHStingerLauncher,BASOHStingerLauncher1,BASOHXM296,BASOHzuni7,BASOHzun14,BASOHzuniSmoke,BASOHzuniSmoke1,BASOHzuniIllum,BASOHzuniIllum1};
      requiredVersion = 1.90;
      requiredAddons[] = {oh58};
      class KioGlowWhite{units[]={KioGlowWhite};};
      class KioGlowRed{units[]={KioGlowRed};};
      class KioGlowFire{units[]={KioGlowFire};};
      class KioSmoke{units[]={KioSmoke};};
   };

};

Spot the difference?

Answer: requiredAddons[] = {oh58};

Why? Because the BAS Kiowas uses the LaserDesignatorOH, a thingie defined in the BIS oh58.pbo addon

It's easy to miss and hard to remember to check and test for when doing an addon. There are literally tons
of other addons out there that are equally broken.  The 21vbCargo suffers from the same problem.

I fixed my Kiowas a while ago and meant to mail BAS about it... guess I forgot.. D-oh!  

How to fix

[1] Mail the addon author(s) and tell them about the problem. Like I ought to have done...*cough*
[2] Hope that the good ole' BAS boys will notice this thread and do an "official" fix  ;D
[3] Put the offending addon(s) into the base OperationFlashpoint/AddOns folder
[4] Fix it yourself, like I did.

*EDIT: I have done [1] and submitted a bug report on this problem to BAS, so no need to flood them with more emails on the subject