Wowpedia

We have moved to Warcraft Wiki. Click here for information and the new URL.

READ MORE

Wowpedia
Advertisement

This is the talk page for discussing improvements to the World of Warcraft API article.

Archived talk


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

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, enchants

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

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?

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. https://github.com/Gethe/wow-ui-source/blob/live/Interface/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?

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

  • 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

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

  • 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 Boilerplate:API Function 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

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

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 Boilerplate:API Function 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

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

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

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?

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?

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

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

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

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

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:

Operators

--
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 -

Datatypes

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

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

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)


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)

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)
Advertisement