naught

You're absolutely right, that is not intended was at the fault of 1 misplaced line of code (go figure!). Updated to 1.0.1.7 - v1.0 Beta 7 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. Download. Changelog 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.

Waypoints are global to groups so there is no need to copy them (released this in the alpha stage after writing all the code for it :P) , FSMs and scripts re-adjust automatically due to the identical conditions, but since distribution usually happens during the beginning of the mission there's no need for special handling for groups which change locality, there's nothing to transfer anyways. But, if say a headless client JIPs mid-game, yes AI will lose their situational awareness momentarily, but it won't take long for their FSMs to catch-up. Scripts which manipulate AI groups should be unaffected by a change in locality, but scripts which monitor AI on a per-unit basis may break when distribution occurs, so I included a little option to run custom code in the config.sqf on AI spawning from cache/distribution for advanced users to remedy this issue. Thanks for all of your work Foxhound, it always amazes me how you run Armaholic so well while also doing these things like checking for our updates. You're invaluable to the Arma community, so have a happy holidays! :)

Updated to 1.0.1.6 - v1.0 Beta 6 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. Download. Changelog 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.

Hey man, that's some good code! Glad to see that we have scripters here who understand programming and optimization (not that we didn't before or anything). I'm guessing you came from a C++ or C-type background? Yes.

It may work, though it depends on the scripts the mission maker uses to control AI movement (AI distribution may cause these scripts to exit prematurely)... Easiest way would be to plug it in and test it out, looking for any AI which have stopped and won't move or are going to the wrong area.

If no units are present in the active group at any time no caching/respawning will take place (due to Arma garbage collection and the inherent lack-of group positioning), hence the "GLOBAL_SPAWN_DISTANCE" being set to slightly above the minimum value for you to start killing enemies. What you could do to see the whole caching system in action is use this code in the config.sqf: UCD_cachingDistance = 500; #define GLOBAL_SPAWN_DISTANCE (UCD_cachingDistance) // Meters And alter the "UCD_cachingDistance" while in-game (using the debug console) to smaller and larger than your current distance (ie. 1m and 90000m), waiting (at a maximum) "CACHE_MONITOR_DELAY" seconds (default 15 seconds) between each shift before any changes will occur. Then you can see the group caching/respawning.

It's working correctly, you shouldn't notice anything different besides increases in performance with large amounts of AI, which is the point of the script, to remain transparent but functional. It automatically uses your viewdistance as the caching distance, and it can be changed in config.sqf as the "GLOBAL_SPAWN_DISTANCE" (use a low value such as (500) or (viewdistance - 500) to actually see the caching happen). Alternatively you can use some type of AI monitor (preferably marking AI on the map) to show what the AI are doing when they're out of your viewdistance, which is where all the magic happens.

The caching system works by deleting all AI but the group leader, so the group continues to move about, but once players get close the entire force spawns in. It works as it would without the caching system with virtually no difference but increased performance.

Server-wide, the purpose of the script is to be as transparent as possible so you won't have to worry about things like this. For each group, it'll find the closest player, and if it is close enough it'll spawn the specified units. So yes, it'll work as long as players are near by, the only issue is with ai vs ai combat since no players are near and groups may not spawn.

Much better performance, easier to install/use, increased compatibility, automatic AI distribution to ALL connected headless clients, configurable options (ie. you can make all AI men spawn within 1000m of players, but make AI vehicle gunners spawn within 1500m, or make AI which are driving/flying vehicles and aircraft not cache, for obvious reasons), mostly coded in object-oriented style (this really just helps to increase performance and extensibility), also works with the ACE ruck system (for Arma 2) and saves much more data about each unit, allowing for better AI caching, and has experimental capability for caching AI vehicles and respawning them close to the leader when players are near.

Is there an analog loadout system? :P Semantics aside, good addon, but if you want to reach a larger audience I'd recommend making the grass/vd options configurable as ACE did in Arma 2, so that on MP servers players cannot "cheat" by increasing their view distance to higher than normal or remove grass. It would be a very easy fix.

// File: "scripts\move.sqf" { // forEach _x addAction ["Move Object", { private ["_target", "_caller", "_actID"]; _target = _this select 0; _caller = _this select 1; _actID = _this select 2; _target removeAction _actID; _target attachTo [_caller, [0,2,1]]; _caller addAction ["Let Go", { private ["_target", "_caller", "_actID", "_object"]; _target = _this select 0; _caller = _this select 1; _actID = _this select 2; _object = _this select 3; _target removeAction _actID; detach _object; [] call compile preprocessFileLineNumbers "scripts\move.sqf"; }, _target]; }]; } foreach [sign, this1];

This is the fun part of SQF :) There are two environments in SQF: a scheduled and unscheduled environment. Unscheduled code runs outside of the scheduler, running fully sequentially and without delay. This is where you're not allowed to sleep. Scheduled code, on the other hand, runs within the scheduler and introduces a 0.3ms delay between instructions, and this environment also allows for sleeping (which doesn't block the thread, just yield it until sleep is over) and infinite loops (since they can be paused at any time and scheduled for later thanks to that 0.3ms delay). So as a simple note, you can tell that you're in a scheduled environment if you've ever used one of these functions to call any of the previous code which sequentially led-up to your current point: execVM, exec, or spawn. So spawning code, then calling within that code, and then sleeping/waiting/looping within the called code can proceed without bound nor error. All call does is increase scope by one, it doesn't do anything else. That's why you can still access local variables which are local to a higher scope than that of the call block, and that why sleeping and infinite loops are possible if any of the higher scopes originated from a scheduled environment. So essentially, some pseudo-code explaining this concept could look like this: [RVE SQF Intepereter] // Will execute all SQF code, single-threaded { [script1] { _localVar1 = 4; { // call function hint(_localVar1); // works //sleep(4); // will error-out if used spawn script2; // Goes to [script2] scheduled environment }; }; }; [RVE SQF Scheduler] // Will periodically allow code to be executed on the [RVE SQF Intepereter] when it isn't busy { [script2] { sleep(1); // works { // call function while {true} do { // Infinite loops are allowed hintSilent("Test"); // Engine sleep 0.3ms between each instruction within the loop, basically yields to allow for other scheduled environments to execute, then starts again }; }; }; }; ---------- Post added at 20:53 ---------- Previous post was at 20:48 ---------- To build-on to your first example, this is how the RVE interpreted your code and allowed for the yielding: [] spawn { // or execVM call compile preProcessFileLineNumbers "functions.sqf"; waitUntil {!isNull player && {isTouchingGround player || {! istouchingGround player}}}; // This is allowed since it's within a scheduled environment, otherwise it wouldn't be call { while {true} do { // This is allowed since it's within a scheduled environment player sideChat "123"; sleep 1; // This is allowed since it's within a scheduled environment }; }; };

In that case then this simpler function will also work: { // forEach _x addAction ["Move Object", { private ["_target", "_caller", "_actID"]; _target = _this select 0; _caller = _this select 1; _actID = _this select 2; _target removeAction _actID; _target attachTo [_caller, [0,2,1]]; _caller addAction ["Let Go", "tools\detach.sqf", [_target]]; // Adds the new action, passes _target as ((_this select 3) select 0) }]; } foreach [sign, this1];

The addAction command has several useful parameters which it passes to the script which it calls, as seen here: http://community.bistudio.com/wiki/addAction If I'm understanding correctly that your attachTo position changes per object (if it didn't this may look simpler), then your script could look something like this: { // forEach (_x select 0) addAction ["Move Object", { private ["_target", "_caller", "_actID", "_args"]; _target = _this select 0; _caller = _this select 1; _actID = _this select 2; _args = _this select 3; // In this case we passed the attachTo position as our _args _target removeAction _actID; _target attachTo [_caller, _args]; _caller addAction ["Let Go", "tools\detach.sqf", [_target]]; // Adds the new action, passes _target as ((_this select 3) select 0) }, (_x select 1)]; } foreach [ [sign, [0,2,1]], [this1, [0,2,1]] // May need to change this positional value ]; I've been programming for a while now so if the above intimidates or confuses you I apologize, I have my own coding style that I cannot seem to break :P

Also, be aware that objects cannot be represented by strings unless doing some global variable look-up via namespaces and the getVariable command. Give this a read to get a better understanding of data types in Arma, since I've seen you mix them up a few times: http://community.bistudio.com/wiki/Data_Types And read this too if you want to better understand the usage of variables (since I think you want to use a local variable in the above example instead of a global one): http://community.bistudio.com/wiki/Variables ---------- Post added at 19:52 ---------- Previous post was at 19:50 ---------- So you want this: private ["_objectarray"]; _objectarray = [sign, this1]; { // forEach _x addAction ["Move this object!", {[] execVM "move.sqf";}]; } foreach _objectarray; Or, if the array is static, you can make it even more efficient: { // forEach _x addAction ["Move this object!", {[] execVM "move.sqf";}]; } foreach [sign, this1];

This is very wrong and may lead people to believe that Arma is some magical memory-sipping beauty, but in reality it's consuming as much memory as you put towards it. Arma by default uses the Intel Threading Building Blocks memory allocator, but may use many others depending on its configuration. But the job of the memory allocator is to store data as quickly and efficiently as possible, and since allocating new memory chunks from RAM is a very taxing process, what it does is pre-allocate a large sector of memory (for me, the total combination size of the sectors is usually under a gigabyte when Arma is running, although it can very greatly) so that later, when Arma needs to store something in RAM, it can simply write over some of its already allocated memory, which is a very quick process to perform. So what you end up having is basically nonfluctuating memory usages from the OS-side of things, but greatly fluctuating memory usages within the Arma process (and more specifically the TBB code). The issue with this is that when you load great deals of data into the Arma process's memory, it takes up space which may not be used by other items, so depending on the configuration of the current Arma instance this could cause Arma to purge some assets from memory, move some to disk, expand its allocation amount (a very taxing process), or even crash. But back to the question at hand, if you put each function in a separate file, IO operations would increase and therefor so would access time, but usually it's by such small amounts it doesn't make too much of a difference. But since Arma automatically loads all preProcessed files into memory and stores them there (it's caching the files), if you preProcess them again it'll be nearly instantaneous with no IO operations necessary (not sure when caches are purged though, on per-instance or per-mission basis). So when it comes down to it, in-line functions (curly-braces) are slightly faster to compile than external functions (preProcessFile) since they perform less IO operations, but the difference is so small it's not worth worrying about, and whichever is more readable or user-friendly should be used. So yes, it depends on preference :)

CallExtension doesn't have any implemented functions, instead it calls code that you make on your own. The wiki is a bit misleading in the fact that the above code won't do anything unless you make a dynamic link library (dll) named "pipes" and that can parse the "openPipe(pipe)" string to something useful. In order to utilized external commands, you need to code a dll, probably in an unmanaged C-type language (C, C++, etc). This task is very low-level, and one would require a lot of coding experience to create a dll from these types of strongly-typed languages. So unfortunately this isn't something that you can do without first properly learning an unmanaged programming language like C or C++. Reference the BIKI page on extensions for more information: http://community.bistudio.com/wiki/Extensions Also if you want to get a feel for the type of code needed for these types of addons, you can check out my [outdated] Naught.Net addon, which utilizes dll extensions: https://github.com/dylanplecki/Naught.Net/tree/master/source/c/Naught.Net.dll/Naught.Net

Take a look at my Bullet Tracking toolbox script, it utilizes HSV (hue-saturation-value) curves to get perfect color representation, not gradual steps. Plus it adds a lot more functionality, like adding action to turn bullet tracking on/off, pausing bullet tracking, etc. You can pull of some of the code from my GitHub to implement in your script (as it's very popular already and I don't want to release an almost identical script which would rip yours off) and make it better, as long as you credit Naught were need be. I'll check :P https://github.com/dylanplecki/ArmaScripts/tree/master/Arma%203/Bullet%20Tracking

I'm working on configurable download options (ie. max concurrent threads, max download/upload sizes, etc.) and download_to_file could be an option, but I'd focus on that after the next beta release with (hopeful) YAML and XML support with configurable extension options via a config.yml/xml. But with the way Arma works, this process of downloading and restarting would have to be done in-game after the player joins, so they may take up a slot (and if the mods are too big this may take a long time). But personally I'd prefer to require a single mod which downloads script from a remote server, but I could still see the potential for dynamic images/sounds/music/configs/videos/etc.

I probably should have renamed the NDT_fnc_newDownloadHandler to NDT_fnc_newConnectionHandler to clarify what exactly it does. With this addon, you can request completely dynamic files from a web server (ie. PHP, ASP, Java, etc.) for completely dynamic data. You can interact with MySQL and SQL servers via this method, you can get and save data with the GET and POST methods, you can connect to remote programs via the PORT option, and much more. With this, you can enable inter-server communication (or even inter-game communication), you can store persistent data, you can connect Arma to web interfaces and stream data to it, and really you can do anything since it's connected to the web. I've had a few ideas myself, like blocking players from playing on the server until they've created an account on our forums, or logging kills and deaths to a web server for fully persistent records, or by linking our NotePad addon to a web server for saving. We've even considered connecting Arma and SB Pro (a tank-based game) so that all actions in one game will be reenacted in another. And for MSO's, you could stream to a web interface all data, or you could even make a real-time interactive web-based map of the area and stream player positions, names, health, etc. so people can see what's going on in the battlefield. This addon is the stepping stone for things that were never possible before. And also the hashing and regex features are more straight-forward so I'm not going to describe what they could do :) Also Tupolov, I was considering adding file reading/writing and downloading larger files to disk but that creates a HUGE security risk, which would've be feasible for an addon which I'm hoping will be accessible to all types of servers and communities. Instead I kept it limited to strings and I used chunking to allow for up to 1 MB of data to be transfered (hard-coded, but may be changed in the future).

The broken links were an unfortunate effect of my meddling with directories, but they're fixed now. Also uploaded source and migrated to a faster host, links are updated in the original post :)

jayarma2lib_fnc_getLocalTime doesn't return accurate results - often off by hours. Essentially broken on my system (tested only on one machine). Windows 8 64-bit.