Authors CurseForge

Gahhh.  I guess I'll be updating my addons by hand, then.  All good things come to an end.

 

Thanks for responding, and good luck!

 

 

 

This normally would go into the "Updaters" subforum, but those posts are from years ago, so presumably it's dead.  Anyhow.

 

Using client v5, version 5.1.1.844.  (Maybe that's out of date, but it's not updating itself either.)  Starts up with no errors, contacts the server according to its logfile, doesn't report or log any errors or other problems.  But... there are never any updated addons reported for several weeks now.  Looking at each addon's specific page, there are definitely new versions, but the client's not seeing them.

 

Is v5 just completely dead now, in favor of Twitch?

 

And that error would be....?

 

Take a screenshot, write it down, do something so the rest of the world doesn't have to guess.

Instead of unconditionally setting dirtyeditor to true, compare the current value with what was there before, and set dirtyeditor if they're actually different.

 

The code didn't show when you needed to know the value of dirtyeditor.  So if you need to use it after a user has finished editing a field, you test the values in a different place than if you need to use it *while* the user is editing, etc.

 

Ditto everything Phanx said, especially this:

Please just get rid of this monstrosity and use a standard textarea with Markdown or BBCode formatting support. Anyone posting on a forum dedicated to online gaming knows how to use one or both of these formatting systems, and you can even still have UI buttons to insert the appropriate formatting codes/symbols for the people who don't.

I've been participating in the wowace forums for years, because their forums are simple and straightforward and they WORK.

 

This garbage is trying too hard to be unique and special instead of standard, and it's not what developers want.

 

Best bet would be to modify Rarity rather than trying to do it all from scratch. The actual "notice a specific loot" is not hard, but allowing the user to manage the lists of specific loot is a lot of UI coding -- which other addons have already done, and done well. I haven't looked at Rarity code, but I bet changing a couple lines to play loud sounds wouldn't be difficult.

I'll add: if whatever code you're compiling might itself throw errors, you can make your calling code more robust by replacing "assert(func())" with

    -- the function inside primary_definition can return up to 3 values
    -- before we have to either add more holders, or redo this in a
    -- variadic helper function
    local okay, ret1, ret2, ret3 = pcall(func)
    if okay then
        -- ret1 is the table we created
        testtable = ret1
        -- ret2 and ret3 are reserved for future work when this addon is
        -- extended to replace Facebook in-game
    else
        -- ret1 is an error message
        print ("shit continues to be on fire", ret1)
    end

Keep in mind that:

1. the code given to loadstring is the guts of a function
2. the eventual function runs in the global namespace by default, unless you change its environment

So, try something like this for a starting point:

local primary_definition = [===[
    print "compiled code running!"
    return {
        ["a"] = 1,
        ["b"] = 2,
        ["c"] = special_data,   -- global variable as far as it knows
    }
]===]

Passing arguments into your compiled function is a bit tricky. You can put everything in globals (sloppy but easy), or you can assemble the code string around them (precise but can be hard to read/maintain), or you can replace the namespace for that function. For the last method, you stuff all the things you want that function to see into a specific table. Advanced mode: chain that table into the actual global namespace, so that you don't break normal name lookup.

local fake_globals = setmetatable({
    special_data = 42,
    ....other_stuff_as_appropriate.... = whatever,
}, {__index = _G})

If you don't know all the values you need at the time you create that table, or if you need to change them during runtime, it's just a regular table. This is how you can give your compiled function access to other local names, which loadstring() doesn't see:

local actual_local_variable = 12345
fake_globals.special_data = actual_local_variable

Building the function looks like this:

local func, err = loadstring (primary_definition, "Your Addon's Name")
if func then
    -- Make the compiled function see this table as its "globals"
    setfenv (func, fake_globals)
    -- Running the code in primary_definition returns a newly created table
    -- with a/b/c indices
    local testtable = assert(func())
else
    print ("shit's on fire, yo")
    print (err)
end

The argument for your addon's name is just for something to show in stack dumps if loadstring() can't compile your code.

The "time to execute" has never been the savings for nolib. It's the time spent reading in the full contents of the files, parsing them, and generating bytecode. That will happen for every file listed in the toc, unconditionally, regardless if "whoops, nvm, return" is executed a few instructions in.

Ace3 itself does not have anything for sharing data across files. Your best bet is, as you suspect, to use the "local addonName, sharedTable = ..." and stick something inside sharedTable.

Note that if you're using AceAddon, the :NewAddon() function optionally takes a table as its first argument, and will build the addon's infrastructure inside that table instead of creating a new table. If you pass the sharedTable pointer as that argument, your core file can then look like

local addonName, addon = ...

-- ... stuff ...

addon = LibStub("AceAddon-3.0"):NewAddon (addon, addonName, "other", "libraries", "here")

function addon:OnWhatever()
    ... self.myFrame ...
end

and other files loaded later in the .toc can be

local addonName, addon = ...

addon.myFrame = CreateFrame(..........)

Quote from Azmaedus

Ok, now I understand. I thought GJB: Disable() would put the addon in a "non functioning" state; no event triggers whatsoever except OnEnable

Well, only the "event triggers" that Ace3 knows about.

The things you register with, for example, AceEvent will be non functioning. But :Disable has no way of knowing which frames to hide or which buttons to ignore. That's what your OnDisable has to do: hide frames, disable buttons, whatever.

Try that, then post that version of your code.

Quote from Azmaedus

Maybe I misunderstand the use of the AceAddon:Disable() function. I presumed that this function disabled the addon entirely like when you select what addon you want enabled in the addon options on the game login screen.

Ah. No, I'm afraid you have misunderstood.

AceAddon:Disable() simply provides a way to programmatically "turn off" an addon from other addons. What it does exactly is to call the "OnDisable" methods of your addon, along with any modules and embedded libraries. For example, AceEvent will stop responding to events, AceComm will stop listening to messages, and so on. What your addon does in OnDisable is up to you.

What you want to use can only be done by calling DisableAddOn, which is a global function and unrelated to Ace. (The names are unfortunately similar. The Ace library was, I think, slightly earlier than the ability to disable addons from within a running session using the API. In any case, they have nothing to do with one another.)

Quote from Azmaedus

What I want to achieve is to disable the whole addon 'MyAddon' previously created with

MyAddon = LibStub("AceAddon-3.0"):NewAddon("MyNewAddon", "AceConsole-3.0", "AceEvent-3.0", "AceTimer-3.0", "AceComm-3.0", "AceSerializer-3.0")

The return value I obtain is true, saying the disable method worked, but the addon is still usable. Any clues?

Clues are being prevented because 90% of your post is concerned with the AceGUI frame. :-) What, exactly, do you mean by

but the addon is still usable

? What is "usable" in this context? Are there event handlers registered? (I can't tell, because you didn't show the code.) Are there slash commands that you want to stop functioning? You need to show that code. Is the frame 'f' still visible? That doesn't make sense if, as you say, "the return value I obtain is true, saying the disable method worked". How can you tell what the return value was? Are you printing it out? Then show that version of the code, please, because that's not what we're seeing.

Everything myrroddin is saying is true, and you should take it to heart. You should also show your complete code, or put it in a pastebin and link to it, and explain what you want to be "disabled" that you think isn't being disabled.

What, exactly, do you want to change? The colors, the name being printed, the formatting...?

If you're trying to change the name displayed, overwriting the 'name' field in your composed addon table will do it, and I don't believe it'll screw up anything else. Alternately, replacing getmetatable(your_addon_table).__tostring with a function returning what you want will also have the same effect.

Colors are hardcoded, so you'd have to declare a new your_add_table:Print[f] pair of functions and replace the ones "inherited" ("mixed in"?) from AceConsole.

FWIW, I occasionally run into crazy tag problems with one of my larger addons. I'm using Mercurial, and as a workaround I occasionally move tag entries out of .hgtags and into .hg/localtags (which isn't pushed to the server).

It's a horrible abuse of tags, but it means that when the packager goes bonkers and begins repackaging *every* tag as "the latest", it's limited to a small handful and not all of project history.

Maybe Git has something similar you could temporarily abuse?