aallkkaa's Avatar
08-26-19 07:22 AM by: aallkkaa
LibSpellName2SID-1.1, LibSpellName2SID-1.1-Passives and LibSpellName2SID-1.1-Populator (the later is currenly only available through SVN) have all, as of version 1.1.09, been released under an MIT license.
See file LICENSE.txt included in each addon's folder for details.

This was the plan all along, we'd just never gotten to it...

Spatial Rift Countdown's next version will also be similarly released under an MIT license. And so should any other addons I'll publish in the future (depending on agreement from other co-authors when they exist).
Title of this post pretty much says it all.
The zipped files provided for download would unzip to folders "LibSpellName2SID-1.1.04" and "LibSpellName2SID-1.1.04-Passives", whereas the .TOC files inside were named "LibSpellName2SID-1.1.toc" and "LibSpellName2SID-1.1-Passives.toc"...
1.1.05 has been uploaded and corrects the problem.

I apoologize for the inconvenience.

As a bonus, the databases now include some (not yet all) of the Azerite Essences introduced in WoW 8.2.0.
aallkkaa's Avatar
04-13-19 06:07 AM by: aallkkaa
LibSpellName2SID, and LibSpellName2SID-Passives, have suffered an API change, warranting them a version number jump from 1.0 to 1.1.

The first change has to do with enabling the library in your addon. Whereas before you'd do a simple:
local Lib = LibStub:GetLibrary(LibSpellName2SID);
-- And/Or
local Libp = LibStub:GetLibrary(LibSpellName2SIDPassives);
You should now do:
local Lib = LibStub("LibSpellName2SID-1.1"):NewInstance(YouNameIt);
local Libp = LibStub("LibSpellName2SID-1.1-Passives"):NewInstance(YouNameIt);

The second change has to do with the SID and LSN metatables. Whereas before you'd declare their local alias as:
local SID = Lib.SID
local LSN = Lib.LSN
-- And/Or
local SIDP = Libp.SID
local LSNP = Libp.LSN
You should now do:
local SID = Lib.clients[YouNameIt].SID
local LSN = Lib.clients[YouNameIt].LSN
-- And/Or
local SIDP = Libp.clients[YouNameIt].SID
local LSNP = Libp.clients[YouNameIt].LSN
And then, as you would before, use it like so:
local MySpellID = SID["EnglishSpellName"(string) or SpellID(number)
local MyLocalizedSpellName = LSN["EnglishSpellName"(string) or SpellID(number)
-- And/Or
local MyPassiveSpellID = SIDP["EnglishSpellName"(string) or SpellID(number)
local MyLocalizedPassiveSpellName = LSNP["EnglishSpellName"(string) or SpellID(number)

A third change has to do with the function :SetFaction(...). This is actually what prompted the need for the changes in the whole API. The purpose of having different factions set for different instances of the library (sp. different addons) is os that you can have one addon getting say the Alliance spell IDs 8say the player's) and another getting the Horde ones (say the player's target), or even the same addon getting the different spell IDs for different units.
This is the first implemented function for which this makes sense. But others will follow, using this very same mechanic. Some of these functions (to be implemented Blizzard-soon(TM) ) include: SetWhitelist(...), SetBlacklist(...), SetLookupOrder(...) and CleanupInstance().

LibSpellName2SID-Passives now includes a new category under General: Riding. All GeneralTab spells that have "Riding" or "Pathfinder" in their names go into this subcategory.

On another related subject: I subscribed for another month of WoW after the free weekend, thus making it much easier for me to test and coolect the data.
However, testing and collecting the data without a subscription, as I had previously thought and stated on my previous News post. It's a bit more cumbersome with only a Trial account, but doable. It turns out that characters at level 1 already allow you to fetch all base spells and PVE and PVP talents' spells.
Well, the Flyout spells require the character to have learned at least one of the spells springing out of the base Flyout button, but even that can be worked around - if you know the spell ID for the base Flyout spell, then you can fetch all the spells sprining off it.
Pets' spells present a similar problem to that of Flyouts but actually require a wider variety of methods to fetch said spells, depending on the character's Class. Hunter pets are notably difficult to fetch from the server because of the sheer amount of different pets with different spells that are available in the game - and thus ironically I don't even need to login to the game to build that list; instead I simply refer to
There are also some spells that I found "by accident", namely several Druid spells I learned about from playing a higher level Druid (not capped yet, but high enough). These spells are learned from Tomes (Flap, Treant Form, etc) but are not items, they actually become class spells once learned and thus are included in this library. There might be other such cases for other classes (aside fromt he Mage Polymorph Variants, Teleports and Portals, as well as Shaman Hex Variants; all of these fetchable from the server in the way I described above, for Flyout spells). Without a proper WoW subscription, the chances I accidentally run into such spells is rather slim.

Above, I mainly talked about fetching spells from within a Trial account, but I realized after my previous News post that I still had access to my PTR account, even without an active subscrition. This allows me to "go after" missing spells in my Trial account much easier. Matter of fact, as far as Allied Races' racial spells go, for 5 of the 8 new races, this is how I got them!
Same goes for Death Knight and Demon Hunter spells, as these Hero Classes are not available to a Trial account.
Also, some spells in the General tab depend on having earned some achievement or some other requirement, which can be hard to get (if not impossible) on a Trial account, but are often obtainable in the PTR.

If you've read this far into this overwhelmingly high wall of text, there's a chance you might actually be willing to help me with this project. You can do this in two different ways:
1. My eal-life financial situation is still rather shakey and therefore, if you can spare it, a small donation would help a lot in keeping my WoW subscription active, thus allowing me to keep on gathering the required data without too much hassle. Follow this link if you want to drop a coin on my hat: . Over the other way to help - that I'll outline bellow - this one also has the advantage of motivating me to keep on with this work.
2.1. The second way you cvan help is to report errors in the databse (missing spells, spells no longer present ingame, wrong SpellName-SpellID pairs). You can open a bug with such remarks clicking the Bugs tab above ( ).
2.2. Complimentarily, you could also use my Populator addon, available through this project SVN ( ). Please do note that this addon is very rough, but at the same time, very easy to use: You simply enable it (it's set to disabled by default), login in to your character, and it will gather the data mostly with no need for you to do anything. Well, fetching Pets' spells can be a bit quirky (I think I have them all working now, but...) and it is mandatory for the concerning Pet to be active for this purpose (often you have to dismiss it and then summon it again). Once you logout, a file called LibSpellName2SID-1.1-Populator.lua will be saved to Your_World_of_Warcraft_Folder\_retail_\WTF\Account\Your_Account\Saved Variables. This file will hold the data for all the classes you run LibSpellName2SID-1.1-Populator on. If you would be so kind, please send me a PM with said file ( LibSpellName2SID-1.1-Populator.lua ). There is no personal information contained in said file (no account details, no character nor realm names; only the classes you ran the addon on, the character levels and the Game Build (I really need this last piece of info)).

If you'd like me to release Populator as a proper addon (and possibly polish it a bit), please open a Feature request by clicking the apropriate tab above ( ).

I'd appreciate your help and feedback!

And... have fun!

May 2nd 2019: Edited a ouple lines to reflect the change implemented in 1.1.01.
Up to date, Not up to date?

You may have noticed that, although WoW 8.1 is live, LibSpellName2SID 1.0.14a has been released today for 8.0. This is not just due to some overlook upon uploading its most recent version. LibSpellName2SID's current database is not in sync with the current lists of spells available to the player in game!

The reason I uploaded a version of the database whose spells are no longer completelly is because 1) The last time I did a fetch for the spells from the server was back when WoW 8.0 was live and 2) That complete fecth is nonetheless much more up to date and complete than the one in the previous version of LibSpellName2SID.


Due to some (ongoing) financial problems I got into during the last trimestre of 2018, I ended up cancelling my subscription in early December, before the release of WoW 8.1.
On the other hand, lack of money hasn't been the only issue, spare time hasn't been all that abundant either...

Still, in between the release of Battle for Azeroth and the new patch 8.1, I did get some work done in LibSpellName2SID. But this was mainly in my (unreleased but available in the SVN) Populator addon, which handles fecthing the data from the server for me. I had to test it and bring it up to date with the new SpellMixin API (easier than I thought actually) and I also cleaned up a variety of small glitches that were pesting it for a while. So, unless 8.1 brought up some major API changes, I believe it should currently be able to do its job rather well.

So... What now?

Baseline spells for almost every class and their specializations can be fetched from the server with a level 10 character of that class; and PVE talents too. Of course, there are no level 10 Death Knights nor Demon Hunters, so those two classes are the reason from the "almost" in the previous sentence.
But otherwise, til I get myself subscribed again, can create a character of each class and race and level them all up to 10 and fetch the baseline and PVE talents' spells.

IIRC you do need a character with access to the PVP talents to fetch them though. Also, characters that have Pets and Flyout buttons will often only have those spells fetchable if you have acquired said Pets / learned the spells included in those Flyouts.

But I will endeavour to get the level 10 characters I can get with a trial account, and release an update to LibSpellName2SID once I've fetched their spells.

I may also come to release my Populator addon (needs some polishing and a little bit of further testing), so that hopefully, people willing and able to fetch the data on high level characters will be able to send me the saved variables (the lists of spells) from my Populator addon.

What about ReadySpells?

Ha, good question! A bit of an uncomfortable one too, if you were to remember that ReadySpells was the reason LibSpellName2SID was created in the first place (by Twobits initially, only as part of ReadySpells). I've intitially started work and released LibSpellName2SID as a standalone library (usable by any other addon) thinking it would be a quick thing...

The interesting thing is, although LibSpellName2SID was meant only to ease the maintenance of the ReadySpells' default class profiles, working on ReadySpells in paralel showed my an issue with its profiles: the spells included in the profiles' lists were validated against server-fetched lists of active spells.
This worked great for keeping the lists working during actual runtime, but it also meant said lists would be validated against e.g. currently active talent spells. ReadySpells had actually been written such that the inclusion of an inactive spell in a list would simply be ignored, but the fact the list against which the spells for display were validated was the same list against which the spells were validated to save into the profile (still is in the current SVN version of ReadySpells), meant a simple talent switch meant the inactive talents (and corresponding conditions) would be immediately removed from that profile.

Given that, in some cases, not all spells available to a class are fetchable (regardless of whether or not they are active), the simplest sollution is to use LibSpellName2SID as a "profile list of spells" and the currently active spells on the character as a separate "display list of spells".
Thus, once LibSpellName2SID is mature enough (apart from what was mentioned above, there are still other glitches in its working), I will implement that logic into ReadySpells and thereafter, hopefully, finish the work on it and ... finally release an up to date, modernized, working version.
I apologize for the previously uploaded LibSpellName2SID 1.0.11b, whose database was in fact broken and made the whole library unaccessible.

If you used that version, please upgrade to the new 1.0.12 version which fixes the problem.