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.
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.
-
Version 1.8.0
- FriedEngineer
- 665 Downloads
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
- FriedEngineer
- 733 Downloads
Update for 3.10
RootsNine
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.
FriedEngineer Author
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?
RootsNine
The server itself wouldn't ever start, the only logs the container would actually get to before restarting was this
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.
FriedEngineer Author
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
RootsNine
I tried that, setting both of those to false still resulted in the error.
FriedEngineer Author
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.
Strungerman
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.
FriedEngineer Author
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.
Strungerman
I didn't notice the timestamps on the names of the files, that helps a lot thanks
Spooks
This is awesome, thanks
ODT
Thanks for updating it!