* Optimize getObjectsInsideRadius calls
our previous implementation calls the ActiveObjectMgr to return ids and then lookup those ids in the same map and test each object
Instead now we call the global map to return the pointers directly and we ask filtering when building the list using lamba.
This drop double looping over ranges of active objects (and then filtered one) and drop x lookups on the map regarding the first call results
This reverts commit df74d369a3.
This reverts commit 908e762479.
Restores the original collision detection bugs to release 5.2.0 prior the large collision detection fix.
Update the profiler names to make more sense of what they actually represent
Move the profiler code from header to its source file
Use monospace font to align lines
Format the statistics line to align better with surrounding values
Refresh the profiler each 3 seconds (roughly)
Works by detecting a collision while moving forward and then
simulating a jump. If the simulated jump is more successful,
an artificial jump key press is injected in the client.
Includes setting and key change GUI element for enabling and
disabling this feature.
Also, use a better distance calculation for 'collide with objects'.
Fixes the issue of a vehicle occasionally colliding with its own driver,
causing one of the velocity components to be set to zero.
* Use constexpr + unroll some calculations to cache definitively some calculations
* Unroll some calls in collision code & use a constref instead of a copy in one occurence
* Rename IWritableNodeDefManager to NodeDefManager
* Make INodeDefManager functions const
* Use "const *NodeDefManager" instead of "*INodeDefManager"
* Remove unused INodeDefManager class
* Merge NodeDefManager and CNodeDefManager
* Document NodeDefManager
the BS constant
implicitly promotes all position calculations it is used in to double even
though positions (= v3f) are only meant to be floats.
There are many, many similar occurrences everywhere, but I'm not willing to
hunt down all; I only fixed the little part I'm already familiar with.
* clientobject, clouds, collision, clientsimpleobject: code modernization
* use range-based for loops
* simplify some tests
* various code style fixes
* use emplace_back instead of push_back when necessary
* use auto on some iterators
* use default operator when needed
* unroll v3s16 creation on collisionMoveSimple
Another small general problem: the player is always standing exactly on the
bondary between 2 nodes e.g. Y=1.5 is exactly between nodes Y=1 and Y=2.
floatToInt() and myround() will round +/-n.5 always 'outwards' to +/-(n+1),
which means they behave differently depending on where you are: they round
upwards above sea level and downwards when underground. This inconsistency
comes from the way the coordinates are calculated, independent of the
specific C++ code.
The result is a tiny bit of lost performance when moving underground,
because 1 node level more than necessary is checked for collisions. This can
be amended by adding a tiny offset to minpos_f.Y, like @paramat suggested.
This is not an elegant solution, but still better than wasting CPU.
To determine the area (nodes) where a player movement took place
collisionMoveSimple() first took the old/new player coordinates and rounded
them to integers, then added the player character's collision box and
implicitely rounded the result. This has 2 problems:
Rounding the position and the box seperately, then adding the resulting
integers means you get twice the rounding error. And implicit rounding
always rounds towards 0.0, unlike floatToInt(), which rounds towards the
closest integer.
Previous (simplified) behavior: round(pos)+(int)box, for example player at
Y=0.9, body is 1.75m high: round(0.9)+(int)1.75 = 1+1 = 2.
==> A character's height of 1.75m always got rounded down to 1m, its width
of +/-0.3 even became 0.
Fixed by adding the floats first, then rounding properly: round(pos+box) =
round(0.9+1.75) = round(2.65) = 3.
