-rageQuit-

What tool are you using to unpack the campaign pbo? It is not strictly necessary to repack the campaign as a pbo in order to play it (as long as you move the original .pbo somewhere out of the way, or rename it as a back-up).

Which vehicle is this related to? And what, specifically, do you mean by regulate?

The Weapon Pool is stored on your hard-disk along with your campaign progress. Scripts are used at the end of missions to collect up your unit's weapons; and at the start to redistribute them. The script that is automatically run before the briefing screen is init.sqs and this is where you should use commands like addWeaponPool. For instance the init.sqs for 11CounterAttack.Noe has this at the end: AddMagazinePool ["RPGLauncher", 6]; AddWeaponPool ["RPGLauncher", 1];

Yes.

It just goes to show how good an idea OFPEC tags were, so you'd know who made the addon. The M136at4 reminds me of Lowlands Warrior, but they might have used the LLW_ tag for it. (Actually, it looks like they used the kmm tag). Try Frandsen's marines first, though. Update: the download link for Frandsen's marines is well broken on that page, use this one instead. Here is an updated ToW M249 pack as well.

I'm not sure if it's what you meant, but you can change the Graphical User Interface (GUI) - see the Project Warchamber tutorial. There are a couple at GamePark that people have done already, for instance BAS for the technically minded, or SJB for those less so.

The animations that play behind the main menu are in \Res\DTA\anims.pbo - on first starting OFP you should be on Desert island (Intro.Intro). After finishing a mission on the other default islands you get the appropriate animation: intro.Abel, intro.Eden, intro.Cain or intro.Noe The music ought to be random (on Desert it picks from four choices). That music is defined in the main config under CfgMusic.

No serious problems: needed an extra pair of parenthesis around the sin / cos terms and increasing the minimum distance from the truck - you may think you spawn it 5 metres away but that not how the game sees it, for some reason To start, addAction Deploy.sqs in the truck's init string. _mgun = "M2StaticMG" createvehicle [((getpos _truck select 0)-((sin (getdir _truck))*5)), ((getpos _truck select 1)-((cos (getdir _truck))*5)), 1.05] ?_truck distance _mgun > 7.5: goto "PackUp" ?_truck distance _mgun > 7.5: _mgun removeaction _load; goto "PackUp"

Be careful about the names you give units. The most likely reason for the error is that enemy is reserved for a command. Change it, as per Nikiller's suggestion.

Beta 2 of OleMissRebel's Arabia (as linked by RuN) is at FileFront (53.3 Mb). A comparison of the PBO dates shows it to be 5 days newer, but it also depends on a lot more addons (see filesize above). Pages in this forum.

There's a link to Afghan Objects (4Mb) on this page at GamePark. I'm not sure which grass it might be - does the readme give any hint about the author?

Don't use the picture attribute for changing the equipment images for default BIS equipment (ie. pre-Resistance stuff). These used one classname for the ammo and weapon config, as opposed to Resistance where you get UziBase, UziMag and Uzi - and then they could use more than one picture. The images for pre-Resistance stuff is in Res\Dta\dtaext.pbo and the game understands the relationships between images for weapons and those for magazines. Simply unpack this folder, change your images and re-PBO.

Is it this: http://www.armamdb.de/phpkit/include.php?path=content/download.php&contentid=587&PHPKITSID=2e211e6b3714c6e154057eb679315e86 ?

You define the model attribute twice in class G36aBase

Well, at the bottom of the page you linked to it says: "IMPORTANT: Needed Operation Frenchpoint Addons !" It's probable that they kept the interior textures from the basic Operation Frenchpoint Mod and just made new ones for the exterior. Look inside the addon with Pbo Explorer. Also you can try opening the model .p3d with TxtPathSwap (if it's in MLOD format) and seeing if it lists textures in an addon that you haven't got.

Presumably you're referring to singleplayer. Most crudely, you could just use setDammage 0 which brings units back to life with whatever equipment they had as a corpse. Fancier scripts have the units laid out in the mission editor, and then use deleteVehicle at the start of the mission. This saves processor cycles but the groupnames, waypoints etc. are preserved. When they're needed, the units are createUnit'd. Kronsky's UPS page is here, including a version for OFP.

You can try opening such files with a web browser. It makes it easier to try different encodings to see if you can decipher it (typically found under View -> Encodings).

Change the texture to data\clear_empty.paa - this is transparent and so wouldn't give you the missing texture whiteness. If the model is in MLOD format use Texture Path Swap. When you open the model, it gives a list of the textures used. Scroll through until you find the relevant texture, double-click on it so that it's entered in the "Find what:" box, then type in the replacement and click replace. Finally save the new model. If it's ODOL, you can use a text editor that handles hexadecimal - I use NotePad Plus, since it doesn't need to be installed and can run as a stand-alone program. Simply do a find-and-replace as above. There are other texture swapping utilities that can manage ODOL, but they're not as friendly as TxtPathSwap.

It is the scope attribute that determines how visible things are in the mission editor. If you want to go through with it you'll have a lot of text editing to do. 1. You could open every addon, copy the CfgModels (and CfgMaterials) section to your own mod Config, rename (to make inoperative) the addon's config and repack it. This would be most efficient on resources, but you wouldn't be able to play with your mod and the addon. 2. Or else open every addon and edit its config (having made a backup) to change "scope = public;" into "scope=protected;". 2 becomes 1, in other words. You'd be able to play missions that use the addon, but not edit them. 3. Most elegant would be to make yet another modfolder with an AddOns folder within it. Create you own addon (the name is unimportant) by merging all other addon configs into it - just the CfgVehicles sections and erase everything except the classnames and their scope attribute. Change the value as per 2. Ensure this mod is loaded last by adding it to the end of your shortcut that runs OFP. Since the addons themselves aren't modified, they'll revert to normal behaviour when you don't run the mod.

It would involve editing the model itself. The old proxies would need to be removed, and their replacements added and positioned. The difficulty comes from there being many stages, rather than from any individual step, particularly if you've not done any editing before.

Lets go through it line by line. transportSoldier This is increased from 2 to 3, meaning one more person can be carried. Not really a problem as all the units that start a mission aboard can still fit in. cargoIsCoDriver Can't remember what this does, if anything - but BIS considers anyone who sits upfront with the driver (shotgun!) to be a co-driver. 1 is true; 0 false for the same array of cargoAction. driverAction The driver has the posture of a Skoda driver rather than a UAZ driver. The angles of the torso and joints may be slightly different, but at least the proxy sits correctly on his seat. Not a problem. cargoAction This is where most changes are. This, in addition to cargoIsCoDriver, mean that the first passenger sits alongside the driver rather than lying in a stretcher (ManActM113Injured). Also "ManActawmvwbusambcargo" is not one of BIS' = ManAct AirWolf Mod VW Bus Ambulance Cargo, so I'd remove that whole cargo proxy. transportSoldier=2; cargoIsCoDriver[]={1,0}; driverAction="ManActSkodaDriver"; cargoAction[]={"ManActSkodaCoDriver","ManActSkodaCoDriverBack"};

Airwolf's vehicle probably uses different proxies for the the driver and co-driver. Proxies, being 3d models, also have x, y and z coordinates - they're not all centred. The relevant parts of the config are: class UAZG:Car { driverAction="ManActUAZDriver"; cargoAction[]={"ManActUazCoDriver","ManActCargo"}; }; class SGUAZG:UAZG { cargoAction[]={"ManActM113Injured","ManActCargo"}; }; As you can see SGUAZG inherits from UAZG, the cargoAction line superceding that from the parent. Check what's in the VW van config - you'll need to copy its driverAction and cargoAction. It's a lot more trouble if they created their own proxies rather than using one of BIS' originals.

1. It is not necessary so long as you have the addon active - ie. while starting up, the game has been able to read the addon's CfgModels in the addons config. 2. As suggested by Zulu1, you can keep your youthful hair attached to your head if you avoid units which require facestex2. How about improved RHS Motorized Infantry (Reskinned by ShadowNX) as the OPFOR? 3. If you're using ECP, you don't need to add an EventHandler for the bd_grenadepack 4. Does this problem cure itself if you wait for several seconds, or turn away and look again? There are two options, and they depend on how committed you are to changing to facestex2: If you are prepared to change every human model in the game and not play with any addon that introduces new models: Edit the CfgFaces section of your config to point at facestex2 textures instead, and also CfgFaceWounds while you're at it. Then you wouldn't need any scripts at all. You want to change models for a specific side, and are prepared to not use any addons with new models for that side: There's a section in the config where "class Soldiers" are defined for each "class <Side>". Change the face=... line for each soldier on that side. None of the above: Write better scripts than in facestex2. These would start by checking if the unit is in a vehicle, and might also check the config name of the unit to be certain that the script should run on it.