Authors CurseForge

Quote from mastermyte

This is why I proposed the UnSet Alt Function with a callback handler. The callback could be used for all addons to update their data when the callback is fired. :cool: This would keep all the data in "synch" without needing a ui relaod.

Quote from Mikk

Absolutely true... but I don't see how LibAlts solves that either? (Maybe I'm missing something; entirely possible)

Quote from Mikk

I think I have a better idea. Provide an API similar to http://www.wowwiki.com/API_GetSellValue

local mainName = GetMainName("SomeAlt")
local alts = { GetAltNames("SomeMain") }

Now you maintain your own SVs, and you can have multiple addons providing data, and the API is lolminimal.

An implementation would be something along the lines of:

local oldGetMainName = GetMainName or function() return end
function GetMainName(name)
  if myAddon.db.chars[name] and myAddon.db.chars[name].main then
    return myAddon.db.chars[name].main
  else
    return oldGetMainName(name)
  end
end

Tadaa?

(Note "return" vs "return nil", which becomes important for alt names. "return nil" = 1 entry with nil in it. "return" = 0 values.)


Edit: Oh, and addons both providing and displaying main/alt data, e.g. Prat/Chatter, should of course call GetMainName() themselves, not only look in their own SVs.

-- function for showing main names in the tooltip
function module:getMain(altname)
 if self.db.profile.usealtlib then
  local main = altregistry:GetMain(altname)
  if main then
   return self:formatCharName(main)
  end  
  return false
 end
 
 -- check a main exists for the given alt name
 if not self.Alts[altname] then return false end
 return self.Alts[altname]
end
 

  -- Load shared Alts data
  for alt,main in pairs(self.db.realm.alts) do
   altregistry:SetAlt(main,alt)
  end

Now you maintain your own SVs, and you can have multiple addons providing data, and the API is lolminimal.

Quote from Seerah

I also agree that the library should store the data rather than force addons to store it. Then there would be only one alts table for various addons to use, rather than, say, Prat storing the table, GuildGreet storing the table, some raid manager storing the table, a guild list organizer storing the table, etc. This defeats the purpose of a shared library, and they may as well use their own methods of creating/storing that data. Instead, the lib will store the table and the mods will access/write to it directly. One centralized location of the data for the mods to share.

Of course, this does require the user to install the library as standalone. Each mod that would use LibAlts would have to have a fallback in case a user did not have LibAlts installed. Having it installed would just be a bonus to the user, in that they would be able to share alt data across all addons they have installed that utilize it. Perhaps LibAlts could have its own frame to enter alt information as well - a centralized place to enter alt names into the table...

 
[21 03:07] <Repo> [WoW] guildcraft: OrionShock * r132 DBO.lua: try using prat to link alts to mains

Quote from HunterZ

I'd like to echo Pasta's concerns. Most end-users would never think to run two chat addons (as an example) at once in order to migrate the data, and it may not even work because errors will likely result from running two full-featured chat addons at the same time.

I do really like the idea of providing a centralized registry for alt data though.

Quote from Pastamancer

Unfortunately I think that makes this less useful than it could be. If I decide to switch from Chatter to Prat, I'd lose all my alt names anyways since they'd be using different saved variables.

 
Alts[main] = { alt1, alt2, alt3 }