Addon system bug reports

[Xenyr]

Not sure if this is a bug, but my castbar code seems to have stopped working in 1.8. If I call Inspect.Unit.Castbar and pass the unitID as the parameter it works. If I try to call Inspect.Unit.Castbar supplying a table of unitIDs then I always get an empty table back. The table I am passing has unitID as the key, but I have tried passing a table with unitID as key and value.

[dOxxx]

I'm also seeing some incredibly weird behaviour from RiftTextfield. GetCursor() is returning -1 even though I have clicked in the field and made sure that the cursor is there. It appears to be caused when the RiftTextfield is parented on creation to frame A, and then frame A is then subsequently reparented using SetParent.

As an example, using my LibSimpleWidgets library, create a SimpleTabView frame, create another standard Frame (A) parented to the tabview and then create a RiftTextfield parented to frame A, then call AddTab on the tabview giving it a string name and frame A as parameters. This reparents frame A to the content frame inside the tabview and the RiftTextfield will now always return -1 from GetCursor().

I had another user of my library report this problem, so I guess the bug still exists on the live servers.

[Noshei]

it appears that the addon system is reporting the GCD for a pyro mage as being 1.5 seconds, which is incorrect. It should be 1 second.

It is reporting a 1 second GCD correctly for rogues.

[ZorbaTHut]

it appears that the addon system is reporting the GCD for a pyro mage as being 1.5 seconds, which is incorrect. It should be 1 second.

It is reporting a 1 second GCD correctly for rogues.

Good catch. Fix is scheduled for 1.9.

[Semele]

From first glance of KBM's messaging system, it would appear cross-server messages omit the @server part when passing the Name parameter.

Only noticed this while watching the wife play a warfront and someone from another server had a battle rez with a Rez Master compatible version of KBM running, and the players name appeared in the Rez Master list (less the @shard), but attempting to /kbmversion <player name> didn't reply.

Add-Watch on the other hand listed the correct player@shard naming conventions.

Not tested to actual output, but thought I'd mention it given how close 1.9 is.

[Noshei]

Did some poking around on the PTS with bCast to make sure it was working for 1.9 and had an issue with CPU usage.

With a single unit casting I was hitting 60% usage, 70% with 2 and 80% with 3 (enough at this point to trigger a watchdog warning).

I did some digging in the addon and couldn't really find any issue (it doesn't have this problem on live). So I decided to check out another addon (Gadgets) to see if it had the same problem, it did.

At first I was thinking it might have been the texture rendering, but I was able to dump that with gadgets because it still tracks castbars even if its not rendering one.

The only other possible cause would be the Inspect.Unit.Castbar calls. Which is done on every Event.System.Update.Begin. I wanted to make sure it wasn't somehow the event so I made a simple addon to make a black frame and increase its width by1 every Update, no problems there.

So that leaves us with something not working correctly with Inspect.Unit.Castbar. I was able to further confirm this through the use of slashprint and the script command. By simply using those to call Inspect.Unit.Castbar repeatedly (using Enter, Up, Enter by hand) I was able to get to 5% usage from them. That was only making the call once every 100 frames or so.

I think I might have a possible cause, though I am not sure if it is related. It appears that the field Inspect.Unit.Castbar().abilityNew is not being populated correctly. Instead of an id all we get is "A0000000000000000".

[Naifu]

Might be that this is fixed on PTS with the updated events, but on live there's a severe bug with Event.Unit.Available:

If you target an enemy using tab while being in a group the event will trigger for groupX.target and falsy report the player as being the target !!!!

If you target an enemy using the mouse the event will not trigger at all!

It will not triger for player.target under any circumstances.

While the later is acceptable the prior is a major PITA.

Cheers
N.

[Noshei]

Might be that this is fixed on PTS with the updated events, but on live there's a severe bug with Event.Unit.Available:

If you target an enemy using tab while being in a group the event will trigger for groupX.target and falsy report the player as being the target !!!!

If you target an enemy using the mouse the event will not trigger at all!

It will not triger for player.target under any circumstances.

While the later is acceptable the prior is a major PITA.

Cheers
N.

There were actually a lot of issues with Event.Unit.Available on live while in a group. Most if not all of these issues should be resolved now on PTS and shortly on live (6/26/2012). You will want to change over to the new event Event.Unit.Availability.* to ensure best results (Event.Unit.Available is still there, but had some bugs on PTS and is now depreciated).

[Semele]

Yeah, the amount of overhead currently in KBM's main unit tracking engine will all but vanish once I switch it over to the new Availability system. I'm looking forward to doing it, even though it's going to be pretty much a strip down and rebuild of the core KBM unit engine (and Safe's Raid Manager will benefit too).

All good though, should reduce KBM and SRM to pretty much Idle CPU even when fully tracking every unit in existence (which is does now to the best of my ability with the tools currently available).

[Naifu]

Good to hear ... allthough once again a lot of work goes down thebdrain. I just wish Trion would have shown the same amount of quality and finesse with the api like with the game right from the start. Ome year and still major flaws exist. Instead of adding more featues, the existing should go through some serious quality checks.

Cheers
D.

[ZorbaTHut]

Yeah, the amount of overhead currently in KBM's main unit tracking engine will all but vanish once I switch it over to the new Availability system.

BTW, if you have some huge CPU drain that requires polling inspects constantly, tell me about it. That's the kind of thing that needs to be fixed

[Semele]

BTW, if you have some huge CPU drain that requires polling inspects constantly, tell me about it. That's the kind of thing that needs to be fixed

Well that is good to know! I just thought it was working as intended and I did my best to work around it without draining too much CPU.

I mean, KBM idles @ 0.2% CPU while tracking and maintaining its unit cache, and I only really see it peak to around 5% with everything in full flow (such as hectic raid encounters with all frame bells and whistles going), and never really peaks past 3% while tracking Units during 4+ full raid ember isle encounters (including buffs & castbars).

But, I'm from the days of making stuff run on a Z80 CPU so I'll never be happy until I'm happy. lol

Just like to say, that my only real issues were with the what is now vanishing Unit.Available system, so I'm really happy you've made these changes, and I'm sure KBM and SRM users will be too!

I would still like Unit.Detail.Calling events if possible, but I have a sneaky feeling this won't be needed now Availability = "full" is incoming, as this should trigger only once all raid/party/player details have fully loaded and therefor I'll have no need to manually check for a fully loaded state. Actually, the whole fully loaded events will pretty much solve everything. Ah well, consider all my previous Unit related requests fulfilled with 1.9

[Naifu]

The following scenario gives an invalid securemode error:

(1) Create a context and secure it to 'restricted'
(2) Create a RiftWindow parented to context and secure it to 'restricted'
(3) Create a frame parented to RiftWindow:GetContent() and try to secure it to 'restricted'

Parenting the frame directly to RiftWindow does work. RiftWindow:GetContent():SetScureMode() does not exist. Looks like the content frame is missing the ability to be secured.

Cheers
N.

[Naifu]

Something is wrong with /reloadui. The more you do it the slower the reload will take over time until eventually the client crashes. Memory leak?

Cheers
N.

[Kreiri]

Playing with context and stratas on PTS:

local context = UI.CreateContext("myContext")
local t = context:GetStrataList()
for k, v in pairs(t) do print (k, v) end

or

local context = UI.CreateContext("myContext")
context:SetStrata(/anything/)

- crashes the game after /reloadui.

Setting strata of context to "dialog" or "loading" crashes game on entering world after character selection screen, but crash reporter's "send report and restart" is able to load game and enter world successfully.

Setting strata of context to "modal" causes frames in this context to appear on loading screen.

Buttons in context with strata set to "hud" do not fire click events.