As far as I could tell, this was the last place that still
used 'seconds' instead of ticks, apart from
some sound notification intervals (which are better
converted to real [milli]seconds).
Also renamed ScaredyCat.PanicLength to PanicDuration for
consistency and easier finding.
Both writing to perf.log frequently as well as GetTimestamp
aren't free and hurt performance particularly on slower systems
(which can have notably higher output to perf.log, further
amplifying the problem).
Therefore we make simulation perf logging opt-in.
Additionally, logging of the current tick and tick type
(local/net) is removed from debug.log, and some
remnant debug logging for kills and pips is removed
to keep performance-sensitive logging limited to
perf.log.
*Remove internal GameSpeed defaults
Enforce setting values explicitly all the time
Require definition of a DefaultSpeed
*Remove Global.Timestep default
*Remove the hacky Timestep/OrderLatency setting via LobbyInfo
*Fix shellmaps ignoring mod-defined gamespeeds
*Make DateTimeGlobal use the MapOptions gamespeed
A mere int comparison is obviously cheaper than
a comparison between two multiplications,
so pulling this above the checks of other damage states
allows us to bail early for undamaged actors.
Profiling has shown that filtering them out early is cheaper
than applying those percentage modifiers anyway.
Additionally, profiling shows foreach loops to be cheaper
than LINQ here as well.
* ResourceType trait has been removed.
* Simulation-related data is now defined on the
ResourceLayer (which mods can subclass/replace).
* Support non-money resources by moving the resource
values to the PlayerResources trait.
* Allow mods to disable the neighbour density override
and instead always use the map-defined densities.
* Allow mods to define their own resource placement
logic (e.g. allow resources on slopes) by subclassing
(Editor)ResourceLayer.
* Improve ability to subclass/override ResourceRenderer
by exposing more virtual methods.
While they may be only 'visual' in terms of influence/cell grid,
they all do update CenterPosition, which is essentially the
actual world position of the actor.
'Visual' would imply that it only affects the position where the
actor is drawn, which is inaccurate.
Furthermore, using the term 'Visual' here would make
naming future methods/properties related to visual interpolation
unnecessarily complicated, because that's where we might
need a real 'Visual(Only)Position'.
