Wikia

WoWWiki

WoWBench/Extending

Talk0
102,215pages on
this wiki

< WoWBench

Revision as of 15:09, March 8, 2008 by Pcj (Talk | contribs)

(diff) ←Older revision | Latest revision (diff) | Newer revision → (diff)

Modifying and extending for local use Edit

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 Edit

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:

lua wowbench.lua MyAddon myscript.txt


We want your hacks, too! Edit

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 Edit


Widgets Edit

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 _notimplemented("class.methodname"), 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.


Around Wikia's network

Random Wiki