I am not all that keen on [bonusbar:x] either, especially since the whole bonus bar system has been revamped to be override bars. I am all for keeping things consistent. But, if it is easier to fix the [bonusbar] conditional than add new ones, it would be better than the current state of addons needing to react to UI changes in a secure way.

I have not seen anything on the beta forums yet. And quite frankly, I have been a bit out of touch on how and where to best make UI suggestions that will reach the UI team.

This seems like it's the trend with the newer functions; that they are returning true/false instead of 1/nil.

Makes sense. Lua didn't have a boolean type when those original functions were initially implemented. Even the upstream standard library used 1/nil returns.

IsInRaid() --true/false
IsInGroup() --true/false, will return true if you are in a raid as well as a party

Now that GetNumRaidMembers has morphed into GetNumGroupMembers, I wonder if GetRaidRosterInfo will return valid data while in a "plain" party? I'd like to think so, but haven't seen anything mentioned anywhere. Will try to test... sometime this week.

For now, you have to do it insecurely. You could register for "PLAYER_REGEN_DISABLED" and use that event to restore your addon to its proper state, regardless if the pet battle ui is up or not.

Originally Posted by Gethe

You are not "in combat" while in a pet battle. This I know because I was able to open and use the Bartender options while in one.

In ideal conditions, this is true. However, and it *will* happen if this is not addressed, somehow or someway, an addon user will be in a pet battle and someone will figure out how to attack them via PVP (if flagged) or a mob will somehow get a character into combat, and leave the player without their crucial UI elements.

As of build 15882, addons seem very prone to causing crashes. According to Tukz, both the presence of a slash command and the GetRegions() function can cause this, but there are probably more causes.

At the start of beta (when addons were enabled) I also had to remove a couple of global strings I replaced, the more abstract patterns with end of string '$' or something like '|3-7' seemed to cause this. Not sure if this works again, I'd have to test.

As of build 15882, addons seem very prone to causing crashes. According to Tukz, both the presence of a slash command and the GetRegions() function can cause this, but there are probably more causes.

At the start of beta (when addons were enabled) I also had to remove a couple of global strings I replaced, the more abstract patterns with end of string '$' or something like '|3-7' seemed to cause this. Not sure if this works again, I'd have to test.

I had a very hard time even getting into the game. But crashes also seem related to having taintLog enabled. Since disabling it, it has become a little more stable...

So it appears they want to embed future addons into the game itself, I wouldn't be surprised if the addons folder disappears at some time from exporting the interface code. I assume so because when pet battle bugs appear there are lua errors reporting errors in code we don't have access to, but it's lua.

So it appears they want to embed future addons into the game itself, I wouldn't be surprised if the addons folder disappears at some time from exporting the interface code. I assume so because when pet battle bugs appear there are lua errors reporting errors in code we don't have access to, but it's lua.

That is one HUGE leap. How do you go from "WoW uses lua in other areas" to "all addons will be removed" ?

What I meant is, since there are signs of lua code running (pet battles) that isn't exported as an addon, meaning we can't see the sources, meaning it makes things just more complicated and busywork to figure out how that particular addons works, what events it uses, API, e.g.

One may say that's a good thing to "bake" all addons into the binary and get rid of all the Blizzard_* addons, but on the other hand if that happens, how can we explore the sources of their LOD addons and learn from them? I think it's an important aspect of both learning how to code for the game, and getting an idea how things work around here.

It's early to say though, they might make the baked addons exportable too, it may be that they just haven't made the export feature export this new type of lua code, so it's no biggie if they fix this for retail release.

I only dislike the idea having the sources completely unavailable and having us guess on API changes and how their addons work. I didn't mean to sound like "they are doing it right now", just saying if they are...

Just a side note, I personally don't see how baking all the Blizzard_* addons would make it any better. Please DO enlighten me though on what you thought!

The old/current IsSpellKnown had a lot of "problems" with not recognising known spells. Namely a lot of spell IDs extracted from a combat log event were different than the ID of the same spell in your spell book, the latter of which worked with IsSpellKnown, while the combat log event did not. I've had to make a lot of special cases because of this. As far as I understand this function is now replaced with IsPlayerSpell.. has anyone noticed if this one is at all improved in this regard?

Here's everything I've had to make exceptions for, for the record. Granted, many of these aren't simple strikes or direct damage effects, but it would be cool if these could be considered "known", as well, depending on what the intended purpose of IsPlayerSpell is.

As of build 15882, addons seem very prone to causing crashes. According to Tukz, both the presence of a slash command and the GetRegions() function can cause this, but there are probably more causes.

At the start of beta (when addons were enabled) I also had to remove a couple of global strings I replaced, the more abstract patterns with end of string '$' or something like '|3-7' seemed to cause this. Not sure if this works again, I'd have to test.

Experienced crashing with build 15882 on logon, found turning off the taint log fixed the crash.
"/console taintLog 0"