View Single Post
01/08/16, 06:50 PM   #4
circonian
AddOn Author - Click to view addons
Join Date: May 2014
Posts: 613
Originally Posted by coolmodi View Post
Thanks! So they just change when going out of visual range I guess, and probably when zoning.

I'll just migrate the data from one unit ID to the other when it changes then, and delete the old entry. That way it should be possible to track players even in cyrodiil reliably.
It sounds like you are going to run into one of the problems I ran into with BuffTracker.

Despite the wording of this post:
Originally Posted by ZOS_ChipHilseberg View Post
For the unique ID we're looking at providing a number to identify each instance with the same name. Players will always be 0 (since their name should be unique anyway) and non-players will have an arbitrary number that will be the same as long as that unit exists.
Players do not have a unitId of 0 and the unitTag is nil unless the event is firing for a unit you are currently targeting. Although the player names are unique that does us no good because there is no way to distinguish between players & other targets (except the users character).

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. 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.

This also means that if you want to track effects on mobs you have no choice but to also track effects on players (and vice-versa) since we can't tell them apart.

My best thought would be to save everything by UnitId and if a targets unitId changes just let it change and start saving new data for that target. Also record a timestamp in the saved effects data table each time the data is updated for any given unitId. Then set a RegisterForUpdate(...) and every once in a while check the timestamps for all of your saved effect data & if its xxx old (meaning it hasn't been updated in a while) assume its no longer valid and delete the data to keep the table clean. Although its not a good solution its the best I've come up with.

I added some things that might help a little to the wish list a while back. Maybe someday we'll get some functions to help with things like this: http://www.esoui.com/forums/showthread.php?t=5298
  Reply With Quote