Magirot

It might've been easier to use KK's code now that it has thisTrigger. I understood from post #9 that the long class array isn't needed, and since it doesn't require a separate script, it would've probably been easier to handle for someone not experienced with execVM. To explain to some extent, what a "local variable" in "Local variable in global space" is referring to is the identifier with _ in front of it, in this case _objectArray. Variables with _ in front of them (local variables) can only be used in a script, since unlike variables defined in a global space (which includes everything defined in the editor), they aren't broadcast outside of the script, thus saving resources but preventing their use in triggers, which require that the data is available during a longer time period. You could use this code too without a separate script, either by just removing the _'s from the fronts of the two _objectArray's, or by moving the contents of _objectArray's defination to the part where it's later referred to. But as said, if the longer array of classnames isn't needed, you could just use what KK provided, and throw it into a trigger's onActivation: Then again, if you are using a script, AND using it in multiplayer, it would be a good idea to add if (!isServer) exitWith {}; to the script's first line to prevent resources from being wasted needlessly.

If Vostov is still having problems with KK's code, it might be because of trying to run the code from a trigger, in which case it should be "thisTrigger" instead of "this". } forEach nearestObjects [thisTrigger, [ <- The part I mean.

Don't forget that removeItem doesn't work with assigned items, you need to either use player unlinkItem "ItemRadio"; or unassignItem them first.

In case you didn't come around it yet: https://community.bistudio.com/wiki/Arma_3_CfgPatches_CfgVehicles Edit: Though you probably wanted a classtree, which would be in the subject of the thread. D: Not sure if there is one beside the aforementioned in-game config editor, the one at the Six Config Browser is nine months old.

You have to execute the setDate command itself on the server, public variabling the value alone doesn't help. BIS_fnc_MP is helpful in this case, and doesn't require the extra pV. If you use it with the original script, it works if you replace all the lines that read setdate _date; with [[[_date], { setDate (_this select 0) }], "BIS_fnc_spawn"] call BIS_fnc_MP; Edit: That's for changing the time alone, the fades and texts would require more of the same, but it would be better to define them as functions instead of using BIS_fnc_spawn. Where is the script called from? As in how do you use it in-game.

Sorry, I forgot regular createVehicle only creates the object at the approximate location. In the initServer.sqf, change this line _obj = (_x select 5) createVehicle (_x select 14); to _obj = createVehicle [(_x select 5), (_x select 14), [], 0, "CAN_COLLIDE"]; and it should work.

Broadcasted setVariables are always present, but if there's no name to know the object by, it can be hard to access it. Essentially you don't "publicVariable the object" when you do this, you pV a variable that has the object as its value. In other words, it's to create a way to refer to the object, which isn't around by default. To clarify, if you put something in the "name" field in the editor, it creates a variable by that name and assigns the object as its value (and you can be sure that all clients know that identifier, because it's done when the mission is being loaded). But you can also assign the object as a value to other variables, and they'll work identically to the one in the name field, provided they've been defined on every client you need them on. On the other hand, vehicles/units/triggers created via script can be easily defined only on the client that creates them. Executing publicVariable on a variable that's defined while creating the vehicle is the easiest way to make sure that every client has a way to refer to the object. createUnit has the init parameter that you can use to define an identifier, but createVehicle and createTrigger do not. Sorry if this is hazily put, I've not slept for a while.

You can also put it into initServer.sqf instead of init.sqf :) "Executed only on server when mission is started."

Put player unlinkItem "ItemRadio"; in your init.sqf?

Here's a file: initServer.sqf If you put it into your mission folder, it will create this (from the snippet you pasted): http://i.imgur.com/L3uWzYN.jpg So if you open the file in a text editor and paste the remaining export in between the brackets: { _obj = createVehicle [(_x select 5), (_x select 14), [], 0, "CAN_COLLIDE"]; _obj setDir (_x select 12); } forEach [ // paste here ]; it should work, if there's no clutter before/after the text. Take care, though, since you cut it at the wrong point previously. A single object looks like this: [0,true,"OBJECT","Object","Object","Land_Shoot_House_Wall_F",16,"Safe","Limited","",0.5,"FORMATION",270,5,[23426.2,18688.9,-0.96517],[23426.2,18688.9,-0.96517],"","",false] If you have problems with it, you can paste the whole thing to pastebin/pastie like I mentioned earlier and someone will probably fit it for you. Edit: Actually the whole export is probably already in between brackets, so just try to see that there's only two brackets before and after the actual contents start.

Could you paste a bit longer snippet of the code, or the whole thing to pastebin or pastie or similar? Just spawning all that's currently there could be quite easy, for example initServer.sqf containing something to the effect of { // forEach block start - go through all the objects // _x is a magic variable referring to the array currently selected, // "select" selects parts from the array _obj = (_x select 5) createVehicle (_x select 14); _obj setDir (_x select 13); } forEach _arrayContainingAllTheObjects; but it's hard to grasp how it's laid out in the export. I don't know how the function that Grumpy Old Man brought up works, but it might have the same effect if you can put it into an array. Of course it's not as ideal as getting it to .sqm would be, but it could work with not so much effort.

There is a way, however I think it might be a bit buggy. I will make certain it works for the 0.3 release, as well as provide a wiki article about it. Is this option around yet? I tried to do it by executing the init scripts that each module addon has, and while many of them surprisingly work with only that, the medical system is missing some crucial event handlers.

Should work like that, yeah. These parts might be all clear to you already, but in case they're not: Usually you can check the wiki for the scripting commands' locality (or at least get hints on how it goes). For example with setFuel there's the three icons under the header - after the version it's arguments "local" and effects "global", meaning it only has effect if its executed on the client where the target is local, but the effect (the amount of fuel changing) is visible on every client. The regular hideObject, for example, has them around the way - you can hide any object regardless of its locality, but the effect will only be visible on the client executing the command.

If you look at the documentation for setting the values, you can see that all of them have options for setting the time during which it'll slowly change. For example if you put 3600 setOvercast 1; 3600 setRain 1; then it'll change during the next hour. And works better than just setting it instantly, since you'd have to use forceWeatherChange to get the game to properly take everything into account otherwise.

setFuel and allowDamage need to be executed on the computer where the objects they're applied to are local. Since addAction is only executed for the client that runs the action, you might want to use BIS_fnc_MP. [{ trouble1 allowDamage FALSE; trouble1 setFuel 1; }, "BIS_fnc_spawn", trouble1] call BIS_fnc_MP; [{ trouble1 setFuel 0; }, "BIS_fnc_spawn", trouble1] call BIS_fnc_MP; If you know for sure that the helicopter will be local on the server, you can use "BIS_fnc_spawn", FALSE] instead of "BIS_fnc_spawn", trouble1]. The wiki has info on the parameters:

I think you're confusing it with BIS_fnc_spawnVehicle, createVehicle array does the same as createVehicle but with more options. And apparently some other differences, if you look at the notes of createVehicle: I doubt it's critical in this case, though, so as long as it works. The reason why the first one doesn't might be because of the last parameter being "" instead of "NONE"?

Maybe add this switchMove ""; to their init, or create a trigger with condition TRUE and activation { _x switchMove "" } forEach allUnits?

I've found a single problem with this method, as well: if a player switches units by leaving to the lobby and selecting another without exiting the server completely, init.sqf doesn't get run again (edit: though my problem here might be not enough checks?). This means that unless the unit was already present as an AI, it won't get its custom loadout. If you want to avoid this, L3TUC3's method is the another viable option. Though even for that, you should add a "do only once" variable check, because if a JIP player joins into a previously server-controlled unit, it can lead to the script being run again. So it would be: if (!local _unit || _unit getVariable ["loadoutDone", FALSE]) exitWith {}; // rest of code // at the bottom: _unit setVariable ["loadoutDone", TRUE, TRUE]; This is as far as my knowledge goes, if someone has more pointers on the issue it would be great to hear them.

The problem with this was two missing brackets, it should be: [b]{[/b] if (_x IsKindof "Man") then {removeAllWeapons _x;removeAllAssignedItems _x;removeAllContainers _x;removeHeadgear _x;removeGoggles _x; } [b]}[/b] forEach allUnits; However, it wouldn't have solved your problem in any way, because without a check to see if it has already been run, Join-In-Progress players would still remove all gear from everyone upon joining. And if you'd add a check, JIP players would be left with the default gear. Arma is really annoying with locality. One way around your problem is to do this: 1. Switch the unit gear removal to a script. Put this in your unit's init field: this execVM "clearInventory.sqf"; Create a file called clearInventory.sqf and put this as its contents: // Get the "this" variable that was passed to the script _unit = _this; // Check that the unit is local to the computer, // and that the items haven't been removed already if (!local _unit || _unit getVariable ["loadoutDone", FALSE]) exitWith {}; // clear inventory removeAllWeapons _unit; removeAllAssignedItems _unit; removeAllContainers _unit; removeHeadgear _unit; removeGoggles _unit; // set the variable so that they won't get removed again _unit setVariable ["loadoutDone", TRUE, TRUE]; 2. Same with the cargo box, don't put it directly in the init line. Return to the script setup like you did earlier: this execVM "cargoBox.sqf"; // Only run for the server, the important part if (!isServer) exitWith {}; //Clearing the box clearWeaponCargoGlobal _this; clearMagazineCargoGlobal _this; //Uniform _this addItemCargoGlobal ["U_mas_mar_B_CombatUniform_des_tshirt",1]; _this addItemCargoGlobal ["U_mas_mar_B_CombatUniform_des_vest",1]; _this addItemCargoGlobal ["U_mas_mar_B_CombatUniform_des_tshirt",1]; //Headgear _this addItemCargoGlobal ["H_mas_mar_helmetd_us",1]; _this addItemCargoGlobal ["H_mas_mar_helmetdgog_us",1]; _this addItemCargoGlobal ["H_mas_mar_Booniehat_des",1]; //Vest _this addItemCargoGlobal ["V_mas_mar_PlateCarrier1_rgr_d",1]; _this addItemCargoGlobal ["V_mas_mar_PlateCarrierGL_rgr_d",1]; //Shemagh _this addItemCargoGlobal ["NeckTight_DMBLK",1]; _this addItemCargoGlobal ["L_Shemagh_Tan",1]; _this addItemCargoGlobal ["NeckTight_TanO",1]; //Weapons _this addWeaponCargoGlobal ["ej_iar30",1]; _this addItemCargoGlobal ["FHQ_optic_ACOG",1]; //Pistol _this addWeaponCargoGlobal ["RH_m9",1]; //Ammo _this addMagazineCargoGlobal ["30RND_556x45_Stanag",15]; _this addMagazineCargoGlobal ["RH_15Rnd_9x19_M9",5]; //Grenade _this addMagazineCargoGlobal ["HandGrenade",2]; _this addMagazineCargoGlobal ["Chemlight_blue",2]; _this addMagazineCargoGlobal ["SmokeShell",2]; _this addMagazineCargoGlobal ["SmokeShellBlue",2]; _this addMagazineCargoGlobal ["SmokeShellGreen",2]; _this addMagazineCargoGlobal ["SmokeShellRed",2]; //Item _this addItemCargoGlobal ["ItemGPS",1]; _this addItemCargoGlobal ["ItemMap",1]; _this addItemCargoGlobal ["ItemCompass",1]; _this addItemCargoGlobal ["ItemWatch",1]; _this addItemCargoGlobal ["TFA_NVGoggles2",1]; //Backpack _this addBackpackCargoGlobal ["B_AssaultPack_cbr",1]; //FirstAid _this addItemCargoGlobal ["FirstAidKit",10]; //Radio _this addItemCargoGlobal ["ItemRadio",1]; This way they do get created globally, but only once. (I fixed a couple of the item types; there FirstAidKits are items, not weapons; grenades are magazines, not items; 30RND_556x45_Stanag is assumedly a magazine, not an item) Also you shouldn't create TFAR radios directly, ItemRadio gets automatically replaced with the appropriate item. If you want to define what that item is, there are commands you can put into init.sqf. Directly creating "tf_rf7800str_2" can lead to problems, the issue is in the "str_2" at the end.

You probably have removeUniform in the init fields of the units? The command is global, and Join-In-Progress players execute init fields for everyone. You either need to remove the command or make sure it's only executed once (with local and get/setVariable, for example).

You do realise that even very recent games like XCOM: Enemy Unknown (2012) employ fog of war? That is because it is a very important strategical element not to see into areas where you do not have units present. In Arma 3, even if you restrict the camera, unit spotting does not factor into the system. Well, I guess this is due to misunderstanding that fog of war would need to be literal fog, as said previously. Edit: welp, didn't notice the thread was quite old.

There's a separate vehicles command for that, allUnits only returns all alive units. As for setObjectTexture and uniforms, it working depends on if there are hidden selection options defined for the clothes in question. If your setObjectTexture [0, "camo\marpat.paa"]; doesn't work, it's possible that there aren't any for that particular uniform, and it's only possible to retexture them through an addon. So while it does work on every faction's regular uniform, units with more "specialised" uniforms like officers can be the issue here. But on a quick glance it looks like the missing ;'s in these lines might also be breaking the whole script: _x enableGunLights "forceOn"

It seemed to work fine when I tested it by defining the function on top of initPlayerLocal.sqf. How do you define the function? Looking at the function name you're not using the Functions Library? Should be mbicr_fnc_freeze if you are.

I can't seem to get my locally hosted dedicated server to show up on the Steam side. Things I've tried so far: Vanilla server settings Both default and development branches arma3server.exe in both the regular game folder and the separately dl'ed server With and without BattlEye Opening the default ports (2303, 8766, 27015, 27016, from here, here and here) Running completely without a firewall, but no dice. Currently it's not a problem as Gamespy works (in all cases it shows up fine there). It's the future that worries me a bit. Any ideas? Couldn't find any earlier discussion with the search, sorry if there's already something on this.

Apparently it's called "face". So this setFace (face player); should work.