In my addon I have tables which contains lists of peoples Mains and Alts. One person in particular has a Non ASCII char in his name and while his name is in the table when ever I try comparing a list of people in a raid group with these tables his doesn't compare properly. It shows him as non existent in both tables.
Is there anyway I can get around this?
Thanks in advance!
Edit: Here is an example of how I look through the Mains table:
for k, v in pairs(RaidGuildMembers) do
for i = 1, #(HALootManager.PriorityList.Mains), 1 do
if (HALootManager.PriorityList.Mains[i] == v) and (HALootManager:IsInGuild(v)) then
table.insert(MainsAndPrimaryAlts, v);
break;
end
end
end
RaidGuildMembers (still need to rename from my previous implementation) is just a list of names from the raid. The IsInGuild function checks if the person is in the guild or not. The MainsAndPrimaryAlts table is what I use later in the code.
Simple string comparisons with the == operator should have no trouble with non-ASCII characters. Neither should table lookups with non-ASCII characters in the key name.
t = { ["Cptámerika"] = "v" }
t["Cptámerika"] -> "v"
For the purpose of determining whose alt Cptámerika is, you should not need any kind of pattern matching. If you're having trouble, or think you need this, you should reevaluate your data structures.
Here are two simple examples:
local altsToMain = {
["Myaltone"] = "Mymain",
["Myalttwo"] = "Mymain",
["Cptámerika"] = "Someguy",
}
local main = altsToMain[name]
if main then
-- name is an alt of main!
end
local mainToAlts = {
["Mymain"] = {
["Myaltone"] = true,
["Myalttwo"] = true,
},
["Someguy"] = {
["Cptámerika"] = true,
}
}
for main, alts in pairs(mainToAlts) do
if alts[name] then
-- name is an alt of main!
end
end
You wont be able to match "somealt" with "Somealt" without using some complicated patterns.
Here's my code to generate a pattern that will match if the first letter is lowercase or uppercase.
MULTIBYTE_FIRST_CHAR = "^([\192-\255]?%a?[\128-\191]*)"
function GetNamePattern(name)
local u = name:match(MULTIBYTE_FIRST_CHAR):upper()
if not u or u:len() == 0 then Prat.Print("GetNamePattern: name error", name) return end
local l = u:lower()
local namepat
if u == l then
namepat = name:lower()
elseif u:len() == 1 then
namepat = "["..u..l.."]"..name:sub(2):lower()
elseif u:len() > 1 then
namepat = ""
for i=1,u:len() do
namepat = namepat .. "[" .. u:sub(i,i)..l:sub(i,i).."]"
end
namepat = namepat .. name:sub(u:len()+1)
end
return "%f[%a\192-\255]"..namepat.."%f[^%a\128-\255]"
end
Why would casing be an issue at all if you're comparing player names as they are displayed in-game from the client? As far as I'm aware, player names displayed by the client are always "Somealt", never "somealt" or "SOMEALT" or "sOMEALT" or "SoMeAlT" or anything else.
Why would casing be an issue at all if you're comparing player names as they are displayed in-game from the client? As far as I'm aware, player names displayed by the client are always "Somealt", never "somealt" or "SOMEALT" or "sOMEALT" or "SoMeAlT" or anything else.
Assuming that things are always correctly cased is one of those things that you have to decide for yourself. Personally, case-sensitivity isnt something that is intuitive for users.
Right, but my impression after reading the initial post is that this isn't something users are typing things into. He wants to compare the names of players in a raid group to names in a predefined table of mains and alts. UnitName("raidN") will always return a correctly cased name. I assume the mains-alts table is hand-written, but it's a lot simpler to hand-write the correct casing than to save yourself the effort of hitting the Shift key a few times only to have to write more code to deal with unknown casing.
Right, but my impression after reading the initial post is that this isn't something users are typing things into. He wants to compare the names of players in a raid group to names in a predefined table of mains and alts. UnitName("raidN") will always return a correctly cased name. I assume the mains-alts table is hand-written, but it's a lot simpler to hand-write the correct casing than to save yourself the effort of hitting the Shift key a few times only to have to write more code to deal with unknown casing.
Yeah - fair enough. I guess since I have already coded something pretty turn-key, there is no additional complexity in case insensitivity [for me]. Also - Alt names were part of what i wrote the code for - i guess im biased.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Is there anyway I can get around this?
Thanks in advance!
Edit: Here is an example of how I look through the Mains table:
RaidGuildMembers (still need to rename from my previous implementation) is just a list of names from the raid. The IsInGuild function checks if the person is in the guild or not. The MainsAndPrimaryAlts table is what I use later in the code.
Before we can help you, it would be great to explain in more detail (read: post code) how you compare.
Oh yes sry that is what I meant >.>. His name is Cptámerika for the record.
http://forums.wowace.com/showthread.php?t=16075
"Cptámerika" == "Cptámerika" -> true
"Cptámerika" == "Cptamerika" -> false
t = { ["Cptámerika"] = "v" }
t["Cptámerika"] -> "v"
For the purpose of determining whose alt Cptámerika is, you should not need any kind of pattern matching. If you're having trouble, or think you need this, you should reevaluate your data structures.
Here are two simple examples:
If this is the case and you are having trouble figuring out how to use UTF-8 then just replace "Cptámerika" with "Cpt\195\161merika".
Not to nitpick, but those characters are extended-ASCII.
That depends on the character and the extension of ASCII, infact there is not one extended ASCII, but many different.
Not to nitpick, but WoW doesn't use extended-ASCII. It uses UTF-8 and ASCII is valid UTF-8. Extended-ASCII is not so those are not extended-ASCII.
You wont be able to match "somealt" with "Somealt" without using some complicated patterns.
Here's my code to generate a pattern that will match if the first letter is lowercase or uppercase.
Assuming that things are always correctly cased is one of those things that you have to decide for yourself. Personally, case-sensitivity isnt something that is intuitive for users.
Yeah - fair enough. I guess since I have already coded something pretty turn-key, there is no additional complexity in case insensitivity [for me]. Also - Alt names were part of what i wrote the code for - i guess im biased.