Help with forced save at restart

[Gigatek1]

I need to make sure that everything is saved at restarts. The other day I watched a player fill a vehicle with laser designators from his storage, he then put them on his player with less then one minute until restart. When he logged back on after the restart both the vehicle had the laser designators and his player. This has become common practice with A3W... well the non sock one. What would I add here to force a save of vehicles, mines, and objects?

https://github.com/Gigatek1/ArmA_Scripts/blob/master/serverRestartMessages/serverRestartMessages.sqf#L208

@AgentRev can you take a look at this and suggest what should be done if it would only take 5 minutes of your time? How would I force a run of oSave.sqf?

[Gigatek1]

Another bonus with this, we could save less often like every 30 minutes or only at restart instead of every minute or 5 minutes. Which could help performance.

[ghost]

I use fire daemon to restart my servers every 4 hours so they aren't at fixed times during the day as it depends when i last manually restarted it etc. If your proposed system could work along side it knowing exactly how long the server had been up for then this would be an excellent addition as i know only to well how much duping goes on it A3W :(

[pAxton-]

Why not update DB using InventoryClosed event handler. Also, can't you use rcon to kick all players after the last minute has passed and not shutdown immediately run a check onPlayerDisconnected to check if any more playable units are alive. If not update all vehicles on map. Then restart the server?

On Tue, Feb 14, 2017 at 4:41 PM, CCGMatt76 notifications@github.com wrote:

I use fire daemon to restart my servers every 4 hours so they aren't at fixed times during the day as it depends when i last manually restarted it etc. If your proposed system could work along side it knowing exactly how long the server had been up for then this would be an excellent addition as i know only to well how much duping goes on it A3W :(

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/A3Armory/A3A_A3Wasteland.Altis/issues/20#issuecomment-279844964, or mute the thread https://github.com/notifications/unsubscribe-auth/AGFZ5dXlEAXS-RBkWKbzoKDCx7cjPjg8ks5rch-TgaJpZM4L_8jD .

[Gigatek1]

It needs to be done on the vehicles and objects like crates and base building stuff. Agent did fix the player duping with the onPlayerDisconnected event handler awhile back though. This needs to be run right at restart. https://github.com/A3Armory/A3A_A3Wasteland.Altis/blob/dev/persistence/server/world/oSave.sqf#L40

That way we can set the _savingInterval to as high as we want (server performance) and only risk a crash setting it back. It already does a kick to lobby a minute before the restart here but the rcon method I couldn't get to work right.

Maybe since the the restart script is server side maybe setting the save interval variable "_savingInterval = 3" to here would do it https://github.com/Gigatek1/ArmA_Scripts/blob/master/serverRestartMessages/serverRestartMessages.sqf#L208. Do you think that will work?

[pAxton-]

If I understand you correctly. You could create a second oSave.sqf(named slightly different obviously), removing the while loops and the uiSleep _saveInterval. Then call this function after line 210 in the serverRestartMessages.sqf

On Tue, Feb 14, 2017 at 7:19 PM, Gigatek notifications@github.com wrote:

It needs to be done on the vehicles and objects like crates and base building stuff. Agent did fix the player duping with the onPlayerDisconnected awhile back though. This need to be run right at restart. https://github.com/A3Armory/A3A_A3Wasteland.Altis/blob/ dev/persistence/server/world/oSave.sqf#L40

That way we can set the _savingInterval to as high as we want (server performance) and only risk a crash setting it back. It already does a kick to lobby a minute before the restart here https://github.com/Gigatek1/ArmA_Scripts/blob/master/serverRestartMessages/serverRestartMessages.sqf#L208 but the rcon method I couldn't get to work right.

Maybe since the the restart script is server side maybe setting the save interval variable "_savingInterval = 3" to here would do it https://github.com/Gigatek1/ArmA_Scripts/blob/master/ serverRestartMessages/serverRestartMessages.sqf#L208. Do you think that will work?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/A3Armory/A3A_A3Wasteland.Altis/issues/20#issuecomment-279879311, or mute the thread https://github.com/notifications/unsubscribe-auth/AGFZ5VAbsVSk_ymmliY6IjU2xKkrDusTks5rckSrgaJpZM4L_8jD .

[pAxton-]

I don't see why all this saving needs to go on every 60 seconds by default. It seems that every hour would be fine. Unless server crashes are common.

On Tue, Feb 14, 2017 at 8:25 PM, DevTeam Paxton lapxtn@gmail.com wrote:

If I understand you correctly. You could create a second oSave.sqf(named slightly different obviously), removing the while loops and the uiSleep _saveInterval. Then call this function after line 210 in the serverRestartMessages.sqf

On Tue, Feb 14, 2017 at 7:19 PM, Gigatek notifications@github.com wrote:

It needs to be done on the vehicles and objects like crates and base building stuff. Agent did fix the player duping with the onPlayerDisconnected awhile back though. This need to be run right at restart. https://github.com/A3Armory/A3A_A3Wasteland.Altis/blob/dev/ persistence/server/world/oSave.sqf#L40

That way we can set the _savingInterval to as high as we want (server performance) and only risk a crash setting it back. It already does a kick to lobby a minute before the restart here https://github.com/Gigatek1/ArmA_Scripts/blob/master/serverRestartMessages/serverRestartMessages.sqf#L208 but the rcon method I couldn't get to work right.

Maybe since the the restart script is server side maybe setting the save interval variable "_savingInterval = 3" to here would do it https://github.com/Gigatek1/ArmA_Scripts/blob/master/serverR estartMessages/serverRestartMessages.sqf#L208. Do you think that will work?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/A3Armory/A3A_A3Wasteland.Altis/issues/20#issuecomment-279879311, or mute the thread https://github.com/notifications/unsubscribe-auth/AGFZ5VAbsVSk_ymmliY6IjU2xKkrDusTks5rckSrgaJpZM4L_8jD .

[Gigatek1]

I set ours to 5 minutes. If this works I'll set it to something like 30 minutes.

On Feb 14, 2017 5:31 PM, "pAxton" notifications@github.com wrote:

I don't see why all this saving needs to go on every 60 seconds by default. It seems that every hour would be fine. Unless server crashes are common.

On Tue, Feb 14, 2017 at 8:25 PM, DevTeam Paxton lapxtn@gmail.com wrote:

If I understand you correctly. You could create a second oSave.sqf(named slightly different obviously), removing the while loops and the uiSleep _saveInterval. Then call this function after line 210 in the serverRestartMessages.sqf

On Tue, Feb 14, 2017 at 7:19 PM, Gigatek notifications@github.com wrote:

It needs to be done on the vehicles and objects like crates and base building stuff. Agent did fix the player duping with the onPlayerDisconnected awhile back though. This need to be run right at restart. https://github.com/A3Armory/A3A_A3Wasteland.Altis/blob/dev/ persistence/server/world/oSave.sqf#L40

That way we can set the _savingInterval to as high as we want (server performance) and only risk a crash setting it back. It already does a kick to lobby a minute before the restart here https://github.com/Gigatek1/ArmA_Scripts/blob/master/ serverRestartMessages/serverRestartMessages.sqf#L208 but the rcon method I couldn't get to work right.

Maybe since the the restart script is server side maybe setting the save interval variable "_savingInterval = 3" to here would do it https://github.com/Gigatek1/ArmA_Scripts/blob/master/serverR estartMessages/serverRestartMessages.sqf#L208. Do you think that will work?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/A3Armory/A3A_A3Wasteland.Altis/issues/ 20#issuecomment-279879311, or mute the thread https://github.com/notifications/unsubscribe-auth/AGFZ5VAbsVSk_ ymmliY6IjU2xKkrDusTks5rckSrgaJpZM4L_8jD .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/A3Armory/A3A_A3Wasteland.Altis/issues/20#issuecomment-279891401, or mute the thread https://github.com/notifications/unsubscribe-auth/AI6sJvHLSm2d6SAqc_Sei-FGd3OUSlDeks5rclVagaJpZM4L_8jD .

[AgentRev]

The small default interval is to account for both crashes and restart. I can't implement a system to save upon restart because running scripts before restart require an external action from the restart backend itself, which varies a lot between server owners. Crashes are not that frequent but they do happen on a weekly basis, and I'd be pissed if my ride wasn't close to me after a crash just because the saving interval was messed with.

[Gigatek1]

Yeah that's what I figured with the small interval. Do you think setting the variable "_savingInterval" to 1 second in the restart script shown would do it? How much do you think the frequent intervals affect performance?

[AgentRev]

Do you think setting the variable "_savingInterval" to 1 second in the restart script shown would do it?

Yeah probably

How much do you think the frequent intervals affect performance?

Not sure, you tell me; I've never benchmarked

[Gigatek1]

Thank you. I'll test to be sure the server is saving at restart.

[Gigatek1]

Damn, putting "_savingInterval" set to 1 in the restart script didn't work. I need to make the stuff in this loop a server function so I can call it when ever I need. Please help with this if it can be done with out much effort and time. It would probably take me a day or 2 of guessing what might work and testing, to get this done.

[pAxton-]

It should only take me a minute to do this for you, but before I jump into it... What didn't work for you?

On Wed, Feb 15, 2017 at 6:46 PM, Gigatek notifications@github.com wrote:

Damn, putting "_savingInterval" set to 1 in the restart script didn't work. I need to make the stuff https://github.com/A3Armory/A3A_A3Wasteland.Altis/blob/dev/persistence/server/world/oSave.sqf#L40 in this loop a server function so I can all it when ever I need. Please help with this if it can be done with out much effort and time. It would probably take me a day or 2 of guessing what might work and testing, to get this done.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/A3Armory/A3A_A3Wasteland.Altis/issues/20#issuecomment-280179719, or mute the thread https://github.com/notifications/unsubscribe-auth/AGFZ5VKNcWqHuYMukaEL1N7AO9nqY6Zlks5rc44_gaJpZM4L_8jD .

[Gigatek1]

I tired adding "_savingInterval = 1;" to a line in the restart function here, to trigger the save loop at restart.

[pAxton-]

I don't remember a server mod folder in the other a3w missions ive worked on outside extdb. Trying to test on my home machine but I dont have the serverRestartMessages.sqf in my build. I do have the a3wasteland_settings folder.

On Wed, Feb 15, 2017 at 7:14 PM, Gigatek notifications@github.com wrote:

I tired adding "_savingInterval = 1;" to a line in the restart function here https://github.com/Gigatek1/ArmA_Scripts/blob/master/serverRestartMessages/serverRestartMessages.sqf#L208, to trigger the save loop at restart.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/A3Armory/A3A_A3Wasteland.Altis/issues/20#issuecomment-280185900, or mute the thread https://github.com/notifications/unsubscribe-auth/AGFZ5dC1B1IVMUAKRlYaSBiVkN6TtMoPks5rc5TKgaJpZM4L_8jD .

[Gigatek1]

All the instructions how to install the script are in the beginning of it. Get the script here. I updated it with what I tried too. https://github.com/Gigatek1/ArmA_Scripts/commit/177df8ffe09459db474cb116286ee4bc4de84cc3

[pAxton-]

Message me on steam next time you are on. We can do a meeting on teamviewer. It shouldn't take 15 minutes as long as everything goes as expected.

On Wed, Feb 15, 2017 at 8:17 PM, Gigatek notifications@github.com wrote:

All the instructions how to install the script are in the beginning of it. Get the script here. I updated it with what I tried too. Gigatek1/ArmA_Scripts@177df8f https://github.com/Gigatek1/ArmA_Scripts/commit/177df8ffe09459db474cb116286ee4bc4de84cc3

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/A3Armory/A3A_A3Wasteland.Altis/issues/20#issuecomment-280198261, or mute the thread https://github.com/notifications/unsubscribe-auth/AGFZ5XF_Da-PX_rfZj88jEuhP-8wCfGPks5rc6OrgaJpZM4L_8jD .

[Gigatek1]

Ok. NM about that last message. Here's the file you need to place in the A3Wasteland_Settings folder. init.txt Change the extension from .txt to .sqf

[Gigatek1]

I just want to prevent duping at restarts. Even with a minute loop it still will do it. It shouldn't take that long to make a function that owners and admins can do what they want with. I have been at this for 3 days. It's frustrating to try and fix a bug with a solution you know will work when people are abusing it now. Especially when it takes hours to try and fix and test when others who know what they are doing would take 20 minutes to do this. I'm going to take a break from this. It's pissing me off. Made a branch for this and will mess with it maybe this weekend.

https://github.com/A3Armory/A3A_A3Wasteland.Altis/tree/force_save

Here's what I tied this morning https://github.com/A3Armory/A3A_A3Wasteland.Altis/commit/9f9ab70acadd3333f2ded70ad0bb19092d362969 https://github.com/Gigatek1/ArmA_Scripts/commit/30bf8f07c6db4b51a1a14b2509fafffebdb8da9f

I tried the precompile and server compile as well. I keep getting undefined variable errors. arma3server_2017-02-16_09-01-07.txt

[Gigatek1]

I was just talking to Badvolt about this and he mentioned the inventory closed event handler. Just putting it out there but maybe that on vehicles and crates plus something for crate money might be a better approach. This with the player disconnect you could disable all saving loops, which could help performance maybe.

Just thought it was a interesting idea.

[AgentRev]

You should not remove loops because if the server crashes before a restart then it would lose a couple hours of data

[Gigatek1]

Oh yeah duh. Wasn't thinking about a crash. Doesn't happen that often, maybe once a month or more, if we are not dealing with hackers fucking the memory with some weird voodoo after killing the whole server. But that's a whole different issue 😆. I guess it would be ideal to set separate save loops in the main config for players, vehicles, objects, and mines.

[AgentRev]

Just a question; aren't you using headlesss saving? If yes, the saving interval won't affect the main server performance...

[Gigatek1]

Yes we are but I plan on probably not using it once the 64-bit comes out, because we only have 8 gigs of RAM per server. Our new server is a 7700K with 16 gigs so I can test how much it will use.

[AgentRev]

Yes but Arma 3 will always suck at multithreading no matter the bits

[Gigatek1]

I know but I'm talking about memory usage. I want to make sure we have enough if it's using over 3gigs when 64bit comes out. The 7700K was definitely the reason we bought it though, because like you said Arma sucks at multi-thread usage, so I got the highest gigahertz I can get.

[AgentRev]

none of that explains why you would want to disable headless saving

[Gigatek1]

The Headless client uses about 2 gigs of RAM and the server uses 3. I want to make sure that the OS has at least a a couple gigs. I don't know how much is going to be used with the new 64-bit and we only have 8 gigs per server. I got a server with 16 gigs to test to be sure but I just want to make sure not to spend any extra money if we don't have to.

[AgentRev]

https://github.com/A3Wasteland/ArmA3_Wasteland.Altis/commit/52b3ebcc9281990707e60dfd2134ae4743924ccb

[Gigatek1]

do not call fn_oSaveOnce outside oSave.sqf or fn_saveAllObjects https://github.com/A3Wasteland/ArmA3_Wasteland.Altis/commit/52b3ebcc9281990707e60dfd2134ae4743924ccb#diff-c527c6b50ec950315ef6cbb9e4e80028R109

What function should I call in the restart script?

[AgentRev]

its written right in the commit message........

[Gigatek1]

Thanks man. That's what I thought, I was just confused a bit by that line.

[Gigatek1]

Works great. Thanks again Agent.

[Gigatek1]

It appears I spoke to soon. We have been getting reports when the server loads up vehicles bought at the stores respawn back at the place they were originally spawned at the stores. The weird part is they seemed to dupe too. I couldn't reproduce this though. I locked the Altis server last night and bought 2 vehicles, a crate, a mine, and a spawn beacon then moved to a clear spot and saved them, then waited on the save loop before I restarted the server. When the server came back on the vehicles and objects were in the right place, with no duped ones I bought at the store, but the vehicles that were at vehicle stores before but blew up were back. I tried this again with the same items just new ones this time with a forced save after the save loop and same results. I couldn't reproduce it and my objects saved fine. I even tried turning off the headless client object saving in the main config and ran the server again and waited for the save loop. Still got vehicles spawning back at the vehicle store after a save loop and restart. Even when I deleted them manually and waited for a save, they came back after the restart.

I think this might be vehicles saved right at restart maybe. I reverted the force save commit and rolled back the db a day. That fixed it.

Here's some more info reported about it http://www.a3armory.com/forum/thread-986.html http://www.a3armory.com/forum/helpcenter.php?action=viewticket&tid=1014

[Gigatek1]

Here's what was being used before the revert and I didn't see any code errors in the rpt. https://github.com/A3Armory/A3A_A3Wasteland.Altis/tree/force_save

[AgentRev]

and where is the rpt?

[Gigatek1]

I knew that was coming. I'll send you a message with them.

[Gigatek1]

Logs are available on request. Message sent Agent

[AgentRev]

I don't know what's going on... it seems like it could be related to HC caching causing mismatching positions

[Gigatek1]

I'll merge the commit again and try it on Stratis later tonight or tomorrow and turn off the HC object saving and run it for a day or so. Then we will know if its at least a HC issue. That was my suspicion too, just couldn't reproduce it.

[AgentRev]

https://github.com/A3Wasteland/ArmA3_Wasteland.Altis/commit/721ed67dbc7e0783fc3569b31c11c5513ba6b4f9

[Gigatek1]

Thanks Agent. I appreciate your time. Thank you for spending some of your weekend on this. I'm testing this on my test server right now and will be running it for a few hours and restarts to be sure.

[Gigatek1]

Works perfect. I'll open this or comment on the a3w issue if I find any problems.

[Gigatek1]

Not sure how but this seemed to mess with parking being saved after a restart. I'll try to think of what the issue is. Help would be appreciated though. I turned force saving off for now.

http://www.a3armory.com/forum/thread-993.html https://github.com/A3Wasteland/ArmA3_Wasteland.Altis/issues/471

[Gigatek1]

I looked at this for awhile and for the life of me can't figure out why forced saving would remove players saved vehicles. Maybe it has something to do with vehicle ID's...? I'm still not sure if it was forced saving anyways. Just haven't had any complaints about parking since I turned it off. I just tried to reproduce this on my test server with no luck. I would like to spend some time on this but want to try to start in the right direction.

[AgentRev]

Vietnam war flashback; https://github.com/A3Wasteland/ArmA3_Wasteland.Altis/commit/73ed4e56d433b754ca4d505c1be8cc82f7900fe5

fn_untrackSavedVehicle would only untrack the ID on the server OR headless, depending on which has save loop duty. However with headless saving + fn_saveAllObjects, both are calling the oSave code, so the ID needs to be untracked from both the server AND headless, otherwise the server thinks the vehicle died and deletes it from the DB.

[Gigatek1]

Wow... Very nice catch. Thank you.