Addon system bug reports

[ZorbaTHut]

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.

[Kreiri]

Buff events and data returned by Inspect.Buff.Detail are inconsistent. Code and results with comments on pastebin: http://pastebin.com/ThMJ3esJ

[ZorbaTHut]

Buff events and data returned by Inspect.Buff.Detail are inconsistent. Code and results with comments on pastebin: http://pastebin.com/ThMJ3esJ

Short answer: the "duration" and "expired" numbers are currently wrong if you query them during Buff.Add. That will be fixed in an upcoming version.

However, it's intended that adding a stack (or refreshing a buff) results in a Buff.Remove/Buff.Add pair. Internally, our buffs are mostly immutable, and resetting the timer on a buff or adding a stack actually requires an entire new buff object. Removing a buff ends up being rather weird - internally we're removing the *old* buff objects, but we're hiding those from you anyway in order to make the API cleaner, so that shows up as a Change message.

If you wanted a horrible hacky fix you could probably assume that "remaining" is equal to "duration" during Buff.Add, but the bug should be fixed in the next PTS build. (No promises, but should.)

Incidentally, your previous excellent bug report posts are a large part of why this thread exists. Thanks

[hp94]

=)

[Pushad]

ResizeToText does strange things..

• calling ResizeToText on text frame that has RIGHT and LEFT points set doesn't expand background properly. Other frames bound to that text frame are positioned correctly tho.
• calling ResizeToText on frame that has RIGHT and LEFT points set with wordwrap enabled does expand text frame properly on Y axis, but fails to wordwrap text and sets width as if wordwrap was false

Test script: http://pastebin.com/ejWMuxwn

[Semele]

Performing an Inspect.Unit.Details on a unit offline returns nil. Lookup still report a unit specifier and unit ID for that group slot.

I was expecting the unit's "offline" field to be true, and at least the name field.

For now I'm assuming a unit is offline under a "groupXX" nil return, but obviously can't pull the name atm.

[hp94]

/script while true do _G = {_G,_G} end --bluescreens

[Kreiri]

/script while true do _G = {_G,_G} end --bluescreens

Oh no, who would think that endless loops or messing with global tables are bad.

[hp94]

Oh no, who would think that endless loops or messing with global tables are bad.

Well, it was news to me =(

[IXI]

/script while true do _G = {_G,_G} end --bluescreens

Hp94.. this isn't a bug. That code does exactly what it is suppose to do. Zorba doesn't need to know how to crash Lua, he needs to know what is and isn't working in the coding he's done. That's not even related to the API, that's purely Lua. Maybe they would be interested in hearing your report though.

[DoomSprout]

It would be nice if the addon system could be sand boxed so that it can't bring the entire client down. I don't know if this is actually possible though.

A lot of Windows' bad reputation for reliability came from poorly written drivers, but people would blame Windows itself. This is also one of the excuses Apple give for not allowing Flash on iOS devices - apparently poorly written Flash apps cause more Mac crashes than anything else.

If addons are able to crash the client, or reduce it to 2 FPS, many people will unfairly blame Rift itself. If addons can be killed off when they are eating up too much CPU, or causing stack overflows like in the code above, the perception of fault will correctly lie with the addon itself.

[Aieny]

Doesn't even have to be an infinite loop; any script that takes more than 30 seconds freezes the game while running and then crashes to desktop.

[ZorbaTHut]

It would be nice if the addon system could be sand boxed so that it can't bring the entire client down. I don't know if this is actually possible though.

Yes and no. In theory, with a huge amount of work, it would be possible to make it unable to crash the client.

However, by their very nature, it's impossible to ensure that addons leave the game in a playable state. Sure they might not be able to crash the client, but they can make it so that the player is incapable of acting in the world - just hide every dialog and button. No game for you!

Furthermore, some people have drastically different tolerances for "playable" than others, and those tolerances can even change from one section of the game to another. If someone wants to (as a hypothetical example) write an addon that locks up the client for a few seconds while it tries to optimize quest completion routes, then maybe that's totally acceptable for someone who's hanging out in Meridian chatting with friends. It's probably less acceptable in the middle of a world event, and far less acceptable in the middle of a raid boss encounter or a PvP fight.

We'll probably be using some tricks to handle the more common and easily-recoverable problems, and we'll try to expose information so that people can tell which addons are impacting their game's performance. More than that will be a bit of a balancing act. And, of course, every day we put into error recovery is a day we aren't putting into improving the API.

[fatalus]

I figured out that after i use /reloadui the cooldown events will no longer fire until i relogin or zone.

Is there another way to reload my addon to shorten test cycles?

Thanks,

fatalus

[Semele]

*.Event:LeftDown() seems to now trigger for each frame no matter which one was clicked. Double checked with your buff bars example, and it does indeed now cancel all buffs when clicking just one.

*.Event:LeftUp() has now stop reporting entirely.