Tidy Plates

Forum > General Comments

Class Color Function Not Working For Coalesced Realms

    #1 Sep 11, 2013 at 22:49 UTC - 0 likes

    Hey Danltiger,

    Great work on Tidy Plates as always.

    I want to report an issue I am having in 5.4. The class color function I am using to color health bars isn't producing a color for players from coalesced realms.

    I did some digging around in the code, and I assumed it was an issue with names showing as Name(*). I gsubbed the (*) out to try to make it reference the cache correctly, but didn't get anywhere. Not sure what the real issue is.

    I changed line 564 of 6.12.3's TidyPlatesCore.lua to:

    unit.name = gsub(regions.name:GetText(), "%(%*%)", "")
    

    to try to get the right name reference, and it did print correctly, but didn't solve my problem.

    The code I am using is:

    -------------------
    -- Initilization --
    -------------------
    	-- Call TidyPlayes widgets.
    	TidyPlatesUtility.EnableUnitCache()
    	TidyPlatesUtility.EnableGroupWatcher()
    
    	local theme = TidyPlatesThemeList["Clamsoda"]
    
    ----------
    -- Core --
    ----------
    	-- Funtion to return class of friendly units.
    	local function GetFriendlyClass(name)
    		local class = TidyPlatesUtility.GroupMembers.Class[name] 
    		
    		if (IsInInstance() == nil) and (not class) then 
    			class = TidyPlatesUtility.CachedUnitClass(name) 
    		end	
    		return class
    	end
    
    	-- Function to return appropriate color.
    	local function HealthBarColor(unit)
    		if unit.reaction == "FRIENDLY" and unit.type == "PLAYER" then
    			local class = GetFriendlyClass(unit.name) or "UNKNOWN"
    			local color = RAID_CLASS_COLORS[class]
    			if color then return color.r or 0, color.g or 1, color.b or 0 end
    		end
    		return unit.red, unit.green, unit.blue
    	end
    	
    	-- Map our HealthBarColor to TidyPlate's SetHealthbarColor.
    	theme.SetHealthbarColor = HealthBarColor
    
    Last edited Sep 11, 2013 by Clamsoda
    #2 Sep 11, 2013 at 23:42 UTC - 0 likes

    Double post sue me.

    I got it! The issue was the name on the nameplate is now Name SPACE (*), and I wasn't gsubbing out that leading space.

    gsub(unit, " %(%*%)", "")
    

    Is doing it for me.

    #3 Sep 11, 2013 at 23:49 UTC - 0 likes

    @Clamsoda: Go

    Cool... I'll have to test and incorporate :-)

    I hadn't tested ANYTHING related to coalesced realms on the PTR, and haven't seen anyone from a different realm yet. I'm guessing that the nameplate names have the realm listed after the proper name?

    Been so busy, I haven't played my main in... well.. a long time.

    Thanks for the post!

    #4 Sep 12, 2013 at 00:25 UTC - 0 likes

    Well, it doesn't appear to list the realm name. If a player from a coalesced realm appears, the nameplate displays the name as: "NameSPACE(*)". I handled stripping the "SPACE(*)" out in MY code; but I think you could apply the same technique to line 564 of 6.12.3's TidyPlatesCore.lua. When I originally tested that, I wasn't killing that trailing space which is why I wasn't noticing a change.

    That being said, do you think there is a way to cache names in a more informative way? What if there are two players with the same name on the server, considering coalesced realms provides that possibility? A "name-realm" setup may be effective. Though, if the nameplate doesn't provide the realm in a region, then I don't know how you'll make that reference. Perhaps some work through GUID?

    Also, go on WoWI's IRC, forums are so slow <.<

    Edit: Here is a conversation between Neffi and I on the subject. Just ignore the other usernames. May provide some useful information.

    Last edited Sep 12, 2013 by Clamsoda
    #5 Sep 12, 2013 at 09:46 UTC - 0 likes

    @Clamsoda: Go

    To grab a GUID, we've got few options:

    1) UnitGUID( ["target", "mouseover", unitid...]) You'd have to constantly mouse-over plates to get the GUID...

    2) Scrape the Combat Log for events; It will contain unit name and guid of the source and destination player.

    Using the combat log effectively would require that the unit cast a spell, which could be cached with a timestamp, and allowed to expire after a certain amount of time, or after you've moved to a different area. ( That sounds like a lot of work) The probability of simultaneously encountering two players with identical names from foreign realms seems lowish. Might depend on the name, though. I see a lot of "Willferal"s and "Shammywow"s.

    Last edited Sep 12, 2013 by danltiger
    #6 Sep 13, 2013 at 01:25 UTC - 0 likes

    Neither option sounds ideal; and I was on the same boat with the "unlikely to see two players of the same name at once" mindset. Even if there was a conflict, it isn't likely that an incorrectly colored nameplate would make much of a difference.

    In arena, raid, or a BG - where it really counts - there's a 99.9999% chance the name will be unique, so no worries.

    Last edited Sep 13, 2013 by Clamsoda
    #7 Sep 13, 2013 at 01:49 UTC - 0 likes

    @Clamsoda: Go

    Fortunately, in Raids, BGs and Arena, the class is gathered by unitid... "raid1", "raid2", "arena1", etc... (feature was already in there, unless it broke)

    #8 Sep 13, 2013 at 08:04 UTC - 0 likes

    Ohhhh that is true! Well then....=].

    Last edited Sep 13, 2013 by Clamsoda
    #9 Sep 14, 2013 at 09:58 UTC - 0 likes

    @Clamsoda: Go

    Except.... you got me thinking.... Any unit with the "(*)" in their name will fail to match up with the index of the data.

    So, I borrowed your gsub code, and now precompute unit.rawName with gsub(unit.name, " %(%*%)", "") whenever the identity is refreshed. I'll to incorporate this into Core, Hub, and some widgets.

    Thanks! :-D

    Last edited Sep 14, 2013 by danltiger
    #10 Sep 15, 2013 at 01:13 UTC - 0 likes
    Quote from danltiger: Go

    @Clamsoda: Go

    Except.... you got me thinking.... Any unit with the "(*)" in their name will fail to match up with the index of the data.

    So, I borrowed your gsub code, and now precompute unit.rawName with gsub(unit.name, " %(%*%)", "") whenever the identity is refreshed. I'll to incorporate this into Core, Hub, and some widgets.

    Thanks! :-D

    That was my point all along! Hehe. Glad to see I could help!

    #11 Sep 15, 2013 at 18:19 UTC - 0 likes

    @Clamsoda: Go

    Consider me pointed! :-)

    My brain was locked onto the class coloring thing; Took me a bit to realize that the extra junk in the name would also foul association of auras and healer warning.

    #12 Sep 18, 2013 at 08:51 UTC - 0 likes

    As of 6.12.4, this is still not working as a release.

    I downloaded your latest release and clean installed it. Note: my changes were applied to your core file and NOT my theme; so there should be no conflict. Upon logging in, units from coalesced realms failed to match their indexed class' color. I am assuming the issue still lies with referencing the index.

    I haven't been through the code yet, I'll let you know what I find.

    #13 Sep 18, 2013 at 10:16 UTC - 0 likes

    @Clamsoda: Go

    Units from coalesced realms wouldn't be stored when you're in the open-world.

    In TidyPlatesWidgets\UnitCache.lua, line 128:

    if UnitRealmRelationship("mouseover") ~= LE_REALM_RELATION_SAME then return end	
    

    Also, TidyPlatesHub\Functions.lua skips over non-battleground coalesced units. (I know in-battleground coloring works, because I spent too much time in level 55 bracket AV. *sigh* On the up-side, I had plenty of time for code-editing while waiting for respawn)

    Maybe I'm being too conservative about the name-collision thing. In your opinion, do you think it would be better to have the coloring + chance of misidentification, vs no coloring?

    On further thought, I'm going to give it a shot, and post the package as a beta.

    Last edited Sep 18, 2013 by danltiger
    #14 Sep 18, 2013 at 18:13 UTC - 0 likes

    I suppose I am a bit confused. Pre 6.12.4, units from coalesced realms were saved; the only issue was that the cached name was free of the " (*)" non sense, and the nameplate name object CONTAINED that nonsense, so the name wasn't identifying with its indexed cache properly. Stripping the " (*)" from the nameplate name object solved that issue.

    Are you telling me that in 6.12.4, you've added logic to no longer cache units from coalesced realms? If that is the case, then there would be no issues with clashing names, considering the only people that can be cached are from your realm, and that abides by the "one name per realm" rule.

    Furthermore, I think I would edit that code out; I want any unit that appears on my screen to have friendly nameplate coloring.

    Last edited Sep 18, 2013 by Clamsoda
    #15 Sep 18, 2013 at 19:00 UTC - 0 likes

    @Clamsoda: Go

    Pre 6.12.4, there WAS logic intended to filter out foreign units, but the API function was broken. 6.12.4 repairs that particular bit of code.

    The problem with caching all units using the current structure, is that good data is potentially being overwritten. The cache currently doesn't discriminate between local and foreign units, so you may overwrite the days about one character with data from another.

    I got a chance to witness that issue while I was questing in stranglethorn.

    #16 Sep 18, 2013 at 19:09 UTC - 0 likes

    Oh....well hrm. I've been using that code to color friendly units' nameplates since well before 6.10; and it was coloring cross-realm units just fine. If I was CRZed onto another server, or if someone was CRZed onto my server, their nameplate was properly colored.

    I've not seen two players with the exact same name from two different realms, CRZed into the same realm; and if it did happen it wouldn't be the end of the world to me.

    #17 Sep 19, 2013 at 12:13 UTC - 0 likes

    @Clamsoda: Go

    6.12.5
    - Widgets: Unit Cache: Stores non-local units with a " (*)" suffix.
    - Hub: Class colors on cached units shoud work properly
    Of course, Curseforge is giving me the ol' "There was an error uploading your file. Try again later."

    It's later, and I'e tried again. Guess I have to wait longer.

    Last edited Sep 19, 2013 by danltiger
    #18 Sep 19, 2013 at 21:35 UTC - 0 likes

    I am just now viewing this post because I kept getting redirected to some Curseforge maintenance page. I had to clear the cache etc.

    Can't believe you took my opinion into consideration! I'll give 6.12.5 a go and let you know what I find.

    Take a rest ;].

    Edit: Working great as far as I can tell, Danltiger. Thank you so much for your hard work and support!

    Last edited Sep 20, 2013 by Clamsoda
    #19 Sep 20, 2013 at 16:06 UTC - 0 likes

    Friendly class colours for coalesced realms still don't work for me even with 6.12.5, I did a clean install. Am I doing something wrong or what? The enemy colours worked even with previous version.

    #20 Sep 21, 2013 at 03:13 UTC - 0 likes

    @Clamsoda: Go

    Clam - Good to hear that it's workin' fine!

    I'm stubborn about some things, but I try to keep an open mind. You have the right-of-it, though; Why throw away a feature when the problem is an uncommon exception? Perhaps there'll be a few instances of mistaken identity. It'll build character :-D

You must login to post a comment. Don't have an account? Register to get one!