Skip to content

Save logging + Fixes#473

Merged
NataKilar merged 28 commits into
PersistentSS13:devfrom
PsyCommando:save-logging
Sep 30, 2023
Merged

Save logging + Fixes#473
NataKilar merged 28 commits into
PersistentSS13:devfrom
PsyCommando:save-logging

Conversation

@PsyCommando
Copy link
Copy Markdown
Collaborator

@PsyCommando PsyCommando commented Sep 24, 2023

Description of changes

Fixes:

  • Fix z level issues with save loading
  • Fix planetoid data not restoring correctly from save.

Changes:

  • Logs each saves to db.
  • Add some db side procedures.
  • Cut up loading and saving code into smaller bits so it's a bit more manageable.
  • Added some customizable error tolerance to saving/loading.
  • Critical errors handling.
  • Recoverable errors handling.
  • Added an admin verb under server to pick what kind of errors to tolerate during saving/loading.

Added admin verb to the server tab to allow changing at runtime the error tolerance for saving the world. Allow skipping over recoverable and unrecoverable error if wanted. Meant to be a sort of last-resort tool to force a save if something on the map breaks the save in a limited way.
Renamed and moved the code for saving in SSpersistence over to it's own file since it was pretty massive and hard to navigate.
* Also renamed "DeserializeOneOff" to "LoadFromLimbo" to match the other limbo proc names.
@PsyCommando PsyCommando added 🆕 enhancement New feature or request 💾 serialization A bug or feature linked to serialization/deserialization labels Sep 24, 2023
@PsyCommando PsyCommando added this to the Outreach Map Pre-Release milestone Sep 24, 2023
@PsyCommando PsyCommando self-assigned this Sep 24, 2023
* Renamed and duplicated exception filters, one for saving, and one for loading. Since loading doesn't need to unblock entering or restart subsystems on an exception.
* Cut up loading code after applying some of the fixes upstream.
Comment thread mods/persistence/__defines/serializer.dm
Comment thread mods/persistence/controllers/subsystems/autosave.dm
Comment thread mods/persistence/controllers/subsystems/persistence.dm
Comment thread mods/persistence/controllers/subsystems/persistence.dm

var/datum/V
try
V = _list[key] //#FIXME: We really need to get rid of this awful way to check list types.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed.

//!! - HOT CODE BELOW - !!
//!!!!!!!!!!!!!!!!!!!!!!!!
for(var/z in saved_levels)
var/datum/persistence/load_cache/z_level/z_level = z_transform["[z]"] //#FIXME: String concatenation are extremely slow!!!
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, but this is only in the saved_levels loop. Creating the string as a key here isn't going to cause an issue.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

if(last_area_type != TA.type || last_area_name != TA.name)
if(area_turf_count > 0)
z_level.areas += list(list("[last_area_type]", sanitize_sql(last_area_name), area_turf_count))
last_area_type = TA.type //#FIXME: If last_area_type is only ever used as a string, might as well concat it here, instead of doing it thousands of time above?
Copy link
Copy Markdown
Collaborator

@NataKilar NataKilar Sep 25, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The string concatenation should only occur at the boundaries of two areas, when last_area_type changes. Changing last_area_type to a string would be slower, as you'd need to convert TA.type to a string for comparison, which would occur thousands of times.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

alright

var/atom/old_loc // Where the ship was prior to saving. Used to relocate the ship following saving, not on load.

//#FIXME: Don't store this here.
//#FIXME: Don't store this here. Those are meant to be strictly just temporary objects just to show a position on the overmap!
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think these should be regarded as temporary, since ship velocity etc. are stored on this object.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The thing is, that's what neb has been going for last time I asked. That's part of why most of the planet code was decoupled from the markers.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not blocking, but it's not like Nebula has saving either. There's nothing in game that creates and destroys these objects, so I'm not sure how they could be regarded as temporary.

. = ..()
CRASH("obj/debug/error_on_save: Crashing save!")

//
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing comment?

level_data.setup_level_data() is not called after loading level data from a save. But that's where it was adding itself to the list of saved levels. (which really should have stayed inside ssmapping for this very reason)
Silently catching it means we don't get a call stack and nice things like that. So, I'm rethrowing it for the runtime log to pick it up.
* Added the persistence config options to the example config file.
* Renamed an ambiguous config options for persistence.
@PsyCommando
Copy link
Copy Markdown
Collaborator Author

Added some more things while waiting. Now persistence config options are actually parsed from the config files via hooks to the modpack.

Removes dependency on the persistence modpack.
@NataKilar NataKilar merged commit 6b9dfbd into PersistentSS13:dev Sep 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

💾 serialization A bug or feature linked to serialization/deserialization 🆕 enhancement New feature or request

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

2 participants