The mutable part of the world model is made up from objects (called references in the original MW terminology). An object can either be located in a cell or in a container (which is also located in a cell).
Each cell and each container keeps a separate list for each record type that can be referenced. Each list is made up from a sequence of ESMS::LiveCellRef objects (specialized for the respective record type). Please note that the LiveCellRef only contains the persistent state. State only valid while the object is in an active cell is stored elsewhere.
There is no polymorphism used here, which is a design flaw that originated at a very early development stage and could not be fixed anymore without a total rewrite, once everyone agreed that it was a flaw. Various workarounds are in place now.
Unified Object Access
Unified access to objects is possible through the MWWorld::Ptr class. There are several ways to obtain a Ptr:
- directly from an object in a cell or a container
- via the record ID (all referencable records have string IDs), if there is only one object of this record
- for NPCs and Creatures, via a CreatureStats::ActorId
Another workaround is the MWWorld::Class hierarchy. Through the static function MWWorld::Class::get from a Ptr a suitable instance of a derived Class-class can be obtained that polymorphically implements record type specific behaviour.
The player is a special object that references a record of the type NPC. The player is by definition always in an active cell.
The player object is not stored within the list of objects of that cell. Instead it is handled separately by the World class. This can be ignored most of the time though. The player can be access like any other object via its ID "player". The world class also provides a function that returns the player's MWWorld::Ptr.
Please note that the esm/esp files don't contain a player object. Instead this object is inserted when the player begins a new game.