GUI's
 

I think us newbie coders have the hardest time with one thing: Starting out.
I know I learn best if I have something to learn from, and I think It'd be awesome if someone took the time to make a simple AddOn that like.. has a small movable frame with a button on that maybe, minimizes/maximizes it.

I found a mod that was just a moveable window and I'm messing around with it, but Its hard to get a button to work if every time I make a code change it crashes wow when I click it :p

Heh, ain't that the truth? ;)

The problem is making something that is advanced enough for intermediate coders to find useful, but simple enough for newbie coders to understand. The fact of the matter is, the best source for either is still just the base WOW UI files, so it really is best to just start there.

What we need is better documentation. WOW Wiki, while useful in many ways, is only as good as the people updating it. We need someone dedicated enough to document all event, api methods, global variables and strings, and other things that many of us have had to find on our own without due documentation.

I may tackle this at a later date, but it would take a lot of work, info gathering, and constant updating, none of which I have time for at this point...

One thing I am currently trying to do is create a lua / wow xml editing plugin for Dreamweaver. I use Dreamweaver for a lot of code writing, and have managed to get successful syntax highlighting with lua, but am still trying to package it into something everyone can use (with code hints)

If you do, you'll make a lot of newbie coders very happy. :)

The syntax checkers and stuff that reads blizzard's UI.xsd are nice but to those starting out it's like handing a book on Swahili grammar to someone who's never spoken a word of Swahili before.

A good approach to teaching the WoW UI would be a documented step-by-step building of a mod from something simple to complex. Once the relationship between the syntax and semantics falls into place by example, all of the wowwiki suddenly makes sense.

I find that building a mod happens in stages which anyone who's done any programming is familiar with:

1. Write out the intent of the mod, with a bunch of ideas that may or may not be doable: We want a mod to keep track of looted items. We want the items to be clickable links, to show who looted what and when. We want to make the results show in a scrollable window.
2. Draw a mock-up of the GUI in paint shop or any graphics program: Define which columns we want in the list, we want a reset button, where will settings go? If there's a ton of options it's best in a separate window. For a couple settings they can go on the main window.
3. Lay a workable foundation in the lua: Create a mod that saves looted items into an internal table. Make a temporary slash command to spit back the results.
4. Lay down the xml elements one layer at a time: Options and altering the elements can wait, we can keep those defined in the lua for now. Create the list, add the scrollbar, reference the interface.mpq to grab textures, reference the FrameXML lua's to see what we're actually inheriting for our controls.
5. Mesh the two together: Make the xml elements react to the lua and vice versa. Plugging in the scrollbar to our internal table, adding the code to react on a push of the reset button, etc.

Most can do 1-3 fine but get stuck on #4. A tutorial to lay some foundation of the elements would be an invaluable document. Once I get recap and hitlist settled I'll see about writing one up. The information seems overwhelming but once you get the basics down the work is 40% design, 20% looking stuff up in the wiki, 10% actually coding it (and 10% debugging hehe).

And what you are talking about will make them even happier! Please do!










Time to reveal a well hidden (or maybe not so well hidden) secret.

I can make neither heads 'nor tails of the coding involved in WoW's interface. I open up any file to try to figure out how someone has done something, and I'm just totally and completely lost.

I don't consider myself a particularily stupid person, but the coding here is sure making me feel stupid. I just can not get my head around it, no matter how many times I try. I try to read the "tutorials" that people have done, and it's just complete information overload. It's exactly like you said, it's like I'm trying to read Swahili. And it's frustrating beyond words.

When I look at the fact that I knew nothing about coding, or about graphics manipulation (alpha channel, what's that?) when I first started out with UI modding back in EQ, and then look at what I was able to do by the end ... one would think that I should be able to do this without any problem. But I just can't. It confuses the hell out of me.

I really desperately need someone who is willing to sit down, take the time and explain it to me, to show me that if you do X, it causes Y. I mean, the simpliest of things. How do I hide the gryphons on the ends of the bar? Should be simple, right? I can't manage to thread my way through the code enough to figure out where they are defined, where they are called and sized, and thus how to turn them off.

It's not like I even want to make major functional changes or anything. I'm all about re-arranging things on the screen and substituting graphics, giving it a new "look". There was so much beautiful work done graphically back in EQ. I want to carry it over here. But ... I.can.not.figure.it.out. :(

People have asked me when they are going to see my Ancient Celts ported over. Or any of the T.King stuff (since I have permission to work with his graphics). Well, here's why they aren't around. :(

There, shameful secret out.

Oh I've been wanting a tking interface for WoW for some time.

It is possible to edit the artwork the UI uses without writing an addon. It would be the equivalent of only editing the windowpieces01-etc.tga files in EQ1.

The WoW version of "uifiles\default" is interface.mpq. You can unpack that and then edit files and put them into the Interfaces folder for the UI to use instead of the default.

For instance, to change any of the default artwork:
1. Use this tool from Blizzard: http://www.blizzard.com/support/wow/?id=aww01669p to extract all the artwork. (Definitely suggest backing up/renaming your current Interfaces directory as this will fill your current Interface directory with an unpacked "Interfaces" folder-- there are a bazillion files)
2. Then go to http://www.cosmosui.org/vjeux/ and grab three utilities: BLP2 Viewer, BLP2 to TGA and TGA to BLP2
3. Using the BLP2 Viewer, browse the interface.mpq for the artwork you want to change:


4. Once found, go to the path in your Interface folder created from step 1. The artwork will be there with a .BLP extension
5. Convert the blp to tga with the util from step 2.
6. Edit the artwork in any graphics program that can save in 32-bit tga (or 24-bit color + alpha)

(God bless alpha channel. No need to stay in the lines!)

7. Convert the tga to blp with the util from step 2.
8. Put the edited file into it's proper place in the Interface folder and now WoW will use your artwork instead:


You can zip the single file to exist on its own, much like a uifiles\mycustomart in EQ1 could have simply a windowpieces01.tga and it would use the default for everything else.

Obviously tking's stuff had a lot more involved, like button placement and stuff. I wouldn't suggest any mod touch any of the FrameXML stuff unless it's for your own personal use (and even then the Glue stuff is off limits).

But a mod that creates a new visual look can definitely be done with artwork alone.

Aye, I've already got all the graphics downloaded, unpacked and converted. And I know that I could just replace them with my own, I've already done it. The problem lies in where/how do I define ones that are not the same size/shape/location as the originals? without editting the FrameXML files? And defining where they are placed on the screen, ie rearrangement. That's where the need to understand the coding comes in, and that's where I get lost. =/

I'm not sure if this is practical for all parts of the UI, but if you just want to change placement/sizes of stuff (sort of the limit to what EQ1 interfaces could do), you can have a mod actively move stuff around once the user's loaded:

MyMod.toc
## Interface: 1300
## Title: MyMod
MyMod.xml

MyMod.xml
<Ui xmlns="http://www.blizzard.com/wow/ui/">
<Script file="MyMod.lua"/>
<Frame name="MyModFrame">
<Scripts>
<OnLoad>
MyMod_OnLoad();
</OnLoad>
<OnEvent>
MyMod_OnEvent();
</OnEvent>
</Scripts>
</Frame>
</Ui>

MyMod.lua
function MyMod_OnLoad()
this:RegisterEvent("PLAYER_ENTERING_WORLD");
end

function MyMod_OnEvent()
MiniMapTrackingFrame:ClearAllPoints(); -- objects can have several anchors. before moving it's often best to clear the anchors
MiniMapTrackingFrame:SetPoint("BOTTOMLEFT","Minimap","BOTTOMLEFT",-15,0) -- moves x,y to -15, 0 relative to the bottomleft of the minimap
MiniMapTrackingFrame:SetWidth(100);
MiniMapTrackingFrame:TexCoords(.2,.5,0,1); -- change what part of the texture to use
etc
-- go through and change the placement and position of all items that need changed
end

Since you know xml from working with eq1 interfaces, you could probably identify what bits are what in the FrameXML files, and then alter their position/size programmatically. The widget API at http://www.wowwiki.com/Widget_API will be your main reference to how to move/shape elements.

It's kinda cludgy but it'd work. Otherwise to make a custom minimap would require rewriting a minimap window. You can inherit elements and hook functions to an amazing degree in the WoW UI, but you can't alter the original's xml without sticking it in FrameXML which is bad.

But for some parts (like the tking casting globe) it'd be worthwhile to write an addon in itself.

For the first time, that almost sorta made sense to me. Thank you.

Okay, example ... I want to make a new casting gauge. I would create it (the image) in PS. It gets defined in which file? ie the telling it to go find the casting gauge image in "this" .tga or .blp file, at "this" (x,y) starting location of the graphics file, and it is "this" long and "this" wide (cx, cy)? The MyMod.lua?

Then, next step, I want to tell the game to use my casting gauge, not the default one. Which file do I work with to tell it to hide the default, and to use mine instead, and to put mine at "this" location on the screen? Again, I know that we don't want to actually touch the default FrameXML files, so I need some way of telling it to hide them and load mine. I take it that the MyMod.xml (that whole "onload" bit) is the file tells it to load up my graphics file?

Or have I just gotten myself all confused again?

And, isn't this going to make it incredibly slow on loading, if it has to load all the original graphics, then hide them and load mine? That could really suck ...

/edit And you have to admit, the xml being used in WoW's interface is a damn sight more ... confusing (advanced) ... than what was being used back in EQ1.

Okay, backing up a step here.

The MyMod.xml file is:
- the one that tells it to load my graphics file, correct?

The MyMod.lua is:
- the one that defines where it is located in the image file (starting point, length, width) MiniMapTrackingFrame:SetWidth(100);
MiniMapTrackingFrame:TexCoords(.2,.5,0,1); -- change what part of the texture to use
and:
- where it is located relative to ... itself? (MiniMapTrackingFrame:SetPoint("BOTTOMLEFT","Minimap","BOTTOMLEFT",-15,0) -- moves x,y to -15, 0 relative to the bottomleft of the minimap)

Where am I defining where it shows up on the screen? Back in EQ1, it was the .ini file. Layout-cache.txt?

And where am I telling it to hide the defaults?

you are trying to think of it in terms of the way EQ handles UI structure. There you can have multiple elements in a single art file, and you must tell it the rect points within that file to locate the image you need. WoW however uses a single image file for most if not all elements. The size of your image is what it goes by, and you can define a separate size (that is scales to) within the XML or LUA.

Much of what you want to do requires some more basic knowledge to get into. If you would like, I would be willing to answer questions or help you in learning more. I haven't released any mods (mainly because I tend to keep my stuff in perpetual beta with constant changes, and never feel good enough about releasing it) but I know quite a bit about lua and xml. Let me know if you want my MSN, AIM, or whatever, and I can give you pointers.

on a side note, my syntax highlighting is done for dreamweaver. The problem is, it requires manual editing of configuration files to get it working. I am now looking for a way to package it into a dreamweaver extension.

P.S. You CAN define images, and even swap some images within lua code. However it is best to stay away from modifying stock ui artwork, especially via lua SetTexture functions. These don't always work right, and can be a pain in the butt to keep stable (no crashes). It is actually better to hide, disable, or replace the functionality of something in the default ui, with a custom element of your own, using your own artwork. More on this later.

Okay, but, that doesn't completely make sense. Using the main menu bar as my example:



There are four sections there. You can't just tell the program to load that file, you have to tell it where each section starts, the length and width of it, and where it goes in relation to the rest of the sections ... right?

/edit And I would by far rather create all new graphics and the appropriate files to support them, then tell the game to ignore the defaults and use my stuff instead, as that would mean being able to stay away from the FrameXML files ( Bad Idea(tm) ). Even if I were to use some of the existing graphics, I'd rather re-define where and how it is used, same reasoning.

As I said ... the programing in WoW's UI is making me feel incredibly stupid. Swahili. =/

My apologies, you are right. I was thinking too narrowly of textures used in widgets like buttons, but textures can be used in layers as art and can accept texture coordinates within a file (thereby getting multiple images from a single file)
Just like in EQ, you have to know the tga dimensions, the actual image topleft point (x,y), the image width, and the image height. You then do simple math to fill in the coordinates.

example:
you have an image file that is 256x256, and you want to use an element in that image that is 256x50 located at point 0, 100.

left = 0/256 = 0.0
right = 256/256 = 1.0
top = 100/256 = 0.390625
bottom = 150/256 = 0.5859375

Your final code would be
Put that within a layer or something similar within a frame, and it should do what you are talking about.

I apologize if you already figured this out. Just trying to share...

As for the Swahili thing - yeah, Lua is a bit weird. The XML Conventions are easy enough to grasp, but lua is very "open" in terms of requirements. I have developed techniques that I use in coding that helps make it a little more "understandable" by wrapping all of my code within variables and accessing them like objects in an OO language. Like mymod.myfunction(); -- doing that seems to help me at least in understanding the structure of how I have things layed out. The next thing to make sure of (at least I do) is that all my coding is consistent in everything I do. That way when you look at one script, and look at another, you can easily pick it up because well, they are structured the same way. I use naming conventions for everything within my little object oriented tables...

Two approaches:

1. Create a new casting bar from scratch used in place of the game's default (pretty complex)
2. Modify the default casting bar to use your own graphics (MUCH simpler but prey to the textures being named and unique)

Method 1
1. You draw up the artwork and save them in blp format or tga. (As an aside, images need to be a power of 2 along each edge. ie: 64x64,128x128,256x128,etc)
2. You create an XML that defines placement of the elements you intend to use:

For instance, say you have the venerable arcanegauge.tga that looks like:



The file is 128 pixels wide and 256 pixels tall.
The "border" image goes from 0,0->120,92
The "guage" image goes from 0,95->43,139

The location of the textures within the file are referenced as a percent of the total:
Border left=0, right=0.9375, top=0, bottom=0.359375
Guage left=0, right=0.33594, top=0.3711, bottom=.54297

We want the guage drawn at 37,30 within the border (decal offset I think it was in eq)

Not to put it in the xml. In a typical XML, the file is laid out like:

(warning: I'm not testing any of this as I type. I'll try to later tonight when I have time)

You can have layers within frames and frames within layers, and almost everything is optional. But for this example let's say we want to just having a casting bar texture that changes without user input. imho it's best as a Layer but you could put it in Frames too:

Things to note:
- The .tga is dropped from arcangauge. You can use either .tga or .blp in your addons. It loads these files at startup and caches them. I typically use .blp since they're compressed and a malformed tga will crash WoW.
- We have two layers. ARTWORK will go below OVERLAY.
- We have no controls (buttons, etc) that want mouse clicks, so we don't have a <Frames> section at all
- Both textures use the same file but with different TexCoords to point to their important part
- The decal offset is done by defining an <Offset> relative to MyCastingBorder
- There is a <Size> and <Anchors> for the main frame, the casting border and the guage.

That's the basic xml bit. To get it to work, in the lua you hook the default casting functions and then use your casting bar instead. Actually programming it to react would be the hard part, and you will be in essence recreating the casting bar from scratch. Feel free to skip over parts that don't make sense, and skip down to Method #2 if you want.

Two ways to get it to use yours instead of the default:

1. Simple but unreliable way is to hide the default one from within yours: CastingBarFrame:Hide() at a good time (or every update on yours) will hide the other one.

2. More elegant but complex way is to replace the original entirely. In Interface\FrameXML\CastingBarFrame.lua are three functions:

function CastingBarFrame_OnLoad()
function CastingBarFrame_OnEvent()
function CastingBarFrame_OnUpdate()

You would need to create your own CastingBarFrame_OnEvent() and _OnUpdate() to use your work. To get the UI to use your versions, you would hook those functions. In MyMod.lua in the OnLoad():

The above is an "impolite" way to hook a function. Often an in-game function has a lot involved that may not have any relation to your mod. So use with care. A more polite way of hooking the function is by keeping the old one around to use if need be:

Now you can toggle User_Wants_Default so that it will use either yours or the default.

As you can see it can get complex very fast. My mods that override the UI's default function (Auto Inner Fire, BestBuff) are very simple in what they do.

Method 2

This is the route I was going with in the above post: Let the UI handle all the programming bits, just change the artwork and if need be change the position/size for the new artwork.

Because we're not laying down our own XML, but using the game's default XML, our MyMod will remain very simple:

Now we go see what textures the game is using by default:

In CastingBarFrame.xml we find:

<Texture file="Interface\CastingBar\UI-CastingBar-Border">
<Texture file="Interface\CastingBar\UI-CastingBar-Flash" alphaMode="ADD">
<Texture name="CastingBarSpark" file="Interface\CastingBar\UI-CastingBar-Spark" alphaMode="ADD">
<BarTexture file="Interface\TargetingFrame\UI-StatusBar"/>

Two things make this method unusable for the casting frame:
1. The elements we want to change aren't named. (only spark is named with name="CastingBarSpark")
2. It's using an element used elsewhere in the UI. So any change to this would affect the whole UI (which may be desirable if we're not changing the size/shape of the texture)

So we're going to pretend these are each named and the UI-Statusbar has a castingbar version (tons of parts of the UIs name every element, so this is just an example):
<Texture name="CastingBarBorder" file="Interface\CastingBar\UI-CastingBar-Border">
<Texture file="Interface\CastingBar\UI-CastingBar-Flash" alphaMode="ADD">
<Texture name="CastingBarSpark" file="Interface\CastingBar\UI-CastingBar-Spark" alphaMode="ADD">
<BarTexture name="CastingBarStatus" file="Interface\CastingBar\UI-StatusBar"/>

1. First, create a directory called Interface\CastingBar
3. Convert arcaneguage.tga to .blp
4. Copy the blp to CastingBar directory and rename it to UI-CastingBar-Border.blp
5. Copy the blp to CastingBar directory and rename it to UI-StatusBar.blp

Now, the game would use what was arcaneguage.tga for both the border and status bars. You could do this with the casting bar also but without a name to reference we can't change sizes/offsets/etc.

6. Edit MyMod.lua to look like:

If the border and status textures were explicitly named, that's all you'd need to do to replace the default border and guage with a custom one.

Sadly it's not the case so the first method is probably better. I don't know how to enumerate frames in xml but if that's possible then you could enumerate through to get the texture id's and then manipulate them.

Sorry, I should've picked a far simpler example than the casting bar. But that hopefully points you in the right direction.

No, I hadn't figured this out yet, this is where you're starting to lose me big time. Why wouldn't I just say:

That's the way I'm used to seeing it. It starts here, it's this long, it's this wide.

/edit Just read Gello's ... yup, definitely completely lost again now. :(

lol, KABLUI!

Good work on the tutorial though. I didn't want to type that much, so I am glad someone else did :p

That is just the way that WoW does texture coordinates, and in truth it is the correct way. The method you mentioned doesn't allow scaling like WoW does. The texture coordinates and eprcentages allow the UI to scale the image at will without destroying the layout of the textures.

It may seem advanced, but once you figure out how to do it, trust me, it gets easier. Texture Coordinates are really the way to go in the end anyway, as most modern gaming design uses it, expecially for texture to model mapping procedures...

EQ UI is a bit strange in my opinion now that I am used to the way WoW does it. WoW just feels more "feature rich" so to speak. You can really do more with it than the EQUI would ever allow...

Oh, I know that (about it's the "proper" way to do it, and that it's more capable, and that it's what they are all going to be going to). That's where the discouragement comes from, though. I'm right back to "hook wha inherit huh where'd that number come from why is that shown that way omg too many brackets and partial brackets and oh forget it I'm too damn stupid to figure this out, leave it to those that can" :(

If memory serves, this is making 'topleftcorner' be the top left quarter of corners.tga. The WoW equivalent is:

The size of the whole texture and the pixel position of the texture within are never used anywhere.

When you see <Anchors>, those are always the position of the frame/control/texture/string in relationship to everything else.

When you see <Size> they never define how much of a texture to draw, it will stretch the whole file to that size. (Or a subset of that file if you define TexCoords)

What are some other UI elements you want to replace? Some may be easy to do without hooking or doing anything.

If it's any reassurance, I had no real programming experience when I recieved my WoW beta. I've been a web designer for years, and have used PHP for relatively basic things, but I had no training or technical experience with which to decipher the then totally undocumented WoW UI. Patience and experimentation are key:)

I finished the Dreamweaver Extension. I was thinking about submitting it for download here, if you think that would be appropriate Cairenn? It isn't an AddOn for WoW as much as it is a tool for budding developers to get syntax highlighting for LUA in Dreamweaver. This extension is for Dreamweaver MX+ (MX and MX 2004)

It does proper code coloring for LUA basic functions, as well as WOW API (Widget and GLobal).

Known Issues --------------------
Code Hints are not currently active. The next release will have this. Main reason is that I want it to work properly with both LUA, and LUA inside of XML. This will take some experimenting / perfecting on my part before releasing it.

Comments that use the format --[[ comment ]]-- are not currently being colored as a comment. This is because the Dreamweaver format for defining comments in the code coloring definitions uses CDATA. Those that know, <![CDATA[]]--]]> is not valid markup, so therefore I cannot define the closing brace for this type of comment. If anyone knows a way to get it to work, let me know! Regular -- comments will work as intended however.

LUA code inside of XML is not color coded. I am still playing with getting LUA code coloring side of regular xml files. This will hopefully be in the next version.

http://0ctavius.com/site/download.php?id=2

Unfortunately I don't see a category that I could upload it to on this site, so I guess I will have to host it on my own site above, unless we can somehow get a Tools Category or something...

If you are willing to release your source code for us to check, we're always more than willing to host things that are of benefit to the modding community. We have a "general" policy against .exe .vbs, etc in regular mods, but even there, if the author is willing to provide us with their code, we will consider making exceptions to the general rule. Something like this, there is no question of whether we'd allow it, given the stipulation about letting us check your code.

It isn't that we figure most folks would do anything malicious, but the unfortunate reality is that some do. That's why the "general" policy is in place. It's protection for the users of the site, protection for you the mod authors, as we can prove beyond doubt that any thing that goes wrong (virus, key logger, even something like undocumented "easter eggs") with someone computer is not the fault of your mod, and it's protection for ourselves, same idea.

And the other reality is that most end-users see a .exe and almost auto-assume that there is going to be a virus or some such and just refuse to use it (which is actually the better choice in most cases). We like to be able to definitely verify for ourselves that anything available from our sites are "clean", and folks know that from having used our sister sites for years, so folks trust that anything coming from here is clean.

Trust you can understand that. :)

Having a "Developers' Tools" section is something we've considered before, there just hasn't been a call for it on our site as of yet. We certainly have no objection to adding one. :)

(And yeah, obviously it won't be me checking the code. ;))

/edit I also want to, personally, say thank you to all of you for the time you are taking to try to help me get my head around this stuff. It is appreciated, I am still reading it, I just have some other things at the moment that are taking up my time and attention (sick daughter, to be exact), so I'm not actually able to start trying to work my way through the info you are providing. I just wanted to add that, so you knew that my lack of responses to the thread all of a sudden wasn't lack of interest or some such. I just don't have the time right now to try practical application. I'll definitely start spamming you guys again though, when I do.

It isn't an exe, but it does auto-run on clicking of the mxp, so I see your points. Virus spread because people aren't careful of what they click on...

Anyway, I have uploaded a new verison of the zip with a directory called "source" which is a complete snapshot of what the MXP file contains. The file structure of the zip is below, and the files therein are the oens that are used to define the code structures.

[LuaScript.zip]
LuaScript.mxp
readme.txt
source/default.lua
source/LuaColoring.xml
source/LuaColors.xml
source/LuaDocumentType.xml
source/LuaScript.mxi

Hope this helps! I also took the liberty of adding the code changes as they have been reported in the upcoming patch. So this syntax highlighting plugin is up to date with 1.5.0 (unless they sneak in some more last minute functions and stuff that I don't know about yet)

http://0ctavius.com/site/download.php?id=2

To quote the person who would be checking the code:

and
So, greenlighted, aaannnnddd ... TaDa! :)

YAY! I think I love you! I will update this thread with more info once I can get it uploaded.

I am having some kind of issue though, as I cannot upload to that category. There isn't a button to upload like there is in the other categories... Will upload as soon as that becomes available...

Crud, I'm sorry, I was trying to get the forum available and your app cleared in a rush while waiting for my daughter to get dressed so I could take her to the hospital. Just got back in now and saw this. In my hurry I had a permission set incorrectly. You should be able to upload with no problem now. Sorry about that. =/

no problem. I uploaded it, awaiting approval. Support thread is here:
http://www.wowinterface.com/forums/showthread.php?t=801

One thing I noticed however, I cannot upload updates to the file, or edit it. I do plan to release updated version of it soon that includes code hints, and lua within xml support, so that feature would be useful...

Sorry, I stumbled onto this thread a bit late I'm afraid.

This quote piqued my interest:
I'm a little like Carienne. Working with lua in a WoW AddOn is a bit like me trying to explain to you how to reapair your car's engine, in French. I don't speak the language, and I'm pretty fuzzy on the mechanics anyway. :p

Beladona, could you elaborate at all on what the pitfalls might be associated with utilizing the SetTexture function in an AddOn? As I said, me no speaka da lua so good, but that -seeemed- from my limited knowledge to be a fairly slick little function, depending on the application.

What am I missing?

/sigh, I'm sorry, I have been so distracted with the stuff about my daughter. Anyway, it's fixed, you should be able to now. I'm not usually such a ditz, honest!

*feels like a complete dope*

sure thing! the SetTexture("texturepath"); function is pretty useful, in that you can change the texture associated with a texture object at will. This is most notable seen in modifications that allow toggle buttons. When you hit the button, and thereby "toggle" it on, or off, the texture can be set to change based on what that value is. I don't have time to go into the specifics right now, but I might be willing to start some discussion threads on it regarding the uses of it.

Basically if you have a texture called "MyTexture" you would do this:

MyTexture:SetTexture("Interface\\AddOns\\myAddon\\mytexture01.tga"); (as someone mentioned earlier, you can leave out the .tga here, as the engine sees the graphics file without the trailing file type, however I prefer to use the extension, for practicality sake, as well as the fact I have seen it not work a couple times...)

With some coding, you could do something like this:

You can also use
MyTexture:SetTexCoord(minX, maxX, minY, maxY); so for people like Cairenn who was discussing having a single file with multiple elements, you can leave the texture as is, and just change the Texture Coordinates...

Aha!

I read the above quote as you saying that you avoided modifying the default textures, partidularly by way of using the SetTexture function. Basically, the complete opposite of what you had actually said. ;)

Nevermind me, and thank you for the clarification. :)



While we're at it, would you mind tossing in an event (properly scripted) for the above (myToggle) to fire from. Say for example, I wanted to alter the target frame on gaining a particular target, a mob vs. a player, friendly vs. hostile, or something to that effect.

I think I'm seeing a glimmer of clarity peeking through here, I want to keep the irons in the fire while the fire is hot, if you don't mind indulging me. :cool:

edit: I think you may have done this already earlier in the thread. I'm going back now to read back through, and see if I can't sort that out. Sorry bout that. :)


(PS: Your TextCoord explanation earlier in this thread was golden. I come from DAoC, which I believe was similar to EQ in terms of UI modification scope. TextCoor's had me totally bamboozled. Not any longer! I will have to play around with that more. Thank you!)

OK, in an effort to get around the pesky un-named texture dilemma, I decided to pursue the earlier castbar example.

Sorry for the eyesores, but here is the code of my reconstruction of the castbar:

Lua:
XML:
Tha's basically the complete Blizz Casting Bar code, with a few elements renamed to include the "DS_" prefix.

Within an AddOn, the above perfectly duplicates the casting bar. However, I can't get the vestiges of the old one to dissappear. It no longer functions, it just sits there, full, with not text, and no "flash" animations, and the "spark" just hanging out dead center. It does still exhibit the behavior of only being present while casting, however. I noted what I tried in the onload function of the lua to get it to hide, but niether of those worked.

Oddly enough, the original casting bar would hide and remain hidden using MoveAnything!, but once I reset the MoveAnything! frame, it went back to ghosting my new casting bar.

Here's an image of what I get. Note the functioning "flash" in the inset:
(don't laugh at the graphics, I just tossed those together quick) ;) :

http://img.photobucket.com/albums/v5...stbarsnafu.jpg

So... What am I missing? I'm not dying to change the castbar graphics, insomuch as I am dying to find out what I am doing wrong. :p

try moving CastingBarFrame:Hide(); to your OnUpdate function. It will get fired quite often, and whenever your new casting bar gets updated, so no matter what your old castingbar is doing it will get hidden (or should)

I may try to play with it later. The image you have below? Is that a custom menubar you made, alone with the other graphics? Or is it a mod that already exists? It looks interesting...

EDIT: Scratch that, I looked up your released AddOns and saw it, so disregard =P

Bingo!

Thank you Beladona. plopping the hide in the update function, like so, did the trick:

Wheeeeee!

Fiddled some more, using all of the tips put forth in this thread, and wrangled the MiniMap around.

Here's a shot of my "new" MiniMap,
toggled open and closed:


Hovering over the Dragon's head gives you
zone info in the tooltip ...
(this was an "accidental" feature I ran with):


Here's a shot with Tracking/Mail/etc.
notification icons displayed:




Sorry, trivial I know, but I just wanted to thank you Beladona and everyone else for taking the time to hand-hold some of us newer folks. I know I for one, really appreciate it.

I still have a few issues with what I did, namely, getting the original map to hide (again), and getting my map to play nice with other AddOns that want to play with the minimap. I also have my suspicions that the ping, while functioning on my map, may not work right for other people in my group as intended. Time to go outside though now. Challenges for another day. :-)




PS: Images include use of smilies, the vB code [img] tag and HTML <img> tags. The use of these is all subject to them being enabled by the administrator. ... I take the limit is four? No emoticons for me! ;-)

Diiver, that looks fantastic! Don't even think about apologizing for it being "trivial", it most assuredly isn't.

This is the other side of UI modding that many folks are still searching for, the graphical changes. A UI can look completely different, just by changing graphics, yet still actually be exactly the same, layout and functionality-wise. I, for one, am very glad to see folks beginning to get into the graphical modding of the UI. That's the area I work with by preference (if I can ever get my head around it all). Now that (more) folks are actually using this area of the forums, (and so far, everyone is being incredibly patient in trying to help others, as we always hope for and expect on our forums), I expect we'll see more and more of this type of modding. It's going to be fun! :)

(PS, I'll look into the whole smilie thing.)

Good work! I love seeing people take the initiative to design original changes to the ui. No Change is a useless change, as there is always someone that finds it useful or fun.

I enjoy providing what little I know about LUA, XML, and WoW AddOns to anyone that needs or wants my advice. I kind of get pleasure out of helping people in even small ways. So feel free to bounce ideas or questions off me at any time, as that is what I am here for...

MuahahahaHAHAHAhahaha. . . A VICTIM! :D

Just kidding, you rock Bel. ;)




OK, in an effort to remedy a problem I'll detail later, I expanded (experimented?) on your earlier "impolite" way to alter my lua. I now have the following for an <OnLoad>:

That's every function in the lua, but as a note, adding in the "Minimap_OnLoad = DS_MinimapOnLoad" was the kicker to get the "Minimapcluster:Hide();" to do what it was supposed to. (finally). This is a good thing, as when I "/script MinimapCluster:Show();" in-game to compare the way the two are behaving, I get a nasty windows error related to the POI's i think when I try to hover over the town pointer widgets that circle the outer border (you know, the little silver arrows on the outer rim that tell you [Ogrimmar] or whatever is that way, when you are out in the boonies, nearing a town). With the primary Minimap hidden, this doesn't seem to be an issue.

OK, by now, about 95% of the "DS" minimap has been converted to hold my prefix. There are still some globals, and some stuff related mainly to the ZoneText headers that I haven't messed with, but everything relating to the minimap seems to be behaving itself as it should now...
except...
Other AddOns!

Namely, anything that parks a button on the minimap, and <cry> Gatherer.
All of that stuff still wants to (understandandably) play with the old minimap, which is of course now hidden. No errors or any other unspeakables, the other addons elements simply hide themselves with the old minimap.

So, is there an "easy" way to intercept this sort of stuff from my AddOn's code so that they will display on the "new" minimap? Or a hard way even? Or am I now faced with modifying other AddOns to "support" mine?

Might be a toughy, but it can't hurt to ask. :)

Now with hawter seggsier round minimize button! :eek:

(By the way, that button is kind of troublesome as a toggle. I would like to vary the "states" of the button image depending on whether the map was minimized or not, but that proved more complicated than expected, once I started trying to fool with it.)



Seriously though, I see a lot of requests from the minimilast camp for this sort of thing. I would be happy to pass this off to soemone more capable if anyone is interested in finishing this "concept" off, if its even possible? (Obviously, a release would likely need to be sans-dragon for the minimilasts, at the very least, I suppose an option at best..)

At this point, other than getting this AddOn to play nice with others, it works really well. It's also really simple to make the map "look" however you want it. ("BlizzardShouldHavedNamedMeAndSavedMeAllThisTrouble" was my favorite texture name in the recode. ;) )

Honestly, giving the map and its various (default) components a sleak "tooltip" border wouldn't be too difficult either. Provided of course, that you don't mind it being round. :p

I can try helping.

On a side note, something I have not tried myself, but may be useful in the situation you are in...

Every frame element or widget, etc... is given a script instance, just like functions. So in effect, remapping a function to a new function, would theoretically work with elements as well?

Example:

MinimapCluster = myCustomMapCluster;

Provided your custom map cluster has all of the same basic code that allows POI and other stuff to work, I would think this would be ideal for you to effectively replace the default element with your own custom one. Again, I have NOT tried this, so have no idea how the UI will behave, or if it will crash out. If it DOES work, then other addons would work out of the box with yours, as their little buttons should jump onto your custom minimap simply because the MinimapCluster reference is pointing to yours...

Be warned, that doing this means that anything that does MinimapCluster:Hide(); will in fact hide your minimap. So doing this means you would need to remove the code that hides the default minimap in favor of yours...

Good work so far, it is looking good...

Oooo, that sounds like it might just be the ticket Beladona. Of course, servers are down at the moment, but I will definitely give that a go later this evening.

Thank you. :)

just tried it. it appears to work, however not without errors. Some tweaking may be in order, but my initial test of remapping an element to a new element worked perfectly.

I tried it with PlayerFrame = cPlayerFrame; and then created cPlayerFrame as an exact duplicate of the regular PlayerFrame, but with the new name... Generated some errors, but still showed up in place of the regular PlayerFrame...

That sounds like the way I'm going to want to do things, if I'm reading it right.

It didn't work with Minimap=DS_Minimap, or with MinimapCluster=DS_MinimapCluster, at least not in the way I had hoped.

It certainly ties the two together, but it doesn't appear to carry anchors or parents over. All of the AddOns referencing the original minimap still did, without carring over any of said activity to the new map.

<sigh>

Back to the drawing board. :)

I dont mind editing a few buttons to anchor to my new minimap, but I haven't even peeked at Gatherer's Code yet. The mere notion gives me the willy's. ;)

hmm, will play with it some more. Remapping an element reference would in fact be the ideal way to do a total conversion in my opinion...

Something else you might consider is NOT hiding MinimapCluster, but instead find a way to make it transparent. You might do this by setting the texture for it in your LUA to something that is blank, and then anchor it to your new minimap. Then addons can still anchor to it all they want, they will just be anchored to it, which is anchored to yours... if you get what I mean.

The final thing you could do, to at least get some mods to work right, is to do a detection script within your own addon. I did this for an addon I was testing, which is going to be part of a larger suite I plan to release very soon. Create a new function that does something like:

All it does is check to see if SomeGathererFunction exists (I recommend using a gatherer function like the main OnLoad function, as it will most likely be there in all versions he ever releases.) and if it does exist, it will move the icon to your new minimap cluster. Obviously what I used above are fake references, so make the changes as you see fit. Call that function in your onload function, and it SHOULD work perfectly. Like I said, I used this method to get custom mods to list themselves in a mod list interface I was creating. If the mod existed, it would get added using my custom function that adds them to the list. -- doing it this way means the user is free to update said mod anytime they want, and it STILL works with your mod, because you are not making any special code changes to someone else's AddOn to make it work with yours.

I don't believe in making slight changes in other AddOns to make them work with mine. I either rewrite their AddOn from the ground up to suit my needs, or I do something in my own AddOn to make theirs behave the way I need it to. Changing underlying code in an AddOn maintained by someone else breaks forwards compatibility when someone attempts to update that individual AddOn. This is one of the problems many users of "Recompilations" face when the original creator of a mod releases an update, and the recmp user attempts to update that part. They then lose whatever custom code the recmp creator added or changes, and thereby lose some functionality of that recmp, or worse causes errors...

If I could set the texture on Blizzard's minimap, I wouldn't be going through all this trouble. :( (They didn't name the blasted thing ;) ). I'm about to go back to the original and see just what and what I really need to hide, but as I recall, the graphical "frame" around the zone text is in a layer in the primary frame, and it's texture is un-named. Since that texture is what I originally was trying to eliminate in the first place... meh.


That's what I was looking for! I'll play with this soon. Right now I got sidetracked with flexbar runscripts... I'm making collapsable graphical elements from DiivSkins all over my screen now with flexbar. lol.

The code block you gave me above should be just the ticket though for some of the map issues, if not all of them. (Assuming of course, that I can sort it out once I get in there ;) ).

Thanks again Beladona. :)

EDIT: scrap all that its already been said, should read before I post, lol.

On another note, one option is that you could actually leave the minimap name being the same as the blizzard default and this *should* overwrite their definition. This works because the FrameXML files(the defacto standard as it where) loads first. Then the addon directory loads.

Not a 'recommended way of doing things' but it may work.

Thank you Kaeltan. I'll give that a try tomorrow night. I'm tired now, and tired me makes version saving mistakes. ;)

I figured this wouldn't be easy, if possible at all, otherwise someone would have done it already. It's funny, I could have been done with this in less than an hour with a FrameXML hack, but that just wouldn't be any fun now would it. :D

I think I would have more luck petitioning Blizzard just to name the dang textures in their default file. :mad:

That minimap is so hot.

I do presume, by the way, that you guys are all aware of WoWWiki, yes?

I'm aware. . .

In the past, that site made little more sense to me than lua in general. Now that I'm slowly beginning to wrap my brain around the script, mayhap I should give it another look-see. I'm sure its a useful resource, I just hadn't been able to put it to much use in the past.

I'm still looking for a lua for dummies. ;)

It's probably sounds funny to those who code, but I couldn't tell you specifically what the significance of a semi colon is. Some times they appear needed, other times they dont. Another one is "=" vs "==". Does the latter mean, "not equal"? If so, then why do you sometimes simply say: "if not yadada".

I'm a language sort. Many moons ago I used to love diagramming sentences when all my classmates were groaning. Somehow, the syntax here is just coming so so slowly to me however. :|

WoWwiki is useful to me only in refreshing my memory on existence of functions and such. The site is HORRIBLY lacking in information. They rely on the communnity to provide usage info for each function and stuff like that, which I guess is partly my fault in that I never bother to submit anything...

Still, nothing can beat a direct question to someone that knows the answer. I tend to find all my info out on my own, but am more than willing to answer questions when they arise.

Just a sneak peek at part of what I am working on:



I moved all of the default micro menu buttons to the bar at the top, and mde a minimap toggle button with the minimap docked to the bar in a way that makes it look integrated to the bar. I know this looks like Titan Panel, which is true only in appearance, as all base coding is original, not to mention this is NOT meant to use plugins. In fact, if anything, I designed this bar to be a companion to Titan panel, as you can effectively have both on screen at the same time, with Titan panel docked to the bottom.

I have done tons of experimentation with code standards, playing with different methods of writing my lua scripts, in order to see which works the best / fastest. For the sake of standard compliance and making sure my mod never uses the same namespace for a function or widget that another mod uses, I have started putting ALL my functions and such into tables. Basically if I have a mod called myMod, I create a table called myMod, and all functions that go into that mod are children of that table. For example myMod.onUpdate(); could be a valid function. It also makes it easier to add new functions into that table within other lua scripts, sot aht other mods could effectively "plug in" to my mod. It also makes it MUCH less likely that my mod will conflict with other mods because of a shared namespace.

The other thing I have started experimenting with is disabling default functions that no longer serve a purpose. For instance, if you decided to hide something in the ui permanently (as long as the mod is installed anyway), then that ui element no longer really needs to exist. yet there are all these functions in the background that may or may not be firing, and as a result are taking up engine and memory space. So why not rehook them to a blank function? Less memory used = faster gameplay in my opinion. If the widget you disable is the only thing using that function, then there is no reason on earth the widget needs to exist at all. SO FAR this has worked like a charm for me, but as I do further testing I will know for sure. Obviously some functions may be best to leave alone, as they may be in use elsewhere...

Hopefully this gave people ideas. My eventual goal is to almost completely redesign the look and feel of the ui, rather than just add little things here and there.

That looks very nice Beladona. One suggestion I might make for you, given the popularity of Titan, is to option your bar top or bottom, so your user can choose. It won't effect me at all (and I do plan on using what I see so far) as I dock Titan on the bottom, but I'll wager you'll get the request. There would be some implementation issues with placement of the *hanging* elements in relation to the plethora of bottom bar possibilites, and I don't have a clue what you do with the map functionality if you park your bar down there, but like I mentioned, it might be worth considering.

Speaking of the map, that is really nicely executed. Well done! I have to ask... What happens when you click the open button for it? (give you three guesses why I'm curious) ;)


Most of what you said regarding lua naturally went right over my head, but I do look forward to taking a look at what you have cooking. Are tables simple enough in concept that you could post a code block here I could sneak a peek at? or is this something I better stay away from for now? (I'm just now getting a handle on the basics of actually calling a function from XML)

On a not really related note, I have a question. My AddOn, so far, doesn't contain a much if any lua/memory action. (Cant speak for MoveAnything! waaaay over my head what's goin on in there, but It feels clean on the top end anyway.) What it does have is a lot of frames, much of which are typically hidden. I swear I read once that a hidden (truly hidden, like, lua :Hide(); hidden) frame isn't using system resources. I'm curious if this is true, I think its fairly relevant to DiivSkins. Any idea if this is corrrect?

It does indeed (give me ideas) the layout stuffs, sadly not the code concepts. ;)

Thank you for sharing, I look forward to seeing more.

After finally knuckling down and asking about getting the minimap texture named in the official forums, I found that someone <cough> Gello <cough> had beat me to the punch. ;)

http://forums.worldofwarcraft.com/th...n&t=138577&p=3

Looks like all it will take to do a proper reskin of the minimap and the casting bar is a little patience. :)

EDIT: actually, that thread is chock-o-block with blue text.. lot of nice info there. I linked to page three, but take it from the top. It's a good read.

very nice link... and damnit, stop making me add stuff to my already messy list of bookmarks =p

Functions arranged in tables:

Just a short tutorial that I hope will help you.............
myMod.lua contains:
This should give you an idea of what I meant. Instead of making tons of functions that are global (like MyModOnLoad, MyModOnEvent, etc...) you can just define the global name first, and make all your functions children under that global. Makes more logical sense in my opinion, and it also approaches making Lua act like an Object Oriented Programming Language.

Make sure when you do it this way, that you put a semicolon after the last END for each function (the engine might let you get away with not doing it, but for the sake of proper coding practices, you should do it.). The reason you ahve to put a semicolon there is that each function is essentially just a variable with a function as it's data. It works the same as any normal function, but gets written a little different...

Any Questions? hehe

Lord help me, I think that actually did make sense.

Lately I've been pouring over the XML, and have been learning a lot about the fundamental architecture there. The system here is a lot more wide open than it was in DAoC. It can be more complicated, but once you get a handle on it, I've found you can do some comparatively nifty stuff with the parent child relationships, particularly when you toss a little lua in to assist something more complex. The lua stuff is coming, gradually. Thankfullly what I tend to work with doesn't require a ton of it, and what I do use it for is fairly simple, but I find myself calling more and more functions as my XML (and my end result in game) gets more and more intricate.

I will definitely play around with the tables, even if only just to see if I can get them working. ;)

By the time I'm happy with what I'm doing with DiivSkins, I might actually understand some of what has thus far been so baffling for me when I dig around in the more complicated AddOns.

As always, thanks so much for your reply Beladona.

What are the performance results of putting functions in tables, relating to speed, memory usage, and overhead?

Also, you mentioned widgets. How do you name your ui elements in the XML? Do you declare all named ui elements in a table in an included script at the beginning of the XML or something?

I hate reviving an old thread but this one is really interesting... I do have one question for you :p

Here's Diiver's code for his casting bar
I kinda understand more or less how it could possibly change in someway teh casting but I'm not going to ask you to explain the entire code :P There's just one thing bothring me... Actualy I think I just found out the answer to my question...

this.DS_casting = 1;
this.fadeOut = nil;

"this." is a table, right? I'm kinda mising it up with "this:"...

Yeah "this" is a table. All frames are tables. Usually (unless you use Ace or any object-oriented stuff), when you see something:SomethingElse(), "something" is a frame, which is a table.

You can add stuff to the frame/table too. It's very common in the default UI to have a frame store its tooltip there.

To backtrack a bit: when an event is sent to your mod, "this" is the frame from which it was sent. The following example doesn't relate to anything but it will hopefully point out exactly what "this" is.

If you have 2 frames in your mod and one has the onload:

<Frame name="MyFrame1">
<Scripts>
<OnLoad>
this:RegisterEvent("BAG_UPDATE")
</OnLoad>
</Scripts>
</Frame>

<Frame name="MyFrame2">
<Scripts>
<OnHide>
this:UnregisterEvent("BAG_UPDATE") <!-- wrong as an example see below -->
</OnHide>
</Scripts>
</Frame>

When the mod loads, this = MyFrame1
When MyFrame2 hides, this = MyFrame2

Note that you registered MyFrame1 to receive BAG_UPDATE. So you would want to use the frame name instead:

<Frame name="MyFrame2">
<Scripts>
<OnHide>
MyFrame1:UnregisterEvent("BAG_UPDATE")
</OnHide>
</Scripts>
</Frame>

As another example, if you have a bunch of buttons in your mod, but don't want to make an _OnClick for each of them. They can all share one function:

<Button name="ButtonTemplate" virtual="true">
<Scripts>
<OnClick>
MyMod_Button_OnClick()
</OnClick>
</Scripts>
</Button>

<Button name="Button1" inherits="ButtonTemplate"/>
<Button name="Button2" inherits="ButtonTemplate"/>
<Button name="Button3" inherits="ButtonTemplate"/>
<Button name="Button4" inherits="ButtonTemplate"/>

then in your lua:

function MyMod_Button_OnClick()
local buttonName = this:GetName()
DEFAULT_CHAT_FRAME:AddMessage(buttonName)
end

When you click Button1-4, this is the name of the frame that called it. (Buttons are frames too) So "this" is the table (or frame) Button1, Button2, Button3, etc.

You can get its name or the name of any named frame with frame:GetName(). So buttonName = this:GetName() will grab the name of the button that was clicked.

btw none of the xml above is fully functional. Just examples kept short.

Cool thanks alot Gello. Sens and understanding are slowly creeping into my brain :p