TTLG|Thief|Bioshock|System Shock|Deus Ex|Mobile
Results 1 to 13 of 13

Thread: Hex fields in some Properties

  1. #1
    Member
    Registered: Oct 2004
    Location: Ireland/Poland

    Hex fields in some Properties

    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?

  2. #2
    Desperately Dodgy Moderator
    Registered: Nov 2001
    Location: Dragonsreach
    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.

  3. #3
    Member
    Registered: Oct 2004
    Location: Ireland/Poland
    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.

  4. #4
    Member
    Registered: Nov 2001
    Location: uk
    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?

  5. #5
    Member
    Registered: May 2002
    Location: Texas
    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.

  6. #6
    Member
    Registered: Jan 2001
    Location: Pushing my luck with Dromed
    Radians are required in conversations, AIWatchObj responses and other pseudoscripts.

  7. #7
    Desperately Dodgy Moderator
    Registered: Nov 2001
    Location: Dragonsreach
    Yes, that's where the angles are in radians, not in the Facing property. Damn my failing memory!

  8. #8
    Member
    Registered: Apr 2001
    Location: Lost in the BSP...
    Quote Originally Posted by PinkDot View Post
    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 Originally Posted by Yandros View Post
    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.

  9. #9
    Member
    Registered: Oct 2004
    Location: Ireland/Poland
    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.

  10. #10
    DromEd Archmage
    Registered: Nov 2010
    Location: Returned to the eternal labor
    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).

  11. #11
    ZylonBane
    Registered: Sep 2000
    Location: ZylonBane
    Err, my experience with the PhysState fields is that they should be treated as read-only, since they tend to revert any changes after a return from game mode. And yes, scripts should stick to using Teleport() instead of monkeying around with the physics internals.

  12. #12
    Member
    Registered: Oct 2004
    Location: Ireland/Poland
    Thanks for the info. My question was purely UI related - not scripts, but still - good to know.

  13. #13
    DromEd Archmage
    Registered: Nov 2010
    Location: Returned to the eternal labor
    Quote Originally Posted by ZylonBane View Post
    Err, my experience with the PhysState fields is that they should be treated as read-only, since they tend to revert any changes after a return from game mode.
    Actually, PhysState behave a bit like an anchor with movements. If you are modifying velocity once, those should not be touched but if you're doing a script which loops to edit this velocity (for a head tracking projectile for example) so it rotate or accelerate constantly until it reaches its target, you'll have a glitch with the velocity : the object will move via the velocity but will teleport suddenly at a random location which is actually the position it should have reached if you didn't had edited the velocity. Such glitch don't happen if you use Physics.SetVelocity instead of Property.Set(obj,"PhysState","Velocity") tho so you'll obviously tell me such piece of news is worthless but still interesting to know how DarkEngine's physics works.

    So the way to prevent this awful glitch is to set PhysState position and rotation to the current position of the object so no matter where the object will be sent by the new velocity, it will be the right location for the engine.
    But well, that's complex scripting and it's being a bit off-topic so I won't go further in here.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •