Talk: World of Warcraft API

The all new WoWAPI-Page layout

Sorry to say this guys, but I hate the new layout. I don't even think it's less overwhelming, since the site's structure is just growing more complex. While splitting the data and arguments section onto its own page seems to be a good idea, the alphabetical division of the API-functions onto several pages slows down the whole process of looking up functions significantly. I tried out the new layout today and i must say that it simply decreases efficency of the site a lot. If you really want to add additional structure to this section (which i do not think is neccessary, since in the end, it is just a reference, not a textbook), i'd suggest you do it by anchoring the different subsections, but for god's sake, please do not split them up! -- DerGhulbus 23:05 17 Jan 2006 (EST)

You can still use World of Warcraft API/All. Did you not see the link at the top? I'll make it more obvious.

Also, I believe Schmidt is going to add many more links. If not, I will.

--Fandyllic 6:20 PM PST 17 Jan 2006

Keeping those two pages up-to-date at the same time isn't gonna be easy. But i guess i'll give it a try.

Oh, and thanks for making the link more obvious ;)

-- DerGhulbus 12:01 18 Jan 2006 (EST)

With page histories, someone can always merge changes from the All page to the sub-pages or vice-versa. Hopefully, Blizzard won't be changing stuff too frequently. Te expansion will be when it gets really tough.

--Fandyllic 10:34 AM PST 18 Jan 2006

While I appreciate what you community editors are trying to do, I gotta ask. Did you consider asking the people who use the API pages on a regular basis what they want and need?

--The Nerd Wonder 02:09, 19 Jan 2006 (EST)

I wasn't planning to add any more links until something was decided. First off, as The Nerd Wonder hit on, I'm not one that uses this page since I have little interest in writing API. I'd like to learn it sometime, but I don't exactly have time nor the capacity right now. As I figured it, the old format was just ugly. If everyone liked it the way it was, and everyone was able to contribute (I mean, if your browser had no issues with it), then I suspect it'd be fine. I've only used IE and Firefox, so I don't know if any other browser wouldn't be able to support at least reading a long page such as that. And I don't remember seeing any complaints about the length.

I don't see how any number of edits can make the full list (such as /All is now) look any better than it does now. Maybe it doesn't need to look any better. After all, geeks (no offense) don't need things to look pretty and fluffy or anything. Me, I don't care if it looks the way it does now or the way it was. If I was a little more interested in coding, however, I would prefer this layout for one major reason: It's more manageable to me. I can look through, and see "group functions" and say "Hey. I need to see what I can do with group functions because I'm trying to figure out how to do...." or "I wonder if I can write a mod that reads the quest log and does this and that with it."

If you're searching for a specific function, there are two things to be done:

• Search through Special:Allpages, such as Special:Allpages/API, and it'll list all the pages in alpha order beginning with API.
• Have a user-created alpha catalog of all the API functions (including red links, of course).

These two options cover the current complaints that you all have, right? Schmidt 02:40, 19 Jan 2006 (EST)

I created World of Warcraft API/Alpha for the alpha catalog, which is what some seem to want (which doesn't make sense to me). If the link belongs on the main page here, link it, but I for one wouldn't want it to be the main API listing. Schmidt 08:01, 19 Jan 2006 (EST)

Looks like we might as well just swap World of Warcraft API/All back to World of Warcraft API, since they are roughly the same size again... Maybe we can make a TOC-like page and put it at World of Warcraft API/TOC, but make it and its sub-pages deprected, since the large page thing isn't really an issue anymore and most devs wouldn't suffer such a limitation anyway in their browser.

--Fandyllic 2:37 PM PST 19 Jan 2006

The whole argument doesn't make sense at all. See, first off, no browser that anyone can name has said limitation, so there was no need to change it at that point, for the sake of that. However, for the sake of appearance, it might be nice to have it look a little cleaner. (It doesn't, right now.) Further, it doesn't make sense to have them grouped in alpha order, because any function may be called by any given command. Such as in BASIC, you have PRINT; in C, you have printf; but in Javascript, you have document.write. Each of these could be categorized under one logical umbrella, but the commands are completely different. My point is that the categories are necessary for any developer not 100% fluent in WoW's code (and no expert C developer would have any advantage over a beginning WoW developer in this instance). And now people don't want to click one more time. What's the big deal? One more freaking link to follow. You should already be able to see what category it would be set under, so you just click the appropriate link. And why do you need documentation anyways, you fluent coders? And if you're looking for a specific function, you can always type it in the friendly Google box and search for it. Furthermore, you could just bookmark each of those 6 (SIX!) pages. Whatever. I guess I'm just irritated at these petty (seems to me) arguments. And I'm sleepy, too, but I have a class in an hour and a half that I have to sleep through and after that I have an hour drive home, and then PT in the morning.

As I think about it now, it only makes sense to go with the developers on this, because they're the only ones who will look at the page. It is readable as it is, so making it more readable would only make it more readable. Schmidt 18:05, 19 Jan 2006 (EST)

First off I am enormously indebted to everyone who's contributed to the wiki, especially those that maintain and pay for it. I'll try to contribute more and certainly I'll go with the flow on whatever format is settled on. But to give a little more insight: groupings aren't clear cut. When you want to know the cooldown left on an item, the function you use depends on where the item sits. GetActionCooldown and GetContainerItemCooldown are in a different group than GetInventoryItemCooldown. It doesn't make the page unusable to break apart the functions into their arbitrary categories, but it does mean that many searches of functions require not one extra click but many: sometimes back and forth into every category and searching for the reference.

Experience and time don't reduce the use of the API page as a reference, either. I have done A LOT of work with GetItemInfo but I constantly come back to look up returns. There is just so much information that nobody could be expected to contain it all in their heads.

Also when using the API pages as a reference, it's often useful to refer to other functions that perform a similar task, which may be in a different group. It's not life-or-death but the categorizing doesn't improve its role as a reference of which the API page has performed flawlessly and elegantly in the flat/ugly style that it was.

The value of the API page as a reference can't be underestimated. The modding community would be crippled without it. Tutorials only serve their purpose until a person can no longer learn anything from them. This API page is used just as heavily, if not more, long after tutorials cease to teach.

I see it's back to the old style now which makes me very happy. I'll live if it goes back the other way but it will likely be in the depreciated listing. -- Gello 20:20, 19 Jan 2006 (EST)

Cosmos API or official API?

2 points I'd like to discuss

It should be noted that this is the COSMOS-WoW API. Not a Wow API. The majority of commands etc will not work unless COSMOS is installed.

also, when searching from the main page for "API" I get no results. I have to search for "macros" then click the link to this page in order to reach it.

(I'm a Wikinewb so please bare with me. But I love the concept and looking forward to participating)

I think you are mistaken. The page only lists global functions that are in fact defined by Blizzard. There isn't a single function that requires Cosmos. You might be confused by the fact that most of these functions are defined internally in WoW, and not in the Lua files, hence you don't see a definition for them if you have a look at the files in the Interface folder. It is of course possible that there are errors on the page, and a given function might not work as a result. -- Lego 12:24, 1 Dec 2004 (EST)

I think you're right *blush* these are all /script [function] or /console [function] commands then? That should perhaps be noted in the initial paragraph to clarify their overall usage. --BillyZ 15:39, 1 Dec 2004 (EST)

Let me try and explain. Lua is the language you use to issue commands and control a lot of the client. There are two places where Lua can be used:

• the /script [string] command in-game, where "string" can be anything that is a valid expression in the Lua language
• the interface files (.xml and .lua)

The list of functions that you see on this page are globally accessible functions, that can be called anywhere where Lua can be used. That's why we don't say they are /script commands or interface commands, they are both. They are Lua global functions, usable anywhere where Lua is. You are of course right in that the page implies they are for interface customization, where in fact they can be used in macros as well as part of the /script command. -- Lego 20:15, 1 Dec 2004 (EST)

How to find function definitions?

Just wondering where these defintions are coming from (or where the original API document came from)? I've played around with an MPQ reader a bit, but can't find any readable stuff. Are there some binary files that need to be decoded, or are we just using limited information Blizzard released some time ago, or what's the situation here? There seem to be loads of useful functions, but I've no idea how to use them without at least a function prototype. TIA. -- Goldark 10:56, 10 Dec 2004 (EST)

Character Function "AcceptXPLoss"

Now that you don't lose XP, but Dur, is this function's name changed? --Gandork 11:21, 11 Dec 2004 (EST)

How function definitions are found.

I'm afraid there is NO official Blizzard documentation whatsoever on these functions, there never was, and there won't be one, for the forseeable future. What you see on these pages is the result of the collective effort of modders, who have figured it out from the following two sources:

• uses of these functions you can see in the Blizzard Lua files
• trial and error

Eventually, over time, this page should be filled in with more info, and ideally we will have a complete documentation on all the functions. But it takes time, as we have no source for it. As for how we get the list of available functions in the first place, have a look at the Global Function List page. It's a combination of opening WoW.exe in Notepad, and having a clever in-game script test what functions exist and what don't. -- Lego 13:36, 11 Dec 2004 (EST)

Since I just posted a page on the tool I've been using to document API functions, I figured I'd say a word here about how I've been approaching this. Firstly by scanning over the extracted UI code, and using the unix 'strings' tool to grab the usage strings from the WoW.exe file, I get a list of the available functions, then after looking at how a function is used in the UI, I also use the /dump command I wrote in the DevTools AddOn to see what values the Function provides, and then do some experimentation to determine how the function behaves and what it's limitations are. -- Flickering 13:30, 27 Dec 2004 (EST)

Proposed format change to API list

So in looking at the API list I've been wondering if we might want to make a slight format change to include the basics argument list fot each function in the list, personally I'd find it easier to read that way, but i'm wondering what other people feel. What i'm suggesting is the following:

Frame:RegisterEvent("event") - Register this Frame's interest in a game event. when a game event occurs.

Frame:RegisterForDrag() - Register a Frame for dragging events

Frame:SetAllPoints("frame") - ??

Frame:SetFrameLevel(level) - ??

Frame:SetID(ID) - Set the ID of a Frame

Frame:SetMaxResize(maxWidth, maxHeight) - Set the maxmimum size of a resizable Frame

Frame:SetMinResize(minWidth, minHeight) - Set the minimum size of a resizable Frame

Frame:SetScale(scale) - Set the size scaling of a Frame relative to its parent.

Frame:UnregisterEvent("event") - Unregister this Frame's interest in a game event.

I feel this would make the API list more of an at-a-glance reference, in addition to just being an index, but I'd like to know what other people feel before making a sweeping change like this.

-- Flickering 12:39, 23 Dec 2004 (EST)

In the absence of any comments about this, I went through and updated the Mapping functions while I filled in the blanks, hopefully the result is something everyone likes!

-- Flickering 17:28, 26 Dec 2004 (EST)

I absolutely like this idea! Simple yet elegant, kind of d'oh, why didn't I think of this. I'm all for it.

-- Lego 19:27, 26 Dec 2004 (EST)

I like your formatting idea. Great idea. Please go ahead and do it.

-- AlexanderYoshi 00:21, 27 Dec 2004 (EST)

It's struck me as I start to do this and while I'm attempting to maintain consistency across API definitions, that method calls need to have more specific names, otherwise we run into issues where multiple objects have the same named method that does different things. I've moved FrameLayout:GetHeight to demonstrate a format I think would work, but as always I'd be interested in feedback. The suggested format is "API ObjectType FunctionName", giving us API FrameLayout GetHeight, which of course is written as FrameLayout:GetHeight() for reference.

-- Flickering 21:23, 6 Jan 2005 (EST)

Split this page into sections?

Since this page is rather huge, maybe it'd be worth splitting it up into sub-pages..

• Data types
• Core functions (Those which are called globally, not on an object)
• Frame Functions (Those which are called on objects)

Should I do this or not? -- Flickering 15:43, 27 Dec 2004 (EST)

We discussed this one a few times. We don't want to split it up because we want to have a master page with a complete list of the functions for developers to look at.

-- AlexanderYoshi 13:49, 28 Dec 2004 (EST)

That makes sense, though it may be a bit overwhelming. On a related note I've been trying to add Category links to the API documents, I started out with just a single "API Functions" category, but I'm now thinking that perhaps subcategories arranged similarly to those on this page would be a better idea, that way we get the subdivided list for free, should someone want it (albeit with fewer frills, but some scripts may be able to fill in those gaps).

-- Flickering 14:10, 28 Dec 2004 (EST)

I made the main page more of a TOC for sub-pages, but created a new World of Warcraft API/All for those who like the master page. Other people are workin on it to make it better (lots of links).

--Fandyllic 10:38 AM PST 18 Jan 2006

Updated for 4150

Widget methods now current as of 4150. Also finally got around to verifying existence of all methods in-game. Reorganized a bit.

How to add new entries?

I've been experimenting with quite a few of the undocumented API calls, and I'd very much like to do some write-ups about them so that others can benefit, but I'm unsure of how to add whole new pages to the document. =) I saw the template page, but I'm afraid that if I edit it I'll be editing the template and just end up screwing everything up. So how do you use the template to create an entirely new page/entry?

Answer: It's pretty straightforward, here's what I do.. I open 2 browser windows (actually 2 tabs since I use mozilla), one is an edit on the template page, I select all from the text box. Then I click on the function in the wow API list I want to create, and paste the template into the empty edit box that comes up. Once that's done I just fill in the data, remove the comments, fix up the category link, preview, and save! -- Flickering 21:06, 18 Jan 2005 (EST)

Widget API Functions

So in the same spirit as the full symbol scan for normal API functions, I scanned all of the viable symbols on all of the defined Frame objects, and derived a widget API hierarchy based on the actual function definitions. It looks a little different than the one here, mostly because there are several 'top-level' entities which define completely different implementations of the basic functions like Show() and Hide().

I've put together a page with the full list on called Widget API.. Check it out and let me know what you all think.

---

Well I had a look, but... to be entirely honest, I don't really see how it's different from what I have added to the WoW API page? Ok so you added some Texture and Fontstring derivatives which I didn't have, but apart from that, I don't really understand the difference.. I also obtained the list here by scanning against existing functions in-game, so how is this different? I see you disagree with the interpretation of what's 'top-level', and I personally don't think that Show and Hide are that different, so that's why I lumped them under LayoutFrame. Which is, in fact, the abstract top-level entity defined in UI.xsd. -- Lego 11:58, 6 Feb 2005 (EST)

---

I wasn't trying to step on any toes, and it wasn't intended as a criticism of the existing WIdget API. I just wanted to make sure tha the derivations matched the code, and then add the object type to the API call name so that we could handle cases where different widget types implement slightly different behaviours for the same method name. As for LayoutFrame, that does indeed seem to be the best approach to those common functions which are implemented differently but which act the same.all of the time, like Show and Hide. -- Flickering 14:02, 6 Feb 2005 (EST)

Place for Important Globals? Purge Old Functions?

Is there a page for important globals like AUCTION_EXPIRED_MAIL_SUBJECT? Also is it OK to purge old functions that don't appear to be in the exe anymore?

--Bug 15:01, 6 Feb 2005 (EST)

There aren't pages for the various global values (yet?) - I do have a pretty comprehensive list as I imagine others do. As for cleanup - which functions do you believe to be expired? I have to admit my focus lately has been more about adding in functions that are not documented here than trying to clean up those that dont exist any more, but it's probably worth asking here about them specifically because sometimes there's a reason to keep them around (the API document includes some that are defined outside of the exe, for example) -- Flickering 16:07, 6 Feb 2005 (EST)

Well there is PickupSendMailCOD(amount), PickupSendMailMoney(amount), AddSendMailCOD(), AddSendMailMoney() and RunMacro(). And should I also unbold the functions I added to the main list in the Global Function List?

--Bug 16:57, 6 Feb 2005 (EST)

With the exception of RunMacro, the others are all referenced in Blizzard's own UI code, but not used. I think in light of that the best idea is to leave them in the page with a note that they do not exist anymore. RunMacro is there but commented out, it may be worth treating it similarly (leave it with a note) but we'll see what the others have to say. As for the Global Function List, that gets updated automatically by a script every so often so you dont need to worry about it. (Oh, and thanks for contributing to the wiki! always nice to see a new name) -- Flickering 17:11, 6 Feb 2005 (EST)

Splitting page (AGAIN)

I know we talked about this in the past and the sentiment was to not split the page at all, but for the sake of maintainability and readability I'd like to reconsider breaking out the Widget API section from the rest. Here are the reasons why I think it's a good idea:

• The page has grown enormously (I've personally added hundreds of API functions) since the last discussion.
• Method calls and base API calls are not interchangable (due to the object requirement for method calls).
• A developer will generally know which type of function they're looking for.

Obviously we'd link to the widget page from this one if we moved it, and both pages would be in the API category. You guys set all this up so you've obviously got the final say, but at least give it a thought again. -- Flickering 16:26, 6 Feb 2005 (EST)

---

Actually, I have had a closer look at what Flickering has done. I must admit that his page is nicer organized than what I had done here. It's more visually appealing, perhaps clearer, and with the LayoutFrame changes actually has the same structure and information content. I also like how all the API links have been converted to object:method form. In summary:

1. I am all for splitting the pages and having a separate Widget API
2. I like what Flickering has done and I say let's go with the way he has set it up

A word of caution! Before you delete the Widget part from this page, let's make sure that all method pages that have already been written get correctly migrated. E.g. API_SetVertexColor -> API_Texture_SetVertexColor -- Lego 19:20, 6 Feb 2005 (EST)

---

Finished moving all API_Function pages (that have already been written) to API_Widget_Function. There is nothing stopping us now from deleting the Widget API section from this page. Lego 19:59, 6 Feb 2005 (EST)

Separation of internal/Lua defined functions

Currently, there are some functions mingled into the list that are actually defined in Blizzard Lua code, e.g. ActionButtonDown, ActionButtonUp. Although these are very useful global functions, some kind of indication is necessary that these are not internal functions. However, I am unsure as to the best way to proceed. We could

• leave the list as it is, and indicate it if a function is Lua defined as opposed to internal, e.g. with a comment
• separate out the two things.

The advantage of letting them mingle is that in that case your average coder can find all references to, for example, Action functions in one place, wether they are internal or Lua defined. The disadvantage is the possible confusion that this can cause, especially if an AddOn replaces some Lua files.

---

My 2 copper.. Right now there's just a select few of these, and they seem to fit very nicely in the sections that contain them. I'm in favor of leaving them in this document as long as they're clearly annotated as non-core functions (i.e. option 1). If it gets out of hand we may just need to add some guidelines concerning whether a function of this type is eligible for the main API list -- Flickering 23:37, 6 Feb 2005 (EST)

---

Perhaps something as simple as adding a character before or after the link itself to show it's a 'script defined function'? Something obvious like § meaning 'Scripted' (using §)? In addition to the in-page comment, of course. So you'd get somthing like:

§ ActionButtonDown(id) - Press the specified blahblahblah...

-- Myrathi 20:19, 22 Mar 2005 (EST)

Issue regarding re-organization/renaming of API functions based on widget...

In Lua,

frame:Func(x,y,z);

Is the same as calling:

Func( frame, x, y, z ); 

Where Func is defined as:

Func = function( self, arg1, arg2, arg3 ) 
   -- Do Something
   return;
end;

If you look carefully and consider, you will realize that this means you can call:

GetWidth(MyFrame); 
AddMessage(MyFrame, "Hiya baby-cakes!"); 

And it will work. They are not truely defined as object functions... a:b() is merely convention for b(a);

I'm not sure renaming the API functions as such really reflects properly on their true nature. -- AlexanderYoshi 01:13, 7 Feb 2005 (EST)

---

I'm afraid Alex you are wrong.

frame:Func(x,y,z);

is actually the same as

frame.Func(frame,x,y,z);

so there are such things as object functions. Since objects in Lua are represented as tables, method calls are the same as accesses to an element of the table. So they are quite different from global functions. You can have a separate global function and several methods of different objects, all of the same name.

For example even in the Blizzard Lua files there is example for this. There is a global GetText funciton, defined in LocaleProperties.lua, which is quite different from the GetText method of several of the widgets.

Lego 09:09, 7 Feb 2005 (EST)

Verified no changes with 4211 or 4216

I re-ran all my symbol dumps for the 4211 build and there dont appear to be any changes as a result of this patch. The only significant changes seem to have been a re-working of some of the emote code in FrameXML. -- Flickering 16:48, 15 Feb 2005 (EST)

Re-verified for 4216 -- Flickering 15:38, 22 Feb 2005 (EST)

I'd just like to note that the EU version may still be on 4211. The person helping me with some translations had to change it back to get it to work. --The Nerd Wonder 16:54, 22 Feb 2005 (EST)

Verified for 4216 in EU as well. The emote related changes happened 1.2.2->1.2.3, which you could've gotten if you haven't updated your interface files between them.

Still more red than blue

Quite a distressing prospect really, after all this effort still more red than blue on this page... Lego 19:55, 26 Feb 2005 (EST)

What a great idea to just create all the pages so that there is no more red. This completely destroys the informative value of red links.
Loriel 09:32, 2 Nov 2005 (EST)

Changes fromo 4216 - 1300

Lots of them, I'll try and get them incorporated today. -- Flickering 16:29, 22 Mar 2005 (EST)

Yeah, I figured there would be. So lucky, you US players have a head start ;-) I will regenerate the list once it hits EU as well. -- Lego 20:06, 22 Mar 2005 (EST)

I have updated the Global List for 1300. Anyone care to verify? -- Lego 13:23, 25 Mar 2005 (EST)

I'll look over it soonish. -- Flickering 20:02, 28 Mar 2005 (EST)

Normalization of API document Format

I've been toying with a plan to go through all of the API documents and make them actually match the function template (Actually, a slightly cleaner template, but basically the same thing). I have a few reasons for wanting to do this, the largest are:

• I want to be able to build the main page from the individual API pages, by grabbing signatures and summaries.
• I'd like to be able to build a stand-alone HTML cross reference for those days when the wiki is down.
• It makes formatting changes easier when things are consistent beforehand.
• Coming up with a process to do this (and verify it) means I can keep new contributions consistent.
• It allows for better tracking of incomplete documentation.
• I can produce 'skeleton' documentation for a great number of the existing undocumented functions if I had better automation.

I spent a bit of time on this over the weekend, and have a process which works for the better behaved entries.

• There's an XSD for an XML representation of an API document.
• There's a script which parses an API wiki page and creates a best guess at the XML representation.
• There's an XSL stylesheet which converts the XML representation back to a standard Wiki format.

If the wiki page makes it through the parsing script without isssues, then the result is a nice consistently formatted page. It's kinda cool when it happens right for one of the larger documents. Anyway, i'm still working on it all offline, but once I have a good degree of confidence about the process I'll start (by hand) converting some of the API documents and you can all chime in on the result.

-- Flickering 20:14, 28 Mar 2005 (EST)

Recategorized

I've gone through and cleaned up the categorization. Most of the old categories have only gained functions, and I'm sure there are some which could do with attention. I also cleaned up places where the same function was listed with different text, and I've clearly marked UI and REMOVED functions. These have their own sections as well, for reference. The only links which I removed were those which should have been on the WidgetAPI.. Hopefully that didn't strand any good documentation in limbo, I guess we'll find out.. I do have a copy of the old version (and checked the two before committing to avoid any unexpected problems). -- Flickering 19:32, 17 Jul 2005 (EDT)

Dressing Room API

I went ahead and added the functions from DressUpFrame.lua. I also adding the description for DressUpItemLink since I was able to confirm it's usage (modified LootLink so I could ctrl-click from it :) ) If it doesn't belong there, or I did something wrong please let me know and I'll correct it. I wasn't sure how previous "patch days" went...

Please revert the layout

Please revert the API page to the way it was before, if you want to make a new sectioned page then by all means do so, but THIS page should be ALL of the core API functions. There doesn't appear to have been much discussion on doing this change before it happened, and, well, it's horrible. -- Flickering 21:49, 18 Jan 2006 (EST)

Revert how far back, you mean? Before I added the group names to what Fandyllic did? Or before what Fandyllic did? I, as well as Fandyllic, think that was horrible (before Fandyllic's change), and now it's more manageable. At least I added the listing of groups so that you can see what you're doing. If you like the old layout, it isn't hard to get to it. It's at World of Warcraft API/All. You can use that. Sure it may not be the best change, but it beats the old layout and the enormity of that page (120 kB).

How about using templates, or calling the sub pages as template pages. It wouldn't be that hard to set up.

As for Gello, he (assuming) said on Talk:World of Warcraft API/All that the flatness of the old format was great because you could search for a specific function and there it is. Well, for one, you could just go to API SpecificFunctionYouWant and there you go. But if that's not enough, how about listing them alpha rather than grouping them–but for this having a separate page–so you don't even have to bother so much as to press ctrl-F. Schmidt 22:38, 18 Jan 2006 (EST)

Revert as far back as before Fandyllic's changes, I suspect you'll find the dissenters of the old format are a MINORITY of the users of the page. I have no problem with ANOTHER page that categorizes the functions differently, but THIS page was a flat list of API functions, so we could find it all in one place. -- Flickering 15:01, 19 Jan 2006 (EST)

I am in favour of reverting the page to one flat list as well. Those of us who do actually use this page regularly, got most utility out of it by having one big flat list, so you could ctrl+F. == Lego 15:12, 19 Jan 2006 (EST)

If you guys want to use the OLD layout, then just click the link to World of Warcraft API/All.. it is the same thing! There is no need to revert the page when the old version still exists. --Anticrash 15:26, 19 Jan 2006 (EST)

We have documents, bookmarks, forum postings, and memory, all around THIS page, there's no reason why THIS page had to change - a brave new format should have been created as an ALTERNATE PAGE, and this one left alone. I fear that this is a problem where the "non-UI community" users of the wiki have crossed over into the area that's used by the UI community without a good historical understanding of why things are the way they are. We were already here using this page, if others want a World of Warcraft API/Subdivided, then by all means make one, but dont make us move OUR links to suit that. We dont have a problem with someone trying to add value by a more browsable page (Assuming they're going to take the burden to keep them in sync), we DO have a problem with making changes to our reference source, without consultation or understanding. -- Flickering 15:46, 19 Jan 2006 (EST)

I for one see no reason for the change, as apparently many others do as well. No one is going to want to update two pages when something changes in the API, regardless of the difficulty (or ease). This coupled with the fact that most users (yes I said most) tend to look for functions using search in their browser, kind of supercedes the "don't want to scroll" argument that was used for the change in the first place. Please change it back, as this goes against what most of us feel makes this site usable and friendly. I for one refuse to update the alpha list --Beladona 15:27, 19 Jan 2006 (EST)

If you guys need it reverted so badly I don't see why you are relying on someone else to revert it for you.. --Anticrash 15:54, 19 Jan 2006 (EST)

Protocol -- We dont want to get into an edit war with the other community folks, while we're not happy with their changes, I have complete faith that their intent was sound and good, and I'd rather reach agreement with them over the format it remains (and have them undo their own changes) than act unilaterally to force an issue. -- Flickering 17:03, 19 Jan 2006 (EST)

As long as there is an open vein of communication, there shouldn't be any issues with users conflicting over a change. As long as you have a valid reason and state that reason in the edit summary, feel free to make any edits you feel necessary. In this case, several users were simply asking for a revert without giving a practical reason to do so, but through the discussion that's taken place above, we can see how the revert is justified. --Anticrash 10:28, 20 Jan 2006 (EST)