Addon system bug reports

[Naifu]

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.

[Semele]

".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.

[ZorbaTHut]

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.

There's still a few holes in the API like this - I wasn't able to come up with a good interface as yet.

[dOxxx]

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.

[Semele]

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.

[Semele]

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.

[Semele]

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.

[Semele]

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.

[ZorbaTHut]

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.

No problem, thanks for tracking down what was going on

[the_real_seebs]

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.)

[Adelea]

The following code will cause the client to crash when it first loads, but not after a /reloadui :

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" })

The actual problem line is

		local d = Inspect.Achievement.Detail(k)

This was working fine with 1.6, it's only since the hotfix #1 it has caused a problem.

If I use Event.Addon.Startup.End as the initial trigger event it all works OK.

[Naifu]

If Inspect.Item.Detail is called a number of times repeatly it will throw an error.

The following code illustrates the problem:

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

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:

/script dump(Inspect.Item.Detail('I07DEA434464F1870,7C757A4FF5F2A906,,,,,,'))

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.

Cheers
N.

[ZorbaTHut]

If Inspect.Item.Detail is called a number of times repeatly it will throw an error.

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.

[chuckySTAR]

Event.Combat.Damage(info)
Inspect.Unit.Detail(info.caster)

Inspect.Unit.Detail() is returning nil if event was triggered by pets like "split personality" and not accessible via unit specifiers like "target/groupXY/pet/owner/...".
But info.caster is always a valid unit id.

When i mouseover a split personality pet (now it's accessible via "mouseover") Inspect.Unit.Detail() is returning valid values and not nil

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...

[Naifu]

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.

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.