I just double-checked the code, it only ever plays sounds if a role you have checked goes from unavailable to available. Are you sure it's LFG Call to Arms Broker that's doing the beeping?
this is wonderful! i have been dying for an addon that does this. my only question is: is there a way to disable the "tank" role showing up on characters that can't tank? my main is a priest, so i'd only be eligible for healing and dps, but i can't seem to turn off the tank option.
when i go to the configuration, the "tank" checkbox is greyed out and i can't click it, but it appears to be defaulted to 'on,' and therefore i always have a little symbol tricking me on my titan panel, haha.
i'd glance around the lua but i'm scared of messing something up. ): thanks for any help you can provide!
What version of LFG Call to Arms Broker were you using? v0.9.4 made all those checkboxes enabled, even if you couldn't use the particular role, and that was released back in July.
Does not show even with Zidomo's fix ; no LUA errors. Clean interface folder, no other addon but yours. ... and I don't want fubar nor titan panel... => Deleted.
Yah, LibDataBroker (LDB) mods such as this sometimes don't include the option for a minimap icon. Requires a bit of code as well as usage of the LibDBIcon-1.0 library (or something else). Many do, but this one doesn't.
So have to get a LDB display if you want to use it. Most other mods like this that report dungeon status are also LDB mods.
As they both are block-type LDB displays, you will not have a giant bar across your screen like FuBar or Titan for just a single mod. And they both don't use much computer memory or any CPU time.
As to the old problem with the embeds.xml file, its still present in the latest alpha v0.9.1-1-g5f88562 on WowAce released today. I posted a comment on my earlier ticket urging the author to fix it. For some reason he made the repository private, so no one other than him can put in fixes. I would have done it by now if it was public as most mods are.
I'm sorry about not seeing your comment earlier. I assumed Curse/WowAce would email me when there's activity on my project, but they don't, so I didn't see the ticket/comment until now.
As for the private thing, I don't understand why most mods are public. Unless you're willing to babysit your mod to make sure nobody screws around with, it seems like a great way for someone else to come along and wreck your work.
As soon as v1.0 shows up here in Curse, that will have a minimap icon. It uses a new icon (satchel of exotic mysteries), and it shows desaturated when there is no CtA and full-color when there is. If you want any more changes, please file a ticket.
On WowAce at least, "public" access isn't as open as you fear. As per when I signed up years ago there, people can only get SVN/GIT access to projects set as "open" by the primary project author(s) by being approved first. They have to specifically request such access to open repos in an email to the WowAce admins. Also, people requesting access to open repos can not in fact tag release versions. Any changes they make will only be seen as alphas, thus won't be seen on the main Curse site. This pretty much eliminates any troublemakers.
In the many years (6) since I first signed up on WowAce, I have not seen a single malicious act done to any mod that I can remember. As to people making incompetent changes to various open repos, I can recall just a single incident in 6 years. A mod translator decided to update the TOC interface version of a number of mods after the first expansion (Burning Crusade) hit. He was messaged to come into IRC chat to discuss this with the site admins. He never did. His open repo access was quickly removed and admins set all the TOCs back.
That single incident in 6 years is the extent of any problems I've seen and it was a problem quickly resolved. I've seen far (far) more issues with authors abandoning or not updating mods and -- with closed repos -- competent people being unable to make updates to such mods to keep them working over WoW patches. So they either adopt them as "fan updates" and put them out themselves or (far more frequently) the mods are left to die and be forgotten.
So its really not a problem. Open repos mean competent people can help support your mod when you are unable/unwilling to. Its one of the reasons why the vast majority of them are open. As well as the intrinsic nature of UI mod development (open source, etc.; you can attach any license you want to a mod) and so on.
I'll consider what you said about making it open. However, it doesn't seem to be the case that you need to be granted access to "open" projects. I certainly never requested such access, and yet I was able to go in and make a change to LibDBIcon myself.
Yah, it was six years ago when I originally signed up on WowAce; it was long before they were taken over by Curse. I had to state specifically why I wanted repo access, what my plans were and so on. May or may not be different now. I know registered authors now for sure do have public repo access. You can't be an author if you don't upload a valid project.
Still, registering as a regular user on Curse or WowAce now (tens to hundreds of thousands of people) is very likely different than being able to gain SVN/GIT access to public repos on WowAce or Curseforge. Worth sending a PM or email to admins on WowAce find out who has access before making a repo open, if you are concerned about things. And I know that if you change your mind about the repo being open, you can change it to closed again.
Good idea. If I can verify precisely what permissions regular users would have (e.g. ensure they can't push a tag, like you said) and who would actually have access, then maybe I will open it up. I'm just used to a development model where people submit patches if they want changes made. One of the reasons I absolutely love GitHub is because it's so trivial to fork a repo, make your changes, and submit them back to the author. And if the author disappears, someone else can step up with their own fork.
Broker2Fubar says "Some addon do not define LDB type at creation. Broker2FuBar does not catch it correctly at this moment. This is worked on." I suspect this is the issue, as LFGCallToArmsBroker defines the type on the line after creation. I'll try changing that, hopefully it will work for you then.
As you've posted another release without addressing the problem in my earlier WowAce ticket (ID #3), will post it here in case you didn't notice it.
The embeds.xml file included with this (with the current v0.9.1 & prior) is bugged and doesn't load the libraries this uses properly.
Due to the fact the listed paths in the file are wrong, the mod either will bug out on client load and fail to work or (if the libraries are loaded by a different mod or disembedded) it will throw errors to the FrameXML.log file, delaying logon.
The file paths written in embeds.xml include the following wrong ones:
I just double-checked the code, it only ever plays sounds if a role you have checked goes from unavailable to available. Are you sure it's LFG Call to Arms Broker that's doing the beeping?
when i go to the configuration, the "tank" checkbox is greyed out and i can't click it, but it appears to be defaulted to 'on,' and therefore i always have a little symbol tricking me on my titan panel, haha.
i'd glance around the lua but i'm scared of messing something up. ): thanks for any help you can provide!
What version of LFG Call to Arms Broker were you using? v0.9.4 made all those checkboxes enabled, even if you couldn't use the particular role, and that was released back in July.
Clean interface folder, no other addon but yours.
... and I don't want fubar nor titan panel...
=> Deleted.
I'm still looking for an addon like this ;)
Sorry Eridius !
But I would really like a minimap icon.. like just a [+] instead of the eye for a healer CTA ^^
So have to get a LDB display if you want to use it. Most other mods like this that report dungeon status are also LDB mods.
Recommended LDB display mods: either StatBlockCore (I use, http://wow.curse.com/downloads/wow-addons/details/stat-block-core.aspx) or Fortress (http://wow.curse.com/downloads/wow-addons/details/fortress.aspx). Or search on Curse, just need one of them. With them, a single "block" appears for each LDB mod you have and you can reposition/resize the block(s) to the size of a minimap icon if you want. Just a single block appears for a single mod; not a lot of difference to having a minimap icon instead.
As they both are block-type LDB displays, you will not have a giant bar across your screen like FuBar or Titan for just a single mod. And they both don't use much computer memory or any CPU time.
As to the old problem with the embeds.xml file, its still present in the latest alpha v0.9.1-1-g5f88562 on WowAce released today. I posted a comment on my earlier ticket urging the author to fix it. For some reason he made the repository private, so no one other than him can put in fixes. I would have done it by now if it was public as most mods are.
As for the private thing, I don't understand why most mods are public. Unless you're willing to babysit your mod to make sure nobody screws around with, it seems like a great way for someone else to come along and wreck your work.
On WowAce at least, "public" access isn't as open as you fear. As per when I signed up years ago there, people can only get SVN/GIT access to projects set as "open" by the primary project author(s) by being approved first. They have to specifically request such access to open repos in an email to the WowAce admins. Also, people requesting access to open repos can not in fact tag release versions. Any changes they make will only be seen as alphas, thus won't be seen on the main Curse site. This pretty much eliminates any troublemakers.
In the many years (6) since I first signed up on WowAce, I have not seen a single malicious act done to any mod that I can remember. As to people making incompetent changes to various open repos, I can recall just a single incident in 6 years. A mod translator decided to update the TOC interface version of a number of mods after the first expansion (Burning Crusade) hit. He was messaged to come into IRC chat to discuss this with the site admins. He never did. His open repo access was quickly removed and admins set all the TOCs back.
That single incident in 6 years is the extent of any problems I've seen and it was a problem quickly resolved. I've seen far (far) more issues with authors abandoning or not updating mods and -- with closed repos -- competent people being unable to make updates to such mods to keep them working over WoW patches. So they either adopt them as "fan updates" and put them out themselves or (far more frequently) the mods are left to die and be forgotten.
So its really not a problem. Open repos mean competent people can help support your mod when you are unable/unwilling to. Its one of the reasons why the vast majority of them are open. As well as the intrinsic nature of UI mod development (open source, etc.; you can attach any license you want to a mod) and so on.
Anyway, thanks again.
Yah, it was six years ago when I originally signed up on WowAce; it was long before they were taken over by Curse. I had to state specifically why I wanted repo access, what my plans were and so on. May or may not be different now. I know registered authors now for sure do have public repo access. You can't be an author if you don't upload a valid project.
Still, registering as a regular user on Curse or WowAce now (tens to hundreds of thousands of people) is very likely different than being able to gain SVN/GIT access to public repos on WowAce or Curseforge. Worth sending a PM or email to admins on WowAce find out who has access before making a repo open, if you are concerned about things. And I know that if you change your mind about the repo being open, you can change it to closed again.
The embeds.xml file included with this (with the current v0.9.1 & prior) is bugged and doesn't load the libraries this uses properly.
Due to the fact the listed paths in the file are wrong, the mod either will bug out on client load and fail to work or (if the libraries are loaded by a different mod or disembedded) it will throw errors to the FrameXML.log file, delaying logon.
The file paths written in embeds.xml include the following wrong ones:
<Include file="libs\Ace3-AceAddon\AceAddon-3.0.xml" />
<Include file="libs\Ace3-AceEvent\AceEvent-3.0.xml" />
<Include File="libs\Ace3-AceTimer\AceTimer-3.0.xml" />
The above in the file needs to be changed to the following to work properly:
<Include file="libs\AceAddon-3.0\AceAddon-3.0.xml" />
<Include file="libs\AceEvent-3.0\AceEvent-3.0.xml" />
<Include File="libs\AceTimer-3.0\AceTimer-3.0.xml" />