geqqo

What exactly do the related parts in the files look like now (for example for the house track again)? Also, nothing related in the rpt?

Ahhh. There's the key to solution (banging my head) :D I specifically made it play only for people in the heli absolutely disregarding the possibility that you would want others (outside) as well to be able to hear it (which of course makes sense, with the say3d and all...). So the solution is to just remove the if (_thisheli == vehicle player) check altogether in the proposed House.sqf (so it plays for all players, but only from the specific heli, where triggered from) - (missionNamespace getVariable (_this select 0)) say3d "house"; hint "Radiowave 'House of the Rising Sun' taken"; sleep 248; hint "Radiowave 'House of the Rising Sun' open"; playhouse = ""; Also, if you do not want to have the action removed from players for some reason but don't want the specific* track to trigger when chosen, then in playhouse.sqf (as per my solution), add an if check as follows - *(disabling all would be done similarly but using a global variable like explained further below but applied to the context of this particular example; see the comment in the code) if(playhouse == "")then{//if(!musicactive)then{ playhouse = _this select 3; ... }; Or... If you do want to have the action (only the particular one) hide itself then the previously suggested "playhouse != """" && driver _target == _this" would still be the way to do it (with the appropriate variable for each case). (else) If you want to have all the actions hidden in case of any tune played then a global variable would do the trick. E.g. - Action's condition - "(!musicactive) && driver _target == _this" To init.sqf - musicactive = false; To House.sqf (and all other serving the same purpose) - Before the sleep: musicactive = true; After the sleep: musicactive = false; What surprises me though, is that you could not repeatedly trigger the track with your solution (using 0/1 for the variable, etc.) since there really don't seem to be any measures against that it in the shown pieces of code. (You may want to read the last sentence of this "chapter" before the contents ;) ) What's started to bug me, is a theoretical "edge-case" of someone being able to potentially execute the action after somebody else has already just done that, but the option was still available to the first party due to delay. If you only ever intend the music options to be available to the driver then that solves it in itself (since there's no "second party") but otherwise a "synchronization" with the server might be required (e.g. instead of publicVariable, the client would run publicVariableServer and then the server-end handler would check if the variable was already set and only run publicVariable if not (however it wouldn't be that straightforward, as publicVariableServer (like publicVariable) changes the variable directly, so you would need to keep a "backup" variable or approach a bit different and send a variable name/value-pair (an array) to a dedicated variable and so forth)). I may be overthinking this and maybe there's some counter-mechanism for that on the game's end, so you may disregard this unless you get cases of people actually doing something like that.

I intended to test this myself but I cannot seem to connect two clients to a dedicated server on the same computer (with kickduplicate=0; and reportingIP="<>";). Anyway, does the rpt say anything? (if you have tested multiple clients on your computer, and thus have access to the rpt of the client that should play the sound but doesn't) If you want to hide it also for the driver (as it currently seems to display only for the driver), you could check like this - "playhouse != """" && driver _target == _this" That is, if you're using the suggested code; or if you're using the number approach, then you would use playhouse == 0 && ... As for showing again while the song is playing, you could just shorten the sleep. Or if you want to show it in case a condition is met, you could use a global variable that you set true at the appropriate time, for either all tracks or per each track (i.e. "houseavailable && driver _target == _this").

Here's one way I can figure this could be done - I'm thinking of making playhouse (and any other such music play-state variable) hold the particular heli's name instead of a number. Note, that any one tune could be played only from one heli at a time like this though (i.e. once the house tune is played from heli 1, it couldn't be played from other helis, however other tunes still could be, if you are still using multiple tunes). If you're running the first code fragment that you posted in each vehicle's init, as it would seem, then you could go like this: this addaction ["House of the Rising Sun", "Variables\playhouse.sqf", "h0", 0, false, true, "", "driver _target == _this"]; Note the "h0" (arguments parameter) after the script parameter, that string will be available in playhouse.sqf as _this select 3. It stands for the heli object (use the particular heli's name in the init line of each; in this example I expect them to be h0,h1,...). In playhouse.sqf change playhouse = 1; into playhouse = _this select 3;. In init.sqf code, change the playhouse = 0; into playhouse = "";. Finally, in House.sqf (I believe the previously present while do loop and the if(true) checks to be unnecessary, if you know otherwise, feel free to reintroduce them) - _thisheli = (missionNamespace getVariable (_this select 0)); if (_thisheli == vehicle player) then { _thisheli say3d "house"; hint "Radiowave 'House of the Rising Sun' taken"; sleep 248; hint "Radiowave 'House of the Rising Sun' open"; playhouse = ""; }; References - getVariable, setVariable, missionNamespace.

If you look in the sample mission's init.sqf, line 31 (layed out here) ... _heli addAction [ (getArray (missionConfigFile >> "CfgSounds" >> _x >> "titles")) select 1, "musicAction.sqf", [_i,_x], 0, false, true, "", "!musicActive" ]; ... - I've used a global variable in the last parameter of addAction (condition; it checks whether the provided expression (in a string) is true, if so the action is shown, if not, it's not). The variable is initially set false (so the actions are shown, because I negate the value in the condition string with the ! operator) and I set it true (in musicActions.sqf in the mission) when playing any sound, so they're automatically hidden (the condition is constantly checked by the game). Since I'm using the same single variable for all addAction condition checks, it disables/enables all of them at the same time. As far as multiplayer goes, I'm afaid my level of expertise is low in that "realm" but essentially, you would probaly need to use publicVariable (or publicVariableServer and publicVariableClient) and possibly also addPublicVariableEventHandler (not mandatory as publicVariable sets the variable for all other players automatically). I.e. whoever activates the action does publicVariable for the variable that's checked in the condition (musicActive) and every player (and the server) has a addPublicVariableEventHandler that will check the new value and if applicable, sleeps for the tune's duration. You could also check the current vehicle of the client to see if the tune was played on their vehicle (if you intend to have it work per-heli instead) etc. The server could also support JIP (by synchronizing the currently left sleep time, if any, with JIP players) by counting the sleep down one second at a time in a loop something like that (to be run on the server only): /* Assumes you have the tune's duration readily available in _tuneLength * and that currentCountdown is an exisiting global (for access by other * functions, e.g. those that handle JIP (not included here)) */ 0 = _tuneLength spawn { currentCountdown = _this; while{currentCountdown > 0}do{ sleep 1; currentCountdown = currentCountdown - 1; }; musicActive = true;//Presuming usage of a variable called musicActive as the global var for the action's condition check publicVariable musicActive; }; hint is local (in the sense that if you call it on any client, it will only trigger for that client; but you still need to make sure you call the code only on the intended player's computer/players' computers). To have the message show to only the troops in the specific heli where the music was activated from, you could use the public variable event handler as mentioned above (by checking the vehicle of the client); however per heli would require using a somewhat different approach (cannot use a single bool (true/false) check), which in the sample mission is commented out (however the setVariable/getVariable used in the sample, will not do the trick alone*, if applied in multiplayer, since they appear to be local, so you would need to use a global array or a set of variables (globals) for each heli that would be publicVariable'd when appropriate). * or ... it might since apparently publicVariable supports type "object", however I'm not sure if that applies to vehicles and if the vehicle's variable space would also be transferred. But yeah, more experienced multiplayer scripters can probably tell with more certainty what the best approaches would be.

I actually replicated the required functionality in a test mission to most part when first considering answering this the other day but didn't complete/post it as I wasn't sure about how some of the functionality was intended (i.e should all helis play the tune together (in 3d, since you're using say3d) or would simply playing the sound to each player individually be acceptable (with you using say3d, possibly for the effect, I expected not); whether it's for multiplayer or singleplayer (I'd guess the former, in which case there should (probably?) be extra handling for syncing the availability of the actions/"playing-state" of the music)). However, I decided to tinker the mission further and have made it accessible here (link). You will need to place tune1.ogg, tune2.ogg, tune3.ogg into the mus folder in there though (just copy & rename some ogg tunes you have; my upload is dial-up grade). It features music loading in such a way that in case you want to add/remove music, you would only need to edit the description.ext and the mus folder's contents (ogg files). The former follows specific "wording" (you'll notice) to achieve it (the code in init.sqf and musicAction.sqf rely on that). Similarly you can edit the mission (add/remove "h#"-named objects) without having to change the scripts/description.ext. It uses a custom config-entry (myduration) to sleep exactly the length of the tune before enabling playing again. It includes various approaches in the scripts (commented) - playing from single object vs from all objects; playing from one disables music playing options from all vs can be played from each independently. By default it plays sound from all the objects (not actually using just helis there). Also note that it isn't built with multiplayer in mind (doesn't handle anything related). The sleep-timers also don't compensate for time acceleration (the music doesn't automatically speed-up when using acceleration however sleep timers do and uisleep couldn't be used, since that would keep running when pausing the game, so the inputs/time acceleration status would need to be manually tracked/handled). In any case, answering the original question - spawn or execVM might be (have been) what you're looking for? As for removing the tracks - removeAction or using the condition parameter of addAction would do that. The provided example mission might give you some ideas/general guidelines though ;) (feel free to make direct use of it, should you feel like it)

Yes, that's how I tested it. For me this was the exact correct position (along x & y) when I respawned the building (the control tower on Utes). I only tested vs the basic getPos/setPos which indeed did place the building incorrectly, so I presumed this might work (as you hadn't tried that yet). But now as I tested further, apparently getPosATL/setPosATL does work for that building (setting it to the exact correct spot), so there's that. I don't have Lingor island myself to test on that particular building at this time though, I'm afraid. There's also visiblePositionASL that you could try I guess.

As for the reasons, I don't know exactly what's causing this but using modelToWorld from the original object and then applying setPosATL to the result with 0 z-coordinate seems to do it for me.

Indeed, I presumed random placement the goal. You are describing the wedge formation, which is the default formation (see more here). I was hoping that maybe calling createUnit with "FORM" instead of "NONE" to fix this, but apparently it doesn't seem to (they still walk to the formation, instead of spawning to it). In any case, as you probably know, typically spawning in formation would be achieved by placing the group leader correctly (in the sought direction/place) in the editor and the rest of the grouped units would be automatically placed accordingly. Positioning via script appears to need custom functionality to set their placement (if immediate formation is required) which you are effectively doing, by hand; to apply the wedge in any direction (in an automated fashion) you could call the following function where appropriate - applyWedge = {//Argument: group (leader's direction and position will be used as reference) private["_dir","_leaderPos","_groupUnits","_a"]; _dir = getDir leader _this; _leaderPos = getPos leader _this; _groupUnits = units _this; _this setFormDir _dir; for "_i" from 1 to ((count _groupUnits) - 1) do{//Starting from 1 since 0 is leader and the reference-point _a = if(_i % 2 == 0)then{-135}else{135}; (_groupUnits select _i) setPos [ (_leaderPos select 0) + ((floor ((_i - 1) / 2) + 1) * 6.5 * sin (_dir + _a)), (_leaderPos select 1) + ((floor ((_i - 1) / 2) + 1) * 6.5 * cos (_dir + _a)) ]; }; }; Even though according to the page I linked to above, wedge should be spacing units 5m out to both sides, I'm using the value of 6.5 in the above code since that seemed to spawn them most accurately in my brief testing. EDIT: How would one go about grouping a unit to a marker (or do you simply mean placing the group-leader to the marker, without any actual linkage to the marker)?

[sorry, this turned a little extensive :)] The sample I gave above does occasionally place several soldiers to the same marker (as well as disregard some markers at times) for me (perhaps you didn't test enough times?). Note that in below, if copying any of the code directly to an unpreprocessed script (such as a unit's init field in the editor), you will need to remove the comments first. You couldn't actually spawn soldiers "into" each other even if assigning them the exact same position (using setPos anyway; attachTo could be used to achieve something like that) as the game will automatically place them in a relatively safe/non-colliding location, however, if you wanted to space the units out when spawning, you could use in init.sqf - soldierToRandomMarker = { private["_minRadius","_maxRadius","_markerPosition"]; _minRadius = 5; _maxRadius = 10; _markerPosition = getMarkerPos str floor random 100; _this setPos [ (_markerPosition select 0) + ((_minRadius + (_maxRadius - _minRadius))*(1 - random 2)), (_markerPosition select 1) + ((_minRadius + (_maxRadius - _minRadius))*(1 - random 2)) ]; }; and in each relevant soldier's init - this call soldierToRandomMarker; Or (in each soldier's init; will require using the Functions Module;might take a (usually negligible) little instant longer than above, since it's got to wait for the module to start) - 0 = this spawn { waitUntil{!isNil "BIS_fnc_init"};//Since it's using the Functions Module _this setPos ([getMarkerPos str floor random 100,5,10,1,0,10,0] call BIS_fnc_findSafePos); }; See BIS_fnc_findSafePos on Biki for argument details. If you want the units to be just randomly placed in a general area (not specific areas, defined by the markers), you could set the "placement radius" in the editor for each soldier or set their positions with similar functions as given above (both the example code and BIS_fnc_findSafePos), using each soldier's editor-set position or a single central marker's position as the center point. If the units are "generic" units (nothing changed about them in the editor or otherwise) you could spawn them in a script something like that (init.sqf; or a single unit's init will do just for testing) - You'll first need a single marker at the center of the area you wish to spawn to (in the code below, referencing a marker called "spawnmarker"). soldierClasses = ["US_Soldier_MG_EP1","US_Soldier_Spotter_EP1",...]; //spawnMarkers = ["somemarker","someothermarker",...];//If using specific location markers call {//Only to use temporary variables private["_count","_group"]; _count = count soldierClasses; //_group = createGroup west;//If soldiers would be assigned to a single group (of BLUFOR) then this would be used with createUnit below for "_i" from 0 to 19 do {//Spawning 20 soldiers (createGroup west) createUnit [soldierClasses select floor random _c,getMarkerPos "spawnmarker",[],500,"NONE"];//creating all units within a circle of 500m radius around "spawnmarker" //or (createGroup west) createUnit [soldierClasses select floor random _c,[0,0,0],spawnMarkers,10,"NONE"];//If using spawnMarkers from above (creating within a circle of 10m radius at a random marker) }; }; If all the created soldiers are to be in the player's group, then use group player with the createUnit in above (assuming singleplayer). If you wanted to use all the soldier-classes in the array once, instead of randomly choosing, you could use soldierClasses select _i instead of soldierClasses select floor random _c in above and adjust the soldierClassses array accordingly. If you want to use specific units, then you can give them names (e.g. in the editor) like "mysoldier1","mysoldier2",... (the incrementing number is the important part) and loop through them as following (init.sqf) - for "_i" from 0 to 19 do { (missionNamespace getVariable format["mysoldier%1",_i]) setPos getMarkerPos str floor random 100; }; This allows to avoid having to type each soldier's init separately (note that the older createUnit syntax also allows defining init for the unit and can be used in similar cases). You can reference the soldiers the same way for the other solutions as well, for brevity I demonstratively used the basic 100 marker-solution here.

Or you could just use a variable instead of the box, if you're using the box only for trigger detection. E.g. you'd use something like trigger1activated=false where you create the box, trigger1activated=true where you destroy the box and trigger1activated && player in thisList for the second trigger's condition.

This does it for me (if markers are named from "0" to "99"): this setPos getMarkerPos str floor random 100;

It works for me if I just put the definitions (the script above) in a spawn and start calling _squadHint in a loop every second (in the same spawn naturally, unless you've modified it and made it global; also in a loop, you would likely prefer hintSilent there). However using this method I can only seem to display up to ~45 units (hitting hint string-length limit?, even though I know I've displayed stuff off the screen even with hint, so I'm not sure), so alternatively you could display the info on a dialog control using cutRsc. Or if you feel like putting more time into it, you could go a step further and make an interface to select a specific unit type (some leads to topics related to the various ways of doing that - addAction, showCommandingMenu, dialog control, groupSelectUnit). EDIT: The reason for the hint cutting off was format's output limit, so you'd need to replace the respective part in the above code with - ... _squadstring = _squadstring + format["<t align='left'>%1 - %2</t><br/>", _type call _typeToNr, getText (configFile >> "cfgVehicles" >> typeof _type >> "displayName") ]; ...

There :) _typeToNr = { private["_start","_typeAsArray","_nr"]; _typeAsArray = toArray str _this; _start = (_typeAsArray find 58) + 1; _nr = []; for "_i" from _start to (count _typeAsArray)-1 do { _nr = _nr + [_typeAsArray select _i]; }; toString _nr }; _squadHint = { private["_squadstring","_ugp","_cugp","_type"]; _squadstring = ""; _ugp = units group player; _cugp = count units group player; for "_i" from 1 to _cugp-1 do { _type = _ugp select _i; _squadstring = format["%1<t align='left'>%2 - %3</t><br/>", _squadstring, _type call _typeToNr, getText (configFile >> "cfgVehicles" >> typeof _type >> "displayName") ]; }; hint parseText _squadstring; }; Left align is achieved by using align attribute of structured text. Getting rid of " and [] by using actual strings for format arguments (you used an array). Isolating the number from the type-string is done manually by help of toArray and toString. Even though the various icons along the face-profiles of the units at the bottom of the screen already tell you pretty much everything.

Following this, I've successfully used the following myself (for smoke) in Arma 2: ... [["\Ca\Data\ParticleEffects\Universal\Universal", 16, 7, 48, 1], ... As for attaching to an object (as in that the particle effect will follow the object at a relative position, e.g. a burning airplane engine) - attachTo ... _ps attachTo [_target,[0,0,0]];//The position is relative to target's local space

This is a direct enhancement of ppEffectsViewer by Przemek_kondor that I'm releasing on his consent. For now it's only for Arma 2 with no idea when/if an Arma 3 port might happen (I hear Arma 3 does the GUI somewhat different and thus the mission will not be "directly portable", besides I don't own a copy of Arma 3 at this time). The updated interface layout, that's generally the same for all effects. I initially intended to just increase the size of the sliders and add a background for better visibility of color-correction sliders for personal convenience but ended up with all the following - Added background for better visibility of sliders Added slider value editboxes for value preview and input Added "multiplier" buttons for contrast and offset (in case somebody wants that heavy posterization effect or something) Added RGB-slider locking for color corrections (move all components together) Added aperture preview (not included in export) Added per-slider and general slider & value reset functionality Added slider-labels to all effects Added draggable move-handle Added compact string export (without spaces in the array-part) Added clipboard import (however will report otherwise working effects that have values outside the bounds displayable by the UI as invalid) Added hint-notice when copying to clipboard Added hint-notice when modifying dynamic blur Increased slider-height Reversed the sliders (lower values towards the bottom) Modified ranges for brightness (from 0..1 to 0..2), contrast (from 0..1 to 0..2 or 0..100 with multiplier) and offset (from 0..1 to -3..1 or -19..1 with multiplier) Modified precision of brightness, offset and color inversions (from 1/100 to 1/1000; since brightness "screens" quickly above 1, offset crushes dark detail quickly below 0 and color inversions apply quite noticeable differences at sub-1/100 steps) Modified step/page "speeds" of sliders for fine control [s]Modified text strings to fit containers (and vice versa)[/s] This depends on the used aspect ratio apparently and will not look 100% as intended with some formats RPT export now outputs only the code without surrounding double-quotes Made the daytime slider initialize and stick to current time Fixed showing a leftover from previous color correction (and other effects?) when first enabling Usage - Like in the original mission. Via radio menu. Access it from the action menu (scrolling the mouse-wheel by default) entry "ppEffects" or by pressing 0 twice. Note that the effects are disabled by default, so to see the effects you will need to click the enable button once you've chosen an effect from the menu (and change the sliders from default in most cases). Also, effects other than color-corrections will require post-processing to be enabled in the game's video settings. Additional note: The editboxes allow entering more decimals than the minimum slider-step and what hints display (however it will be applied to the effect as entered) which allows to temporarily test the tiniest value-differences. Export (as well as import) will still round it as displayed in the hint, so it would need to be entered manually to the ppEffect line in your code to be used. Thanks to Przemek_kondor for the original mission and encouragement to release this. Download - Original: Link Mirror: Armaholic

You probably know this but since you're not mentioning it; perhaps the difficulty setting DeathMessages (in-game called "YOU WERE KILLED") might do what you're looking for? Even though unlikely, as this doesn't apply to -radio- chatter but only the system-messages. Usage example in difficulty config - class Difficulties{ ... class regular{ ... DeathMessages=0; ... }; ... }; Edit: Or perhaps disableChannels (as used in Description.ext) could help (however that would probably disable all chat on the channels, even that of players, so that may be undesirable). I suppose just for testing, you could try to put the disableSentences false; (or all the lines) into a unit's init and see if that does it; if it does then the init.sqf is probably not properly calling it on the clients.

Agreed, I was just about to edit above that the 3rd option would likely be the best one to go by.

Ahh, I disregarded a detail in there - the _box2 isn't even the classname, but the "key-string" that the boxCreation.sqf expects, so the nearestObject will currently always give a null object. So there's various ways to solve this. A more experienced scripter might be able to tell which solution would be the most advisable here but here's what comes to my mind - 1. If you're only using the boxCreation.sqf in this instance (or don't mind changing the other instances to use the classnames as well), then modifying the expected strings in boxCreation.sqf (and _nerfBoxes) to the classnames (e.g. case "basicUS": -> case "USBasicWeaponsBox":). Otherwise a lookup table could do the job (e.g. one array with ["basicUS",...] (which you already have as _nerfBoxes) and another with ["USBasicWeaponsBox",...] and then something like _array2 select (_nerfBoxes find _box2) for the respective nearestObject's argument). 2. A global variable. E.g. either modifying the boxCreation to write to a specific global variable and read that after the script is done or make it accept a name for a global variable as a string (should you intend to have multiple scripts spawning in crates independently (with different global variables)) which it would write back to (getVariable/setVariable with missionNamespace). 3. Preprocess/compile the file into a variable* (function) and call it having modified the last line of the boxCreation.sqf to return _currBox. * (or if you're only going to ever call it once then might just _box2 = call compile preprocessFile "spawning\boxCreation.sqf" without storing the compile result to a variable).

I saw your post just now. Oddly enough I didn't see your post immediately when doing the multiple edits to my post (even though I did the last edit a good while after your post). My edited post should still apply (you will not be needing the modifications you did to the boxCreation.sqf).

As far as I can tell _box2 is a string not a vehicle-object (it should tell in rpt though) - _nerfBoxes = ["basicUS","basicUS2","basicRU","basicRU2","basicGER","basicPMC","basicSpecial","basicSpecial2","basicSpecial3"]; ... _box2 = _nerfBoxes select (random (count _nerfBoxes - 1)); ... [_box2, _safePos] execVM "spawning\boxCreation.sqf"; So, perhaps the boxCreation.sqf returns the object? So maybe the last line above should instead look like - [s]_box2 = [_box2, _safePos] execVM "spawning\boxCreation.sqf";[/s] Disregard that... forgot that execVM returns the script handle, so I'm unsure how boxCreation.sqf would provide a reference to the actual object. If it's the same boxCreation.sqf as apparently is used in some wasteland missions, then that one doesn't seem to provide a direct way for referencing the vehicle-object that was created. However I suppose you could do something like that after the execVM (but before the waitUntil in which you check for the box damage) - private[...,"_boxcreation"]; ... _boxcreation = [_box2, _safePos] execVM "spawning\boxCreation.sqf"; ... waitUntil{scriptDone _boxcreation}; _box2 = nearestObject [_safePos, _box2];//Note that up to this point I expect the _box2 to be the string, from here on it would be the box itself (hopefully) If I'm reading the code correctly, you're spawning the second box quite close to the first one so if there's a chance that the second box is of the same type as the first (wouldn't appear to be such chance with that boxCreation.sqf and that _nerfBoxes but I'm still providing this just in case) you might instead of the last line need something like - //If it's the same boxCreation.sqf I think it is, then it spawns the box at up to 30m away, leaving a small margin, I've put 40 here; if you know yours to work different, adjust as necessary _boxes = nearestObjects [_safePos, [_box2], 40]; { if(_x != _box1)exitWith{_box2=_x}; }forEach _boxes; However this expects these two to be the only two ammoboxes with with such classes in the area. The provided script doesn't suggest presence of more, so it should be ok. Also in the commented line, there appears to be little (probabaly insignificant) parenthesizing typo at the last expression - //(... AND ((damage _box2)) == 1) which is probably meant as //(... AND ((damage _box2) == 1))

Are you sure that _box2, referring to the correct object, absolutely certainly is accessible/exists in that scope?