1. Posted by LJHW on Thu, 14 Oct 2010 22:22:04

   Hi Guys,

   Have been playing WOW for a few months and am a professional developer (12 years C++, .NET, servers mainly, some GUI stuff, bit of scripting, etcetera).

   I would like to learn AddOns/Lua skills via a project that I have in mind.

   Here's what I want to do: 1) Create macro in WOW client. 2) Have this macro call into Lua code to decide on one of a simple set of WOW commands to next perform. 3) Execute this command: very simple, /use XXX, /cast YYY target, type commands.

   I have an AddOn which obtains 2 player-state variables that I need for calculation. I can see how I can create a Lua function to run the logic for my decision. What would help me are toy examples of the following: 1) Call into Lua from client created macro 2) Execute WOW command from Lua

   I would hard-code the decision logic to start with. But, in time would include an addon properties window to diversify the logic etcetera.

   Also - debugging/development. Do we use the actual game to test behaviour - if so, can I write log files out easily? Is there some type of debugging harness that is easy to use?

   Your help would be very much appreciated in advance. I look forward to contributing to the site properly once I'm up to speed with the relevant technologies.

   Thanks, LJHW

2. Posted by jnwhiteh on Thu, 14 Oct 2010 22:33:22

   I would like to learn AddOns/Lua skills via a project that I have in mind.

   Then you've come to the right place! I'd suggest picking up a copy of World of Warcraft Programming, it was written precisely with this in mind.

   Here's what I want to do: 1) Create macro in WOW client. 2) Have this macro call into Lua code to decide on one of a simple set of WOW commands to next perform. 3) Execute this command: very simple, /use XXX, /cast YYY target, type commands.

   What you want cannot be done. Explicitly.

   I have an AddOn which obtains 2 player-state variables that I need for calculation. I can see how I can create a Lua function to run the logic for my decision. What would help me are toy examples of the following: 1) Call into Lua from client created macro 2) Execute WOW command from Lua

   You cannot make action decisions based on logic conditionals that are not already present as macro conditionals.

   I would hard-code the decision logic to start with. But, in time would include an addon properties window to diversify the logic etcetera.

   Also - debugging/development. Do we use the actual game to test behaviour - if so, can I write log files out easily? Is there some type of debugging harness that is easy to use?

   There are no log files, there are no traditional debug harnesses. All development is either dry-coded offline (and tested if the function don't need the WoW API), but it has to be loaded into the game to be tested.

   Your help would be very much appreciated in advance. I look forward to contributing to the site properly once I'm up to speed with the relevant technologies.

   Great to have you aboard!

3. Posted by LJHW on Fri, 15 Oct 2010 17:55:12

   Many thanks for your swift response. I am going to order that book this weekend.

   Have done a little research and played with some code.

   I can do the first part. i.e. I can call into an addon via a macro and run lua code that I have written. So I have an addon where I can arrange to call public API functions via a macro that I create. Have only done simple things like Emote etcetera. I am looking into the equivalent of static variables which persist and can be updated between my macro calls.

   However, I think I understand something crucial now. Blizzard has "protected" certain API functions - essentially the ones that would allow me to do the second part of what I was intending. I'm guessing they made them protected after people actually did what I am trying to do! This would make sense because it could give an unfair advantage otherwise, right?

   I have another 2 questions. There are addons like clique and PallyPower where the player can "/cast" i.e. heals, blessings and so forth. These mouse clicks must be handled in Lua OnClick event-handlers somewhere and the API called in order to execute the spell. I had a look but got a bit swamped with the amount of code.

   So:

   1) Are certain API functions suddenly available if handling mouse events rather than keyboard events?

   2) What type of API calls do clique and PallyPower use to execute these casts?

   Many thanks, LJHW

4. Posted by jnwhiteh on Fri, 15 Oct 2010 18:07:25

   Many thanks for your swift response. I am going to order that book this weekend.

   Have done a little research and played with some code.

   I can do the first part. i.e. I can call into an addon via a macro and run lua code that I have written. So I have an addon where I can arrange to call public API functions via a macro that I create. Have only done simple things like Emote etcetera. I am looking into the equivalent of static variables which persist and can be updated between my macro calls.

   Yes, but as I said you cannot do what you want to do. You can call whatever functions you want from macros, but you cannot ever target units or cast spells.

   However, I think I understand something crucial now. Blizzard has "protected" certain API functions - essentially the ones that would allow me to do the second part of what I was intending. I'm guessing they made them protected after people actually did what I am trying to do! This would make sense because it could give an unfair advantage otherwise, right?

   I have another 2 questions. There are addons like clique and PallyPower where the player can "/cast" i.e. heals, blessings and so forth. These mouse clicks must be handled in Lua OnClick event-handlers somewhere and the API called in order to execute the spell. I had a look but got a bit swamped with the amount of code. So:

   1) Are certain API functions suddenly available if handling mouse events rather than keyboard events?

   No.

   2) What type of API calls do clique and PallyPower use to execute these casts?

   They don't. They use the 'secure templates'. This means they pre-program what a button is set to do, and this is static and cannot change. It cannot be any more conditional than a macro. The only way an addon can cast spells or target units (i.e. any protected action) in combat is to use the secure templates.

5. Posted by LJHW on Sat, 16 Oct 2010 01:35:01

   That's great, thanks. I think I can work out how to call via secure templates (have seen an example but haven't tried yet).

   2 very important questions though, then I'm off experimenting:

   1) Can I set N "buttons" up when the addon is loaded? So that in principle, I can access the button I need, 'quickly' via an array, knowing that the call will have been registered with the API already.

   2) Is there some equivalent of protected API functions in relation to the secure templates? From what you say: 'heal', 'Blessing of Might', 'Seal of Wisdom', ... - must be invocable via secure template. These seem like passive/friendly functions. Is the line drawn at /casts that can't damage non-friendly targets?

   Many thanks, LJHW

6. Posted by jnwhiteh on Sat, 16 Oct 2010 08:23:56

   I am going to be as clear as I possibly can. You cannot under any circumstances cast any type of spell using any condition other than those already supported by the macro system. The entire secure template system was designed to prevent this. You will always need to click a button or press a key in order to cast a spell, and you will always need to choose which spell is being cast, by choosing what you click or press.

   http://github.com/tekkub/wow-ui-source/blob/live/FrameXML/SecureTemplates.lua

   Search from SECURE_ACTIONS and that lists every type of action a secure action button can take.

7. Posted by LJHW on Mon, 18 Oct 2010 16:50:51

   Thanks for your help JN. Your responses have accelerated my jump into this addon writing immensely.

   I get it now:

   1) API event-handlers like, mouse clicks or button presses, have to be registered with the framework out of combat. These are restricted to secure frames, which are in turn restricted to only what you can do manually i.e. inbuilt action or macro.

   2) You can't re-register these things in combat so they can't be called via any type of combat-runtime logic. They must be pre-set.

   3) The best you can do is display combat-runtime logic and give the user visual pointers to make the decision based on some sort of algorithm.

   This is what I think I'm going to try now. Create some sort of graphical feedback that will flash up under the configured circumstances. Then a user-friendly way of displaying which buttons to hit.

   Now for knocking out the code and detail!

   Thanks again, LJHW

8. Posted by jnwhiteh on Mon, 18 Oct 2010 18:35:57

   Thanks for your help JN. Your responses have accelerated my jump into this addon writing immensely.

   I get it now:

   1) API event-handlers like, mouse clicks or button presses, have to be registered with the framework out of combat. These are restricted to secure frames, which are in turn restricted to only what you can do manually i.e. inbuilt action or macro.

   2) You can't re-register these things in combat so they can't be called via any type of combat-runtime logic. They must be pre-set.

   3) The best you can do is display combat-runtime logic and give the user visual pointers to make the decision based on some sort of algorithm.

   This is what I think I'm going to try now. Create some sort of graphical feedback that will flash up under the configured circumstances. Then a user-friendly way of displaying which buttons to hit.

   Now for knocking out the code and detail!

   This is EXACTLY what Blizzard wants =) You can give the user all the information you want, they just need to actually DO the thing themselves =)

• About
• Privacy Policy
• Terms of Service

World of Warcraft™ and Blizzard Entertainment™ are trademarks or registered trademarks of Blizzard Entertainment, Inc. in the U.S. and/or other countries. The original materials contained in the API Reference section of this website are copyright John Wiley & Sons. Other copyrights on this page are owned by their respective owners. All other content © 2008-2021 wowprogramming.com.