I'm close to releasing a SP/COOP mission on Tanoa and it relies heavily on player persistence (there are consequences if you are spotted by a certain side, meaning getting anywhere takes ages). The issue I'm having now, having nearly completed this scenario, is that whenever there is persistent data present, the mission takes a long time to load and when it does, it skips the briefing screen. This itself isn't an issue but it completely breaks player persistence. The only way around it is to autoinitialise the server, which breaks half the scripts in the mission.

My feeling is that it's a module load order issue relating specifically to the Data module. On missions that have a lot of persistent data (for me, this includes pretty much standard suite of ALiVE modules on anything larger than Stratis), the game starts (as in, you can hear environmental sounds, footsteps, people shouting orders) well before the player has left the loading screen. The map briefing screen may flash up, then it jumps back to loading and stays there for a while, until the mission actually starts properly. By which time, player persistence has lost its window of opportunity to work and so the player starts at the default starting position with the default kit. Change the mission name (and get rid of the persistent data associated with it), and the mission will load absolutely fine.

Using auto-init on TADST, persistence works perfectly on all fronts so the Data module itself is working fine, but like I said, unfortunately this breaks the mission itself.

It's an issue I can recreate completely vanilla and near-universally with any mission that has a lot of data saved. I did have another thread a while back about a similar issue but have no idea where it's gone!

So, two questions really. First, is this affecting anyone else?

Second, is there a workaround to make sure the player data is loaded later on in the loading queue?

Thank you all again for all your awesome work on this mod, it's improving at an astonishing rate.

I got rid of all the errors like that, spent ages trying to fish them out! There's probably quite a few left over though. The briefing screen is basically just the map screen you get when you play a single player mission right at the start, you have to click continue to get to the mission itself.

It's a problem that happens vanilla with nothing fancy running at all, I've pretty much narrowed it down now to purely the amount of data that ALiVE has to load at the beginning of the mission. If it's a small mission with few AI, player persistence works fine and so does the briefing screen (which doesn't really matter too much, but player persistence will only work on a newly restarted server when the briefing screen does load). With a big mission with lots to persist, then player persistence doesn't initialise properly. This is with many different variations of description.ext and init.sqf. Basically, it's with missions that fundamentally should work perfectly with ALiVE (and do, ignoring this issue).

To reproduce, make a really simple mission on a large map (like Tanoa or Altis) and have two OPCOMs with around 60 objectives and 400 units each, have civpop and placement modules, and all the basics like player options, data and C2ISTAR. Set it up on a dedicated server, start the server with autoinit off, then log in, play for a couple of minutes, save and exit. The close the server down, start it up again, and rejoin.

I can make a sample mission to send out when I get back to my PC.

Yeah, it's purely a dedicated server issue as it's the persistence data itself that causes the mission to skip the briefing and player persistence.

If you are able to actually dude, could you try setting one of your missions on a dedicated server, starting the server with autoinit off, then log in, move somewhere and drop your weapon or change it or something, then save and exit, close the server down, start it up again, and rejoin?

No worries if not! But at least if someone else can reproduce it then I know I'm not going nuts.

Just to confirm, if you do this, the behaviour you should see when joining the mission once again is this:

1. Longer loading screen compared to when no data is present.

2. No map screen or a map screen that flickers in and goes back to the loading screen then gets skipped entirely.

3. Player persistence failed (other persistence should be alright) when in mission.

On another smaller mission, the map screen flickers on and back to the loading screen for a while, then back to the map screen. Player persistence always succeeds when you have to click continue before mission start and it frequently (if not always) fails when it takes too long to load and that map screen is skipped.

Thanks buddy!! Really appreciate the help. Yep it's ONLY when persistent data is present that this issue happens. Really, the briefing screen isn't an issue at all, it's just the clearest indication that player persistence is about to fail. For me, the correlation is near 100%.

I'm away from my PC today but will post one when I'm back soon.

I have a feeling this could be a pretty universal issue though as my usage is fairly niche (SP on dedi for performance and persistence). Would love to iron this out though as I have a load of scenarios I've been working on for months tailored specifically for this usage and I'd like to release them but I haven't been able to get past this player persistence issue since the CBA changes just after EDEN.

I've started missions from scratch and even changed PCs since then and the same issue, each time, even with brand new modules with each ALiVE update, player persistence has failed on anything other than the most basic Stratis-sized missions. Each time, auto-init solves all persistence problems it but breaks mission scripts. Really want to get these missions out there!

Yeah of course, thanks for your help regardless of whether you get the chance to repro. Can't be a biggie given that everything works fine without data. And it could always be that I place Data down as one of my first modules. Who knows!

Funnily enough, you can actually see similar behaviour in this video from the Display Map Intel: Working on dedicated servers? thread. See how the mission loads up, then starts, then jumps back into the loading screen? You don't see the briefing screen in the editor but that behaviour (in my experience) always correlates with player persistence being broken for the first person starting a mission on a dedicated server. That's likely because of an error in the last version, but it helps demonstrate roughly what I'm referring to when I say it jumps back to the loading screen after the mission has loaded.

Hold fire on this, seems I spoke too soon. My repro isn't quite working yet. Not sure quite why yet but I'll get something consistent that I can get going 100% and report back if it's anything to do with ALiVE. May just be that I forgot to replace a module since the last update. Standby!

EDIT: Unfortunately, the repro is working. I just added another few playable units to my test scenario and it all went a bit loopy. Here's the RPT and mission files .

Completely vanilla, made from scratch purely for this test, basic settings of most modules applied. Persistence saves fine but when the server is restarted and initialised by the client, it fails exactly in the manner described above for the initialising client - no briefing screen, sounds heard long before loading screen finishes, and no player persistence. Other modules' persistence is working however.

I have verified that persistence data is saving fine; the mission loads perfectly when the server is auto-initialised. However, when the client prompts server init, player persistence (and only this as far as I can tell) fails.

Steps to reproduce:

1. Load up the scenario on dedicated server. Briefing screen will appear, mission will load fine.

2. Wait a short while. Remove weapon and change positions. Server save and exit.

3. Close server completely.

4. Restart server making sure not to use auto-init.

5. Join the server. This time, briefing will be skipped, much longer loading screen, sounds heard before the loading screen finishes, and player persistence will have failed.

You can also verify that the mission itself is set up correctly by doing steps 1 - 3, then:

4. Starting the server using auto-init (option next to persistent battlefield on TADST).

5. Watching monitor to wait for the mission to initialise completely.

6. Join the server. Player persistence will be working.

Please let me know if I can do anything else to help narrow this down.

Here's my second repro done with as much detail as I can muster. Produced this (slightly more complex) mission earlier on and have since run three tests on it. Basically, it's the usual array of modules just with a larger number of objectives and an asymmetric OPCOM with all persistence options set to on. The mission files are included in the dropbox link at the bottom. It has no scripts, was built in a sterile environment with no other mods, and had no previous saved data. Mission entirely produced by me just now using latest versions of ALiVE, Arma 3 and CBA.

Test 1 (fresh mission name, no pre-existing data, no auto-init): Mission initialised at 12.23.19. Briefing screen appears at 12.24.23. Clicked continue and hint about player data loaded from ALiVE servers appears, everything works perfectly.

Actions taken: moved to new location, dropped primary weapon on ground, placed test marker, moved nearby vehicle, placed second test marker on top of profile e174 in Gravia. Then logged into admin, server saved and exited at 12.28.07, save completes at 12.29.06. Shut down server completely.

Stats:

Time between mission init and briefing screen: 1 min, 4 sec.
Data save duration: 59 sec.

Test 2 (pre-existing data from Test 1, no auto-init): Mission initialised at 12.37.44. Goes into loading screen. At roughly 12.39.15 (+/- 4 seconds), during the load screen, environmental sounds begin (including footsteps and some distant shooting). Server RPT suggests this is during data loading and just after Player Options starts loading (although I'd ask a dev to confirm this as I'm no RPT expert). At 12.39.36, the loading screen finishes, map briefing flashes for a millisecond, and the hint about player data loaded from ALiVE servers does not appear.

Observations: Markers are present at correct location, profile e174 is exactly where it should be, weapon left on ground is at correct position, the moved vehicle is at the place it was left at the end of Test 1. Time of day (I think) has persisted too. Player loadout and starting position however have failed and are the default for the character, despite these options being checked in the player options module. Essentially, all persistence has worked except for Player Persistence.

Actions taken: Server shut down without saving persistence.

Stats:

Time between mission initialised and environmental sounds: 1 min, 31 sec.
Time between mission init and loading screen ending: 1 min, 47 sec.

Test 3 (pre-existing data, "persistent battlefield" and "auto-init" options checked in TADST settings):

13.04.36: Read mission.
13.05.45: ALiVE Global Timer Complete.
13.06.21: Player joins.
13.06.27: Loading screen finishes.

Observations: Hint about player data loaded from ALiVE servers appears and everything works perfectly. Markers loaded, weapon left on ground, vehicle where it should be, e174 at exact position) however this time, the player has persisted too and is in the correct place and has no primary weapon as per the end of test 1.

Conclusions

I strongly suspect the persistence problem is caused by Player Persistence loading before the player is found in playable units. Previous tests I've run suggest that if player persistence doesn't load at the start, it won't save at the end, even if everything else does. So I could run Test 2 again, save and exit at the end, and then run Test 3, and the player persistence data that loads will be the original data from Test 1.

A further, less clinical test I ran suggests that the longer SYS_DATA takes to load, the more likely this behaviour is to appear. So, for people with slower internet connections (mine is about 2mb/sec) or internet connections that are bottlenecked in some way, this issue is more likely. Furthermore, the more data there is to load and therefore the longer that loading takes place, the more likely this issue is to persist.

Possible solutions:

1. Make player persistence wait until the player is found in playableunits before initialising.

2. Find a way to prevent the mission starting while the first player on server is still stuck in the loading screen. The best indicator of this is the first player on the server having to click "Continue" on the map screen before the mission starts.

Edit: I'll post this on GitHub.

Here are the RPTs and mission files for the tests above.

Usually the server only actually starts loading the mission once the first player has joined. Auto-init overrides this and allows the server to load a mission before any players actually join, massively speeding up the load time of the first player to join the mission.

As for whether you should use it, I think the above bug is dependent on two things: first, there being a lot of data, and second, the speed of the internet connect. Together these dictate how quickly SYS_DATA loads and therefore whether player persistence initialises at the right time. So, smaller missions with less persistent data and people with faster internet connections will experience the issue less.

Short answer is: does player persistence work? If so, you're fine. If not, and all other persistence works, then try using auto-init.