i started all this trouble cux i put it after the local color stuff for the PowerBarColor. putting it there did nothing and it was skipped.
That's basically correct, except I think you're still not quite understanding what the "local color" does. Let's say you can either log on as a mage (with MANA) or a warrior (with RAGE).
Blizzard's code defines this:
PowerBarColor = {}
PowerBarColor["MANA"] = { r = 0.00, g = 0.00, b = 1.00 }
PowerBarColor["RAGE"] = { r = 1.00, g = 0.00, b = 0.00 }
This basically says:
Create an empty table.
Name it "PowerBarColor".
Put it in the global namespace.
Add a key named "MANA".
Set the value of the key named "MANA" to a table containing three keys "r", "g", and "b".
Set each of their values to a number.
Add a key named "RAGE".
Set the value of the key named "RAGE" to a table containing three keys "r", "g", and "b".
Set each of their values to a number.
Other ways to write the same thing, with exactly the same result, would be:
Which way you construct tables is a matter of personal choice. They all accomplish the same thing.
However, there is much less flexibility in how you can write code to change a value in a table that already exists. Any time you write a pair of curly brackets "{ }", regardless of what's between them, you create a new table. If you just want to change a value in a table that already exists, you don't want to create a new table, and creating a new table won't accomplish your goal. So you can see that the value of the "r" key, which is part of a table which is the value of the "MANA" key, which is part of a table that is named "PowerBarColor", would be accessed like this:
value = PowerBarColor["MANA"]["r"]
or like this, if your key names are all strictly alphanumeric and begin with a letter:
value = PowerBarColor.MANA.r
In either case, the value of the variable "value" would be the number "0" (note that trailing decimal zeros are ignored, so if you write "1.00000000000000" Lua just sees "1").
Now, if you want to look up the value of the "r" key, which is part of a table which is the value of one of multiple keys whose value may vary each time your code is executed, which is part of a table named "PowerBarColor", variables come into play. In your case, you're obtaining the key name by calling the function UnitPowerType:
Depending on whether you logged in on a mage or a warrior, the value of the variable "powerTypeName" will either be "MANA" or "RAGE". We could do a chain of "if-then-else" constructs with full table lookups each time:
if powerTypeName == "MANA" then
fontstring:SetTextColor(PowerBarColor["MANA"]["r"], PowerBarColor["MANA"]["g"], PowerBarColor["MANA"]["b"])
elseif powerTypeName == "RAGE" then
fontstring:SetTextColor(PowerBarColor["RAGE"]["r"], PowerBarColor["RAGE"]["g"], PowerBarColor["RAGE"]["b"])
end
However, this is big and ugly, would require lots more "elseif"s to account for the other possible power types, and would require you to update your code if a new power type was ever added. So, you can look at the above, and notice that certain things are the same. For example, the name of first key you look up in the table "PowerBarColor" is always exactly the same as the value of the variable "powerTypeName". So, you can shorten it all down to:
This works, too. But, you can look at it some more, and notice that the first two parts of each lookup are the same. Each one first finds the global table "PowerBarColor" and then finds the key in it whose name is the same as the value of the variable "powerTypeName". There's not really anything wrong with this, but table lookups cost CPU time, so any time you can reduce the number of table lookups your code must do, it's beneficial to do so. So, you can create an upvalue, which is basically a bookmark into a specific point in a table. In your code, that's what "local color" is. You're creating a variable named "color", which is an upvalue pointing at the key whose name is the same as the value of the variable "powerTypeName" in the table "PowerBarColor", and then you're using the "local" keyword to keep "color" limited to that specific function execution.
local color = PowerBarColor[powerTypeName]
Then, you use that bookmark when you actually look up the color values, to reduce the number of table lookups. It's basically like you have a big reference book in front of you, and you know that you're going to be looking for information about either kangaroos or rhinoceroses. You could use the index in the back of the book and thumb through pages to find the kangaroo and rhinoceros sections every time, or you could just use bookmarks to mark the locations of the kangaroo and rhinoceros sections.
This is exactly the same, except that you name the variables "_" and "powerType" instead of "powerTypeNumber" and "powerTypeName", and you use the "local" keyword to keep both variables limited to the scope of the code currently being executed.
Why "_"? When you're assigning variable names to values returned by functions, you can't selectively tell the function to only return one of its values, or to return them in a different order, so you get all of them in the same order every time you call the function. Instead of giving each variable a meaningful name, it's a common practice to use an underscore to name the ones you don't care about. Not only is it easy to type, and consistent, but the fact that the variable's name is a single character of punctuation helps you remember that it's "junk" and doesn't have a value you care about.
As for the "local" keyword...
local foo = "Goodbye"
function DoStuff()
local foo = "Hello"
if foo == "Hello" then
local bar = "World!"
-- 1. At this point, the value of "foo" is "Hello"
-- and the value of "bar" is "World!". Do you see why?
end
-- 2. At this point, the value of "foo" is "Hello",
-- and the value of "bar" is nil. Do you see why?
end
-- 3. At this point, the value of foo is "Goodbye",
-- and the value of "bar" is nil. Do you see why?
Do #1, #2, and #3 all make sense?
Quote from ET20 »
Before instead of after the other local color for PowerBarColor but that isn't good formatting.
The term formatting refers to things like indentation and spacing. It does not refer to things like code order, variable naming, variable scoping, upvalues, etc. Formatting refers to the things that don't affect how the code works, but do affect how easy it is for humans to read the code. Formatting does not refer to anything that affects how the code works.
wouldn't give me the same color i think. Is doing 0/255 for shades cux from what i understood 0 = off 1 = on.
i don't have to put PowerBarColor = {} at the start of that cux that would make a new table for PowerBarColor which one already exists correct?
--
value = PowerBarColor["MANA"]["r"]
in this example value is what i'm working with?
or are we talking about
value = PowerBarColor["MANA"]["r"] [B]The number here for value[/B]
What does
"_"
exactly mean? It means it's junk so it's saying
local _(junk), powerType = UnitPowerType("player") but what does this cover?
--
[QUOTE]
local foo = "Goodbye"
function DoStuff()
local foo = "Hello"
if foo == "Hello" then
local bar = "World!"
-- 1. At this point, the value of "foo" is "Hello"
-- and the value of "bar" is "World!". Do you see why? [B]( cux of line 4 and 7 )[/B]
end
-- 2. At this point, the value of "foo" is "Hello", [B]( line 4 )[/B]
-- and the value of "bar" is nil. Do you see why? [B]( not exactly but why does foo = hello and goodbye? )[/B]
end
-- 3. At this point, the value of foo is "Goodbye",
-- and the value of "bar" is nil. Do you see why?[/QUOTE]
WoW accepts color values from 0 to 1. People who are used to working with colors in other mediums, like graphic design, or HTML, are usually more familiar with a 0-255 range for specifying color values, so you can write "144/255" instead of "0.564" and WoW will do the math for you to get a 0-1 number. So, 255/255 = 1, and 0/255 = 0.
That line of code reads the value of the "r" key from the table which is the value of the "MANA" key in the "PowerBarColor" table, and copies that value to a variable named "value". So, in that example, "value" would have a value of 0.
What does "_" exactly mean? It means it's junk so it's saying
local _(junk), powerType = UnitPowerType("player")
but what does this cover?
It doesn't "mean" anything. It's just a name for a variable. You could just as easily say local pie, cake = UnitPowerType("player"), but as we've already talked about, it's a good idea to give your variables names that help you remember what their values are. Since the second return value from the UnitPowerType function is a string describing the unit's power type ("MANA", "RAGE", etc), we name it "powerType". Since the first return value from the UnitPowerType function is something we don't care about and aren't going to use, we name it an underscore.
If we were calling a function that gave us five return values, and we only cared about the second and fourth ones, we could do:
local _, second, _, fourth, _ = GetTheValues()
The underscore is just a placeholder, because we have to name the variable something, but we don't actually want to use it anywhere in our code, and don't care what its value is.
So:
local _, powerType = UnitPowerType("player")
Basically says:
The function UnitPowerType returns two values. Ignore the first value, and name the second one "powerType".
I'm not really sure what you're asking... the underscore doesn't "cover" anything, and doesn't do anything special. It's just a variable name like any other. You could just as easily use "jello" or "crapWeDontCareAbout" as a variable name. It's just a common practice, which means it's a popular way of doing a certain thing; common practices mainly exist because they're convenient and consistent, but they're not the only way to do something, and in many cases they're not "better" than any other way to do the same thing. It's a common practice to name a variable an underscore if you're not going to use its value, but naming a variable an underscore doesn't do anything special, or differently than naming a variable anything else.
Most people never use this as a variable name unless they are throwing it away.
-- this
local _, second, _, fourth, _ = GetTheValues()
-- is the same as this without all the extra the overhead.
[COLOR=red]Warning:Do not use this method![/COLOR]
local _ = select(1, GetTheValues())
local second = select(2, GetTheValues())
local _ = select(3, GetTheValues())
local fourth = select(4, GetTheValues())
local _ = select(5, GetTheValues())
alright so basically all this time i thought the local variable had to point to a function. which they do most of the time but don't have to. they're just named that way for the sake of remember what that part does.
I would suggest you make a weekend out of reading all the way through the Programming in Lua (PIL) online reference. Most of the things you are/have had problems iwth is baisc programming rather than specific cases. IE, what is a table, how do I use them, what's the syntax for changing them. Same for local variables and for that matter what is a variable, how . . .
You've jumped in feet first before fully understanding the concepts. This is a bad thing as it's SO easy to get confused by more advanced concepts at that point in your programming development.
Phanx is a god when it comes to patience it seems, Phanx's explanations and handholding, though good isn't going to get you where you want to go without understanding the basic concepts.
Bascially you'll do much better by taking a deep breath, putthing the addon down and doing homework for a week or so, writing basic "hello world" type things first.
i've already started reading one of the past links Phanx showed me. ( http://www.lua.org/manual/5.1/manual.html#2 ) i hadn't planed on making another post till i read the entire thing. It's been progression/achievement week. so that and other things have been taking up my time.
That's basically correct, except I think you're still not quite understanding what the "local color" does. Let's say you can either log on as a mage (with MANA) or a warrior (with RAGE).
Blizzard's code defines this:
PowerBarColor = {} PowerBarColor["MANA"] = { r = 0.00, g = 0.00, b = 1.00 } PowerBarColor["RAGE"] = { r = 1.00, g = 0.00, b = 0.00 }This basically says:
Other ways to write the same thing, with exactly the same result, would be:
PowerBarColor = { ["MANA"] = { ["r"] = 0.00, ["g"] = 0.00, ["b"] = 1.00, }, ["RAGE"] = { ["r"] = 1.00, ["g"] = 0.00, ["b"] = 0.00, }, }PowerBarColor = { MANA = { r = 0.00, g = 0.00, b = 1.00 }, RAGE = { r = 1.00, g = 0.00, b = 0.00 }, }PowerBarColor = {} PowerBarColor.MANA = {} PowerBarColor.MANA.r = 0.00 PowerBarColor.MANA.g = 0.00 PowerBarColor.MANA.b = 1.00 PowerBarColor.RAGE = {} PowerBarColor.RAGE.r = 1.00 PowerBarColor.RAGE.g = 0.00 PowerBarColor.RAGE.b = 0.00Which way you construct tables is a matter of personal choice. They all accomplish the same thing.
However, there is much less flexibility in how you can write code to change a value in a table that already exists. Any time you write a pair of curly brackets "{ }", regardless of what's between them, you create a new table. If you just want to change a value in a table that already exists, you don't want to create a new table, and creating a new table won't accomplish your goal. So you can see that the value of the "r" key, which is part of a table which is the value of the "MANA" key, which is part of a table that is named "PowerBarColor", would be accessed like this:
or like this, if your key names are all strictly alphanumeric and begin with a letter:
In either case, the value of the variable "value" would be the number "0" (note that trailing decimal zeros are ignored, so if you write "1.00000000000000" Lua just sees "1").
Now, if you want to look up the value of the "r" key, which is part of a table which is the value of one of multiple keys whose value may vary each time your code is executed, which is part of a table named "PowerBarColor", variables come into play. In your case, you're obtaining the key name by calling the function UnitPowerType:
powerTypeNumber, powerTypeName = UnitPowerType("player")Depending on whether you logged in on a mage or a warrior, the value of the variable "powerTypeName" will either be "MANA" or "RAGE". We could do a chain of "if-then-else" constructs with full table lookups each time:
However, this is big and ugly, would require lots more "elseif"s to account for the other possible power types, and would require you to update your code if a new power type was ever added. So, you can look at the above, and notice that certain things are the same. For example, the name of first key you look up in the table "PowerBarColor" is always exactly the same as the value of the variable "powerTypeName". So, you can shorten it all down to:
This works, too. But, you can look at it some more, and notice that the first two parts of each lookup are the same. Each one first finds the global table "PowerBarColor" and then finds the key in it whose name is the same as the value of the variable "powerTypeName". There's not really anything wrong with this, but table lookups cost CPU time, so any time you can reduce the number of table lookups your code must do, it's beneficial to do so. So, you can create an upvalue, which is basically a bookmark into a specific point in a table. In your code, that's what "local color" is. You're creating a variable named "color", which is an upvalue pointing at the key whose name is the same as the value of the variable "powerTypeName" in the table "PowerBarColor", and then you're using the "local" keyword to keep "color" limited to that specific function execution.
Then, you use that bookmark when you actually look up the color values, to reduce the number of table lookups. It's basically like you have a big reference book in front of you, and you know that you're going to be looking for information about either kangaroos or rhinoceroses. You could use the index in the back of the book and thumb through pages to find the kangaroo and rhinoceros sections every time, or you could just use bookmarks to mark the locations of the kangaroo and rhinoceros sections.
Note that in your actual code, instead of:
powerTypeNumber, powerTypeName = UnitPowerType("player")You have:
local _, powerType = UnitPowerType("player")This is exactly the same, except that you name the variables "_" and "powerType" instead of "powerTypeNumber" and "powerTypeName", and you use the "local" keyword to keep both variables limited to the scope of the code currently being executed.
Why "_"? When you're assigning variable names to values returned by functions, you can't selectively tell the function to only return one of its values, or to return them in a different order, so you get all of them in the same order every time you call the function. Instead of giving each variable a meaningful name, it's a common practice to use an underscore to name the ones you don't care about. Not only is it easy to type, and consistent, but the fact that the variable's name is a single character of punctuation helps you remember that it's "junk" and doesn't have a value you care about.
As for the "local" keyword...
Do #1, #2, and #3 all make sense?
The term formatting refers to things like indentation and spacing. It does not refer to things like code order, variable naming, variable scoping, upvalues, etc. Formatting refers to the things that don't affect how the code works, but do affect how easy it is for humans to read the code. Formatting does not refer to anything that affects how the code works.
PowerBarColor["MANA"]["r"] = 0 PowerBarColor["MANA"]["g"] = 144/255 PowerBarColor["MANA"]["b"] = 255is 255 considered 1.0 or can you go past 1.0?
cux doing this:
PowerBarColor["MANA"]["r"] = 0 PowerBarColor["MANA"]["g"] = 1.0 PowerBarColor["MANA"]["b"] = 1.0wouldn't give me the same color i think. Is doing 0/255 for shades cux from what i understood 0 = off 1 = on.
i don't have to put PowerBarColor = {} at the start of that cux that would make a new table for PowerBarColor which one already exists correct?
--
in this example value is what i'm working with?
or are we talking about
What doesexactly mean? It means it's junk so it's saying
local _(junk), powerType = UnitPowerType("player") but what does this cover?
--
WoW accepts color values from 0 to 1. People who are used to working with colors in other mediums, like graphic design, or HTML, are usually more familiar with a 0-255 range for specifying color values, so you can write "144/255" instead of "0.564" and WoW will do the math for you to get a 0-1 number. So, 255/255 = 1, and 0/255 = 0.
That would give you a "pure" cyan. 0 parts red, 1 part green, 1 part blue.
Correct.
That line of code reads the value of the "r" key from the table which is the value of the "MANA" key in the "PowerBarColor" table, and copies that value to a variable named "value". So, in that example, "value" would have a value of 0.
It doesn't "mean" anything. It's just a name for a variable. You could just as easily say local pie, cake = UnitPowerType("player"), but as we've already talked about, it's a good idea to give your variables names that help you remember what their values are. Since the second return value from the UnitPowerType function is a string describing the unit's power type ("MANA", "RAGE", etc), we name it "powerType". Since the first return value from the UnitPowerType function is something we don't care about and aren't going to use, we name it an underscore.
If we were calling a function that gave us five return values, and we only cared about the second and fourth ones, we could do:
The underscore is just a placeholder, because we have to name the variable something, but we don't actually want to use it anywhere in our code, and don't care what its value is.
So:
local _, powerType = UnitPowerType("player")Basically says:
The function UnitPowerType returns two values. Ignore the first value, and name the second one "powerType".
What can I say, I like dirty water. :p
You can give it an arbitrary value:
Or you can fill in its value by calling a function that returns a value:
local myName = UnitName("player")You don't even have to give it a value right away:
local myVariable function MyAddon:DoStuff() myVariable = "Hello World!" endAnd you can change its value later:
local myVariable = 2 function MyAddon:DoStuff() myVariable = myVariable + 1 endYou can also use a function's return value directly without creating a variable:
if UnitName("player") == "Someguy" then DoStuff() endYou've jumped in feet first before fully understanding the concepts. This is a bad thing as it's SO easy to get confused by more advanced concepts at that point in your programming development.
Phanx is a god when it comes to patience it seems, Phanx's explanations and handholding, though good isn't going to get you where you want to go without understanding the basic concepts.
Bascially you'll do much better by taking a deep breath, putthing the addon down and doing homework for a week or so, writing basic "hello world" type things first.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumwow thanks - fav-ed :D