1. #1

    Can addon "intercept" keyclicks assigned to some action? Also LF addon

    Hello.

    I'm often leading random BG pug premades, or just try to coordinate people in BGs, and I need to be able to tell people during combat a lot of info, and voicechat is not an option. I need an addon that would allow me to do that. I need to be able to quickly send numereous commands into chat, like "Regroup @ GY" "EFC going RAMP" "GET MID" "Help FRR" "Incoming DR" etc.

    I found the following addons that kinda do what I need:

    AlarBGHelper
    BGSHouter
    REPorter

    Why don't they fit my needs?
    AlarBGHelper is outdated, buggy, does not support several BGs and has a limited number of what you can say.
    BGSHouter has to take up space on my screen, has to be used by mouse even if you've bound keys to it (in order to select locations), and you cannot rename the horrific location names on WSG (Alliance Eastern Exit, oh my God!), and does not support new BGs
    REPorter can only report and order people limited amount of commands (like, help said point or get said point).

    If noone knows an addon that can do what I need, then I have a question about WoW addon language.

    I'm a programmer myself so I'm willing to learn to make an addon, but I don't know if it's possible to do what I need. What I have in mind is a system in place in numerous games - Smite, Counter-Strike, it was most well developed in Free Allegiance, if anyone played that. Basically, you have a hotkey, that displays a number of options on the screen, each with its own hotkey, and an options can be nested, so you'd go like (Menu) -> (Order) -> (Attack) -> (My Target) and your character says in chat "Attak My Target (target name)!".

    For that, I need a functionality that allows me to intercept keyclicks and not let them through, when my addon frame is open. This is kinda like it works when you type in a chat window - you type "g" but your guild panel isn't opening. I want the same functionality. Also, I need to be able to intercept any keyclick the player does (well, any keyclick on a character button like a-z, 1-0, num 1-0, etc) without binding to that specific key (so, key "g" stays for "guild panel" but when I need to I can react to it being pressed).

    Is that possible in WoW addon language?

    If that is not possible, maybe I could do it so that when user pressed the addon hotkey, a hidden text bar gets focus, and each typed key is parsed immediately and interpreted?
    Last edited by Istrebitel; 2013-07-02 at 06:34 AM.

  2. #2
    Deleted
    Would be possible. SetOverrideBindingClick, then parse "clicks" on that "button".

  3. #3
    2 Treeston
    Thanks alot! By the way, offtopic, since you're UI expert, can you suggest the best primer / tutorial read on coding a WoW addon? One that would guide me through basics of syntax involved and common routines (re/store addon settings, bind keys, design visuals of an addon, common libs and how to use them etc). My background is C/C++, Pascal/Delphi, .Net C#, if that matters.

  4. #4
    Deleted
    I'm slightly stuck every time someone asks that question, sadly. There's no good "making an addon" tutorials I'm aware of, so I usually link to the various docs and advise people to read other authors' code, then ask questions about how it works.

    Since C/C++ is the only language from that list I'm actually fluid in, I'll give you a quick rundown on the differences that come to mind (there's significant ones):
    1. There is no distinct typing of variables. You can overwrite a String with a Number or a Table. Thus, functions also have no return type defined.
    2. Functions have no signature. Passing less or more arguments than specified in the function definition is legal.
    3. Functions can have multiple return values. If you want to understand the lower-level mechanics, you can look into the C Lua API documentation. It's quite an insightful read at advanced levels.
    4. There are no pointers. Whether a value acts as a pointer or not depends on its type. Tables, Functions and Userdatas are allocated in the heap, with a pointer pushed onto the stack. Everything else is pushed directly onto the stack. This leads to some interesting dynamics. For example:
      Code:
      local a = {} -- a is now a pointer to a table allocated in heap
      local b = a -- b is now the same pointer as a
      a.key = "test" -- set a key
      print(b.key) -- since both values point to the same heap location, the key also exists in b
    5. By extension of point 4, if you want to copy a table, you need to write a recursive table copy function to do so.
    6. By extension of point 6, function references are also first-level objects. A "function definition" (using 'function name(args)', there's other ways) consists of allocating the bytecode in the heap, then storing a reference in the global namespace.
    7. By extension of point 7, you can overwrite defined functions. This simply replaces the pointer in the global namespace.
    8. There's (obviously) no memory management. The Lua GC will (try to) collect unreachable tables. It's not particularly good at its job, so excessive creation of tables should be avoided.
    9. It's been too long since I used C++, not sure why I didn't think of this earlier. Tables can use any first-level variable (except nil) as an index (as opposed to C/C++ arrays using only numbers due to its low-level nature). This means that a construct like this is valid (while not particularly practical in most cases):
      Code:
      local a = { [{ [function() print("hello world!") end] = "key" }] = "another key" }
    10. There's no semicolon terminating every statement. Most statements automatically detect terminate, in fact. While this is usually only of concern when making macros (due to their 255-character limit), something like this will run just fine:
      Code:
      local a="wasd"print(a)a={}a.key="val"print(a.key)
    11. Lua is not an OOP language. There are no classes in Lua (though you can reproduce them using metatables).

    There's probably loads of stuff I forgot here. Like I said (in the link), you can always ask me stuff on IRC, and I'm sure most other authors will also be happy to point you in the right direction.

  5. #5
    The Patient
    15+ Year Old Account
    Join Date
    Apr 2008
    Location
    United Kingdom
    Posts
    319
    http://www.curse.com/addons/wow/opie is a radial AddOn which kind of does the things you want but I think it uses mouse movement instead.

  6. #6
    2 Treeston

    Thanks again!

    I think I kinda get it. I guess I will start by dissecting simplier addons to see how they do stuff and follow from there. Good thing is, what i'm planning to do is relatively simple on the interface part, so I hope I can handle that for now. Will come back when I have questions.

    Quote Originally Posted by suprep View Post
    http://www.curse.com/addons/wow/opie is a radial AddOn which kind of does the things you want but I think it uses mouse movement instead.
    Nah, not at all. I am using this wonderful addon and I tried to make it do what I want. It is not what i need for the following reasons
    - you cannot have more than one nested level AFAIK
    - you have to choose nested ring's item via mouse scroll, cannot use cursor/anything else
    - cannot have hotkeys for anytthing except popping the ring
    - cannot have text buttons/custom icons for the action, only builtin wow icons
    - cannot have rings appear based on BG you're in, like if i'm in WSG show this ring, if in AB show this ring...
    Last edited by Istrebitel; 2013-07-02 at 12:13 PM.

  7. #7
    I guess it is better to ask questions here rather than spawn another thread. Correct me if I'm wrong on this.

    I've read some stuff on WoW addon programming and now I have a vision of what I should do, and I have a question if I make any mistakes, and what is the best way to do what I planned.

    So, my addon's goal will be to provide a Quick Chat system, similar to those found in Free Allegiance / SMITE / Counter-Strike.

    Initially (in future all will be customiseable) it will provide a single nested menu, similar to a typical nested dropdown menu. A message is sent into predefined channel (Raid_warning / Instance / Raid/...) when final choice is made.
    The menu's structure can be simplified as this:

    Incoming -> Current/Node1/Node2/.../NodeN -> Unspecified/1/2/3/4/5/Zerg
    Defend -> Node1/Node2/.../NodeN
    Help -> Node1/Node2/.../NodeN
    Retreat to -> Unspecified/OurGY/Middlefield

    So for example, if one wants to shout out "Incoming to (my location)", he would choose Incoming -> Current -> Unspecified, and if one wants to shout out "Retreat to our GY", he would choose Retreat to -> Our GY.

    The root menu itself is shown by using a hotkey which is bound as usual (Bindings.xml file, entry appearing in the keybinding menu). Let's assume the key is "V".

    Navigation through the menu is done by individual hotkeys that fit well with the message you're trying to convey, in the code this is done by using SetOverrideBindingClick to bind specific hotkeys temporarily to the menu options, so for example "Defend" option could have a natural "D" hotkey, even though D is already bound to movement by most players.

    Therefore, to use the addon players would have to type a natural sequence of letters, for example, "VIMM" -> "Incoming Mine" or "VIM5" -> "Incoming Mine, 5 players" or "VRR" -> "Retreat!" or "VRG" -> "Retreat to our GY". This would be easy to memorise because the hotkeys would all be chosen in a way that makes as much sense as possible (first letters of a word, etc.).

    Exact menu options available would be based on the zone player is currently in, so for example in AB the "Incoming" menu would have a different submenu than in EotS, listing different node names.

    In future I plan to have everything be modular, in a way that every menu item is either a terminal item or not. A terminal item is assigned a string to be output, and a non-terminal is assigned a list of menus that follow out of it, based on the zone, and a variable it pushes into variable array.

    So for example, "Incoming Mine, 5 players" works like this:
    "Incoming" stores "Incoming" and shows next menu based on the BG
    'Mine" stores "Mine" and shows next menu
    "5" outputs %s %s, 5 players" to the predefined channel, which is supplied the list of variables "Incoming" and "Mine"

    One specific exception will be done for the location the player is currently in - a special combination like %l in the output string would be substituted with it.

    Here are my questions:

    1. Based on what I described, do you see any obvious flaws, oversights or problems I might run into?

    2. Do I have to manually do all this (show and hide frames, anchor them), or can this be done via the builtin dropdown functionality of WoW?

    The thing I do not know how to do with woW's dropdown menus is OnHide or a similar handler (because I must clear bindings every time a menu hides) and displaying a text on both sides of the button (Like you can do in Tooptips - so that I can display text on the left and hotkey on the right). Latter is not as important (could live without it and just specify hotkeys before the text, like "[D] Defend") but first one is a must.

    Come to think of it, I'm not even creating buttons in the dropdown menu, am I? I'm only creating "Info"s and I never get a pointer to a button or anything like that.

    3. The way it is done with dropdown menus, you're creating buttons every time a menu is dropped - is this a good practice? Wouldn't it be better (faster) to store the frames populated with buttons in hidden state and show them when required? Or is the benefit going to be miniscule?
    Last edited by Istrebitel; 2013-07-03 at 01:50 PM.

  8. #8
    Deleted
    1. None at first glance.
    2. You could technically do it using templates, but I wouldn't suggest it. Your best bet is to just programmatically create the frames as needed (use CreateFrame and, potentially, metatables).
    3. It would indeed be better to store hidden frames and not recreate them. See my metatables comment above.

    PS: For metatables you'd want to use the __index metamethod to create a frame if one does not already exist.

  9. #9
    Nice set of use cases, Istrebitel. Do you do this for a living?

  10. #10
    2 rfarris
    Hmm, I've actually done all sorts of stuff for living over my 26 years, all related to programming (been site administrator, done sharepoint webparts, was database administrator / architect / programmer, also audio compression algorithms, and so on and so forth). Bits and pieces, mostly because the company I work for does all sorts of different software / hardware projects.

    I've always loved programming and I enjoy learning new stuff and creating new stuff, but I've never got to making an addon because most of the functionality I needed was either already made by someone else, or I thought it was too hard or even impossible to make. But this one I decided is worth it to finally give it a try and learn lua and WoW addon programming, because multiple addons existing for this purpose are all taking a different direction, and I belive what I need is something that a lot of other players would also find useful.

    Btw, the addon is progessing quite nicely, it's already working with a basic set of features, I hope to be able to release it in a couple of weeks!

  11. #11
    I like the idea, Istrebitel. A few suggestions (I am not an addon author so some of my suggestions might not even be possible)

    1) For an addon like this, it is very important to be able to put custom messages. If I want my addon to be able to instruct my team mates 'rogue, create distraction and vanish', I should have an option to add that message to the list of available commands.

    2) Try to put enemy names instead of 'Attack my target'. Having some one say 'attack hpgupta' is a lot more easier than seeing what someone else is attacking and switching (yes, focus frames and /assist exist but there are situations where I want the target name / class before I start attacking them blindly).

    3) Make this work outside of BGs as well. If you can create a different set of commands to be used in raids or dungeons, you could have a killer addon! A lot of raid leaders don't use vent (or other forms of voice comm), and for them to be able to tell others to stack or spread out or switch or stop dps or taunt could be very useful.

    4) Don't change (or keep on changing) the command order/shortcuts/hotkeys once people have started using them. People will memorize your shortcuts, so in your counter strike example, if I know my buy order is b42b82b14, I don't want to re-learn everything with an update. It is better to spend a lot of time first and make a good list than have to keep on changing it every now and then.

    5) It is very very important for your addon to not be obtrusive. The last thing people want is to be stuck in your menu when they are getting attacked. I should be able to exit the addon at a moment's notice.

    I will be willing to help you test the whole addon (from an end user perspective) a bit. I use vent mostly while leading, so it could be a good test to see how much of voice comm can I effectively replace.

    - - - Updated - - -

    Oh, just noticed that Lacoste22 had necroed an old thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •