Inkompetent

No. You don't need to create one. Just that if you use a custom profile to play, rather than the default one, you'll have a My Documents\ArmA 2 other profiles\ directory. Otherwise you can shorten the path to My Documents\ArmA 2\missions (if the folder should be in the missions folder, rather than just in the profile folder at the same level as the missions and mpmissions folders. Haven't tried, and the posts in this thread aren't really conclusive on the matter)

player is a magic variable. It automatically refers to the local player object (or at least SHOULD refer to the local player object. The chance that it might sometimes be slow to be defined is a possible issue here, judging from Galzohar's stuff. However, since it is a by the game engine automatically defined variable you never need to (and never should) assign a value to it yourself. In some scripts you see waitUntil {!isNil "player"}; and waitUntil {player == player}; which are two stages of verifying that the variable has been initialized and defined. If Galzohar and Xeno are right though, it seems that there could be the tiniest of delay between the variable being assigned, and the client getting 'ownership' of the player character, so that the player variable is properly initialized, but the character is still not in the player's control for some microseconds yet.

The downside with my code is that it in no way tracks an individual unit's presence. It simply damages anyone that happens to be in the zone, 1-10 seconds after the first person enters the zone. So it is quite unreliable in that manner. To make it track individuals you'd rather need a script that instantly upon entering it fires a script for the new individual, and that script tracks the person's presence in the 'danger zone' and wounds him if he's in there for too long, which is easier said than done.

Hmm... How about doing a setVariable on the unit itself in its init line, and the script waiting for said setVariable to become defined/a certain value? Does that take a long enough time to happen to get the desired results?

To damage anyone in the trigger area, set the following in the On Activation field: {_x setDamage X} forEach thisList; where X is how much damage you want to do. thisList is an arraying containing all (by trigger setting eligible to activate?) units in the trigger area. I don't really know why the timeout doesn't work though. Tried setting Min=1, Mid=5.5 and Max=10, and the timer method to Timeout?

In the init-line of each soldier you want to put into the boat, just add this moveInCargo nameOfBoat; and they'll teleport into a cargo slot of the boat at mission start.

The helicopter itself isn't local to the script. It exists globally. However the variable _vcl_new that is a reference to the helicopter object is local only in the scope it was created, in this case the main scope (and all lower level scopes) of the script. A moment though and I'll test so that I got my waitUntil check right. Edit: Okay, I tested in the editor noticed my syntax was at fault. The waitUntil should look like: waitUntil {(count units sfg1 == {_x in crew _vcl_new} count units sfg1) && (count units sfg2 == {_x in crew _vcl_new} count units sfg2)};

You can't write a waitUntil {test1} && {test2}; line of code. You can't compare two lines of code to eachother. Just the boolean result of said code. It should be written as waitUntil {(test1) && (test2)}; Try with that first. :)

waitUntil {count units sfg1 == count units sfg1 in crew heliName}; should work I think. Although I'd recommend a slower looping while-loop or something for such a check if it will be running during any longer time during the mission, since it is fairly resource-taxing with such a complex check with the frequency of a waitUntil check.

Exactly same principle as above. Just got to experiment with the height. One thing I've done is to make a trigger, set it to repeatable and 'radio alpha', and put hint format ["%1", getPosATL player select 2]; in the On Activation field. That way I can check the height for a specific position when running around in-game by simply pressing 0-0-1.

Actually, you can even have a completely blank briefing.html file if you want to. As long as the file is present it is enough.

A Hold waypoint can only be broken by a switch-trigger syncronized to the waypoint, unless you want to start messing with deleting and adding waypoints during runtime.

Well, you can pre-compile scripts with compile preprocessFile and compile preprocessFileLineNumbers (for example like fTaskHint = compile preprocessFileLineNumbers "scripts\tasks\fTaskHint.sqf"; ), which you then can run with call or spawn depending on use. However BIS_fnc_spawnGroup is already compiled, and you can't really hurry up the process more in that regard. You could however pre-make and cache the waypoints you want to assign to them, or just slowly add the waypoints one by one with sleeps in between. Anything to let the server focus its CPU cycles on creating the units and broadcasting their existance. Best suggestion really is.. well.. make the mission less busy. Be it through slower cycling scripts, less resource-heavy stuff that'll do almost the same as before, hopefully with just a marginally noticable difference (especially when it comes to AI a lot can often be achieved with very little, simply by... suspension of disbelief), less triggers (important one!), or what more you can think of for your mission specifically.

MOPP suits looks lovely! However I must say that the shadow and highlight contrast on the journalist was beyond passable. Maybe that in a certain kind of lighting would show up like that, but in the lighting in the picture it looks *completely* off =/

Unfortunately this also causes a crap-ton of other nauseating post-processing like... blurring everything as soon as you move, move the camera, or pretty much do anything at all, making the eyes hurt just from watching the screen :(

Sort'a depends. For a perimeter patrol of a base, or a street patrol where being visible is more important than covering ground, then the speed is fully reasonable. For marching or long patrols though I agree that the speed doesn't cut it.

There's only 'safe' walk, 'high ready' walk, jog, and sprint in the game as far as standing movement goes I'm afraid. Personally I like the slow, relaxed walk though. It wouldn't really feel natural if it was much faster, unless it is to be a forced march.

Well, if it is to be sold on DVD, which it is, it has to be 'finished' some weeks before June 29th for the code to be sent to the DVD printers, get manuals and packaging printed and done, and shipped to stores. ;)

The ballistics and MIL-dots (mostly ballistics though) in vanilla ArmA2 are off. There are however mods for that though like FNC Ballistics, FNC Scopes, GMJ Sight Adjustment, and some more. Something to look at if you don't want to use full ACE2 when playing, but want proper sniping to work.

But that was pure PvP with no AI?

A COOP mission with 100 players is, to my knowledge, unlikely to work well unless only a small portion (50-100) AI is present at a time, and even then it'd be a challenge to keep the game syncronized and non-stuttering across the board. For PvP it does work, but there's a great risk of desync problems and lagging/non-responsive AI with the incredible stress on the server to constantly update 100 people with the position and action data of 200-300 units.

Ahh, well. The class name of the helicopter definitely should be tagged, since we never know how many people will want to make Ka-50s. For exmple rstr_ka50 (OFPEC-tags are limited to 4 characters I think to keep class name length down). Not the best of practices to change the class name after release, but if it causes such compatability problems there isn't much choice.

Now that's some awesome footage! Looking really well done!

That's the problem with so many servers running more or less unmodified versions of Domination, since the mission per default is VERY friendly to lone wolfing, and there's almost no punishment what so ever for dying. Teamwork ends up being limited to the pilots that fly people to the front. It's the most casual-friendly mission made for ArmA I think. It *can* be very good if played properly, but good luck finding it properly played on an unadmined public server.

Simply put: As in every single existing game public servers have the same level of teamwork as lemmings have sense of self preservation. If you want to play ANY game and enjoy actual teamplay, join a community/clan/squad/whatever that suits your preferences.