* Move declaration of dItems to items.cpp
This array is never used in dungeon generation, it's closely related to Items so should be kept together. Ideally managing dItems can become responsibility of a container for Items, which will handle adding/removing items from the list and keeping the positions in sync.
* Rename SetPlrHandItem to match purpose/use
* Give more descriptive name to GetPlrHandSeed
This function sets a new seed on a given item struct, not just the held item.
* Don't use HoldItem as a temporary for the players initial inventory
* Take Item by reference in RespawnItem
* Don't use holdItem as a temporary when dropping gold on death
* Update DeadItem to take item by reference, and refer to it consistently
Move code which invalidates the source of dropped items to the caller
Most call sites use a temporary item instance or remove the item from the container, so there's no real point invalidating the item after it's been copied to the drop list.
Update DeadItem to take position instead of player references
There's a bit of common code, but most of the initialisation logic relies on globals or other functions defined in objects.cpp so it's not really appropriate to move these wholesale into a member of the Object class.
There are a bunch of direct references to dObject related to testing if an area contains the interactable part of an object, this needs further cleanup.
This extracts some of the common object logic from ItemSpaceOk and CanPut, these functions are almost identical except for the way players and monsters are checked...
The other use of dObject is displaying the contents of that array so makes sense to leave as is. We're also able to remove the map since we can reference the current object type value directly on the returned object.
All set maps initialise objects as expected so dObject has the correct ID already, no need to iterate over all active objects. Also by returning a pointer we can use this function to test if an object exists at the target position.
While on msvc int8_t is typedefed to signed char we might as well match the expected data type for the dObject array
* Add helper to test if an object is a trap source
* Add helper to test if an object is a barrel
* Add helper to test if an object is a crucifix
* Add helpers to check if an object is a chest (and statuses)
* Add helpers to check if an object is a (basic) shrine
While it does reference a global configuration option it's mainly concerned with the properties of the object itself, so makes sense to be a member of the object class.
qndel