From the screenshot, I can't tell which part of it you're referring to - what is "this", and what overlay are you referring to?
I'm talking about the pink text. That's from an outside program that monitors my GPU stats. It's an overlay. It's supposed to be down in the bottom left hand corner. But some frames cause it to move around.
WoW addons have no control over (or even awareness of) video overlays from other programs, so there's no way any addon is moving your GPU overay. The only thing an addon can do is move the tooltip.
WoW addons have no control over (or even awareness of) video overlays from other programs, so there's no way any addon is moving your GPU overay. The only thing an addon can do is move the tooltip.
Something about the frame is causing the overlay to move. I wasn't suggesting that the addon was moving the overlay. It's just something about the frame. There are other frames that cause this as well. It's moving the overlay to the bottom left corner of the frame instead of the entire screen I think.
To give you an idea how this is designed, here are the basics.
LibCore takes the configuration and builds the layouts and widgets from that. You provide this library with an LCD. So far there is LibLCDText for character displays.. A graphical LCD can be written easily. You just provide a means to draw on a surface, via a driver. Right now there's the LibQtip driver. Your LCD should have a blit function that calls your driver's real blit. The character displays only update the portions of the display framebuffer that have changed, and passes that data and coordinates to your driver's real blit function.
Plugins are simple. For the most part in your scripts you can use _G to access WoW's global environment, but you can provide special wrappers through plugins. PluginResourceTools is a good example of a custom plugin. It keeps track of your memory and cpu usage:
local mem, percent, memdiff, totalMem, totaldiff = GetMemUsage("StarTip")
Through layering you can draw animations or whatever on top of other frame buffers. LibLCDText (and other LCD libraries, such as the graphical display I mentioned) takes care of these details. You tell the library how many layers you want, and a frame buffer is created for each layer. The character displays use a space character as the transparency channel. Graphical displays can use actual opacity for this, alpha blending the pixels. Honestly I'm not sure if graphical displays are very feasible. I filled a character LCD bufffer with 256x64 cells, and it killed WoW. They are likely only usable for drawing small icons or something. I'm rather disappointed in that.
Layouts describe a LCD display. Here is where you tell LibCore where to put what widget, and on what layer. You also tell it what kind of transition you want, if any. Character displays have left, right, both (every other line goes left, the rest go right), up and down transitions. That's also taken care of by the LCD library. LibCore deals with looking into your configuration and passing your transition information (what kind of transition - up, down, etc..) to your LCD, and provides the related timers, starting and stopping them as needed. All the LCD library does is deal with the actual buffers and tells LibCore when the transition is finished.
Widgets provide data only. For instance, bar widgets provide a percentage, and the LCD does the actual drawing. This characteristic of only providing data allows widgets to be used in all sorts of situations. For example, you can use a bar widget to provide data for a progress bar. The only requirement is a LibCore object and a callback that does the actual progress bar updating.
Edit: Actually, you can provide a widget with a generic core object. All the widget wants is a LibCFG object and an environment. I might write a LibCoreLight or something.
I'm dealing with an ethical question. At first I didn't want to let people pass scripts via addon coms. Now I'm thinking it would be a really cool idea. Then I said well maybe in a way so you restrict whom you can receive code from. So for instance, a raid leader could pass a piece of code to your addon, and your small addon executes that code. The only one that needs a large addon with all the boss mods is the raid leader. That was cool, since there's some restrictions. However, I'm at a point where I want to make it an option to allow anybody at all that you trust. You could even set whom you trust to everybody. Someone can send you entire displays. You could even have a conversation over it, established _and_ coded by one party only. The people who are not familiar with writing stuff can enjoy other people's stuff. A person could set a cool little signature as mouseover communication. Someone mouses over you, and you receive their personalized signature, in the form of a display. Or they see your personalized signature.
... for instance, a raid leader could pass a piece of code to your addon, and your small addon executes that code. The only one that needs a large addon with all the boss mods is the raid leader.
There have already been several attempts at boss mods of this type, and none of them have gained any significant userbase. If you're already going through the effort of getting your raiders to install an addon, why not just get them to actually install the addon you want them to have (the boss mod) instead of adding in a "middleman" (the addon that lets you send them the boss mod in-game)?
There have already been several attempts at boss mods of this type, and none of them have gained any significant userbase. If you're already going through the effort of getting your raiders to install an addon, why not just get them to actually install the addon you want them to have (the boss mod) instead of adding in a "middleman" (the addon that lets you send them the boss mod in-game)?
I think I caused some confusion. You're not sending raw code. You're sending display information, which includes code. And the whole point of this library is to get other people programming, so I'm thinking in terms of the library's programmer base. This isn't an addon as a middle man; it's a library.
Honestly I'm not sure if one individual person can send out that much traffic to make any of it useful to a boss mod. That is one of the reasons I posted here, but I failed to mention it. And honestly, I'm not writing a boss mod. I want others to use the code. It's a library; it's a library; it's a library.
Yeah, so I was thinking about it. Maybe that's not such a great idea after all. I agree. Still, though, the personalized signatures are pretty cool. :)
Why do some people here try to prevent libraries from being written? The community scrutinizes some new libraries like it's a matter of life and death. Is it really just that you think StarLibs are a bad idea or is there something specifically wrong about them.
The LCD4WoW demonstration was tainted by its own polling of its memory and cpu resources. I've written an addon named ResourceServer that does the polling for the calling addon. That way you can display your own addon's memory without tainting the information. Of course it's a development tool. It calls those resource functions for every addon once every second. I wouldn't install it with an addon in other words. :) Unless you just want to see the usage in your own addons personally. Some people may. As long as ResourceServer:New(environment) is called you have access to environment.GetMemUsage and environment.GetCPUUsage. They each provide 5 return values: cpu, percent, cpudiff, totalCPU, totaldiff = GetCPUUsage("StarTip") --
Here's an example:
cpu, percent,cpudiff, totalCpu, totaldiff = GetMemUsage("StarTip")
if cpu then
if totaldiff == 0 then totaldiff = .001 end
return '--------' .. format("%.2f", cpudiff / totaldiff * 100) .. "%" .. "-------"
end
I wrote this using StarLibs' resources plugin, so it's become useful to me as a library. What's the big deal over me wanting to write it as a library? I'm also writing LCD4WoW, the almost full implementation of LCDControl plus more.
welcome to wowace, ever sense the move to the curseforge system we've been more critical about libs due to the new attitude of how the CF system works with externals / embeds.
Also, back on the old system there where a lot of useless libs that maybe 1 or 2 addons used overall and thus overall bloat. (re: AlarLib, sadly no longer accessible.)
I can respect that. It's just super convenient having all of this as a library. I want to actually release StarTip sometime soon. I can work on LCD4WoW as a development board till there's something worthy of polishing up.
Ah I see :) Well, StarLib can be used in pieces if you write your own core object. You don't need the core object for mere plugins though. ResourceServer only uses the StarLibPluginResourceTools library.
Now honestly I didn't want to write a library. I _hate_ keeping something backward compatible.
I got it. You place filters on shared scripts so you sort of sandbox even further the execution, so you can remove things like _G that's available in the execution environment. It's probably best to have it as a white list, allowing more and more depending on the trust factor.
You can define special characters that are 7x8 large fonts more less. If you've ever seen the icons in that gif I linked, the hearts, lightning bolts, etc... then you know what a special character is. :) Character displays are usually limited to around 8 special characters. You can draw 32x32 sized images in that space. :) We have unlimited special characters. You can draw what you want, and it's not that heavy. Shown in the image is a 1x20 display. Running that took about 1.4% CPU time and the name's pingpong scrolling the width of the display. I wouldn't get too big with them. I don't think I'll be doing graphical displays, since they'll only be usable at really small sizes.
And did I say you'll be able to send these displays to friends? You can send a rose to your sweet heart. Oh and it's all layered, so you can draw a background for your rose. Or a scrolling message on top of it. :)
Edit: Oh and did I also say this is completely open source? I don't want anyone asking if they can have permission to borrow code. I borrowed from open source to get here.
I've come to the conclusion that this is mere eye candy. Its usefulness is in displaying fancy and scriptable information. It's more of a social tool than a raid tool. It's social hacking. I'm going to make socializing scriptable. What do you need framerates for when you're shooting the hey with your WoW friends.
Why do some people here try to prevent libraries from being written? The community scrutinizes some new libraries like it's a matter of life and death. Is it really just that you think StarLibs are a bad idea or is there something specifically wrong about them.
The general feeling about libraries (around here, at least) is that if the code is likely to be used only by one addon, or even only by one addon installed on a typical user's system, it shouldn't be a library, it should just be written into the addon. For example, a user almost certainly wouldn't be running both Gatherer and GatherMate, so there's no point in factoring out the common code into a library, and you wouldn't find much support for such a library.
Well, I've used this library in 3 addons now, and I have plans to enhance AuraAlarm's interface with it, so good stuff. I'm going to turn AuraAlarm into a single pixel graphical LCD, and scriptable, so you can create any sort of visual alarm you want. :)
Large DriverCharacter displays take a little while to load. There's a demo of a 30x6 sized display in v1.1.2b of LCD4WoW if you want to see how long. You can load it in-game if you use StarTip and enable the LCD module. Otherwise LCD4WoW will load it at load time.
I'll definitely need to allow someone to set limits for the DriverCharacter displays, and they'll need to see an incoming display's size before accepting the it. Maybe even some hard limits. It's nothing like Auctioneer's fast search feature, but it takes a little time. Small ones like the Artardery one load in a snap. A 30x2 display loads in about 2 seconds. The QTipDriver displays on the other hand load real fast, even the 30x6 display. I imagine it can handle larger than that, although I don't know why you'd need one so large. Maybe for ASCII art.
Edit: Of course I can just recycle frames after they're first created, so later ones won't take so long. And I can write some code to predict when something may load soon, so start creating frames silently.
Edit2: Try 1.1.5b for a smaller demo. You might need to enable the character display. /lcd4wow or /startip
I'm talking about the pink text. That's from an outside program that monitors my GPU stats. It's an overlay. It's supposed to be down in the bottom left hand corner. But some frames cause it to move around.
Something about the frame is causing the overlay to move. I wasn't suggesting that the addon was moving the overlay. It's just something about the frame. There are other frames that cause this as well. It's moving the overlay to the bottom left corner of the frame instead of the entire screen I think.
I just added the driver for LibQTip. It looks ok, but could use different fonts. I'm using the default game tooltip font with MONOCHROME specified.
Marquees are behaving better.
LibCore takes the configuration and builds the layouts and widgets from that. You provide this library with an LCD. So far there is LibLCDText for character displays.. A graphical LCD can be written easily. You just provide a means to draw on a surface, via a driver. Right now there's the LibQtip driver. Your LCD should have a blit function that calls your driver's real blit. The character displays only update the portions of the display framebuffer that have changed, and passes that data and coordinates to your driver's real blit function.
Plugins are simple. For the most part in your scripts you can use _G to access WoW's global environment, but you can provide special wrappers through plugins. PluginResourceTools is a good example of a custom plugin. It keeps track of your memory and cpu usage:
local mem, percent, memdiff, totalMem, totaldiff = GetMemUsage("StarTip")Through layering you can draw animations or whatever on top of other frame buffers. LibLCDText (and other LCD libraries, such as the graphical display I mentioned) takes care of these details. You tell the library how many layers you want, and a frame buffer is created for each layer. The character displays use a space character as the transparency channel. Graphical displays can use actual opacity for this, alpha blending the pixels. Honestly I'm not sure if graphical displays are very feasible. I filled a character LCD bufffer with 256x64 cells, and it killed WoW. They are likely only usable for drawing small icons or something. I'm rather disappointed in that.
Layouts describe a LCD display. Here is where you tell LibCore where to put what widget, and on what layer. You also tell it what kind of transition you want, if any. Character displays have left, right, both (every other line goes left, the rest go right), up and down transitions. That's also taken care of by the LCD library. LibCore deals with looking into your configuration and passing your transition information (what kind of transition - up, down, etc..) to your LCD, and provides the related timers, starting and stopping them as needed. All the LCD library does is deal with the actual buffers and tells LibCore when the transition is finished.
Widgets provide data only. For instance, bar widgets provide a percentage, and the LCD does the actual drawing. This characteristic of only providing data allows widgets to be used in all sorts of situations. For example, you can use a bar widget to provide data for a progress bar. The only requirement is a LibCore object and a callback that does the actual progress bar updating.
Edit: Actually, you can provide a widget with a generic core object. All the widget wants is a LibCFG object and an environment. I might write a LibCoreLight or something.
There have already been several attempts at boss mods of this type, and none of them have gained any significant userbase. If you're already going through the effort of getting your raiders to install an addon, why not just get them to actually install the addon you want them to have (the boss mod) instead of adding in a "middleman" (the addon that lets you send them the boss mod in-game)?
I think I caused some confusion. You're not sending raw code. You're sending display information, which includes code. And the whole point of this library is to get other people programming, so I'm thinking in terms of the library's programmer base. This isn't an addon as a middle man; it's a library.
Honestly I'm not sure if one individual person can send out that much traffic to make any of it useful to a boss mod. That is one of the reasons I posted here, but I failed to mention it. And honestly, I'm not writing a boss mod. I want others to use the code. It's a library; it's a library; it's a library.
The LCD4WoW demonstration was tainted by its own polling of its memory and cpu resources. I've written an addon named ResourceServer that does the polling for the calling addon. That way you can display your own addon's memory without tainting the information. Of course it's a development tool. It calls those resource functions for every addon once every second. I wouldn't install it with an addon in other words. :) Unless you just want to see the usage in your own addons personally. Some people may. As long as ResourceServer:New(environment) is called you have access to environment.GetMemUsage and environment.GetCPUUsage. They each provide 5 return values: cpu, percent, cpudiff, totalCPU, totaldiff = GetCPUUsage("StarTip") --
Here's an example:
cpu, percent,cpudiff, totalCpu, totaldiff = GetMemUsage("StarTip") if cpu then if totaldiff == 0 then totaldiff = .001 end return '--------' .. format("%.2f", cpudiff / totaldiff * 100) .. "%" .. "-------" endI wrote this using StarLibs' resources plugin, so it's become useful to me as a library. What's the big deal over me wanting to write it as a library? I'm also writing LCD4WoW, the almost full implementation of LCDControl plus more.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAlso, back on the old system there where a lot of useless libs that maybe 1 or 2 addons used overall and thus overall bloat. (re: AlarLib, sadly no longer accessible.)
Why's AlarLib no longer available?
-
View User Profile
-
View Posts
-
Send Message
Curse Premium"Oh let me count the ways ....."
Think Ace2/3 Wrapper + customizations & Bloat..
Now honestly I didn't want to write a library. I _hate_ keeping something backward compatible.
You can define special characters that are 7x8 large fonts more less. If you've ever seen the icons in that gif I linked, the hearts, lightning bolts, etc... then you know what a special character is. :) Character displays are usually limited to around 8 special characters. You can draw 32x32 sized images in that space. :) We have unlimited special characters. You can draw what you want, and it's not that heavy. Shown in the image is a 1x20 display. Running that took about 1.4% CPU time and the name's pingpong scrolling the width of the display. I wouldn't get too big with them. I don't think I'll be doing graphical displays, since they'll only be usable at really small sizes.
And did I say you'll be able to send these displays to friends? You can send a rose to your sweet heart. Oh and it's all layered, so you can draw a background for your rose. Or a scrolling message on top of it. :)
Edit: Oh and did I also say this is completely open source? I don't want anyone asking if they can have permission to borrow code. I borrowed from open source to get here.
The general feeling about libraries (around here, at least) is that if the code is likely to be used only by one addon, or even only by one addon installed on a typical user's system, it shouldn't be a library, it should just be written into the addon. For example, a user almost certainly wouldn't be running both Gatherer and GatherMate, so there's no point in factoring out the common code into a library, and you wouldn't find much support for such a library.
I'll definitely need to allow someone to set limits for the DriverCharacter displays, and they'll need to see an incoming display's size before accepting the it. Maybe even some hard limits. It's nothing like Auctioneer's fast search feature, but it takes a little time. Small ones like the Artardery one load in a snap. A 30x2 display loads in about 2 seconds. The QTipDriver displays on the other hand load real fast, even the 30x6 display. I imagine it can handle larger than that, although I don't know why you'd need one so large. Maybe for ASCII art.
Edit: Of course I can just recycle frames after they're first created, so later ones won't take so long. And I can write some code to predict when something may load soon, so start creating frames silently.
Edit2: Try 1.1.5b for a smaller demo. You might need to enable the character display. /lcd4wow or /startip