Hey Addon Authors -
I am starting up an addon and plan to host it on wowace. I figured I'd start using git, too, 'cause all my friends make fun of me for preferring svn. So, I have done the "Create Addon" thing, it's awaiting approval, but I was able to edit the repository, pick git, and get a git link.
However, when I try to clone the git development line to my local machine so I can do work, I get a "Permission denied (publickey). The remote end hung up unexpectedly" error. I am guessing I am missing something! But I have no idea what, so I figured I'd ask around here for some help getting the details worked out.
- Registered User
Member for 16 years and 13 days
Last active Fri, Oct, 4 2013 21:29:42
- 0 Followers
- 425 Total Posts
- 0 Thanks
Aug 19, 2010I've been raid-leadering and main-tanking a lot lately. Until a few months ago, I was always a healer, and Grid was always exactly what I wanted. Default Grid provided 90% of what I wanted, if not everything I wanted.Posted in: Grid & Grid2
Now, however, I am paladin tanking and/or raid-leadering, and there's information I want that is not available. I have written mods in the past, and am considering writing these Statuses, but I'd rather do that for Grid2, and honestly, I'd rather not write them at all, as I often get bored and stop updating/maintaining, so I'm here to make my arguments for why they should be default Grid statuses.
The basic idea here is that not everyone needs the same information. Most healer classes are pretty well represented with Grid, but nobody else has really been considered. DPSers dps, tanks tank, raid leaders read wowwiki. None of them need Grid.
Now, I think DPSers still do not need Grid, except for decursing, which works fine.
But as a tank, there's a number of somewhat important threat-related and agro-related pieces of information I'd like, which I can't get with Grid.
First off, there's a distinction between "has agro" and "is targeted" -- lots of bosses to off-target stuff. Healers, in my mind, should want "is targeted" since it would give them a headsup about who will get hit soon. Tanks, on the other hand, couldn't care less if their well-tanked mob does an off-target attack, and if they waste a taunt on that, they will be sad. lowered overall threat due to wasted GCDs, and no taunt if it's needed soon.
Next, there's a distinction between "is currently targeted by a mob/has agro" and "is currently targeting a mob that is not targeting the tank." See, I use Clique. And honestly, even if I didn't, I have two ways to get agro off my healer. I can do an aoe taunt or righteously defend them (easy with clique/grid), or I can taunt the mob. In order to taunt the mob, I have to find it. What's the best way to find it? Well, Grid already sees it, so obviously someone in my raid is targeting it. How about a status for that, so I can clique-taunt that person's target, or at least click them then assist them to find the mob quickly.
Third is the "you're not tanking fast enough" indicator. This one might exist, honestly, but I don't think so? I can check the threat level of every raid member against my current target. I'd like a "high threat" light. Like "low mana," I'd set a threshold like 80% and if anyone is above 80% threat on my target. Then I know I need to either hand of salvation them, use my cooldown-threat-gen stuff, or stop watching tv (obviously, a last resort).
Along similar lines, I'd actually like a separate indicator stating "has above X% on THEIR target" -- since often times in pugs, some idiot is on the warrior when I assume everyone is on the priest, so they can easily out-threat my aoe threat with single-target damage. However, it's an important disinction that they are gaining threat on a target I am not on right now.
The next "tanking" specific idea I have is the concept of "is likely to have agro" -- I'd like a separate status I can assign/color which says "recently had agro from a mob you moused over but do not currently have access to so we can't be sure". "recently" could be a setting or whatever. You could expand this and make it much more intelligent. You could include "recently had agro from a mob someone in your group targeted" or any other sources of information we're willing to exploit. Even combat log parsing. "Was recently hit by a mob who has not died or hit someone else since, and who we do not have current target information about" -- so if someone other than the tank gets hit and the tank doesn't get hit by that same mob very quickly afterward, a light would be on that person, indicating that they might have agro. Clearly, this idea is more about what level of attention you should be paying to finding hostile mobs, rather than absolute information.
The last one I put in this category is another combat-log one. The idea for this status is "we probably pulled another group, or mobs were added to the fight." Sometimes you expect this and don't care, sometimes this is really important. Basically, "read combat logs. If a mob who WAS NOT INVOLVED IN THE FIGHT BEFORE (by unique unitid) hits someone who IS NOT THE TANK, put a light on them until the tank gets them. Clearly, this would require knowing who the tank is, but in random dungeons that's easy, and in raids there's maintank settings, so this could be easily maintained.
Next up are the "raid leader" type statuses I think would be useful. Other than "has enough mana" or "said they were ready" which probably already exist, mine are more about "who is targeting what" -- which as a raid leader, I find very important. Knowing who is not doing their job is a hard thing to figure out, but I think Grid could do wonders to assist that.
So, the first ones are all the basic information about what someone is targeting (not all of it is really useful, but if you're doing these statuses, might as well be complete, in case someone really wants the information):
* Player's target is friendly/hostile/neutral/human/npc/in combat -- the basics. None particularly useful, but information some people might like.
* Player's target is my target/main assist's target/main tank's target/OTHER -- these statuses would let me get lights for 'dude is on the wrong target' pretty easily. Very useful as a raid leader, somewhat useful as a tank.
* Player's target is not in combat (with our group?) -- a lovely light that would show me who's about to add a second group! :)
* Player's target is/is not the <raid icon>.
* The only non-boolean status I have in my lists: Player's target's raid icon. So, I could see a little skull somewhere. This one would likely require a new indicator, since you wouldn't want a giant skull in the center icon indicator, probably want a side-icon-indicator or something. Maybe Grid2 already plans that sort of thing, I dunno. But I'd love to see 12 skulls and two red x's and know exactly who is doing this wrong. :)
So, I guess there's two main questions here.
First, what do people think? Do other people support/like these ideas? Do these ideas inspire other, better ideas that I didn't think of?
Second, do the Grid2 authors thing these are good enough/useful enough ideas to include as default Grid Statuses, or would someone else have to develop them (and if the latter, is anyone else interested in developing them, 'cause I am lazy and haven't modded in a long time :) )
Aug 19, 2010I somewhat agree with the poster. I don't have a 5-button mouse, and maybe I have better eyes than you, or a larger monitor, but I could easily click on the default corner indicator lights on my screen with relative accuracy.Posted in: Grid & Grid2
And I play different classes/roles, and memorizing all the different key-combinations for them (or using middle mouse-push on my scrollwheel) are not exactly easy for everyone. I know some people who pick them up instantly, and some people who never do.
If I knew that a light in the top right meant they were diseased and clicking it would cast cleanse, great. I could have Clique do heals on the whole frame, but the top right corner do cleanse, and I would click it if I knew the fight required cleansing and the light was on. (Obviously, it would still cleanse even if the light was off, but I wouldn't be trying to click up there :) )...
Sure, it wouldn't be useful for everyone, but having a "clickable-indicator" could be useful to a number of people.
Aug 19, 2010I didn't see anyone bring up this side of this topic, so I figured I would.Posted in: Grid & Grid2
The argument here seems to be one group of people saying "I want all the information I can get" (a classic scientific/analytic approach to things -- more information can't be worse, right?), with examples like "I have SCT showing me tons of information!" -- arguing against a group of people basically saying "Why? what's the point? I don't need that!"
I have a couple thoughts on this. First off, I'm not actually arguing for or against mana bars (or, side bad indicators with a variety of options!). I'm all for options if people want them, and I find it amazing what kind of useful information people can come up with. I am envisioning side-bar threat meters integrated into Grid, but my following arguments will likely make me change my mind anyway.
The key to Grid, in my mind, from the days when it was just a MSPaint graphic concept in these forums, was that it was about re-thinking the information you need. Normal frames give you all the information -- HP, MP, absolute numbers, percentages, bars, cast bars (another great use for the side bar, for those of us with overpowered machines! :) ), debuffs, buffs, etc. All the information is there. The point of Grid is that it was all about re-thinking what information you *need*, and how it can be best presented. A list of debuffs is all the debuff information I could ever need. However, most of it is useless to me. I don't care if someone has 10 debuffs, I don't care if they have a curse (I can't de-curse), I only care if they have a debuff I can remove. Not only that, I can't parse 5 debuff icons fast enough to accurately see that half my raid has 5+ debuffs, see them all, figure out who has the bad ones, and clique them. In point of fact, the best I can do is see that "oh that guy has a debuff, I should remove it." And hey, there we go, a boolean indicator light. Now I have way less information on my screen, I can maintain it in a compact fashion, and the light popping on is a clear indicator that really sticks out. I could even go further and say "I want a light just for the debuffs I want to get rid of" if a specific fight has 4 debuffs I *can* get rid of, but only one matters, and the fight is particularly hard. The goal is to reduce the information overload, and provide you with exclusively useful information.
I know, I know, humans can ignore information. If you have hundreds of numbers flying around on your screen and you don't even see them, they aren't actually useful. The 90% of them you don't see shouldn't be there, because the best thing they can do is nothing, and the worst is clutter your screen and make you miss something important.
So, for this topic -- the really important idea in my mind is to really stop and think about what information you need.
Are you a raid leader, and want to know if you should pull? Request/write a boolean status called "is ready for combat," and it makes sure tanks have 99% or higher hp, healers have 95% or higher mana, dps has 90% or higher mana, etc. Attach it to a lovely little corner indicator, and just glance and see "oh, everyone's ready but Joe. Oh, Joe, always forgetting to eat your biscuits." Now you have a boolean indicator that actually tells you much more than a bar. With the bar, how are you supposed to tell the difference between 91% and 89%? And if 89% is fine, just lower your values for "is ready for combat."
Are you a druid, and you want to know who to innervate? This is the classic example, and having a boolean "could benefit from innervate" (aka "low mana") should not only be as useful, but moreso. Instead of parsing 25 partially-full mana bars, determining if they are below 30% or not, then trying to find the healers first, and if they are all good, find the dpsers, just use the "low mana" indicator, then you have nothing on your screen unless someone needs something. You have less to parse, less information in your way, and you have a clear indicator the instant something matters.
If you really want more information, do a multi-tiered indicator. "below 25%" is a dark blue, "25-50%" is a medium blue, 50%-75% is a light blue, and 75%+ isn't there. Now you can tell the raid mana situation at a glance, but everything is significantly clearer than a bunch of too-small-to-accurately-estimate bars that are significantly more difficult to properly interpret than 3 distinct colors. The best you'll get out of the bars is "oh look, most people have used some mana" or "oh hey that guy is really low" -- and look, our indicators already do that.
The point of Grid (again, to me, I understand that some people want to just use it as a raid frame and see all the information available) is to re-consider what you need, and have Grid present you with exactly the right information required to make your decisions quickly and accurately. More information is not always better. Usually, you have a specific question, and specific information required to find the answers. Yes, knowing the exact value of every member of your raids mana and accurately analyzing it along with the mana-usage-history of each person, cross-referencing that with how many healers you have, their overall mana, how many are on raid healing, how much aoe dps the boss has during the remaining phases, and how hard your raid needs to burn him down, would make for an amazingly well-informed decision about who to innervate. However, seeing mana bars doesn't make that happen. In fact, nothing will make that happen, it would take hours to do all the math and make the perfect decision. The important immediate question is "who needs mana?" If you can define your question better ("which healer needs mana?" or "which MT healer needs mana?"), then great, that's easy to do with Grid. And the answer to your actual question will always be more useful than 25 partially filled bars which could theoretically be analyzed to find your answer.
So, my suggestion is the people who are arguing that they need mana bars stop and think about what they actually want to know, and not just assume "everything," 'cause that doesn't actually lead to a useful interface.
At the same time, I think having a Grid-standard indicator of "side/top bars" would be brilliant. I'd love to see cast bars, threat meters, a bar that fills up over 10 seconds but resets every time the person takes an action (so I know who's just sitting around), and even more, I'd love to see what other people come up with to put in there. It doesn't seem like it would be so much work to add one additional bar indicator that it'd delay Grid2's release more than a day or two, and having it be properly integrated and supported and updated with Grid2 instead of a standalone indicator that lags behind in development, breaks stuff, and is hacked in seems like a smarter idea. But the Grid people often refuse to add things that they don't think are integral to what they think Grid is for, so who knows. :)
Jul 24, 2008_ForgeUser2440 posted a message on nQuestLog + MobMap + Cartographer + <new idea> = Carbonite ?I wonder how complicated it would be to stitch together Cartographer_QuestObjectives with MobMap to essentially pre-populate the C_QO with MM info.... Anyone familiar with the mods or interested in looking? :)Posted in: Addon Ideas
Jul 23, 2008_ForgeUser2440 posted a message on nQuestLog + MobMap + Cartographer + <new idea> = Carbonite ?Hey everyone. I've thought about this mod idea for a while, then Carbonite came along and did it. But they charge money for their addon, and are very engineer-oriented, with pretty archaic approaches to options/interfaces/etc.Posted in: Addon Ideas
Once I saw Carbonite do it, I knew it really was feasable, and started looking around for normal mods that do it or come close. I already used nQuestLog, which is much nicer than Carbonite's quest tracker. I found MobMap while searching.
I see that nQuestLog and MobMap are somewhat integrated. But I'm wondering if there's an addon out there that takes the MobMap database and applies a Carbonite-style "all quest objectives" mapping to Cartographer? If not, I think that would be a fairly simple mod (relatively speaking) that would be totally awesome to have.
Basically, any quest that is displayed on nQuestLog gets all its MobMap objectives put on the map, perhaps in different colors do you can identify them. A little googling and you can see Carbonite map pictures, etc.
I realize that MobMap does one objective at a time, but it is clunky to get it to show up, and it doesn't help much when trying to plan your quest route through a new zone, and I *always* want my objectives on my map, not just after multiple clicks, one at a time, etc... so figured I'd ask/bring up the idea. :)
If this already exists, I'd love to get a link, and I'm sorry for posting. I tried to search around and wasn't having any luck...
Anyone else think this is a good idea? Anyone interested in taking it on as a project?
Jun 10, 2008I got my guild mate set up with ZOMG the other day, and now we're in a raid and he's having a problem. His ZOMG button has the tooltip "Suspended. ZOMGBuffs is not buffing because it is disabled."Posted in: General AddOns
I can't figure out how to make that tooltip happen so I have no idea how to tell him to fix it. When I *suspend* zomg, the button dissapears, so that isn't it, and "disabled" doesn't seem to be anything I can figure out...
Any chance anyone else knows what he should do to fix that?
Apr 24, 2008Posted in: General AddOnsQuote from ant1pathy »
Had been getting a "Babble-Zone 3.0" error, which I fixed by installing Babble-Zone 3.0. I have no other addons that use this plugin; what functionality (other than keeping my Bugsack clean) does this provide?
I have been getting errors like this for quite a while with Prat. RIght now, it's "Prat\libs\Glory-2.0\Gory-2.0.lua:24: Glory-2.0 requires LibBabble-Zone-3.0". (Prat includes LibBabble-Zone-2.2)
While I can fix it like ant1pathy did, by installing Glory-2.0 on my own, but I don't like to do that ('cause then you eventually add it to your libs and I am sitting here with Glory-2.0 on my machine always wondering if I actually need it or not)
I had another lib error a few weeks ago, too. I got rid of that one by ClassTimers, which used the same libs but included them, even on characters where I don't want Class Timers. :)
Any chance for a fix? It's gotta be extremely simple. I see Prat updating almost daily with my WowAceUpdater, but this hasn't been fixed yet... :/
Apr 15, 2008Posted in: AddOn HELP!Quote from OttoDeFe »
There was a mod called Backtrace posted in a thread - it saves the comm backtrace of the AddOn messages sent. Not something you wanna run constantly, but it is informative. Particularly when you wanna know what mod @? is. Not sure where it was posted, but I have a copy if'n ya can't find it.
I found it, I'll take a look at both of these addons and see if they show me what I'm hoping to see. :) Thanks a bunch, both of you.
Apr 15, 2008Posted in: AddOn HELP!Quote from Seerah »
There's AddonSpamFu - from the description, it "Tracks SendAddonMessage Spam."
What addon are you using that is obfuscated? I know Carbonite and CarboniteQuest are, but that's because they're copyrighted.
Sure, it's copyrighted. That doesn't mean I don't wonder what information I am broadcasting when I use it, nor does it mean I am not allowed to know. I don't like to be completely blind about what my addons are doing behind the scenes. I normally read the code, but I can't in this case. :)
Apr 14, 2008Hey everyone. I hate to be the guy who posts "where can I find this mod?" but for some reason, I simply can't find this one, and I feel like it really has to exist already...Posted in: AddOn HELP!
I'd like a mod that shows, in a decent format (although just printing to the chat frame works too if that's the only option) all incoming and outgoing whispers/addon messages/any other way an addon could chat with another character/account on the server. ALL of them. I'm interested in seeing what one of my mods is chatting about and who it is chatting with, and I am not having any luck reading the code. (It's obfuscated.)
I found one mod that did like a quarter of this, but I feel like this sort of thing would have been written, quite possibly by an Ace coder, who wants to make sure his mods aren't spamming or something. :)
Thanks in advance, and again, I'm sorry to be the guy asking for a link to a mod I should have been able to just search for....
Apr 5, 2008I've been getting an "Omen-Omen r67943 / Threat-2.0 r67942\\Modules\\SingleTarget\\SingleTarget.lua:563: invalid order function for sorting" error with the current files.wowace.com / aceupdater version. I also got it with the www.wowinterface.com version...Posted in: Raid AddOns
Any idea what's causing this?
Mar 28, 2008Posted in: General AddOnsQuote from sylvanaar »
Sounds cool. I can help you write an external prat module - similar to how Prat_Logon was done.
If I PM you my AIM-name, or you could PM me yours? Then we can chat on aim? (or msn, or gchat, or whatever you like :)).
Mar 27, 2008One more idea that came to me during that:Posted in: General AddOns
Why not handle the "channel ordering" like an alias? So you say "I want channel 4 to be myfriendschat" -- instead of making Prat do weird (and patently unreliable in my experience) channel joining/leaving to try to get it to *actually* be channel 4, why not just alias "/4" to the channel that it *is*? Then you could easily let them alias "/c" or "/a" or "/friends" or whatever they want to the channel by name...
But basically, I feel like chat colors, commands/aliases, re-naming-schemes, etc, should all be done by channel name, not number. I tried to make my friends chat ('/join myfriendschat') to be named "Frenz" for short. It worked until I relogged and my Frenz chat (which was channel 4 on my main) was not on my alt, and my alt had /trade as 4, then suddenly Trade is claiming is "Frenz" and that was just confusing.
I feel like saying "call channel 4 "some name"" is kinda missing something, since channel 4 could be different things, why not do all your aliasing/renaming/coloring/etc by channel name (even "trade" or "guild" etc), so that the numbers don't cause issues like this?
Thanks a bunch!
Mar 27, 2008Feature Request: Guild-Like alias/rename/coloring/etc.Posted in: General AddOns
I would like to request the ability to do the following (I've written a mod
that does this, but it's not compatible with Prat, and my friends started
using Prat, so I started using it too and now my mod doesn't work, and I
thought this made more sense in Prat than as a personal work-around-mod :)):
I want to be able to set an alias ("/whatever" ex: "/c") to talk on a
specific channel. By NAME. I want "/c" to talk to whatever number was
assigned to the channel when I did "/join myclanchannel" -- I do not care
one little bit what that number is. For all I care, it doesn't even have a
number. (my mod hid the number from me too :)). I just want it
consistent. If it's a different number on one account than another, that's
fine. I don't care about channel ordering. That seems confusing to begin
with, since it does this weird slow channel quitting and joining thing...
I just want "/c" to automatically figure out the # of the channel, and
alias itself to it on the fly.
It's a pretty straightforward idea, especially if you already have your
stuff able to alias things and control channels. And I really like it.
Possible extensions to this:
A "Faux Guild" Prat-Module.
The config screen lets you set up faux guilds.
Guilds get a name, a command alias, and a "channelname" (and maybe a
channel password?), a channel color... -- Then Prat always makes sure they
are in that channel (on all alts too!), that /commandalias talks on that
channel, that the channel shows up in the right color, and that when people
talk on it, it says [Guild Name] instead of "[# channelname]"
That's actually what my mod did... :)
As a side note, I'd be happy to try to write the module for Prat that does this, but I'm not exactly sure what that would take. I took a look at that "empty Prat module.lua" you reference somewhere, but didn't quite follow it... I could send you the code I wrote for my old mod, which still works but has some kind of conflict with Prat, and for the most part seems to overlap in functionality anyway, it's just presented differently.
- To post a comment, please login or register a new account.