PinkDot on 19/12/2019 at 13:49
This is mostly a question out of curiosity:
I noticed, that certain fields in some Properties display and accept hexadecimal values like ffff etc..
Example fields are in
Position property: Heading, Pitch, Bank.
There's more of them - you can find a full list by doing a properties dump - 'dump_props_full' - it produces 'properties.txt' file in the game's root folder.
At the bottom of that file there is a list of types used:
Code:
int_hex = hexadecimal integer number (0xABCD0123)
uint_hex = positive hexadecimal number (0xABCD0123)
(...)
short_hex = integer hexadecimal -0x8000 to 0x7FFF
ushort_hex = positive integer number 0 to 65535
Any ideas why they're not simply decimal integer numbers? Wouldn't life be easier if they were?
Yandros on 19/12/2019 at 16:22
My best guess is just that there was no overall global technical requirements spec, and parts of the engine and Dromed were written by different people, who used whatever convention they wanted for variable types etc. Another example is the units for angles, which in most cases is degrees, but in the AI Facing: Directions property, you have to use radians instead. I had been Dromeding for years before I learned that.
PinkDot on 19/12/2019 at 17:27
Radians in UI! That's offensive! ;)
I never realized that. It does look like a bit of mess alright. A lot of the UI labels actually give a hint to the units used, but not all of them apparently.
After digging a bit more into these hexadecimal values, what appears is:
- at least the ones in Position property represent rotational values, which are stored as a ushort values - not float, as one would expect. (and not uint, as it's saying)
- 90 degrees equals to 0x4000, which in decimal system would be 16384. I guess 4000 is easier to remember than 16384.
- 45 is 0x2000 and 22.5 is 0x1000 and so on
- so this system might be preferrable for "clean" rotation values for brushes. And objects are brushes too, so their rotation is also limited to this weird ushort representation.
Still, it puzzles me, why they went for such a limiting format. Rotating brush (or object) by perfect 30 degrees (and any other human-preferrable angle, like most multiplications of 1) is impossible.
caffeinatedzombeh on 19/12/2019 at 19:56
Because they did it a very long time ago and they wanted to be able to do complex maths on it really really fast on (compared to tody)crap hardware?
john9818a on 20/12/2019 at 00:52
I'm not meaning to contradict you Russ, but I currently have a guard set to change between 180, 90 and 360 degrees with higher priority on 180 and 90, and the guard follows those values. I remember reading here at TTLG a long time ago about having to use radians, but I never did. :)
R Soul on 20/12/2019 at 19:28
Radians are required in conversations, AIWatchObj responses and other pseudoscripts.
Yandros on 20/12/2019 at 20:10
Yes, that's where the angles are in radians, not in the Facing property. Damn my failing memory!
Hit Deity on 10/2/2020 at 22:19
Quote Posted by PinkDot
Any ideas why they're not simply decimal integer numbers? Wouldn't life be easier if they were?
Who knows, but Windows Calculator can convert those quite easily for you. And there are thousands of web converters for it.
Quote Posted by Yandros
Yes, that's where the angles are in radians, not in the Facing property. Damn my failing memory!
You've got one of those memories as well, I see. Welcome to the club. :cheeky:
PinkDot on 11/2/2020 at 13:19
Quote:
Who knows, but Windows Calculator can convert those quite easily for you. And there are thousands of web converters for it.
I think I answered myself this question in the following post. Apparently it's easier to handle Dromed's preferrable angle values in hex, rather than decimal format.
FireMage on 11/2/2020 at 14:41
At worst, if you want to set a rotation without dealing with the hex_integer from "Position", you can use the PhysState : Rotation which actually works with decimal.
PhysState is for physical objects tho and its coordinates are applied after a few milliseconds (according to my tests, it's the position an object should reach after moving via velocity but it's still applied when the object is not moving)
(So if the point of this thread is to play with properties via scripts and you don't want to deal with hex_int use "PhysState" instead. Even if Object.Teleport would have been a better option to edit pos or rot).