WoWBench/Extending

= Modifying and extending for local use =

The easiest and most non-invasive way to modify existing functionality, or implementing "hacks" for APIs that do not yet exist, is probably to add a new file to the bottom of world.toc and have that (re-)define APIs that you need.

Example world.toc: (more above...) world.xml worldcmds.lua #My local hacks myhacks.lua

Example myhacks.lua: function CursorCanGoInSlot(slot) your code here end

Remember that Lua functions can be re-defined as many times as you like. At the end of world.toc, WoWBench has finished defining everything built-in. All that remains to be loaded after that point is FrameXML and AddOns.

If you want to modify something after FrameXML has loaded, the best way is probably to create a new "AddOn" (new directory with .toc and everything) that contains your "myhacks.lua", and list that addon as the first one on the command line.

Of course just flat out modifying what's already there works too, but you might end up regretting it when you download a new copy of WoWBench.

Using command-line .txt files to temporarily load hacks
As of v1.11.0.a4, WoWBench will accept .txt file names on the command line. These files will parse just like anything you enter on the command line.

Example commandline script to add extensions and tweak things: dofile("myhacks.lua"); dofile("hacks/someotherhacks.lua"); some_var = some_value; say Bob Oh, schnapps!

You'd just load this with something like:

We want your hacks, too!
If there's even a remote chance that your local hacks can be useful to anyone else, we'll gladly accept them! See WoWBench/Contributing and WoWBench/Hacks.

= Guidelines for adding to WoWBench =

Widgets
Since WoWBench is command line driven, much of the Widget API is just duds. Methods that are not implemented, but have not yet caused problems for anyone, call, which causes an assert.

If any of these methods cause problems for you, but you judge that it is not important for them to be emulated in any way, just replace "_notimplemented" with "_ignore_notimplemented". Do not simply remove the call; it is useful to be able to modify _ignore_notimplemented to spot problems in the future.