Arma 3
PERSIST - RCO
Showing 11-20 of 22 entries
< 1  2  3 >
Update: 16 Dec, 2021 @ 3:06am

Minor Hotfix:
- Fixed: Fixed a bug that meant certain mines were not being deleted properly when loading a PERSIST save.

Update: 29 Nov, 2021 @ 9:34pm

Init Loading Update:
- Changed: Instead of needing Detailed Loading to put inventories, damage, fuel, ammunition etc. into Vehicles and Crates, PERSIST will now take the information and put it in the init box of the object instead. This means that Vehicles and Crates can be freely moved, edited and deleted and will still maintain their information.
- Changed: Detailed Load. It still exists, but is now purely for handling map markers, player loadouts, hunger, medical, etc. It no longer affects Vehicles or Crates.

Update: 11 Nov, 2021 @ 6:54pm

Demo Mission Release:

- Added: Demo Mission to show how PERSIST works on the Github Wiki, here: https://github.com/RimmyDownunder/PERSIST-RCO/wiki
- Fixed: Major issue with 'Detailed Load Testing' Module

Update: 10 Nov, 2021 @ 8:18am

Dynamic AI Minefield Update:

- Added: Persistence for Dynamic AI Minefields, if they are in use. While PERSIST was already able to save the mines placed by the AI, it will now also save the exclusion zone around the mines, meaning AI will not build more minefields on top of pre-existing ones.
- Added: Pylon recording. Vehicles will editable pylons will now record the correct weapon and ammo stored on their pylons at the time of saving and load it back with the Detailed Load system.
- Added: PERSIST will remember which side had knowledge of a mine. So if BLUFOR & OPFOR knew a mine existed, they will both remember in the next session.
- Improved: Group Marker cleanup with each 3Den Load. This means that if you have to load multiple times, you won't have to constantly delete all of the group markers manually.
- Fixed: Mine saving. There were several issues with it that should have been resolved. Please let me know what mine you are having issues with if it continues to be a problem.

I also started working on a version of Limited Fortify that would allow for multiple opposing teams to use it, but it is not ready yet sadly due to it being a major overhaul.

Update: 26 Oct, 2021 @ 1:46am

ACE Compatability Update:

- Fixed saving bug with new ACE update.
- Added ACE Medical Saving/Loading, no longer placeholder

I am aware of a possible issue with Fortify, but cannot replicate it myself. Likely has to do with the team merging ACEX into ACE. Personally it works for me, but I will continue to test if people have issues.

Update: 12 Oct, 2021 @ 5:45am

Map Marker Persistence Update:
- Added: Map Marker recording for Slot-Based saving.
- Fixed: Error with old slot persistence.

Only local and player map markers will be saved, so anything placed by the mission will not be recorded by PERSIST. Since it's local, if one player has private markers (like vehicle, group, direct) only he will see them when the mission loads again. For potential use with systems like RR Immersive Maps or Basic Map Sharing - RCO.

Update: 1 Oct, 2021 @ 4:30am

Missing Slot Loadout Update:
- Added: PERSIST can attempt to save a slot's loadout if the player is disconnected or missing.
- Updated: Save and Load tools were moved to prevent misclicks. A reminder to always save and back up your PERSIST missions after completetion.
- Updated: A few of the module descriptions.
- Fixed: Load tool had a sleep where it shouldn't.

Slot Loadouts have been updated again (and I continue to recommend people use them over Player Loadouts). If a Slot is empty at the end of a round, then their loadout will normally not be saved, and thus at the start of the next mission they will be using mission default gear. With this new setting, PERSIST will check your current save and see if there is already a loadout saved for that slot. If there is, it will add the missing slot's loadout to the save list.
In practice, this means a Rifleman who attends Mission 1, then does not attend Mission 2, will load his loadout from the end of Mission 1 if he returns for Mission 3.
There is one potential error with this system, in that if a mission maker reuses a slot's variable name for a different slot, it will load the saved gear. For this reason, always use unique variable names even when adding and removing slots in a PERSIST campaign.

Update: 25 Sep, 2021 @ 2:29am

Join-In-Progress Loadout Update:
- Updated: Delete Blocker description a little
- Added: Join-In-Progress Option to Detailed Load

The 'persist1' player must be in the server at the initial loading of the mission. If this new setting is toggled on, if a player loads into the server after the mission starts they will load their player loadout from either the Slot or from their Profile, depending on mission setting.

Update: 20 Sep, 2021 @ 11:15pm

Minor Bugfix:
- Changed FOB Objects to Save module info to the correct information.
- Changed Crates & Vehicles to Save module info to the correct information.

Thank you to Lynx Australis for pointing out this bug!

Update: 20 Sep, 2021 @ 1:51am

Slot-Based Loadout Update:
- Player Loadouts can now be saved and loaded on a slot-based system, rather than tied to the player's profile. The old option remains for those who want it.
- ACEX Hunger and Thirst is now recorded at the time of save and can be loaded back in the next mission. This is for use with ACEX Field Rations.
- A placeholder for ACE Medical recording has been added. The next ACE update will contain a function to save and load a player's medical status, so when ACE is updated this placeholder will become functional.

How Slot-Based Loadouts Work:
The mission maker must give a variable name to any slot a player will use and that the mission maker wants recorded. The main slot used for loading the operation must still be called 'persist1', but the rest of the slots can be named anything else. When the mission saves, the equipment each slot had at that time will be recorded. When the next operation starts and Detailed Load is run, each slot will find the loadout with their variable name attached and equip that loadout. This means if a new player takes the slot in the second operation, they will get whatever loadout the player from the first operation was saved with.

The system will also function with adding or removing slots from a mission as the campaign moves on, as long as variable names remain unique.