• 0

    posted a message on pkgmeta -- Specifying Git repo subfolders?
    No solution, but some explanation:

    Quote from Phanx
    In the externals section of my .pkgmeta file, how do I tell the packager to only pull in a specific subfolder from a Git repository?


    Subfolder checkout is a unique feature of Subversion. Git does not provide it.

    Quote from Phanx
    And finally, if I try using the SVN URL that GitHub provides (since they support basic operations over SVN) the packager still seems to be attempting to use Git


    I think the packager should be modified to distinguish the Subversion and Git repositories URLs:

    Posted in: General Chat
  • 0

    posted a message on Forum cleanup suggestion
    Quote from Torhal
    It's actually GitHub, BitBucket, and local hosting. Some people actually want to use the former two, so we'll have web hooks to allow packaging when they make commits there.


    Woohoo !

    Quote from Phanx
    I'm currently using GitHub for a few projects, because their on-site developer tools (code viewing, version diffs, TICKETS!, automatic ticket management via commits and email) are so good


    Plus you can use CI platforms for open-source, if you feel like writing some automated tests.

    Quote from Phanx
    since TortoiseGit is buggy and there are no other shell-extension Git clients.


    Have you tried gitextensions, https://code.google.com/p/gitextensions/ ? (Disclaimer: I don't use it myself, I stick to git CLI + git gui/gitk).
    Posted in: General Chat
  • 0

    posted a message on Global & SavedVariables Help
    I would recommend using AceDB-3.0. It deals with all the shenanigans for you and can be later used to add a profile-switching feature.

    Download Ace3 and copy the folders named LibStub, CallbackHandler-1.0 and AceDB-3.0 into a libs subfolder of your addon.

    Add this in the TOC file:

    ## SavedVariables: DejaViewDB
    
    libs\LibStub\LibStub.lua
    libs\CallbackHandler-1.0\CallbackHandler-1.0.xml
    libs\AceDB-3.0\AceDB-3.0.xml


    And this in your Lua file:

    local DEFAULT_SETTINGS = {
        -- We will use the "char" section, which is specific to each character
        char = {
            -- No need to append "default" to all names
    	dvb = {0, 0}, 
    	dvdb = {0, -60},
    	Minimap = {0, 0},
    	dvpet = {0, 6},
    	dvstance = {0, 6},
    	dvrsb = {0, 0},
    	dvmm = {0, 6},
    	stat = {0, 0},
    	dvbag = {0, 0},
    	dvgtt = {0, 0},
    	DebuffButton1 = {0, -6},
        }
    }
    
    local settings
    
    local dejaview = CreateFrame("Frame", "DejaView")
    dejaview:RegisterEvent("ADDON_LOADED")
    dejaview:SetScript("OnEvent", function(self, event, arg1)
    	if event == "ADDON_LOADED" and arg1 == "DejaView" then
                    -- Initialize the database
                    settings = LibStub('AceDB-3.0'):New("DejaViewDB", DEFAULT_SETTINGS)
    		self:UnregisterEvent("ADDON_LOADED")
    	end
    end)
    
    -- Then use settings, e.g.:
    local dvb = settings.char.dvb
    
    -- Or set them:
    settings.char.dvb = {6, 7}


    AceDB-3.0 will take care of handling the default and saving the variables per character.
    Posted in: Need Help?
  • 0

    posted a message on Mobile app
    These API only give read-only access.
    Posted in: Addon Ideas
  • 0

    posted a message on Embedded library
    For the sake of completeness: some libraries do a "little more" when embedded using AceAddon-3.0, because AceAddon-3.0 searchs and calls the library methods OnEmbedEnable and OnEmbedDisable when the addon is enabled/disabled. For example, AceEvent-3.0 automatically unregisters all events and messages when the addon is disabled.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Why won't this work???
    By order of increasing importance :
    • You do not need to name your button "ExtraButton1". This will create a global variable with the same name. At least name it MyUI_ExtraButton1 or something like this.
    • MyUIVersion is a global that will probably not be saved.
    • I am pretty sure SecureActionButtonTemplate does not create btn.icon. This should cause an error. Have you enabled the display of errors ? or are you using a error catching addons like !BugGrabber+BugSack ? As this should happen just before the call to :SetPoint, it should prevent the button from being displayed.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Lua OOP coding style.
    Phanx is totally right about using (or not) OOP in addons. However, if you wanted to write OOP in lua, there were several ways to do it.

    One is the factory approach : create a self-contained object with a factory method (see http://www.troubleshooters.com/codecorn/lua/luaoop.htm). On the plus side : you can have private variables (but only private, not protected). On the minus side : inheritance is harder to manage.

    Another one (and that I personally prefer) is what Lombra is doing : use metatables. You can't have private variables but inheritance is possible. IMO, it is easier to give up private variables than inheritance.

    There may be other ways.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Explaining this SetScript to an idiot.
    Quote from theultimateend

    local profession = ProfTable[id] -- Each time the script runs it makes the word "profession" equal to the current table identifier. So profession on the first run is the same as typing ProfTable[1].



    Are you sure you get the concept of variable ?

    "the word "profession" equal to the current table identifier" is an awful wording for what happens.

    A variables is like a box with a label on it. The label is the name of the variables. Each time we use the variable name in the code, we work with the content of the box. E.g. :

    "x = 5" puts 5 in the box labeled "x".
    "y = x * 5" gets a copy of the content of the box labeled "x", multiply it by 5 and put the result in the box labeled "y".

    Tables are containers. A table is like a shelf of labeled boxes. Labels are the indexes of the table, and we work with the content of the boxes. When you create a new, empty table, a empty shelf is created somewhere in the building and you are given its location (its reference). When passing you the table around you are actually copying its location and not the whole shelf.

    t = { 6 } -- create an shelf with one box on it, labeled 1, and put 6 in that box, then put the location of that shelf in the box labeled "t".
    t.foo = 5 -- use the content of the box labeled "t" to find the corresponding shelf then put 5 in the box labeled "foo". If there is no box labeled "foo" on the shelf, create it.


    When you nest a table into another, you simply put the location of the former shelf in a box of the latter one.

    Quote from theultimateend

    Now where or how is the addon figuring out what profession equals on the first run, as opposed to the /reload run.


    Each time you reload, the Lua interface is completely reset. All the addons are loaded and started again. The subtle difference is that some data may be available at the very start after a /reload because the C code is NOT reset. However, for all intent and purpose, you should consider the case of the first connection, with missing data, because most of people does not want to /reload each time they log in.

    Quote from theultimateend

    We haven't told it that profession = ProfTable[id] until a piece that can only be accurate the second time we run it?

    I feel like the object is looking at a different location than we are creating, which is why the tooltip is always failing to find its target (it gets pissy about concatinating "name").


    So you have the write a piece of code that can handle the lack of information (i.e. nil). This is quite common with wow addons, since most data are not available at loading time.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Explaining this SetScript to an idiot.
    Quote from theultimateend
    So in this example I presume that "t" is short for whatever the name of the table is?


    i and t are just the variable names I wanted to use inside my "for" loop. They have no other meaning (beside "i" for index and "t" for table, but that's just a convention) and have no use outside of the loop.

    Quote from theultimateend
    Or does Lua assign the name of the table to t when using the function in this manner?


    Tables are passed by reference. So when iterating ProfTable, t will point to each actual tables of ProfTable. I.e. inside the loop, ProfTable[i] and t are strictly equivalents.

    Quote from theultimateend
    if the table are random shouldn't this


    They are not strictly random. Iterating them with pairs() returns theirs items in an order determined by their implementation (which we does not know) and we cannot make any assumption about this order: maybe items will be in the right order, maybe not; maybe items will be in the same order every time, maybe the order will change each time you iterate the whole table. In the contrary, ipairs() guarantees that it iterates the table using an numerical index in ascending order.

    Have you given a look at the Lua table tutorial ?
    Posted in: Lua Code Discussion
  • 0

    posted a message on Explaining this SetScript to an idiot.
    When using tinsert() to populate ProfTable, think of it as being in "list mode" (which is not completely accurate but enough to grab the concept). In this case, you can get the number of items using #ProfTable, and when iterating it, the first value returned by pairs() is the index (not the id). {} creates a empty table, which is different from nil (remember that nil means not-in-list), so inserting an empty table into ProfTable does create an entry.

    Also, pairs() iterates in random order and though it is valid to use it with "lists", it is mostly used with "maps" (tables with non-numerical and/or sparse indexes). If this is an issue, use ipairs() instead, it iterates the list element in numerical order.

    Last but no least, pairs() (or ipairs()) does not know about the content of the table values (second value of the for loop). There is no way it can returns that value of the "id" member of these tables (which can be anything by the way, not only tables). E.g. you can do this:

    local someTable = {}
    tinsert(someTable, { id = 25 })
    tinsert(someTable, { id = 2 })
    tinsert(someTable, { id = 1 })
    for i, t in ipairs(someTable) do
      print(i, t.id)
    end
    -- Prints:
    -- 1 25
    -- 2 2
    -- 3 1
    Posted in: Lua Code Discussion
  • 0

    posted a message on Explaining this SetScript to an idiot.
    This is a more verbose way to write this piece of code:

    local function DispatchEvent(self, event, ...)
      local handlerMethod = self[event]
      handlerMethod(self, ...)
    end
    f:SetScript('OnEvent', DispatchEvent)
    f:RegisterEvent("TRADE_SKILL_UPDATE")
    
    f["TRADE_SKILL_UPDATE"] = function(self)
      --[[ function body ]]
    end
    


    As you might know, Lua objects are actually tables. Methods are functions, usually accepting "self" as their first argument, assigned in that table by their name. So self[event] gets the method named by the event and the next line calls it.
    Posted in: Lua Code Discussion
  • 0

    posted a message on :Click and /click accepts any button argument
    I'm not sure whether /click accepting any string is the "unintended result of [Blizzard] laziness" but SecureActionButtons do handle "virtual buttons" (i.e. any string), as mentioned by the comments about SecureActionButton in FrameXML/SecureTemplates.lua.

    Anyway, as you cannot automatically modify macros or the actions in response to these virtual buttons in combat, it is still quite rigid. It is mainly a way to provide several different features using only one secure button.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Fixing the Interface Options Cancel button taint
    Quote from Phanx
    If people can't figure out how to use their addons, and their stupidity is causing a problem in the raid, the solution is simple -- remove that person from the raid. If they continuously cause problems, stop inviting them to raids. Either they will figure it out, or they are not raid material. No serious guild I have ever been in has had any tolerance for idiots who hold up the raid with addon problems.


    Well, I'm in a guild with a core of real-life friends, and most of the members are somehow related to someone of this core in real life. We play together because we are friends. If some of them are "addon-challenged", we help them instead of excluding them for that reason.

    Anyway, back to the topic: as I said, the "open GUI configuration" feature of my addons are broken without the InterfaceOptionsFrame_OpenToCategory fix of BlizzBugSuck. If it is eventually decided it cannot become an embeddable addon, I'll look to make it a required dependency of my addons, but I find this solution less neat.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Battle Pet Addons Broken
    What you describe looks like severe network lag, but I am not aware of any addons that caused such lag. Maybe Blizzard introduced a bug with latest patch that is triggered somehow by pet addons. Anyway, as Elkano suggests, try to see if any addon is causing lua errors.
    Posted in: Need Help?
  • 0

    posted a message on Packager changing .toc name
    I already had this issue :

    For some reason, the left part of the move folder is interpreted as CouncilLootMaster/Council*, e.g. it will rename/move any file or directory that starts with CouncilLootMaster/Council. In your case, this include CouncilLootMaster/CouncilLootMaster.toc, which is renamed to
    CouncilLootMaster_CouncilLootMaster.toc.

    If you had something like:

    move-folders:
        CouncilLootMaster/Council: Tomato


    It would rename the directory CouncilLootMaster/Council to Tomato but also the file CouncilLootMaster/CouncilLootMaster.toc to TomatoLootMaster.toc...
    Posted in: Need Help?
  • To post a comment, please or register a new account.