• 0

    posted a message on DataStore

     

    Hi everyone,

    As some of you may already know, DataStore is a series of libraries which, unlike most existing libraries, handle their own SV files.
    More information can be found here : http://wow.curseforge.com/addons/datastore/

    For those of you who do not know what they do, their goal is to be data repositories for client addons, so that new developpers don't have to care about which events should be registered to get specific data, or even how to save them in the most efficient way.

    A Brief history

    I started coding Altoholic a little bit more than 2 years ago, and although I'm a programmer, I did not know anything about Lua, the WoW API, or even the Ace Framework, so I made things work before I made them better.

    This meant having to manage a large database full of information, with the annoying consequence that one false move could hurt the DB and result in having to clean the add-on's SV file. That, and the lack of a clean interface to access my data. So after numerous iterations, I thought that adopting a layered/client-server approach could be a solution to my problem, and if it could help other authors at the same time, that would be the cherry on the cake.

    How it works

    DataStore is the main module, it contains character/guild keys to address the information stored by the other modules.

    Samples can be found here : http://wow.curseforge.com/addons/datastore/pages/api/

    Pros & cons

    I have been using DataStore since July 2009, and the biggest advantage I found was that having a single interface to access data is pure bliss from a coder's perspective. There is less need for integrity checks since DS does them for you, and more than anything, data is shared for client addons. I currently use them in two projects, Altoholic & Odyssey, but I'm confident that more addons could benefit from this work.

    Another benefit I see is that having a limited number of addons registering the same events avoid conflicts/deadlocks, since client addons basically get rid of this issue. Bag addons, for instance, no longer have to care about which event to register to get bag updates, and especially about when is the right time to do that.

    On the other hand, the biggest inconvenient I have faced so far is packaging issues.

    At this point, DataStore and its modules are all separate projects, so the svn repository cannot copy them into an addon's package since they would have to be at the same level as the client addon's folder.

    Ex: Under Interface\Addons\
    - Altoholic\
    - DataStore\
    - ...
    ShowBox Mobdro TutuApp
    This means that release packages have to be assembled manually. It's a pain, but I live with it until I find a better solution...

    About the future

    .. which is where this post comes into play. As I mentioned above, I have been using DS since last summer, and I intentionally waited until I felt certain that the approach was right before making it a bit more public.

    What I need now is a peer review, and suggestions on what is right/wrong. The approach is right, but it's perfectible, and seeing how my backlog is growing, I would gladly welcome more hands on the project :)



    Just to give an idea, here are some targets I have for the libs:
    • Add support for data export (to xml, or whichever format).
    • Review packaging options. Mikk suggested me to have turn the libs into simple addons that only contain the SV file, and to put all the code into real libs, that's a valid alternative.
    • Add support for LDB feeds.
    • Add more methods/options to each modules.
    • etc...
    Feedback would be greatly appreciated :)
     I think you could have the packager to layout the folders as need using .pkgmeta:

     
    Posted in: Libraries
  • 0

    posted a message on LibActionButton-1.0

     

    Quote from Nevcairiel >>
    LibActionButton-1.0 is a library to create and manage Action Buttons. And when i say action button, i don't necessarily mean buttons that are limited to the 120 actions the game gives you.

    LibActionButton-1.0 implements a full replacement button which can either use the 120 actions provided by the game, or alternatively be completely independent of those actions, and directly use spells, items, macros, etc, letting the addon using LAB-1.0 manage the contents of the buttons.
    Of course, actions and non-actions can also be mixed.

    The whole button handling code, while roughly modeled after how Blizzard manages their buttons, has been cleaned up and optimized quite a lot. Replacing the whole default UIs action buttons with LAB-1.0 based buttons will increase your performance, even if not by much.

    Features
    - 100% support for Action-based buttons.
    - 99%* support for non-action based buttons, containing spells, items, macros**.
    - LibKeyBound-1.0 integration
    - ButtonFacade support
    - Configuration of the buttons through a config table
    - Static Buttons (Disable Drag'n'Drop, so the user cannot change the contents of the button - only for non-action)

    * 99% because Drag'N'Drop in combat is not 100% the same as for action buttons. You can drag a spell on the button, but only with a real drag (keep mouse button pressed from action pickup to action drop). Having the action on the cursor and clicking on the button to drop the action only works out of combat.

    ** Macros are not fully supported yet. You can drag them on buttons, and the macros will be cast when you click them, however alot of visual feedback is still missing.

    ToDos
    - Finish Macro support
    - Pet Action support (replacing the pet bar)
    - Add support for non-combat pets/mounts on the buttons
    - New 4.0 "flyout" action support
    - Extensive Testing

    Maybes
    - "Auto-Assist" option from Bartender

    Requirements
    - Requires WoW 4.0
    - Its currently required to have a secure header driving the buttons.

    Primarily aimed at replacing the custom Action Button code in Bartender4.5, i decided to make it a proper library, for everyone to benefit.

    If anyone is creating secure buttons with custom actions on them right now, this could be potentially interesting for you. For example, this could be addons that provide bars for Hunter Aspects, Mage Portals, or something generic like AutoBar. Any kind of button that holds items or spells, and needs to behave like a typical Action Button, can make use of this library, and get rid of all the interfacing to the restricted environment and event handling.

    Project: http://www.wowace.com/addons/libactionbutton-1-0/
    API: http://www.wowace.com/addons/libactionbutton-1-0/pages/api/
    Torrent TurboTax Gogoanime
    If anyone is interested in using it, i would appreciate any feedback and features you might need/want.
     I'll expand on the non-action functionality in the coming weeks, mostly as i need it in Bartender
     
    Posted in: Libraries
  • 0

    posted a message on PeriodicTable-3.1

     

    Quote from Toadkiller >>
    So lets kick this off with a discussion of one thing that sucks in 3.1:
    It is no longer compressed. For AutoBar this bloats the data by 500k in the 4 major files that are included vs the exact sets needed. Is there a reason its not compressed? Do we want to start compressing again? human readable is nice for debugging of course.

    I am open to suggestions:
    One thing I want to do is roll a custom file that AutoBar needs with the exact sets required. Especially under current conditions this saves a lot of memory.

    Another idea I had is to pre (post?) process PT3.1 and just save off the results and refresh that when the minor rev changes and then not load the lib when not necessary. So basically for a login session, set access is tracked and the result sets saved off. On next login these sets are available already or if an unknown set is queried PT3.1 loads and gets the new set. Not sure how you would dump stuff that stops being used. Maybe track logins with some ascending number & use cache algorithms to dump apparently unused stuff.

     


    This works great for static PT3.1 use like in AutoBar. Browsing mods would have to skip the mechanism and use the current API. I guess that implies doing this as an API layer on top of PT3.1
     I'll repost this in this thread (btw I locked the old one for you Toadkiller)... PeriodicTable-3.0 included an ItemSearch function for searching data; this was useful, for example, for finding out which boss dropped a specific item. Here's an adapted version for 3.1 that works from within an addon (I'm using it in my branch version of TooltipExchange
     
    Posted in: Libraries
  • 0

    posted a message on PeriodicTable-3.1

     

    Quote from Toadkiller >>
    So lets kick this off with a discussion of one thing that sucks in 3.1:
    It is no longer compressed. For AutoBar this bloats the data by 500k in the 4 major files that are included vs the exact sets needed. Is there a reason its not compressed? Do we want to start compressing again? human readable is nice for debugging of course.

    I am open to suggestions:
    One thing I want to do is roll a custom file that AutoBar needs with the exact sets required. Especially under current conditions this saves a lot of memory.

    Another idea I had is to pre (post?) process PT3.1 and just save off the results and refresh that when the minor rev changes and then not load the lib when not necessary. So basically for a login session, set access is tracked and the result sets saved off. On next login these sets are available already or if an unknown set is queried PT3.1 loads and gets the new set. Not sure how you would dump stuff that stops being used. Maybe track logins with some ascending number & use cache algorithms to dump apparently unused stuff.

     


    This works great for static PT3.1 use like in AutoBar. Browsing mods would have to skip the mechanism and use the current API. I guess that implies doing this as an API layer on top of PT3.1
     I'll repost this in this thread (btw I locked the old one for you Toadkiller)... PeriodicTable-3.0 included an ItemSearch function for searching data; this was useful, for example, for finding out which boss dropped a specific item. Here's an adapted version for 3.1 that works from within an addon
     
    Posted in: Libraries
  • 0

    posted a message on Can't call function

     

    Quote from Circoo >>
    I have made a lot of changes and now i get error
    attempt to call method 'BGCallouts_func' (a nil value)
    If i get it right the function cant be found so i must have made a fail in how to declare the function i guess . Can i get a hint what i missed and why function has a nil value?

    function BGCallouts:ZONE_CHANGED_NEW_AREA()
    self:BGCallouts_func(GetZoneText()) -- error
    end

    ....

    local function BGCallouts_func(msg)
    -- BGCallouts:Print(msg)
    if (msg=="Arathi Basin") then
    ArathiBasin:Show(true)
    elseif (msg=="Deepwind Gorge") then
    DeepwindGorge:Show(true)
    elseif (msg=="The Battle for Gilneas") then
    Gilneas:Show(true)
    elseif (msg=="Eye of the Storm") then
    EotStorm:Show(true)
    else

     


    self:BGCallouts_hide()
    end
    return
    end
     That may prevent the error but it won't actually work the way you probably expect.
     
    Posted in: Project Discussion
  • 0

    posted a message on Addon file not downloading correct version

     

    Quote from bhaskell >>
    My addon SpecCheck was updated with a new version a few days ago. The file shows as available download on curse, but my client only shows the previous version and does not offer an update. Does anyone know if there's a way to check if you still need to wait for approval? even though the file is available to download, but as an "other" file?

     

    Thank you.
     with synchronization between CurseForge and the Client. I'll poke someone about it.
    Posted in: Project Discussion
  • To post a comment, please or register a new account.