View Single Post
01/08/16, 08:11 PM   #5
coolmodi
AddOn Author - Click to view addons
Join Date: Mar 2015
Posts: 47
Originally Posted by circonian View Post
Since other targets/mobs do not have unique names you can not use the units name as a key for the data (not even for players because we can't distinguish between players & mobs to separate the two). It also means that if the unitId changes you can't migrate the data because you have no way of knowing what the original unitId was to find the correct data to migrate.
Oh yes I can, at least if I'm not totally wrong and miss something really obvious, my two addons here are the first thing I ever programmed that goes over the hello world crap I had to do for an uni course

Basic arrays needed, just to show the data structure
Lua Code:
  1. --to have name and the info whether it's a player (or named mob but that's ok for migration purposes) and in group for each unitId
  2. unitList = {                    
  3.    [unitId] = {name,player,group}
  4. }
  5. --this is the important thing, you need names as key with id as value too!!!
  6. nameIdPairs = {          
  7.    [name] = Id
  8. }
  9. --data saved to each unitId
  10. dataArray = {
  11.    [unitId] = dataForUnit
  12. }

Then some changed wip code from my addon:

Lua Code:
  1. --on every combat and effect event this is done, data collection into the "dataArray" is done somewhere else
  2. function GroupDamage:UpdateUnitList(unitId, unitName, unitType)
  3.     if unitName == "" and (unitType ~= 3 or unitType ~= 1) then return end
  4.     if self.unitList[unitId] == nil then
  5.         self.unitList[unitId] = {
  6.             ["name"] = "<placeholder>" .. unitId,
  7.             ["player"] = false,
  8.             ["group"] = false
  9.         }
  10.     end
  11.     if targetName ~= "" then
  12.         self.unitList[unitId]["name"] = zo_strformat("<<C:1>>", unitName)
  13.        
  14.         --magic starts here
  15.         --if a name contains a "^" it isn't a general mob, and in any case(?) at least unique, or unique enough to not make problems
  16.         if unitName:match("%^")~=nil then
  17.             self.unitList[unitId]["player"] = true --this is bull**** because of that, but it helps filtering out general mobs in my addon (do mobs have an x after f/m too?)
  18.            
  19.             --so now check if you already had that name with an id before and if the id for the name changed
  20.             if self.nameIdPairs[unitName] ~= nil and self.nameIdPairs[unitName] ~= unitId then
  21.                 --yes? you now have the old and new ID!
  22.                 self:MigrateToNewId(self.nameIdPairs[unitName], unitId)
  23.             end
  24.             self.nameIdPairs[unitName] = unitId --assign new id to the name
  25.            
  26.         end
  27.    
  28.    
  29.     end
  30.     if unitType == 3 or unitType == 1 then
  31.         self.unitList[unitId]["group"] = true
  32.     end
  33. end
  34.  
  35. function GroupDamage:MigrateToNewId(oldId, newId) --WIP
  36.     d("Id for player or named mob changed!")
  37.     d("Old name: " .. self.unitList[oldId]["name"] .. " with ID: " .. oldId)
  38.     d("New name: " .. self.unitList[newId]["name"] .. " with ID: " .. newId)
  39.     --copy data from one unitId to the new unitId in "dataArray", or add it if it already exists, which is highly probable with combat event...
  40.     self.unitList[oldId] = nil   --also remove old from unitList
  41.     self.currentFightData["units"][oldId] = nil   --and also old data in the "dataArray"
  42. end

This should work, I even tested it ingame, but with a much worse solution in terms of performance, hence the extra array with [name] = ID pairs, so I can just use ~= two times and don't have to loop through the unitList

Thanks to effect changed ALWAYS giving name and ID this should work pretty reliable too, as soon as someone comes in range it will fire even if they only have the ESO PLUS buff, or a food buff, really anything. In that moment I will have their new id, and the old one from the name+id pairs.

Originally Posted by circonian View Post
Also migrating the data would probably be a bad idea. As an example: If a player went out of range & his unitId changed (or even if it didn't change) he was probably far enough out of range that when his effects changed the event did not fire for us so that effect data you have saved is probably no longer valid.
Doesn't affect me, I just need name and ID from it, my addon tracks damage and heal for every unit
But anyways, why would the effect data not be valid anymore? Doesn't it just provide begin and end time of buffs? That won't change only because they were out of range, so what isn't valid anymore?

Edit: And why are the code containers not as wide as quote containers here??

Last edited by coolmodi : 01/08/16 at 09:00 PM.
  Reply With Quote