-rageQuit-

You should decide from the outset if your mission is meant to be SP or MP. Fewer functions work in MP, and it requires more care to get scripts, etc to synchronise properly. In SP, all objects should last indefinitely unless they're deleted by the mission maker; that is: nothing should disappear unless it is scripted to do so. It ought to be the same in MP, although there is a known "Ammo Bug" which causes havoc if you try to cram too many weapons in a container. If the dummy unit is putting weapons/ammo down from a script, then you can launch further scripts at that point. 1. Determine the location of the dummy unit and pass that info on to a Finder script. 2. Finder script searches the immediate vicinity to find the nearest "WeaponHolder" - this will be the dropped weapon/ammo. 3. Run a simple timer script on the WeaponHolder to delete it after a while. This would get a bit more complicated if you're using RPGs as they use "SecondaryWeaponHolder"s Somewhat more advanced would be to make an array, each element of which would be a WeaponHolder ID plus the time it was created. Each new element gets added to the end. A housekeeping script runs and removes items from the beginning if there are more than 50 AND if they were created more than a set period of time ago.

How many invisible units do you have? Making how many drops? How are you making the invisible unit drop the ammo/weapon? It is a limitation of the game that you can only pick-up ammo that is configured as an acceptable "Magazine" for one of the weapons the player is holding. I've made a quick-and-dirty test of a MegaWeapon that would allow the player to pickup a disparate range of ammo: ... <snip> ... Further work would be needed: would it be better to make it a child class of "Default"? Possibly, yes is it restricted to weapons that use the same modes of fire? No #define true 1 #define false 0 // type scope #define private 0 #define protected 1 #define public 2 #define WeaponNoSlot 0 // dummy weapons #define WeaponSlotPrimary 1 // primary weapons #define WeaponSlotSecondary 16 // secondary weapons #define WeaponSlotItem 256 // items #define WeaponSlotBinocular 4096 // binocular #define WeaponHardMounted 65536 class CfgPatches { class MegaWeapon { units[] = { }; weapons[] = { MegaWeapon }; requiredVersion = 1.90; }; }; class CfgWeapons { class Default {}; class MegaWeapon: Default { scopeWeapon = 1; scopemagazine = 0; displayName = "MegaWeapon"; valueWeapon=0; weaponType=0; optics=0; canLock=0; enableAttack=0; primary=0; showEmpty=0; canDrop=0; magazines[]={"AK47","AK74","PK","M16","M60"}; }; };

I can't remember precisely, but OFP/CWA is fussy about what can be patched via addon pbos. This might be one of those things; it can be made to work as part of a whole Mod config. True. But I couldn't get TimeToLive to work that way - it seems to be more for ammo and effects. However, since a weaponholder is a vehicle you can add an Init EventHandler to it class WeaponHolder:ReammoBox { scope=1; model="\misc\dummyweapon.p3d"; accuracy=0.2; forceSupply=1; showWeaponCargo=1; transportMaxMagazines=1000000000.0; transportMaxWeapons=1000000000.0; displayName=""; class TransportMagazines { }; class EventHandlers { init="hint ""Weaponholder spawned""; (_this select 0) exec {\<pboname>\delete_me.sqs} "; }; }; Hints are for debugging purposes. delete_me.sqs is pbo'd and the pbo put in your Addons folder: ;delete_me.sqs ~5 hint "Delete Weaponholder script run" ~5 hint format ["%1", _this] ~5 ? (alive _this): deleteVehicle _this If you know which houses they are, find out their ID numbers: in the Mission Editor, activate the "Show ID" button. Then have a slowly looping script, every 12 seconds say, that checks if the player is nearer that 150 metres from one of them. Set a variable flag to true and launch another script for that building only, to do the close up work. When the player moves more than 175 metres away, set the flag to false and the slow loop resumes. This saves have to search through building types and the proximity of all of them to the player. player distance object <object ID number> ...

"!alive _x" count <array name> >= 1 Meaning: the number of units in <array name> who are NOT alive is equal to, or greater than, one. Or else apply a Killed EventHandler to them, but that might be difficult to make work in multi-player.

You can find the targets classname and then run a "find nearest" function (search OFPEC) based on that. It would take ages to search the whole map, but if they were in clusters... Or Option B - via their Init lines 1. Open mission.sqm with a text editor 2. Add the following to one of the first Items in the class Vehicle section of the mission: <arrayname> = [] 3. Run a search for "TargetE" (the classname of the object) 4. Add the following to the Init line in each instance: <arrayname> = <arrayname> + [this] 5. Check it has been applied correctly in the mission editor, and remove it from any targets you don't want included

As far as the LST goes, you can hover behind it in an Mi-17 and empty all your rockets into it - that gets it moving! The more mundane method would be to use setVelocity, but since it's unsteerable any change of course would need to be with setDir in very small increments. It might be easier to create a new config for it, which would be a very small addon. Not sure which submarine you mean - the one in CSLA Mod certainly moves, and I thought Colonel Klink's did also.

I don't think this is not going to work in those circumstances -> Name the target. You should wait for the target to complete its falling over animation (at least two seconds; three would be better for the smoke to clear) before it can return upright.

Do not use group when creating the array because units are removed once their death is noticed ("Oh no, X is down!") Either create it in init.sqs from unit names, or you can write the following in the Init line of a member of the group: <array name> = units this Then the condition is: "!alive _x" count <array name> == <number to be dead>

Go back to Sanctuary's original model and begin the process of removing the goggles again. You probably deleted an important point by accident. How did you select the parts you want removed?

One of the toggles (at the top of the GRAA config) is ENABLE_BURNING_VEH. Search for this and you will see that it adds an EventHandler to class LandVehicle : #ifdef ENABLE_BURNING_VEH class EventHandlers { killed="_this select 0 exec {\sanc_fx\burnn.sqs}"; }; #endif Thus when a vehicle is killed it runs the script burnn.sqs in the pbo in the GRAA Addons folder sanc_fx.pbo. You'd have to open the pbo and edit the script, which uses the Drop command. While it's still available, see Vektorboson's Drop Tutorial at OFPEC. It's not something I understand.

(https://community.bistudio.com/wiki/File:OFP_editor_triggers.jpg) Trigger "Type" is half-way down, on the left. It's a drop-down menu; in the image above it currently reads "None".

Waypoints can't be created - they can be moved or bypassed. That means you have two choices: 1. Waypoints & Switch Trigger Lay out the whole path for the general in waypoints, but at the end add the escape route you want him to take. Make a trigger connected to the waypoint immediately before the escape route, make sure it is of the 'switch' type and will be tripped once the player is detected. When that happens, the general will skip his normal waypoints and go down the escape route. 1.b. Use <general name> allowFleeing 1 - he should run away to his first waypoint, I think. 2. Script everything No waypoints, just a long list of commands, eg. <general name> doMove (getPos) <general's uaz> <general name> assignAsDriver <general's uaz> [<general name>] orderGetIn true <general name> doMove <coordinates> / getMarkerPos "<markername>" / getPos <object eg. Game Logic> unassignVehicle <general name>

Searched for "reinforcements" here or at OFPEC? It turns up threads like this. A simple way, provided you can leave individual units somewhere safe (maybe mark it on the map) is to add the following to their Init line in the editor: this addAction ["Join my group", "join.sqs"] ;Join.sqs _man = _this select 0 _action = _this select 2 _presser = _this select 1 IF (count units _presser >= 9) THEN {hint "You have too many units!"; exit} _man removeaction _action [_man] join _presser _man groupchat format ["%1 reporting for duty, sir.", name _man] exit Change the number after "count units" to whatever you want as a group size (including the player). The maximum number of groups on any side is 63 - so you can have the player's group and 62 individual reinforcements. Advantages: You specify the type of unit; and the player should be able to recognise this and decide if they want them to join his group. Disadvantages: Lots of individual units stuck waiting where-ever, hopefully out of the way of the enemy.

Malden (Abel) and Everon (Eden), certainly. SLX Mod (and for that matter FFUR/SLX '85) contain SLX_Grass_CWC_Islands.pbo which is "Everon and Malden with SLX Grass replacing some bushes and grass". You might be able to depbo this and replace the abel.wrp and eden.wrp in your \Worlds\ folder - needless to say you should back up the originals. Also, copy SLX_Grass.pbo into your \Addons\ folder. Hopefully that's all that is required.

Beaten by Zulu1 ... ... but anyway: Put http://ofpc.de/berghoff/files/addons/naturepacks/* into the Wayback Internet Archive (www.archive.org) - the wildcard (*) at the end is so that it lists files should get you to this sort of page choose the file you wanted and it might get you to a page like this - the download from June 13th, 2006 seems to be working = 13.3 Mb

Assuming this is for single-player, name the helicopter (eg. choppy). Condition for player's group being aboard: "alive _x" count (units player + [driver choppy] + [gunner choppy]) == "alive _x" count (crew choppy) Condition for player's group having disembarked: "_x in choppy && alive _x" count (units player) == 0 Put the second condition in the waypoint where the team get out, and also put a handful of seconds in the "Timeout" boxes. The heli will stay at the waypoint until the team are out of the doors and the time has elapsed - that is, it will wait until they have roped down to the ground.

player setDammage -1 will cause the player's aim to waver, but also returns the getDammage value to 0.

How about a grave, with the weapons on top of it or laying alongside (like in some missions in which you take weapons from a table)? If that's what you meant you should use weaponholder's. These need care as they're createVehicle'd and you don't want multiple instances to be spawned. There is a ten-year old script for this here on the forums, but I'm afraid the change in forum formatting has not left it very legible. Update: this should be cleared up (just needed pasting in here, and the formatting cured itself)

@ ChumySL MapFact's massive weapon pack, but still without grenade launchers: info page, download from GamePark.

Can the corpses of players perform actions? If so, then Action "Drop Weapon" could be used to move across a weapon and its magazines (including any that are half empty). Along the lines of: _player action ["DROP WEAPON",_playertombstone,1,1,(primaryWeapon _player)] However, I think Lenyoga is correct in suggesting the way to proceed is to generate arrays: firstly, of weapons - loop through them checking they are not <null> and move them across. Then of any magazines that have been missed.

I've had a chance to test what I wrote and there are a few boo-boos. I believe I've got it working now, with no need for you to make arrays of units that start outside vehicles or delay moveIn... commands. Everything else I wrote before should be correct, except combat_talk_init.sqs _unit = _this select 0 if (typeOf _unit != "Man") then {{[_x] exec "fx\voice\combat_talking.sqs"} forEach crew _unit} else {[_unit] exec "fx\voice\combat_talking.sqs"}

You don't need long scripts with lots of If-Then's and Goto's to make a good mission, but familiarity with the commands (as linked by Zulu1 and Luki_M2K) mean you can make more interesting missions. They may look complicated at first but dialogue and camera controlling scripts (for intros and cut-scenes) are done in order - one thing after another - and it can be easier to make sense of (since it's one file) than a whole lot of triggers. Update: have a look at Khartak's Mission Editing Guide, rather than just a list of commands it gives them friendly titles (at least according to the screenshot). There was a longer (approx 15Mb pdf) complete editing guide, but I can't recall who made it.

Use the code snippet from ProfTournesol in an intermediate script (and also in your talking script). (NB. I haven't checked the following in-game) In the trigger: {[_x] exec "fx\voice\combat_talk_init.sqs"} forEach thislist combat_talk_init.sqs _unit = _this select 0 if (vehicle _unit != _unit) then {{[_x] exec "fx\voice\combat_talking.sqs"} forEach crew _unit} else {_unit exec "fx\voice\combat_talking.sqs"} finally, in combat_talking.sqs if (vehicle _unit == _unit) then {_unit say (_v select _re)}

I can't remember all the implications on vehicles, but you could removeMagazine the Armour-Piercing ammunition from your tanks. Then they'd be forced to use High Explosive, and hopefully get fewer one-shot kills.

The game engine doesn't make use of the ...Base definitions, but rather the ViewOptics, ViewPilot, etc that are derived from them. Hence if you add class ViewPilot:ViewPilotBase {}; class ViewGunner:ViewGunnerBase{}; etc. after where you've changed the ...Base, that ought to work. For instance, I've just tried the following added to the main config after M60 tank class Test_M60:M60 { displayName="No-Zoom M60"; class ViewOptics:ViewOpticsBase // from Tank class { initFov=0.3; // minFov=0.07; // maxFov=0.35; minFov=0.3; maxFov=0.3; }; }; That prevents zooming in or out ONLY when viewing through a position's optics. It seemingly applies to all positions: driver, gunner and commander. You can still zoom in/out when in normal first-person view (when you can also turn your head with the numpad).