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

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!

Posting Permissions

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