Firstly, which version of OFP are you using?
1. As you have done, open
mission.sqm with a text editor and delete all the listed Addons.
2. Remove all addons that you do not wish to use in your mission from <OFP>\Addons (use
Modfolders or see
Hawkins' Tutorial)
3. Start OFP and go to the Mission Editor. Load your mission.
4. Preview and then Save the mission. The Addon list should be correctly updated.
Here's a copy of the relevant post by Killswitch, but it is of more use to addon-makers rather than mission authors:
Quote from: Killswitch on 22 Dec 2005, 00:04:40Broken addonsThere is a persistent and annoying missing addon bas_repairh. This is nonsense and is a scripting failure, the name of the pbo is bas_repair the name of the addon is bas_repairH
This is not a "scripting failure". It is a configuration error within the addon BAS_repair.pbo. Like far too many addons out there, this one doesn't properly declare the addons it depends on. The funny part is that none of the missions use anything from this addon, yet it causes trouble anyhow. The reason? Some of the campaign missions feature a BIS Apache (AH64)...
I'll explain. The BIS Apache is an addon. The addon BAS_repair.pbo depends on this addon since it defines a new vehicle class - a descendant of the
AH64 class. Since the addon doesn't properly declare this fact, you get that symptom - "Cannot load mission - missing addon bas_repair".
If you load OFP with that addon, you will get this error message in
all missions that have a BIS Apache in it.
The solution is to fix the BAS_repair.pbo addon. Open it up and make sure the CfgPatches part of it reads
class CfgPatches
{
class BAS_repairH
{
units[] = {bas_repairHW,bas_repairHE,bas_repairHR,bas_cobra_a,bas_ah64_a,bas_mi24_a,bas_mi17_a};
weapons[] = {};
requiredVersion = 1.90;
requiredAddons[] = {"AH64"};
};
};
Take note of how it now
properly declares its addon dependencies. That will take care of the problems with BAS_repair.pbo for you and you can concentrate on playing missions instead.
Again: this error is not Marvin's fault. It's lacking BIS documentation and the resulting less-than-stellar configs that are so common out there...