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

  Click here to go to the first Rift Team post in this thread.   Thread: ImhoBags inventory API wishlist

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

    Default ImhoBags inventory API wishlist

    After about 4 months of development here is an updated version of my Trion "wishlist":

    These API features are required to have ImhoBags be able to replace the default inventory windows:
    1. First of all a way of preventing the native inventory frames from appearing. However, some sort of event when the inventory/bank/gbank/... bag windows should be opened or closed as response to visiting a merchant or hitting a shortcut (B or CTRL+F) is then required (in case Event.Loaded wouldn't fire anymore). Being able to SetPoint() a native frame would allow one to move them off-screen. Probably not possible due to the UI architecture though...
    2. Some way to execute the default item action when a frame is right-clicked (including modifiers like CTRL for equipment preview and so on).
      This however presents a challenge. I assume that for this the frames would need to be secured and their itemid/slotid not being changed during combat. However, ImhoBags creates/destroys/moves buttons on-the-fly as items are added/removed, according to sorting and grouping rules. Furthermore, it should be possible to open/close the inventory window during combat, which if it has secure frames cannot be done with a simple SetVisible(true) (correct me if I'm wrong here, I haven't lookup up the secure lockdown thing yet so I don't really know much about it).
    3. For the BANK window: A way to query the status/price and buy the additional bank bag slots.
    4. For the GUILD VAULT: A way to access guild vault information. More details here and here.

    Current strange or misleading behaviour:
    1. When picking up an item from any native frame and dropping it on any frame which does not accept items (Lua frames are ignored) triggers the "Delete?" popup. The mouse event processing has already completed in the background and one needs to hit cancel. Picking up an item with Command.Cursor() doesn't do anything if dropped on other frames (not even triggering deletion in the 3D view). I think it would be better to only trigger the game's item deletion sequence when the item is dropped on the 3D view and have the same happen if picked up with Command.Cursor() (as I'm currently not aware of a means to retrieve the frame stack below the cursor).
    2. Items picked up from the "sbmn" container with Command.Cursor() (or from the native frame) don't seem to work properly. Inspect.Cursor() returns the itemid but Command.Move() won't do anything inside Event.LeftDown/LeftUp. But calling Command.Move() while the item is not picked up works fine.

    These are some bugs, although mainly nuisances:
    1. Item tooltips created with Command.Tooltip() always appear in the topleft corner of my screen instead of at the tooltip anchor (only for items and item types, not for abilities or units).
    2. Item tooltips created with Command.Tooltip() do not include the item's sell price.
    3. Item tooltips created with Command.Tooltip() do not cause the comparison tooltip to appear.

    These ones would be "nice to have":
    1. The colored borders I show above items to indicate their rarity are textures stored in my Addon. The problem here is, that Rift seems to load these files from disk everytime I call SetTexture(), causing a noticable delay when multiple item buttons are updated (done only when they change). There is arelady a thread on this topic for being able to cache textures to avoid 1. multiple instances of the same image in memory and 2. the repeatedly occurring loading lags. There are two ways I came up with: Either have the UI engine cache textures and reload them only if forced to with a special command or have a UI object like TextureInstance that loads a texture once and can then be displayed on regular Texture widgets (either with a new command or overloading SetTexture() to accept a single TextureInstance object). The second approach gives the addon author greater control about texture caching and can be ignored in addons where frequent reloading of textures is not an issue. Alternatively instead of introcuding a new type a Texture widget could get the ability to display the content of a different Texture widget without incurring any loading penalty or duplication.
    2. There is currently no reliable way to detect the deletion of a mail. I have tried quite a few combinations of events and commands, but none work properly. It's at least the last mail where all attempts to detect deletion fail. Event.Mail.Deleted would be really nice.
    3. A new kind of UI widget that displays the cooldown indicator. I tried to come up with textures to duplicate it, but one would need quite a few (plus there is the texture loading issue mentioned above). Having SetTextureCoordinates() would reduce the amount of required textures, but having who knows how many cooldown indicators reloading their textures from disk each frame would be just bad.
    4. Knowing what search criteria the native frames use when searching for artifacts with "/a" and whether that functionality can be duplicated with the current API feature set (there is a thread for this topic).
    5. Being able to pass a frame to Command.Tooltip() as additional parameter thus having the tooltip position itself automagically at the corners of this frame the same way as it does with the native inventory buttons.
    6. Being able to display the mouseover-animation from the native item buttons would be just awesome.
    7. Texture paths!

    I think that's it for now, but I'm sure I forgot something.

  2.   This is the last Rift Team post in this thread.   #2
    Rift Team
    Join Date
    Oct 2010
    Posts
    927

    Default

    Good writeup, thanks much

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

    Default GUILD bank further info

    While the API Imhothar suggested would be nice, fleshing it out completely would be even better. We already have most of the tools such as serialization and the compression lib. Here's what I would like to see.
    LibGuildBankComm, which scans the guild bank for changes and fires callbacks when there are changes. You can parse the guild bank contents using its API, and when you close the guild bank, it sends the data as serialized, compressed format to other users of the library within the same guild. It only sends data that has been changed.

    Usage examples.

    That's WoW, sure, but there is no reason why Rift can't have something similar. Also we need events for when a player joins or leaves a guild.
    Last edited by Lorandii; 06-08-2012 at 11:35 AM.

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

    Default

    In a perfect Rift world, we wouldn't even need this kind of library or addon. Every member of a guild should get updates to their guild bank info automatically. Just sayin' LOL.

+ 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