#Gramps' save file issue
icy ermine
oops! I meant 400KB and this is going to be long, so...
This is a scenario that is PVE and has a lot of added capture points. A round can last between 20 - 72 hrs. Im having two main issues I guess.
When the scenario ends, I have it set to kill the process after 30sec. The server restarts, and picks a new MOB successfully, but all the enemy bases still have the construction built by the players from the previous match.
Other times, the server will restart mid-match due to a crash, and sometimes it starts up fine, but other times (I assume when it's trying to load the save file) the server fps drops down to below 1 and eventually crashes, putting it into a boot loop. In this case, deleting the save file and starting fresh is the workaround, which isn't ideal at all. If I can get confirmation that the save file size is still an issue (game limitation), I can start to look for other ways to save custom data, as I know myself and another mod are both adding data to the save file.
I honestly am starting to think it could be a backend issue?
In experimental 1.3 I killed the process via script as soon as the round ended and everything restarted with a fresh map every time. Since 1.3 came to stable, it's not restarted successfully much at all.
I have tried the new startup parameters they added to resolve the JIP errors after scenario restarts, but that gave me the same results as killing the task myself, no change. I also still get JIP sometimes when this save file glitch happens where everything's already built on round start. And when one of my admins uses #restart to fix it, sometimes it gives us the JIP issue, which requires me to log in and manually kill the task to fix it.
Im already starting to remove stuff from the save file myself in case it is indeed a file size issue. But the stuff already built thing, Im not sure I can do anything about that if its a backend issue.
tame creek
After a successful round ending, do you get the POSTGAME, then very next line a Session Save? I'm guessing yours is doing the POSTGAME state because the -autoreload wouldn't happen/work without it I'm guessing. I have only really messed with Combat Ops, and that's what shows in my logs when my round ends, and I'm guessing it's creating an empty .LastestSave file after the POSTGAME state. Could it be something with the actual scenario itself? I'm just taking wild guesses here as I don't have the means to do any scenario creation (PS5) so I am at the mercy of the modding community. I do use the -autoreload=30 -autoshutdown for a successful scenario completion to reload the config, but only because of the missionHeader setting I use to increase the number of tasks for the vanilla Combat Ops, and RHS Status Quo. But their scenarios must be using older scenario/framework stuff because "Clear Area" task never completes, and the Exfil doesn't work at all....server never enters a POSTGAME state after exfil timer ends and just sits there in an idle state with no "Restarting in <timer>".
I did try your Scenario to see if it was something I'd like to run instead of Combat Ops, but I only host small 4 player servers due to bandwidth issues (Home Internet) and it would probably take days to clear the whole map. I'd be all over a Conflict Remixed Arland map LOL. Sorry if I'm not much help. I was just thinking about how the server does the session saves every two minutes, and maybe finding a way for it to make an empty save after a POSTGAME if it hadn't done so already.
tame creek
Just tested with a admin run through of a Combat Ops Arland Scenario, and as you can see, I have a normal Session save happen at 22:03:47, put myself at exfil and let the Exfil timer count down to initiate the POSTGAME at 22:04:18, and immediately after that entry I have another session save, -autoreload=30 kicks in, and then the -autoshutdown happens at 22:04:49. That last session save zeroed out the .LatestSave.json file and it just has {} as content. ```
22:03:47.785 SCRIPT : SCR_LatestSaveDSSessionCallback: LocalSave: .LatestSave
22:04:18.482 WORLD : UpdateEntities
22:04:18.483 WORLD : PostFrame
22:04:18.483 SCRIPT : SCR_BaseGameMode::OnGameStateChanged = POSTGAME
22:04:18.483 SCRIPT : SCR_LatestSaveDSSessionCallback: LocalSave: .LatestSave
22:04:18.483 SCRIPT : ServerAdminTools | Event serveradmintools_game_ended | reason: faction_victory, winner: US Army
22:04:49.508 DEFAULT : BattlEye Server: Done.
I don't parse logs like some others do. I just use a mod that kills the server OnGameEnd or whatever it's called. This is very frustrating having my server consistently failing to restart correctly. I'm currently at work and it just had an issue where I need to manually go in and fix it... Again! So it's going to be down pretty much all day...
I'll have to look into manually doing a save on game end before killing the server for the restart.
I don't know why they chose to create a Band-Aid instead of fixing the actual issue on scenario restarts. The Band-Aid doesn't even work well. So I hope they look into this issue and actually fix it soon. ..... Or imagine this, when you have serious game breaking issues, keep it in experimental until it's fixed instead of pushing it to stable with errors.