Event Auto Profile Backup 1.8.0

Do not ask when mod authors will update their mods or if they can upload older versions of their mods.
Bothering mod authors will lead to warnings and repeat offenses will lead to bans.
Due to an unusually high volume of traffic, our site may be experiencing intermittent slowdowns. If you notice any issues, log out of your account and browse anonymously so you can better utilize caching or try using forge.sp-tarkov.com to search for and download mods.

No more worries to backup your profile. Automatic event-based profile backup system with easy restore system.

[tabmenu]
Heart 2 Thumbs Up 1

  • Version 1.8.0

    Update for 3.11


    No functionality change.

    Changes

    • Reduce default max backup files per profile to 20
    • Swap VFS for FileSystemSync (required by 3.11) and simplify FileSystem calls
    • Check for headless_ instead of dedicated_ profiles to ignore (required for 3.11 compatible Fika)

  • Version 1.7.0

    Update for 3.10

  • Dose this save character inventory on exfil ?

    Looking for somthing to backup profile for when you exfil and its stuck and dosent go through back to main menu.

    • The default config has "OnRaidEnd", which is triggered right before you get to the post-death screen (ie where we see "head, eyes"). So if you get to that screen, even if something happens before you make it back to your stash then yes, your profile would be backed up. If not, then you have deeper issues, probably with a local mods or with the connection to your server, which you should absolutely troubleshoot but this mod will not be able to workaround.


      Background: When the exfil countdown completes it begins a handoff of the data from the client to the server. You know that the handoff is complete when you get to that first post-death screen. If that doesn't get to that screen (your game client will likely just have the spinning circle in the bottom corner) then the handoff failed and there is no profile data for this mod to save anyways as it would grab it from the server's memory.

  • I am running FIKA in a Docker container with Docker in Rootless mode, and attempting to restore backups from this mod completely breaks the container. The server fails to load and spits out "incorrect data check" errors, even after the file which I was attempting to restore is removed. The only fix I have found is to completely destroy and recreate the container.

    • I'm also running the SPT Server with Fika in a docker container (https://github.com/zhliau/fika-spt-server-docker on Debian 12 to be specific) and have never had issues restoring profiles. The only difference I can see is that I'm not running it in rootless mode. Can you shoot me your server logs?

    • The server itself wouldn't ever start, the only logs the container would actually get to before restarting was this

      Code
      Validating SPT version
Validating Fika version
Found server files, skipping init
Fika install requested but Fika server mod dir already exists, skipping Fika installation
Enabling profile backups
Starting periodic command scheduler: cron.
Checking running user/group: 0:1000
spt:x:1000:
Changing permissions of server files to user+rwx, group+rwx, others+rx
Error: incorrect data check at genericNodeError (node:internal/errors:983:15) at wrappedFn (node:internal/errors:537:14) at Zlib.zlibOnError [as onerror] (node:zlib:185:17) at processChunkSync (node:zlib:418:12) at zlibBufferSync (node:zlib:174:12) at syncBufferWrapper (node:zlib:769:14) at payloadFileSync (pkg/prelude/bootstrap.js:561:21) at Module._compile (pkg/prelude/bootstrap.js:1920:21) at Object..js (node:internal/modules/cjs/loader:1712:10) at Module.load (node:internal/modules/cjs/loader:1322:32)

      However, upon recreating the mounted volume and the container, placing the file into the ProfilesToRestore directory resulted in this error, and that error persisted after removing the file. This screamed permissions issue to me but everything was owned by the Rootless Docker user and group, 100999:100999
      I am running this all on NixOS.
      I'm going to be honest, I'm not sure who else to report this to if your mod is not at fault. This is literal weeks of me trying to solve this issue.

    • I agree, it does seem like a permissions issue, especially since it occurs right after the permissions change. I can't think of why EventAutoProfileBackup would cause issues though as it uses SPT functions to interact with the file system.


      The only thing I can think to try is setting the CHANGE_PERMISSIONS env variable to false so the code that produces Changing permissions of server files to user+rwx, group+rwx, others+rx doesn't have the chance to run; I added it to the docker startup script last summer to handle other permissions issues but I never tried it in passwordless mode. If that doesn't work, also try setting TAKE_OWNERSHIP, but since the take_ownership runs before the change_permissions, I'm less confident that's the issue. If it doesn't work with both of those set to false, I'll have to dig quite a bit deeper.


      Reference: https://github.com/zhliau/fika…le#-environment-variables

    • I tried that, setting both of those to false still resulted in the error.

    • Hmmm. Unfortunately I don't have any more ideas right now. I'm certainly not upset at you reporting it here, even if it ends up not being EventAutoProfileBackup at fault. Since you've reported that it only happens when using EventAutoProfileBackup to restore a profile backup, it is probably related. I'll have to set up a rootless environment and get into the weeds to figure out what's going on. If I'm being honest, I probably won't have time to do that in the near future and maybe not even until I rewrite it for SPT 4.


      You can do a "manual" restore by stopping the container, moving/copying the backup files to replace the profile file, and then starting the container again.

      Thumbs Up 1

  • Really great mod!! As a suggestion, i wonder if it is possible to save after a number of raids instead of after every one, since this creates too many backups and it makes it harder to know which one to restore. Thanks for the mod.

    • Thanks! I thought I'd replied to your comment weeks ago but it seems I did not. Sorry about that!


      I put the timestamp at the beginning of the file name and the event at the end so that by just sorting by name you can see the files in chronological order and easily pick out the last time a given even occurred.


      Implementing a system like what you've described is certainly possible in theory but I'd have to build out a system to keep track which would add a decent bit of complexity so I'm hesitant to do so. Right now it's pretty simple as it just runs every time the events in the config file occur. The only obvious work-around that exists at the moment is to just disable some of the events in the config. For example if you only have it run a backup at game start then you'd only get about one backup per gaming session.

    • I didn't notice the timestamps on the names of the files, that helps a lot thanks

      Heart 1

  • This is awesome, thanks

    Thumbs Up 1

  • Thanks for updating it!

    Thumbs Up 1