igneous01

If you need to get the clientID when doing a remoteExecute on the server, the best method is to pass it in as a parameter like so to remoteExec, just before the code is executed on the server: [clientOwner, {_clientID = _this; ...}] remoteExec ["bis_fnc_call", 2]; This example is one way, there are other ways of calling remoteExec that don't rely on bis_fnc_call. You would only use bis_fnc_call on anonymous functions/code that is not defined globally for example. This is how I implemented global events and remote handlers. If you have multiple admin scripts that you need access to, you could do something like this with IGN_EH: IGN_EH if (isDedicated) then { // create an AdminCallRequested event, with parameters ["fncName", clientID, params] SERVER_EVT_AdminCallRequested = [["", 0, [] ], "SERVER_EVT_AdminCallRequested", true] call IGN_fnc_createEvent; AdminCallRequestedHandler = ["SERVER_EVT_AdminCallRequested", { params["_fnc", "_clientID", "_params"]; // use your method for validating the client has permissions to run // if _fnc is a valid function on server call compile format ["_adminFnc = %1", _fnc]; // this will strip the quotes off _fnc, so that "MyFunction" becomes MyFunction _data = _params call _adminFnc; // get some data and return it to remote caller _data remoteExec ["hint", _clientID]; }] call IGN_fnc_addEventHandler; }; // somewhere locally on a machine... ["AdminGetSectors", clientOwner, [someArgs, 0, ...] ] call IGN_fnc_raiseEvent; This will create a global event that the server owns, with a server side handler. When a client raises the event, the server handler takes the clientID passed in and can do some validation to ensure the proper client has access. It's a somewhat contrived example, as it's not completely secure, since all clients are aware of the event and can register their own handlers or raise it. But this should hopefully give you some ideas for getting what you want done.

I am proud to present a new framework for mission makers to use. Thanks to the initial feedback, the framework was rewritten to utilize the latest scripting commands added for improved performance, as well as proper MP support with broadcasting / global events. Global events can be raised from any machine, and handlers registered to on client machines are remote executed when an event is raised. JIP is still being looked into for integration. IGN Event Framework gives mission makers custom event support, being able to define events, add handlers, and raising events. The framework was originally developed back in 2014 when I released Tiger Shark on the steam workshop (which heavily used it for updating tasks and controlling mission flow). Most of the 'pilot xxx' missions on Steam Workshop also use this framework. Download: http://www.mediafire.com/file/6c5o9louso1583o/IGN_EH_v1_1.zip The download comes with demo missions, documentation, and in 2 flavors - the typical scripted approach, and CfgFunctions approach, with instructions on how to install using both. There is also debug mode support, Documentation is included with a list of all calls and explanations for each in the Docs folder. There is a manual.pdf included, but it's not complete by any means. There are also some functions for creating functors/function objects, but this is still work in progress. Changelog: v 1.1: - added path parameter to IGN_EH_INIT.sqf, which lets you specify the path where IGN will compile scripts from. Useful if you wish to move the folder to a different directory. - compileFinal used instead of compile - rewrite of all functions to utilize new scripting commands (push, params, etc) - added proper MP support with global events and remote handlers - added new demo mission IGN_EH_MPDemo1_DedicatedServer.VR which showcases using events on dedicated server with clients - updated documentation v 1.0 - Initial Release Demo Missions: IGN_EH_SPDemo1.VR - a mission with 3 tasks using the traditional scripted approach IGN_EH_SPDemo2.VR - same mission, this time using the CfgFunctions approach IGN_EH_MPDemo1_DedicatedServer.VR - same mission, tweaked to use both Global and Local events Please feel free to leave feedback and any bugs encountered using this.

Updated to 1.1 I was looking into locations, but they are seriously hindered by the fact that publicVariable wont support them. In fact to use locations on a global event each client would need to have it's own local copy of the same event with manual updating each time, which is what publicVariable helps address. The call compile format was removed, but it had its uses: Reasoning for using call compile format ["%1 = _this", _name]; This allows you to create an event, without having to specify a global variable AND the string name to match. With it, you can do the following: [[], "SAMPLE_EVENT"] call IGN_fnc_createEvent; hint SAMPLE_EVENT; // this variable is now available In my opinion this keeps things more consistent rather than having the variable and the string match exactly. Which introduces fewer bugs. But for now it's been removed for obvious reasons. Thanks to everyone for the initial feedback, keep it coming!

you're right, sorry my mistake. Well, initially it looks like I've duplicated existing code that BIS created, so I'm in the process of rewriting it (and add proper MP support). I do have a few questions for the mp scripters out there: 1. What happens if you have a function (that returns a value with call) that has checks for (isServer)? If you call the function, then all client machines will call it as well (assuming you are not doing if(isServer) call fnc) but in this case, only the server will return a proper value? I want to say that this should probably be avoided if someone forgets to wrap a call with isServer. fnc = { private _obj = locationNull; if (isServer) { _obj = createLocation[...]; }; _obj; // client will get locationNull? }; 2. is createLocation global, or local? There's no mention of this on the biki. 3. would this invoke a broadcast? _event getVariable "handlers" pushback [clientOwner, _handle]; publicVariable _event; 4. Is there a need to be able to register a handler from a client machine to a server event? 5. Is there a need for a client to be able to raise a server event? 6. Is there a need for a client to be able to raise another clients event? So far I have a broadcasting event, and a normal local event, but I'm wondering if there's more that's needed?

don't worry about it, if people are willing to criticize it this much, that means that there is a need to have a robust library for doing these sorts of things. :)

BIS_fnc_addScriptedEventHandler only lets you register to predefined events. If you needed to define your own event, it will not work. Think of this as more than just Event Handling - this is signal and slots / observer pattern support for missions. If you need to notify multiple entities that something has happened, it makes sense using this lib.

Yes, it uses some old scripting commands (I'm getting up to speed on all the new ones they added, especially the collection commands for pushback and sort). This library will be maintained, so I'm glad dedmen is being honest here, because that's what I was looking for if this is to be something widely accepted by the community. Dedman: I'm glad you mentioned location - but how would one associate new instances with locations (which I believe are static)? I'm also glad you mentioned MP - you're right that remote exec is not here (yet), so far just some local based event creations. IGN_fnc_createEventServer is the most well defined because it does a setVehicleVarInit and publicVariable so that it broadcasts across mp. The local ones with remote exec is still something to be done. This is still in its infancy, however I will be releasing some updates to this (adding support for routed events for UI) when I release my dialog framework script (which relies on this). Dedman, if you have any other concerns please voice them, so that I can properly address them.

Are we able to create this control in our dialogs defined in description.ext ? Whenever I try to create a control of this type I receive a message in .rpt that says: 'Do not create it this way' I'm assuming this is reserved for internal use by developers only, similar to treeview?

Thanks for the link, I have most of these control types mapped out already, but some like TreeView and ContextMenu were reserved (Atleast, Treeview used to be in Arma 2). Was curious if ContextMenu can be instantiated via scripts, looking on the wiki showed some properties and an example, but it looks like this can't be created (it's not in Karels template mission either). I'm glad to hear that TreeView is available to us now though ^^

It's very possible in this context, especially if sqf commands are not atomic. Anything that is threaded that doesn't require locks or atomics can be run truly concurrent on a multi-core system. Back on topic, adding event handlers to the queue makes me believe that this is not threaded in any way. One reason being that it's difficult to get performance out of it, and second that threaded calls to handlers would cause the handlers all to be in separate threads, and handlers can access global variables which reside on the main stack. If that were the case, threading the handler queue would absolutely destroy performance, and cause concurrency bugs in the engine (which none have been observed so far). You can safely bet that handlers will be called in order as they were registered to the event.

Is there a list I can find anywhere that contains all font types and styles that are supported in dialogs? Since there is a lot of documentation about dialogs still missing, is there a file I can comb through to see all definitions for the various controls?

That's the issue, the search on the wiki doesn't work well. Not all controls are fully documented.

Thank you both for the help, I really appreciate it. austin_medic - how did you find this page? I was searching the wiki for font and it always returns no results. The search is so broken that any case mismatch returns 0 results. Are there other undocumented pages such as this one that exist? Perhaps an explanation of the undocumented properties certain ST_STYLES have or CT_TYPES that are not supported via scripting? (TreeView, Key, Static Skew?)

Here is something i recently finished. This script randomly spawns enemy units in a random position (or positions) you define. These newly created groups will then move to a waypoint location that you specify as well. The types of forces this script spawns are random with a percentage chance of being spawned. For example, Infantry might always spawn (100% chance) but the number of groups that are spawned may differ (random of max 10 groups - you can define this as well inside the script) so you can specify and customize whatever types of units you want it to spawn, it supports custom factions as well, all you have to do is add that faction classname into the script (template already inside), and fill the arrays with the classnames of the groups there (individual units will not work) You can adjust the amount of waves the script will produce (1 wave = 1 iteration of the script spawning stuff) You can also adjust the timer before a new wave begins (old units that are alive will still stay on the field, but dead units and empty groups will be deleted to preserve cpu and space) - thanks demonized for the empty group feature This script is Multiplayer compatible, works with both dedicated and listen servers (however the host will probably be lagging quite a bit with this script) How to Use: nul = [RUguy, [spawn1, spawn2, spawn3], attackwp, spawntimer, Scripttime] execVM "RUIS.sqf" where: RUguy - The name of a unit on the field, the script will take this units faction and side and spawn units of this type, works with BIS_US, USMC, RU, TAKI_INS, and Taki Army [spawn1, ..... ] - the spawn locations on the map (best to use gamelogics with names here) attackwp - an object or gamelogic where the units spawned will move to spawntimer - the amount of time to wait before spawning new units (in seconds) Scripttime - the amount of waves you wish the script to run link: mission example (UPDATED**):http://www.mediafire.com/?0wye5wxtgt69z47 Script: maybe some people will make use of this - I know ive needed this a few times

hey all :D after many sleepless nights and lots of rockstars i have finally managed to finish part of my campaign. I am deciding to release it now so that people will have a chance to play through the missions and provide some feedback for more missions, while i work on the other ones. I know some people have been asking and waiting for something like this, but fear no more! snipers are here and missions are galore! (well not really galore, but its getting there ;)) This campaign tries to focus on realism, so its not a sniper kill a hundred guys kind of thing. I used various ideas for the missions and made it challenging enough to keep it interesting. While some missions dont look or have a realistic setting, i tried it keep it as fair and balenced as possible between some fun and some real. feedback and suggestions appreciated, also report any bugs you find. Single Player Only, i may incorporate it as coop in the future. ====TEAM SHADOW (0.93)==== created by: DZ (Igneous01) Description: Team Shadow is a realistic campaign that focuses on a sniper team call sign shadow. It takes you through the war in Chernarus where Russians have invaded and progresses through the war with ops in all different areas. The missions are quite diverse, considering its just a two man team, ranging from target elimination to reconnaisance, counter sniper operations, ordering support and surgical strikes on high value areas. Also features training missions to help prepare you for whats expected in the field. Features: - precise control of your ai team mate - use the radio commands to make the ai never fire, even if you team switch, as well as disabling their movement when you want them to be still in a tight situation. - Diverse missions ranging from about everything a sniper team can do in real life - Realistic presentation of a sniper team - Task hints, sound effects, briefings, and all the other good stuff polished - Range Me script, use the scroll action to get your ai to give you a quick range reading, if your spotter dies you will no longer be able to use this function - gear selection - choose the right weapons and equipment for the job - 3 training missions to help you on your way - Spotting Mode (**NEW) watch your own follow through when you take a shot, useful for longe range shots where you cant see the dust Notes: - Currently there are 8 missions in this campaign, but i plan to expand on this with many more missions in many different parts of the map, the more people request missions, the quicker it will be done!!! - The missions are fairly long, so saving is advised - This campaign focuses on the real aspects of being a sniper - that means that for a majority of the time - youll be on your belly crawling around from bush to bush to get around. Stealth is key in all these missions. - Be Patient, rushing and getting ahead of yourself will just cause bad things to happen, like getting spotted and gunned down - Accuracy is extremely important in this campaign - In most of these missions you will only be allowed to carry one magazine for your weapon, that means you really need to think about who you shoot, wasting ammo on grunts will only cause bad things to happen, like getting spotted and gun down, as well as having no way of taking out your real target - Sidearm is your friend - Learn how to use a pistol in those times when things get heated up - Position is everything - While it might seem like fun challenge trying to kill someone 1000 metres away, if the weather doesnt permit it, and theres better options in getting closer, its better to take the safe route and make sure that what you kill is on the first (or second) time around - Notice theres alot of smoke grenades available when you select your gear - its your best friend when you gotta make a fast escape from certain death Feedback: All feedback is highly appreciated, if you spot any bugs let me know, if you can repro any serious ones that would help me out alot as well. Also suggestions on mission types would be very helpful to me, those that have more knowledge about real snipers should definitly voice their opinions on some missions and material to work with. Installation: Extract and move to your arma 2/campaigns folder Known Bugs: - Some missions dont have a picture to show - paint can be quite limiting at times Future Features: - More Missions - Implement BIS Range Call function to replace the range me action - Different Ghillie suits to better match the mission environments - Weapon addon compatibility - More gear to choose from - Spotter smoke screen action Requirements: - Arma 2 Combined Operations - CBA - ACE, ACEX, ACEX_RU - MAP_EU Included Files: TeamShadow_Campaign.pbo readme.txt SniperFAQ.txt Credits: Monsada - UPSMON Script GLT Myke for his help - without him alot of this wouldnt be possible Draper - Air Support Script SHK - For his move objects script ACE team - for the wonderful features And everyone else that I forgot to mention Changelog: 0.92 General: - Added Spotting scope to gear pool (was missing because of USNavy) "Invisible Man" - Fixed timer on GIVER's arrival, it is now at the appropriate time (45 minutes) 0.93 "Becoming a HOG" - Removed scripting hints from mission "Guardian Angel" - Removed Ace_Wounds to fix problem with gear selection - Adjusted enemy numbers to better balance forces - Repositioned helicopter crash and removed excess smoke to allow better visibility and places to fire. General: - Added new mission "Patrol" - player will now return to stealth behaviour when using radio trigger never fire - Fixed range me script condition - if the spotter dies it will become unusable - Added missing radio trigger options in some missions LINK TO FILE link1 (7z): http://www.4shared.com/file/gfoPj7hO/TeamShadow_Campaign.html? link2 (rar): http://www.mediafire.com/?pvm0ncdxjeyrzhc armaholic: http://www.armaholic.com/page.php?id=13779

TIGER SHARK V1.2 Tiger Shark is a collection of randomly generated missions for the mi-48 Kajman. Your crew is on call for today... what will command have in store for you? http://cloud-2.steampowered.com/ugc/794065437397819834/BE5510E0A706B026915622F6DCFF37B2011D81A2/ (127 kB) Mission Types: - Convoy Interception - Close Air Support - Insertion - Hot LZ Extractions - Search and Rescue - If you are shot down, command will send a SAR team to find you and pick you up (player SAR mission) Features: - (NEW) Mechanical Failures: Possibility for failures to occur and cause damage to your chopper. - (NEW) Custom Chopper Damage handling: Engine damage reduces your ability to gain altitude (compounds with more damage), including engines smoking/fire - (NEW) Options Menu at start of mission for more control over what you want - Randomly generated mission - positions and types are randomly selected from a large collection - Spawning/Despawning of Infantry AA - theres quite a bit of AA on Altis, so fly low! (need feedback on AA difficulty) - Sometimes the enemy might call for reinforcements... like a Jet to come shoot you down - you'll need to eliminate the enemy quickly and try to escape before the jet can intercept you - Units spawn with no lag (executes on another thread) - Missions auto clean-up when finished, sending unneeded groups/units to the garbage collector - friendlies drop smoke on extraction missions - more authentic vehicle servicing (thanks to Jacmac) - SAR: enemies will try to get to the crash site as fast as they can, so you need to move quick to finding those pilots - Random Day/Night Cycle - Random Weather/ Random Forecast 1h later - Player SAR: Defend and hold your position - sometimes enemies might go to your crash site to eliminate survivors! TODO: - Random Air/Vehicle Patrols (not related to any mission) - Weapon Loadout GUI (change out missiles) - Replace gunner if only he is killed - Base/Outpost Raid Mission - Nicer Display alternative to hints - conversations Known Issues: - Sometimes CAS targets will spawn in bad places, causing them to be destroyed (completing the mission to early) or calling reinforcements... (not common) - Enemy infantry sometimes spawn in water - Chance that the player down mission will activate at the same time as another mission, corrupting one of the missions (rare and investigating) Feedback: If you spot any bugs, or have any suggestions for improving this mission, then please post here. Credits: Generic Vehicle Service Script - Jacmac Inspiration and a starting point for this mission - Wibbler INFO: Built using Arma 3 Release Build Version 1.14.116248 No Mods Required Please give feedback on mission performance in developer build. Download: Steam Workshop: http://steamcommunity.com/sharedfiles/filedetails/?id=245321376 Armaholic: Tiger Shark link 1: speedyshare link 2: mediafire

Strange... Is there anything logged in the rpt file? I've had no issues latest stable patch (non-dev however). Maybe something was broken in the scripting commands?

looking really good! can't wait to try it out

From what I have read of it, the turret and some other components are modular. That slow auto-loader gun might be swapped out for something more practical for urban environments like a 30 mm cannon. Although I don't really see urban and IR masking mixing very well, because the engagement range of typical AT weapons in an urban area will probably be at most 1 km (like a highway), infantry would probably already have visual confirmation of the vehicle, without having to resort to IR. Although in a hull-down position, it would probably have more use. If it had troop transport capability then it might be more versatile, masking the IR while driving to the insertion point would probably increase its survivability.

you shouldn't use spawnvehicle to spawn ai units, spawnvehicle only works with vehicles use createUnit or BIS_fnc_spawnGroup

Ill try my best to answer some of these: 1) Generally, when you load a dialog, all controls are shown - you can however hide certain controls using a few methods: a) onLoad display handler - you specify in your dialog class a handler for when the display is loaded, hiding your controls in preferably a separate script: class myDialog { onLoad = "_this execVM 'onLoadInit.sqf'"; //... etc } onLoadInit.sqf _display = _this select 0; // onload sends [display] as argument ctrlShow[3001, false]; // assuming that the idc of the control you want to hide is 3001 // keep doing this for all other controls // or { ctrlShow[_x, false]; } foreach [3001, 3002, 3003, 3004, ...]; b) In the script that creates the dialog - immediately after creating the dialog, you can use ctrlShow to hide the specified controls there, this would probably be easier, but you might see the controls flicker when you open up the dialog. (onLoad handler executes just before the gui is displayed, where as hiding it after createDialog causes the gui to show first, then hide the controls) 2) Parent is simply that - the parent of the control/class. A parent can be the base class you are inheriting from, or it can be the class that contains the child class. Example: class Parent { class Child {}; }; class Parent2 { class controls { class myControl {}; // this is a child of Parent2 - because Parent2 contains myControl within itself }; }; class Parent3 {}; class Child2 : Parent3 {}; 3) from what I understand, the problem here is that action is a string, so you have to use "" "" or ' ' to wrap nested strings inside: action = "ctrlSetText [2503,'data\checkedBox.paa'];" 4) this command exists as a workaround to the limitations of variable assignment/setVariable for control and display types. From what I understand, controls and displays cannot be serialized within the engine (but I assume all other data types can be) so in order for the engine to communicate with your script, it needs to be able to read these values. By specifying disableSerialization; in your code, you tell the engine to: a) NOT serialize these variables b) Do not save these script variables when the mission is saved c) when the mission loads, whatever state the script was in is not saved. (may require restarting the script) however be warned - you cannot use setVariable for control or display types - the game will warn you that these types are not serializable, however you can store the control or display in an array. I dont know why -[control]- works and -control- doesn't, but I think its because the dialog aspect is not feature complete in the engine. Do you need disableSerialization? Only if you plan to use variables to reference control and display types (idd and idc numbers dont count)

Visual Studio 2012 - msvc updated to the new c++ standard, but still some things are missing/questionable FL Studio 10 Sibelius 6 OpenOffice Windows Snipping Tool Notepad ++ Sublime Text 2 Adobe Audition GIMP

even without knowing how extended event handlers accepts definitions, I know for a fact that you cannot declare a class with a stringed name. You also cannot declare conditional statements inside a class definition (BIS classes don't support any sort of templating) it should be: class Extended_Init_EventHandlers { class Man { MyCode_init="if (!isPlayer) then {_this call compile preprocessFileLineNumbers 'scripts\briefcaseintel.sqf';}"; }; };

that entirely depends on how you design your mission. I would recommend using one FSM to handle the missionFlow (like missionFlow.fsm suggests) - this would involve creating tasks/when tasks are completed/when to assign new ones/when can the mission end The advantage to this is that if you have a mission that is as complex as lets say 'manhattan' from arma 2, the missionFlow fsm will make it much easier to see the connections made between various tasks and side missions. If you have some sort of scripted behaviour in your mission that is complicated to write, it would be best to do this in a separate fsm - the missionFlow shouldn't handle some unrelated behaviours to an ai unit when its focusing on handling the mission itself. Remember that the goal of FSM is to define and implement behaviours for a specific entity. Mission Flow can be considered one entity, where as scripted ai behaviours would be another.

you can use onMouseEnter and onMouseExit to display the RscStructuredText tooltip, or a rscTitle (but the tool tip will not be surrounded by a box). I would probably recommend using rscTitle, as rscTitle's cannot take focus away from a control (where the RscStructuredText can)