Addon system bug reports

[Pushad]

http://pastebin.com/iWU0jcH3

Changing parent frame of RiftTextfield clears its content. I had also some issues with layers after parent change, but can't reproduce them in test addon so those might be on my side.

[Adelea]

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

And today this is causing rift to crash too!

As a workaround I am hooking Event.System.Update.Begin and using Inspect.Time.Frame() to wait until 5 seconds have passed, and then call my setup functions and set a flag so that the function being called from the Update.Begin handler returns immediately.

But.. This feels a bit like a hack!

I see from other comments that Inspect.Item.Detail doesnt have its data available right away, so I guess that something similar is happening on Inspect.Achievement.Detail.

I did try using pcall() to run the Inspect.Achievement.Detail() function, but it still crashed Rift, so I think the problem isnt in the LUA system but rather somewhere deeper inside Rift itself.

[Xenyr]

I am getting ability start events multiple times and I am not always getting the ability end event. Its simple to reproduce (on Rift 1.6), just load the eventlog addon and do /eventlog Ability. Now press Omen Sight. You will get the below output. In the first cast at 13:34:15 I got a second begin event 44s later and never got the end event. In the second cast (at 13:37:06) I got a second begin event 34s later. I only got the end event after I cast plague bringer. Notice the end event arrived at 13:39:42 which is 2m36s after i cast omen sight, but it is roughly 2m after the spurious second begin event.

a00000000563D1578 = Omen Sight
a000000004DB93F92 = Plague Bringer

13:34:15: [Dev] Event.Ability.Cooldown.Begin	{a00000000563D1578 = 120.00000762939}
13:35:29: [Dev] Event.Ability.Cooldown.Begin	{a00000000563D1578 = 120.00000762939}

13:37:06: [Dev] Event.Ability.Cooldown.Begin	{a00000000563D1578 = 120.00000762939}
13:37:40: [Dev] Event.Ability.Cooldown.Begin	{a00000000563D1578 = 120.00000762939}
13:39:22: [Dev] Event.Ability.Cooldown.Begin	{a000000004DB93F92 = 10}
13:39:32: [Dev] Event.Ability.Cooldown.End	{a000000004DB93F92 = 0}
13:39:42: [Dev] Event.Ability.Cooldown.End	{a00000000563D1578 = 0}

[the_real_seebs]

So, I have a bunch of small frames near each other (think "table of results"), and they have mousein and mouseout handlers.

It does not appear to be consistently the case that oldframe.Event.MouseOut is called before newframe.Event.MouseIn. Is that a bug?

[dOxxx]

So, I have a bunch of small frames near each other (think "table of results"), and they have mousein and mouseout handlers.

It does not appear to be consistently the case that oldframe.Event.MouseOut is called before newframe.Event.MouseIn. Is that a bug?

Apparently there is no guarantee about the order of events. I've encountered the same problem as you and I had to workaround it with some funky state tracking and even then I didn't get it quite right. See the MouseIn/MouseOut events for the label and checkbox frames in SimpleCheckbox in LibSimpleWidgets.

[Levva]

So, I have a bunch of small frames near each other (think "table of results"), and they have mousein and mouseout handlers.

It does not appear to be consistently the case that oldframe.Event.MouseOut is called before newframe.Event.MouseIn. Is that a bug?

I've seen exactly this in my addon but was assuming that I was doing something wrong. I'm away from home at present so haven't been able to do much testing hence I'd not posted anything before.

I'd have expected that unless the frames are overlapping which mine are not and I guess you other guys haven't got overlapping frames either. That there are specific mouse co-ordinates when the mouse is now outside the oldframe and entering another frame. Thus I'd expect a transition state to fire leaving before firing entering for the next frame.

[dOxxx]

I get an error when I use X/Y offsets with SetPoint and the LEFT/RIGHT/TOP/BOTTOM anchors. As long as I use the correct axis offset and the other axis offset is 0, I don't see why it shouldn't work.

For example:

SetPoint("LEFT", parent, "LEFT", 5, 0) -- anchor frame's left to parent's left, offset by 5 in X

SetPoint("LEFT", parent, "LEFT", 5, 5) -- invalid due to non-zero Y offset

Both of these usages give the "incorrect function usage" error on Live currently.

[Adelea]

I get an error when I use X/Y offsets with SetPoint and the LEFT/RIGHT/TOP/BOTTOM anchors. As long as I use the correct axis offset and the other axis offset is 0, I don't see why it shouldn't work.

For example:

SetPoint("LEFT", parent, "LEFT", 5, 0) -- anchor frame's left to parent's left, offset by 5 in X

SetPoint("LEFT", parent, "LEFT", 5, 5) -- invalid due to non-zero Y offset

Both of these usages give the "incorrect function usage" error on Live currently.

Doesnt this make sense though? You are saying make the child frames left edge the same as its parent, oh and make it higher too. Higher than what?

I guess LEFT/RIGHT work OK with an X offset coord, and throw an error with a Y offset? And the opposite for TOP/BOTTOM?

If you want to offset something by two directions, then why not just use TOPLEFT / BOTTOMRIGHT etc?

[ZorbaTHut]

So, I have a bunch of small frames near each other (think "table of results"), and they have mousein and mouseout handlers.

It does not appear to be consistently the case that oldframe.Event.MouseOut is called before newframe.Event.MouseIn. Is that a bug?

In general, we're not giving assurances on event ordering. I'll look at this to see if it's easy to change, but no guarantees .

[ZorbaTHut]

I get an error when I use X/Y offsets with SetPoint and the LEFT/RIGHT/TOP/BOTTOM anchors. As long as I use the correct axis offset and the other axis offset is 0, I don't see why it shouldn't work.

For example:

SetPoint("LEFT", parent, "LEFT", 5, 0) -- anchor frame's left to parent's left, offset by 5 in X

SetPoint("LEFT", parent, "LEFT", 5, 5) -- invalid due to non-zero Y offset

Both of these usages give the "incorrect function usage" error on Live currently.

We're being a little paranoid with regards to SetPoint() parameter ordering. Valid parameters:

SetPoint("LEFT", parent, "LEFT", 5, nil)

This way is a little more resilient against typos.

[dOxxx]

We're being a little paranoid with regards to SetPoint() parameter ordering. Valid parameters:

SetPoint("LEFT", parent, "LEFT", 5, nil)

This way is a little more resilient against typos.

Bah, I never thought to try nil. Thanks, Zorba!

[dOxxx]

Doesnt this make sense though? You are saying make the child frames left edge the same as its parent, oh and make it higher too. Higher than what?

I guess LEFT/RIGHT work OK with an X offset coord, and throw an error with a Y offset? And the opposite for TOP/BOTTOM?

If you want to offset something by two directions, then why not just use TOPLEFT / BOTTOMRIGHT etc?

When you want to constrain one axis relative to one frame and another axis relative to another frame. For example:

frame.SetPoint("TOP", parent, "TOP", nil, 5)
frame.SetPoint("LEFT", frameToMyLeft, "RIGHT", 5, nil)

That can be rewritten as:

frame.SetPoint("TOPLEFT", frameToMyLeft, "TOPRIGHT", 5, 0)

But then you have to ensure that the first frame of this string of left-to-right frames has it's TOPLEFT anchored relative to the parent instead. It makes the anchoring logic simpler to use the previous form.

[Blaez420]

Please post your addon API bug reports here. Note that this is not the right place for game bug reports or for bug reports on specific addons, this is for the addon framework itself.

We'd appreciate as much detail as possible on the bug. If possible, put together a small example addon and post the .lua file.

We will generally not respond to this thread unless we need more information, but we will be reading it.

My addons only work on some shards can someone plz help me fix this??

[Blaez420]

Why are my addons only working on some shards? Can someone please help me fix this?!

[Levva]

Why are my addons only working on some shards? Can someone please help me fix this?!

We read your message the first time!!

Addons are currently disabled on the North American realms to allow Trion to find the source of disconnect/lag issues people are reporting. However it seems this is still happening with addons turned off so it isn't an addon issue. Still it makes it a whole lot easier for them to debug if they have only their own code as the possible culprit.

NB. I said NA realms because they are still working on EU realms, at least they are on the ones I play on