Help with a table issue
Ok so, here's my good old nameplates addon
http://pastebin.com/ATJTK2VN Now here's my threat oUF module http://pastebin.com/ghNQfx5k I don't want to use the default nameplates threat coloring instead, i want to use my own. So, i feed the plates in a global table (nameplates lines 307 and 328) and then use that table to color them (threat lines 132 to 141) The issue i need help with: Currently, when i enter combat with a group of mobs, all the plates light up showing the threat color of my target instead of their own threat in relation to me. Does anyone know what i have to change to make it work on a plate per plate basis ? (so that each plate show their own threat) ? |
Read http://wowprogramming.com/docs/api/UnitThreatSituation
Add the nameplate unit to test to Lua Code:
Or use http://wowprogramming.com/docs/api/U...hreatSituation. I'm not sure. Just read the descriptions. :) |
That's not the issue at all, actually the threat module works just fine, it's the nameplates. in other words, ALL the nameplates visible on screen show the colors of the nameplate of my target, probably because they're all being fed to the table without any distinction. So, the threat module takes everything in the table and colors it according to my current target when they should be fed one by one, independently.
|
Well, as far as I understand your code you are iterating over all the nameplates and recolor them here:
Code:
for _, plate in pairs(caelUI.plates) do Code:
local status = UnitThreatSituation("player") |
So two hours later the website is stable enough so I can finally post:
As far as I'm aware it is unfeasible to get accurate threat information for nameplates other than from the supplied threat region on the nameplate(s). This is because the methods for determining threat (UnitThreatSituation, UnitDetailedThreatSituation) require a unitID (for both the threater and threatee). Because nameplates inherently don't have unitIDs linked to them and although it would be possible to match unitIDs to nameplates in a limited scope it's just not feasible as a threat indicator on a large scale. The practical way to guarantee known threat on nameplates is to use the provided threat region on them. If you want a simple solution to your answer replace lines 132-141 in Threat with this: Lua Code:
Personally, the way I do it is as you've done previously, with an OnUpdate script. However, I use a single OnUpdate script and a table for tracking currently visible nameplates. It will benefit from less CPU time and less memory usage (compared to giving each nameplate it's own OnUpdate script). |
Quote:
However, this only works for units with a current (and known) unit token, so it isn't a suitable solution for nameplates. Use the solution posted by Oppugno instead to get the information from the nameplate's default threat region. |
Quote:
|
Nameplates persist long after they've gone off screen / not visible anymore and are constantly being recycled. Which makes sense or else there would be alot of garbage being generated each time a nameplate went off screen only to come back on screen 2 seconds later because you turned your camera. To test it, try doing a frame stack.
|
In that case i'm not sure i understand the comment you've made in the code :)
|
(Although I'm pretty sure you understood this part) To clarify, when I wrote 'active' I meant the nameplate is actually visible on the screen at this moment in time.
Say you've fought 50 mobs at once and they all had unique nameplates because they were all on the screen at one time. If you then encounter a pack of 3 mobs, well only 3 of those 50 nameplates are actually active / visible at the moment. So, obviously it would be wasteful running your threat update on the 47 other nameplates because they're not visible at the moment. The way I avoid updating those hidden nameplates is by storing the active / visible nameplates in a table of only them. I do this by Hooking/Setting the OnHide and OnShow scripts for each nameplate to remove or add them to that table of visible nameplates. Lua Code:
With that we now have a table that contains only nameplates that are actually visible. Which now means we can do: Lua Code:
|
Right, this is what i have now, let me know if i didn't miss anything :)
http://pastebin.com/vx7HakVc So far it seems to work great for just about everything exept one minor detail: For some reason, if i enable lines 37-39 to recolor tapped units, those will just not keep the color i want them to have, so they'll be blinking between whatever color i choose (in this case for testing purpose plain red) and the default grey color and i can't find any reason why those won't work when everything else does. |
The tapped colour is set/reset every frame while the nameplate is tapped. That is what is causing your flickering bar colour. I know of three 'solutions':
The only parts of UpdatePlate() that need to be run in an OnUpdate script are lines 63-65 so you have a massive overhead calling that entire function. |
Quote:
http://pastebin.com/XSEw2iXN I had to leave the healthbar stuff in the OnUpdate, if i move it in the OnShow for example the healthbar are fine at first but as soon as they leave the screen then come back, they keep the skin but change to the default size. |
Sorry, what I meant was you do need everything else other than lines 63-65 in your OnShow function (UpdatePlate). But you need to make a separate function that is called from your OnUpdate script.
Lua Code:
Lua Code:
Lua Code:
Or better yet, merge the two components (the threat colouring and the OnUpdate script) and get rid of UpdateThreat entirely. There will be up to a ~0.1s delay after a frame is shown before its threat is updated by your OnUpdate script but it's faster iterating over the table and running the contents of a function than iterating and then calling a function to run its contents. Lua Code:
Edit: And that'll teach me to get distracted while writing a response. |
Ouch, i edited my post above with my most recent changes at the same time you were posting i guess.
|
As for the resizing frames if you do increase their size keep in mind that the area on which you can click a nameplate will be roughly the same as the original (smaller) area. Also, OnSizeChanged scripts are probably the ideal script for dealing with changing frame sizes, not OnUpdate. This thread might be of some use, where someone had to deal with resizing frames on nameplates.
|
Cael, the code in the linked thread is basically a stripped version of your CaelNameplates before you took it off from WoWI. I think the only real difference is the removal of the custom coloring and using a texture for the border instead of a backdrop. I hope it helps
|
The UNIT_SPELLCAST* events you have registered are not helpful because they only fire for "real" unit ids but you have them registered to all castbars. So you will spread the results for your target among all nameplates. The same goes for channeling. Also instead of calling UpdateTime from Castbar_OnValueChanged why not set it directly as the script handler? You could significantly reduce the table look-ups in CreatePlate too.
|
|
In your OnUpdate (lines 303-322 in the pastebin) you should create a local reference to self.healthBar and spare yourself 11 table look-ups. You also have an unnecessary call to GetStatusBarColor() in UpdatePlateColor. Line 46 could just read
Code:
newr, newg, newb = r, g, b |
All times are GMT -6. The time now is 01:19 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI