+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 31 to 45 of 57
Like Tree1Likes

  Click here to go to the first Rift Team post in this thread.   Thread: Event API Redesign

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

    Default

    Quote Originally Posted by ZorbaTHut View Post
    I guess I don't understand why you can't do this entirely within addon space.
    You can do this within addon space, but any chance to eliminate hooking Event.System.Update is a performance improvement. I am not sure if this is possible, but you could workaround, sort of. Register events, create a frame, call the passed event function to the frame. Event.Buff.Add is a bad example for eliminating Event.System.Update because if you want to know if buffs have changed, use Event.Buff.Changed instead. However, there must be Inspectors that if you want current values, registering for E.S.U. is the only way.

    I just proposed registering events on frames in order to regulate E.S.U. to merely timekeeping purposes.
    Quote Originally Posted by Grinderofl View Post
    I definitely agree with Lorandii, if only for performance reasons:

    You're only interested in boss buffs, if you have a bossframe, you need to go through all units and find the one you need, the loop of all units might be cheap, but if you have many of those, it adds up.
    Quote Originally Posted by 0dine View Post
    Lorandii's post nailed it! I liked the way..... that other game..... handled events
    It is great to see and have some support, but I was trying NOT to be exactly like the other game. Instead, I was going for improvements that are "Rift-like" and "better than that other game" combined. Changes that make you think "Yeah, that is familiar to how Rift was before" yet simplified, streamlined, and most importantly, developer friendly. Not mention as future-proof as I could think at this time.

    Could someone explain Dive and Bubble in layman's terms? I do not quite follow what they are supposed to do or accomplish.

    And maybe this is just me trying for an ego boost, but in a general view or way, Zorba, what do you think of my suggestions? I am only asking because everybody else is talking about Dive and Bubble, and other addon developers have discussed parts of my posts, but what do you think? Are they workable, or useless feedback?

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

    Default

    Quote Originally Posted by Lorandii View Post
    However, there must be Inspectors that if you want current values, registering for E.S.U. is the only way.
    While there may be, this would be considered a bug, and the fix would be to add events for them (If you know of any, let me know! I don't *think* there are any right now but I haven't gone over the small-fix list in a while)

    Quote Originally Posted by Lorandii View Post
    Could someone explain Dive and Bubble in layman's terms? I do not quite follow what they are supposed to do or accomplish.
    I am going to let someone else do this to ensure that people besides me actually understand what's going on :V

    Quote Originally Posted by Lorandii View Post
    And maybe this is just me trying for an ego boost, but in a general view or way, Zorba, what do you think of my suggestions? I am only asking because everybody else is talking about Dive and Bubble, and other addon developers have discussed parts of my posts, but what do you think? Are they workable, or useless feedback?
    I think it's one of those difference-between-end-developer-and-API-developer deals. There's nothing in there that I'm looking at and saying "ha ha that's a dumb idea", they're all perfectly reasonable extensions to the API and I can see how they would make development easier. However, as the API developer, I can't justify the time spent on them when I see bigger and juicier targets. My TODO list is somewhere around 500 lines long now, so anything that can be done efficiently within the addon system without API support is very likely to be deferred in favor of things that can't be done.

    For example, right now I'm putting together the final XP/Planar-Attunement-Progress API, because there is currently literally no way to retrieve your planar attunement progress before level 60.

    All feedback is appreciated, and I read every single post made. Even when it's something I don't immediately agree with (for example, the early complaints that removing event handlers was difficult) enough consistent chatter about it can eventually change my mind (for example, this post, which fixes the problem that removing event handlers is difficult). But it's always a tightrope walk between bugfixes, quality-of-life improvements, and API additions, so often, no matter how totally reasonable a request is, it's not gonna happen for a while just due to priorities.

    For what it's worth, I'd love to see a user library that provided the features you're asking for.

  3. #33
    RIFT Guide Writer Noshei's Avatar
    Join Date
    Feb 2011
    Posts
    1,879

    Default

    Quote Originally Posted by Lorandii View Post
    Could someone explain Dive and Bubble in layman's terms? I do not quite follow what they are supposed to do or accomplish.

    Do you know what a phone tree is? We used these in the military to pass information, usually when we had to get to base ASAP, from the top of our chain of command to the lowest person.

    The idea being that the information starts at the very top, they call the next level to pass along the information. The people at the second level then call the people at the third level. This process repeats until the information has reached everyone at every level.

    Now this differs slightly from how Dive/Bubble works in that the information is only passed to a single low lever entity instead of everything.

    To give a more visual aspect to what Zorba described with code I make a little image.
    Event API Redesign-dive-bubble.jpg

    So say an event occurred on the frame Target 2a, with the Dive/Bubble concept that event process doesn't start at the location the event occurred, but at the highest level (aka UIParent). From there the Event will Dive down, through all of the different levels until it reaches the frame the event actually occurred on. Once the event is triggered the process then works in reverse from the low level target beck to the top level UIParent.


    Another analogy I think might be useful in describing how this works is bouncing a ball. When you bounce a ball it first starts at the high point and then falls (or Dives) down to the ground. When the ball hits the ground an Event occurs and the ball is then forced back up (or Bubbles) to where it started.

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

    Default

    Quote Originally Posted by ZorbaTHut View Post
    While there may be, this would be considered a bug, and the fix would be to add events for them (If you know of any, let me know! I don't *think* there are any right now but I haven't gone over the small-fix list in a while)
    The passage of time per se.

    ... which is why I wrote LibCron.

    I am going to let someone else do this to ensure that people besides me actually understand what's going on :V
    My explanation:

    Containers are implicitly given a chance to intercept events that would otherwise go to their contents, in cacse they have some reason to want to override. For instance, a window might want to intercept any click on it when it's behind other windows, so it can bump itself forward, and then you want that to happen instead of the click reaching the UI item in the window. Or maybe you don't want to. Or maybe you only want to sometimes... So everything between the top level UI and the specific item gets a chance to say "hang on, that's for me".

    And on the way back up, you get a chance to take action based on an event having been processed.

    I think it's one of those difference-between-end-developer-and-API-developer deals. There's nothing in there that I'm looking at and saying "ha ha that's a dumb idea", they're all perfectly reasonable extensions to the API and I can see how they would make development easier. However, as the API developer, I can't justify the time spent on them when I see bigger and juicier targets. My TODO list is somewhere around 500 lines long now, so anything that can be done efficiently within the addon system without API support is very likely to be deferred in favor of things that can't be done.
    Unix programmers might recognize this as the gap between syscalls and the standard library.

    Sure, printf's super handy to have... but you don't need the kernel to be the one providing it. The kernel has to give you the ability to create files, write to them, and so on. Given that, it's easy to do the rest.

    Basically, think about all the addon framework code that WoW acquired (note: Rift forums do not prohibit talking about other games specifically) over the years. In some cases, that was because the basic API was painful to use (*cough* AfterCast *cough*), but in some cases it was because the basic API was adequate, but not fancy.

    My impression of the Rift API hunks I've used so far is that the API is intending to provide you all the necessary primitives, but not utility and convenience stuff, because addon devs can write and share utility and convenience stuff.

    For example, right now I'm putting together the final XP/Planar-Attunement-Progress API, because there is currently literally no way to retrieve your planar attunement progress before level 60.
    CreateFancyDialog("Please enter your current PA totals, and the names of the abilities you have trained...")

    People are just lazy is all.

    All feedback is appreciated, and I read every single post made. Even when it's something I don't immediately agree with (for example, the early complaints that removing event handlers was difficult) enough consistent chatter about it can eventually change my mind (for example, this post, which fixes the problem that removing event handlers is difficult). But it's always a tightrope walk between bugfixes, quality-of-life improvements, and API additions, so often, no matter how totally reasonable a request is, it's not gonna happen for a while just due to priorities.

    For what it's worth, I'd love to see a user library that provided the features you're asking for.
    Wouldn't be hard at all to implement, if I understand the intent correctly.
    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!)

  5. #35
    Telaran
    Join Date
    Jun 2011
    Posts
    82

    Default

    Quote Originally Posted by Lorandii View Post
    It is great to see and have some support, but I was trying NOT to be exactly like the other game. Instead, I was going for improvements that are "Rift-like" and "better than that other game" combined. Changes that make you think "Yeah, that is familiar to how Rift was before" yet simplified, streamlined, and most importantly, developer friendly. Not mention as future-proof as I could think at this time.
    It was not my intent to completely mimic/copy that other game, but I do like the general idea proposed! Now im going to shush though as my knowledge doesnt span wide enough to get further involved in this thread

  6. #36
    Rift Disciple
    Join Date
    Jan 2011
    Posts
    147

    Default

    Perhaps I'm just dense, but I'm struggling to see how this new design applies to custom frames that want to generate their own events like RadioButtonClicked or ListItemSelected for example.

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

    Default

    Quote Originally Posted by dOxxx View Post
    Perhaps I'm just dense, but I'm struggling to see how this new design applies to custom frames that want to generate their own events like RadioButtonClicked or ListItemSelected for example.
    It makes it much easier to create new event types. You could create a new type UI.Event.Radio.Clicked, for example, and then hook UI.Event.Radio.Clicked.Dive events on native frames that have never heard of your custom event, but have the event processing still work properly.

    Note that this functionality may not be available on the first revision of the new system, but it's at least possible to rig up in the future.

  8. #38
    Rift Disciple
    Join Date
    Jan 2011
    Posts
    147

    Default

    Quote Originally Posted by ZorbaTHut View Post
    It makes it much easier to create new event types. You could create a new type UI.Event.Radio.Clicked, for example, and then hook UI.Event.Radio.Clicked.Dive events on native frames that have never heard of your custom event, but have the event processing still work properly.

    Note that this functionality may not be available on the first revision of the new system, but it's at least possible to rig up in the future.
    Would the existing Event tables disappear from frame objects when the first revision of the new system is implemented?

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

    Default

    Couple general questions about priority:
    * Is behavior when two hooks list the same priority defined? Consistent between UI loads? Consistent between events within a single UI load?
    * Does the list of hooks give you information like which addons are hooking things?
    * Are you allowed to remove a hook you didn't add? ("you" meaning a given Inspect.Addon.Current())

    Also, it seems to me: There are things you might want to do in response to an event hook, but which cannot be done during the hook. You can, of course, have an Event.Update.Begin hook that then does these other things, unless you are trying to do it for your hook for that.

    What if handle could also take:

    :After(function)

    which would be a function that would be queued up to be executed in an unspecified order after the current event is done processing, at a time when it is safe and permissible to alter the hooks for that event? So, if I want to unhook something once I process a given instance of it, the code once I've determined that I am done watching this event is:

    handle:After(function() Command.Event.Detach(this_event, this_hook) end)

    Basically, the issue is: If this isn't available, then when do I detach a no-longer-needed hook? The only solution I can see is to add some other hook somewhere for a different event, and cause it to get the information that this hook needs to be detached from this event. But the only obviously guaranteed events to come along are the system update ticks of various sorts. And then we have the problem: How do I detatch from one of those?
    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!)

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

    Default

    Quote Originally Posted by the_real_seebs View Post
    Couple general questions about priority:
    * Is behavior when two hooks list the same priority defined? Consistent between UI loads? Consistent between events within a single UI load?
    Consistent between events within a single UI load. Realistically it's probably going to be the stronger guarantee, but I'm not making that as an official guarantee.

    Quote Originally Posted by the_real_seebs View Post
    * Does the list of hooks give you information like which addons are hooking things?
    Yep, it'll include "owner" as well as all the parameters passed in.

    Quote Originally Posted by the_real_seebs View Post
    * Are you allowed to remove a hook you didn't add? ("you" meaning a given Inspect.Addon.Current())
    Absolutely.

    Quote Originally Posted by the_real_seebs View Post
    :After(function)

    which would be a function that would be queued up to be executed in an unspecified order after the current event is done processing, at a time when it is safe and permissible to alter the hooks for that event? So, if I want to unhook something once I process a given instance of it, the code once I've determined that I am done watching this event is:

    handle:After(function() Command.Event.Detach(this_event, this_hook) end)

    Basically, the issue is: If this isn't available, then when do I detach a no-longer-needed hook? The only solution I can see is to add some other hook somewhere for a different event, and cause it to get the information that this hook needs to be detached from this event. But the only obviously guaranteed events to come along are the system update ticks of various sorts. And then we have the problem: How do I detatch from one of those?
    Hmmmmm.

    How about this guarantee: Modifying an event's hooks during the time the event is being called may or may not call the hook you're modifying. However, it is guaranteed to work properly in all other respects, i.e. it will still call every event that you didn't modify, it won't accidentally double-call unrelated handlers (unless you keep adding and removing the same event I suppose, in which case, stop that), it won't crash, etc.

    So the answer to when you detach a no-longer-needed hook: as soon as you are aware that it is no longer needed.

    I think I can actually guarantee that it will update the hook list immediately, but I'll have to play around with the code to make sure that can be efficient.

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

    Default

    Quote Originally Posted by dOxxx View Post
    Would the existing Event tables disappear from frame objects when the first revision of the new system is implemented?
    It'll be the standard deprecation system we use. For a while, both systems will exist in harmony. Later, the old style will exist only in compatibility mode. After that, the old style will vanish, along with compatibility mode (again).

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

    Default

    Quote Originally Posted by ZorbaTHut View Post
    I think I can actually guarantee that it will update the hook list immediately, but I'll have to play around with the code to make sure that can be efficient.
    I think it would be safer if modifying the even hook list while it is executing was not an immediate change but delayed until after the hanlders have finished. This is easyily accomplished by making a temporary copy of the hook list before running the hanlders (think of the copy-and-swap pattern) and should make stuff like recursively inflating the hook list impossible.
    Author of the Imhothar's Bags addon.

  13. #43
    RIFT Fan Site Operator Qube's Avatar
    Join Date
    Nov 2011
    Posts
    263

    Default

    Quote Originally Posted by ZorbaTHut View Post
    It'll be the standard deprecation system we use. For a while, both systems will exist in harmony. Later, the old style will exist only in compatibility mode. After that, the old style will vanish, along with compatibility mode (again).
    Out of curiosity - what is the timeline on this? I was experimenting with something that might be a lot easier with this system by the sounds of it?

    No need to give any specific timelines - extremely vague works fine. I more or less just have a limited amount of free time and would like to use it where it won't be.. wasted.

  14. #44
    Rift Disciple
    Join Date
    Jan 2011
    Posts
    147

    Default

    Quote Originally Posted by ZorbaTHut View Post
    It'll be the standard deprecation system we use. For a while, both systems will exist in harmony. Later, the old style will exist only in compatibility mode. After that, the old style will vanish, along with compatibility mode (again).
    Cool. I should be able to keep my widget library working through the transition then.

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

    Default

    Quote Originally Posted by theepiphany View Post
    Out of curiosity - what is the timeline on this? I was experimenting with something that might be a lot easier with this system by the sounds of it?

    No need to give any specific timelines - extremely vague works fine. I more or less just have a limited amount of free time and would like to use it where it won't be.. wasted.
    At the absolute earliest, 2.2 for the new features to show up.

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 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