Magirot

Make sure there's a helipad object (invisible or not) where you want it to land and use _wp [url="https://community.bistudio.com/wiki/setWaypointStatements"]setWaypointStatements[/url] ["TRUE", "this [url="https://community.bistudio.com/wiki/land"]land[/url] 'LAND'""]; Edit: When using this, it's actually better to put the waypoint well before the helipad, else the helicopter probably overshoots and the landing takes more time.

Have you got it to work otherwise? I remember reading a comment on the wiki saying that nearestObjects doesn't work with grenades, and that you should use nearObjects instead. Here's the comment: I guess it works now, or the reason why the above didn't work was using count? Edit: Oh, of course you're using nearestObject (not nearestObjects), since you're checking for distance, that might explain.

I tried the investigating bit. JIP seemed to sync before the first second. Maybe it's related to server load? Or to my test method (init.sqf): player_time_at_the_beginning_of_init = time; _check = 0; while {_check < 10} do { call compile format ["player_time_at_%1s = time", _check]; _check = _check + 1; sleep 1; }; Afterwards the client and server time values quickly got separated by dozens of seconds, with apparently no further synchronisation after connecting to the server (in line with teaCup's comment in the wiki). Edit: Also, when I went to the server the first time to load the mission, the difference between the admin client time and the server time was around 6s even initially. I know public variables aren't a good way to test this, but it was easy to show and the values seemed to be within 0.2 of the stuff I printed to server log. Image 2 (serverTime shows the uptime of arma3server.exe)

They do have a value for armour which is 0 for some items, but I don't know how to check it in a simple fashion with all the subclasses. Just look at the classtree. ---------- Post added at 18:23 ---------- Previous post was at 18:06 ---------- Or wait, can you just look for anything that's below a class? _itemg = headgear player; _noarmour = if (getNumber (configFile >> "cfgWeapons" >> _itemg >> "ItemInfo" >> "armor") == 0) then { TRUE } else { FALSE }; if (_noarmour) then { hint _itemg + " has no armour"; }; Edit: Actually yeah, that's how they're listed in Cfg's normally, I was confusing it with classtree hierarchy. So that should work.

I don't think it's possible without modifying game data, but you can apply the skins after the script has run with spawn. Just put _null = this spawn { sleep 0.1; _this setObjectTexture [0, "yourtexture.paa"]; _this setObjectTexture [1, "yourtexture.paa"]; }; in the init field. More info in this thread

The game only recognises a variable as local if it has an underscore in front of it (wiki), but the main issue is that triggers can only access and affect global variables. So the least you'd have to do is either to generate a separate variable name for each trigger, or use setVariable on the trigger itself. F2k Sel's script seems to handle it in a nice functional manner without any variables, though.

You can use the condition parameter of addAction to implement that. init.sqf: if isServer then { FOB_created = FALSE; publicVariable "FOB_created" }; // on server and public to prevent JIP issues player addAction ["Create FOB", "fobscript.sqf", [], 1, TRUE, TRUE, "", "_this == _target && _this distance [b]cargobox_object[/b] < 50 && leader group _this == _this && !FOB_created"]; Then somewhere in fobscript.sqf put FOB_created = TRUE; publicVariable "FOB_created"; Don't know if it's for MP, just in case I put the public variables and the check for updating the leader. A trigger isn't necessary unless I missed something. Edit: Explanation for the command in case someone is wondering: player addAction ["Create FOB", "fobscript.sqf", [], 1, TRUE, TRUE, "", Stuff you have to give before getting to the condition. In order: Action name, script or code, extra arguments passed to the script, priority in the action menu, show text in the middle of the screen if active, close menu on use, shortcut key. _this == _target The condition field has two special variables available, _this referring to the person using the action and _target referring to the target. In this case the action is attached to the player itself, so this is kind of redundant, mainly for issues with switchable units in SP. _this distance cargobox_object < 50 Check that the activator is less than 50 meters from the vehicle named cargobox_object. leader group _this == _this Check that the activator is the leader of his group. Or is it leader group _this == leader _this? !FOB_created Check that variable FOB_created is FALSE.

That's pretty sweet stuff Das Attorney, thanks for sharing. I'll give it a few tests with a stacked EH in MP later this week.

You can see them from the editor's own Config Viewer under CfgWeapons, at least. Or if you want to browse a file, kju has a giant config.cpp here (login with guest/guest) (thread). I just checked from Six's Config Browser that the icon of the uniform is in characters_f.pbo though, and then checked the config file from there.

You're completely right trying to execute addUniform globally. Actually I came across this in the addUniform thread: The syntax looks really weird, but apparently it works, so it'd be best to test both. I'm actually a poor person to advise with loadouts, since I keep getting into problems with them, and every working system confuses me further. LEA, for example, calls the loadout only for the server and the local player playing the unit, while the addUniform thread example above has it not run on the server at all. Something like the following could work could work. Leave the editor init line as it is, add player setVariable ["respawn_init", TRUE]; before the execVM line in onPlayerRespawn.sqf, and then try something like this for loadout.sqf: // try to avoid JIP issues waitUntil {!isNull player}; // Declare private variables (local to this scope) private ["_clothesArray","_clothes","_unit","_respawn_init"]; _unit = _this select 0; _respawn_init = _unit getVariable ["respawn_init", FALSE]; // since the remove commands are global, it should be alright to run them only // for the server and the player of the unit, right? ...right? if (_unit == player OR isServer) then { // Remove uniform and equipment removeAllContainers _unit; // Removes uniform, vest, backpack removeAllWeapons _unit; removeAllAssignedItems _unit; removeHeadgear _unit; removeGoggles _unit; // Set player's clothes (through the server, or through respawn) if (isServer OR _respawn_init) then { _clothesArray = ["U_C_Poloshirt_tricolour", "U_C_Commoner1_1", "U_C_Poloshirt_blue", "U_C_Poloshirt_redwhite"]; _clothes = _clothesArray call BIS_fnc_selectRandom; // does a function look simpler? [ [_unit, _clothes], {(_this select 0) addUniform (_this select 1)}], "BIS_fnc_spawn", TRUE ] call BIS_fnc_MP; // Alternative way (comment/remove the above three lines if used): /* Remove this line if below's in use switch (round (random 3) do { case 0: [[{}, _unit addUniform "U_C_Poloshirt_tricolour"], "BIS_fnc_spawn", TRUE] call BIS_fnc_MP; case 1: [[{}, _unit addUniform "U_C_Commoner1_1"], "BIS_fnc_spawn", TRUE] call BIS_fnc_MP; case 2: [[{}, _unit addUniform "U_C_Poloshirt_blue"], "BIS_fnc_spawn", TRUE] call BIS_fnc_MP; case 3: [[{}, _unit addUniform "U_C_Poloshirt_redwhite"], "BIS_fnc_spawn", TRUE] call BIS_fnc_MP; }; */ // Remove this line if above's in use }; }; It's not the same, since when hosting from the multiplayer menu, server == your client. On a dedicated, even if it's on the same machine, this isn't the case. On this issue it doesn't help as much, since you'll still need other players to make sure that the loadout is working, but for many other situations it'll be helpful.

Isn't it in characters_f.pbo, BLUFOR\Data\clothing1_as.paa?

I've understood that BIS removed capabilities for affecting dead bodies (to conform with censorship requirements), beginning with some Arma 2 version. 'Source' for the reason being hearsay and .So picking up a dead body would involve removing the corpse and spawning a new unit to simulate one. Don't know how credible it's possible to get that looking. The second point (behaviour when seeing corpses) should be manageable, since bodies can still be accessed via script. For the shadows I have no idea, unless you start making triggers for every shadow and do really weird checks for if a vehicle light is pointing in that direction. For simple stealth missions I've used bored_guard setSkill ["spotDistance", 0]; bored_guard setSkill ["spotTime", 0]; until there's an alert, to give the players more leeway.

colCheck shouldn't be declared private; it's not a private variable. Also, the "on activation" part of the trigger statements should be format["""%1"" setMarkerColor ""ColorRed"";[b] colCheck = false"[/b],_x], ""]; or format["""%1"" setMarkerColor ""ColorRed"";",_x][b] +" colCheck = false"[/b], ""]; Maybe that helps?

I mean these: http://i.imgur.com/y4edKWH.jpg Disabling those is what you get as the purpose of BIS_noCoreConversations if you google it, for example. Are you sure you're not confusing it with the effect of enableSentences? I mean I just tested it in A3 with "player setVariable ["BIS_noCoreConversations", true]; { _x setVariable ["BIS_noCoreConversations", true]; } forEach allUnits;" and I couldn't notice any difference.

The Six Config Browser has one, though it's for an old version (1.10). http://browser.six-projects.net/cfg_vehicles/tree?utf8=%E2%9C%93&version=73&commit=Change

It is a problem if you setup it from the unit init like you currently do, because everyone will see everyone else's actions and can access them if they're close enough. Right now the behaviour would be very erratic in MP. Edit: Okay, at this point I should've mentioned that all you need for yours to work is put your addAction into init.sqf, and switch "this" into "player" in that part, and if you want to remove the text in the middle of the screen, use: player addAction["personal light on","light_on.sqf", [], 10, FALSE]; The rest of this message is just an example. This is how I set it up for a friend (with four chemlights, removed the rest for this), supplanting removeAction: init.sqf: chemlightsOn = FALSE; player addAction ["Attach chemlight", "chemlights.sqf", [], 1, FALSE, TRUE, "", "_target == _this && !chemlightsOn"]; player addAction ["Remove chemlight", "chemlights.sqf", [color="#40E0D0"][][/color], [color="#FF0000"]1[/color], [color="#00FF00"]FALSE[/color], [color="#FFA07A"]TRUE[/color], [color="#DDA0DD"]""[/color], [color="#000080"]"_target == _this && chemlightsOn"[/color]]; The addAction arguments are: name, script, arguments that are passed to the script beside the three mentioned above, priority (bigger = appears higher in the action menu), show text in the middle of the screen, close the action menu on use, shortuct key, condition. (Sorry for the colours, that probably made it even less clear. D: ) See the wiki entry for more info. chemlights.sqf: private ["_bluelight", "_player", "_playerx", "_playery"]; _player = _this select 1; _playerx = getPos _player select 0; _playery = getPos _player select 1; if (!chemlightsOn) then { _bluelight = createVehicle ["Chemlight_blue", [_playerx, _playery, 2], [], 0, "CAN_COLLIDE"]; _bluelight attachTo [_player, [0.12, 0.06, -0.1], "LeftShoulder"]; _player setVariable ["chemlight1", _bluelight]; chemlightsOn = TRUE; } else { _bluelight = _player getVariable "chemlight1"; deleteVehicle _bluelight; chemlightsOn = FALSE; };

The static ID system was reverted a version later, see under operations in this sitrep. Stand right next to the sign and type this in the debug console: hint format ["%1", nearestObjects [player, [], 15]]; Does it return anything usable (instead of a model file) for it? If not, it's related to these: Need hideObject command to hide objects with no classnames (feedback tracker) Maybe you can, I dunno, put a big sandbag on top of the old sign or something?

Maybe it's a resource effect instead of a postprocessing effect? I can't test it right now. _layerTestNoise = "mytestnoise" call BIS_fnc_rscLayer; RscNoise_color = [1, 1, 1, 0]; _layerTestNoise cutRsc ["RscNoise", "BLACK"]; Edit: Without local variables (remove the underscores) if in the editor instead of a script.

It's possible to assign a value to paramsArray? On default no, you'll need to assign the HC into the slot as an admin, but you manually can put forceHeadlessClient=1; under the unit in mission.sqm, after which it'll pick that unit automatically. I can't tell what's wrong with your scripts (as said I have no experience of HC's), still you shouldn't need setOwner if the HC spawns the units on itself. Hopefully someone can help you, though maybe you'd have a better chance of getting answers in the headless client thread?

You probably already know this, but: nothing happens automatically after you've set up the HC itself. Locality reminder: The player's unit is always local to its client AI units are always local to the client of their leader A vehicle is always local to the client of its driver AI leaders are always local to the server, if placed in the mission editor AI units created after mission start via scripting will be local to the computer that issued the command Empty vehicles/objects placed in the mission editor are local to the server Empty vehicles/objects created after mission start via scripting (with createVehicle for example) are local to the machine that issued the command And HC makes use of the bolded points, which is why in my knowledge the normal (or most basic?) procedure for HC setup is to Check if the client is a HC in init.sqf. If it is, spawn everything through that client by script, to ensure that they will be local to the HC. I guess the reason for saying UPSMON is easy to use with a HC is that it'll handle the waypoints? Especially since there's a command called setOwner for transferring the locality of a unit, and I heard WP's aren't part of that transfer. So, I have zero experience of HC's, but it should be something like this? if isServer then { HCServerSetup = FALSE; publicVariable "HCServerSetup"; _hc_clientID = owner that_immortal_bunny; _playerIDpool = []; { _playerIDpool = _playerIDpool + [owner _x]; } forEach playableUnits; _playerIDpool = _playerIDpool - [0]; // 'owner' returns 0 if it's not a client { if ( !((owner _x) in _playerIDpool) ) then { _x setOwner _hc_clientID; }; } forEach allUnits; // probably should be for vehicles as well? HCServerSetup = TRUE; publicVariable "HCServerSetup"; }; // no interface and not a dedicated server = HC if (!hasInterface && !isDedicated) then { waitUntil { HCServerSetup }; { if (!isPlayer && leader group _x == _x) then { [_x, "upsmonareamarker"] execVM "UPS.sqf"; // UPSMON script here }; } forEach allUnits; }; I'd be really surprised if that worked as-it-is, but that should be the general idea? The information is scattered but it's there, on Google and the Server Admin forum.

I think I read somewhere that units group returns the group members that the group thinks are alive, and is updated in the regular AI reporting method you'll see in-game. Haven't confirmed it, though, I've always used an alive check even with group arrays. Edit: Kronzky has something about it in the entry for units (2009), but it doesn't sound like the above.

I think it's just used as a tool for sending code (instead of a predefined function) through BIS_fnc_MP, since the latter doesn't normally support this. First thing I noticed: you're initially executing loadout.sqf through the unit's init field. The init fields are executed by all players. In such a circumstance you shouldn't get a random item from an array, because everyone will get a different random result - and then at the end everyone runs BIS_fnc_MP and broadcasts their choice. Chaos! Madness! It needs a different solution. Secondly, BIS_fnc_spawn almost certainly uses the parameters given in the first parameter, and you can't pass local variables into the code part itself. It should probably look like this: [[_unit, _clothes], {(_this select 0) addUniform (_this select 1)}], "BIS_fnc_spawn", TRUE] call BIS_fnc_MP; You can use "player" (as a parameter, not in the actual code) in the script you call from onPlayerRespawn, but if you use it in the one you call from the unit init, every player calls it as their own unit. Just to be sure (sorry just in case), are you aware of arma3server.exe in the Arma 3 Steam directory? If you have access to the game itself, you can simply open that and then join through the LAN menu. Obviously it's not as good as testing with players, especially in this case, but in many instances it'll still give a much closer impression of how things will actually play out in MP.

It should work, as long as you execute it from the unit init field (which are executed by all players), and use a trigger that doesn't depend on variables that players have differing values for (like player). My understanding is that the issues with hideObject locality are mostly related to separate scripts that aren't run for everyone. (I won't vouch for it though, since you never know with this series.)

I guess you could put ambushgroup1 = group this; { hideObject _x; _x enableSimulation FALSE; } forEach units ambushgroup1; in the init fields of the ambush group leaders, and then // use if there's only one group: { _x enableSimulation TRUE; _x hideObject FALSE; } forEach units ambushgroup1; // if there's more than one: { _x enableSimulation TRUE; _x hideObject FALSE; } forEach units ambushgroup1 + units ambushgroup2 + units ambushgroup3; in the trigger, switching the group names if necessary. Not sure if it's the smartest way, but I suppose spawning the group and creating the waypoints by script isn't nearly as easy.