Looking for a way to Persistent Save on Dedicated Server

[polishmartyr 10]

So I built this mission using a collection of mods and scripts such as the Enemy Occupation System and real weather to name a few. It is basically clearing out zones across an island. Now this is not the only mission this unit plays and I want to find a way to have it where they can save their progress on the mission, take the mission down, play a different mission, and then afterwards go back load up the save and continue their progress in clearing the zones. Much like antistasi, I want my players to play the mission for a while but be able to load another mission and come back to my mission without losing progress. Is there a way or script that allows me to do this?

[Darjusz 3]

Check extDB3. It will solve your issue however you'll need to write some custom scripting and database understanding to handle mission progress saving and loading.

[polishmartyr 10]

20 minutes ago, Darjusz said:

Check extDB3. It will solve your issue however you'll need to write some custom scripting and database understanding to handle mission progress saving and loading.

When you say custom scripting, is there a framework or have to write from scratch? 

[crewt 31]

Setting up a databank for one Mission seems like a heavy approch. 

Try storing relevant mission data in the namespace of the server.

 

If I'm correct, and eos didn't change in the past years, you should have a few arrays with markers, relevant for different types of EOS zones.

You can store all Markers with the "ColorGreen" and/or with a matching Name like this:

 

_arr = allMapMarkers select {(markerColor == "ColorGreen") && {"EOS" in _x }}
profileNamespace setVariable ["XX_mission_X_storage", _arr];

After you done this, or maybe you want to frequently do this somewhere on the server, like.... every 1-2 minutes, this variable is in your namespace and acessable in everymission, as long as you get it from the Server.

 

Now, not sure how you start eos, but the best way would be, before you initialize it, do something like the following:

// This would be your array with the Markers you placed on the Map. You should have this somewhere
EOS_markerArray = [ "EOS_1", "EOS_2", "EOS_3", "EOS_4", "EOS_5", "EOS_6", "EOS_7", "EOS_8", "EOS_9", "EOS_10", "EOS_11", "EOS_12" ];

XX_saveArr = profileNamespace getVariable ["XX_mission_X_storage", []]; 
XX_FinArr = EOS_markerArray - XX_saveArr;
null =[XX_FinArr,[2,1],[2,2],[1,3],[1],[2],[1,2],[1,0,35,WEST,FALSE,FALSE]] call EOS_Spawn;


for "_i" from 0 to count XX_saveArr -1 do {(XX_saveArr select _i) setMarkerColor "ColorGreen";};

this way the markers will be taken out of the EOS stuff. As they now would be green/or how they are, turn them Green or invisible.

These Areas can't be captured or changed, as they didn't run through eos, (if eos does something with them)

[Darjusz 3]

@crewt you are absolutely right that this might be a little bit of an overkill for a single mission. However, the database approach allows you to continue the mission even after server randomly crashes/restarts. 

 

@polishmartyr I don't know about any frameworks because I haven't yet dug up the subject deep enough, but writing your own one will definitely increase your coding skills which might pay back in the future 

[crewt 31]

1 minute ago, Darjusz said:

@crewt you are absolutely right that this might be a little bit of an overkill for a single mission. However, the database approach allows you to continue the mission even after server randomly crashes/restarts. 

 

@polishmartyr I don't know about any frameworks because I haven't yet dug up the subject deep enough, but writing your own one will definitely increase your coding skills which might pay back in the future 

You are right at this point, and if you find joy in setting up a database, sure. Depending on your saving interval, when you are writing in the namespace, you will only lose what hasn't been saved. As you can write anything in the variable of a namespace, you can save nearly anything. But you will lose track quite fast.

 

But the Database is the more advanced approach. Depending on your end goal, It might be the one more useful to you in the long run.

[Darjusz 3]

Exactly. It all dwells down to how much advanced (and flexible) you want to have your mission. Personally, I'm a huge fan of reusability, so I'd take the database approach. Also, my job is related to databases so it's kinda my profession deviation :) 

[Midnighters 152]

A dedicated server box for SQL would  be best too. If the thread author is just running this locally on a p2p server then it may warrant for issues.

Since by default SQL DB's don't necessarily use a whole lot of resources, but in order for variables, info, to be accessed quickly you'll need it to be running at a higher priority.