Thread Tools Display Modes
05-01-05, 03:35 PM   #1
TinkerUI
A Murloc Raider
 
TinkerUI's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2005
Posts: 4
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
__________________
TinkerUI
TinkerUI - Core - [////||||||] 40%
TinkerUI - CogWorks - [/|||||||||] 10%
Website - [/////|||||] 50%
  Reply With Quote
05-01-05, 03:41 PM   #2
Cairenn
Credendo Vides
 
Cairenn's Avatar
Premium Member
WoWInterface Admin
Join Date: Mar 2004
Posts: 7,134
Originally Posted by TinkerUI
I think us newbie coders have the hardest time with one thing: Starting out.
Heh, ain't that the truth?
__________________
“Do what you feel in your heart to be right — for you’ll be criticized anyway.” ~ Eleanor Roosevelt
~~~~~~~~~~~~~~~~~~~
Co-Founder & Admin: MMOUI
FaceBook Profile, Page, Group
Avatar Image by RaffaeleMarinetti
  Reply With Quote
05-25-05, 08:44 AM   #3
Beladona
A Molten Giant
 
Beladona's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2005
Posts: 539
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)
  Reply With Quote
05-25-05, 08:58 AM   #4
Cairenn
Credendo Vides
 
Cairenn's Avatar
Premium Member
WoWInterface Admin
Join Date: Mar 2004
Posts: 7,134
Originally Posted by Beladona
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.
__________________
“Do what you feel in your heart to be right — for you’ll be criticized anyway.” ~ Eleanor Roosevelt
~~~~~~~~~~~~~~~~~~~
Co-Founder & Admin: MMOUI
FaceBook Profile, Page, Group
Avatar Image by RaffaeleMarinetti
  Reply With Quote
05-25-05, 10:25 PM   #5
Gello
A Molten Giant
AddOn Author - Click to view addons
Join Date: Jan 2005
Posts: 521
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).
  Reply With Quote
05-25-05, 10:29 PM   #6
Cairenn
Credendo Vides
 
Cairenn's Avatar
Premium Member
WoWInterface Admin
Join Date: Mar 2004
Posts: 7,134
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.

Last edited by Cairenn : 05-26-05 at 08:26 AM.
  Reply With Quote
05-26-05, 11:39 AM   #7
Gello
A Molten Giant
AddOn Author - Click to view addons
Join Date: Jan 2005
Posts: 521
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.
  Reply With Quote
05-26-05, 11:47 AM   #8
Cairenn
Credendo Vides
 
Cairenn's Avatar
Premium Member
WoWInterface Admin
Join Date: Mar 2004
Posts: 7,134
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. =/
  Reply With Quote
05-26-05, 12:11 PM   #9
Gello
A Molten Giant
AddOn Author - Click to view addons
Join Date: Jan 2005
Posts: 521
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.
  Reply With Quote
05-26-05, 12:30 PM   #10
Cairenn
Credendo Vides
 
Cairenn's Avatar
Premium Member
WoWInterface Admin
Join Date: Mar 2004
Posts: 7,134
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?

Last edited by Cairenn : 05-26-05 at 01:05 PM.
  Reply With Quote
05-26-05, 01:51 PM   #11
Beladona
A Molten Giant
 
Beladona's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2005
Posts: 539
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.
  Reply With Quote
05-26-05, 02:04 PM   #12
Cairenn
Credendo Vides
 
Cairenn's Avatar
Premium Member
WoWInterface Admin
Join Date: Mar 2004
Posts: 7,134
Originally Posted by Beladona
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.
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. =/

Last edited by Cairenn : 10-01-09 at 07:42 PM.
  Reply With Quote
05-26-05, 02:49 PM   #13
Beladona
A Molten Giant
 
Beladona's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2005
Posts: 539
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)
<Texture name="MainMenuBarTexture0" file="Interface\MainMenuBar\UI-MainMenuBar-Dwarf"><Size><AbsDimension x="256" y="53"/></Size><Anchors><Anchor point="BOTTOM"><Offset><AbsDimension x="-384" y="0"/></Offset></Anchor></Anchors><TexCoords left="0" right="1.0" top="0.79296875" bottom="1.0"/></Texture>
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
<Texture name="MyTexture0" file="Interface\AddOns\MyAddOn\image.tga"><Size><AbsDimension x="256" y="50"/></Size><Anchors><Anchor point="BOTTOM"><Offset><AbsDimension x="0" y="0"/></Offset></Anchor></Anchors><TexCoords left="0" right="1.0" top="0.390625" bottom="0.5859375"/></Texture>
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...

Last edited by Beladona : 05-26-05 at 02:52 PM.
  Reply With Quote
05-26-05, 02:50 PM   #14
Gello
A Molten Giant
AddOn Author - Click to view addons
Join Date: Jan 2005
Posts: 521
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)

Code:
<Ui xmlns="http://www.blizzard.com/wow/ui/">
	<Script file="MyMod.lua"/>
	<Frame name="MyModFrame">
		<!-- Attributes of the main MyModFrame: size, anchors, scripts, backdrop, etc -->
		<Layers>
			<Layer name="(something pre-defined: ARTWORK, BACKGROUND, OVERLAY">
				<!-- labels and textures that will be behind everything else -->
			</Layer>
		</Layers>
		<Frames>
			<!-- Buttons, sliders, things that will accept mouse clicks go here -->
		</Frames>
		<Scripts>
			<!-- Events (OnLoad, OnEvent, etc) for MyModFrame -->
		</Scripts>
	</Frame>
</Ui>
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:

Code:
<Ui xmlns="http://www.blizzard.com/wow/ui/">
	<Script file="MyMod.lua"/>
	<Frame name="MyModFrame" parent="UIParent">
		<Size>
			<AbsDimension x="1" y="1"/>
		</Size>
		<Anchors>
			<Anchor point="CENTER"/>
		</Anchors>
		<Layers>
			<Layer name="OVERLAY"/>
				<Texture name="MyCastingBorder" file="Interface\AddOns\MyMod\arcanegauge">
					<Size>
						<AbsDimension x="128" y="32"/>
					</Size>
					<Anchors>
						<Anchor point="TOPLEFT" relativeTo="MyModFrame" relativePoint="TOPLEFT"/>
					</Anchors>
					<TexCoords left="0" right="0.9375" top="0" bottom="0.359375"/>
				</Texture>
			</Layer>
			<Layer name="ARTWORK"/>
				<Texture name="MyCastingGuage" file="Interface\AddOns\MyMod\arcanegauge">
					<Size>
						<AbsDimension x="128" y="32"/>
					</Size>
					<Anchors>
						<Anchor point="TOPLEFT" relativeTo="MyCastingBorder" relativePoint="TOPLEFT">
							<Offset>
								<AbsDimension x="37" y="30"/>
							</Offset>
						</Anchor>
					</Anchors>
					<TexCoords left="0" right="0.33594" top="0.3711" bottom=".54297"/>
				</Texture>
			</Layer>
		</Layers>
		<Scripts>
			<OnLoad>
				MyMod_OnLoad();
			</OnLoad>
			<OnEvent>
				MyMod_OnEvent();
			</OnEvent>
		</Scripts>
	</Frame>
</Ui>
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():

Code:
function MyMod_OnLoad()
	CastingBarFrame_OnEvent = MyCastingBarFrame_OnEvent
	CastingBarFrame_OnUpdate = MyCastingBarFrame_OnUpdate
end

function MyCastingBarFrame_OnEvent()
	-- use my code
end

function MyCastingBarFrame_OnUpdate()
	-- use my code
end
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:

Code:
function MyMod_OnLoad()
	Old_CastingBarFrame_OnEvent = CastingBarFrame_OnEvent
	CastingBarFrame_OnEvent = MyCastingBarFrame_OnEvent

	Old_CastingBarFrame_OnUpdate = CastingBarFrame_OnUpdate
	CastingBarFrame_OnUpdate = MyCastingBarFrame_OnUpdate

	User_Wants_Default = false; -- user can toggle this somehow to go back to original casting bar
end

function MyCastingBarFrame_OnEvent()

	if User_Wants_Default then
		Old_CastingBarFrame_OnEvent()
	else
		-- use my code
	end
end

function MyCastingBarFrame_OnUpdate()

	if User_wants_Default then
		Old_CastingBarFrame_OnUpdate()
	else
		-- use my code
	end
end
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:

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

Code:
function MyMod_OnLoad()
	this:RegisterEvent("PLAYER_ENTERING_WORLD");
end

function MyMod_OnEvent()
	CastingBarBorder:SetWidth(120);
	CastingBarBorder:SetHeight(92);
	CastingBarBorder:SetTexCoords(0,0,.92375,.359375);
	CastingBarStatus:SetWidth(44);
	CastingBarStatus:SetHeight(44);
	CastingBarStatus:SetTexCoords(0,.33954,.3711,.54297);
	CastingBarStatus:ClearAllPoints();
	CastingBarStatus:SetPoint("TOPLEFT","CastingBarBorder","TOPLEFT",37,30);
end
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.
  Reply With Quote
05-26-05, 02:56 PM   #15
Cairenn
Credendo Vides
 
Cairenn's Avatar
Premium Member
WoWInterface Admin
Join Date: Mar 2004
Posts: 7,134
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:

Code:
  <TextureInfo item="corners.tga">
    <Size>
      <CX>256</CX>
      <CY>256</CY>
    </Size>
  </TextureInfo>
  <Ui2DAnimation item="topleftcorner">
    <Frames>
      <Texture>corners.tga</Texture>
      <Location>
        <X>0</X>
        <Y>0</Y>
      </Location>
      <Size>
        <CX>128</CX>
        <CY>128</CY>
      </Size>
     </Frames>
  </Ui2DAnimation>
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.

Last edited by Cairenn : 05-26-05 at 03:01 PM.
  Reply With Quote
05-26-05, 03:01 PM   #16
Beladona
A Molten Giant
 
Beladona's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2005
Posts: 539
lol, KABLUI!

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

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

Last edited by Beladona : 05-26-05 at 03:05 PM.
  Reply With Quote
05-26-05, 03:09 PM   #17
Cairenn
Credendo Vides
 
Cairenn's Avatar
Premium Member
WoWInterface Admin
Join Date: Mar 2004
Posts: 7,134
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"
  Reply With Quote
05-26-05, 03:51 PM   #18
Gello
A Molten Giant
AddOn Author - Click to view addons
Join Date: Jan 2005
Posts: 521
Code:
  <TextureInfo item="corners.tga">
    <Size>
      <CX>256</CX>
      <CY>256</CY>
    </Size>
  </TextureInfo>
  <Ui2DAnimation item="topleftcorner">
    <Frames>
      <Texture>corners.tga</Texture>
      <Location>
        <X>0</X>
        <Y>0</Y>
      </Location>
      <Size>
        <CX>128</CX>
        <CY>128</CY>
      </Size>
     </Frames>
  </Ui2DAnimation>
If memory serves, this is making 'topleftcorner' be the top left quarter of corners.tga. The WoW equivalent is:

Code:
  <Texture name="topleftcorner" file="Interface\AddOns\MyMod\corners">
      <TexCoords left="0" right=".5" top="0" bottom=".5"/>
  </Texture>
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.
  Reply With Quote
05-26-05, 05:15 PM   #19
mondinga
A Theradrim Guardian
AddOn Author - Click to view addons
Join Date: Jan 2005
Posts: 66
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
  Reply With Quote
05-27-05, 09:58 AM   #20
Beladona
A Molten Giant
 
Beladona's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2005
Posts: 539
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...

Last edited by Beladona : 05-27-05 at 10:37 AM.
  Reply With Quote

WoWInterface » Developer Discussions » Lua/XML Help » GUI's

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off