oUF_Kygo, a few tips wanted

[Phanx]

Keep in mind that files are read in the order listed in your TOC. If your "config" file is listed after your "main" file, then values you added to your private table in the "config" file aren't available in the main chunk of your "main" file. Either list your "config" file first (easiest) or make sure you don't try to access any of those values until after all your files have been read (during/after your addon's ADDON_LOADED event).

[Kygo]

How my .toc file currently looks:

## Interface: 60000
## Title: oUF_Kygo
## Author: Kygo
## Version: 1.2
## Dependencies: oUF

cfg.lua

elements\BurningEmbers.lua

Frames.lua

What I'm aware of so does WoW read all files in a top-to-bottom order.

And I changed around inside the "cfg" file itself last night to find a way to tell Frames.lua for example, "powerText:SetFont(cfg.font, cfg.fontsize, cfg.fontflag)". But in game, it gives me errors saying that's not how "SetFont" works.



Just gonna throw the three lines on the top the Frames.lua aswell in here if those are the ones that are wrong.

	local _, ns = ...
	local oUF = ns.oUF or oUF
	local cfg = ns.cfg

How the "cfg" file looks atm (the ClassPowerText is there to somehow call that table to set the powerText on both player and target to the color that their power is (eg mana is blue, rage is red..))

local addon, ns = ...
local name, ns = ...
local cfg = CreateFrame('Frame')
local _, class = UnitClass('player')
local cfg = {}
 
local mediaPath = "Interface\\AddOns\\oUF_Kygo\\Media\\"
cfg.texture = mediaPath.."normTex2.tga"
cfg.bgFile = mediaPath.."backdrop"
cfg.edgeFile = mediaPath.."backdrop_edge"
cfg.Icon = mediaPath.."Neal_border"
cfg.CPoint = mediaPath.."NCPoint"
 
cfg.font, cfg.fontsize, cfg.fontflag = "Interface\\AddOns\\oUF_Kygo\\Media\\Fonts\\ExpresswayRg.ttf", 10, 0, 0, "Outlinemonochrome"
 
    cfg.ClassPowerText = {
        Priest = {26/255, 160/255, 255/255}, --Mana
        Shaman = {26/255, 160/255, 255/255}, -- Mana
        Warlock = {26/255, 160/255, 255/255}, -- Mana
        Paladin = {26/255, 160/255, 255/255}, -- Mana
        MonkMistweaver = {26/255, 160/255, 255/255}, --How to check if monk is MW or not status: Unknown atm
        Mage = {26/255, 160/255, 255/255}, -- Mana
        DruidRestoBalance = {26/255, 160/255, 255/255}, -- Mana
        Warrior = {255/255, 26/255, 48/255}, -- Rage
        DruidGuardian = {255/255, 26/255, 48/255}, --Rage
        Hunter = {255/255, 128/255, 64/255}, -- Focus
        Rogue = {255/255, 225/255, 26/255}, -- Energy
        DruidFeral = {255/255, 225/255, 26/255}, -- Energy
        DeathKnight = {0.00, 0.82, 1.00}, -- Runic Power
}
 
ns.cfg = cfg

[Ekaterina]

Ah...not quite. You're doing a couple of things here that may cause things to act in a way you don't expect them to.

local addon, ns = ...
local name, ns = ...
local cfg = CreateFrame('Frame')
local _, class = UnitClass('player')
local cfg = {}

What you are doing here is creating two variables (addon and name) that hold the same information (the Addon Name). Then with cfg, first you are creating it as a frame, then re-defining it as a table.

Try this.
Config file:

local addonName, ns = ...
local _, class = UnitClass('player')
local mediaPath = "Interface\\AddOns\\oUF_Kygo\\Media\\"
 
local cfg = {
   texture = mediaPath.."normTex2.tga",
   bgFile = mediaPath.."backdrop",
   edgeFile = mediaPath.."backdrop_edge",
   Icon = mediaPath.."Neal_border",
   CPoint = mediaPath.."NCPoint",
   font = "Interface\\AddOns\\oUF_Kygo\\Media\\Fonts\\ExpresswayRg.ttf", 
   fontsize = 10,
   fontflag = "OUTLINE, MONOCHROME", -- Font flags should be in capitals and separated by a comma
 
   ClassPowerText = {
        Priest = {26/255, 160/255, 255/255}, --Mana
        Shaman = {26/255, 160/255, 255/255}, -- Mana
        Warlock = {26/255, 160/255, 255/255}, -- Mana
        Paladin = {26/255, 160/255, 255/255}, -- Mana
        MonkMistweaver = {26/255, 160/255, 255/255}, --How to check if monk is MW or not status: Unknown atm
        Mage = {26/255, 160/255, 255/255}, -- Mana
        DruidRestoBalance = {26/255, 160/255, 255/255}, -- Mana
        Warrior = {255/255, 26/255, 48/255}, -- Rage
        DruidGuardian = {255/255, 26/255, 48/255}, --Rage
        Hunter = {255/255, 128/255, 64/255}, -- Focus
        Rogue = {255/255, 225/255, 26/255}, -- Energy
        DruidFeral = {255/255, 225/255, 26/255}, -- Energy
        DeathKnight = {0.00, 0.82, 1.00}, -- Runic Power
    }
 
ns.cfg = cfg

Then at the top of the files where you need to access this information

local addonName, ns = ...
local cfg = ns.cfg -- if you want to save yourself some typing and reference the table as cfg.[i]KeyName[/i]. Otherwise you could just access the values using ns.cfg.[i]keyName[/i]

powerText:SetFont(cfg.font, cfg.fontsize, cfg.fontflag) would then work. It wasn't previously because the way you had the flags set.

The way I think of it is :
Config File

1. Get Access to the table accessible to the whole addon - (done by assigning it to 'ns')
2. Assemble the information I want to put into the table
3. Add the information to the table (ns.cfg = cfg)

Then in each other file you need to get that information.

1. Get access to the table (assigning it to 'ns' again)
2. [Optional] Assign the ns.cfg part of the table to a new variable to make typing out table references easier.
3. Use or change the information as required.

That is just the way I think of it for it to make sense to me and it is a very simplistic view of it. Phanx and others could probably go into more detail for you if you wished.

[Phanx]

While those duplicate variable declarations are indeed wrong, in this case they're not actually causing any problems, since you're not actually attempting to use the first ones (which get overwritten by the second ones).

There's also nothing wrong with doing tbl = {} and then a bunch of tbl.something = "some value" instead of tbl = { something = "some value "}. The second is technically more efficient, since it doesn't require a bunch of table lookups, but it won't really make any difference here, so you should use whichever you find easier to read and maintain.

However, the error you're getting indicates that you're doing something wrong in your Frames.lua file; you'll have to post the whole contents (preferrably as a file attachment or paste, not as inline code).

On a side note, I'm a little confused about why that ClassPowerText table exists at all -- instead of getting a class and a spec (two function calls) and then looking up a custom color based on that (presumably with a bunch if/else checks since your table key names are not conducive to a simple table lookup, at least not in non-English clients), why not just get the current power type and use the power color?

local powerType = UnitPowerType(unit)
local color = oUF.colors.power[powerType]

[Kygo]

Originally Posted by Ekaterina Ah...not quite. You're doing a couple of things here that may cause things to act in a way you don't expect them to. A lof of text

Thanks a lot! Got the font working ! Going to replace texture paths etc in the main chunk aswell

Originally Posted by Phanx There's also nothing wrong with doing tbl = {} and then a bunch of tbl.something = "some value" instead of tbl = { something = "some value "}. The second is technically more efficient, since it doesn't require a bunch of table lookups, but it won't really make any difference here, so you should use whichever you find easier to read and maintain.

So far, I've found that using the tbl = {} and then a bunch of tbl.something is easier for me to understand at this point!

Originally Posted by Phanx However, the error you're getting indicates that you're doing something wrong in your Frames.lua file; you'll have to post the whole contents (preferrably as a file attachment or paste, not as inline code).

The error occurred to my lack of knowledge when passing values and variables between files!

Originally Posted by Phanx On a side note, I'm a little confused about why that ClassPowerText table exists at all -- instead of getting a class and a spec (two function calls) and then looking up a custom color based on that (presumably with a bunch if/else checks since your table key names are not conducive to a simple table lookup, at least not in non-English clients), why not just get the current power type and use the power color? local powerType = UnitPowerType(unit) local color = oUF.colors.power[powerType]

I had that table (removed now) because I have defined my own power colors, which now are in the main chunk of the file (Thanks to Lumen's oUF layout)
Here is the color table = http://paste2.org/aIJAOhmV

It works as coloring the power bar correctly at the moment


EDIT: It's now on Github: https://github.com/Kygos/oUF_Kygo_NonRelease

[Kygo]

Not sure if the "Edit post" makes the thread marked as "Unread", but anyway!
Added the project on Github, which can be found here.
Successfully added tags and a half complete cfg files, less clutter in the main file!

Working on adding positions and sizes of the unit frames to the cfg file and to get the powerType local to work with the SetTextColor. I'm not the sharpest knife the drawer when it comes to certain things (Learning more and more which is a huge + for me! )!

Is it possible to "merge" Boss1-4 and Party1-4 into just "Boss" and "Party"?

[Phanx]

Originally Posted by Kygo Is it possible to "merge" Boss1-4 and Party1-4 into just "Boss" and "Party"?

Party - yes, you can use a header. Boss - no, they aren't supported by headers.

Party header example:
https://github.com/Phanx/oUF_Phanx/b...rames.lua#L865
https://github.com/Phanx/oUF_Phanx/b...r/Core.lua#L96

[Kygo]

Originally Posted by Phanx Party - yes, you can use a header. Boss - no, they aren't supported by headers. Party header example: https://github.com/Phanx/oUF_Phanx/b...rames.lua#L865 https://github.com/Phanx/oUF_Phanx/b...r/Core.lua#L96

Alrighty! Thanks for the examples!
Gonna take a look at it and see if I'm able to make it work

[Kygo]

Got the party frames "merge" sorta working. No LUA errors or so. Going to tinker with that after I've got the text coloring working. (Been stuck on this for the past X amount of hours) Where I'm stuck currently > I'm stuck here

Added a working castbar (woho!) with timer , name and a lovely spark !

Updated the whole thingymagic on Github for those who are interested > Github link

Have a continued great Friday evening

[Phanx]

Originally Posted by Kygo Where I'm stuck currently > I'm stuck here

1. The :SetTextColor method requires three (or four) arguments -- r, g, b, and optionally a.

2. You can't apply any coloring your spawn function, if the coloring depends on things that can change during gameplay, like what type of power the player has (that information is probably not even available in your addon's main chunk). You need to put that kind of thing in the PostUpdate callback for your Power element. Example:
https://github.com/Phanx/oUF_Phanx/b...tions.lua#L267
https://github.com/Phanx/oUF_Phanx/b...rames.lua#L212

3. Get an error display addon. There would definitely be an error telling you about #1. The default error display cannot show you errors that occur early in the loading process, and the main chunk (code in your addon that's run immediately, outside of a function) is definitely early. I recommend Bugger because I wrote it, but if you already have BugSack or Swatter those are fine too -- just pick one and turn it on.

[Kygo]

Originally Posted by Phanx 2. You can't apply any coloring your spawn function, if the coloring depends on things that can change during gameplay, like what type of power the player has (that information is probably not even available in your addon's main chunk). You need to put that kind of thing in the PostUpdate callback for your Power element. Example: https://github.com/Phanx/oUF_Phanx/b...tions.lua#L267 https://github.com/Phanx/oUF_Phanx/b...rames.lua#L212

Having a rough time following along in your example due to the use of "self" (Not using it myself.)
Tried to break it down so I could understand it, didn't go that well

If you have some pointers to information or guides about PostUpdate, it would be swell The only thing relative I could find was this.

Originally Posted by Phanx ...like what type of power the player has (that information is probably not even available in your addon's main chunk)...

I have a color table that the powerbar itself are using, not sure if that counts as the correct information needed tho?

Originally Posted by Phanx 3. Get an error display addon. There would definitely be an error telling you about #1. The default error display cannot show you errors that occur early in the loading process, and the main chunk (code in your addon that's run immediately, outside of a function) is definitely early. I recommend Bugger because I wrote it, but if you already have BugSack or Swatter those are fine too -- just pick one and turn it on.

Forgot I had Bugger installed, but turned off for some reason.

[Phanx]

Originally Posted by Kygo Having a rough time following along in your example due to the use of "self"

There's nothing magical about "self" -- it's just a variable name. The only time it's somewhat magical is when you use method notation. If you've got this:

local addon = {}
addon.name = "My Addon"

Then these are effectively identical:

function addon.PrintName(self) -- dot
    print("My name is:", self.name)
end

function addon:PrintName() -- colon
    print("My name is:", self.name)
end

... and regardless of which way you constructed your function, you can call it either of these ways:

addon:PrintName()
addon.PrintName(addon)

The only difference is that when calling your function with a colon, "self" is automatically defined as a reference to "addon" inside the function, whereas when you call it with a dot, you have to pass the reference yourself.

In the two sections of my oUF layout I linked, the section in Functions.lua defines a function (without a colon, so the "self" is explicitly named in the list of arguments it accepts) and the section in Frames.lua attaches that function to the frame's Power element under the name "PostUpdate". Later, each time oUF updates the Power element, it checks if the element has a "PostUpdate" function and, if it does, calls that function (with a colon, so "self" is automatically passed as the first argument).

Originally Posted by Kygo I have a color table that the powerbar itself are using, not sure if that counts as the correct information needed tho?

That's part of it, but I can't actually find where you were even using the "ClassPowerText" table, so I can't actually give you an example of correct usage.

However, while I was looking, I noticed this:

oUF.Tags.Events["readycheckicon"] = "DoReadyCheck"
oUF.Tags.SharedEvents["IsInGroup"] = true
oUF.Tags.Methods["readycheckicon"] = function(unit)
	if unit == "player" and IsInGroup() then
		return [[|TInterface\RAIDFRAME\ReadyCheck-Ready|t]]
	end
end

1. "DoReadyCheck" and "IsInGroup" are functions, not events, so your tag won't update properly. It'll only be updated at times when all elements get updated, like when you pass through a loading screen.

2. Your tag function checks for the "player" unit, so your tag would never display anything on other units, which rather defeats the point of a ready check icon.

3. There's not really any need to check if you're in a group, since there can't be a ready check if you're not in a group.

4. Your current code will cause an icon to be displayed all the time while you're in a group, since you're not actually checking the unit's ready check status.

5. oUF already provides a ReadyCheck element that will show not just the green "ready" icon, but also the red "not ready" and yellow "waiting" icons. It looks like you may have borrowed some tags from my layout -- most of those aren't strictly necessary since oUF already provides icon elements for most of that stuff, and I'm just using tags so I can put them all in a row that auto-adjusts without having to reposition texture objects. For static icons that always appear in the same place, just use the real elements.