naught

When you call getPosition, you're passing a nil parameter to the object, but since your getPosition object member actually expects an array (look below), it won't find an available member and return nil. So this: PUBLIC FUNCTION("array","getPosition") FUNC_GETVAR("position"); Should be this: PUBLIC FUNCTION("","getPosition") FUNC_GETVAR("position");

/* You can use either this: */ private ["_var"]; _var = [0,0,0]; MEMBER("position",_var); /* Or this: */ #define VAR [0,0,0] MEMBER("position",VAR); And yes, if local paths are fixed (ie. "../") then it would be easier to include files within a mission and make it feasible to include a header in each file, but the array-comma issue in macros is a problem that would just slow the preprocessor down for close to no benefit since other alternatives are available.

No it shouldn't cause any issues with performance or stability. If you're not planning to use a headless client, then the script will work with UPSMON as-is. Otherwise you'd have to define a function (#define CACHE_UNIT_SPAWN_FNC {func}) in the config.sqf to run when a group is transferred over to the HC, like this: #define CACHE_UNIT_SPAWN_FNC {_this spawn UCD_fnc_newUnitSpawn} // Should remain small, will be sent to all clients on mission load UCD_fnc_newUnitSpawn = { uisleep 1; // Wait for group transfer and processing if (isNil {(group _this) getVariable ["UPSMON_grpid", nil]}) then { [(leader _this), "dynamicPatrolArea", "spawned"] call compile preprocessFileLineNumbers "scripts\upsmon.sqf"; }; }; call compile preprocessFileLineNumbers "scripts\Init_UPSMON.sqf"; // Remember to load UPSMON in here too To tell you the truth, I have no idea if the above code will work, or maybe UPSMON works with this script and headless client(s) out of the box - you'll have to test it out though. If the transfer works quick enough the UPSMON shouldn't detect that the group all died and respawned, but it may also have locality checks that would stop execution.

Yes it would make the code look more natural, but then you wouldn't be able to pass arrays unless you define them as a variable prior, which would be wasting memory (macros can't take arrays as parameters because they contain commas). Also it would require including the "oop.h" file in every script that called the object, and I was hoping to be able to keep the layout of including the "oop.h" file only where objects/classes are defined, so they can be created, accessed, manipulated, and destroyed anywhere after that with normal SQF syntax. Not to mention the include system is totally broken with a non-working #include "../file.sqf" command. And although I can just add those macros to the "oop.h" file to be used as a shorthand alternative, I feel like it would create more confusion than benefit (especially with the whole no-array thing). But good idea nonetheless, I'd love to be able to simplify the syntax a bit if possible.

It shouldn't interfere with pre-placed waypoints since those are global to the group, but any dynamic scripts like UPSMON may break.

http://forums.unitedoperations.net/index.php/topic/21527-ai-caching-and-distribution-script/?p=264381

Sorry for the long wait, I subscribed to this thread but never got a notification that you had posted... Weird :P Anyways it works as intended, since calling a variable member with a nil parameter makes the member macro retrieve that variable's value - as I'm sure you know. But when the variable isn't initialized (static variables only need to be initialized once, while normal variables will need to be initialized each time an object is created), it will return nil, so this code would be necessary (and it looks like my example doesn't work the way it should haha): #include "oop.h" CLASS("PlayerInfo") PRIVATE STATIC_VARIABLE("scalar","unitCount"); PRIVATE VARIABLE("object","currentUnit"); PUBLIC FUNCTION("object","constructor") { MEMBER("currentUnit",_this); private ["_unitCount"]; _unitCount = MEMBER("unitCount",nil); // Retrieves value if (isNil "_unitCount") then {_unitCount = 0}; // Initializes variable on a one-time basis _unitCount = _unitCount + 1; // Increments variable MEMBER("unitCount",_unitCount); // Sets variable back }; PUBLIC FUNCTION("","getUnit") FUNC_GETVAR("currentUnit"); PUBLIC FUNCTION("","setUnit") { MEMBER("currentUnit",_this); }; PUBLIC FUNCTION("string","deconstructor") { DELETE_VARIABLE("currentUnit"); private ["_unitCount"]; _unitCount = MEMBER("unitCount",nil); _unitCount = _unitCount - 1; MEMBER("unitCount",_unitCount); hint _this; }; ENDCLASS; _playerInfo = ["new", player] call PlayerInfo; _currentUnit = "getUnit" call _playerInfo; Anyways I just fixed the example in Github too - thanks for bringing this up to me.

Yes, the caching aspect would still increase performance, especially if you host it and play it on the same PC. Also, so everyone knows, I'm currently finished with and testing a new version which should fix a few issues with the script (ie. magazine message, AI leaders fleeing, etc.) and it should be out soon. ---------- Post added at 14:59 ---------- Previous post was at 13:03 ---------- Updated to 1.0.2.2 - v1.0 RC 2 I told you that this one was coming really soon! Thank you all for your patience on a stable release (especially Foxhound). :) This is a full-release, but does not contain a guarantee of any type of support. Bugs and other issues should have been found and patched through testing, but are still possible in the RC. If you find one, report it back in this thread or on the Github issues page. This release candidate has been deemed stable enough to be used in production environments. Proceeding v1.0 updates should be sparse, should contain nothing major, and should not be mandatory. Download Unit Caching and Distribution System v1.0 RC 2. Changelog 1.0.2.2 [FIXED] AI no longer flee when their group is cached (work-around). [FIXED] Library linkages now correctly handle others' exceptions. [FIXED] 'No entry in CfgMagazines ...' error has been fixed (due to currentMagazine command). [FIXED] Rewrote the caching functions to check for all exceptions at the correct points. 1.0.1.8 [FIXED] 1.0.1.7 regression which caused caching checks to spin infinitely. 1.0.1.7 [FIXED] Units' volatile shifts to leadership are now accounted for while caching. [NOTE] SSD crashed, proceeding without testing (for now). 1.0.1.6 [FIXED] Possible error in config.sqf with wrong types. [FIXED] Enabled CBA caching of static files for release version. 1.0.1.5 [NEW] Initial public release.

Updated to 1.0.1.8 - v1.0 Beta 8 This is a pre-release version of the software, so expect some bugs or otherwise broken features. This is an incremental release, so it can be seen as a "hotfix" of sorts. It won't add anything major, but it does fix bugs which evaded the bug-testing phase. Note: Unfortunately my previous untested release broke the caching mechanism of this script, so updating to 1.0.1.8 from 1.0.1.7 is mandatory. But if things do go well this should be the last beta update. +Note: A release-candidate should be done soon, so, if you can, hold-off on putting this into a major release mission, or be prepared for a quick update, hopefully fixing many of the issues. Download Unit Caching and Distribution System v1.0 Beta 8. Changelog 1.0.1.8 [FIXED] 1.0.1.7 regression which caused caching checks to spin infinitely. 1.0.1.7 [FIXED] Units' volatile shifts to leadership are now accounted for while caching. [NOTE] SSD crashed, proceeding without testing (for now). 1.0.1.6 [FIXED] Possible error in config.sqf with wrong types. [FIXED] Enabled CBA caching of static files for release version. 1.0.1.5 [NEW] Initial public release.

Yes, you can either throw the contents of the download file (fpsmon.sqf) into the init.sqf or you can execVM the file.

There's no strict datatypes in SQF, so we resort to using basically "prototypes" of the desired data type to retrieve the wanted type name. So just put a true or false in the dataTypes parameter (reference https://community.bistudio.com/wiki/BIS_fnc_param for more information): _directCall = [_this, 7, false, [true]] call BIS_fnc_param;

This script monitors and reports local FPS, all of the headless clients' FPS (averaged), all of the players' FPS (averaged), and the server FPS, instead of just the server FPS (like the #monitor command does). It gives you better insight into the performance of other players and the headless clients.

unit setOwner (owner hcUnit); if (!hasInterface && !isDedicated) then{ hcUnit = player; publicVariable "hcUnit"; };

For now, unless you want to dedicate some time to learning OOP. But when you come from another language, it's almost given that you know at least the basics of OOP, so hopefully that's a large percentage of the serious developer base. When I have some time I'll continue making my tutorials for SQF, hopefully including detailed instructions and descriptions on the use and effectiveness of OOP so anyone can use it properly.

Front-end code (like simple code to move/spawn units, interface with the GUI, interact with the player, etc.) probably won't see a benefit to this because, like you said, it's limited in its scope. But when you start to look at some of the back-end code (for instance CBA, ACRE, TFA, ACE in Arma 2, ALiVE in Arma 3, my caching system), huge data structures start to evolve from these total conversions of what BI had done, and you get programming that just doesn't make sense to do in a functional manner. This is where this script is targeted at, not the simple "let's spawn some AI" or "let's make a system for launching artillery", it's targeted at the scripts that plan to create entire systems from nothing, building upon the basic primitives that BI has laid out for us. So the functionality of this system really depends on who you are and what you do - if you're a simple mission maker, you won't find much use, but if you want to make a good script-based addon you'll see large possibilities for it.

Scripters who come from a coding background other than SQF. Most (and I really mean MOST) other languages strongly focus on object-oriented design, and the programmers who coded in these languages for years are very well-versed in OOP. It helps speed-up design, implementation, and execution, and is really a great tool for people who have learned it. But if you're just scripting in SQF and not any other language, my guess will be that you won't find much use for it unless you want to learn how to code in OOP-standards, which would be a good stepping-stone to learning other languages. The BI developers have been looking for a good OOP implementation for a while now, and they're tried it themselves but it's never been fully functional. ---------- Post added at 12:57 ---------- Previous post was at 12:55 ---------- Thank you Mikie, yes for now all I have up are the two "success stories", the AI caching and distribution one being the best use of OOP, but it is still very complicated. I have a few more projects I need to wrap-up, but once I'm done with them I'll be able to focus on getting the community to higher scripting standards, with OOP and better tutorials.

I won't lie, the basic example is something I coded up in like a minute and I'm pretty sure it was never going to work, it's just used to explain the syntax. Anyways, here's an example on how to implement the hashmap object: https://dl.dropboxusercontent.com/u/25977070/Games/Arma%202/Scripts/Hashmaps.rar I tried as hard as I could to find an appropriate and simple SQF syntax for calling objects, but this is the best you can do within the confines of SQF. Believe me I'd love a more 'natural' syntax. Parameters have to lead the code in a call statement, and this cannot be fixed without a macro of some kind, and for simplicity's sake I wanted to only require the OOP header for where objects are defined. ---------- Post added at 12:20 ---------- Previous post was at 12:18 ---------- He posted that meaning that PHP's implementation is close enough to mine that you can learn one and use it to learn the other - it's the same principles and basics.

Change !isServer to !isDedicated. It does, but then you would have to establish a reasonable timeout period, ie. 30 seconds, for which the server waits for the "hcPresent" variable to change. If it doesn't within that 30 seconds, then you spawn on the server, but if it does you spawn on the HC. That also means you won't have AI for the first 30 seconds of your mission, and what if multiple HCs connect? Only one will be used (although that's an edge case).

Make sure the code is in a scheduled environment, ie. make sure it's either spawned or execVM'd. So try this: [] spawn { for "_i" from 0 to 200 do { private ["_force"]; _force = random 15; "chromAberration" ppEffectEnable true; "chromAberration" ppEffectAdjust [_force / 24, _force / 24, false]; "chromAberration" ppEffectCommit (0.3 + random 0.1); waituntil {ppEffectCommitted "chromAberration"}; "radialBlur" ppEffectEnable true; "radialBlur" ppEffectAdjust [_force * random 3,_force * random 3,_force * random 3,_force * random 3]; "radialBlur" ppEffectCommit (0.2 + random 0.2); waitUntil {ppEffectCommitted "radialBlur"}; if((random 100) > 75) then { titletext["","WHITE OUT",random 1]; sleep (random 0.5); titletext["","WHITE IN",random 1]; }; sleep 0.02; }; };

Ya, that's what my function does... This is the code that you should have used: if (_artillery == 1 && {_side == _playerside} && {_count < 4}) then { // All 3 conditions have to be true, but cond 2 & 3 are only evaluated if the preceding one is true. Lazy Evaluation. _index = lbAdd [_listBox, _displayName]; // Add display name to ListBox entry. Goes from 0 to 3. (0-index based) lbSetPicture [_listBox, _index, _picture]; // Adds the previously defined picture to the listbox entry. Again, 0 to 3. It will show up to the left of the text. if ((vehicleVarName _x) == "") then { if (isNil "veh_ref_counter") then {veh_ref_counter = 0}; veh_ref_counter = veh_ref_counter + 1; private ["_vehVarName"]; _vehVarName = format["veh_ref_%1", veh_ref_counter]; _x setVehicleVarName _vehVarName; missionNamespace setVariable [_vehVarName, _x]; }; lbSetData [_listBox, _index, (vehicleVarName _x)]; // This command is used for later reference, it has no immediate effect on the listbox. _count = _count + 1; }; switch (lbCurSel _listBox) do { case 0: { _textValue = lbText [_listBox, 0]; ctrlSetText [_display, _textValue]; missionNamespace setVariable ["ArtilleryUsed", missionNamespace getVariable [(lbData [1500,0]), objNull]]; }; // Continues downwards *** EDIT: I understand that the listbox was a bit too complicated for what you were looking for, but I posted this up for future reference and/or anyone else who wants a solution.

This is the better way to do it: _obj = missionNamespace getVariable [_objString, objNull]; Or you can do it the "more popular" (but worse) way: _obj = call compile _objString;

If CBA isn't on the machine, then none of the code will run, so it's only really necessary on any machine which will be hosting the AI (servers/HC). And drop the contents of the "Unit Caching" folder to your mission (the scripts folder should be in your root mission directory), and append the lines of the description.ext if it asks to overwrite, and that's it.

Updated to v1.3.1, read the original post for updated information.

Gotcha, yes once BI integrates some form of event handlers per CfgVehicle class I can remove CBA, but for now it's a necessity. Anyways if you just want distribution you can disable the caching part: http://forums.unitedoperations.net/index.php/topic/21527-ai-caching-and-distribution-script/?p=264381 If you choose to make your own distribution system, it can be pretty challenging due to the possibility of none or multiple HC connections/disconnects. What I chose to do, and what you can mirror, is a method as described below: Spawn units on server as normal, in case no HC connects. Use an asynchronous script (spawn|execVM script, you can integrate the entire async script within your caching system if it already has one running) to monitor each group, and hold a global variable (array) with all the available headless clients within it (I chose to serialize each HC as an array within the aforementioned global array, ie. [[hcUnit, hcNetID, hcPlayerUID], ...]). When a HC loads into the mission, have it broadcast to the server that it's available and to add it to the HC gvar array. Once the server receives the message that a HC has joined, set a "MPkilled" event handler on the HC's unit, and for the code if isServer then remove the HC from the HC gvar array, and if !hasInterface && !isDedicated then send a message to the server asking it to readd the HC to the list (preferably using the same method as it did when broadcasting the message on HC join). The point of this is to remove the HC from the array if it disconnects or dies, but then add it back if it respawns (ie. still connected, but just died). It's basically the most efficient way to handle HC disconnections, although you'll still lose units if they're not transferred. Have the aforementioned async script check the HC gvar on a set interval, and if isServer && (count gvar_hcArr > 0) then choose randomly any HC from the list (with an equal probability distribution, ie. (gvar_hcArr select random((count gvar_hcArr) - 1))) to send the group to (I just cached the group, sent the cache variable, and then spawned all of the cached units).

This script will do it automatically for you: http://forums.bistudio.com/showthread.php?170539-AI-Caching-and-Distribution-System