In it's infancy, Ace was intended to be a minimal framework for providing the common-ground that ALL addon's use. An event-frame, some enable/disable methods, a common database system, etc..
Over time and with the development of Ace2, it has gone from focusing on being a small, efficient tool...to an all-out addon creation kit and abstraction of the LUA language, aimed at helping new users get their feet wet as well as experienced users reduce their development time. This however, has come at the cost of size and efficiency. Ace has also shifted from being a primarily "behind-the-scenes" development tool to a full-fledged community, complete with addon distribution and support. Even has become a "selling point" for alot of mods (all thou this shouldn't happen, and I hope that it never happens again with any framework, since this kind of thinking encourages ignorance)
This is where Dongle came from. It's back to the original roots and ideals of the Ace(1) project. A minimal, efficient, and most importantly transparent developer tool. Unless you are the person writing an addon, you shouldn't even care that Dongle exists. You won't ever see a wowdongle.com, you won't have a cute litte -Dongle- tag behind the names of your addons in your addon list, you won't even see a central repository for "all things dongle" so to speak. Individual authors tend to have a google-code project for their mods, and release versions wind up on WowInterface.
Ace2 is very robust, very useful, and has it's own merits. Dongle is still in it's infancy, and it also has it's own pros and cons...but unless you are writing something, you shouldn't give a crap one way or the other.
- Registered User
Member for 10 years, 9 months, and 17 days
Last active Fri, Oct, 4 2013 14:32:22
- 0 Followers
- 820 Total Posts
- 0 Thanks
Jul 10, 2007My current copy is much different than that alpha I posted, but it's also much more functional :) There is no way yet to edit the settings aside from editing the lua file, and until I get an in-game way to mess with things I'm not releasing anything.Posted in: Addon Ideas
If you don't mind hacking up the lua file for the settings you'd like (its not that hard) you can check-out a working copy from my google-code:
(And before anyone thinks of asking...no it is not Ace, and it will most likely never be on the SVN)
Jul 10, 2007This should be very possible (just dosen't exist yet :))Posted in: Addon Ideas
When you boil it down, any addon's settings are stored in a table. All you'd have to do, in theory, is take the current table...back it up (to the profiler's saved variables)...and inject a new table (that had your second set of options.) Then reload the UI and walla, new settings. To revert it would simply do the opposite.
It's simple in theory at least :P
Jul 10, 2007This isn't going to stop non-guilded members getting into the channel and then locking it (with a new password). The problem isn't simple ignoring the spam, its an actual security issue of keeping people out, and the only way to limit access to a password protected area, is to limit who knows the password (something hard to do in a guild of 3000).Posted in: Addon Ideas
Hence I'm back to thinking the best solution is to simply not let the end-users see the actual channel / password...the addon in question should simply do the joining/leaving/masking for the user, so they *think* they are in [5. PAA] with no apparent password when they are really in [5. k8l9fg] with a password of '28dj42'
Jul 10, 2007Kyahx posted a message on Healers targeting me / Players assisting me / action performed / healthbarPosted in: Addon IdeasQuote from OrionShock »
to make it more real/reliable/accurate, everyone would have to have the addon. the addon would be spamming addon messages left and right about nearly everything... ya.. it get complicated and laggy real fast..
I don't think this is neccesarily true anymore. TARGET_CHANGED fires for *every* raid member I believe, so you'd be able to pick up when people target you. If their target is your target, you can assume they are asssiting you. Also I know Pitbull can have cast bars for every since raid unit frame, which leads me to believe pulling casting and spell information is also possible (without others using said mod).
Complicated...yes, but I believe it can be done (and done locally, without making others run something)
Jul 6, 2007http://www.wowace.com/wiki/Category:Inventory_Addons -- The wiki is your friend (I am not)Posted in: Addon Ideas
Jul 5, 2007I think the solution here would be to use a password protected channel, but in a way that the members don't actually know the password themselves.Posted in: Addon Ideas
This could (in theory) be done transparently using an encryption method, and storing the un-encrypted chan/password in say...the GMOD.
Player logs in, the chat mod sees that the GMOD is "awesome:magic:pants". The mod the encrypts the word 'magic' and 'pants' using the word 'awesome' as a key (for the sake of example, lets say 'magic' translates to '12345' and 'pants' to 'abcde')
The mod would then join the '12345' channel using the password 'abcde', and it would be semi-transparent to the user, since they never even know the "true" channel/password. This would also allow (guild leaders) to change the 'key:channel:password' simply by updating the GMOD, should security be compromised.
All in theory, of course :P
Edit: If you wanted you could go even further with that idea, by encrypting all of the chat traffic as well. This would add another layer of security should a non-guild member get in, as they will just read gibberish.
Even if a non-member managed to get-ahold of the mod, they would need to know the unencrypted [key:chan:pass] combo (since they wouldnt have the GMOD to read from), plus would need to know enough about LUA to modify their local copy to input that combo by hand.
Jul 3, 2007I also can guarantee that the code I provided is just as efficient as the code in Automaton, seeing as how I copied it strait from Automaton's code. It's not doing anything constant, the ONLY time it does the check is when PLAYER_DEAD fires, becuase that's the only event that the frame is registered with.Posted in: Addon Ideas
Jul 2, 2007Those 4 lines are a lightweight mod, just slap it into a .lua file, make the proper .toc / folder structure and walla. Magic.Posted in: Addon Ideas
Dig around on wowwiki if you don't know how to make a simple toc file / addon folder.
Jul 2, 2007Posted in: Addon Ideas
local f = CreateFrame("Frame") f:SetScript("OnEvent", function() if MiniMapBattlefieldFrame.status == "active" then RepopMe() end end) f:RegisterEvent("PLAYER_DEAD")
If you want it to be small, it won't be Ace2.
Edit: Extra parenthensis at line 2 :P
Jul 2, 2007Kyahx posted a message on AgUnitFrames and Disabling Default Blizzard Player BuffsOr you could do this with two lines of code..Posted in: Unit Frames
Assuming <frame> is the name of whatever the buff frame is (I think TemporaryEnchantFrame ? Don't recall off the top of my head)
Jul 2, 2007After much research, it actually *won't* be very hard to add this functionality to the default action bar.Posted in: Addon Ideas
Stay tuned :)
EDIT: The basic functionality is there. It fucks up with the class stance bars, and the default paging behavior. But what do you expect from a proof-of-concept :)
- To post a comment, please login or register a new account.