Authors CurseForge

A common practice when moderate to large amount of code is required to handle BAG_UPDATEs, is to set a timer that evaluates, say, 0.02 sec after the event is received, because usually BAG_UPDATE fires by pair (if not way more).

local timer

function handler(self, elapsed)
	timer = timer - elapsed
	if timer > 0 then return end
	self:SetScript( "OnUpdate", nil )
	-- BAG_UPDATE handler here
end

function f:OnEvent(event, ...)
	if event == "BAG_UPDATE" then
		timer = 0.02
		self:SetScript( "OnUpdate", handler )
	end
end

If you use an elseif chain in your OnEvent, be sure to place BAG_UPDATE on top of it.

Also, note that if a frame is hidden, its associated OnUpdate is not called anymore, until it's shown again.

Damn, there's a huge issue. I get UNIT_SPELLCAST_FAILED and UNIT_SPELLCAST_INTERRUPTED events properly but no UNIT_SPELLCAST_SUCCEEDED at all :(. (EDIT: nevermind, I think it's just an error in my code that prevented the message :p)

I know that CLEU doesnt provide any SPELL_CAST_SUCCESS on tradeskill completion and I thought it was the same with UNIT_SPELLCAST_SUCCEEDED :p.

Quote from lilsparky

one problem that comes to mind is the very possible (and maybe even likely) scenario of people closing the tradeskill window during the execution of the tradeskill in question. can you still do tradeskill api calls or has the tradeskill reverted to "unknown"?

Yes, you can still get info from tradeskills if the window is closed.

Quote from lilsparky

what about shared cooldowns? aren't transmutes shared?

I don't see any problems with shared cooldowns. Can you detail your question and make sense of it ? :p

I think I found a generic and efficient way to handle all tradeskill CDs. Here is a code snippet: http://www.pastey.net/104665

local watchedIndex, watchedCast, watchedTimer
local orgDoTradeSkill = _G.DoTradeSkill

function DoTradeSkill(index, ...)
	watchedTimer = watchedTimers[ tonumber( strmatch( GetTradeSkillRecipeLink(index), "enchant:(%d+)" ) ) ]
	if watchedTimer then
		watchedIndex, watchedCast = index, GetTradeSkillInfo(index)
		f:RegisterEvent"UNIT_SPELLCAST_SUCCEEDED"
		f:RegisterEvent"UNIT_SPELLCAST_FAILED"
		f:RegisterEvent"UNIT_SPELLCAST_INTERRUPTED"
	end
	return orgDoTradeSkill(index, ...)
end

function f:OnEvent( event, unit, spell )
	if event == "UNIT_SPELLCAST_SUCCEEDED" or event == "UNIT_SPELLCAST_FAILED" or event == "UNIT_SPELLCAST_INTERRUPTED" then
		if unit ~= "player" or spell ~= watchedCast then return end
		f:UnregisterEvent"UNIT_SPELLCAST_SUCCEEDED"
		f:UnregisterEvent"UNIT_SPELLCAST_FAILED"
		f:UnregisterEvent"UNIT_SPELLCAST_INTERRUPTED"
		if event ~= "UNIT_SPELLCAST_SUCCEEDED" then return end
		f.db.char[watchedTimer.spellID] = time() + GetTradeSkillCooldown(watchedIndex)
		if blockHovered then f.OnEnter(blockHovered) end
	end
end

The only problem I see is when you research a new tradeskill that moves the research skill down, making watchedIndex invalid (I know it's not the case for inscription, maybe for alchemy ?). But that's not something we can't overcome.

For most CDs I use ITEM_PUSH and check the itemTexture arg (almost all item crafted on CDs have unique texture). It works for tailoring (ebonweave, moonshround...), enchanting (spheres), smelting (titansteel) and jewelcrafting (brilliant glass and probably the incoming icy prism).

For CDs where this method doesn't work (transmutes because you can merge 10 motes/crystallized elem to generate an ITEM_PUSH, alchemy/inscription research, and craftable items that share their icon with other items), I hook DoTradeSkill. But once I know the player is about to cast a tradeskill CD spell, I don't know what event to register to properly check if it has been successfull or not.

UNIT_SPELLCAST_SUCCEEDED, UNIT_SPELLCAST_FAILED, SPELL_UPDATE_COOLDOWN, TRADE_SKILL_UPDATE, ITEM_PUSH, others ?

What would be the most efficient combo ?

Any other idea besides the crappy tradeskill window scan ?

In this pre 3.0 exemple I get a "Font not set" error from FSB_Area but I don't know what to change in the XML to make it work (only know for Lua). Any idea ?

<FontString name="FSBar" inherits="GameFontNormalSmall" virtual="true">
	<FontHeight>
		<AbsValue val="9" />
	</FontHeight>
	<Color r="1.0" g="1.0" b="1.0" />
</FontString>

(...)

<FontString name="FSB_Area" inherits="FSBar" wraponspaces="false" justifyH="LEFT" text="area">
	<Size>
		<AbsDimension x="75" y="16" />
	</Size>
	<Anchors>
		<Anchor point="TOPLEFT">
			<Offset>
				<AbsDimension x="2" y="0" />
			</Offset>
		</Anchor>
	</Anchors>
</FontString>

You use "secureTemplates" while SBC use "secureTemplate", what's the best ? I feel both stand correct depending of the point of view (names are annoying :p).

Outch, and I thought PerformanceFu was big :p

The scrollable tooltip is a bit of a problem no ? It's either not usable with SBC or it requires a "mouse enabled" tooltip frame.

What do you, people, miss the most from PerformanceFu that you don't have with current LDB alternatives ?

I will make an alternative aswell. I want to get rid of the last FuBar plugins I have (PerformanceFu and MoneyFu) and Im not satisfied with what's currently available :p

Quote from Mikk

Nitpickery: The ".." operator becomes a single huge concat operation without intermediate string garbage -- assuming all the components are strings. If they are nonstrings they get converted before the concatenation.

(Yes, rly, we tested :))

So, for all-strings: Use "..". It's slightly faster than using format().

If nonstrings are involved, use format(), it doesn't create extra garbage.

Interesting. So when comparing the following 2 pieces of code (colorXXX are strings), the latter the better in all aspects ?

block.text = strjoin( "", "|cff", colorXP,
	strsub( bar, 1, lenXP * lenChar ), "|r|cff", colorRested,
	strsub( bar, 1, lenRested * lenChar ), "|r|cff", colorRemaining,
	strsub( bar, 1, (length - lenXP - lenRested) * lenChar ), "|r" )

block.text = "|cff"..colorXP..
	strsub( bar, 1, lenXP*lenChar ).."|r|cff"..colorRested..
	strsub( bar, 1, lenRested * lenChar ).."|r|cff"..colorRemaining..
	strsub( bar, 1, (length - lenXP - lenRested) * lenChar ).."|r"

Some ppl run WoW on heavily fragmented 250gb HD with 2gb free at best, and delete some files when they're at less than 200mb and applications don't want to launch. That makes me wonder how long it takes to read a 4gb MPQ file fragmented in 1200 pieces all over the HD :confused:. Maybe some ppl are also crazy enough to use disembedded libs to make addons load marginally faster :p. (And maybe some of them even edit lua files to remove comments and indent :p).

Quote from Torhal

Oh? I've always thought of "label" as something to the effect of "Addon Name", with "value/suffix" taking precedence over "text".

What you describe is how FuBar2Broker use "label" :)

@funkydude: In your version I still miss the handling of the "label" attribute. The handling includes a hide/show option for "label" so we can easily switch between long/short text.

The general consensus seems to let "label" take precedence over "text". Then you append "value/suffix" to it. If no "label" nor "value" then display "text".

Quote from Borlox

Even if it's not "official", it's a really interesting idea. That would allow a whole bunch of new broker plugins.

Exactly! But it requires some(many) adjustements to make the display compatible. The amount of adjustments depends of the current display implementations as none have been designed to support these from start.

For exemple: if you allow plugins to resize in combat and that resize action tries to move adjacent plugins, it will taint if not done in a secure way. But a (simple ?) solution could be to lock them in combat.

I really hope new displays will be designed with secure stuff in mind. That would be the best to add in-combat features more freely without breaking.

Anyway, if you love programming, it's a great experience I recommend :p

EDIT: I forgot to link the secure bible for interested devs :p: http://www.iriel.org/wow/docs/SecureHeadersGuide%20-%20pre1.pdf

Im playing with a hackish way to retrieve the number of dose for a given itemID:

PickupItem( itemID )
PlaceAction(120)
local doseCount = GetActionCount(120)
PickupAction(120)
ClearCursor()

It picks up an item and places it on an action bar slot, retrieves the dose count, then removes the item and clears it from the cursor.

The problem is when it's done with multiple oils/stones in a loop: accumulated sounds are really annoying. I looked at the FrameXML\ActionButton.lua but found nothing.

How can I disable this properly ?

EDIT: to avoid confusion, this is part of a discussion with Funky (to avoid ppl wondering why the plugin does nothing for them :p)

The wrapping stuff is GREAT! No more conflicts with existing scripts! And if the plugin try to wrap a non existing script, the snippets are still called! Even if the associated secure templates are not present, as long as the generic handler is <3 <3 <3

So now, when you enter the secure block (in or out of combat), the consumable list shows, along with your alpha settings, all that without a single code addition on both sides (I simply replaced the SetAttribute lines by WrapScript ones on my side).

In addition, the plugin seems free to wrap about everything and doesnt need to implement specific templates, the generic one or any other will do for every possible scripts. So it could be possible to reduce the spec to just: DO.OnCreate, setting the type attribute to "secure" and letting the display implement whatever secure templates he needs.

Test it please: http://perso.orange.fr/aranarth/wow/addons/Ara_Broker_Poisons-r3.zip

What remains is how the display could handle tainting scripts properly. Imagine, for exemple, that you want to allow the secure plugin to use your mousewheel stuff in combat.

I will test that tomorrow, having in mind that the display now has complete control over secure templates.