• 0

    posted a message on PallyPower - Official Thread
    Thanks Az, you're a good coder. Just look at the summary at the bottom of the post to see what needs implementing, it's quite easy stuff. I'd help code it but don't have time to learn the codebase, sorry. You'll be able to do it faster than me for that reason. :-) As for how to toggle righteous fury on/off in this new implementation, I think it would be very easy if it was as simple as shift-clicking the location where the righteous fury icon sits, to make it appear/disappear (and set the boolean true/false state for it). That way you don't have to have that setting in any menus, and makes it easier when saving, loading and making sets.
    Posted in: General AddOns
  • 0

    posted a message on PallyPower - Official Thread
    Thanks for trying Aznamir. I might sound a bit rude now but it's 4 am and I'm dead tired, I don't mean any offense.

    Now, a review of the current system you've implemented:

    Your primary spec will be auto-assigned to the "Default" profile (your old settings). The first thing to do is copy the settings to your secondary spec's profile:

    Swap to your secondary spec, go to the Options menu, hit Profile > Copy from > Default. Now your Secondary and Primary (Default) profiles match up, so the layout will be the same.

    Next, open the Options menu while in each of your specs and choose Buff Buttons > Righteous Fury/Seals > ..., where you choose if righteous fury is needed in the active spec.

    From now on, it will remember righteous fury on/off, and the currently active seal whenever you swap spec.

    It will NOT remember Aura or Blessing assignments.

    So here's where the update went wrong:

    * It needlessly complicates things by using the "shortcut" of profiles, which in turn just makes it so you have to manage two different layouts that go out of sync if you make the slightest change to either's position etc. Yes, at least you have the "Profile > Copy From" feature when that happens, but that also copies over righteous fury/seal settings forcing you to redo that every time you've moved/changed the PallyPower window. MOST people don't need to resize the window or move it or whatever when they change specs, so implementing it via profiles just complicates things a lot.

    * Additionally, it has NO support for automatic swappings of seals and auras, which was the MAJOR reason everyone has been wanting dual spec support. When tanking, you have one set of assignments, and when healing, another, and when dpsing, another, etc. Not having this support means that the new dual spec support is completely pointless. All it has achieved is making it complex to manage the layout (having to "Copy From" each time you move/change the window in either spec), while pointlessly speeding up an area that was fast enough as it is (changing the seal was the easiest part of changing spec, it's the slow and tedious change of BLESSINGS that sucks).

    Please re-read my suggestion. It would be so much better if the LAYOUT and PROFILE was always global ("Default") and totally separate from the spec assignments.

    To handle specs, it would be best to implement what I suggested earlier:

    Quote from Yewbacca
    Actually, it would be even cooler if it was implemented as some sort of "set" system where you can do /pp save tanking and /pp load tanking, to save/load a set of auras, seals and blessings. That way you can implement it in macro buttons to easily swap all at once. That would be INCREDIBLE.

    Such a system of user-named sets would also be easy to tie into specs, like "on Spec swap, if spec==1 activate set named "tanking" else activate set named "healing"".

    That really would be a superb solution.


    The result would be:

    * A slash command for saving sets.
    * An additional menu (via a button such as Options, named "Sets" or similar) that lets you pick from the saved sets via a dropdown menu.
    * The ability to load sets via the slash command.
    * Finally, code inside PallyPower that automatically switches to the assignments from one of these named sets for each spec you have. Implemented like this: Options > Spec1 Set > ..., Options > Spec2 Set > ..., where "..." is the list of saved sets. That way the user can easily manage multiple sets, and choose which one should be auto-activated on spec change, for each spec.

    A set should contain aura, blessings, righteous fury on/off, and seal.

    Also, since the sets are saved by name, and are implemented in a different table from profiles etc, it means they are global and static, in that let's say you swap to Spec1, which activates your assignment set named "tanking", which sets all blessings to Kings (except your own to Sanctuary), Devotion Aura, Seal of Vengeance(/corruption), and Righteous Fury On. You then play a bit and give the mage his BoW etc. This change won't affect the actual SAVED "tanking" set, and is just temporary. The next time you swap back and forth between specs, it will load the clean "tanking" set as usual. You can also type /pp load tanking to immediately reload the "tanking" set even while in the spec. Additionally, you will be able to have many different sets, and the ability to bind them to macro buttons thanks to the slash command.

    You see why this is superior? ;-)

    It shouldn't be much work either, as it can be implemented this way:

    * A database table containing subtables for each stored set, and inside each of those tables it's simply a matter of storing the aura/seal/blessing numbers (the way they're already implemented internally on a number-basis in PallyPower) and a boolean true/false for the righteous fury.

    * Adding a few submenus for the "Sets" menu described above, the Options menu additions, etc.

    * Adding a slash command that writes the currently assigned aura/seal/blessing numbers and righteous fury state into the set-table.

    * Adding a slash command (and function) that reads the set-table and puts the assigned aura/seal/blessing numbers and righteous fury state into PallyPower's currently active state, in order to load sets.

    * Finally, a piece of glue-code that listens for the spec swap event, checks what spec has been activated, reads which named set it should load for that spec (and whether the set still exists; otherwise abort and retain current assignments), and then finally uses the load-function to load the set for the newly activated spec.

    The result:

    FULL support for sets, including the ability to have multiple sets and even load them from macro buttons. Super easy to manage, clean, logical, and no need to manage multiple profiles that go out of sync when simply moving the window (causing you to have to "Copy From" settings and re-do the rfury and seal assignment). Its modular nature will also be easily expandable whenever Blizzard releases triple spec (it'll happen, it may take years but it'll happen, the code to allow an unlimited number of specs is already in the game and they are toying with the idea of 3 specs).
    Posted in: General AddOns
  • 0

    posted a message on PallyPower - Official Thread
    Actually, it would be even cooler if it was implemented as some sort of "set" system where you can do /pp save tanking and /pp load tanking, to save/load a set of auras, seals and blessings. That way you can implement it in macro buttons to easily swap all at once. That would be INCREDIBLE.

    Such a system of user-named sets would also be easy to tie into specs, like "on Spec swap, if spec==1 activate set named "tanking" else activate set named "healing"".

    That really would be a superb solution.
    Posted in: General AddOns
  • 0

    posted a message on PallyPower - Official Thread
    Another vote for dual spec support, by storing each setting as a subtable independently in the table as something like [spec1] and [spec2], and just read from whatever one the current spec is, on spec change.
    Posted in: General AddOns
  • 0

    posted a message on AHsearch
    Kunda: Okay fair enough. Keep up the good work! ;-)

    Edit: Wait a minute... I accepted the "confusing to manage" part before I noticed that you DO use the Curse packer. Hehe.

    It's not confusing at all to make a nolib version with the packer. Here's the .pkgmeta documentation:

    http://kb.curseforge.com/projects/pkgmeta-file/

    Using the pkgmeta you can make it automatically write both a regular zip and a -nolib zip (only downloadable by the client). It couldn't be easier to manage, for what it does! :-)

    Here are the special .toc keywords:

    http://kb.curseforge.com/repositories/repository-keyword-substitutions/

    Now, to make an automatic -nolib version that requires no work for you, do this:

    In the .toc file:
    ## OptionalDeps: Ace2, DewdropLib
    
    #@no-lib-strip@
    libs\AceLibrary\AceLibrary.lua
    libs\Dewdrop-2.0\Dewdrop-2.0.lua
    #@end-no-lib-strip@


    Note how there's NO hashmarks (#) on the lines between the no-lib-strip parts. That's what the curse packer comments out when it automatically makes the nolib version.

    The only other step is to edit the .pkgmeta file as follows:
    externals:
        libs/AceLibrary:
            url: svn://svn.wowace.com/wow/whateverthesvnpathistoacelibrary
            tag: latest
        libs/Dewdrop-2.0:
            url: svn://svn.wowace.com/wow/whateverthesvnpathistocallbackhandler
            tag: latest
    
    enable-nolib-creation: yes
    


    After these two changes, each time you tell Curse packer to pack your project, it will AUTOMATICALLY create two files:

    "If your project has libraries, two zips will be made, one with libraries (main one) and one without, the -nolib version."

    The -nolib version will ONLY be accessible from Curse Client and if the user has set his client to nolib mode. In that case it downloads the -nolib zip as well as all libraries (if you don't already have them).

    Nolib leads to faster loading (no need for WoW to parse let's say 1500 extra files, IF the libraries had been embedded for every addon I use), less problems (ensures that the latest version of a library loads cleanly without 20 other versions running their load procedures, seeing that another version was loaded, and aborting load), and as mentioned it puts less strain on the file system too. The file system is a big database and it's the snappiest at lookups when you don't overload it with frivolous files that could be avoided.

    So give it a spin kunda, it's not hard, it's just a big benefit to everyone, and you won't get user reports since there's nothing to report (the client ensures the libraries are downloaded, and it also makes clear that enabling nolib mode is for experts). From curse.com's manual download, and for 99% of users with the client, things will carry on as usual, but for that 1% they'll get an autogenerated zip without libraries. Could it be easier?
    Posted in: General AddOns
  • 0

    posted a message on AHsearch
    Hahaha, yeah I feel your pain. You managed to solve the -nolib boogie with the newly updated version to replace the old one. Good work!

    However, why are you so afraid of a nolib version? Yes, you don't want people to whine that the libraries are missing. But they WON'T be missing, because the only way to get the nolib version is to use the curse client, and if you do that, it installs the libraries.

    Perhaps you're thinking about the 3.2 LoadAddOn() bug? It doesn't matter, Blizzard is bound to fix that, because it causes errors even in their default UI without any addons (Blizzard_BattlefieldMap is load on demand).

    Also think about all the successful addons with nolib versions, here are some high profile examples:
    Ackis Recipe List
    ag_UnitFrames
    Atlasloot
    Bartender
    ButtonFacade
    ElkBuffBars
    Fubar
    Grid
    kgPanels
    Omen
    Prat
    Quartz
    RatingBuster
    Recount
    ScrollingCombatText (SCT)
    Skinner
    Talented
    XLoot


    Why not make a nolib version with the method above? There's no harm if done right. It benefits the user who has less files to load during WoW launch, less files to fill up the filesystem, less conflicts, and less strain on the Curse servers (nolib versions are smaller downloads), as well as ensuring that the library is always up to date. Also, if the reason for bundling the library was to make sure you only use supported versions of that lib (and not newer versions that may break your addon), that's futile, because if you have a newer version of that library anywhere (inside another addon or as a separate folder), that version will overwrite the old one in memory.

    So those are some reasons to not fear a nolib version. :-)

    Take care!
    Posted in: General AddOns
  • 0

    posted a message on AHsearch
    Quote from kunda
    There is no *-nolib version of AHsearch.
    Okay, there was a *-nolib version online for about 1 minute, than I deleted it.

    Please download AHsearch-30200-1.zip (http://www.wowace.com/addons/ahsearch/files/ or attached file at first post of this thread)


    I see, then that file is not properly deleted from CurseForge or WowAce (whichever upload method you're using), because Curse Clients keeps re-downloading "30200-1-nolib (Released: 2009/08/05)" which lacks the libraries.

    Anyway, to make a no-lib version is very easy, just do this to the .toc file:

    ## OptionalDeps: Ace2, DewdropLib
    
    #@no-lib-strip@
    # libs\AceLibrary\AceLibrary.lua
    # libs\Dewdrop-2.0\Dewdrop-2.0.lua
    #@end-no-lib-strip@


    That's enough to make it load the libraries separately if they exist, or internally if you bundled them. You'll then just have to do something in the packer so CurseClient knows which libraries to download separately for the nolib version.

    Those two changes make the nolib version work.
    Posted in: General AddOns
  • 0

    posted a message on AHsearch
    Error occured in: Global
    Count: 1
    Message: ..\AddOns\AHsearch\AHsearch.lua line 51:
    Cannot find a library instance of Dewdrop-2.0.
    Debug:
    [C]: ?
    [C]: error()
    Ace2\AceLibrary\AceLibrary.lua:490: AceLibrary()
    AHsearch\AHsearch.lua:51: in main chunk
    Posted in: General AddOns
  • To post a comment, please or register a new account.