+ Reply to Thread
Results 1 to 12 of 12

  Click here to go to the first Rift Team post in this thread.   Thread: UI elements and secure mode

  1. #1
    Champion
    Join Date
    Jun 2011
    Posts
    561

    Default UI elements and secure mode

    Fellow addon developpers

    Maybe someone can help me with an issue I have: is it really the case that SetVisible() is not possible on a frame which is bound to secure mode while I'm in fight?

    If I do SetVisible() on a frame which is not in secure mode that works perfectly fine. However if I want to show a secured frame in fight the API throws an error saying that's not possible.

    While I do understand the limitations needed to prevent addons from doing automated stuff, the SetVisible() restriction looks to me like a huge overkill. To some extend I can understand the reason behind the decision to prevent an addon from building a different UI element for every situation and display the needed one under the players cursor. But please there has to be another way.

    The way it is today any action bar oriented mod is not possible. I want to combine all different buttons for my various addons into one action bar plus add generic functionality like potions and consumables. However I don't see any way to achieve this with the current restriction.

    Cheers
    N.

  2. #2
    Telaran
    Join Date
    Oct 2011
    Posts
    86

    Default

    I had the same problem with Rift Healer. What I had to end up doing is making a main invisible frame and parenting alll my render frames to it. Then making making all my click frames parented to context but setpoint to that mainframe. I did have to add a combat check that locked any dragging and such to the rendered frames so nothing became offset but it saved me alot of headaches.

  3. #3
    Champion
    Join Date
    Jun 2011
    Posts
    561

    Default

    Quote Originally Posted by TinnerKB View Post
    I had the same problem with Rift Healer. What I had to end up doing is making a main invisible frame and parenting alll my render frames to it. Then making making all my click frames parented to context but setpoint to that mainframe. I did have to add a combat check that locked any dragging and such to the rendered frames so nothing became offset but it saved me alot of headaches.
    Hmm I think I haven't quite understood what you did. SetPoint() is restricted as well in secure mode. Do you mean that you build a seperat frame for the click functions? If so that would mean the frame is there and any clicking wouldn't go through to the UI behind.

    What I'm trying to achieve is an action bar consiting of a number of buttons. Upon click of any of a the buttons sub-buttons would pop up. These would actually hold the real functionality. However preparing the clickframes at the location where the sub buttons would eventually show up would mean that these areas of the UI are no longer clickable if I'd separat the UI element (buttons) from the clickable frame covering the area.

    Unless I missed your point, I think this will not help in my situation.

    Cheers
    N.

  4. #4
    Telaran
    Join Date
    Oct 2011
    Posts
    86

    Default

    Quote Originally Posted by Naifu View Post
    Hmm I think I haven't quite understood what you did. SetPoint() is restricted as well in secure mode. Do you mean that you build a seperat frame for the click functions? If so that would mean the frame is there and any clicking wouldn't go through to the UI behind.

    What I'm trying to achieve is an action bar consiting of a number of buttons. Upon click of any of a the buttons sub-buttons would pop up. These would actually hold the real functionality. However preparing the clickframes at the location where the sub buttons would eventually show up would mean that these areas of the UI are no longer clickable if I'd separat the UI element (buttons) from the clickable frame covering the area.

    Unless I missed your point, I think this will not help in my situation.


    Cheers
    N.
    Yup, had to make a complete set of click frames for the macros that overlayed the rendered frames. You can make your buttons nonrestricted if they are just gonna open subbuttons. they only frames that have to be restricted are the ones that actually run a macro. The bad thing about this in the way you have described is that those macro'd frames have to be set to visible in your Secure.Start event. else once you are in combat you cant make them appear/disappear. There has been some discussion about allowing some manipulation once in combat but not idea whats gonna happen or be allowed.

  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 TinnerKB View Post
    I had the same problem with Rift Healer. What I had to end up doing is making a main invisible frame and parenting alll my render frames to it. Then making making all my click frames parented to context but setpoint to that mainframe. I did have to add a combat check that locked any dragging and such to the rendered frames so nothing became offset but it saved me alot of headaches.
    For what it's worth, this is the intended solution.

  6. #6
    Telaran
    Join Date
    Oct 2011
    Posts
    86

    Default

    Quote Originally Posted by ZorbaTHut View Post
    For what it's worth, this is the intended solution.
    I am not complaining. Rift Healer is working great right now. But looking at what he is trying to do here, im not sure its possible the way restricted frames are setup. Once the click frames are enabled, you can no longer select something behind them so not sure what can be done.

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

    Default

    Quote Originally Posted by TinnerKB View Post
    I am not complaining. Rift Healer is working great right now. But looking at what he is trying to do here, im not sure its possible the way restricted frames are setup. Once the click frames are enabled, you can no longer select something behind them so not sure what can be done.
    Yeah, I'm pretty sure it's not possible either. It would open the door to a lot of unintended automation, unfortunately.

  8. #8
    jca
    jca is offline
    Rift Chaser
    Join Date
    Mar 2011
    Posts
    314

    Default

    I'm handling it pretty much the same way as TinnerKB.

    I understand what the OP's trying to do and in that particular application it wouldn't be harmful, but as Zorba said, I don't see how you could enable that w/o opening to door to a lot of harmful things such as having addons selecting the appropriate ability for a button at an given time, etc.

    Something interesting to mess with. Anchor a secure frame to a non-secure frame and move the non-secure frame off-screen. Then during combat, move the non-secure frame back to a visible area of the screen. Doing so doesn't call any protected functions on the secure frame but the result is interesting. Zorba is a step ahead of us I guess hehe ;)

  9. #9
    Champion
    Join Date
    Jun 2011
    Posts
    561

    Default

    While I fully support to keep pandora's box closed there has to be a way to achieve some more fexibility. Warcraft, Warhammer and Runes of Magic managed to do it so there has to be a way. Ok Runes of Magic isn't that good of an example. While there wasn't much harm in building action bars, one could do some very nasty stuff with their API.

    Here are some suggestions I could come up for future API enhancements:

    - Implement a new function like for example SetActive(true/false) which would allow authors to activate / deactivate the events on a frame on the fly in secure mode. That way the click frame could be there but as long as the 'ui element' frame is not visible it wouldn't block the UI behind. As only the top frame gets the user interaction you'd go around any potential problem of misuse of the API.

    - Throttle down SetParent() or SetVisible() of secured frame down to something like once every one or two seconds

    - Build an API element which allows to build popup action bars and the API handles the opening / closing and clicking and refuses changes to the elements in secure mode

    Just some thoughts about this issue.

    Cheers
    N.
    Last edited by Naifu; 01-03-2012 at 10:38 PM.

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

    Default

    The potential abuse goes roughly like this:

    Stack 30 buttons on each other. Disable all but one. Now enable and disable them on the fly to make it so only one receives clicks, and you've allowed software to pick which button the user presses. So if I have one button per cleanse per party member, I can just click a region of the screen over and over and cleanse whatever the software thinks I should...
    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!)

  11. #11
    Champion
    Join Date
    Jun 2011
    Posts
    561

    Default

    Quote Originally Posted by the_real_seebs View Post
    The potential abuse goes roughly like this:

    Stack 30 buttons on each other. Disable all but one. Now enable and disable them on the fly to make it so only one receives clicks, and you've allowed software to pick which button the user presses. So if I have one button per cleanse per party member, I can just click a region of the screen over and over and cleanse whatever the software thinks I should...
    Easy solutions. The API can already check the topmost intactable ui element as two frames on top of each other inly the top one receives the events already now. Nothing should change here. Just make it so, that the top most frame catches the event, but redirects the interaction down to the standard ui if deactivated.

    And regarding the cleanse remark .. It's not as if one could simplify cleansing aleady down to one button spamming using the standard macro system of Rift ...

    Cheers
    N.

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

    Default

    Yeah, the macro system is pretty horrid. I would actually prefer something similar to WoW's, complete with /castsequence and the mini-scripting-language for conditionals, because it would result in more decision making by players.
    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!)

+ 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