Jump to content

Search the Community

Showing results for tags 'persistence'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


    • Vigor
    • DAYZ
    • ARMA 3
    • ARMA 2
    • YLANDS
    • ARGO
  • Die Hard OFP Lovers' Club's Topics
  • ArmA Toolmakers's Releases
  • ArmA Toolmakers's General
  • Japan in Arma's Topics
  • Arma 3 Photography Club's Discussions
  • The Order Of the Wolfs- Unit's Topics
  • 4th Infantry Brigade's Recruitment
  • 11th Marine Expeditionary Unit OFFICIAL | 11th MEU(SOC)'s 11th MEU(SOC) Recruitment Status - OPEN
  • Legion latina semper fi's New Server Legion latina next wick
  • Legion latina semper fi's https://www.facebook.com/groups/legionlatinasemperfidelis/
  • Legion latina semper fi's Server VPN LEGION LATINA SEMPER FI
  • Team Nederland's Welkom bij ons club
  • Team Nederland's Facebook
  • [H.S.O.] Hellenic Special Operations's Infos
  • BI Forum Ravage Club's Forum Topics
  • Exilemod (Unofficial)'s General Discussion
  • Exilemod (Unofficial)'s Scripts
  • Exilemod (Unofficial)'s Addons
  • Exilemod (Unofficial)'s Problems & Bugs
  • Exilemod (Unofficial)'s Exilemod Tweaks
  • Exilemod (Unofficial)'s Promotion
  • Exilemod (Unofficial)'s Maps - Mission Files
  • TKO's Weferlingen
  • TKO's Virolahti
  • TKO's Livonia
  • TKO's Rules
  • TKO's Changelog
  • TKO's Help
  • TKO's What we Need
  • TKO's Australia
  • MSOF A3 Wasteland's Server Game Play Features
  • MSOF A3 Wasteland's Problems & Bugs
  • MSOF A3 Wasteland's Maps in Rotation
  • SOS GAMING's Server
  • SOS GAMING's News on Server
  • SOS GAMING's Regeln / Rules
  • SOS GAMING's Ghost-Town-Team
  • SOS GAMING's Steuerung / Keys
  • SOS GAMING's Div. Infos
  • SOS GAMING's Small Talk
  • NAMC's Topics
  • NTC's New Members
  • NTC's Enlisted Members
  • The STATE's Topics

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Website URL


Jabber (xmpp)








Steam url id







PlayStation PSN














Found 6 results

  1. Hello, @super-truite and I have made a little piece of script to allows missions maker to make a better use of AIs and vehicles on missions. We are guessing that a similar system already exists but we wanted to have a custom system for some of our projects and thought it would be nice to share it. This compilation of script allows a mission make to cache units suchs as vehicles and soldiers with their respective properties (waypoints, stance, direction, position, health, ...). This allows for greater performance and (if chosen) persistence. Features: Grid caching GCS allows the mission maker to automatically cache into the memory AIs andvehicles. Waypoints assigned to a group or a unit are also cached and are reapplied when the unit or group is set up. The mission creator, if necessary, can also exclude a unit or a vehicle from the cache so that the system does not take it into account. Persistence system (optionnal) In addition to all the caching made, the mission maker can also integrate a data persistence system via MySQL so that, even with a restart of the mission or the machine, the units and vehicles will still be saved. How it works: GCS will create a virtual grid on the map based on three parameters available in GCS_configServer.sqf : GCS_VAR_SIZE_SQUARE_GRID - Represents the total size of each cell on the grid GCS_VAR_SIZE_ACTIVATION_SQUARE_GRID - Represents the trigger distance where AIs and vehicles will be created in the cell GCS_VAR_SIZE_UNSPAWN_SQUARES - Represents the trigger distance where AIs and vehicles will be cached and removed in the cell Each cell is defined by these three variables, as described, GCS_VAR_SIZE_UNSPAWN_SQUARES will trigger the caching and removal of units for the given cell, GCS_VAR_SIZE_ACTIVATION_SQUARE_GRID will activate a cell, retrieve it's cached content for the memory or database and will spawn the units. GCS_VAR_SIZE_SQUARE_GRID Defines the cell size. You can disable the caching system on a unit or vehicle by adding the variable "UseGrid" to false on the unit/vehicle init: this setVariable ["UseGrid", False] In this way, even if no player is near the unit or vehicle, it will never be cached and removed. The following gif shows a simple example with a single grid cell being cached, unloaded (player leaving the cell) and reloaded with cached data once the player re-enter the cell: https://i.imgur.com/ai7PeLh.mp4 and the picture below demonstrates a more complete case: Video example: https://streamable.com/jrh43r (4601 units on Stratis) By default, the persistence system is disabled, you will need to install a MySQL database, have the InterceptDB mod installed aswell with CBA. A full tutorial is available on the readme on Github (https://github.com/Super-truite/arma3_GCS.vr/blob/master/README.md) Download: Get the latest release here: https://github.com/Super-truite/arma3_GCS.vr
  2. Trying to use GRAD to save a variable, which is to be referenced after the mission is restarted to be used as part of an if-then statement to simply delete the zone since it's already been cleared by players. The effect I'm going for is simple, which is a progression of clearing sectors by deleting marker areas (EOS zones) and planting a flag marker saying it's secure once the players destroy an object (like a transmitter). That so far has been simple enough: I'm attempting to set a public variable in the missionNameSpace, as that's what I think GRAD wants in order to save it properly. GRAD Config: For reference, the config is saving vehicles, containers, and markers created during the mission. Player position and inventory is also saved, in addition to credit count as I'm also using GRAD money menu. I use a remoteexeccall to get the save function to go, which hasn't failed yet with all the other data. Once the mission restarts, the following code is run from a separate .sqf called from the initServer.sqf I've also tried combinations of "safyrahnorth" == 1 and safyrahnorth == 1, but the error is that the variable is undefined. If I run the same scripts in the same session, it all executes fine. It's as if the variable "safyrahnorth" is getting destroyed as soon as the server shuts down, which makes me think I'm not executing the GRAD variable save correctly. I'm unclear on where I'm going wrong, and some extra eyeballs would be greatly appreciated. Or suggestions on approaching this differently.
  3. Hello again, community. I'm trying to make persistent triggers using profileNamespace, so their state would be saved upon mission restart. Here's what I've got to this minute: private ["_debug","_resetTriggers","_persTriggers","_actTriggers","_triggersLoaded"]; _persTriggers = [trigger_01,trigger_02]; _resetTriggers = false; _debug = true; //Define variable if launched for the first time or reset if ((isNil "triggers_var") || (_resetTriggers)) then { _actTriggers = []; profileNamespace setVariable ["triggers_var",[]]; saveProfileNamespace; }; //Loading activated triggers and activates them again _actTriggers = profileNamespace getVariable "triggers_var"; {_x setTriggerActivation ["ANYPLAYER","NOT PRESENT",false]} forEach _actTriggers; if (_debug) then {hint format ["Persistent triggers:\n%1\n\nActivated triggers:\n%2\n\ntriggers_var:\n%3",_persTriggers,_actTriggers,triggers_var];}; //Checking in any of the persitent triggers was activated while {true} do { UIsleep 2; { if (triggerActivated _x && !(_x in _actTriggers)) then { _actTriggers pushBackUnique _x; profileNamespace setVariable ["triggers_var",_actTriggers]; saveProfileNamespace; if (_debug) then {hint format ["Persistent triggers:\n%1\n\nActivated triggers:\n%2\n\ntriggers_var:\n%3\n\nLast activated:\n%4",_persTriggers,_actTriggers,triggers_var,_x];}; }; } forEach _persTriggers; }; No matter what I do It returns undefined expression in "triggers_var". If I change profileNamespace to missionNamespace - it works fine, so my guess is that I somehow cannot write to profileNamespace. filePatching is on, BattleEye disabled - no changes. Any help or ideas appreciated, I'm really stuck here.
  4. Hi. I got an idea, but lack the means to put the idea into development. I have a idea about creating a mod or program, that can simulate experience build up like real life, and the development of skills and real life progress. I'm guessing is should some kind of persistent mod running on the server, storing players progress. You, as a player, then receives "experience" for participating in missions, and performing specific tasks. After a specific number of points, you then unlock, better stamina, less weapon sway, more carry capacity and so forth. It's a idea about simulating real life progress of soldiers, who develop through training, missions and tasks. No one starts as a super hero special forces soldier. Like I said, i don't have the coding skills, to make this, but I would very much like to help in any way i can. So if anyone is up for it, let me know, and lets figure something out.
  5. Hey guys, I've been trying to run a server for me and my friends to play when we hop on ArmA, right now I'm using RHS and ALiVE to do some guerrilla style missions, I've been using TADST's "local dedicated" server tool, I've enabled the autoInit "persistence" between player joins, but this obviously has it's downsides. - I'm running on my desktop, if I want to restart my PC, I have to close the server (duh) - I can't do an actual dedicated server, I don't want to pay for one or build a server box, so ALiVE's persistence is out of the question, I tried it's "single player save" but it is too much and crashes So this might be a dumb question, but is there a way I can run this server, and have the server save when I exit, then start back up when I re-join with my friends? Basically the same as ALiVE, but save the data local to my PC. Thanks, Envak
  6. sync <code> SQF makes it very easy to achieve asynchrony, while at the same time offering no means of synchronization. Some people seem to think that race conditions aren't a thing in SQF. This is of course wrong, as the scheduler is free to pause execution almost anywhere. A simple example: if (player hasWeapon _someWeapon) then { player removeWeapon _someWeapon; player addWeapon _someOtherWeapon; }; Here it is entirely possible (though admittedly unlikely) for the scheduler to pause between the condition and the effect, and consequently for the player to drop the weapon, keeping it, while also receiving the new one. I have personally witnessed a similar situation occurring in a real game under very heavy lag. Using certain hacky solutions it is possible to get around these issues. Relating to the previous example, it is for example possible to create an atomic function which at the same time attempts to remove the weapon, and returns a boolean indicating whether it was. It is also of course possible to create simple mutexes and consequently spinlocks. Neither solution is very pretty however. As such i suggest the following, very simple, script command: sync { /* some critical section */ } This command should execute the right hand argument synchronously, without the possibility of interruption by the scheduler. Use of any scheduler-only commands such as sleep and waitUntil should generate errors, just as they do in the unscheduled environment. If used in the unscheduled environment the command would have no special effect of course, behaving instead similarly to call. [<string>,...] preprocessFileLineNumbers <string> Many mod developers make clever use of macros for conditional compilation, for instance in order to enable or disable debugging features such as logging, argument validation, call stack tracing, et cetera. This is often done using macro constants defined either in each code file, or in a central header file. Unfortunately it doesn't seem to be possible to include files from the mission in an addon, as it is vice versa. This means in order to enable or disable the aforementioned features, one has to rebuild the mod, or a part of it while defining different macro constants. To ease this, and undoubtedly many other tasks, i suggest the extension of the preprocessFileLineNumbers command with a variant accepting, as the left hand argument, an array of strings representing macro constants to be defined during preprocessing. For example: ["MY_MACRO", "DO_THE_DEBUG"] preprocessFileLineNumbers "myScript.sqf" Would be equivalent to defining these macros at the top of the myScript.sqf file, like so: #define MY_MACRO #define DO_THE_DEBUG // ... compileFinal <code> We can all agree that the compileFinal command, as well as the underlying concept, are great additions to SQF. However they seem to necessitate placing each function, no matter how small, into its own code file. I would often prefer to place related functions, such as class member functions, next to each other in the same code file. For instance: //map.sqf my_fnc_map_add = { // add key value pair to the map }; my_fnc_map_get = { // retrieve value from the map using the specified key }; my_fnc_map_remove = { // remove the specified key from the map }; my_fnc_map_hasKey = { // determine whether the map contains the specified key }; Now all of these functions end up being non-final, and editable. For a dirty workaround something like this might be used: my_fnc = compileFinal str {...} However extending the compileFinal command with a variant accepting code as the right hand argument seems like it would be very simple to implement. serializeObject <object> / deserializeObject [...] Persistence across sessions is nothing new. Implementing it however ranges from arduous to downright impossible (at least without hacking memory via extensions), depending on the desired fidelity. Correctly saving and loading the attachments on a weapon inside a backpack inside a vehicle for instance isn't exactly simple. What i'm suggesting is two new simple commands to streamline this process. The proposed serializeObject command, given a right hand argument of type object, might return an array containing enough information to recreate the object with high precision. Properties such as type, position, orientation, velocity, damage to each part, and the entire inventory tree should be included. The counterpart, deserializeObject, could then be used to bring this array representation back to life. This would simplify immensely the task of persistence seen in many missions and mods, as well as offer a performance boost by moving a significant portion of SQF code over to a native implementation. Please share your thoughts, or any other suggestions you might have. If any (or all) of these have been suggested before, i apologize.