Zenophon

The code executed on activation of the action is effectively a separate thread than the script that added the action. The code executed stands on its own without a higher scope that called it. Therefore, the error means that you have used a local variable that is undefined in the current scope. You can make use of the feature of addAction that allows you to pass arguments to the code. It is detailed on this wiki page (arguments are after the code): http://community.bistudio.com/wiki/addAction Using this, I would write the addAction statement like so: _spawnCamp addAction ["Join this camp?", {[_this select 1] joinSilent (_this select 3)}, _grp]; The '(_this select 3)' refers to the argument passed into the code of the addAction; this is the value defined in your script as '_grp'. This argument remains a persistent property of the action, storing the value of '_grp' separately from your function that executed the addAction. Changing the value of '_grp' in your function will not affect the code of the addAction.

Allow me to clarify what I said about task modules. They are, as you said, for mission designers who do not want to use external scripts. However, the core code within the modules is the same as the most basic code of any task system; there are several sqf commands that everyone must use to create and manage tasks. The difference is just that modules have an easier GUI instead of making you create sqf functions, but the functions can have extra logic layered on top to provide advanced features. The modules are excellent if you do not need any complex operations done on tasks and if you only have a few tasks. You can imagine that if you use the task modules for a dozen tasks, the web of modules, triggers, and synchronization lines could become overwhelming as well as hard to debug or change later. The modules also cannot offer features like removing a task from some units and copying it to new units. If you have any inclination to learn sqf scripting, I strongly encourage you to do so. The advantage that scripting offers over using only the editor is immense, and it constantly means the difference between implementing a feature I want in a mission and leaving it out. As you are beginner though, using the task modules will be faster and less frustrating than learning to use sqf functions for your tasks or figuring out how to use some one else's complex task system. All I can say is that learning to script will pay off later. The first guide that you posted is a bit disorganized and fails to give you a good overall idea of what is being done, but the link to the forum thread at the very bottom seems much more promising. That thread seems to provide better, concise answers for using the task modules and includes some beginner questions that are answered. For the second guide, I assume you are referring to section 16 of the guide. This is a slightly overcomplicated beginner's guide to creating tasks in a script. If you want to try using external tasks scripts, just refer to the parts of that section where the task is actually created (with 'createSimpleTask') and the part where an editor trigger is used to refer to that task by name. Unfortunately, neither guide seems willing or able to explain what a task actually is or why they work that way. In short, a task is similar to an object (like a unit or a car) in that it has persistent properties that can be altered, but it is considered its own data type. Each task is assigned to a single unit, and there are numerous issues that arise when scripting tasks in multiplayer due to locality and JIP. I do not know if the task modules actually work well in multiplayer or not. If you are interested in more about scripting tasks, see this: http://community.bistudio.com/wiki/Tasks Whether you chose modules or scripts (or a combination of both), I recommend starting small and worrying about it working in multiplayer later. I have just run out of time to write this, but I will try to answer your question about a helicopter insertion later (maybe with an actual script instead of links and general advice).

Firstly, if you posted a link to any guides you are using, that might help people gauge what you have learned/done so far and if there is any important information missing from the guides. I personally do not use the task modules in the editor, and I am currently creating my own system of managing tasks that is far more robust. I highly recommend that you use external scripts to create and manage tasks. You may be particularly interested in these systems: http://forums.bistudio.com/showthread.php?151680-FHQ-TaskTracker http://forums.bistudio.com/showthread.php?100731-Taskmaster-2 I have not personally used them, but they seem to fit your needs perfectly. There are several good beginner's guides for the editor, but most are for ArmA 2 or 1 and do not contain information about the task modules (as they are new to ArmA 3). You may also be interested in BIS functions for creating and managing tasks; they can be found in the functions view in the editor with names starting with 'task*'. If you need specific help for implementing any of those functions or systems, it may help to post more details about your mission.

I am not an expert in what can be done with C++ dialogs, but you might be very interested in this: http://forums.bistudio.com/showthread.php?150909-MCC-Sandbox-3-Dynamic-mission-creating-tool-for-ArmA-3 However, I think you mean that every player has such a dialog for commanding their AI in more detail with multi-step plans. The mod linked above seems to (I have never tried it) allow only a single person to control everything. It also includes a lot of features that are superfluous to simply commanding the AI, but going by what is done there, I would say that a system such as you roughly described is very possible (and does not necessarily need to made by BIS). I do know a lot more about locality than I do about dialogs, and I would guess that any multiplayer security problems would arise from the design and implementation of the dialog rather than the functions that it generated. Those functions obey the basic locality rules of the game engine. Also, I am going to guess what you mean about AI interacting with server objects. Giving the AI orders in an sqf function does not need to involve any objects at all (except AI objects that are local to the client giving orders). If you mean the AI getting in and out of vehicles or picking up/placing objects, then the designer of this theoretical AI control system would have to test commands such as 'orderGetIn' and 'action' when they involve objects local to the server. The functions generated by this supposed dialog would only give the AI sensible actions to perform that would be equivalent to what a player could do (fly a helicopter at a certain altitude for example). A player would only have access to certain commands that could not be used to cheat, grief, etc.