KILLICIDE, as discussed, I'm going to be nitpicking some of your points in this section. I'll probably get bored soon
Your variable names are unnecessarily long. For example, your hashtable is called Base_Hashtable_1UnsT1. You could have got away with just calling it UT_Hash (UT for Unstable Tectonic)
You're right that the variable name is bad, but your reasoning is not quite correct.
Long variable names are good in all contexts because they reduce ambiguity and make it easier to write self-documenting code.
Here is a nice, recent example: https://beehollander.wordpress.com/...d-why-i-will-never-abbreviate-variable-names/
In the context of JASS, users have discussed in the past that long variable names are sometimes bad because the JASS interpreter has to read characters one line at a time. In fact, there was a time when it was encouraged to write code without any extra whitespace, e.g.
That is no longer the case. You should be using a preprocessor that strips the developer context (descriptive variable names) into fast code.
Why is the variable name bad then? Hungarian notation is bad because it clutters names with data useless to a maintenance programmer, and makes refactoring the variable type prone to bug. There are more reasons and more argument. See http://programmers.stackexchange.co...s-the-benefit-of-not-using-hungarian-notation https://herbsutter.com/2008/07/15/hungarian-notation-is-clearly-goodbad/
As another reference, the google c++ style guide strictly forbids hungarian notation.
Finally, the correct thing to do here is actually to not declare a global hashtable at all. The developer should be using a shared hashtable instance (Table API) because initializing
for every spell is wasteful (it's slow, and there's a hard limit of 255 of them).
A 0.01 second loop timer is unnecessary and taxing on performance if you have a lot of them. You can stick with the conventional 0.03
For a GUI trigger I'll let this pass (and in either case we really shouldn't be accepting GUI triggers to this forum), but in a more general context, the 0.03 value has always been a bad, magic number.
To describe intent better you should be using a number representing frequency, not period. So
constant real CLOCK_PERIOD = 1. / 30.
is (in general) probably the best way to go.
The rest of the suggestions look good to me.