So I'm renaming my SimpleTexts to LuaTexts. All that's really left is to finish up the config and put in the lua for all the default codes. Basic design is you can choose the events to trigger an update and have lua code that generates the parameters to SetFormattedText() on the fontstring.
This design should produce significantly less garbage than DogTags does, run faster than dogtags since it has no need for a parser. However, this comes at the cost of ease of configurability. While it can pretty much do anything including things that DogTags can't do. It's going to be much more difficult to make it do things that seem simple in DogTags.
However, the goal here is to provide performance improvements for people that primarily only use built in tags with the current DogTagTexts. If you're a heavy user of DogTags you probably won't like it. If all you ever did was select prebuilt tags you'll probably think it's swimmingly better.
Sweet, I can't wait! I wonder what the feasibility is of going in and customizing the Lua for a text? Should we clone the LuaTexts module and make our own? (Not wanting to merge in my custom Lua changes during an update.)
Sweet, I can't wait! I wonder what the feasibility is of going in and customizing the Lua for a text? Should we clone the LuaTexts module and make our own? (Not wanting to merge in my custom Lua changes during an update.)
Actually the code is exposed to edit in the config UI. Similar to how DogTags are exposed. The only difference is you have to manage your own events that are needed to trigger updates (there's a dropdown boxes with a list of events you can check to turn on updates from) and another checkbox to turn on fast updates for things like the PowerBar on player and pet frames.
Most people will just want to ignore the event drop down and the code box and select stuff from the drop down list of already written codes.
For all practical purposes this is a rewrite of LibDogTag without the language that requires parsing and using raw Lua instead. I have included a special environment each script gets and am writing some functions that replace some of the features of DogTags. For example Name - Long looks like so:
if unit then local r,g,b = ClassColor(unit) return '%s |cff%02x%02x%02x%s|r%s',Level(unit),r,g,b,UnitName(unit),AFK(unit) or DND(unit) or '' end
The first return is the format string to put together the text and everything after that is a value that goes in. Level(unit), AFK(unit) and DND(unit) were functions I wrote that essentially replace the [Level] [AFK] and [DND] tags in LibDogTag.
Anyway to directly answer your question, you won't need to duplicate the module.
Anyway to directly answer your question, you won't need to duplicate the module.
That is the coolest thing I have possibly ever heard. This is going to hands down make Pitbull 4 the best thing since sliced bread! Thanks for working on it.
So I'm renaming my SimpleTexts to LuaTexts. All that's really left is to finish up the config and put in the lua for all the default codes. Basic design is you can choose the events to trigger an update and have lua code that generates the parameters to SetFormattedText() on the fontstring.
I can't wait for this. I see applications far beyond PitBull4 though. I know lots of people are lamenting the DogTag-related issues with CowTip, for instance. Imagine a tooltip addon that uses LuaTexts! Hot! We could even have LDB tickers that show us exactly what we want to see. Mmmmm.
Push I just did added LuaTexts. It's complete as far as the default tags are concerned. I'll try to get a page up with some degree of documentation.
Ohh I should note, the module is disabled by default. If you're looking to switch probably the most logical thing to do is to disable DogTagTexts and load LuaTexts. If you're running embeded all you should need to do to prevent LibDogTag from being load is to reload your ui. Unless of course you're running some other mod that needs it or you have it separately installed.
My limited testing earlier tonight showed a 10 fps improvement over DogTagTexts in Ulduar. YMMV. Bugs are likely to abound.
I can't wait for this. I see applications far beyond PitBull4 though. I know lots of people are lamenting the DogTag-related issues with CowTip, for instance. Imagine a tooltip addon that uses LuaTexts! Hot! We could even have LDB tickers that show us exactly what we want to see. Mmmmm.
Just to be clear, I didn't write this to be a generalized text provider. It's pretty much designed to be attached at the hip to PitBull4. Separating it out to be a separate library is going to probably add some overhead.
It's missing the load.xml file to make it load. Easy enough to just copy from another module and edit though. Checking this awesomeness out now!
UPDATE: This is really really complicated. :) I don't think I can replace all my DogTags in the 20 minutes before my raid. LOL! It'll be worth it later though.
I told you it would be. Thanks for catching that I missed that one file. Did another push to put it in.
Some of the complexity of the provided codes is that I'm avoiding doing concatentation or string formatting and trying to pass it all through to SetFormattedText(). The reason for this is if SetFormattedText does it then no garbage is produced, since it's done by the C++ code of WoW rather than Lua. The function was added specifically to help us avoid churning memory.
You can write a heck of a lot simpler looking stuff without that constraint.
That said, I avoided adding conveience functions that would encourage you to do that. This module is really about performance. Not about easy tinkering.
Is there a chance for some reference sheet of custom functions in lua module?
Reverse engineering from built-in sample texts is a bit tough;P
For now could anyone help me with checking if unit is in combat and retrieving reaction colors?;P
I have strange feeling that we have to implement all DogTag colors from scratch now ><
Thanks a lot for the lua texts! I really appreciate it!
Maybe if anyone has time, I would be interested in 3 things I used to do with the dogtags:
Abbreviate, Afk:formatduration without it saying afk because the text usually got way big, so I had just the playername:afktime aaand for better reading I had outlined font.
If there was a way to do that for me with the lua texts, it would be absolutely perfect!
Is LUA Texts supposed to have the same features that DogTags has or is it meant to be a slimmed down text module? If it's going to have all the same function/features etc... wouldn't it suffer from the same performance problem DogTags has?
if we want for example PVP with the Duration, do we have to create that first in the LUA, then in the macro ?
Can we shorten the name value so it contains only AFK, pvpduration, DEAD ?
I personally always removed my name on my player frame as I know who I am :)
I tried to suppress the name and keep the AFK but it says error.
Can we add Color to some taggs ?
May be someone who understand better how it works could give us some hints or some example ?
if we want for example PVP with the Duration, do we have to create that first in the LUA, then in the macro ?
Can we shorten the name value so it contains only AFK, pvpduration, DEAD ?
I personally always removed my name on my player frame as I know who I am :)
I tried to suppress the name and keep the AFK but it says error.
Can we add Color to some taggs ?
May be someone who understand better how it works could give us some hints or some example ?
As you probably noticed, in lua (and other C-based languages) generation of string of text has 2 "aspects": the format and variables.
Look at this code (my player name):
if UnitIsAFK(unit) then
return "|cff33cc26%s (AFK)|r",Name(unit)
elseif UnitIsDND(unit) then
return "|cff33cc26%s (DND)|r",Name(unit)
else
return "|cff33cc26%s|r",Name(unit)
end
In " " you have the format, which includes static text (which will always be there) and spaces for entering variables (%s in above example). After format comes variables/functions generating string of text (%s is for strings, %d is for generic numbers etc.. google for it;P), which will fill the spaces you left.
Note that the number of spaces and entered variables MUST match, or you will have an error.
Other characters in my format string are because of WoW color formatting system. Basically it looks like this:
|c<alpha><red><green><blue><YOUR_TEXT>|r
Note that if you want to have default (white) text color, you just type the text;P
UnitIsAFK(unit) and UnitIsDND(unit) are lua functions that return 1 (true) or nil (false) depending of "unit"'s state (in this case it's player).
So basically in this example it shows green "Garaddon (AFK)" if i'm afk, "Garaddon (DND)" if i'm dnd and "Garaddon" if i'm neither afk nor dnd. (Garaddon is my char name;P)
Is LUA Texts supposed to have the same features that DogTags has or is it meant to be a slimmed down text module? If it's going to have all the same function/features etc... wouldn't it suffer from the same performance problem DogTags has?
It doesn't have anywhere near the same features.
a) It doesn't have a language to parse. It's lua which is parsed by the Lua interpretor. You can't get any better than that because we can't write in anything else.
b) It uses SetFormattedText to put the text on the FontStrings. This eliminates a lot of garbage that DogTags produces.
c) A lot of tags in DogTags are built on other tags. Sometimes it gets really really bad where a tag is built on a tag. Code reuse is good for programmers but it causes the following problem with Lua. Lua has a
pretty annoying method of dealing with memory for strings:
string = string .. "soemthing"
Doesn't simply add the text something to whatever was in string. It actually destroys the original string and produces a new one. As a result anytime you use string.format() or concat stuff you're producing a new string and the old stuff ends up needing to be garbage collected.
Those tags bulit upon tags do that a lot.
d) A lot of tags ended up calling Blizzard API's multiple times to asking for the same question even something simple like this:
[HP] [MaxHP] [PercentHP]
actually asked for the current HP (UnitHealth) and MaxHP (UnitHealthMax) twice because PercentHP actually calls HP and PercentHP to get the data that you already have. If you look at the presets you'll see we don't do that we store the value in a variable.
e) It's written with PB4 in mind. DogTags is a generalized library. There are times I know PB4 is going to force an update on my FontStrings in reaction to something happening. DogTags doesn't know that and can never rely on it because it has to work for a lot of other addons. Knowing that means I can more intelligently chose when to update.
f) It includes a lot of the performance tricks we've learned. For example DogTags blindly updates mana bars for smooth updates. LuaTexts caches the power and avoids updating the text if it isn't changed. This is especially noticeable if you're standing around town.
g) The events that trigger updates in DogTags are built off all the tags the text uses. LuaTexts requires a person to figure out when to update. This pushes this workload out of run time and to configuration time.
I had two goals in mind when I wrote this:
1) Performance. I wanted it to run well.
2) Replace DogTags for users who used the preset tags.
It's not intended to be as easy to customize. DogTags was really great for that. But that ease comes with a cost.
How does this new text handle with more advanced stuff like multi step if/then/else functions?
It's flat out Lua so you can nest and do whatever you want. Take a look at the default text you'll see some places where I had multi levels if then else.
Is there a chance for some reference sheet of custom functions in lua module?
Reverse engineering from built-in sample texts is a bit tough;P
For now could anyone help me with checking if unit is in combat and retrieving reaction colors?;P
I have strange feeling that we have to implement all DogTag colors from scratch now ><
I intend to build a page, hopefully today, with some documentation. You can take a look at the ScriptEnv.lua file for stuff that's available for now.
You probably want HostileColors() for reaction colors. Keep in mind it while it shares a name with the DogTag it doesn't behave the same way. Take a look at the default Name texts to see how to use it.
It's flat out Lua so you can nest and do whatever you want. Take a look at the default text you'll see some places where I had multi levels if then else.
Will have to try an wrap my head around it, unf i suck at lua :/
But i really need to get rid of dogtags.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
This design should produce significantly less garbage than DogTags does, run faster than dogtags since it has no need for a parser. However, this comes at the cost of ease of configurability. While it can pretty much do anything including things that DogTags can't do. It's going to be much more difficult to make it do things that seem simple in DogTags.
However, the goal here is to provide performance improvements for people that primarily only use built in tags with the current DogTagTexts. If you're a heavy user of DogTags you probably won't like it. If all you ever did was select prebuilt tags you'll probably think it's swimmingly better.
Actually the code is exposed to edit in the config UI. Similar to how DogTags are exposed. The only difference is you have to manage your own events that are needed to trigger updates (there's a dropdown boxes with a list of events you can check to turn on updates from) and another checkbox to turn on fast updates for things like the PowerBar on player and pet frames.
Most people will just want to ignore the event drop down and the code box and select stuff from the drop down list of already written codes.
For all practical purposes this is a rewrite of LibDogTag without the language that requires parsing and using raw Lua instead. I have included a special environment each script gets and am writing some functions that replace some of the features of DogTags. For example Name - Long looks like so:
The first return is the format string to put together the text and everything after that is a value that goes in. Level(unit), AFK(unit) and DND(unit) were functions I wrote that essentially replace the [Level] [AFK] and [DND] tags in LibDogTag.
Anyway to directly answer your question, you won't need to duplicate the module.
That is the coolest thing I have possibly ever heard. This is going to hands down make Pitbull 4 the best thing since sliced bread! Thanks for working on it.
I can't wait for this. I see applications far beyond PitBull4 though. I know lots of people are lamenting the DogTag-related issues with CowTip, for instance. Imagine a tooltip addon that uses LuaTexts! Hot! We could even have LDB tickers that show us exactly what we want to see. Mmmmm.
Ohh I should note, the module is disabled by default. If you're looking to switch probably the most logical thing to do is to disable DogTagTexts and load LuaTexts. If you're running embeded all you should need to do to prevent LibDogTag from being load is to reload your ui. Unless of course you're running some other mod that needs it or you have it separately installed.
My limited testing earlier tonight showed a 10 fps improvement over DogTagTexts in Ulduar. YMMV. Bugs are likely to abound.
Just to be clear, I didn't write this to be a generalized text provider. It's pretty much designed to be attached at the hip to PitBull4. Separating it out to be a separate library is going to probably add some overhead.
It's missing the load.xml file to make it load. Easy enough to just copy from another module and edit though. Checking this awesomeness out now!
UPDATE: This is really really complicated. :) I don't think I can replace all my DogTags in the 20 minutes before my raid. LOL! It'll be worth it later though.
Some of the complexity of the provided codes is that I'm avoiding doing concatentation or string formatting and trying to pass it all through to SetFormattedText(). The reason for this is if SetFormattedText does it then no garbage is produced, since it's done by the C++ code of WoW rather than Lua. The function was added specifically to help us avoid churning memory.
You can write a heck of a lot simpler looking stuff without that constraint.
That said, I avoided adding conveience functions that would encourage you to do that. This module is really about performance. Not about easy tinkering.
Reverse engineering from built-in sample texts is a bit tough;P
For now could anyone help me with checking if unit is in combat and retrieving reaction colors?;P
I have strange feeling that we have to implement all DogTag colors from scratch now ><
Maybe if anyone has time, I would be interested in 3 things I used to do with the dogtags:
Abbreviate, Afk:formatduration without it saying afk because the text usually got way big, so I had just the playername:afktime aaand for better reading I had outlined font.
If there was a way to do that for me with the lua texts, it would be absolutely perfect!
Can we shorten the name value so it contains only AFK, pvpduration, DEAD ?
I personally always removed my name on my player frame as I know who I am :)
I tried to suppress the name and keep the AFK but it says error.
Can we add Color to some taggs ?
May be someone who understand better how it works could give us some hints or some example ?
As you probably noticed, in lua (and other C-based languages) generation of string of text has 2 "aspects": the format and variables.
Look at this code (my player name):
In " " you have the format, which includes static text (which will always be there) and spaces for entering variables (%s in above example). After format comes variables/functions generating string of text (%s is for strings, %d is for generic numbers etc.. google for it;P), which will fill the spaces you left.
Note that the number of spaces and entered variables MUST match, or you will have an error.
Other characters in my format string are because of WoW color formatting system. Basically it looks like this:
|c<alpha><red><green><blue><YOUR_TEXT>|r
Note that if you want to have default (white) text color, you just type the text;P
UnitIsAFK(unit) and UnitIsDND(unit) are lua functions that return 1 (true) or nil (false) depending of "unit"'s state (in this case it's player).
So basically in this example it shows green "Garaddon (AFK)" if i'm afk, "Garaddon (DND)" if i'm dnd and "Garaddon" if i'm neither afk nor dnd. (Garaddon is my char name;P)
For other WoW functions look there: http://www.wowwiki.com/World_of_Warcraft_API and keep trying. It's the best way to learn;P
edit: sorry for wall-of-text XD
It doesn't have anywhere near the same features.
a) It doesn't have a language to parse. It's lua which is parsed by the Lua interpretor. You can't get any better than that because we can't write in anything else.
b) It uses SetFormattedText to put the text on the FontStrings. This eliminates a lot of garbage that DogTags produces.
c) A lot of tags in DogTags are built on other tags. Sometimes it gets really really bad where a tag is built on a tag. Code reuse is good for programmers but it causes the following problem with Lua. Lua has a
pretty annoying method of dealing with memory for strings:
string = string .. "soemthing"
Doesn't simply add the text something to whatever was in string. It actually destroys the original string and produces a new one. As a result anytime you use string.format() or concat stuff you're producing a new string and the old stuff ends up needing to be garbage collected.
Those tags bulit upon tags do that a lot.
d) A lot of tags ended up calling Blizzard API's multiple times to asking for the same question even something simple like this:
[HP] [MaxHP] [PercentHP]
actually asked for the current HP (UnitHealth) and MaxHP (UnitHealthMax) twice because PercentHP actually calls HP and PercentHP to get the data that you already have. If you look at the presets you'll see we don't do that we store the value in a variable.
e) It's written with PB4 in mind. DogTags is a generalized library. There are times I know PB4 is going to force an update on my FontStrings in reaction to something happening. DogTags doesn't know that and can never rely on it because it has to work for a lot of other addons. Knowing that means I can more intelligently chose when to update.
f) It includes a lot of the performance tricks we've learned. For example DogTags blindly updates mana bars for smooth updates. LuaTexts caches the power and avoids updating the text if it isn't changed. This is especially noticeable if you're standing around town.
g) The events that trigger updates in DogTags are built off all the tags the text uses. LuaTexts requires a person to figure out when to update. This pushes this workload out of run time and to configuration time.
I had two goals in mind when I wrote this:
1) Performance. I wanted it to run well.
2) Replace DogTags for users who used the preset tags.
It's not intended to be as easy to customize. DogTags was really great for that. But that ease comes with a cost.
It's flat out Lua so you can nest and do whatever you want. Take a look at the default text you'll see some places where I had multi levels if then else.
I intend to build a page, hopefully today, with some documentation. You can take a look at the ScriptEnv.lua file for stuff that's available for now.
http://www.wowwiki.com/API_UnitAffectingCombat
You probably want HostileColors() for reaction colors. Keep in mind it while it shares a name with the DogTag it doesn't behave the same way. Take a look at the default Name texts to see how to use it.
Will have to try an wrap my head around it, unf i suck at lua :/
But i really need to get rid of dogtags.