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.

Actors are automatically removed from a cell by the Oblivion engine when one of two events occur after the 72 hours Cell Reset Timer expires (either naturally or by ResetInterior):

1. the game is saved, or
2. the player returns to the cell.

In other words, when the game is saved after the 72 hours have passed, some actors are removed and will not be part of the save file. Or, if the player returns to the cell more than 72 hours after he left, some actors are removed from the cell. Which actors are removed in each case will be detailed below.

The event of reentering the cell splits into two scenarios, depending on the use of ResetInterior, so there are three distinct scenarios when actors are removed:

• External Cell Reset (ECR) – When the game is saved more than 72 after the player left the cell or any time the game is saved after the ResetInterior function is used (even if before the 72 hours).
• Internal Cell Reset (ICR) – When the player reenters the cell after the 72 hours Cell Reset Timer expired and ResetInterior has not been used
• Internal Cell Reset Extended (ICRx) – When the player reenters the cell after ResetInterior has been used after the last time he left.

Note on ResetInterior – This function sets the Cell Detach Time and the Cell Reset Hours values to -1, so the next time the player enters the cell, the Interior Cell Reset will be executed, as if the Cell Reset Timer has expired.

The following table resumes what happens in each scenario to actors with various combinations of characteristics

CS / Dynamic	Dead	Persistent	Respawn	Not Removed	ECR - External Cell Reset	ICR - Internal Cell Reset	ICRx - Internal Cell Reset Extended
CS	N	Y/N	Y/N	•
CS	Y	Y/N	N			•	•
CS	Y	Y/N	Y	•
DYN	N	N	Y/N		•		•
DYN	N	Y	Y/N				•
DYN	Y	Y	N		•	•	•
DYN	Y	N	Y		•		•
DYN	Y	Y	N			•	•
DYN	Y	Y	Y				•

Sort of obvious note: actors that may be removed by more than one event, are removed by the event that occurs first.

As seen in the table, actor characteristics/flags, directly or indirectly, affects the Cell Reset behavior. These are the general rules, which may be overruled depending on the combinations (discussed later on):

• Quest Item flag - Actors with the “Quest Item” flag checked are never removed, under any circumstance. Period! All considerations below refer to non-Quest-Item actors.

• Essential flag – The Essential flag affects Cell Reset only indirectly: since they do not die, all considerations about dead actors do not apply to Essential actors.

• Respawn flag
  • Dynamic actors with the Respawn flag on are only removed from outside the cell (ECR and ICRx). Otherwise, they are still valid when the player reenters the cell and are not removed with their non-respawn counterparts.
  • If not removed, Respawn actors continue in the cell with most of their values unchanged. Scripted actors keep running their scripts with the vars preserved.
  • The only noticed difference is that dead actors resurrect (standing up and GetDead returns false), although their Health remains zero.

• Persistent –
  • Dynamic, persistent actors are only removed with ICRx.
  • Persistence on non-dynamic actors, of course, depends on how the “Persistent reference” flag is set when the actor is created in the Construction Set.
  • Persistent, dynamic actors are created when a reference is dynamically created based on a Base Object with the “No low level processing” off.
  • Non-persistent, dynamic actors are created when a reference is dynamically created based on a Base Object with the “No low level processing” off.

• Dead –
  • Dead actors are removed when the player reenters the cell.
  • 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.

• non-dynamic –
  • 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)
  • In a few cases, Cell Reset may flag their FormIDs as Deleted (see IsRefDeleted), but does not remove the FormID from the game. The actor himself does disappear, thou.

• Dynamic – Dynamic actors may or may not be removed, depending on the other flags

Some other ways of reading the table:

• ECR removes all dynamic, non-persistent actors, regardless of the other flags.
• ICRx removes all dynamic actors, regardless of the other flags.
• ICRx is the only way of removing persistent, dynamic actors
• ICR and ICRx remove all dead, non-respawn actors, including the non-dynamic ones.

• The only non-dynamic actors removed are the dead, non-respawn actors. As mentioned, they are not actually removed. Their FormIDs are flagged as Deleted (IsRefDeleted returns true), but are not removed from the game and remains valid ([[IsFormValid] returns true])

• Dynamic, non-persistent actors are removed by ECR. Since, sooner or later, everybody saves the game, these actors do not bloat the savegame file (all vanilla leveled list creatures are in this category, as they have the “No low level processing” flag checked and, therefore, spawn as non-persistent )

• If the player never reenters a cell containing dynamic actors, the persistent ones will never be removed. Non-persistent actors are removed by ECR.

• If the player reenters the cell, dynamic dead actors are removed from the game.

• Respawn actors removed by ECR do not respawn because the removal is done before the player enters the cell, so when the player enters, the references to those actors are already gone.

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.

See also

• ResetInterior
• PurgeCellBuffers
• GetCellDetachTime and GetCellResetHours
• CloseCurrentOblivionGate