Cell Reset

Cells reset to their original setup after a number of hours after the player leaves them, which means that all objects return to their original places, containers return to their original contents etc.

The number of hours is determined by the iHoursToRespawnCell setting, which defaults to 72 hours. Since there may be mods that depend on that, and no modder should mess with it, most references to Cell Reset (including the text below) just say that "cells reset after 3 days" or "cells reset after 72 hours" without bothering to mention that it is configurable. Just be aware that, depending on the mods installed, that may not be exactly true.

Why ?

The cell reset concept is a way to keep the savegame file size under control.

When a new game starts, the whole game universe is set as the developers of the vanilla game and the authors of the installed mods designed their respective worldspaces and interiors. As the game develops, the player activities change the environment (pick, drop, bump, kill, etc)

All those changes are saved in the savegame file, so, when a savegame is loaded, the engine loads the original, static setup from the game and mod files (ESPs, ESMs, BSAs, NIFs etc) and, THEN, makes the required changes recorded in the savegame file, rebuilding the changed world as the player left it when the game was saved.

It would be nice if we moved that loaf of bread in the initial prison cell from the table to the floor and, when we returned to that cell hundreds of playing hours later, we found it on the floor as we left it. On the other hand, to do that, the new XYZ positions and angles would have to be kept in the savegame all the time, so whenever the player returned to that that particular, the engine could move the loaf of bread to its new, changed position on the floor.

If the savegame kept all these detailed changes forever, the file size would be too big (who will go back to every cell in the game, anyway? And, if one does, will he remember (or care) exactly how it was left?). So the designers came to a nice compromise: the game will 'remember' those changes for a while (how about 3 days?) and 'forget' them after that.

So, Cell Reset is not putting everything back where they started, but, instead, is a matter of forgetting (deleting) the information about the changes made to that particular cell.

How ?

When the player leaves a cell, the game saves the game date and time (called Cell Detach Time) and sets the Cell Reset Hours to 72. Every hour, on the hour, the Cell Reset Hours count is reduced by 1. When the count goes from 0 to -1, the information about changes made to that cell are deleted from wherever the engine keeps it. (GetCellDetachTime and GetCellResetHours return those values).

At the beginning of the game, all cells have the Cell Detach Time and the Cell Reset Hours values set to -1. When the player enters a cell, they are set to -1 as well (and will be initialized when the player leaves).

Since cell reset is done at round hours, it happens 72 hours after the next round hour after the player leaves the cell. In other words, cell reset happens from 72 to 73 hours after the player leaves the cell, e.g., it the player leaves a cell at 9:23 AM (or 9:01AM or 9:59AM), cell reset will happen 3 days later, at 10:00 AM.

When the count runs out, the next time the game is saved, those changes are not saved.

And the next time the cell is loaded into memory, those changes are not applied.

Note the wording on the previous sentence: it does not say "the next time the player enters the cell". There is a subtle difference here.

Remember: as the player goes from cell to cell, the engine keeps the most recently visited cells in memory so it does not have to 'rebuild' them if the player goes back, which is wise, as it is not that unusual to go backtrack and because rebuilding a cell does take a while (that is when the engine shows us the load screen . . . from the time we spend looking at load screens, we can guess that loading (rebuilding) a cell is not a trivial task).

The number of cells that remain loaded depends on the INI settings "uInterior Cell Buffer" and "uExterior Cell Buffer", but is also limited by available memory. On low memory PCs, it can go as low as no buffer at all (so you will get a load screen even if you go back immediately) .

If the cell is not loaded when the player goes in, the engine loads it from the game/mod files and applies the known changes. Since after 72 hours those changes are deleted, there will be no changes to apply, so . . . Bingo! . . Cell Reset!

But if the cell is still in the cell buffer, it is not rebuilt, therefore the changes are not reapplied, therefore the cell is not reset, therefore the changes remain. (but, as you can figure out, this is a rare scenario).

All of the above applies also to ResetInterior: most likely, it just deletes those change info, as the cell reset process does, so, if the cell is already loaded, it does not 'reset' it.

PurgeCellBuffers, of course, clears the cell buffer and forces all new cells to be loaded (rebuilt).

Notes

There are many texts (including the OBSE doc) that mention that the cell is reset only when the player reenters it after 72 hours. Maybe there are situations (to be determined) when this is true, but it does not make much sense. If this were true, all of us would carry in our savegames all changes we made to the prison cell and all other cells we ever visited. Since these changes would be deleted the moment we went back, what is the point of keeping then all that time?
There are texts that mention that the time is counted from the moment the player enters the cell. This is certainly not true. The reset time starts counting the moment the player leaves the cell, as can be tested using GetCellDetachTime and GetCellResetHours.

Known exceptions

Non-dynamic actors are not removed.

Cell Reset x Hidden Cells

Hidden cells (aka Dummy Cells) are cells created without a way to go in, where mods keep their things that are not used, and should not be available, all the time. If the reference must be persistent or non-dynamic, modders create them in the CS, place them on hidden cells and move them in and out of the game as needed. Otherwise, modders use PlaceAtMe to create them dynamically and get rid of them when not needed anymore.

Except for actors, all kinds of PlaceAtMe'd references can be removed from the game with DeleteReference. To get rid of PlaceAtMe'd actors, many modders kill them and move them to hidden cells in the hope that the engine will get rid of them sooner or later.

As explained above, the Cell Reset clock is triggered when the player leaves a cell. What may not be so obvious is that hidden cells will never reset, because the player never goes there in the first place and, therefore, never triggers its clock.

One alternative that works fine is to use ResetInterior on the hidden cell just after moving the disposable actor there.

Cell Reset x Actors

Dynamic actors are removed, dead or alive, scripted or not scripted.

Cell Reset does not remove information about non-dynamic actors in the cell, dead or alive, scripted or not scripted, persistent or not. (which makes sense, as NPCs go all over the place and would be bad if they were reset back to their editor location because the cell they happen to be at the moment got reset)

Dead bodies of non-dynamic actors are removed from view when the cell is reset. The game keeps the information, so those actors can be resurrected, if needed. If a script resurrects that actor while the player is the same cell, the actor will not show up automatically. Reset3DState does not help here. To show the resurrected actor either (1) move it somewhere else and back (can be done in the same frame, one MoveTo after another) or (2) the player must leave and reenter the cell.

Cell Reset x Items

?

Cell Reset x Traps

Traps aren't innately reset. Rather their scripts receive the OnReset event and use that to reset themselves. (Hence the trap could something other than reset itself in response to the OnReset event, e.g. it might enable a second, more difficult trap.)

Cell Reset x Oblivion worlds

CloseCurrentOblivionGate resets the Oblivion world the player is in. Player and other foreign actors are moved outside the gate.