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.
If the random number generator ends up giving X-Y coordinate pairs
that always are on bad tiles (e.g. solid, with object or with monster)
then after a total of MAXDUNX * MAXDUNY tries, it will still cast
phasing to teleport to the bad tile.
No idea why template deduction was failing on 3ds builds only... It was using the context of the return type to deduce what the template arguments should be? Hopefully specifying the template explicitly works.
ephphatha
obligaron
Gleb Mazovetskiy
staphen
qndel
Juliano Leal Goncalves
Anders Jenbo
Robin
BC Ko
Robin Eklind
BC Ko