• 0

    posted a message on BigWigs
    I am seeing this error today while fighting magtheridon. It happened six times during the fight but i did not notice exactly when it was happening.

    BigWigs-2.0 r68415\Prototype.lua:408: C stack overflow
    Posted in: Raid AddOns
  • 0

    posted a message on SCT 6.0 / SCTD 3.0
    [20] = {display="Critical! (*1: *4)", type="DAMAGETARGET", selfonly=1, critical=1, r=200/256, g=0/256, b=0/256, iscrit=1},

    Specifically i have this custom event. i'm pretty sure it worked fine a couple days ago but i just recently noticed that things like immolate and seed of corruption which are both dots and can crit are not showing up with this event. A little playing around and it seems that they are registering as DAMAGESELF instead. This event does work fine for all direct damage and melee attacks though.
    Posted in: General AddOns
  • 0

    posted a message on SCT 6.0 / SCTD 3.0
    I am currently seeing 2 problems with sct.

    1) The soul shard custom event is no longer working.
    2) My dots seem to be showing as damage to self and not target.
    Posted in: General AddOns
  • 0

    posted a message on State of the community: SVN for end-users too
    Quote from Seerah »

    Have you ever tried to herd cats? :)


    Personally, i think that about sums it up. From what i can see the people who are in charge don't want to make it a job (perfectly understandable) and too many of the people who use the site lack the experience to do things correctly (also perfectly understandable). So i really don't see any major changes happening anytime soon.

    Now that being said, from my experience the easiest method to achieve some semblance of stability would be to use the stable trunk/develop on branches style of source control usage. You currently have a large chunk of code that while it is comprised of individual addons is for all intents and purposes a single code base. So each addon is best seen as a feature of that code base. Developers should then be adding and testing code in their individual addon branch and merging back into the trunk version. Given that there is a large number of people this allows everyone to spend the majority of their time working in isolation and having little impact on anyone else. As long as people are fairly responsible in only merging stable updates into the trunk then things would work fairly well.

    I also don't see any need for incorporating any sort of standardized tagging system into things. It just creates more work for everyone and there is rarely any need for people to be downgrading things anyways. Especially if there was a reasonable expectation that everything on the trunk was stable.

    This would probably also allow the various site scripts to remain unchanged since the trunk is still the trunk and most of the work in determining what is stable and not would fall on the developers. Even though it is a fairly minimal amount of extra work you probably still wont see most people volunteering to do it. Which is rather unfortunate.

    Posted in: General Chat
  • 0

    posted a message on Skillet - Official Thread
    Excellent mod.

    The only problem i have seen so far is that sometimes there seems to be a phantom old tradeskill window. For example i click on a tradeskill button and skillet opens up, then if i ctrl-click to view some item in the dressing room window, the dressing room will pop up in the middle of my screen as if there was still an old tradeskill window to the left of it.
    Posted in: General AddOns
  • 0

    posted a message on JasonQuest - Official Thread
    Quote from JASlaughter »

    The only way I could think to get support in was to force a detach. Because the LightHeaded frame is parented to the QuestLog Frame, it shows and hides with it, and if you want to use LH while looking at JQuests and not normal quests the frame has to be re-parented to UIParent and detached.

    I'm open to other ideas of how this could be accomplished.


    Well this may not be easiest suggestion but it would seem natural to me to just have the JasonQuest frame be the default QuestLog Frame. Have the first tab always be the player and tabs 2-5 be the group members. You would probably still need to move the tabs for LightHeaded to attach nicely though, but maybe they could be put on the left or maybe the bottom instead.
    Posted in: General AddOns
  • 0

    posted a message on Grid
    Quote from Pastamancer »

    Mind if I include this in Grid?


    Be my guest.
    Posted in: Grid & Grid2
  • 0

    posted a message on Grid
    Here is something that will show who is talking as a status in grid if anyone wants it. Seems like it is working fine for me. YMMV...

    local L = AceLibrary("AceLocale-2.2"):new("GridStatusVoiceComm")
    
    --{{{ Localization
    
    L:RegisterTranslations("enUS", function()
    	return {
    		["VoiceComm"] = true,
    		["<Talking>"] = true,
    	}
    end)
    
    ---}}}
    
    GridStatusVoiceComm = GridStatus:NewModule("GridStatusVoiceComm")
    GridStatusVoiceComm.menuName = L["VoiceComm"]
    
    --{{{ AceDB defaults
    
    GridStatusVoiceComm.defaultDB = {
    	debug = false,
    	alert_voice = {
    		text = L["<Talking>"],
    		enable = false,
    		color = { r = 0.5, g = 1.0, b = 0.5, a = 1.0 },
    		priority = 50,
    		range = false,
    	},
    }
    
    --}}}
    
    GridStatusVoiceComm.options = false
    
    function GridStatusVoiceComm:OnInitialize()
    	self.super.OnInitialize(self)
    	self:RegisterStatus("alert_voice", L["VoiceComm"], nil, true)
    end
    
    function GridStatusVoiceComm:OnEnable()
    	self:RegisterEvent("VOICE_START")
    	self:RegisterEvent("VOICE_STOP")
    end
    
    function GridStatusVoiceComm:VOICE_START(unitid)
    	if string.find(unitid, "pet") then return end
    
    	local settings = self.db.profile.alert_voice
    
    	self.core:SendStatusGained(
    		UnitName(unitid),
    		"alert_voice",
    		settings.priority,
    		(settings.range and 40),
    		settings.color,
    		settings.text,
    		nil,
    		nil,
    		settings.icon
    	)
    end
    
    function GridStatusVoiceComm:VOICE_STOP(unitid)
    	self.core:SendStatusLost(UnitName(unitid), "alert_voice")
    end
    Posted in: Grid & Grid2
  • 0

    posted a message on To ace or to not ace as first add-on
    Quote from Shadowed »

    If you go right for using a library at the start you'll never learn when a library is the right answer, and when doing it yourself is and you'll likely become another one of those people who think that 5 libraries for 50 lines of code is good.


    And if those 5 libraries allow you to write in 50 lines what would otherwise take you 5000? Sounds like a pretty good trade off to me.

    It should probably be noted that everyone does learn things differently.

    Otherwise i couldnt disagree more. Libraries are generally pretty easy to learn and they are there to prevent unneeded duplication. If you are trying to learn the language you are going to learn just as much about it trying to solve your problem domain as you would trying to rewrite the io subsystem before you finally tackle your problem domain. All you end up doing is creating a large amount of work for a potentially small amount of extra knowledge.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Autobar (Toadkiller)
    Quote from Toadkiller »

    exactly what food (ie. its name) shows up in two separate buttons? As is AutoBar has separate buttons for regular (including conjured) foods & for buff foods & for combo foods.


    This is not in the alpha and it sounds like the new version might give the flexibility to solve this. But in the current versions +sta food is showing up under the Buff: General and Buff: Health categories. In PT3 browser this would be consumables->buff group->general and consumables->buff->health. At the very least +sta food should probably not be in the health category, it should probably be in the stamina one. Also no other stat food seems to be in the various buff categories from what i can see so the +sta food seems out of place there in general. And finally AutoBar dosen't seem to have some sort of Potions: General and Potions: Health category so it kind of forces you to have the food on the same button as your potions regardless of whether you want it there or not.

    I don't know which of those are actually bugs but all combined they make things a little confusing.
    Posted in: General AddOns
  • 0

    posted a message on To ace or to not ace as first add-on
    I would highly recommend you start by using a library or framework and to not write everything from scratch. It will allow you to get more done in a shorter amount of time. You will spend more time getting your domain logic correct and spend less time figuring out confusing minutia that generally doesn't matter in the long run anyway. You will be using code that is already abstracted out which can help keep your code cleaner and easier to understand.

    I like to think of it like this, in general learning to use a tool is a lot easier than learning how to make the tool and often you don't really gain any higher understanding of how to use the tool from making it. The important, interesting, and fun part for me has always been the problem domain.

    Your mileage may vary....
    Posted in: Lua Code Discussion
  • 0

    posted a message on Options and config abstraction (Rock, Ace3)
    Quote from ckknight »

    I've been pondering, as one like myself would ponder, about exporting the data-retrieval functions of LibRockConfig-1.0 and then having third-party libraries use these same functions to create their own configuration menus. This could be used for a dropdown system (a la Dewdrop) or a slash command system (a la AceConsole) or whatever. The major advantage to doing this is that it would eliminate the issue that Waterfall/AceConsole/Dewdrop had before where each had to write their own data retrieval functions and none would be consistent. The only problem that remains (that I honestly don't know how to solve) is that then things wouldn't necessarily be consistent from the user's point of view.


    To be honest, as long as the library code that handled all this was consistent and complete i don't think it would matter if the manner in which things were displayed was inconsistent. Most users would not mix and match the different display systems, they would just use the one they prefer and ignore the rest. The problem only arises if they have to use multiple display systems to be able to handle everything because certain things are only available in each one.
    Posted in: Frameworks
  • 0

    posted a message on CastYeller - announces to your party/raid important spells you cast.
    Quote from Adirelle »

    Weird, though having no warlock, I couldn't test thoses rituals. I guess some spell events are sent twice where they should be sent only one time.


    The way the rituals work is kind of weird. Basically it has a normal casting time like most spells and after that time you then get the graphic to click on, once that happens it then turns into a channeled spell until it either times out or the required number of people click on it. So i believe it registers with both SpellEvents_Player_Spell_Start and SpellEvents_Player_Channel_Start events for the first part of the spell and the second part respectively.
    Posted in: General AddOns
  • 0

    posted a message on CastYeller - announces to your party/raid important spells you cast.
    Quote from Melvalian »

    Something I have been seeing is when I use my ritual spells I sometimes get 2 messages. 1 when I start casting the portal and one when I have finished casting the portal. Right before the channeled part. Is there a way to make it so it posts only when I start? Thanks


    I had to increase the cooldown limit from 3 seconds to 6 seconds to fix this since ritual of summoning is a 5 second cast time. Look for the line
    yellCooldown[event..':'..spellKey] = GetTime() + 3
    and change the 3 to a 6. 5 didn't seem to be long enough even though 3 seemed to work fine for the 3 second casting time of ritual of souls.


    There is also a bug in the ParserEvent function, e.targetName needs to be changed to e.recipientName. This fixes $TARGET getting replaced with an empty string.
    Posted in: General AddOns
  • 0

    posted a message on Grid
    Quote from Pasus Nauran »

    We'll call it "GridStatusPvP". Here's my complete hack of Halgrimm's AFK code to (potentially) add PvP status. I checked, and UnitIsPVP is a valid tag, so in theory this should work (IN THEORY). I'll give it a try tonight, but if anyone else gives it a try let me know (or any coders please feel free to correct the errors I'm sure will exist).


    It almost works. The problem is that the PLAYER_FLAGS_CHANGED event fires when you turn your PvP flag off and not when the flag actually turns off. Since the PvP flag actually takes 5 minutes to turn off this causes the grid status to stay on permanently. After a little digging I found that the UNIT_FACTION event fires correctly for this. So a simple search and replace of PLAYER_FLAGS_CHANGED with UNIT_FACTION in the provided code makes this work quite well.

    And thank you Adelea for putting this stuff into svn.
    Posted in: Grid & Grid2
  • To post a comment, please or register a new account.