Players scaled after their creation have collision issues with terrain.
Changing this bit of code fixes those issues for downsized players, even
when shrunk to 10% of their original size.
attackradius - seperate value/callbacks to allow AI to be coded to move and shoot.
slowdown triggered by 2x movetolerance rather than a fixed 5 untis.
void AIPlayer::updateMove(const Move* move) - 'lag' correction.
getTargetDistance - c side distance calculation with enabled option.
SPECIAL NOTE: highly suggest https://github.com/GarageGames/Torque3D/pull/1441 or a variation thereof to prevent debug spew and false-postives for occlusion results.
With significant research, development and prototyping assistance from both @andr3wmac (shaders and partial hook work), and @LuisAntonRebollo (additional culling)
System operates as follows:
1) materials are given an additional castDynamicShadows boolean entry. (Default at time of writing is true by request. Personal usage at time of writing defaults to false. value is default-initialized in materialDefinition.cpp. script/gui exposed)
2) lights are given a staticRefreshFreq and dynamicRefreshFreq (in milliseconds). script/gui exposed
3) materials are (effectively) sorted into dynamic and static shadowmap render lists based on flag. (see shadowMapPass.cpp)
4) initial shadowmaps are generated for each light and 'list'.
5) as each refreshFreq times out, the relevant shadowmap for a given light is refreshed.
Special notes:
dynamicRefreshFreq for all lights is set to a (script exposed) 8MS refresh timer.
StaticRefreshFreq for the lions share of lights defaults to 250 MS (1/4 of a second)
scattersky's embedded light, which is intended to operate in a mobile manner, defaults to 8
to reiterate, these are all customizable per-light via script/inspector gui in the case of alternate project needs.
First line is to ensure similar behavior to current regarding pushback on the object doing the colliding.
Second line applies an impulse to the rigid that was collided with.
Will go ahead and merge this in on the grounds that while it may not technically be possible to make this problem occur(at least no one seems to have been able to reproduce it), having the clamping of values is generally a smart move on principle and prevents even the weird outliers from happening.
Many instances where we would create a object via a new call, and then check that it was non-null.
This is redundant, as if we ever were in a situation where new failed, we'd be crashing left and right already, so the additional check is wasted processing.
A lot of instances where some function args are not actually modified in any way, meaning that it is better for performance to convert them into const references. This prevents an additional copy, which can help performance.
Many instances of a function or expression being used repeatedly, which can lower performance.
Fixed it in these cases by creating on local var, reference or pointer that's used instead.
