loyalguard

This thread from 2010 should get you pointed in the right direction. Make sure you read the whole thread! There is some good discussion on modules vs. mission scripting vs. just using a logic to execute your scripts It's for A2 but it contains the same concepts for setting up your module as an addon. You will need to change the requiredAddons, class inheritance, icon, picture, and probably other portions of the config to make it work: http://forums.bistudio.com/showthread.php?98880-How-do-you-create-a-module I would recommend looking at the module config(s) in A3 to figure out what you might need to change, inheritances, etc. Here is a link on the SIX config browser (Make sure A3 is selected): http://browser.six-projects.net/configclasses/CfgVehicles%3EModule_F/config?version=67

I recommend using extended event handlers (XEH), which is part of CBA. Not knowing what your addon does (adds a new vehicle or justexecutes a script(s) or both, it is a little hard to tell you which XEH to use or how to set it up in your config, but XEH is the best way to avoid conflicts and adds more flexibility in when and where you want to run your script(s).

That is most likey the issue. For example, if you have a trigger that activates when there are no enemy left inside a trigger's detectiona area, when a new player JIPs that trigger will activate (since triggers placed in the editor are present on all the server and all clients) because the condition would be true since their would be no enemies inside the trigger area. Performing a local check may or may not work (it depends on the condition), but I would lean towards it would not work. Are you making tasks complete as well when the triggers activate or just playing audio? The solutions depends on what else happens when the trigger activates.

rAddAction was part of the old Multiplayer Framework which appears to have been revamped for A3 and no longer works the same way. BIS_fnc_MP has replaced it for remotely executing code (you can look it up in the functions viewer (or in this post) for details on parameters and such). You could use BIS_fnc_MP to add the code to all the clients, but just note you would have to create your own function that added the addAction to the vehicle and load it into memory first. You could also try setVehicleInit and processInitCommands after you create the vehicle which will broadcast it across the network to it will be added on all clients. Lastly, you could also try public variable events handlers and publicVariable to tell the clients when to add the action to the vehicle.

Loved DevCon for A2 and very happy to see it in A3!

outside of the init line, you have to refer to the unit specifically. Substitute this with player and see if that works, such as: _action1 = player addAction ["Check Hunger and Thirst Levels.", "check_foodwater.sqf"]; _action2 = player addaction ["Heal Self.","heal.sqf"];

We will probably need some more details about your mission. Here are some questions consider in the meantime? Do you have a lot of loops or uses of waitUntil in your mission? Do you use publicVariable a lot (especially in conjunction with loops/waitUntil)? How many AI units are involved?

Tajin pretty much covered everything. Here are a few additional comments. The method Tajin described in his response to question 1 (using pubicVariable and public variable event handlers) is one way of making them global and as you note you can also use the MP framework. BIS_fnc_MP in itself is fairly simple, but what you do not see outright are the other functions it uses to make the code global. It uses publicVariable and related commands to accomplish this, but you do not necessarily have to use publicVariable yourself separately to make it work. If you are creating a mission, using the MP framework is a very good way to make sure the results you need get to the machines that need it, it is not require however. As Tajin noted, some evernnt handlers are local and should be added via addEventHandler. There are certain MP event handlers that must be added with addMPEventHandler. This article link and jump describe which must use the MP version: https://community.bistudio.com/wiki/ArmA_2:_Event_Handlers#General_MP_Note

There is no one significant definitive source on locality. It looks like you have been looking in all of the right places. One particular Biki article that definitely helped me start to piece it all together is this one: https://community.bistudio.com/wiki/6thSense.eu:EG If you have not read it, please do! There is also a corresponding forum thread if you have not seen that either: http://forums.bistudio.com/showthread.php?65604-ArmA-(MP)-Scripting There is also this article: http://community.bistudio.com/wiki/Locality_in_Multiplayer As far as locality goes, one of the key things to be familiar with when looking at commands in the Biki is the effects locality icon you will often (but not always) find in the upper left hand corner of the article: If the icon has a E and then either a "G" for global or "L" for local effects. Please note there is often an arguments icon as well do not confuse the two. If the icon has a "G", it means that effects of this scripting command are broadcasted over the network and happen on every computer in the network. If the icon has an "L", it means that effects of this scripting command are not broadcasted over the network and remain local to the client the command is executed on. Unfortunately, not every command has an icon, but for the most part it is a reliable way of determining the effects of a command. Here are some attempts at answers to your questions (not necessarily in the order you asked them.): If a server executes a script the results/effects are broadcasted to all the clients only if the commands in the script have global effects. Otherwise the results only stay on the server. Using createVehicle for an example, if the server executes it, will create the vehicle on the server and then broadcast the results (i.e. a new single vehicle) accessible to all since it has global effects. It only creates one vehicle but everyone can see it and interact with it. Just to clarify, some scripts can be explicitly run locally because they only contain commands with local effects. You can also prevent certain scripts and commands from executing by using isServer or isDedicated or !isServer or !isDedicated condition checks to ensure they only run on servers or clients, but this is more to prevent duplication of effects by preventing commands with global effects running on multiple machines (such as createVehicle on a client and server both being run and resulting in two vehicles). So, createVehicle only run on a client would still produce a vehicle visible/accessible by all clients. The game engine's netcode would handle how effects are broadcasted, but again, if code is run concurrently and has global effects, it would duplicate on all machines. Actually, it is probably more appropriate to say that scripts are functions that do not return data as opposed to functions being scripts that do return data. Here is a quick breakdown on the differences between execVM, spawn, and call (also see this article: https://community.bistudio.com/wiki/Script_(File)#Execution execVM - Load a script from a sqf file and execute the code within via a new processing thread running in parallel to the executing instance (script or command that executes it) and does not return a value. spawn - executes code that follow it in between { } in a new processing thread running in parallel to the executing instance. It cannot return a value. Functions the same as execVM except the code does not need to be in a separate file, it essentially creates a new script without a separate file. call - executes a function that has already been compiled. The executing instance halts until the function is completed. It can return a value (but it does not have to). Yes, but if the server needs to know about some or all of the results of the scripts on the clients and some or all of the commands in those scripts are local, then the server will not have that information. Regarding not being able to run a server and client on the same machine, see this thread with instructions on how to possible do this: http://forums.bistudio.com/showthread.php?147537-Tutorial-How-to-run-ArmA3-server-on-a-dedicated-server Long story short, this is a trial and error process. Multiplayer scripting can be difficult and locality is the the factor most pertinent to its difficulty, but it can be overcome. Good luck!

This is possible to code via scripting and only using vanilla objects so that the mod would not need to add new objects. But, if you wanted these options to be available for multiple missions you will still need to create an addon/mod to ensure the scripts would run across all missions or you would have to include the scripts in every mission specifically for which you wanted to have this capability.

The SIX config browser is a great way to see the names of all of the available classes. Here is a link showing the whole class tree. Make sure ArmA 3 is selected in in the box at the top: http://browser.six-projects.net/cfg_vehicles/tree

Just try "StreetLamp" instead of individual class names. I will eventually port my ArmA Electrical Grids (Script Pack and Addon) to A3 which will make blackouts like this automatic, but it will probably not be for a few more months.

I am not sure if you copied and pasted from your actual script or retyped your code here, but you are missing thread handles in front of execVM which could be causing the problems. e.g. null = [] execVM "taskb1.sqf"; Have you tried this? _mission = switch (random floor(4)) do { // Main objective: Capture case 0: {null = [] execVM "taskb1.sqf"; }; // Main objective: Destroy case 1: {null = [] execVM "taskb2.sqf"; }; // infiltrate case 2: {null = [] execVM "taskb3.sqf"; }; // Supply case 3: {null = [] execVM "taskb4.sqf"; };

First, I just found a typo in the code I gave you. Change "for each" to "forEach". I corrected it in the example I gave earlier but I wanted to point that out first. If the script is in your main mission folder it should be executing. Here are some things you can do to debug: 1. You said you were seeing syntax errors so I assume you have -showscripterrors active, but I just wanted to make sure.2. Try a hint as the first line of the script to make sure it is actually executing such as hint "Script Executed"; 3. Try putting () around getPos _x. e.g. (getPos _x). 4. Take out all of the comments to include the / or //. 5. You can also use the command diag_log to dump info to the .RPT file. Give those a shot and see if that works.

For your first question, what would be put in the common folder, there are probably scripts or functions (or both) in there that run on servers and clients, so they are "common" to both of servers and clients.

Ah, I did not know this was trigger activated. The best thing to do would be to save the code I gave in you in a seperate script file called bombLoop.sqf (or something similar) saved in your mission folder and then in your "On Act" field enter the following: null = [] execVM "bombLoop.sqf";

The problem is that the script will not automatically turn the number value of "i" into the "i" of portion of "t_i". Each iteration of the loop it justs sees a variable names "t_i" instead of "t_0", t_1", etc. which obviously do not match the names of any of your logics. There is a way to dynamically create variables that point to your logics, but the simpler method (eventhough it is a little more brute force) is to do the following: _logics = [[color=#3E3E3E]t_0, [/color][color=#3E3E3E]t_1, [/color][color=#3E3E3E]t_2, [/color][color=#3E3E3E]t_3, [/color][color=#3E3E3E]t_4, [/color][color=#3E3E3E]t_5, [/color][color=#3E3E3E]t_6, [/color][color=#3E3E3E]t_7, [/color][color=#3E3E3E]t_8, [/color][color=#3E3E3E]t_09, [/color][color=#3E3E3E]t_10, [/color][color=#3E3E3E]t_11, [/color][color=#3E3E3E]t_12, [/color][color=#3E3E3E]t_13]; // Create an array with the names of all of the logics. [/color]{_bomb = "M_Mo_82mm_AT" createvehicle getpos _x; sleep 1;} forEach _logics; // Create an explosion at the position of each logic with a one second delay (change the number after sleep to change the delay). I hope this helps. Good luck!

I know this is an obvious question, but have you confirmed that the script does not delete the projectile whenever diag_log prints <NULL-object>? I only as because to me it seems that diag_log is printing <NULL-object> because by the time it gets to actually output it to the log the projectile has already been deleted and appears to be null (even though you use the diag_log command before you actually delete the projectile. FYI, just a small tip, I recommend using the in command when doing your conditional check to make your code easier to maintain in case you want to add or delete weapons. Example: _weapons = ["LMG_Minigun_heli", "missiles_DAGR", "CMFlareLauncher", "M134_minigun", "missiles_DAR", "SmokeLauncher", "GMG_40mm", "HMG_Mk30", "LMG_Minigun"]; if (_this select 2) in _weapons then { if ({(_this select 0) distance getMarkerPos (_x select 0) < _x select 1} count SAFEZONES > 0) then { deleteVehicle (_this select 6); titleText [FIREMESSAGE, "PLAIN", 3]; diag_log("shotsFired: " + str(shotsFired)); diag_log("DELETED: " + str(_this select 6)); }; };

Check out this thread with a similar question: http://forums.bistudio.com/showthread.php?124003-How-to-make-a-vehicle-start-moving-when-you-begin-mission

As far as I know, support has not been canceled, but BIS does not want to implement until it is ready: http://forums.bistudio.com/showthread.php?146924-ARMA-3-Alpha-Java-Virtual-Machine&p=2305403&viewfull=1#post2305403

Here is are some links that may give you some ideas: http://community.bistudio.com/wiki/Java_Scripting http://forums.bistudio.com/showthread.php?128800-Take-On-Java&p=2075796&viewfull=1#post2075796

Those commands are listed in the post 1.62 beta builds and are listed among the available A3 commands: https://dev-heaven.net/projects/cmb/repository/revisions/745d0efc55f45da299f167b03ca16d4422aacb99/entry/scripts/A3/diffs/supportInfo.sqf So they should work in A3

I have never used these commands, but profileNamespace and saveprofileNamespace might be able to accomplish what you are looking for. These were initially implemented in TOH, then later in A2OA, and should also be in A3. What they do is save a variable to your profile that would persist after you log off and then reload when you log back on. This thread can give you an idea of how it works (it is from TOH but should still be applicable): http://forums.bistudio.com/showthread.php?122995-profileNamespace-how-to-use Here is an example of how it might work: // Give the player $100 and save that amount in a variable called "money" in the player's profile name space. profileNamespace setVariable ["money", 100]; // Save all the variables in the player's profile to a file in case the player disconnects.logs off. saveprofileNamespace; //Find out how much money the player has. _currentMoney = profileNamespace getVariable "money"; // Should return 100. //Give the player $10 more dollars. _currentMoney = _currentMoney + 10; profileNamespace setVariable ["money", _currentMoney]; // Save all the variables in the player's profile (again) to a file in case the player disconnects. saveprofileNamespace; Make sure you see the warnings about usting saveprofileNamespace too often as it uses a lot of resources.

That is something that BIS is looking into but not yet implemented. There are several threads on the topic if you search to see the latest status.

Welcome to the world of ArmA scripting. In addition to the very good advice above from tryteyker, I highly recommend opening other people's scripts so you become familiar with the variety of commands and their functions. This is how I first started getting into scripting. One of the best BIKI pages for more info of those commands is Scripting Commands by Functionality which as you can tell by the title groups the commands by their particular functions.