• 0

    posted a message on Skillet - Official Thread
    Quote from sfagent07 »

    I was wondering if there was anyway this addon could actually give you an option to see every recipe even ones you dont own? With that and Lil workshop I could see which gems are profitabe before I even blow the 500g-1000g on the recipes. I think that would be incredible is there away to possibly get this feature implemented?

    Hi sfagent07, check the TradeskillInfo and TradeskillInfoUI addons here on wowace - they serve as a list of all tradeskill recipes and are compatible with LilSparkysWorkshop ;)
    Posted in: General AddOns
  • 0

    posted a message on WoW UI Updater (Win/OSX/Linux, supports multiple sites), 1.6 thread
    Because of problems with WAU and it's limitation to update just wowace addons I'm trying out WUU and it looks really good... Great work :)

    I have one small bug report: the regex for Gatherer is missing _ and thus is not able to update the GathererDB_Wowhead.
    gath_version	<a\shref="\?dl=(%s/([0-9a-zA-Z\._-]+?\.zip))">.+?(\d{4})-(\d{2})-(\d{2})


    I also have a feature request to (optionaly) ignore externals when using wowace SVN addon - could use same setting as for WoWAce: use no-ext addons.

    Thanks for a great program and I have fingers crossed for re-adding wowui support ;)
    Posted in: Updaters
  • 0

    posted a message on Why Acing/Rocking addons is good
    Quote from Xinhuan »

    Pretty much zarevak was quoting me everywhere quite a bit inaccurately due to the lack of understanding of the Rock and Ace2 communication protocols libraries.

    I'm sorry, I wanted to make my point that having more addons using the same library/framework is good because they all will use the same communication protocol.
    The problem doesn't lie in the frameworks themselves but in the communication library used. Maybe we can solve this by creating pure communication library for all addons. Question is, is there a demand for such library or is it better to write specialized protocols for each addon category (healing - LibHealComm-3.0/threat - Threat-2.0/craft info/raid management/...).
    Posted in: General Chat
  • 0

    posted a message on Why Acing/Rocking addons is good
    Quote from Seerah »

    Good explanations, Phanx. :) I didn't have the energy to do that earlier today. :)

    I admire Phanx for his willingness to invest his precious time to provide his point of view and his input into the discussion and I thank him for it.

    I see a difference in our thinking - when I see a possibility to do something easier by using a library/framework, Phanx see a possibility to make specialized solution that works better for his specific task.
    From his response to point #1 I now see that blindly using Ace2/Rock/... framework is bad thing because it uses proprietary communication protocol which is hard to implement without the use of such framework.


    After a day of this thread the current positives of using Ace/Rock/... frameworks are:
    1) Centralized configuration
    2) Easier development

    And negatives:
    1) Overhead - especially when using embedded libraries and just few addons of each framework
    2) Proprietary communication protocols (Serialization/Memoization)
    3) False faith in better addon quality :)


    EDIT: Can we please stick to the topic and not bring up the -Ace2- or any other tag again? I've started this thread to learn more about the acing issue and not to continue wars about tags/colors in addon titles. Thank you.
    Posted in: General Chat
  • 0

    posted a message on ACP - Official Thread
    If you look in the sorting code you'll notice it already tries format the title by calling the formattitle function before comparing the names (this is done just in the TITLES sorter). The formattitle() function colors the Lib: part of the addon name and removes the -Ace2- tag.

    I suggest:
    	local striptitle = function(s) return string.lower(s:gsub("|[cC]%x%x%x%x%x%x%x%x", ""):gsub("|r", "")) end
    	table.sort(masterAddonList, function(a, b)
    		local _, nameA = GetAddOnInfo(a)
    		local _, nameB = GetAddOnInfo(b)
    		return striptitle(nameA) < striptitle(nameB)
    	end )

    The gsub(...) will remove all coloring and lower(...) will solve issue of sorting AHSearch before Abakus
    Posted in: General AddOns
  • 0

    posted a message on ACP - Official Thread
    Quote from Phanx »

    Stripping, not striping. ;)

    Thanks. English is not my native language and my spell checker haven't read my mind correctly...

    Quote from Phanx »

    I like my addons in alphabetical order. Some addon authors think that gratuitous colors and spaces look cool, and alphabetical order be damned. This annoys me. IMO it's not worth the extra CPU time to determine if the color code is at the beginning of the title (disrupting alphabetical order) or not. Therefore, all colors should be removed. They don't add any information, they're just frivolous visual clutter.

    I'm just making fool of myself more and more here. Maybe it's time to go to bed (it's 4:30AM here)... I thought the problem is with the space at the beginning and not the colors. After the space was removed the MoveIt addon is still last so I now see the problem being the color codes.

    I've just skimmed through my AddOn list and tried to identify the color usage:
    1) -Ace2-/-Extension- tags (extenstion tag is used by Dock Config)
    2) colorized version information (AlphaMap, Natur ECB, ...)
    3) colorized module information (Cartographer, Natur ECB, BigWigs (two styles), Atlas, Baggins (two styles), cyCircled, LibPeriodicTable, Quartz, ....)
    4) colorized name for design purpose (cyCircled, ClearFont2, ArcaneBar, ...)
    5) colorized Fubar module names
    6) crazy colors (MoveIt, Whats)

    I'm for leaving the 2), 3) and 5) types colorized because it brings more clarification to addon list - it's use is similar to colorizing source code :) I'm against 6) and have no strong opinion about points 4) and 1).

    As for the sorting issue you can always sort the list based on the title stripped of all the colors but still display the colorized version just for the user.
    Posted in: General AddOns
  • 0

    posted a message on ACP - Official Thread
    Quote from njmorf »

    I've been using ACP for a few months now and it's pretty good, but there's one particular problem that's driving me nuts. I've got the mod Gemhelper installed, but ACP doesn't show it on the list of mods, so can't enable it. This means that Gemhelper's not loaded most of the time. Is there any way I can get it to show up?

    Hi NJMorf,
    I've just tested ACP with GemHelper and haven't encountered any problems. Can you check if GemHelper is listed in Blizzard AddOn list on your character selection screen? If it doesn't show there the addon is probably not installed properly. Try to reinstall it.
    Posted in: General AddOns
  • 0

    posted a message on ACP - Official Thread
    Quote from sylvanaar »

    I took out the -ace2- stuff, but if you look at my commit notes they are sarcastic in nature. I think the whole topic is stupid, and I'd be happy with or without the tags myself.

    That's what had worried me the most ;)

    Quote from sylvanaar »

    I just was doing it so people would stop their little holy wars. I'm sure I could make it an option too.

    And you've created a new small holy war with me :) No; personally I think the issue is overstated and if you (the Ace developers) don't like -aceX- tag you can just post a recommendation to remove the tag from TOCs. As someone posted in the no -Ace3- tag thread the issue comes from copy-pasting the TOC from one addon to another...

    Quote from Phanx »

    That's because it's TOC title looks like this:
    ## Title: |CFF00CED1W|r|CFFFFFFFFhats|r
    ...instead of something normal like:
    ## Title: Whats

    The main problem is with the big C at the start of color tag. I also sometimes use MoveIt which has even worse title (notice the extra space at the beginning):
    ## Title: |cffAF66FF MoveIt by Shervin |r
    When disabled the title is properly displayed as gray in ACP but it is last in whole addon list similarly to Blizzard addon manager in login screen.

    Quote from Phanx »

    I think ACP should really just strip out all colors so that addon authors who feel compelled to add unsightly rainbows to their titles don't mess up the ACP color coding. I also think it should strip out common non-title tags, includng but not limited to -Ace*-. It would be nice to strip out version numbers, but distinguishing between a number actually being part of the title (Bartender3) and being a version number (PitBull 2.0) might be impossible to implement perfectly.

    I don't agree for striping the colors for enabled addons - let's have it same as in the Blizzard addon manager. For disabled addons I agree with colors striping as it is done now.


    Because the heat around the addon tagging have calmed and we can judge the problem with clearer heads I see the removal of -Ace2- (or any other useless tags) is not such a bad thing ;) Before the issue arose I even remember myself wondering why some addons have the tag and others don't.
    Posted in: General AddOns
  • 0

    posted a message on Why Acing/Rocking addons is good
    Quote from Pastamancer »

    LibHealComm-3.0 is different because nobody is going around adding a tag to the toc file. You're not going to see "Grid -Ace2- -LHC3-" in your addon list. However, you will find that the usage of LibHealComm-3.0 is advertised on the wiki page because it affects the functionality of the incoming heals status.

    AFAIK all the healing addons switched to the LibHealComm-3.0 library so there is no need for such tag. When there will be other addons using other communication protocols there may be a need to tell the users if it uses LibHealComm-3.0 or any other standard so the users can tell if their addons will or will not be compatible with the rest of the Guild/Raid/.... I'm not trying to justify the -Ace2- or any other tag, I'm just trying to say there may be needs for tagging addons in some way and the tag in TOC name is easiest one.

    Quote from Elsia »

    With all these unifications, addon handling becomes more predictable and manageable for the users.

    Elsia, thank you for your brief introduction to the history of Ace addons.

    I like your idea of general configuration options across all addons for backgrounds/colors/fonts. As for the fonts the ClearFont addon almost manages to create global font settings which is IMHO a good start.

    Personally I think the addon compatibility and shared addon configuration is the main reasons for the users to stick to addons of one framework. From my personal experience when using around 300 addons/modules it's hard to remember how can I access options for each of the addons. Many Ace2 and Rock addons are configurable from RockConfig. Almost all Ace3 addon are configurable from Ace3Config (when using disembedded libs). Auctioneer addons use Configator and tekkub's addons use OptionHouse. Some addons use their own proprietary configuration systems, which may be specialized just for needs of one addon, but are harder to find for the user. One might protest that adding whole framework just because of unified configuration system is overkill but I think the 400kb of the framework is very well satisfied by:
    1) user satisfaction
    2) ease of writing such configuration options in the addon and thus saving developers time

    BTW: In my first post I've asked you to bring up positives of acing/rocking of addons. If you have any negative issues to add, please bring them up as well. I'd like to hear constructive opinions from both sides :)
    Posted in: General Chat
  • 0

    posted a message on Why Acing/Rocking addons is good
    Hi, When ACP addon started to remove the -Ace2- clutter from addon names I objected and requested the new feature to be removed. In the same post I've tried to bring up objective positives of using addons using same framework. After a while I started to feel bad because I brought off-topic discussion to addon thread...

    In the now locked "no -Ace3-" thread there was a point made users don't understand what Ace means for them and just want their addons to be Aced. I'm trying to get objective points why using addons of one framework (be it Ace2/Rock/Ace3) is good:

    1) Greater compatibility between addons using same framework (Ace/RockComm - problem of incompatibilities reported in Mapster thread)
    Quote from Xinhuan »

    It will be more than ugly, because it would need to optionally include all the Ace2 and LibRock libraries just to make it work in order to deserialize the data that is being sent across the addon channels.


    2) Better compatibility with other addons even when the addon is poorly written (Ace/RockHook vs. custom hooking that is not handled properly)

    3) Global Addon options via Waterfall/RockConfig/Ace3Config


    I have to also report that even when people here become sensitive to addon Acing issue there was similar motion from Ace/Rock developers in January about using LibHealComm-3.0 and trying to get all healing addons LibHealCommed. You may object it's just library and it's needed for compatibility between addons - isn't it what I said in point #1?


    So what do you think about gains of Acing/Rocking addons? Please don't post flame post saying "My addons don't use Ace2 bloat and work just fine". I know you can create great addons without any framework, but the point of frameworks is to make life of developers easier :)
    Posted in: General Chat
  • 0

    posted a message on ACP - Official Thread
    Quote from Phanx »

    Censorship? Thanks for the laugh. But it really has nothing to do with "censorship" or "interfering with addon developers"... color codes in TOC titles interferes with ACP's color coding for enabled/disabled statuses, and -Ace2- is not part of any addon's actual name. When is the last time you heard someone talk about "this really cool cast bar addon, Quartz -Ace2-"? Never, because it's a metadata tag, not a title. ACP is intended to list addon titles for simple in-game addon management.

    You are right - It's a metadata tag and not the title. It's the same as name of my OS: Microsoft(R) Windows(R) XP - the (R) symbols are metadata as well...
    I may have been emotional when thought that hiding just one tag -Ace2- and not any other tags is censorship. Now I see it as a new feature to remove clutter from addon name for cleaner list ;)
    and I have a feature request for you: Can you please make your new feature optional? I don't mind having my addon list cluttered....


    Quote from Phanx »

    And just to comment on your points, #2 is false; addons using AceHook or RockHook can still improperly hook things, and there are tons of addons that use no framework that handle hooking properly. #1 isn't really true either; Ace Addon A and Ace Addon B might not work well together at all, where Ace Addon A and Rock Addon Q or Standalone Addon X work together just fine. It all comes down to how well the addon is written, not what framework it's written around.

    2) I thought that AceHook automatically preserved the hook chain but looking at the sources I see you have to do it in your code similar to custom hooking. Why I came with this point is because I installed new non-ace addon and it broke other addons because of not preserving the hook chain. I've never had similar problems with Ace/Rock addons - it may be because of quality of developers here ;)
    1) Please take a look at latest posts in Mapster thread. There is post from Xinhuan saying that synchronization with Cartohrapher(Rock) or GuildMap(??) would need to use Ace2/Rock libraries in Ace3 addon.

    Quote from Xinhuan »

    It will be more than ugly, because it would need to optionally include all the Ace2 and LibRock libraries just to make it work in order to deserialize the data that is being sent across the addon channels.

    4) People here become sensitive to addon Acing issue. But there was similar motion even from Ace/Rock developers in January about using LibHealComm-3.0 and trying to get all healing addons LibHealCommed. You may object it's just library and it's needed for compatibility between addons - isn't it what I said in point #1?
    Moved offtopic discussion to new thread: Why Acing/Rocking addons is good


    To leave our irrelevant discussion about usefulness of addon acing/rocking I have also a bug report for you :)
    The Whats addon name (hosted here on wowace) is colored even when disabled.



    Posted in: General AddOns
  • 0

    posted a message on Chinchilla - Minimap addon of awesomeness.
    I love the new customizable location bar and border settings. Great work! I just have some small feature requests if you don't mind ;)

    1) Blizzard location bar has tooltip displaying details about the current area/location. Can you add similar tooltip to the customizable version?

    2) Setting the Radius in Move Button section of options doesn't move the addon (FubarPlugin) buttons. Can you move them as well?

    3) I have my minimap set up with corner shape but when I drag the addon buttons they change the distance from the center of minimap when dragging from the rectangular part to round part and vice versa (there's a visible jump in otherwise smooth drag around the minimap). I suspect the problem is somewhere in this part of code (in both FuBarPlugin-2.0 and LibFuBarPlugin-3.0):
    		if round then
    			x = cos * 80
    			y = sin * 80
    		else
    			x = 110 * cos
    			y = 110 * sin
    			x = math.max(-82, math.min(x, 84))
    			y = math.max(-86, math.min(y, 82))
    		end
    - I don't understand why round part has radius 80 and rectangular part maximum distance of 82, 84 and 86...
    Posted in: Map/Minimap AddOns
  • 0

    posted a message on TradeskillInfo Official Thread
    Quote from zarevak »

    2) All non-recipes are uncolored. Items you cannot use should be red-colored.

    This came from my partial solution to Compact-UI bug not setting the red/white color for textures based on item usability.

    Updated code for TradeskillInfo:AuctionFrameBrowse_Update():
      if button:IsVisible() then
       local iconTexture
       local recipeLink
       if button.Icon then -- cached or from Auc-Advanced Compact-UI
        iconTexture = button.Icon
       else
        button.Icon = getglobal("BrowseButton"..i.."ItemIconTexture"); -- cache the icon texture
        iconTexture = button.Icon
       end
       if button.id then   -- contains real index when sorted in Compact-UI level
        index = button.id
       end
       local recipeLink = GetAuctionItemLink("list", index)
       local recipeId = getIdFromLink(recipeLink);
       local id = self:GetRecipeItem(recipeId);
       if id then
        local you,alt = self:GetCombineAvailability(id);
        -- self:Print("recipe: %s you %d alt %d - %d %s",id,you,alt, recipeId, recipeLink);
        -- 0 = Unavailable, 1 = known, 2 = learnable, 3 = will be able to learn
        if you == 2 then
         local c = self.db.profile.AHColorLearnable;
         iconTexture:SetVertexColor(c.r, c.g, c.b);
        elseif alt == 2 then
         local c = self.db.profile.AHColorAltLearnable;
         iconTexture:SetVertexColor(c.r, c.g, c.b);
        elseif you == 3 then
         local c = self.db.profile.AHColorWillLearn;
         iconTexture:SetVertexColor(c.r, c.g, c.b);
        elseif alt == 3 then
         local c = self.db.profile.AHColorAltWillLearn;
         iconTexture:SetVertexColor(c.r, c.g, c.b);
        else
         local c = self.db.profile.AHColorUnavailable;
         iconTexture:SetVertexColor(c.r, c.g, c.b);
        end
       elseif button.id then  -- button.id is set only by Compact-UI; we need to fix texture colors.
        if IsUsableItem(recipeLink) then
         iconTexture:SetVertexColor(1.0, 1.0, 1.0); -- usable, non-recipe item
        else
         iconTexture:SetVertexColor(1.0, 0.0, 0.0); -- item is not usable
        end
       end
      end


    If you encounter the error described a few posts above by thegriffgeeks and want a quick fix apply this patch. Otherwise wait for a proper solution from Evenue.
    Posted in: General AddOns
  • 0

    posted a message on TradeskillInfo Official Thread
    Quote from fred »

    I use it with Auctioneer Advanced with no errors.

    Yes. This is because the problem I described under my patch: With only Auc-Advanced the hook doesn't work... I've finally found out why and feel stupid about it - When TradeskillInfo tries to create the hook the AuctionFrame doesn't exist and it silently fails.
    The TradeskillInfo doesn't throw any error for you, but it doesn't color the recipes as it should.

    Quote from thegriffgeeks »

    Hi I don't use WoWcon, but I do use auctioneer classic and advanced. This is the error I get at times when mousing over items in the auction window.

    I suspect you are using another Auction addon that is forcing the AuctionFrame to be created and TradeskillInfo hooks to be initialized. You can try applying my patch which will solve the error and start coloring the recipes. Only problem is that all non-recipe items won't be colored red when you cannot use them.
    Posted in: General AddOns
  • 0

    posted a message on ACP - Official Thread
    Hi sylvanaar, I know there is big discussion about addon branding, but I don't see any reason to censor the -Ace2- tag from Addon names in ACP.

    Can you please revert your latest changes and leave the addon naming issue to developers of each addon? Thank you ;)

    In the branding thread there is also question whether the Acing/Rocking is something better then anything else. From my user perspective it is, because what Ace2/Rock/Ace3 gives me:
    1) Greater compatibility between addons using same framework (Ace/RockComm - problem of incompatibilities just reported in Mapster thread)
    2) Better compatibility with other addons even when the addon is poorly written (Ace/RockHook vs. custom hooking that is not handled properly)
    3) Global Addon options via Waterfall/RockConfig/Ace3Config
    Posted in: General AddOns
  • To post a comment, please or register a new account.