kronzky

Your first method looks correct, as far as the syntax is concerned, but I think the only problem is that the variable tName you're putting into the argument of the script call (the <span style='color:blue'>nil = [%1] execVM 'IL_Scripts\ScriptName.sqf'</span>) is probably just a number, whereas the name of the trigger is TRG, plus a number (i.e. TRG1, TRG2, ...). So, if you change your statement code to <span style='color:blue'>nil = [TRG%1] execVM 'IL_Scripts\ScriptName.sqf'</span> it should probably work. I tried the code below, and that put out a different number for each trigger I enter:<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">for "_i" from 1 to 3 do { tName=str(_i); tPosX=getPos player select 0; tPosY=(getPos player select 1)+50*_i; tSize=20; call compile format ["TRG%1 = Â createTrigger ['EmptyDetector', [tPosX,tPosY]]",tName]; call compile format ["TRG%1 setTriggerArea[(tSize),(tSize),0,true]",tName]; call compile format ["TRG%1 setTriggerActivation['WEST','PRESENT',true]",tName]; call compile format ["TRG%1 setTriggerStatements['this','hint str(%1)', '']",tName]; };

Here's a module that lets you create any type of mine field with one call to the script. You designate the active area via a rectangular marker, and then that area will fill be filled randomly with the types of mines you need. • The mines can be specific to certain classes. (e.g. only anti-personnel, or only anti-tank; or cover a range of classes, e.g. any vehicle.) • You can define the explosion strength and the activation radius. • How much of the mines is visible is up to you (they can also be totally hidden). • By default the mine field will be filled with an amount dependent on the size, but you can also specify a fixed number of mines to use. • Qualified classes (engineers & special forces) are able to disarm them via the normal ArmA interface. • If the mine field is too dense (i.e. where mines end up with an overlapping activation radius) they may trigger each other when detonating, leading to a chain reaction. • You can also opt to automatically create warning signs at the edges of the mine field (in this case the mines are indicated by road cones for demonstration purposes). Available at my site.

Another quick way to find out the class name of a placable object is to put this into its init line: <span style='color:blue'>hint typeof this</span>

Closed per request of topic starter (continued on release thread).

Well, it'd require some work, but I don't see any major hurdles. You'd have to separate the different scripts a bit - starting some only on the server, and others on each individual player's machine. Object creation, movement and regeneration should be pretty straightforward - just run that main script on the server exclusively. Weapon selection is a separate script, and the action for it would have to be added to each individual player's init file. Implementing bullet cam and ballistic info would be a bit more involved, but since you're talking MP, I somewhat suspect that that's not really what you're after. Hopefully... Not sure how you would want to go about changing the target distance  (if at all). But that's not so much a technical issue as a game-play one (i.e. who is allowed to change it, or should it change by itself, depending on certain conditions).

You can't enter an absolute speed directly, but each speed step is roughly 0.5 m/sec So a speed value of 5 would end up being 2.5 m/sec, and a speed of 10 would be 5 m/sec.

I figured while I was working on this already, I may as well do a major overhaul - so now we're at version 2.0! Here's what's new: [*] More user friendly parameter entry: Instead of having a row of mystery parameters (e.g. [50,500,100,["target"],5,10] ...), each parameter can now be entered at any position, along with its label (e.g. [["target], "min:50", "max:500", "step:50","speed:5","move:10"] works just as well as [["target], "speed:5", "move:10", "step:50", "max:500", "min:50"]). [*] You can now define targets by placing them on the map, and referring to them in the script call. So for those who never liked very much having to dig through the cfgVehicles class, to find the object they're looking for, you can now just place the object you want somewhere on the map, and that item (as well as any others you might have created) will then be used for the target lineup. You can still use class names (or even mix and match), but this is an additional option. [*] Moving targets can be stopped and restarted from inside the mission (via the radio menu). [*] When selecting a weapon via the action menu, you will be equipped with all compatible ammo types. There are a few other minor tweaks, but these are the major changes. Available here.

Every single unit is one group. Every *group* is also one group. Surprising, isn't it... So if you want more than 144 units in the map, create groups with more than one member.

Of course! That's what they're for - to be used...

The first link goes to the string library itself, but you don't need to download that separately, as everything is included already in the demo mission.

Actually, with the newly expanded String Library it's fairly straightforward to do. You first convert the object array that nearestObjects returns into an array of strings, and then you use the function KRON_getArgRev to find any occurrences of the types of trees you're looking for. Unfortunately you will have to assemble the list of tree names yourself - there is no automated way of determining what is a tree and what isn't. But luckily the names are somewhat self-explanatory. Here's an example that lists any of the three palm trees within a 20 meter radius. I'm sure you'll be able to tweak it to your specific needs.<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">nul=[] execVM "KRON_STRINGS.sqf"; // load the string library _radius=20; // how far you want to look for trees _trees=[" palm_01.p3d"," palm_02.p3d"," palm_03.p3d"]; // the names of trees while {true} do {  _objlist = nearestObjects [player,[],_radius]; // get every object within the specified radius  _strlist = []; {_strlist = _strlist + [str(_x)]}forEach _objlist; // convert those array elements into strings  // check for every type of tree  {   _fnd=[_strlist,_x] call KRON_getArgRev; // does the element contain the tree name?   if (_fnd!="") then { // if it does, the object id is returned as a string    _objId=parseNumber(_fnd); // convert it to a number    _obj=position player nearestObject _objId; // and get the proper object    player sidechat format["%1 found as object# %2 (%3)",_x,_objId,getPos _obj]; // show off what we found;)    };  }forEach _trees;  sleep 1; }; You can also download a demo mission from here.

Now with moving targets! Speed and distance can be configured. <OBJECT CLASSID="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" WIDTH=400 HEIGHT=326><PARAM NAME=MOVIE VALUE=http://video.google.com/googleplayer.swf?docId=-6330398047571047597&hl=en><PARAM NAME=PLAY VALUE=TRUE><PARAM NAME=LOOP VALUE=TRUE><PARAM NAME=QUALITY VALUE=HIGH><EMBED SRC=http://video.google.com/googleplayer.swf?docId=-6330398047571047597&hl=en WIDTH=400 HEIGHT=326 PLAY=TRUE LOOP=TRUE QUALITY=HIGH></EMBED></OBJECT>

If you keep the range down fairly low, you shouldn't have a problem. But some people had nearObjects commands that covered the whole island. That *will* screw up things...

I'm afraid you're out of luck, DMarkwick. this in a trigger refers to its condition (either true or false), and not the trigger object. And any of the nearestObject* commands only detect stuff from the cfgVehicles class (which doesn't contain the triggers). So while there might be ways of automating your tasks (you could place a Game Logic, and have that create a trigger, which then refers to the GL, etc.), I think just doing some manual editing will probably be faster...

Not quite sure which tower you're referrring to (if it's "Radar"/"Land_radar", then the model is "\ca\buildings\vysilac_FM2"), but the easiest way to find a model name for an object is to place it on the map, and then put this into its init line: hint getText (configFile >> "cfgVehicles" >> Â typeOf this >> "model")

Theoretically your code should work, but even though a group leader may be dead, it normally takes quite a while until he's removed from the game, and not considered a group leader anymore. That's probably why your new leader assignment doesn't work. Once you determine that the current leader is dead you should probably do a waitUntil the unit is actually gone, to circumvent this problem. e.g. Â waitUntil {isNull _civleader} or waitUntil {leader civgrp!=_civleader}

set is what you need: ExemptTownsArray set [3,1]

There's also a semicolon missing in the first line: useCamera = true

Assuming your unit is actually called "general", then the condition syntax would be: !(alive general)

If I understood your goal properly this might work:: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">{   _trigger=_x    {     _vehicle=_x;     {       _vehlist = _x;       if ((typeOf _vehicle) in _vehlist) then {         nul = [_vehicle,_vehlist,90,false] execVM "scripts\ammo_burn.sqf";       };     }forEach [_support,_light_armor,_heavy_armor];   }forEach list _trigger; }forEach _area+_enemy_towns; The outer loop goes though all the triggers (in _area & _enemy_towns), the next loop takes each unit that is in each trigger area (list _trigger), and then we go through the three vehicle groups. If the vehicle tested is in one of the groups, it then calls the script. Your original script didn't actually hand over the vehicle itself (only the class array). I don't know what happens in that script, but whatever it is, I would assume that it would need the *object* that it should do something with, so I've added that now as the first argument (_vehicle). Good luck! You may need it...

crew is what you need.

The animations ActsPercMstpSnonWnonDnon_MarianQ_shot1, ~2, ~3 will let her use the microphone (no special "weapon" needed). So - if you put a Game Logic where you want her, and then put the following code into the initialization line, you should get the correct animation: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">mq="MarianQuandt" createVehicle (getPos this); mq switchMove "ActsPercMstpSnonWnonDnon_MarianQ_shot1"

Hah! I recently wrote *exactly* this kind of mission (to do a stress test for my Urban Patrol Script). Never though anybody else would have interest in something like this, but I guess you never know... It has two sides fighting endlessly, with automatic patrolling of the designated area, and instant respawns. It even comes with a camera option to automatically follow the action. It's like "ArmA TV"... You have to run it from the editor, and you can get it from here.

All you need is ctrlPosition & ctrlCommit. You may just have a typo in there, or a wrong control ID. Check out my Object Browser, where the main menu can be hidden via a button. It's pretty straightforward:

Actually the "named" flag doesn't get a parameter. It just tells the script that this unit has a named assigned to it (in the editor), so you can then use a global variable that contains that name to externally influence the script. It's one of the more advanced features, but I'll try to explain (it *is* in the readme, though, at the bottom section, where I talk about GLOBAL VARIABLES). By default there is one global variable per side (e.g. KRON_UPS_WEST) that you can change from the outside to stop any patrolling by units of that side (by setting it to 0). (The included demo mission "ups-dynamic" demonstrates that.) If the lead unit is named (e.g. "w1"), and you have told UPS about this via the "named" flag, you can then use the variable KRON_UPS_W1 to stop *only* this particular unit. NOW - since I'm here already I may as well announce that UPS2 is coming soon! It doesn't have any "breakthrough" additions (since the current one seems to work quite well), but it makes usage even easier, and has a few new features: [*] You don't need to initialize it anymore via the "init" call [*] You don't need a "server" Game Logic anymoe [*] You can have a unit stationary at their current location, and only start moving once they spot an enemy [*] You can restrict the pursuit movement to only the patrol area (right now they would follow enemies outside). [*] You can specify how many unit can be left to consider a sector cleared (it doesn't have to be totally empty anymore). [*] Dead units can be removed after a specified time. For those adventurous souls who would like to try the first beta already, you can download it from here. It doesn't contain any readme yet, but the new parameters follow the regular UPS standard, and are briefly described in the header comment. Email me directly if you run into any problems.