+ Reply to Thread
Results 1 to 5 of 5

  Click here to go to the first Rift Team post in this thread.   Thread: Equipping Items - Event Handling lessons learned

  1. #1
    RIFT Guide Writer Wylt's Avatar
    Join Date
    Oct 2011
    Posts
    910

    Default Equipping Items - Event Handling lessons learned

    I just finished a 3 day battle with the API event handling triggers to get gear swapped between wardrobe & bags slots and the character's equipment slots. I now have it working 99.99999% of the time flawlessly (I haven't been able to break it after my last change). So I figured I would add some lessons learned for anyone else trying to write addons that do this kind of thing.

    First and foremost, this is for an addon I'm writing named Gadgets: Outfitter. This addon currently functions in the following capacity:
    1. I can build, Save, Edit & Load equipment sets plus their configuration settings into a config window
    2. I can build expandable/collapsable button bars on screen that match what has been configured in the window
    3. I can equip gear (and add it to the set) by dragging any item onto the config window, from any bag or wardrobe slot
    4. I can swap entire sets of gear with 1 click, no matter where the desired piece of gear is stored (already worn, in a bag, in a wardrobe)

    What I can't do right now, for some reason, is issue /role # commands and the like. I need to be able to trigger those commands AND swap gear with 1 click and it's just not playing nice right now. I'll figure it out soon enough (if anyone has any tips, wykkyd.gaming@gmail.com please).

    Lessons Learned:

    First - You can't equip items directly out of Wardrobe without them first going to a bag slot.

    Second - Event.Item.Slot updates are not to be trusted explicitly in all conditions. If I'm changing a piece of gear out from a bag slot and the slot I'm trying to equip it in already contains an item, the two items swap places... sort of. The equipped item may or may not always land in the same bag space the item you're equipping was in prior. Worse still, you get 2 Event.Item.Slot triggers for that one move.

    Considering our first lesson learned you might think, "Oh I'll just move wardrobe piece 1 to a bag slot, then swap with the equipped item, then pull the old equipped item out of the bag and throw it into the wardrobe slot". In principle that flow is correct. But considering our second lesson learned, it just won't work. Because you can't actually just issue 3 equip commands sequentially like that if they depending on things reaching a certain state first. Command 2 in that chain would issue the same error as trying to go directly from wardrobe to equip because command 1 really hasn't finished processing before command 2 fires.

    Third - We have to get tricky to mass move items from non bag slots, or swap gear multiple times from-to anywhere. So I had to build a scheduling system. My first version watched Event.Unit.Slot updates and waited for the final results of 1 command to exist before continuing to the next command. The problem here is that those conditions might not (read: didn't) line up correctly before Event.Unit.Slot just stops registering events, and thus your queue stops processing.

    So I had to get even trickier...

    Fourth - Watching Event.System.Update.Begin was much more garaunteed to generate results... however, it was firing too quickly. In fact... in what I like to refer to as "Holy Crap Slow Down" seconds. IE: Stupidly fast. So my next iteration of my gear swapping queue system was a complete and utter failure for different reasons. Progress, right? Wrong. I crashed Rift. Twice.

    Fifth - So I had to implement a means of reserving the right to process, and running certain things that I knew wouldn't collide in "batches". Thus my Event.System.Update.Begin method basically says, "If I'm not running already and things are in the queue, flag that a process is already running and then run a batch". The next series of Event.System.Update.Begin triggers all see something is "in process" and therefor they do nothing... until something frees up the process.

    This allowed me to safely enter batch mode where I could dump a series of equip commands before freeing the process, all under a blanket of safety. To help facilitate this I even split equip commands into 4 different stages, each stage firing in order but only after the previous stage had completed processing.

    However...

    Sixth - ...this lead to my 6th lesson: Free bag slots can't be trusted willy nilly. I'd issue a move command for 6 wardrobe items only to see them all try to jam their way into the same bag slot, which meant they failed and that meant I didn't get my gear swapped like I wanted. Ugh!

    So I added a method that finds & catalogs all empty bag slots so that I could pull from that list 1 by 1 for each item move. I also, at the same time, had to change my queueing system so that every equip used a pcall() to issue the command, every command only issued when an item was either sitting in a predicted item slot OR the item was NOT in the slot I'd wanted it out of. And every time I move an item I have to rebuild the queue to cleanly drop that queued move out of the stack, and then kick the process over to the next update.


    Ultimately gear now swaps extremely quickly between wardrobe & worn, or bags & worn, or a combination thereof. I can have my Tank gear in Wardrobe 4 while wearing DPS gear. Press 1 button and I'm wearing full tank gear with my DPS gear in Wardrobe 4. Awesomesauce. (and it's coming your way if you download the addon when I'm done).


    Anyway, I figured I couldn't be the only person dealing with this kind of situation so I thought I would share.

    Seventh - I'm really not surprised this kind of addon hasn't been published yet. This has been painfully frustrating.
    Note: I was an Outfitter user in WoW, and an nkWardrobe user since December. This goes above and beyond what nkWardrobe for moving gear, though... you'll see what I mean soon enough)


    For any dev's that happen by:
    - It would be nice if there was a "Wait for command to complete" version of command objects, like item moves. It'd be very nice and make a lot of this much less headache inducing.
    - It would also be nice if there was a clean way to remove event triggers that WE generate.
    - It would also be nice if we could DESTROY frames we've created.
    Last edited by Wylt; 08-28-2012 at 07:09 AM.

  2. #2
    Sword of Telara DoomSprout's Avatar
    Join Date
    Apr 2011
    Posts
    876

    Default

    Wow, sounds like you've been having fun there! Really really looking forward to seeing this when you release it.

    I think on the role command, the only way to do it would be to associate a macro with the button that did something like:

    role 1
    script Outfitter.SwitchToRole(1)

    (assuming your equipment swapping can happen while the cast of the role change is on-going ofc)

    This means your buttons have to be secure, along with every frame up the chain, and all the pain that this brings
    Last edited by DoomSprout; 08-28-2012 at 06:49 AM.

    Gadgets: Unit Frames and Other Stuff for RIFT

  3. #3
    RIFT Guide Writer Wylt's Avatar
    Join Date
    Oct 2011
    Posts
    910

    Default

    Quote Originally Posted by DoomSprout View Post
    Wow, sounds like you've been having fun there! Really really looking forward to seeing this when you release it.

    I think on the role command, the only way to do it would be to associate a macro with the button that did something like:

    role 1
    script Outfitter.SwitchToRole(1)

    (assuming your equipment swapping can happen while the cast of the role change is on-going ofc)

    This means your buttons have to be secure, along with every frame up the chain, and all the pain that this brings
    Ahh yes, I forgot about the buttons needing to be secure. That's easy enough though since the button bars themselves are small and self contained. The popup windows I generate are of a different context, so they are fine as is and won't be impacted. Thanks!

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

    Default

    Quote Originally Posted by Wylt View Post
    - It would be nice if there was a "Wait for command to complete" version of command objects, like item moves. It'd be very nice and make a lot of this much less headache inducing.
    There is, sort of! Many Command.* functions will support an optional callback. If you wrap your process in a coroutine, and set the callback up to resume the coroutine, you'll get the effect you want. I'm not sure offhand if Command.Item.Move() supports a callback, but if it doesn't, it should - let me know if it's missing.

    We can't simply block until completion for a few reasons. The most fundamental reason is that commands require a server round-trip to complete, which would mean that the entire client would lock up for about a tenth of a second for every command (or more, if the user has bad lag.) Even doing that would require huge changes to Rift's architecture, though.
    Last edited by ZorbaTHut; 09-05-2012 at 04:21 PM.

  5. #5
    RIFT Guide Writer Wylt's Avatar
    Join Date
    Oct 2011
    Posts
    910

    Default

    Thanks for the response! I'll check that out next time I find a need to re-write what it does. For now it works smoothly and quickly and I am afraid to touch it again. After the thread above I'm sure you can understand why ;)

    I'd welcome any feedback you have on the addon itself (code-wise, or in use in game...)

+ 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