View Single Post
Old 03-11-17, 16:52   #7
AkyV
Moderator
 
Joined: Dec 2011
Posts: 4,881
Default

6. Variable sizes and names

TRNG variables have “byte”, “short” or “long” sizes.
The variables in the plugin are similar, but you have more than three possibilities. – You can read more about it here:
Types of Variables

As I said above, you, the plugin maker, are allowed to create any new variable in these types:
- Custom memory zone fields.
- Custom plugin variables.

When you create one of those variables, then it is you who needs to define the size of the variable.

Custom memory zone fields are a bit complicated, let’s see only custom plugin variables, for the time being.

Some examples to choose the proper custom plugin variable size:
- You want to use the variable only as a single flag: the value is 0 if the feature is still not done, or 1 if it is already done. The smallest variables are enough for that, you don’t need to engage too much memory for this variable. Seeing that “Types of Variables” link, they are “char” (from -128 to +127) or “BYTE” (from 0 to 255). You don’t need negative values this time, so BYTE seems the better decision.
- The index of an object is always positive, but could be bigger than 255, so probably the “WORD” size (from 0 to 65535) is the best choice for a variable that hosts that index, BYTE is not enough, DWORD (for positive numbers even above 65535) is too much.
- You can find “Statistics. Secrets (Byte)” memory zone field in several trng.dll triggers, to store the amount of secrets you have found so far. TRNG Byte variables have the same size like plugin BYTE variables, between 0 and 255. Which means you can never find more than 255 secrets in the game. So if you’d like to copy the value of “Statistics. Secrets (Byte)” into your custom variable, then it is evident that your custom variable should be also BYTE.
- You can find “int OrigYBottom” variable in the plugin sources. “Int” means the size is from -2 147 483 648 to +2 147 483 647. This default memory zone field contains the floor level of the actual room, in units.
As you know, one click is 256 units, which means OrigYBottom hosts the room level between -8 388 608 (-2 147 483 648/256) and +8 388 607 (+2 147 483 647/256) clicks. But this is so huge! I mean, as you know, the room maximal vertical interval is between -127 click (floor minimum) and +128 click (ceiling maximum). This is only between -32512 units (-127×256) and +32768 units (+128×256).
If we know that signs are swapped in the code when we talk about vertical sizes (so from +127 click floor min to -128 click ceiling max), then it is between +32512 (+127×256) and -32768 (-128×256).
A “short” variable is between +32535 and -32536. Which means the top ceiling size (-32768) is out of the limit (-32536). And the next variable after “short” (-32536/+32535), where you can also handle negative and positive values as well, is “int (-2 147 483 648/+2 147 483 647) – probably that is why Paolone chose “int” for OrigYBottom.
But I think he made a tiny mistake here. (Or he thought of some future development where room sizes could be bigger. Or he just follow the TRLE code where Core Design programmers used “int”. Or whatever else.) I mean, this variable is only floor data, not floor/ceiling data. I mean, there is always 1 click distance betwen the floor and the ceiling of a room, even if you did some room geometry tricks for a totally flat room. So, if -128 click is the ceiling maximum, then -127 is the floor maximum, which means +32512 (+127×256 floor min) and -32512 (-127×256 floor max) limits – and this time -32512 is INSIDE the -32536 limit, OrigYBottom could be even a “short” variable.
So if you’d like to copy OrigYBottom values into a custom variable, then your variable could be a “short” one, you don’t need an „int” one, even if that is not a mistake. I mean, if a variable is big enough for an „int” size, then the smaller „short” values will surely fit in it. (Or, if you’d like to copy OrigYBottom in clicks into your variable, then, as I said above, the limits are -127 and +127 – which means a “char” custom variable.)
- You’d like a variable to host a field of a Parameters Script command in the code. The field is about a ColorRGB ID number, which is never negative. However, many Parameters field can be “IGNORE”, when you skip that feature. What if you skip that ColorRGB command? Well, if you ignore that, and you type IGNORE, then the field value is -1, as you definitely know. But -1 is not positive, so if you can type IGNORE in a field, then the variable must be able to handle not only positive, but even negative numbers.
- The value you need to store is π (3.14), having the decimal point, so you choose a “float” variable for it. (In the actual TRNG you don’t have the tools to print variables with the decimal point properly in Diagnostics or in the log. The value will show a pure 3 now for π on the screen. Which doesn’t mean the float variable value is only 3.00 now.)
You need to do this choice even if it is a negative π.

I sum it up:
- Always be thoughtful when you choose the variable size. It is a single, independent decision, for each time when you create a variable.
- It doesn’t matter if you choose a bigger variable size, compared to what you need. What really important is you never choose a less one.
However, be thoughtful, you don’t need to engage much memory with a variable, if less memory will also do. Much and much and much and much can be even too much.
- Can the values be also negative or not? Do I need values after the decimal point or not? – These are also important questions when you try to find the proper size.

The name of your custom plugin variables could be anything, after all. There are only a few rules, just like usually when you name something in your computer: you can’t type SPACE in the name etc.
But the variable name should not be very general, like “Variable_A”, but something that refers properly to the task, like ObjectSizeFlag or a shorter one (ObjSizeFlag) – for example, ObjectSizeFlag is 1 if the object has been resized, and 0, if it has been not.

BYTE ObjectSizeFlag
BYTE ObjSizeFlag
int TimeTaken
WORD CameraDistance
WORD CamDist
short Layer1SpeedLow
short Layer2SpeedHigh

Be careful, letters are case sensitive. I mean, eg. “a” and “A” are not the same!

Later I will tell where you should declare the custom variables in the code.

Last edited by AkyV; 17-11-17 at 18:26.
AkyV is offline