When you register for an event you either need to have a function of the same name as the event or specify a handler for the event that points to a function you already have.
self.following = following
self.mostRecentBag = containerID
for u,name in rosterlib:IterateRoster() do
soulstone[name] = soulstone[name] or 0
Does the "for u,name in iterate do" part mean that from a list of names created by rosterlib:iterateroster(), it uses 'u' as a dummy variable and goes across all the names, sort of like an "for i,1,100"?
Quote from maia »
soulstone[name] = GetTime()
I don't understand if this is a generic "okay, this is where you put your function to check for a soulstone" thing, or if you're implying that RosterLib also creates a set of variables(?) for each buff on each person.
actually I was wrong, sorry. I recommend not to use IterateRoster at the moment anyway, as it will cause some garbage collection (tiny, but still). So I suggest to rather do:
roster = self.rosterlib.roster --somewhere at the end of your OnEnable()
for n, u in roster do ... end
In this example n is the name of the unit. u is the entire unit object. So if you only need the names, you can do a "for n in roster do ... end", and if you need more than only the name but e.g. also the class, subgroup etc, you can access the unit via u.class etc.
This is the basic table thats indexed by a non integer. So all you do is a "for key, value in..." - in our example the key is the unit name (as the table is indexed by name), and value will return a subtable with all the information for the unit.
As for your second code snippet, all that does is save the current time in your table "soulstone", indexed by name. So "print(soulstone["theondry"]) will print the server time the last SS was cast on you. As for parsing buffs or handling buff related events, you need to do that yourself though - all rosterlib provides is an always up to date roster with name, unitid, subgroup, class and rank.
So the "u" isn't just a generic iterator? It's a specific variable that holds some meaning, unlike the traditional "i" that I was taught to use? The bit in the lua manual at their website suggests that, instead, "n" is an index while "u" is the value associated with that index (though it is unclear what kind of index it would be, either a number or what).
Also, I need some lua explaining:
I understand "tablename[indexname]=value"
tablename[indexname]=tablename[indexname] or 0
mean? (taken from the apocryphal "second code snippet", sometimes called the "dead sea snippet")
edit for more questions:
Is there a reason to set the variable "roster" as local, rather than defining "self.roster = self.rosterlib.roster"?
edit for a bit of independant thought:
is the "or 0" part sort of an "elseif not then set it equal to zero endif" kind of thing?
theondry, replace u by unitobj if that helps. It doesnt matter what's used there, I just abbreviated everything. You don't need to use i either, it's just a naming convention (as key, value or k,v are used for non integer indexed tables).
As for setting the roster to local: set everything to local if you can. There's a tiny tiny performance increase afaik. And it doesn't hurt.
In SnaFu, I'm noticing something a little odd when people join a raid... It *seems* like RosterLib will temporarily empty out the list of people when people join. (I'm noticing this, because snafu tells me that stoned people leave this roster and then rejoin it (thus reseting the timers).)
Is this possible? or did I not code something properly?
kaybe, if you'd want to submit some code to RosterLib, please feel free to e.g. paste it to pastebin.ca and post the link so I can take a look at it before submitting it. I guess this should be a second table, indexed by the subgroup, holding the names of all units in that group.
theondry, raid members shouldn't leave the raid in RosterLib when an update occurs. I'd suggest to watch which units the event RosterLib_RosterChanged sends, and what really changed. That will let you track down what the problem is.