Ace
Ace∞ is a framework to allow and encourage mods to work together in a modular fashion. Basically, if a mod is an
Ace∞ mod, it allows its author to embed other
Ace∞ mods within it, so you don't have to install these other mods in order to enjoy their functionality -- they're wrapped up in the one mod you install. The power of
Ace∞ is that when you have multiple Ace mods all using the same embedded libraries and mods, it will ensure that you are only running one instance (and better still, the most up-to-date instance available) of each mod. This means that Ace mods tend to be more resource-efficient.
For example, say you have three stand-alone
Ace∞ mods, X, Y, and Z. X only uses the basic
Ace libraries∞ (we'll call them 'L') -- it doesn't embed any additional mods within it. Y uses X's features, so it embeds X within it. Z depends on Y, which depends on X, so it will embed X, Y, and Z. Now you've explicitly installed all three of these mods, so your Interface/Addons folder looks like this:
- Addons
- Blizzard UI Schtuff
- X
- lib
- L
- Y
- lib
- L
- X
- Z
- lib
- Y
- X
- L
...as you can see, each separate mod has its own 'lib' folder, which contains the stuff it needs to run. You could rip your X or Y mod out of your Addons folder, and Z would still run quite happily. As a matter of fact, X and Y would run just fine, too, but let's say you're kind of anal about your mods, and so you make a habit of explicitly installing the latest version of the mods you know you want. So you've got X, Y, and Z.
Now, when you start
WoW, it will load X, Y, and Z. In fact, it will load some of those mods several times. If these mods weren't
Ace∞ mods, that would suck, because you'd have all these separate and completely redundant instances of your mods running. But Ace will manage that for you to keep things efficient. To take our previous example, let's add some version info:
- Blizzard UI Schtuff
- X v1.0
- lib
- L v1.0
- Y v1.0
- lib
- L v1.0
- X v1.0
- Z v1.4
- lib
- Y v1.2
- X v1.3
- L v1.0
...so when you fire up
WoW, you'll end up with all of these mods running:
- L v1.0
- Y v1.0
- L v1.0
- X v1.0
- Z v1.4
- Y v1.2
- X v1.3
- L v1.0
...arranged alphabetically:
- L v1.0
- L v1.0
- X v1.0
- X v1.0
- X v1.3
- Y v1.0
- Y v1.2
- Z v1.4
As you can see, we've got three instances of L running, three instances of X running, two instances of Y, and one of Z. We really only need one of each of those. So
Ace∞ will cut loose two instances of L (doesn't matter which, as they're all the same version). It will also take the instances of X and Y that Z has embedded, because those are the latest versions. So now these are the mods we have loaded:
- X v1.3
- Y v1.2
- Z v1.4
...and the rest are cut loose and freed up by garbage collection. This ensures that you're only running one instance of each mod, and that the instance you're running is the latest version you have installed.
Ace∞ mods are great for the user, because they're a lot more efficient than other mods. They're also designed in a more collaborative community, so they're less likely to get forgotten and become out-of-date when the original author stops maintaining them. They're also great for the mod author, because of that collaborative community. There's lots of stuff to extend and build upon, and there are a lot of people who can help you figure out how to do what you're trying to do. Also, since Ace developers don't have to re-invent the wheel every time, it allows them to focus simply on the problem they're trying to solve, without worrying about the extra overhead. This tends to make the mods less error-prone and more efficient as well. That said, there is theoretically a bit of performance hit for the loosely-coupled design, and of course, being Ace does not necessarily guarantee that it's good. Crap coding is crap coding, and anyone can try their hand at writing an Ace mod. But all-in-all, the Ace movement seems to be a good one.