+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 15 of 27
Like Tree1Likes

  Click here to go to the first Rift Team post in this thread.   Thread: My experience developing an inventory addon

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

    Default My experience developing an inventory addon

    Hello everbody!

    After getting my hands dirty for a few days in an attempt to create an Addon for easier inventory management I came to a point where I have something that can be worked with.
    And I reached some limits of the Rift API on which I'd like to elaborate.

    First: a screenshot of the current progress (the Addon windows are the ones with numbers in their titles)
    Second: the Addon code.

    What is currently implemented:
    • Storage of items accross all characters on the account.
    • Grouping of items according to primary category with special treatment of collectibles and the "sellable" rarity.
    • Sorting of items inside groups by name.
    • Optionally condense full stacks into one button (e.g. three stacks of 50 linen display as one stack with 150 plus the number 3 to indicate the number of used slots: example).
    • Drag & drop of the item buttons. Items dragged into empty areas of the window get moved to the respective location (i.e. dropping an item on the bank window moves the item to a random empty slot in the bank or one of its bags). This makes it needless to display the empty slots per se and saves screen space.
    • Tooltips
    • Display the number of empty slots in the title.
    • Freely positionable windows
    • Window width can be changed by dragging the right border.
    • Windows automatically open/close together with their respective native frames

    Things on my ToDo list:
    • Create and implement the stack split window as I can't use UI.Native.Split
    • Pimp the UI to add character selection, character summaries etc and other options
    • Make the grouping and sorting customizable. But: KISS!
    • Search in the current window and the entire item database
    • Add character summaries to item tooltips
    • Add mail attachments
    • Possibly add artifacts/collectibles once the API allows it
    • Add buttons for opening bank/guildbank/mail/etc from inventory as we can't add/change/hook key bindings
    • Stack compression
    • "Beautify" everything

    Known issues:
    • Items picked up using Command.Cursor() from the "sbmn" container aren't accepted by the native inventory frames, although "sb01"..."sb04" work like a charm (don't have more than 4 bank slots yet). Once the addon is finished the native frames aren't supposed to be visible, so this may actually be a no-issue as it works between my custom frames.
    Other issues I came upon during development:
    • When I gave the Addon to my friend for testing the first reaction was "error spam". After some digging in the SavedVariables it turned out Inspect.Item.Detail() throws an error when passed the item type
      I22AA1CA55C501809,87A167E16EF20020,,1E884CCC4DDE64 5C,FFFFFFFFFFFFFFFF0000001E,,,
      She was able to reproduce the error by simply running:
      Code:
      /script Inspect.Item.Detail(Inspect.Item.Detail("sbmn.012").type)
      This ruled out any errors possibly introduced by my Addon code. The item in question was Ephemeral Tidestone of the Fortress. What immediatelly struck me was the "FFFFFFFFFFFFFFFF0000001E", which is wider than 64 bits. Removing the leading 8 'F's got the item type accepted by Inspect.Item.Detail().
    • The new carnival items (very thin leather and helium flower or what they're called in the English client) have category = nil.

    And now some thoughts on my experiences so far with the Rift API:
    It wasn't difficult to get to know the API, especially as its documentation is very good. The self documenting functions were a big help. I find the table-based approach of handling arguments and return values in the API interesting. Stays true to the Lua style of getting things done. I was a bit disappointed when I found out how very few possibilities exist to manipualte the native frames and I hope their API is going to be enriched in the future. The overall API feels quite consistent and very well thought through.
    Good work there, Trion folks!

    Lastly, I would like to present a ToDo- (ehm I mean Wish- ) list for Trion in order to make the Addon actually usable someday:
    1. As far as I can see there is no way to issue something like Command.Item.Use. This is a rather crucial point for an inventory Addon which aims to replace the existing windows. I gather this has to do with security measures. I have a proposal in mind which I am going to present below.
    2. If I'm not mistaken it isn't possible to display cooldowns the same way as in the native frames or action bars.
    3. Calling Command.Tooltip(item) the tooltip is always anchored at the topleft of the screen. Would it be possible to extend Command.Tooltip() to accept positioning parameters similar to SetPoint? (a simplified version to have the tooltip appear at a frame's corner would suffice)
    4. The ability to SetPoint() on a native frame would make it possible to "hide" the default inventory windows by moving them out of the screen. This way they stay open and keep working for the game but aren't visible to the user. SetVisible(false) would be needed when the user closes the Addon window by hitting X. In order for the frames not to stay hidden when the Addon is disabled the native frames might reset their position whenever they are closed, thus requiring a new SetPoint() every time they become visible.
    5. It would be a big plus if the item tooltip could be extended with custom text. In the context of this Addon it is obviously adding item sums of other characters. Clearing the custom lines every time the tooltip target changes would ensure it is only filled with relevant information.
    6. Adding "inventory" to Inspect.Interaction and Event.Interaction would make it obsolete to modify UI.Native.BagInventory*.Event.Loaded (and possibly others). The current solution can cause incompabilities between addons if multiple try to observe this event. I first tried to add a new child frame to the native one so I wouldn't have to touch the original event handler, but unfortunately, that's not possible...
    7. Adding a new field to item details called "new" (or similar) which reflects the "blinking" state in the default inventory plus a new Command.Item.Something() to clear this state would be great.
    8. It is a bit difficult to create an Addon which looks like the default Rift UI because the texture paths aren't known (or at least I wasn't able to find any info on this). I am thinking mainly about stuff like the currency icons, category buttons in the auction house, the tree collapse arrows, the dark "groups" in the Config Menu, the section header underlines in the Config Menu, and many, many more. I am really terrible at painting pretty pictures and having access to the UI textures would make things much much easier and consistent with Rift.
    9. Is it possible to add formatting codes for Text frames to display multi-colored text or in-line images?
    10. I noticed that issueing Command.Tooltip(itemId) the resulting tooltip does not equal the one you get when hovering the mouse over one of the default buttons in the native inventory. One observable discrepancy is the missing sell value in the Command.Tooltip() frame.
    Guess I should note all development was done on the life server, so I'm not up-to-date with any PTS changes.

    Here is my approach at solving the "use item" problem:
    There are already some predefined frames like "RiftButton". My suggestion is to add a new one called "RiftItemButton" (or "RiftActionButton" if one doesn't want to be limited to items only). Using the button would need setting it's target item or slot (if the current secure mode allows it). The button would then handle the user input and perform actions according to the button's target object the same way as the existing buttons do. Ideally the components (icon, border, highlight, item count, cooldown indicator, etc) could either be set to match the target item/slot or be modifiable individually if one chosed to for greater flexibility. Being able to hook the button events for secondary processing would be a big plus as well.

    This solution would also add up to the consisteny as it would look and feel the same as the default UI (especially the nice animations).

    If anyone knows solutions to the problems I listed above please let me know. Would be very thankfull.
    Should anyone want to give the Addon a try please do so. But remember it's stil something like "pre-alpha".

    Setting debug=true at the bottom of RiftAddon.toc makes the addon table publicly visible behind the global "ImhoBags". The two item windows are "ImhoBags.Ux.BackpackItemWindow" and "ImhoBags.Ux.BankItemWindow". So far the bank frame must be SetVisible() via script manually if away from the bank.

    Sheesh, now that turned into a wall of text...

  2. #2
    Soulwalker
    Join Date
    Oct 2011
    Posts
    7

    Default

    I really don't know much about developing an addon (not enough that i'd know how to make one), I really appreciate people who take the time to make them though. Your addon looks great, this is exactly what i'm hoping for so Trion, please help this one out!

  3.   Click here to go to the next Rift Team post in this thread.   #3
    Rift Team
    Join Date
    Oct 2010
    Posts
    927

    Default

    Quote Originally Posted by Imhothar View Post
    Hello everbody!

    After getting my hands dirty for a few days in an attempt to create an Addon for easier inventory management I came to a point where I have something that can be worked with.
    And I reached some limits of the Rift API on which I'd like to elaborate.
    This is exactly the kind of post I love to see :V

    • Items picked up using Command.Cursor() from the "sbmn" container aren't accepted by the native inventory frames, although "sb01"..."sb04" work like a charm (don't have more than 4 bank slots yet). Once the addon is finished the native frames aren't supposed to be visible, so this may actually be a no-issue as it works between my custom frames.
    • I noticed that issueing Command.Tooltip(itemId) the resulting tooltip does not equal the one you get when hovering the mouse over one of the default buttons in the native inventory. One observable discrepancy is the missing sell value in the Command.Tooltip() frame.
    That'd be a bug. I've added it to the list.

    • When I gave the Addon to my friend for testing the first reaction was "error spam". After some digging in the SavedVariables it turned out Inspect.Item.Detail() throws an error when passed the item type She was able to reproduce the error by simply running:
      Code:
      /script Inspect.Item.Detail(Inspect.Item.Detail("sbmn.012").type)
      This ruled out any errors possibly introduced by my Addon code. The item in question was Ephemeral Tidestone of the Fortress. What immediatelly struck me was the "FFFFFFFFFFFFFFFF0000001E", which is wider than 64 bits. Removing the leading 8 'F's got the item type accepted by Inspect.Item.Detail().
    This is actually fixed on PTS, but if you need it on Live I can get it pushed over.

    • The new carnival items (very thin leather and helium flower or what they're called in the English client) have category = nil.
    This will happen sometimes - not all items have a valid category.

    • If I'm not mistaken it isn't possible to display cooldowns the same way as in the native frames or action bars.
    Not easily, though you could pre-bake a bunch of cooldown overlay images and display them as appropriate.

    • Calling Command.Tooltip(item) the tooltip is always anchored at the topleft of the screen. Would it be possible to extend Command.Tooltip() to accept positioning parameters similar to SetPoint? (a simplified version to have the tooltip appear at a frame's corner would suffice)
    • The ability to SetPoint() on a native frame would make it possible to "hide" the default inventory windows by moving them out of the screen. This way they stay open and keep working for the game but aren't visible to the user. SetVisible(false) would be needed when the user closes the Addon window by hitting X. In order for the frames not to stay hidden when the Addon is disabled the native frames might reset their position whenever they are closed, thus requiring a new SetPoint() every time they become visible.
    • It is a bit difficult to create an Addon which looks like the default Rift UI because the texture paths aren't known (or at least I wasn't able to find any info on this). I am thinking mainly about stuff like the currency icons, category buttons in the auction house, the tree collapse arrows, the dark "groups" in the Config Menu, the section header underlines in the Config Menu, and many, many more. I am really terrible at painting pretty pictures and having access to the UI textures would make things much much easier and consistent with Rift.
    • Is it possible to add formatting codes for Text frames to display multi-colored text or in-line images?
    These are on the TODO list, albeit possibly not coming up soon.

    I'm hoping to provide a SetDisabled() function for native windows so you can suppress them entirely, and maybe a Close() function for certain native windows to behave as if the player clicked the close box. These might take a while

    • It would be a big plus if the item tooltip could be extended with custom text. In the context of this Addon it is obviously adding item sums of other characters. Clearing the custom lines every time the tooltip target changes would ensure it is only filled with relevant information.
    This is probably not going to happen, unfortunately. I'd recommend using UI.Native.Tooltip and attaching an extra window relative to it.

    • Adding "inventory" to Inspect.Interaction and Event.Interaction would make it obsolete to modify UI.Native.BagInventory*.Event.Loaded (and possibly others). The current solution can cause incompabilities between addons if multiple try to observe this event. I first tried to add a new child frame to the native one so I wouldn't have to touch the original event handler, but unfortunately, that's not possible...
    "Interaction" is intended for interactions with gameworld entities, so you can do things like determine if it is possible to interact with the bank.

    I am, however, not satisfied with how the UI.Native events behave. They took on the behavior of the native frames, but it's possible I need a second event handler type to deal with situations where many addons are likely to hook the same events. I'm not quite sure how that should look (should I just re-use the global event system, maybe?) and I'm not quite sure how it should interact with the current event system. So, yeah, there's work left to be done here.

    • Adding a new field to item details called "new" (or similar) which reflects the "blinking" state in the default inventory plus a new Command.Item.Something() to clear this state would be great.
    I'd recommend you just store that flag internally. The "blinking" state isn't really part of the item itself, it's kind of part of how the default bags work. I think it makes sense for that to not be a global thing.

    • Here is my approach at solving the "use item" problem:
      There are already some predefined frames like "RiftButton". My suggestion is to add a new one called "RiftItemButton" (or "RiftActionButton" if one doesn't want to be limited to items only). Using the button would need setting it's target item or slot (if the current secure mode allows it). The button would then handle the user input and perform actions according to the button's target object the same way as the existing buttons do. Ideally the components (icon, border, highlight, item count, cooldown indicator, etc) could either be set to match the target item/slot or be modifiable individually if one chosed to for greater flexibility. Being able to hook the button events for secondary processing would be a big plus as well.
    What's realistically going to happen here - and note that this isn't going to happen *immediately*, but I'll get it in once I can - is that frames will gain a SetInventoryItem() function. With this set, clicking on that frame will behave as if you clicked on the equivalent inventory slot. It will probably not take on any graphical effects, it'll be up to you to add those as you see fit. This is sort of the sibling of SetMouseoverUnit(). I'm not quite sure how mouse events should work - should it be possible to override them, hook them, disable them, modify them, ??? - so there's probably a chunk of work left to do before this occurs.

    There is a potential way to provide "use", however - use the macro system to allow right-clicking an item to "/use" the item. Note that this will result in problems with hiding or showing the inventory system in combat. Not an ideal solution, I'll admit.

    Hopefully I'll be able to patch up a few of the holes for 1.8, but even if not, this looks like you're doing some great work!

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

    Default

    Quote Originally Posted by ZorbaTHut View Post
    This is actually fixed on PTS, but if you need it on Live I can get it pushed over.
    Well it will take quite some time before the Addon is in a state where it could be made public, so not in a hurry.


    Quote Originally Posted by ZorbaTHut View Post
    This will happen sometimes - not all items have a valid category.
    I'm guesstimating all nil categories to "misc" right now so it's not a problem.


    Quote Originally Posted by ZorbaTHut View Post
    Not easily, though you could pre-bake a bunch of cooldown overlay images and display them as appropriate.
    That might be a solution, time to get the dust of my photoshop...

    Quote Originally Posted by ZorbaTHut View Post
    I'm hoping to provide a SetDisabled() function for native windows so you can suppress them entirely, and maybe a Close() function for certain native windows to behave as if the player clicked the close box. These might take a while
    This sounds very good.

    Quote Originally Posted by ZorbaTHut View Post
    This is probably not going to happen, unfortunately. I'd recommend using UI.Native.Tooltip and attaching an extra window relative to it.
    Why the hell didn't I get this idea...

    Quote Originally Posted by ZorbaTHut View Post
    "Interaction" is intended for interactions with gameworld entities, so you can do things like determine if it is possible to interact with the bank.

    I am, however, not satisfied with how the UI.Native events behave. They took on the behavior of the native frames, but it's possible I need a second event handler type to deal with situations where many addons are likely to hook the same events. I'm not quite sure how that should look (should I just re-use the global event system, maybe?) and I'm not quite sure how it should interact with the current event system. So, yeah, there's work left to be done here.
    Good to see there goes some thought into it. For the sake of Addon interoperability it might be useful to change the Event handlers of all frames (UI.Native and normal) from functions to objects hookable by many observers. In case Addon1 wants to work with Addon2 by listening to its UI events.

    Thus the line
    Code:
    function frame.Event:LeftDown()
    end
    could change to
    Code:
    frame.Event.LeftDown:Hook(function(self)
    end
    This is something that could be easily prototyped in Lua. Maybe even squeezed in a "UI hook addon" for the start. Might work if authors used it consistently. Giving the hook object a __call metatable entry would leave it callable just like the existing event handlers as long as your C Lua API doesn't expect a "function" type.

    Quote Originally Posted by ZorbaTHut View Post
    ]I'd recommend you just store that flag internally. The "blinking" state isn't really part of the item itself, it's kind of part of how the default bags work. I think it makes sense for that to not be a global thing.
    Makes sense, yes.

    Quote Originally Posted by ZorbaTHut View Post
    What's realistically going to happen here - and note that this isn't going to happen *immediately*, but I'll get it in once I can - is that frames will gain a SetInventoryItem() function. With this set, clicking on that frame will behave as if you clicked on the equivalent inventory slot. It will probably not take on any graphical effects, it'll be up to you to add those as you see fit. This is sort of the sibling of SetMouseoverUnit(). I'm not quite sure how mouse events should work - should it be possible to override them, hook them, disable them, modify them, ??? - so there's probably a chunk of work left to do before this occurs.
    I see. It definitely sounds like a possible solution, though. About the graphics: Is it possible to get the paths to the textures which are present in the inventory UI? For example the icon frame, the "shiny" thing, the selected image, the empty slot and empty bag background etc? I'd like to have it all look as Rift as possible and I'm not sure about editing screenshots and copyright issues. In case the mouse-hover and blinking animations are present in separate textures it wouldn't be a problem to recreate them using already existing means.

    Quote Originally Posted by ZorbaTHut View Post
    There is a potential way to provide "use", however - use the macro system to allow right-clicking an item to "/use" the item. Note that this will result in problems with hiding or showing the inventory system in combat. Not an ideal solution, I'll admit.
    It is definitely something I might look into for some testing, thanks for the hint!

    Quote Originally Posted by ZorbaTHut View Post
    Hopefully I'll be able to patch up a few of the holes for 1.8, but even if not, this looks like you're doing some great work!
    Thank you, and thanks for your efforts!

  5.   Click here to go to the next Rift Team post in this thread.   #5
    Rift Team
    Join Date
    Oct 2010
    Posts
    927

    Default

    Quote Originally Posted by Imhothar View Post
    About the graphics: Is it possible to get the paths to the textures which are present in the inventory UI?
    I've tried to come up with a good way to provide this several times and ended up running into a wall each time. I've got a new idea that I'll work on once I no longer have time to add the big risky things for 1.8. No guarantees, but I acknowledge that it would be very useful.

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

    Default

    Cool, even though I was just thinking of a list of file paths and texture coordinates, but if you have bigger plans for it I'm the last one to stand in your way.
    Last edited by Imhothar; 03-02-2012 at 10:01 AM.

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

    Default

    I did some testing with the "hooking UI.Native events" issue. It turns out an event must be a function, otherwise the method "frameEventTable:(internal event creation)" throws an error.

    This makes the quite elegant solution using a metatable with a __call member not possible.

    So instead i hacked a library for hooking and unhooking frame events here. Right now it makes use of Utility.Event.Create() but I consider that a bit overkill and might replace it with something simpler.
    It's usage is quite straightforward:

    Code:
    LibNativeEventHook.Hook(UI.Native.BagInventory1, "Loaded", foo)
    
    LibNativeEventHook.Hook(UI.Native.BagInventory1, "Loaded", function(self)
        do something meaningful
    end)
    LibNativeEventHook.Hook() returns the passed function as a convenience feature for getting a handle to the in-place defined function.
    To remove a previously created hook:
    Code:
    LibNativeEventHook.Unhook(UI.Native.BagInventory2, "Loaded", hook)
    The addon is in fact rather simplistic, but the concept could be further enhanced to allow the hooking of any arbitrary method. If anyone thinks it's worth it I am going to do just that.

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

    Default

    New feature added: tooltip enhancement showing which of your characters own the displayed item how many times.

    But it's not flawless:
    1. There are only the two strata "implementation" and "main" available for Lua frames. The result is the custom frame attached to the tooltip appearing behind most frames. Is it possible to add additional strata which reflect the ones of UI.Native?
    2. Toolltips created with Command.Tooltip() appear in the top-left corner of the screen. Can I somehow influence that?
    3. It turns out UI.Native.Tooltip always reports having top=0 and bottom=1103 (result of GetBounds()), so I cannot rely on these values when I want to decide whether to attach the frame at the top or bottom (ReadAll() also returns some very confusing stuff). Attaching my frame to "BOTTOMLEFT" and "BOTTOMRIGHT" lets it disappear. I guess it is moved out of the bottom of the screen? "TOPLEFT" and "TOPRIGHT" work, though (as can be seen in the screenshot).

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

    Default

    Quote Originally Posted by Imhothar View Post
    There are only the two strata "implementation" and "main" available for Lua frames. The result is the custom frame attached to the tooltip appearing behind most frames. Is it possible to add additional strata which reflect the ones of UI.Native?
    If you check out the strata list for a context, you'll find there's actually a lot more strata available. Non-contexts are limited to implementation and main, contexts have all the stratas you'd expect.

    Quote Originally Posted by Imhothar View Post
    Toolltips created with Command.Tooltip() appear in the top-left corner of the screen. Can I somehow influence that?
    Not at this time. (Technically, they should appear where you have your tooltip anchor set - that's a per-player setting.)

    Quote Originally Posted by Imhothar View Post
    It turns out UI.Native.Tooltip always reports having top=0 and bottom=1103 (result of GetBounds()), so I cannot rely on these values when I want to decide whether to attach the frame at the top or bottom (ReadAll() also returns some very confusing stuff). Attaching my frame to "BOTTOMLEFT" and "BOTTOMRIGHT" lets it disappear. I guess it is moved out of the bottom of the screen? "TOPLEFT" and "TOPRIGHT" work, though (as can be seen in the screenshot).
    Which tooltip are you having the problem with? It's possible that one or two tooltip types are broken (right now, the item comparison tooltips throw a wrench into the works, for example. Bug, on the TODO list.)

    I find it helps to make a frame with a semitransparent color, then set TOPLEFT and BOTTOMRIGHT to see exactly where the Native frame thinks it is.

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

    Default

    Quote Originally Posted by ZorbaTHut View Post
    If you check out the strata list for a context, you'll find there's actually a lot more strata available. Non-contexts are limited to implementation and main, contexts have all the stratas you'd expect.
    Ah great, works now.

    Quote Originally Posted by ZorbaTHut View Post
    Not at this time. (Technically, they should appear where you have your tooltip anchor set - that's a per-player setting.)
    Maybe that is a bug then, because whenever I call Command.Tooltip() it appears in the topleft corner. I moved my tooltip anchor using the layout interface to 403, 727, 658, 747 if that helps. I also tried to move it while testing, but it didn't change anything.

    Quote Originally Posted by ZorbaTHut View Post
    Which tooltip are you having the problem with? It's possible that one or two tooltip types are broken (right now, the item comparison tooltips throw a wrench into the works, for example. Bug, on the TODO list.)

    I find it helps to make a frame with a semitransparent color, then set TOPLEFT and BOTTOMRIGHT to see exactly where the Native frame thinks it is.
    It's all about the main item tooltip UI.Native.Tooltip, didn't know we could reference others?

    So I tried what you suggestd and created a red frame with SetAllPoints(UI.Native.Tooltip). What I can observe now is that whenever the native inventory and action buttons create an item tooltip (only items, not spells or abilities) then I can see a red rectangle with the bounds 0, 0, 230, 1103 for a fraction of a second. Unit tooltips created in the game world, as well as spells or abilities do not show this behaviour.

    The tooltips I create with Command.Tooltip() always show a red rectangle at 0, 0, 230, 1103. For player items I set the tooltip target to Inspect.Item.Detail(slot).id, for other characters I use the item type. So just for fun I tried it with an ability id et voilą the tooltip as well as my red frame appear at the tooltip anchor.

    Thus attaching my frame to the bottom works as long as it's not a tooltip I trigger myself. But the very moment Event.Tooltip is raised the item(!) tooltip always has a bounds of 0, 0, 230, 1103 if it is an item, so I cannot use it to determine whether I should attach my frame to the top or bottom so it won't get clipped off-screen. I could of course postpone the anchoring for like 500ms but that's quite a dirty race condition hack.

  11. #11
    RIFT Community Ambassador the_real_seebs's Avatar
    Join Date
    Jan 2011
    Posts
    16,859

    Default

    Quote Originally Posted by Imhothar View Post
    Ah great, works now.

    Maybe that is a bug then, because whenever I call Command.Tooltip() it appears in the topleft corner. I moved my tooltip anchor using the layout interface to 403, 727, 658, 747 if that helps. I also tried to move it while testing, but it didn't change anything.
    Same, my regular tooltips are anchored somewhere else.
    You can play WoW in any MMO. You don't have to play WoW in RIFT. Oh, and no, RIFT is not a WoW clone. Not having fun any more? Learn to play, noob! I don't speak for Riftui, but I moderate stuff there. Just came back? Welcome back! Here's what's changed. (Updated for 2.5!)

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

    Default

    New feature and new problems

    The addon now scans mail attachments and adds the info to the tooltip summary. This is what I encountered:
    1. Performing a /reloadui with the native mail window opened causes Rift to crash. Tried it with all Addons disabled and it still crashed. Not sure if this is the right place to report it though. I had three mails in inbox with each having one attachment.
      Evil side effect: All action bars except the default one are empty after the crash...
    2. After handling Event.Mail I check my database against Inspect.Mail.List() to purge no longer existing mails from storage (as there is nothing like Event.Mail.Deleted). The algorithm is simple: if a mail in the database is not present in the table returned by Inspect.Mail.List() I delete it form the DB.
      When the mail window is closing, Event.Mail is triggered with all mails as arguments, BUT Mail.Inspect.List() returns an empty table.

      My current fix is to merge the "mails" argument of the event (where at this point all values are "false") with the table of Inspect.Mail.List(). So far it works, but it fails however when you delete the last mail, as then the merged table still contains the deleted mail.
    Last edited by Imhothar; 03-03-2012 at 03:51 PM.

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

    Default

    Quote Originally Posted by ZorbaTHut View Post
    There is a potential way to provide "use", however - use the macro system to allow right-clicking an item to "/use" the item. Note that this will result in problems with hiding or showing the inventory system in combat. Not an ideal solution, I'll admit.
    Another issue with the macro solution I just realized: It won't work with merchants, mails, auctions etc. basically every situation where an item is used in any other way than "consumed".

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

    Default

    Quote Originally Posted by ZorbaTHut View Post
    Which tooltip are you having the problem with? It's possible that one or two tooltip types are broken (right now, the item comparison tooltips throw a wrench into the works, for example. Bug, on the TODO list.)
    Something to add here: If the tooltip has item comparions then Event.Tooltip is fired once for the item in question, followed by many calls with type, shown and buff each being nil. Maybe that helps somehow.

    Besides, calling Command.Tooltip() for the same item id the tooltip does not show any item comparison.

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

    Default

    Dragging an item from an inventory frame onto my Addon buttons shows the "do you wish to destroy the item" dialog. This does not happen when I initiate the item drag with Command.Cursor().

    Can this behavior be changed so the destroy dialog only appears when the item is dropped on the 3D world?

+ Reply to Thread
Page 1 of 2 1 2 LastLast

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