+ Reply to Thread
Results 1 to 3 of 3
Like Tree1Likes
  • 1 Post By Imhothar

Thread: "Type" member in Inspect.*.Detail functions

  1. #1
    Rift Disciple chuckySTAR's Avatar
    Join Date
    Feb 2011
    Posts
    152

    Default "Type" member in Inspect.*.Detail functions

    Documentation says "The * type ID".
    Is this something we can rely on and build databases?
    And whats the difference between this ID and an abilityNew ID in Inspect.Buff.Detail?
    Inspect.Item.Detail even returns several IDs separated by commas in the type member.
    Would use this for identifying several bosses then.
    Last edited by chuckySTAR; 08-16-2012 at 08:25 AM.
    Vince
    GAME OVER
    WORLD FIRST PRE NERFZ REGULOS

  2. #2
    Plane Walker Imhothar's Avatar
    Join Date
    Feb 2012
    Posts
    439

    Default

    The type ID tells you "what is it?" and the ID tells you "which one is it?".

    The .id member is always guaranteed to be unique for everything. That means there are never two items in your inventory with the same .id but they may have the same .type. If you split a stack of Linen in two, the two stacks have a different .id but the same .type because they are both of type "Linen".

    Every buff has a type, too. For example "Bleeding" is the type of a buff. But "Bleeding on player X" and "Bleeding on player Y" are two different things. You also have to differentiate between "Bleeding on player X caused by player A" and "Bleeding on player X caused by player B". They all have the same .type but not the same .id. Now buffs may be caused by abilities and if so the .abilityNew member tells you which ability it was (the "new" part of the name only means its part of a new API and is in the middle of a migration phase and to be renamed in the future).

    The type returned for items is actually a bit complicated as it also encodes information about randomization, runes and enchantments, but it usually suffices to treat the entire string "I33C56D574F5632D1,0551B74AC9E81E46,,,,,," as THE item type. Most item types have only the first two parts filled out anyway and what exactly thse values mean is internal to the game logic. The following type "I09156150424FD0FC,7FBCBF1F3AD033CA,,,,,r7FEC6C965 E05DE35," has a rune on it (indicated with the "r" part) but Inspect.Item.Detail tells you anyway which rune it is in the .statsRune(Temporary) member so there is no need to deal with it (except to find out the base type of the un-runed item or the exact rune type). Types like "I4124F67005B01A4C,31FF4BA6D8F1FFCB,,4BE443935D7E6 9B4,000000120000001E,,," are for randomized items. But as I said, for the most cases it's usually better to think of the entire stirng as a single value.
    Author of the Imhothar's Bags addon.

  3. #3
    Champion Lorandii's Avatar
    Join Date
    Jun 2011
    Posts
    516

    Default

    Quote Originally Posted by chuckySTAR View Post
    Would use this for identifying several bosses then.
    I have written LibBossInfo, which, among other things, can ID bosses. It is testing phase now, and I need to populate it with many more entries, of which I may ask help when I get to that stage. As a preview, here are the APIs:
    Code:
    lib:GetBossID(name, instance, difficulty) -- boss name in English, instance name in English, dungeon difficulty in English (normal, expert, hard, raid, heroic), returns ID
    lib:GetInstance(id) -- boss ID, returns which instance boss is located in English, or nil if outdoor boss
    lib:GetLevel(id) -- boss ID, returns boss level, ie 44 or 52
    lib:GetBoss(id) -- boss ID, boolean, true if ID is a boss, else nil

+ Reply to Thread

Bookmarks

Posting Permissions

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