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.
This will be used in a few places where we previously used a raw integer random to index into a local array for selection, simplifying that type of logic to a single statement.
Identified and removed an instance of Direction being used as an argument for a bool parameter
Removed a single-use temporary variable being cast from sprite frame to direction to size_t
Co-authored-by: Anders Jenbo <anders@jenbo.dk>
Fix alignment of WalkSettings array
Previously an improper check was being done to see if the player was
located on the 3 teleporting pads in the level. Even if fixng this the
spell would not work correctly if the layer was standing on the pads
when casting the spell.
Simply use TARGET_BOTH to indicate that it should not be random and send
the player to the given destination
Phasing could end up attempting to teleport to hunreds of random
location and still fail to find a valid target and send the player in to
a wall or outside the map.
This is fixed by first finding all valid locations within range and then
picking one of them at random.
Valid targets is a 13x13 area around the player minus the inner 7x7
In total there can be no more then 120 valid tiles and on average there
should be 75 avalible.
