# Storing Dynamically Generated Locations

###### tags: `Deprecated`

To make ruins more interesting to explore, players should be given reasons to come back after they first leave. In order for this to work, players must be able to revisit locations they have visited previously. Currently, this is not an option; points of interest are procedurally generated when they are visited and permanently deleted when they are left. Admins have the ability to force ruins to stick around, but this functionality is not available to the players.

There are two obvious ways of allowing players to revisit previous locations: storing them inaccessibly on the map, or storing them in map files.

## Storing ruins on the map.
Instead of deleting the ruin after the players leave, just... don't. Keep it around, and, if the players revisit, send them back to it.

### Pros:
* Simple and painless.
* "Unloaded" ruin behavior is intuitive (because they aren't unloaded). Time passes normally on them.

### Cons:
* Does not scale well with ruin count. Each ruin needs the same amount of memory and processing power while it's "unloaded" as it needs while it's loaded. Since the amount of ruins "unloaded" will increase with every ruin visited, so too will the memory and processing power required to store them.
* Does not scale well with ruin size. If ruins are made bigger, they will need more map space, and consume more processing power.

In standard SS13, the round comes pre-generated with a number of ruins (chief among them Lavaland itself), implying that for small-ish numbers of ruins the cost of storage is negligible.

It is possible that the performance issues would not rear their ugly head in practice; however, without a strong idea of the number of ruins that will be loaded in a round (dependent on # of ships, round length, average amt. of time spent on a ruin), it is difficult to predict whether this is true.

## Storing ruins as .DMMs.
Don't delete ruins when players leave them -- instead, copy their contents into a DMM file (or something similar), and then load that DMM back into the server when the players return.

### Pros:
* Scales very well with unloaded ruin count and size. The only limit is on-disk storage space.
* There's already a mechanism in place to copy a section of space into a DMM.

### Cons:
* Poor performance. You have to iterate through a lot, and the preexisting implementation is INCREDIBLY slow. This is because it has to check each variable of each object to see if it's been changed.
* Buggy, unpredictable behavior of unloaded ruins. Time will not pass on unloaded ruins, but they will not look exactly like how they were left behind either. Regardless of the implementation, this approach is lossy, and there will be information about the map that is not translated into the DMM. This is fine if it heals wounded enemies; it is very bad if it allows players to duplicate items or conjure electricity from thin air. Individual cases can be mitigated in various ways, but problems will still persist.
* "But wait! Couldn't you check all the variables that a datum has modified from its base type, and copy those into the DMM as well?" Yes, but in addition to being performance-heavy this still wouldn't capture *references to other datums*. Once you start trying to automatically fill in variables, you get into the scariest territory of all -- *invalid state*. For example, an object's variables might be set expecting the existence of a timer. But if that timer gets left behind (and without custom code, it will be) the object may end up in an otherwise-impossible situation when reinstantiated. This can cause many, many bugs.

---

## Hybrid Systems

These approaches alone are not complete descriptions of persistence systems. At their core, they are simply techniques for storing ruins. A complete system for ruin persistence would certainly involve one or both of the above storage techniques, but it might use them selectively, to mitigate their shortcomings.

Possible elements of such complete systems include:
* A limited number of locations phsyically stored at a time.
* The ship might have a limited number of "locks" it can place on ruins in order to tell them to persist, while "unlocked" ruins can be deleted as usual.
* Alternatively, the last *N* ruins visited by the ship might be stored, essentially forming a fixed-size queue of stored ruins. When the ship visits a new ruin with a full queue, the oldest ruin in the queue gets bumped out.
* These approaches could be combined without too much issue.
* DMM system as backup or overflow storage.
* If there are too many ships for each to get its allocated amount of locks / persistent previously visited ruins, DMM-based storage could be used to fill the gap.
* If some degree of persistence for all ruins is desired, DMM storage could be used to store ruins that fall out of the persistence queue instead of deleting them.
* Significant concern: If the DMM system is used only as a backup, it is likely to end up more buggy than it would otherwise be, due to undermaintenance.