Category talk:Variables

I've noticed that arithmetic on Long values only appears to work in the range of -16777219 to 16777216, which is right about a range of 2^25 (with the positive half being exactly 2^24). You can still store values in the full range expected for a 32-bit var, but doing something like "Set counter To counter + 1" seems to stop working at the ends of this smaller 25-bit range. Has anyone else seen this? -- Nezroy 19:36, 12 May 2006 (EDT)

See my explanation under Variable_types:_floating_point whenever you use floating-point arithmetics you have only a 23 bit mantissa (plus implicit 1). Add the exponent (8bit) and the sign (1bit) and you're at 32 bit. Global variables are always floating point, and whenever an expression uses a floating-point number or variable the 24 bit restriction also applies.--JOG 04:08, 13 May 2006 (EDT)

That would seem to explain it, though in this particular case it was a quest script variable declared as Long that was having issues. Presumably it's also stored as a float similar to globals though. -- Nezroy 02:37, 14 May 2006 (EDT)

Longs are not stored as 32-bit/single floats; instead, they are used as floats (in most functions). This is important for effect codes returned by OBSE Magic functions - they will be accurately stored even though they take 32 bits. One note on the linked topic - I don't think it's quite so clear whether longs are singles or doubles, but they certainly aren't single floats.--Haama 01:18, 3 April 2008 (EDT)

I've changed it back to represent the actual behavior scripters can expect. Whether the variables are internally stored as 64bit double or not is irrelevant. The scripter only cares whether an int/long can hold the whole 31 bit (+sign) as if it were a 32 bit integer, and this is the case. (Unless it's a global then it can only savely hold 24 bit as if it were a float32.)--JOG 12:34, 28 February 2011 (EST)

Round or Floor

I know spells will automatically floor a float variable. What happens when you store a float in a short variable (set ShortVar to FloatVar)?--Haama 12:44, 14 February 2008 (EST)

There is no proper data conversion OR DATA PROTECTION in the game. You cannot convert a float (such as GetCurrentTime )to an integer by direct assignment (GRRR). You will get Script Corruption and strange bugs in the game. --Andyreptile 11:07, 6 March 2008 (EST)

I'm nearly certain that AndyReptile's response is entirely and patently false. You can definitely set a short to a float (can't remember it is rounded or truncated, so I can't answer the question), and I've never heard of any bugs or corruption from doing so.

Dragoon Wraith TALK 16:31, 3 April 2008 (EDT)

Floor--Haama 23:06, 5 April 2008 (EDT)

Those functions are available on the Ceiling and Floor page.

Overhaul

This category has a very strange set up.

1. Declaring variables doesn't need to be a separate article
2. There is a lot of redundant info across the 3 numeral types and the overarching Variables page.
3. Globals and Special Variables aren't really mentioned in the top, so it's unclear (on first glance) why they're in the category. Also, they're a different beast from the other 4 as they don't need to be declared (well, not in a script at least).

Some proposals and choices:

1. Place the 4 variable-types on a sub-category of this category.
   • Place the declaration and usage info on the index of the sub-category
2. Create a separate article for Script Usage and make the variables as general as possible (with more specific info on the script usage page).
   • This one has a problem, though, as a global long is not the same as a scripted long.--Haama 15:28, 25 March 2008 (EDT)

"...a global long is not the same as a scripted long" - How so? In my experience all variables are stored as floats, not just globals. Shorts aren't restricted to the +/-32k range you'd expect from a signed int16. Longs do have precision issues that you wouldn't expect from an int32. This is why personally I've dropped both of them, and simply use "int" now. --Speedo 15:45, 25 March 2008 (EDT)

See the notes on the Globals page - essentially the number returned will never be truncated as with script variables. A good example would be the Special Variable GameHour.--Haama 16:10, 25 March 2008 (EDT)

Thinking about this again - could it be that all variables are stored as floats, but not always used as floats? I've had problems with short variables and EffectCodes before that were fixed by changing the variables to longs. More specifically on globals - in script they are always treated as floats, even if marked as short or long; however, what about quest conditions, dialogue conditons, and result scripts?--Haama 15:34, 27 March 2008 (EDT)

Some more specific overhaul suggestions:

• Have a variable splash page that explains Global variables and Script variables, with a special warning on Game Settings
  • Script variables - splash page with details on usage, declaration, variables init at 0 but will stay at whatever setting when script is called again (that info would have been great when I started), variable indexes including deleting and adding back a variable and adding variables in master/child situations, types (might make these into separate pages), should probably include the set function as well
  • Global variables - Those pages are pretty good, so I don't think they need to change

I've created a Test page. For now it only has pieces and parts, but it's something.--Haama 17:25, 3 April 2008 (EDT)

I've done some more tests, and am pretty sure ([s]for CS/OB v1.2[/s] Seems to be the same for CS v.8 and OB v1.0--Haama 20:54, 6 April 2008 (EDT)) that:

1. All variables are 32-bit
2. All script variables are the same, and they're all longs. The stored value is accurate to 2^31, so the range is -2,147,483,648 to 2,147,483,647. This was tested by storing the value with Set and printing it out with pluggy's IntToString. (and corrected below --Haama 19:35, 6 April 2008 (EDT))
3. Scripted Shorts, Scripted Longs, and Scripted Ints are treated as Int32 variables. The stored value is accurate to 2^31, so the range is -2,147,483,648 to 2,147,483,647. This was tested by storing the value and printing it out with pluggy's IntToString.
4. Scripted Floats are treated similar to Singles. They are accurate, as floats, up to 2^20 (Estimated range -104857.6*10^n to 104857.5*10^n). Past that point they are treated as Int32s. Tested the same way as shorts above.
   • Note, however, that is the stored precision. Once a float value is used in a function it will lose some precision.
5. All global variables are the same, and they're all floats. The stored value is accurate to 2^24 so the range is -16777215 to 16777216 (in testing, it was accurate to 16777216 but not 16777217, so I'm sure about the positive side - not sure why the 0 is on the negative side for these variables). Note that the full 32 bits are used, and 2147483647 will be stored as -2147483648. Tested the same way as above.--Haama 23:40, 5 April 2008 (EDT)
6. All globals are similar to Scripted Floats. They are accurate, as floats, up to 2^20 and are treated as integers after that point. However, they are limited to 24 bit precision, so their (accurate) range is limited from -16777216 to 16777215.

Oops, was thinking of the wrong script when I did the float tests. I'm simply striking everything above, as editing it would be too messy. I assume that they're accurate to 2^24 or 2^23, but I can't run the tests now. More later--Haama 15:09, 7 April 2008 (EDT)

Some of this information is incorrect. As mentioned previously, all script variables except ref are stored internally as doubles - i.e. 64-bit (double-precision) floats. For example, a short, long, or float containing the value 65535 is not stored as 0x0000FFFF but rather 0x40EFFFE000000000. Ref is a special case in that the 64 bits are treated as a 64-bit integer; a ref variable holding the refID 0106C4FD is stored as 0x000000000106C4FD; this is done to avoid loss of significant digits when down-casting to a 32-bit float. Scruggs 15:56, 7 April 2008 (EDT)

Forgot to mention that part; it is incorrect - I'd based the above on the assumption that the new Pluggy LC function worked at Double-precision, but it works on Int32 instead. Striking the whole thing now (the second strikeout undid the nested ones.)--Haama 16:05, 7 April 2008 (EDT)

The operators all do float arithmetic however, correct? So you can do this:

set longVar to (some number above float precision)

but not

set longVar to (some number) + (some other number so that the sum is above float precision)

right?

Dragoon Wraith TALK 18:38, 7 April 2008 (EDT)

From Elys' tests, everything but % and directly setting the variable (as in your first example) will be limited to Single/float precision. She created LC so we can do more precise calculations.--Haama 00:49, 8 April 2008 (EDT)

Ely's info applies when doing arithmetic with a variable and a literal value. In DW's second example, doing arithmetic with 2 literal values gives correct results because literals are compiled as doubles. If someNumber of someOtherNumber are variables, the results will be incorrect.

I suppose if they'd tried they could have made it even a little more confusing. ;) Scruggs 11:58, 8 April 2008 (EDT)