anthariel

It depends on how the units are added. If the units are added via the editor of ArmA 3, that is to say when the mission is not loaded, then the data will not be saved in the database because, if the persistence system is defined as active, the system ignores any new entry, it simply goes to the database and retrieves all the information from there. In that case you are going to need to use the PersistenceResetOnStart parameter from the description.ext. In your case, if you want to add new units while the mission is running, it is possible yes, but only for already loaded sectors. If you add a unit with this in his initialization conditions: this setVariable ['UseGrid', True], it will be added to the database once the sector where that unit is, is cached (no player nearby). You can see my message above in relation to the UseGrid variable for more details. I even posted a video demonstrating it :-) https://streamable.com/x5rbyq Does that anwser your question?

@sgtfuzzle17Absolutely, there are two big ways in which the system will check whether the units should be cached or not. 1: Without persistence The verification of the units to be cached is only executed when all players have triggered a despawn cell (GCS_VAR_SIZE_UNSPAWN_SQUARES). The verification will be done in the content of the respective cell (GCS_VAR_SIZE_SQUARE_GRID). 2: With persistence Same as 1. but the verification is done every n seconds (1s by default with the parameter GCS_VAR_MONITORING_FREQUENCY_SECS). Every n seconds therefore, a check between before and now is made. This frequency change is due to the fact that with persistence on, we need to be ready for a system shutdown or mission shutdown and we therefore cannot wait for all players to leave the cells for caching. In all cases, if a unit is added by a script after the initialization of the mission, it will by default be ignored, it is possible to do it more explicitly with the variable "UseGrid" to false if necessary but it is not required. On the other hand, if the unit or vehicle is added with the variable "UseGrid" set to true, then the unit will be taken up in the systematic verification of the system and will be cached. After some tests, I had some trouble with the following code: _newUnit = "O_Soldier_A_F" createUnit [position player, (createGroup east)]; _newUnit setVariable ["UseGrid", True]; In my case, the setVariable seems to be triggered before the actual unit was intialized (or something else that I didn't understand) and ArmA did not add the variable to the unit. To fix this, you should use the following code: _newUnit = "O_Soldier_A_F" createUnit [position player, (createGroup east), "this setVariable ['UseGrid', True]"]; as described here: https://community.bistudio.com/wiki/createUnit in the alternative syntax paragraph. Demo: https://streamable.com/x5rbyq You can see that the first unit was added without the variable and was not cached, the second one was added with the variable set to true and, was cached once I leaved the cell.

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

Some good news:

Mods: ArmAGeddon (2017)

I sent a private message to Dwarden on the beginning of this week (since he works on the executables and that apparently diagnostic executable partially corrects the problem), I did not had any response since but he subsequently followed two tickets related to this problem, I assume that this is a start.

Some new screenshots for your eyes! https://twitter.com/ArmAGeddon_mod/status/875094278774697985 Those hurricanes are a new difficulty, they can appear in the middle of a fight, You will have to choose between being sent into orbit or trying to get covered in time .

Thank you everyone! We are also looking for developers (experienced or fast learner) to join our team from 3D to scripting, if you are interested please send us an email: contact@armageddonmod.com

To add to the super-truite comment above, we also have this particle problem. That is, when generating a smoke trail in our case, one or more particles will not be rendered or will be removed (see picture 1). We have try to lower the total number of particle rendered (~7500) but this doesn't solves the problem, however when we do an alt-tab to go back to the Windows desktop and then we go back into the game, it solves the problem for previously deleted particles (they reappear)(if we zoom into the missing particle, the particle will also reappear...). Our second problem is that it is apparently impossible to force the engine to render more than 18,000 particles? Despite the following modification: (see picture 2 and 3 for error) class CfgVideoOptions { class Particles { class High; class Low; class Normal; class UltraTest: High { text="Ultra test"; particlesSoftLimit=50000; particlesHardLimit=75000; smokeGenMinDist=300; smokeGenMaxDist=5000; smokeSizeCoef=2; smokeIntervalCoef=1; smokeZoomCoef=1.42857; highQualityShader=1; numFullSizeParticles=120; }; }; Once the hardLimit had been reached, the next particles following the particle n°18000 will not been rendered. (Can someone from BI can confirm that please?) All of this was tested in dev and stable version (1.68 and 1.70). pictures here : Edit: Tested on the "Arma3LegacyPorts" branch (ArmA3 1.64) nothing changes.

Good luck with the development guys! ;)

https://twitter.com/Arma3official/status/697800594510192640

Hello, do you have selected "Convert exported textures into *.paa files" during your satellite / mask / normal map generation ? Those files are needed because the game engine didn't use png file for that (paa format is way better than png files in term of quality/compression) It can also happen when generating those files that some links between some RVMAT and .paa files are missing / buggy (this can happen when you are playing with the satellite/mask titles parameters). In this case I recommend to you to delete the folder "layers" in the "data" source directory and restart a new generation. Edit, for your next posts related to Terrain builder post here please: https://forums.bistudio.com/forum/164-arma-3-terrain-builder/ ;)

Here some latest screenshots (sorry again for the picture quality, especially Objects LODs...). This will be probably the last screenshots until the release on June 24. ;) https://imgur.com/a/nHNSr

All right Soolie :lol: You can now see the Satellite Imagery in HQ (1px=2m, not the real S.I. Size, Real size is 1px=1m) here: http://anthariel.be/Projects/Tilos/Data/ATP_Tilos_Island_Satellite_Imagery.jpg (if it don't load try CTRL+ F5 or download from here: https://www.dropbox.com/s/fdyryuyhx76apvs/ATP_Tilos_Island_Satellite_Imagery.jpg?dl=0) Ithink that I'll leave that as it is right now, colors are good and I don't see any errors but if you see some glitches, tell me!

Thanks :)