Another thing which came up today:
Trinkets retrieved through Utility.Item.Slot.Equipment() do not have an information about onUse or onEquip effects.
Cheers
N.
Another thing which came up today:
Trinkets retrieved through Utility.Item.Slot.Equipment() do not have an information about onUse or onEquip effects.
Cheers
N.
".owner" is not working with summoned ability pets (such as Empty the Crypts). Works fine for normal pets as they are seen, I'm confident the problem is that the ability pets are never actually added to the specifier tree when summoned (there's no raw Event.Unit.Add for them).
The .owner member is present in the Rift raw combat log.
20:13:37: ( 3 , T=N#R=O#9223372046003492381 , T=N#R=O#9223372038247298264 , T=P#R=C#221239331907804514 , T=X#R=X#0 , Shambling Corpse , Runebroken Golem , 141 , 96431209 , Auto Attack ) Shambling Corpse's Auto Attack hits Runebroken Golem for 141 Physical damage. (29 overkill)
The bold unitID is the owner.
Rank 76 Guardian Mage
When you create a Text frame, it's default height and width are a square box, it only resizes properly when you call SetText. It would be nice if the default height with no text was the same as if it had a single line of text in it.
I'm having a little inconsistency with Event.Unit.Detail.Combat and Event.Combat.Death.
While doing my usual day of testing with my new engine in HK Chronicles, Prince Dollin (on death) will throw an Event.Unit.Detail.Combat as false but never seems to throw an Event.Combat.Death to my usual handler any longer.
But, with the above in mind, the Incorporeal Revenants do the exact opposite, they'll trigger an Event.Combat.Death but never an Event.Unit.Detail.Combat.
For both examples I've had them both targeted myself upon death, or my pet had them targeted. The only consistent thing about it is that they both always seem to trigger the same way. If you get one message, you'll unlikely get the other, and I'm yet to see both sent at the same time (ideally I think the Death event should be first, or at least override the Combat one consistently).
I'll work around this however with some checks in my Library and send both messages upon a units death to my addon, and any addon which uses it.
Last edited by Semele; 11-17-2011 at 04:37 PM.
Rank 76 Guardian Mage
With further testing, I removed the capturing of the Event.Unit.Detail.Combat events altogether and I still don't get the Event.Combat.Death event. So, I'm at a loss.
Does explain the strange behavior of my addon since 1.6 though. Anyhow, raid in an hour, need to see if I can fix this before then.
Rank 76 Guardian Mage
More feedback on what's going on. Problem with Prince is he apparently never dies (perhaps), always has hp left, and then the corpse is unavailable. So, maybe not the best test in the world.
As for the revanant, I would imagine that the Combat.Death event overrides the Unit.Detail.Combat event, which is ok. I'll implement it as is tonight, and ensure there's no glitches. Could just be a case of fake deaths not triggering the API death event. Lessons learned either way.
Rank 76 Guardian Mage
So, after some better testing with Bosses and Trash, I'm happy with the current messages from Death and combat, so far Combat leave messages appear after Death ones, and that's spot on. Sorry for the initial scare.
Rank 76 Guardian Mage
This could totally be my bad, but the FIRST time I try to iterate over a frame item, I get the "Event" table twice. I'm using my SlashPrint addon (locally tweaked to be a little less buggy), but this is really just iterating over pairs(x).
So if I grab some RiftWindow's :GetBorder(), and iterate it, I get two Event members... once. After that I only get one. (The two Event members appear to be the same table object.)
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!)
The following code will cause the client to crash when it first loads, but not after a /reloadui :
The actual problem line isCode:local RAW = {} function RAW.VariablesLoaded(addon) if not (addon == "RAW") then return end RAW.CreateTracker("Flamebound Defense") end function RAW.CreateTracker(name) for k,v in pairs(Inspect.Achievement.List()) do local d = Inspect.Achievement.Detail(k) print (d.name) end end table.insert(Event.Addon.SavedVariables.Load.End, { RAW.VariablesLoaded, "RAW", "VariablesLoaded" })
This was working fine with 1.6, it's only since the hotfix #1 it has caused a problem.Code:local d = Inspect.Achievement.Detail(k)
If I use Event.Addon.Startup.End as the initial trigger event it all works OK.
Last edited by Adelea; 11-19-2011 at 02:12 AM.
If Inspect.Item.Detail is called a number of times repeatly it will throw an error.
The following code illustrates the problem:
This will throw an error on one of the itemtypes provided. However if the itemtype throwing the error is then manually entered like this it will work:Code:local list = {"I4573F16A106292BD,421D20CB2FAA6850,,,,,,", "I2154D82F5ECCAC6E,BF8E4C3D21726EEA,,,,,,", "I07DEA434464F1870,7C757A4FF5F2A906,,,,,,", "I223142862791758F,C57038A8D779F112,,,,,,", "I2281D65F7A332014,0D0C39131C6DCA71,,,,,,", "I0B6617AA1D80AC66,E89AFAB643DC1B78,,,,,,", "I3A9518E93375D0F7,0306EAEC391637B1,,,,,,"} for k, v in pairs (list) do print ('get ' .. v) local RiftItem = Inspect.Item.Detail(v) dump (RiftItem) end
So the itemtypes are not the problem, but calling Inspect.Item.Data a couple of time in fast succession it will stop working and throw an error.Code:/script dump(Inspect.Item.Detail('I07DEA434464F1870,7C757A4FF5F2A906,,,,,,'))
Cheers
N.
Actually, there's something a bit more complicated going on here.
The client doesn't have full item detail when it starts up (in fact, it's got very, very minimal item detail.) If you request item type data for an item you don't yet have, it'll throw an error, but it'll also send the server a request for that item. A later request - i.e. one server round-trip later, probably a few frames if you're on a good connection - will succeed.
I bet if you call those manually, in a session *without* the loop that calls them in a row, you'll get the same error on the first call.
Right now the intended fix is to use pcall() to trap the error. Still coming up with a better fix.
And Inspect.Unit.Detail has another bug...
On AoE'ing Event.Combat.Damage(info) triggers for everyone who got hit by that one ability. the first Inspect.Unit.Detail(info.target) will return valid values. but the other calls will return nil while info.target isn't nil!
Same problem as in the quote... The other targets aren't accessible via the unit specifiers, so Inspect.Unit.Detail() returns nil...
Last edited by chuckySTAR; 11-19-2011 at 12:54 PM.
Hmmm that will be a problem for me then. What I need to do for my addon is to request the information for the items of a specifc loot table. So the addon knows it needs x items and will try to get the details. So this means in reality I will have to stick with extracting the neccessary information from the FTP XML file in future? DOH!
Or do you mean by waiting a couple of frames to actually capture with pcall and retry until the item is there?
Using pcall is was able to capture the error. Funny enough on around the 7th call (not the same item, 7 different items in a row) the error is not really captured by pcall and will be reported in the chat.
Cheers
N.
Last edited by Naifu; 11-19-2011 at 02:30 PM.
Bookmarks