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.

Unfortunately this doesn't resolve the issue I don't think.

Roger, thanks. I'll add any more info I see from the RPTs to the Github issue.

Yeah, see my earlier posts...

...auto-init solves all persistence problems it but breaks mission scripts

It messes a few things up unfortunately. Does player persistence work with your mission without auto-init?

Who knows. Maybe it's a good sign if the player is supposed to be in control of Zeus.