Magirot

Did you create groups first in the 3d editor, or what do you mean that you cannot select them? You have to create them separately first from a menu different from creating units, like in scripts but unlike the 2d editor. Edit: I do think it's the best option for static objects, at least, because the mission.sqf it creates works fine when you strip the object creation part into a separate script.

Bolded the important part: So you can't use it from a regular mission. The wiki really should have this info.

You could use an event handler. Put this in your init.sqf or similar place: { // forEach block start // only if the unit is blufor // _x is the magic variable referring to the current forEach unit if (side _x == blufor) then { // add an eventhandler for getting hit _x addEventHandler ["Hit", { // Object the event is attached to is the first variable passed _unit = _this select 0; // Object that caused the damage is the second variable passed _causedBy = _this select 1; if (side _causedBy == civilian) then { _causedBy addRating -2500; _unit removeAllEventHandlers "Hit"; // or //[_causedBy] joinSilent someOpforGroup; }; }]; // add an eventhandler for if the unit is killed _x addEventHandler ["Killed", { // Object the event is attached to is the first variable passed _unit = _this select 0; // Object that caused the damage is the second variable passed _causedBy = _this select 1; if (side _causedBy == civilian) then { _causedBy addRating -2500; _unit removeAllEventHandlers "Killed"; // or //[_causedBy] joinSilent someOpforGroup; }; }]; }; } forEach allUnits; // cycle through all units in the mission They won't react if the unit fires near them, which can look silly, but will turn hostile if the unit hits someone or kills someone.

.h and .hpp are extensions for include files, that is files the contents of which replace the include line. So if you had a Debriefing.hpp containing: class End1 { title = "End"; subtitle = ""; description = "The mission has ended."; }; and a Description.ext containing: class CfgDebriefing { #include "Debriefing.hpp" }; Then the way the latter is read by the game is: class CfgDebriefing { class End1 { title = "End"; subtitle = ""; description = "The mission has ended."; }; }; There's usually no "need" for them beside making files easier to read.

The wiki doesn't have have the A3 list for markers, though, and at the time of the thread, the A2 ones hadn't been appended to the end of the markers config. So nothing wrong in tryteyker's advice, in my opinion.

Might be a case of fixing a problem for some people and causing a new one for others. Gamespy seems to be down now, and I still can't get my server to show up with any of the suggestions listed in the thread. Situation unchanged since Steam browser was introduced. :(

You can place some normal units down in the editor, check the animal class names you want from here (or the config editor), and then open up mission.sqm with a text editor and manually switch the unit class names. Afterwards you can't open the unit's properties in the mission editor, though, because that resets the class back to one that's available regularly. Also some of the animals are absolutely horrible to control.

ArmA: Introduction to Scripting - Written for Arma 1, but still mostly applies. It's just a very basic introduction. Identifiers Variables Data Types Magic Variables Code Optimisation Multiplayer locality, the bane of the Arma series (these overlap somewhat, but both contain necessary nuggets on information) Locality in multiplayer Sickboy's view on multiplayer scripting

A file called onPlayerRespawn.sqf will be executed on default, unless you specify another file in a new respawn template. The loadout should work like that in theory, but because of the still-persisting bug with addUniform, there will be problems. You should switch the addUniform line into: [[[_unit, "U_B_CTRG_3"], { (_this select 0) addUniform (_this select 1) }], "BIS_fnc_spawn", TRUE] call BIS_fnc_MP; Otherwise you will run into problems, as removeUniform is executed for everyone, while addUniform is only executed locally. Which means people in underpants. However, there will actually be problems with the init lines at well: If a Join-In-Progress player joins while the game in progress, all players who are still controlling their initial, non-respawned units, will lose their uniforms (because the JIP player executes the init lines, and the global commands will get applied again). Also I think they might be teleported 500m into the air at that point too. Avoiding this is relatively simple in your case, if there aren't any AI units or separate loadouts. You could give this a try in your init.sqf, for example: That way the initial setup is actually only executed once, JIP should work, and if you put BIS_fnc_MP uniform line in onPlayerRespawn, everything should work. should.

As far as I know, the issue is that A3 attachTo prevents the player from looking around with freelook, which the A2 script was based on. Feedback ticket

Some time ago I figured that they work if I just throw the mission directory in the MPMissions folder, but with a pbo it crashes like I described. Am I the only one with this problem? Could someone give it a test? Here's a zip with a folder and a pbo.

So I threw together a short mission for MP purposes, and decided it was a good time to test the templates listed here: https://community.bistudio.com/wiki/Arma_3_Mission_Parameters#Predefined_Params However, using any of them causes the server to crash when the mission list is loaded, with an error message like this (the file is just the first file I try to include): Include file a3\functions_f\Params\paramWeather.hpp not found It's confusing because I think I've seen a few people use them without problems, and the Bohemia Zeus missions, for example, use them in their .ext files. However if I copy the same lines to my own mission, it'll crash with the "not found" message. The barebones version I tried was just: class Params { #include "\a3\functions_f\Params\paramWeather.hpp" #include "\a3\functions_f\Params\paramDaytimePeriod.hpp" }; Any ideas what I'm doing wrong?

Respawn happens by spawning a new unit of the same class name and switching the player to that one, so the init field of the old doesn't get applied. Have you thought using the loadouts you can define in description.ext? See the settings like MenuInventory. https://community.bistudio.com/wiki/Arma_3_Respawn Other way is to apply the scripted loadout again in a file called onPlayerRespawn.sqf that you create in your mission directory. The HALO jump you have to apply this way in either case. Create the file and put this in it: // the new unit is the first parameter that the game passes to the script _unit = _this select 0; _unit setPos [getPos _unit select 0, getPos _unit select 1, 500];

The ones in the editor's config viewer should be correct. Are you sure you had the quotation marks and such? If you want to use them with say3D, you do need to define them as sounds in your description.ext, using the actual file paths instead of class names. The config viewer has them if you click the entries in CfgMusic. The newer playSound3D would allow the same functionality without the need for extra-defining. For me it stops working when I give it the volume and distance parameters that're required for stuff like this, though.

What syntax have you tried & where did you get the classnames? playMusic "Track11_StageB_stealth"; It it doesn't work, maybe add 0 fadeMusic 1; to be sure?

For Kilo1-1's problem above: with AI, all you need is to make sure the server (and only the server) manages to execute all relevant stuff before the players get into that phase. A function containing an isServer check run from the unit's init field works great, and doesn't require BIS_fnc_MP, since apparently the data manages to get synced in time. Only executing on the server through a function actually works even with player units, and similarly doesn't need BIS_fnc_MP with addUniform, but this fails on JIP/respawn. Doesn't it cause problems if even one of the units is missing (due to the slot not being selected), because the variable will be undefined? That's what I instantly hit with a similar setup, at least.

As another question on optimisation, wouldn't it be better to remove the one sleep from cosInit.sqf? I mean the one in the loop that checks for road positions (line 141). I've understood that a mission initialises under the loading screen as far as it can get before it runs into a waitUntil that doesn't pass, or sleep. Wouldn't removing it allow all the positions to be checked during loading, while currently it'll start running only after the mission has started, causing extra slowdown during the first seconds? I do have to finally thank for this wonderful script that has helped me bring so much more atmosphere to my missions. It's too bad that I've lately been having problems with it. Sometimes the game freezes for several seconds when the trigger is activated, and in the end nothing is spawned. I guess I should try to debug what's the cause, somehow.

If you mean the half-finished one that comes with the game: http://forums.bistudio.com/showthread.php?150961-Using-inbuilt-3D-Editor-for-map-making Edit: The thread is focused on terrain building, though. Basically what you need to do is: Either in your SteamApps\common\Arma 3 folder, or in your User\Documents\Arma 3\missions -folder, create a folder with the name something.something (for example 3d.editor or something.Altis). In the folder, create a new file and name it mission.biedi Open mission.biedi with your arma3.exe Any missions you save will go to the user folder's missions folder, like normal edited missions. I usually just use it to place empty objects, then copy and slightly edit the mission.sqf to spawn them in my regular mission.

I spent a lot of fruitless effort trying to get the folder paths to work with briefing images, but in the end I've just ended throwing them to the mission folder's root, because at least that works. It should still display a message that the image wasn't found, though.

If you have disabledAI = 1; in your mission's description.ext, this should happen automatically, but obviously it's not suited for every mission.

That's a pretty crafty solution, thanks for sharing.

Gamespy is closing later this month, so these are very much just temporary solutions. I didn't even have reportingIP in my server.cfg, nor do I define any ports. I'm not behind NAT, I've tried with all firewalls disabled, and I still can't get my server to show up Steam-side. :/

On a quick glance, getMarkerPos objective1 -> getMarkerPos "objective1"

I don't know for sure, but my guess is that the module creates the editing area when the module is initialised, well before init.sqf and your script, so moving the trigger alone has no effect. Have you thought using the scripting command to define it/them? Something like this under the isServer part of the randomisation script: zeusObjName addCuratorEditingArea [0, _zonePos, radius]; zeusObjName addCuratorCameraArea [0, _zonePos, radius];