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.
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.
This could be me not understanding the function usage
Code:context = UI.CreateContext("test"); frame = UI.CreateFrame("Frame", "Test", context); frame:SetSecureMode("restricted");Is apparently incorrect butCode:[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>
works fine. In both cases calling the function while not in secure mode, I'll admit I could be missing something obvious.Code:frame:SetSecureMode("normal");
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.
The above should work. Took some head-scratching, but the usual epiphany while drifting off to sleep had me test this today.Code:context = UI.CreateContext("test"); context:SetSecureMode("restricted"); frame = UI.CreateFrame("Frame", "Test", context); frame:SetSecureMode("restricted");
Last edited by Semele; 09-02-2011 at 09:04 AM.
Rank 76 Guardian Mage
Ah thanks.
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.
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?Code:local unitdetail = Inspect.Unit.Detail("group02")
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.
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).
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.
Bookmarks