Closed Thread
Page 2 of 30 FirstFirst 1 2 3 4 5 6 12 ... LastLast
Results 16 to 30 of 439
Like Tree4Likes

  Click here to go to the first Rift Team post in this thread.   Thread: Addon system bug reports

  1. #16
    Rift Team
    Join Date
    Oct 2010
    Posts
    927

    Default

    Quote Originally Posted by Semele View Post
    *.Event:LeftDown() seems to now trigger for each frame no matter which one was clicked. Double checked with your buff bars example, and it does indeed now cancel all buffs when clicking just one.

    *.Event:LeftUp() has now stop reporting entirely.
    We're in the middle of redesigning the mouse event backend and the implementation may be flaky for a little bit. We'll keep you posted.

  2. #17
    Soulwalker
    Join Date
    Jul 2011
    Posts
    9

    Default Text Frame :SetText breaks with numerics

    No rendering with the return value ".level of "Inspect.Unit.Detail(..)" with :SetText of "UI.CreateFrame("Text", ..."

    My Workaround is ":SetText(level.." ");"
    Last edited by fatalus; 07-15-2011 at 09:13 AM.

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

    Default

    Quote Originally Posted by fatalus View Post
    No rendering with the return value ".level of "Inspect.Unit.Detail(..)" with :SetText of "UI.CreateFrame("Text", ..."

    My Workaround is ":SetText(level.." ");"
    You can also do tostring(level). It's a number, not a string, so I'm not sure we should be trying to display it. I'll think about this one, though.

  4. #19
    Rift Disciple hp94's Avatar
    Join Date
    Feb 2011
    Posts
    175

    Default

    Quote Originally Posted by ZorbaTHut View Post
    We're in the middle of redesigning the mouse event backend and the implementation may be flaky for a little bit. We'll keep you posted.
    Ya, a lot of my OnClick type events are acting differently than I expected. Should I just wait until we get the go-ahead before trying to program around it?

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

    Default

    Quote Originally Posted by hp94 View Post
    Ya, a lot of my OnClick type events are acting differently than I expected. Should I just wait until we get the go-ahead before trying to program around it?
    Probably, yeah. Work on other parts of your addon

  6. #21
    Plane Walker Kreiri's Avatar
    Join Date
    Feb 2011
    Posts
    402

    Default

    sometimes Event.Ability.Cooldown.* gives spell IDs, for which Inspect.Ability.Detail returns nil.
    Example:
    a0000000030042499 - Flicker
    Feminism is the radical notion that women are people.

  7. #22
    Soulwalker
    Join Date
    Feb 2011
    Posts
    19

    Default

    This could be me not understanding the function usage

    Code:
    context = UI.CreateContext("test");
    frame = UI.CreateFrame("Frame", "Test", context);
    frame:SetSecureMode("restricted");
    Code:
    [Test] stack traceback:
    [Test] 	[string "Rift core"]:231: in function <[string "Rift core"]:230>
    [Test] 	[C]: in function 'SetSecureMode'
    [Test] 	Test/core.lua:3: in function 'func'
    [Test] 	[string "Rift core"]:229: in function <[string "Rift core"]:228>
    [Test] 	[C]: in function 'xpcall'
    [Test] 	[string "Rift core"]:228: in function <[string "Rift core"]:227>
    Is apparently incorrect but

    Code:
    frame:SetSecureMode("normal");
    works fine. In both cases calling the function while not in secure mode, I'll admit I could be missing something obvious.

  8. #23
    Sword of Telara Semele's Avatar
    Join Date
    Mar 2011
    Posts
    872

    Default

    Quote Originally Posted by Padawan View Post
    This could be me not understanding the function usage

    Code:
    context = UI.CreateContext("test");
    frame = UI.CreateFrame("Frame", "Test", context);
    frame:SetSecureMode("restricted");
    Code:
    [Test] stack traceback:
    [Test] 	[string "Rift core"]:231: in function <[string "Rift core"]:230>
    [Test] 	[C]: in function 'SetSecureMode'
    [Test] 	Test/core.lua:3: in function 'func'
    [Test] 	[string "Rift core"]:229: in function <[string "Rift core"]:228>
    [Test] 	[C]: in function 'xpcall'
    [Test] 	[string "Rift core"]:228: in function <[string "Rift core"]:227>
    Is apparently incorrect but

    Code:
    frame:SetSecureMode("normal");
    works fine. In both cases calling the function while not in secure mode, I'll admit I could be missing something obvious.
    Although the Error received is ambiguous, I figured it was something to do with the parent chain also not having the "restricted" flag set.

    If you change your example to below, it'll work. So make sure every parent is in restrictive mode also.

    Code:
    context = UI.CreateContext("test");
    context:SetSecureMode("restricted");
    frame = UI.CreateFrame("Frame", "Test", context);
    frame:SetSecureMode("restricted");
    The above should work. Took some head-scratching, but the usual epiphany while drifting off to sleep had me test this today.
    Last edited by Semele; 09-02-2011 at 09:04 AM.
    Rank 76 Guardian Mage

  9. #24
    Soulwalker
    Join Date
    Feb 2011
    Posts
    19

    Default

    Ah thanks.

  10. #25
    BRG
    BRG is offline
    Soulwalker
    Join Date
    Sep 2011
    Posts
    5

    Default Buffs with no duration have inconsistent duration fields

    The .duration fields of a buff's details (fetched via Inspect.Buff.Details) is inconsistent for buffs with no duration (those that last forever). I've tested a few buffs and I know that a shaman's passive buffs (Heart and Courage spells) will have .duration = nil. On the other hand, the Rested buff and a justicar's Mien spells have a buff duration of 0.

    Although trivial to work around, I imagine that these no duration buffs should all have the same .duration field.

  11. #26
    Plane Touched Levva's Avatar
    Join Date
    Jan 2011
    Location
    Aberdeen, Scotland
    Posts
    243

    Default

    Code:
    	local unitdetail = Inspect.Unit.Detail("group02")
    This seems to return nil if the player identified by "group02" is offline, yet the default UI knows that the player exists. Is there something odd when using a unitSpecifier in Inspect.Unit.Detail vs a unitID?

    It kind of makes the .offline value of Inspect.Unit.Detail redundant if you can't get to the parent object when the player is offline.

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

    Default

    Quote Originally Posted by Levva View Post
    Code:
    	local unitdetail = Inspect.Unit.Detail("group02")
    This seems to return nil if the player identified by "group02" is offline, yet the default UI knows that the player exists. Is there something odd when using a unitSpecifier in Inspect.Unit.Detail vs a unitID?

    It kind of makes the .offline value of Inspect.Unit.Detail redundant if you can't get to the parent object when the player is offline.
    I can't reproduce this - it was true at one point, but it was fixed about a month ago. Can you doublecheck?

    I'm logging in two characters, joining a group, having the non-leader log off, and doing "/script dump(Inspect.Unit.Detail("group02"))" on the remaining character. I get {name = "CharacterName", offline = true}.

    Note that the group IDs can have unexpected ordering - make sure the dump() works properly when they're logged on, I *think* it preserves the group ordering when someone logs off. Worst-case, try everything from group01 through group05, or hook Event.Unit.Detail.Offline.

  13. #28
    Plane Touched Levva's Avatar
    Join Date
    Jan 2011
    Location
    Aberdeen, Scotland
    Posts
    243

    Default

    I'll investigate further this evening (10:05am UK time here). My current code is doing a loop from group01-group20 to check all possible raid members and skipping if nil returned. I was in a test party checking syntax of new role feature, having got the role stuff working I thanked the guy helping me and he disconnected rather than logging off thus leaving him in the party and the UI showing him as offline. However my code was no longer detecting him.

    Tonight I'll pop round to mates and bug him to login/out several times so I can test things and see if I can come up with sample code illustrating the issue. (Assuming of course there is an issue and the bug isn't in my code).

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

    Default

    Quote Originally Posted by Levva View Post
    Tonight I'll pop round to mates and bug him to login/out several times so I can test things and see if I can come up with sample code illustrating the issue. (Assuming of course there is an issue and the bug isn't in my code).
    Let me know what you figure out If it helps, here's the one-line test script I just used to try out raids:

    /script print("---") for i = 1, 20 do local dat = Inspect.Unit.Detail(string.format("group%02d", i)) if dat then dump(i, dat) end end

  15. #30
    Plane Touched Levva's Avatar
    Join Date
    Jan 2011
    Location
    Aberdeen, Scotland
    Posts
    243

    Default

    Quote Originally Posted by ZorbaTHut View Post
    Let me know what you figure out If it helps, here's the one-line test script I just used to try out raids:

    /script print("---") for i = 1, 20 do local dat = Inspect.Unit.Detail(string.format("group%02d", i)) if dat then dump(i, dat) end end
    Thanks for script. Tested and it is working I had a test in to see if unit was a player to filter out pet objects and targets etc which was required when I used Inspect.Unit.List but now I use "groupxx" it is overkill to test if unit.player is true.

    My code was failing because I'd not noticed that an offline player has no return value for the .player attribute. When I reported the bug I hadn't checked where the nil was I just noted it wasn't getting to the debug line I had after the test to see if Inspect.Unit.Detail returned an object. Unfortunately that test tested both that the object existed and the .player attribute was true. Hence the failure which I attributed to a nil value from Inspect.Unit.Detail. Sorry about that.

Closed Thread
Page 2 of 30 FirstFirst 1 2 3 4 5 6 12 ... 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