Wikia

WoWWiki

Talk:World of Warcraft API/Archive 2009 January

101,312pages on
this wiki

Back to page | < Talk:World of Warcraft API

API UnitSex("target") : What if there is no selected target ?Edit

Hello everyone,

As defined in the UnitSex article, this function returns 2 if the unit specified in argument is male, and 3 for a female. However, when I write UnitSex("target"), I get the information I'm waiting for, but only if I really have selected a unit : if there is no unit selected, the function returns 2. I thought at first that it corresponded to a default "player" (myself), but it still returns 2 if I play a female character. I'd like to understand why the UnitSex("target") returns something when there is no target, whereas a UnitName("target") returns a nil. Where does that "2" come from ?

What's more, since I cannot establish a distinction between a male and a lack of selection with UnitSex, could anyone direct me to a function that could tell whether there is a selection or not ?

Thanks in advance.
--Kerrie 03:43, 7 December 2007 (UTC)


You can call if UnitExists("target") prior to UnitSex("target"), or if UnitName("target") since you say that would return nil.

Valana 15:21, 7 December 2007 (UTC)

Getting information from within script about items, gems, enchantsEdit

Hi guys I have real trouble finding functions that give me information about stats and equip and use effects. Functions that I can find, like GetItemInfo only return an ItemLink, with which I can get the ItemID, but I cannot find any function that gets me the stats that I want. Can anyone enlighten me?

I'd like to get numerical information on item stats, like int, sta, etc. In addition, +healing and +def rating are vital to the application I have in mind. The same holds for enchants and gems, since they change the overall effect of equipping/unequipping an item.

I've found that on this site somewhere there is a list, but that's of no use to me. That would still mean I would have to make my own database which I really don't want to do.

Dunno whether this is the correct place to ask questions, but sry I don't hve IRC. Any info appreciated. Legionmaster 01:29, 12 August 2007 (UTC) Legionmaster

As far as I know, the only way to do this is to parse the text of the tooltip. There's an example of how to do this on the GameTooltip Object page. Posted by: EGingell (T|C|F) on 10:16, 12 August 2007 (UTC)

Restructuring things without a new namespace Edit

API Reference Categories

It basically looks like Rustak won't be adding any more namespaces - period. So I've started some structuring work without it (almost said REstructuring, but it isn't really..).

See the nice table on the right for categories I've created so far. They're not just duds; everything that belongs in them now actually lives there rather than Category:World of Warcraft API.

Comments so far, or nice and shiny ideas? (Please someone say something or I'm likely to go split the main API page just to spark some discussion :-)) --Mikk 15:12, 11 June 2006 (EDT)

The FrameXML section lacks lots of information - e.g. there's absolutely no information about substitution groups, links to the API documentation of the element, etc... As it is now - there is no reason to even have it
Now there is a huge and impossible to read list of all Widgets, and on the other side the Widget pages are empty and lack other important information - like their attributes, inheritance, substitution group members (yeah again)
My suggestion:
Combine XML User Interface & Widget API into FrameXML Elements or something like that (hope you geht the point). Provide API info (lua functions) AND xml info (inheritance etc.) from a single widget on ONE page. Get rid of "API_Widgetname" pages and only
As with all the categories - sure, good idea. The only problem is that api functions without their own pages would be simply not there. so before the "switch" to pure categories we would have to create pages for every api-function so that no function will disappear. Also I would recommend subcategories representing the current categorization in World_of_Warcraft_API like Action Functions etc..
watchout 09:29, 9 July 2006 (EDT)
I never suggested we get rid of World of Warcraft API. In part for reasons you mentioned, but also because we all want a big page that we can just ctrl+f in and get the bare minimums (arguments, very brief description). And yeah, those categories you suggest would be the categories I'd want to see. Though the problem is that if a function doesn't have a page, it won't show in the category, which makes me think it's not very useful to begin with, in spite of everything =/   --Mikk 10:48, 10 July 2006 (EDT)
Good, but what are the categories for? There seems to be no actual reason to have them, you could as well put all those pages in a global wowwiki category... Categories are for easier browsing through the wiki, you can find similar pages etc. but why using categories when that huge World_of_Warcraft_API has all functions while the categories cover no more than 10% of them?
And what do you think about the Widget thing? You left that out... Personally I thinks it's better to have more information on the function/widget pages than on those overview pages. (urgs, sorry for the delay, I thought I had checked this page more often...) --watchout 05:12, 16 July 2006 (EDT)
You know... I was going to start out saying that it'd be a pain to maintain separate widget pages since you'll be duplicating a lot of information. Then it hit me that we can easily put the methods for each (base) class into subpages and pull them in as templates in each widget's page. And even keep Widget API just like it looks today by pulling them all into that page. Cool idea. I'm going to go check with Flickering though since he's generating that page from a script. --Mikk 05:45, 16 July 2006 (EDT)
Hm, you mean inherited functions etc.? I didnt think mean to take it this far, but it's ok. The only thing that needs to be considered would be performance. I know that many templates were deleted in wikipedia because of the performance problems they caused. wowwiki is at least a level beneath wikipedia in both scale and users, but I really don't know how big the performance problem with templates is... Um yeah, my main concern was that information about one and the same widget is spread and to some degree duplicated over small pages. TBH, I don't like those huge UISUMMARY_ pages, where every inherited method is listed with all arguments... Hmm, maybe I should create a sample page to show what I mean... --watchout 14:17, 16 July 2006 (EDT)
Thats about what I meant: User:Watchout/DevWidget - still needs a bit refining tho (stupid edit links) --watchout 20:35, 10 August 2006 (EDT)
I fiddled around a bit with templates etc., I think that's about it User:Watchout/DevWidget
We could also do UIOBJECT_*/Attributes|Elements|Methods|Events pages, so the information can be included via template from different pages making it easier to maintain. -watchout 08:27, 20 August 2006 (EDT)
Just to bump the discussion about what to do with the FrameXML_Documentation I guess in it's current stage it's rather useless having it there. Not that it isn't linked on any of the current index pages any longer, but it also contains only a hand full of functions, where most (if not all) are linked on the WoW-API-Page, as well. It misses a list of undocumented functions, too.
Therefore I think we'd do something about it, since currently I've got no clue, where to document functions declared in Blizzards FrameXML (for example: MoneyInputFrame_GetCopper()). I tend to add these to a category under the World_of_Warcraft_API page, but it should made clear how to handle such situations.--Luke1410 10:14, 4 May 2007 (EDT)

Why the "API" prefix? Edit

Am I the only one getting annoyed by the "API" prefix on everything? It's just forcing us to pipe links all the time when we're linking to a function. It seems to me that it'd be more wiki to just use e.g. [[GetFramerate]], [[UIObject:SetAlpha]].... ?

Yes, it'd be a lot of work to change everything. I'm up for it though :-P (Of course with redirects from the old pages; that happens automatically in mediawiki when you rename a page)   --Mikk 07:45, 3 August 2006 (EDT)

Even if you remove all "API_" prefixes, you'll still need to pipe links: [[GetFramerate|GetFramerate()]] or [[UIObject:SetAlpha|UIObject:SetAlpha(alpha)]] --Fibby 00:31, 20 September 2007 (UTC)

Not sure if this belongs here, but here is where I am putting it...

There is a paradigm assumption in the API that I want to question.
At some point a lot of work went into categorizing the methods by behavior. While I understand the concept, in practice this frequently leaves me floundering. I am used to grokking methods by class and/or name as well as by behavior type. I was wondering if I am the only one who would like to see the functions have some reference to the lua script that defines them (where applicable). For example the function ActionButtonDown is defined in the file ActionButton.lua yet on the page there is nothing to indicate that this is the case.
The end result of this distinction would be two classes (or kinds) of methods, (1)those methods defined in the interface lua files, and (2)those methods that make direct calls into the game engine. I'm not sure that I am making myself clear, but essentially calls into the engine might be shown with API:<Function>(<Param>), while functions defined in a script could be shown by <ScriptName>:<Function>(<Param>). This would help people like me to filter out the <Script>:<Function>'s and concentrate on the API:<Function>'s (or vice versa...).
IMHO the best way to do this would be to allow for 2 seperate views either by behavior category or defining object. If this is not clear please let me know and I will try to clarify.

--Bubadragon 11:52, 4 September 2006 (CST)


Hm.. In World of Warcraft API, functions defined in FrameXML are clearly denoted as "UI". Such functions have different menus and categorization, but I suppose it could be much more clear in the pages themselves. I'll tweak the template for FrameXML-defined functions to better point it out.   --Mikk (T) 09:26, 5 September 2006 (EDT)


Yes I noticed the definitions in FrameXML however with eighty something individual scriptlets in that directory (Not to mention the functions defined in the xml files themselves) finding a particular function is only slightly less difficult than finding a needle in the proverbial haystack. Awhile back I worked on the NWN_Lexicon in that case all of the functions went to the Aurora Toolset and we were forced to use an alphabetical/behavioral taxonomy. However in the WOW UI we have an object heierarchy that is availible to assist with the categorization. I wonder if there might be some way to grep the contents of the FrameXML directory and append the parent file name to the function and then perform a pattern matching on the directory to isolate the API calls from the defined functions?
One of the reasons this would be useful is to differentiate between the defined functions implemented in FrameXML (which may be overridden and or reimplemented) and the API calls that may not. I'll poke around a bit and see if there is some easy way to distinguish between the two and produce a list of what I'm looking for.

--Bubadragon 01:32, 5 September 2006 (CST)

I've added a line at the top of all FrameXML-defined functions and changed the instructions for creating function descriptions for them. They now have a direct link to the relevant Lua/XML file at http://wdn.wowinterface.com/, e.g. http://wowprogramming.com/utils/xmlbrowser/live/FrameXML/ActionButton.lua.
And, on a sidenote, real APIs can be hooked and overridden just fine :-)   --Mikk (T) 16:01, 5 September 2006 (EDT)

Would be great to also have a See Also section to group related functions.
Legionmaster 01:33, 12 August 2007 (UTC) Legionmaster

API page redesign? Edit

There's a proposal in WoWWiki_talk:Village_pump/Archive05#API_Boilerplate_Styling to change the design of API pages. Presently, there's two proposals:

  1. A complete redesign of all page content, as in Boilerplate API Documentation (archive screenshot) by Mind.
  2. Just change the {{wowapi}} template to include a bit more colorful graphics, as in User:Mikk/Dev (archive screenshot). (No changes required to individual pages)


Votes Edit

  • You can vote for two options if you're ok with either one.
Keep it as it is
  1. Keep Mikk 07:54, 3 August 2006 (EDT) - ()
  2. Keep Shadow 12:53, 3 August 2006 (EDT) - ()
  3. Keep Osiris 06:35, 7 August 2006 (EDT) - ()
  4. Keep Micah 18:40, 10 August 2006 (EDT) - (When I come to the API section of WoW Wiki I'm not here to look at pretty graphics, I'm here find information as quickly as possible. Any added graphics just add to the load time and take up UI space and changing the layout as in the Makeover proposal would simply spread the information out forcing me to have to scroll for information that is currently available in a single easy to read yet compact page. While the)
  5. Keep watchout 18:51, 10 August 2006 (EDT) - (Actually I don't think a wiki should be built with fancy graphics or style info on every page. Mikk's suggestion would be ok, but adding graphics, or other style info that are not connected to the content, into a template isn't a good thing to do. The only thing you'll accomplish is (further) destroying other skins)
  6. Keep Thrae 01:40, 12 August 2006 (EDT) - ()
  7. Keep JIM 17:07, 12 August 2006 (EDT) - (The sole advantage to Mikk/Dev that I see is that you'd know at a glance which of the multiple Wiki pages you had open was the API and which one the event. I've never wanted for that distinction.)
  8. Keep LudiKalell2 18:48, 14 August 2006 (GMT) - (I like it the way it looks now, small and simple, content >> design)
  9. Keep Starlightblunder 15:03, 23 August 2006 (EDT) - (Changing every single API page for styling purposes only is bad; a left-side "World of Warcraft API" tag isn't needed.)
  10. Keep DerGhulbus 21:40, 25 August 2006 (GMT) - ()
  11. Keep Zelgadis 00:54, 5 September 2006 (EDT) - (Improving readability should be prioritized over adding fancy looks)
Boilerplate API Documentation (archive screenshot)


User:Mikk/Dev (archive screenshot)

My idea but I'm in no way married to it - i just don't like the idea of a total makeover of all content. lots of work.   --Mikk (T) 13:38, 14 September 2006 (EDT)

  1. Template Shadow 12:53, 3 August 2006 (EDT) - (Agreed with Mikk pretty much)
  2. Template Osiris 06:35, 7 August 2006 (EDT) - (Slightly improves the appearance/readability of content, but neither suggestion is a drastic improvement over what we have now. Certainly not worth a total makeover.)
  3. Template Ralthor 08:36, 8 August 2006 (EDT) - (Love the graphic on the side, just having a colorful design on the border makes a page full of text seem easier to read.)
  4. Template Kirkburn 10:50, 8 August 2006 (EDT) - (Nice design :))
  5. Template Progdog 20:14, 16 August 2006 (PST) - (I like the template. If anything, maybe it will inspire folks to work on pages more?)
  6. Template MentalPower 21:12, 16 August 2006 (EDT) - (I like the template, the complete re-design is not worth it IMHO)


Comments Edit

Design should never rule a wiki, content should. So you shouldnt decide whats fancy looking, but what's practical. The boilerplate thing doesnt seem practical to me, just restrictive (no offense) --watchout 19:05, 10 August 2006 (EDT)

I completely agree with your points about skins. I designed the vertical bar to work as well as possible on other skins. Yes, it still becomes dark, but it's definitely readable and doesn't hurt too much (look for yourself). And, yeah, it's up there on the list of stuff to fix when we get CSS access, if it does end up getting chosen. --Mikk 20:31, 10 August 2006 (EDT)
Using Monobook myself - dark text on light background is more convenient to read (but thats another topic...) - And from my point there is a break in the style. Its perfectly readable, but just breaks the style. But when I say content is more important to me, I mean it. It's ok with me. I just didnt see a reason to work on something when there's no need ;-). Oh and you should work on antialising the graphics (use PNG24 maybe? Filter out M$ via conditional comments).
(But the Boilerplate thing I still don't like because it kills content, making it harder for me to read etc.) --watchout 20:52, 10 August 2006 (EDT)


Re: User:Zelgadis/Dev Edit

  • I do not believe that changing the layout of World of Warcraft API to User:Zelgadis/Dev is a good idea. Consider e.g. "QueryAuctionItems("name", minLevel, maxLevel, invTypeIndex, classIndex, subclassIndex, page, isUsable, qualityIndex)" in a table layout.
Further, I do not see the point of changing Help:API Function articles to the style in API LFGQuery. It'd be a lot of work to no gain visible to me (other than the info about which[[:Category:API events are triggered, which is certainly a very good idea, but could be standardized in the current design). On the contrary, I think it has too many fonts and makes reading harder than it needs to be; c.f. standard typesetting practice: you want to keep the number of distinct fonts in a given area small so that the eye does not constantly need to "re-train" what it is expecting for "word pictures" (hm.. wrong word; sorry, I haven't had to talk typography in anything other than Swedish previously =)).
  --Mikk (T) 17:07, 3 September 2006 (EDT)
Thanks for replying, Mikk.
  • I fully share your concerns. The prototype shouldn't be included in the index, that's why it currently only pulls the descriptions. About the fonts: I tried to introduce some of the look of a syntax highlighting environment there, but it really could be better. The typesetting shouldn't be the concern of the boilerplate anyway. Next about[[:Category:API events: It really would be nice to have that info in all articles as a long-term goal. Would also be cool to have them clickable, so you can immediately read about them too.
  • I tried to improve the way descriptions are pulled from articles, but it didn't really work out. It's too complicated to use, too unrealiable and too ugly to use it in the real world =/. As a result, I removed my proposal for now and changed my documentation to look like the standard boilerplate.
  • I think I made it look all wrong, I didn't want to tell how things must be done but rather give some ideas what could be improved. This means I still like the idea of having the index generated automatically or even some real syntax highlighting, even if my attempt at implementing these weren't too good. I would still like to propose new ideas, but I'll better fully develop them first so people don't get the wrong idea. I'll change my vote on this subject to Keep for now.
Zelgadis 00:49, 5 September 2006 (EDT)


Got rid of "API TYPE" prefix Edit

Welpz, I came to the end of my patience with piping links all the time to hide the "API TYPE" prefix, so now the API type pages are simply named e.g. "bagId", "unitId", etc, the wiki way. → API types.   --Mikk 13:18, 13 August 2006 (EDT)

Asian translation Edit

There already was a discussion about that on Talk:World_of_Warcraft_API/Archive_2006_June#Can_someone_verify_Fantasy55.27s_changes.3F. Now its on some of the API-Function-Pages, like API_ActionButtonDown - what to do?

Personally, I think there's still no value for a translation. If someone can read and use the rest of this wiki, he/she can also read those articles (My native language is german, no problems here). Everything else is duplicates. -watchout 02:37, 26 August 2006 (EDT)

The right way is certainly NOT to clutter duplicate text into the same page; imagine a dozen languages saying the same thing in a single page? Unreadable. Revert it. --Mikk 06:27, 26 August 2006 (EDT)

"Triggers[[:Category:API events" section in API descriptions

I've added a "Triggers[[:Category:API events" section in Help:API Function articles as per Zelgadis' excellent idea. Of course, this won't affect all the already-existing pages. Feel free to fix y'all :-)   --Mikk (T) 14:51, 7 September 2006 (EDT)

I think "related[[:Category:API events" would have fit better. -watchout 16:25, 14 September 2006 (EDT)
Hmmmmmm... This would have included[[:Category:API events where the function is often called? If so, I'd suggest a different section (the already-existing "Details" section, perhaps?). Having a separate list of[[:Category:API events that are actually triggered by calling a function seems useful to me.
... or am I misunderstanding you horribly? :-)   --Mikk (T) 04:50, 15 September 2006 (EDT)

a question Edit

I'm just starting (today actually) to learn scripting and trying to set it up so that my character will say my target's class in /say.

Here is what I have: /script localizedClass = UnitClass("target");SendChatMessage ("My target is a : ' .. localizedclass .. '.")

When I do this though it just comes out as a /say message saying "My target is a : ' .. localizedclass .. '." What am I doing wrong?

Two things. You're mixing quote types, and you've got the case wrong in the label name. The second problem is hidden by the first. This should work:
/script localizedClass = UnitClass("target");SendChatMessage ("My target is a : " .. localizedClass .. ".")
  --Mikk (T) 14:21, 5 November 2006 (EST)

Searching for an API Edit

Hello, I'm not aware with wow addon programming, but I'll try to make one or two little tests. What I wanted to do is one add that tell me the distance between me and another character (computer or human character), but I don't find any API to show this. Does it exist?

The GetPlayerMapPosition function can give you map coordinates for you and other players in your party or raid, and you can use pythagoras to get the distance. For mobs, NPCs, enemy players, players not in your party/raid, or players in your party/raid that are in an instance, there is no way to get their position or distance from you; this is by design. --Karrion 21:04, 16 November 2006 (EST)

TBC/WoW 2.0.1 API updates Edit

With the sweeping API changes to WoW API coming in TBC and 2.0.1 currently on the PTRs, I believe that updated doc is warranted. Naturally, it doesn't make sense to replace the existing doc until it is fully depricated, but I think that it would be very useful to start noting 2.0.1 changes.

For example, GetItemInfo() has had a change in the parameters that it returns. I think it would be very worthwhile to have a template that can be placed on the page that links to documentation for a TBC/2.0.1 version of the call. That way, I can browse the list as normal and access the updated doc if it is relevant to me.

There would also need to be a section (either a new page, or a new section on the API page) for new calls in TBC.

Finally, a place to start documenting the secure frames and secure state header stuff would be extraordinarily useful.

Thoughts?

--Antiarc

I'm pretty sure someone should start doing that. Pre-2.0 addons will lose a good amount of their functionality, but people seem to have to dig stuff themselves currently. But before it's done I've made myself a 2.0.1 global function list so I can find function names when necessary.

--Drundia 14:16, 19 November 2006 (EST)

I have added a cross-reference to two pages which isolate the changes brought by patch 2.0 - it seems to address this question. --Hammersmith 00:04, 7 December 2006 (EST)

Is there any way? Edit

Hi guys,

just playing around with addons for the first time. now i got a little problem - do you know how to create any file and save your tabledata into it? there´s no os function inside blizzard´s lua. or is there a way to start a batchfile or something like that?

regards, Thomas (AVL)

I highly recommend joining the IRC chat mentioned at WoWInterface to contact knowledgeable AddOn devs in real-time. --Fandyllic (talk) 3:47 PM PST 16 Nov 2006
There is (quite deliberatly) no way to save data to an external file in real time, or to communicate with any external process. For keeping data between sessions, there is the SavedVariables mechanism, through which variables can be saved to a file, but the file is only written on logout or UI reload. --Karrion 20:58, 16 November 2006 (EST)

How to collect character info and upload it to a website? Edit

How would I go about auotmaticly uploading saved info about character info to a website? Or can you direct me in the right direction to find this info.

Thank you in advance

http://wowroster.net/ has a program called UniUploader that does exactly what you described. Posted by: EGingell (T|C|F) on 11:21, 8 August 2007 (UTC)

Ammunition Edit

I'm making an addon to see if I can basically, and I was wondering if there was any API for checking hunter's ranged ammunition amount. I could do a GetItemCount("Sharp Arrow") but that would only work with hunters using sharp arrows, right? What can I do? -- Yoda  talk / cont 11:51, 23 March 2007 (EDT)

find out all arrow/bolt/shot/whatever names... get their item counts, sum it up, there you go. -watchout 12:56, 23 March 2007 (EDT)


PromoteToLeader, PromoteToAssistant, etc Edit

I noticed in the FrameXML that these all accept the UnitId or the PlayerName, but they also can accept a number as a second parameter. In UnitPopup.lua it uses PromoteToLeader(unit, 1) and PromoteToLeader(fullname, 1). Does anyone know what difference the number makes? Ravas 16:31, 8 June 2007 (UTC)

Rotating MiniMap Edit

Anybody know how to get North on the Minimap. I'm trying to figure out how to make a bigger "N" so I can see the friggin' thing. And, no, turning off the rotation is not an option. Egingell 11:57, 7 July 2007 (UTC)

Well, I found out one thing, it's a Model, so it's not easily embiggened. I did; however, do this, "MiniMapCompassRing:SetFrameLevel(10);" to make it appear above the buttons around the Minimap. This definitely helps with the visibility problem. Egingell 14:51, 7 July 2007 (UTC)

String Concatenation Operator Edit

I spent hours messing around with the SendChatMessage() function trying to add the string return value from UnitName() to " is behind you." Finally, I figured out that the correct concatenation operator for strings is '..' not '+'. I found this out in a script example, but the operator is not described and I cannot find any page that contains this information. What would be the best way to go about showing this information? One idea is to make a new page called "String" and a couple redirects, then include this and other information, such as how to properly enclose a string, on that page. There could be several pages like this under a new Category, each about the various primitive datatypes available to scripts and information about how to use each one. -- OranL 14:37, 6 August 2007 (UTC)

The best way would be to actually read the manual for the Lua language, helpfully linked to on the Lua page. --Mikk (T) 10:56, 8 August 2007 (UTC)
Or just google "lua string concatenate" and click on the first result. Incidentally, it brings you to Programming in Lua. Not that hard to find. Tifi 03:52, 10 November 2007 (UTC)

I don't know about you, but I find the official Lua reference pages to be extremely difficult to follow and I've been a coder for over 10 years.

Anywho, this is my idea: A page called Operators listing all of the operators ("--", "--[[...]]", "..", "+", "=", "==", "-", "/", "*", ">", ">=", "<", "<=", "~=", "and", "or", "not", ":", ".", "[...]") and a page called Datatypes listing all of the datatypes ("string", "number", "nil", "table", "function", "boolean").

They could be structured like this:

OperatorsEdit

--
Single-Line Comment.
--[[...]]
Multi-Line Comment.
Can also be used to make inline comments (e.g. function (--[[string]] arg1) end)
..
String concatenation.
Must be string values. You can cast other types to string with tostring().
+
Addition.
Must be number values. You can cast other types to number with tonumber().
=
Assignment. Set a variable equal to a value.
-
Subtraction.
Must be number values. You can cast other types to number with tonumber().
/
Division.
Must be number values. You can cast other types to number with tonumber().
*
Multiplication.
Must be number values. You can cast other types to number with tonumber().
==
Equality. Test if two values equal each other.
>
Greater Than. Test if the value on the left is greater than the value on the right.
Must be number values. You can cast other types to number with tonumber().
>=
Greater Than or Equal to. Test if the value on the left is greater than or equal to the value on the right.
Must be number values. You can cast other types to number with tonumber().
<
Less Than. Test if the value on the left is less than the value on the right.
Must be number values. You can cast other types to number with tonumber().
<=
Less Than or Equal to. Test if the value on the left is less than or equal to the value on the right.
Must be number values. You can cast other types to number with tonumber().
~=
Not Equal to. Test if two values are not equal to each other.
and
If the condition on the left and the condition on the right evaluate to true, then the expression returns true.
or
If the condition on the left or the condition on the right evaluate to true, then expression returns true.
not
If the condition on the right evaluates to false, return true.
:
Table function accessor.
Use this to call a function in a table (e.g. MyTable:MyFunction(val1, val2)).
.
Table value accessor.
Use this to retrieve a value from a table (doesn't always work as expected) (e.g. MyTable.value1).
Can sometimes be used to call a function depending on how the function was declared (e.g. MyTable.MyFunction(val1, val2)).
[...]
Table value accessor.
Use this to retrieve a value from a table (always works) (e.g. MyTable["value1"]).
Can sometimes be used to call a function depending on how the function was declared (e.g. MyTable["MyFunction"](val1, val2)).
  • Note with and and or: If the first conditional would cause the whole expression to return the same value regardless of the outcome of the second conditional, then the second conditional will not be tested. This is called "short circuiting".
  • Order of operations:
1. parens, inner-most to outer-most (including conditional expressions).
These two examples are not the same.
if (not a and b) -- if a is false, nil, or 0 and b is not false, nil, or 0, return true.
if (not (a and b)) -- if a is false, nil, or 0 or b is false, nil, or 0, return true.
2. * and /
3. + and -

DatatypesEdit

string 
A value consisting of alphanumeric and special characters. Basically anything inside of quotation marks.
Examples of string values: "string", "true", 'false', "0", "5", "I have 5x[Corpse Harvesters]".
number 
A value consisting of only numbers and passed without quotation marks.
Examples of number values: 1, 5, 10.7, 0.58, 1e10.
nil 
Variable is not set or it was explicitly set to nil.
table 
A table is a collection of all other types of values accessible by a key (string) or index (number).
Example of a table value: { "false", ["a"] = false, function() end, }
function 
A function. Can't have a structured language without functions.
Example of a function value: function(args) DEFAULT_CHAT_FRAME:AddMessage(args) end
boolean 
true or false

Posted by: EGingell (T|C|F) on 11:07, 8 August 2007 (UTC)


I'd vote for this solution. It makes sense, but should we add "API" to the page names? -- OranL 21:13, 9 September 2007 (UTC)

Uncategorized Functions talk Edit

Judging by the code in FrameXML/PlayerFrame.lua:243, (function PlayerFrame_UpdatePlaytime), it appears that PartialPlayTime, NoPlayTime, and GetBillingTimeRested now are related to the play time limiting capabilities. Related strings exists in FrameXML/GlobalStrings.lua:3081, which talk about being online too long. I have, however, been unable to find further information in Blizzard's code. -VeqIR

As a reply to you VeqIR: Well, if you remember in EU when they enabled the play limitation system for the 2.0 PTR we had limited playtime. After 5 hours you end up exausted and the game tells you to take a break, not giving you experience nor any loot. You can't even complete quests and this is how it also is in Asia to reduce their playing times. Those functions are used by the player frames to change the tooltip and icon. Green face is normal, yellow is half tired (giving half experience) and red is exausted giving no loot or experience (no quest completion either). This feature is not related to the character rested state, but global account play time reduction so people don't kill themselves on their PCs. :P

I guess these 3 first functions work for an account under a parental control. If anyone wants to setup parental control for yourself and see if this is indeed so - feel free to post your findings (I'm just too lazy). Two last functions defined in MinigameFrame.lua and refer to what appears to be an abandoned feature of the game. Maybe the developer who was writing that addon got fired? -- Vladinator 09:43, 04 January 2008 (UTC)

Cant get my event to trigger Edit

Bramming (talk) 13:53, 26 November 2008 (UTC)Hey. My addon loads just as its supposed to, but for some reason i cant get the event to trigger. Its supposed to trigger when someone whispers "ding" but it doesnt. i even added "DEFAULT_CHAT_FRAME:AddMessage("IS Chat_MSG_WHISPER proc");" so i would be able to see if the event triggered properly, but it doesnt. Heres my code :

local frame = CreateFrame("Frame", "HelloWorldFrame") -- this corresponds to <Frame name="HelloWorldFrame">, the "frame" in "local frame" is just a pointer reference to HelloWorldFrame

frame:SetScript("OnEvent", IS_OnEvent); -- <OnEvent> IS_OnEvent(); </OnEvent> 


frame:RegisterEvent("CHAT_MSG_WHISPER");

function IS_OnLoad()
    DEFAULT_CHAT_FRAME:AddMessage("IS loaded");
end

function IS_OnEvent(event)
if (event == "CHAT_MSG_WHISPER") then
    DEFAULT_CHAT_FRAME:AddMessage("IS Chat_MSG_WHISPER proc");
    Msg = event(arg1);
    Name = event(arg2);
    if (Msg == "ding") then
        SendChatMessage("Gz", "WHISPER", nil, Name);
    end
end
end

Try this instead, changes are in bold.

local frame = CreateFrame("Frame", "HelloWorldFrame") -- this corresponds to <Frame name="HelloWorldFrame">, the "frame" in "local frame" is just a pointer reference to HelloWorldFrame

frame:SetScript("OnEvent", IS_OnEvent); -- <OnEvent> IS_OnEvent(); </OnEvent>

frame:RegisterEvent("CHAT_MSG_WHISPER");

function IS_OnLoad()
    DEFAULT_CHAT_FRAME:AddMessage("IS loaded");
end

function IS_OnEvent(self, event, ...)
    local arg1, arg2 = ...
    if (event == "CHAT_MSG_WHISPER") then
        DEFAULT_CHAT_FRAME:AddMessage("IS Chat_MSG_WHISPER proc");
        Msg = event(arg1);
        Name = event(arg2);
        if (Msg == "ding") then
            SendChatMessage("Gz", "WHISPER", nil, Name);
        end
    end
end

Posted by: EGingell (T|C|F) on 18:07, 24 November 2008 (UTC)


Bramming (talk) 13:53, 26 November 2008 (UTC)Thanks for the help m8. The addon doesnt seem to work though. It loads up fine saying "IS loaded" but it wont go any further. heres the current code (taken from you egingell :) )

local frame = CreateFrame("Frame", "HelloWorldFrame") 

frame:SetScript("OnEvent", IS_OnEvent); 

frame:RegisterEvent("CHAT_MSG_WHISPER");

DEFAULT_CHAT_FRAME:AddMessage("IS loaded");


 function IS_OnEvent(self, event, ...)
    local arg1, arg2 = ...
    if (event == "CHAT_MSG_WHISPER") then
        DEFAULT_CHAT_FRAME:AddMessage("IS Chat_MSG_WHISPER proc");
        Msg = event(arg1);
        Name = event(arg2);
        if (Msg == "ding") then
            SendChatMessage("Gz", "WHISPER", nil, Name);
        end
    end
end

This should work better:

local frame = CreateFrame("Frame", "HelloWorldFrame") 
frame:SetScript("OnEvent", IS_OnEvent); 
frame:RegisterEvent("CHAT_MSG_WHISPER");
DEFAULT_CHAT_FRAME:AddMessage("IS loaded");
function IS_OnEvent(self, event, ...)
   local arg1, arg2 = select(1, ...)
   if (event == "CHAT_MSG_WHISPER") then
      DEFAULT_CHAT_FRAME:AddMessage("IS Chat_MSG_WHISPER proc");
      if (arg1 == "ding") then
         SendChatMessage("Gz", "WHISPER", nil, arg2);
      end
   end
end

Posted by: EGingell (T|C|F) on 19:57, 25 November 2008 (UTC)

Bramming (talk) 13:53, 26 November 2008 (UTC)Hmm it still doesnt work which makes me wonder if any addons would conflict. i only use the ace2based addon Simpleminimap so i can do /rl (reload ui). Hope it isnt the prob.

Btw thanks for all the help, really appreciate it :)


Please sign your posts (four tildes (~) in a row). As for the code, you don't need to use ... at all. Try something like this:
function IS_OnEvent(self, event, arg1, arg2)
  if (event == "CHAT_MSG_WHISPER") then
-- and so on
-- Tuhljin (talk)

Bramming (talk) 13:53, 26 November 2008 (UTC) Hmm it still doesnt work. Im beginning to feel really lost, since nothing produces an error, but still doesnt work. Again, thanks for help :)

There's no reason, at all, that it shouldn't work. How are you testing it? I whispered myself the word "ding" and I got a whisper back. Posted by: EGingell (T|C|F) on 18:53, 26 November 2008 (UTC)

Bramming (talk) 12:49, 27 November 2008 (UTC)Hey. Testing it with no other addons running. Tried both whispering myself, and getting a friend to whisper me. Maybe something is wrong with my code? here it is:

local frame = CreateFrame("Frame", "HelloWorldFrame") 
frame:SetScript("OnEvent", IS_OnEvent); 
frame:RegisterEvent("CHAT_MSG_WHISPER");
DEFAULT_CHAT_FRAME:AddMessage("IS loaded"); 

function IS_OnEvent(self, event, arg1, arg2)
  if (event == "CHAT_MSG_WHISPER") then
      DEFAULT_CHAT_FRAME:AddMessage("IS Chat_MSG_WHISPER proc");
      if (arg1 == "ding") then
         SendChatMessage("Gz", "WHISPER", nil, arg2);
      end
   end
end
Your problem appears to be that you're assigning the IS_OnEvent function to your frame before you ever declare what the function is. Move your frame:SetScript call so that it falls after your definition of IS_OnEvent. Lua is a sequential programming language, so you have to do things in the order they appear. In this case, you create a frame, define your function, and then assign that function to your frame. Curtwulf (talk) 15:16, 28 November 2008 (UTC)

Bramming (talk) 17:05, 29 November 2008 (UTC) Ah perfect! Thanks a lot for helping Curtwulf, Egingell and Tuhljin. I really appreciate it! :)

Full API Dump for WoW v3.0.3 Edit

Hello.

I've integrated an API dumper into one of my internal projects and thought the output might be useful to the people here. I'm currently in the process of writing a standalone dumper that I can release as open source, and that won't require function hooks like my current one does (assuming there is sufficient demand).

Anyway, here's the output (used pastebin because its quite long): http://pastebin.ca/1284089

I have OMITTED the following:

  • Function pointer.
  • Timestamp.

I have MODIFIED the output as such:

  • Sorted into alphabetical order.

If you would like the unmodified output (dumped in the order that WoW registers the functions, along with all the function pointers which are useful if you want to reverse the parameters or return value of the undocumented functions) let me know. I can be contacted on MSN at joshua[dot]lizard[at]gmail[dot]com or by email at cypher[dot]jb[at]gmail[dot]com.

Furthermore, if you think a public tool to dump out WoWs full API in an automated fashion would be useful please leave a comment or let me know and I'll move it higher up my priority list.

Cypherjb (talk) 04:42, 13 December 2008 (UTC)

Protected API Type 2 Edit

"Protected APIs" fall into 2 categories. API's that can never be called from insecure code, and API's which can be called in the handlers for hardware events ie. OnClick. An example is the LFGQuery api.

Is there a label we can attach to these api's? What would it be since protected is already taken?

Sylvanaar (talk) 12:59, 30 December 2008 (UTC)

"Controlled" since they have to go through handlers? "Tamed", "Handled", "Secured"? Curtwulf (talk) 16:09, 31 December 2008 (UTC)
There's actually a third type too isn't there? ForceLogout is not protected in the sense it can only be called from Blizzard's code, if you reverse the client you'll see the protection is on the server, the function used to determine whether a protected function is being called from addon code or not is never called, the ForceLogout function simply calls CNetClient::Logout with the param "Force" set to 'true'. The server then denies the logout if you do not have the required permissions. I am unaware of any other functions using server-side protection. Cypherjb (talk) 11:10, 3 January 2009 (UTC)

Macro API Edit

I know this isn't the proper page to ask this, but I got no responses on the main UI portal's talk page. I have copied the wonderful format of the API repository here to create a Macro API section. I would like to see it added to the Main UI portal under Holy Writ. I believe it classifies as such, and the list was directly extracted from the global environment in-game, so I don't see why not. Due to UI limitations and the changes to the Secure Templates, macro code is just as integral to mod function as script actions sometimes. This format provides a lot more flexible format and clearer information than any other pages or sections I've seen. Who manages the main UI portal anymore? My responses there have gone unanswered. --DrDoom (talk) 01:50, 9 January 2009 (UTC)

It looks very well done to me. Maybe try leaving a message on one of the active admins' talk pages? -- Tuhljin (talk) 22:10, 9 January 2009 (UTC)

Question - Addons - Need Help Edit

Hello! I've been working with a Addon for several days now and i just can't find a solution to the problem..

So.. What do i want? Well, as i said, i've been trying this for quite some time now and i just cant get it too work.. What i want is an addon which tells me if a specific Spell is usable by making a button/image of the spell appear in the middle of the screen and stay there until i use it.

An Example: As Paladin, you can't use the spell "Judgement of Light" until a seal Spell is used. So then i use my seal spell, an image or Button of "Judgement of Light" will appear at the center of my screen(well, abit right of it would be better ^^) until i've used it (or until it's not usable)

This is what i have now:

-- Global Variables
f = CreateFrame("Frame",nil,UIParent);
t = f:CreateTexture(nil,"BACKGROUND");
SetupComplete = false;  -- If False then the frame was not created.
DisplayError = true;    -- Nevermind these variables, they are just used for debugging.
DisplayDone = true;		-- Nevermind these variables, they are just used for debugging.
Debug = true;			-- Nevermind these variables, they are just used for debugging.
-- End Global Variables


function HelloWorld_OnUpdate(self)
	
	if (not SetupComplete) then
	
			f:SetFrameStrata("BACKGROUND");
			f:SetWidth(128);
			f:SetHeight(64);
			
		name, rank, iconTexture, count, duration, timeLeft =  UnitBuff("player", "Judgement of Light");
			t:SetTexture(iconTexture);
			t:SetAllPoints(f);
			f.texture = t;

		f:SetPoint("CENTER",0,0);
		
		SetupComplete = true;
		if (DisplayDone) then
		--	message("Setup is now done ^^");
			DisplayDone = false;
		end
	
	end
	
	if (SetupComplete) then
		usable, nomana = IsUsableSpell("Judgement of Light")
		if (not usable) then
		f:Hide();
		else
			if (Debug) then
				message("F:Show() = True!");
				Debug = false;
			end
			f:Show();
		end
	else
		if (DisplayError) then
			message("Error: Setup is not complete.");
		DisplayError = false;
		end
	end
end

Sorry, i forgot to sign my Post before! anyway, i updated the Script and everything works, expect that the Frame does not show up on the screen! It shows me the Debug message i made (Like "F:Show() = True!") but the frame never shows up, so it seems that my frame Variable f is either nil or the something else..

Anyone, help?

LaNiZ (talk) 19:41, 11 January 2009 (UTC)

Its really a bad programming practice to use a variable name like 'f' in the global namespace. Many authors don't think about variable scoping when they write, so they might be overwriting your variables. Unless you plan to have these variables modified outside of this file, you should define them as local. Its good practice to define every temporary variable in the local namespace unless you really need it to be global. --DrDoom (talk) 23:31, 11 January 2009 (UTC)

For more on Scoping <-- click here.
As to the problem at hand, try this:

-- don't reinvent the wheel 
local name, rank, iconTexture, usable
name, _, iconTexture = GetSpellInfo(20185) -- Use this instead, it always provides the icon.

local f = CreateFrame("Frame", "My" .. name .. "Button", UIParent, "ActionButtonTemplate");
local t = _G["My" .. name .. "ButtonIcon"]

f:EnableMouse(false) -- won't work as an action button, so might as well disable the mouse.
f:Hide()

f:SetFrameStrata("BACKGROUND");
f:SetWidth(128);
f:SetHeight(64);

f:SetPoint("CENTER",0,0);

-- this will never change, so it doesn't need to be in the OnUpdate handler.
t:SetTexture(iconTexture);

-- this way, you can safely delete the XML file.
CreateFrame("Frame"):SetScript("OnUpdate", function (self, elasped)
    if (not IsUsableSpell(name)) then
        f:Hide();
    else
        f:Show();
    end
end)

As a side note, right in the center of the screen might not be the best place for it. :)
Posted by: EGingell (T|C|F) on 00:44, 12 January 2009 (UTC)

It works perfect now! Thanks! (i already planned to change the position of the frame from the center =P) i understand everything in the script, expect the line: "local t = _G["My" .. name .. "ButtonIcon"]" i know that you assign the texture/icon to the local variable t, but what i dont understand is why you are using _G.. (as you maybe can guess.. i'm new to LUA)

LaNiZ (talk) 06:07, 12 January 2009 (UTC)

Hey, you deleted my comment! :P Ah well, I'm glad that EGingell and I could help you get it working. As for _G, that's the global table, where all the global variables are stored. He used it because the name of the variable wanted there changes depending on the variable name. Another way to do the same thing is with the getglobal function, though it's more efficient to use _G. -- Tuhljin (talk) 09:17, 12 January 2009 (UTC)
I wrote it that way to be more accommodating to multiple spells. These two lines can be changed if so desired:
-- dynamic button
local f = CreateFrame("Frame", "My" .. name .. "Button", UIParent, "ActionButtonTemplate");
local t = _G["My" .. name .. "ButtonIcon"]

-- not so dynamic button
local f = CreateFrame("Frame", "MySpellReadyButton", UIParent, "ActionButtonTemplate");
local t = MySpellReadyButtonIcon

Posted by: EGingell (T|C|F) on 14:44, 12 January 2009 (UTC)

Around Wikia's network

Random Wiki