Authors CurseForge

Quote from Ketho

Question 01: Is it normal there were created over 3.1 million characters on that server?
Even though ppl might make a lot of alts and/or even delete them again, racechanges, and taking into consideration how long that beta server has been up already(4-6 month?)

They don't necessarily start at 0000.....00001 for the first toon, do they?

So Question 02 is: Can a lua array be sorted numerically or can it only be printed out sorted with this "orderedPairs()" function?

Not if you're using non-numerical keys. It's a hash table, after all. (Or "dictionary" or whatever the cool kids are calling them now.) Rearranging the keys would defeat the whole point of the hash.

What you're doing -- an ancillary table with the numerical keys in whatever order you want, and the values as keys of the original table -- is pretty much the only approach, although there are many variants on the implementation.

1. We don't know how Blizzard assigns GUIDs.

2. You can't iterate through a table by keys in such a way that the keys are in sorted order. However, you can use a second array indexed from 1 to N with the values of this table as the keys of the first, sort this one, then access the first table using the sorted keys.

The orderedPairs() essentially does exactly what I described internally, and then gives you back each iteration one by one using the temporary array. Note that the example given that you linked has performance issues.

Specifically, issue number 1 is that if the loop was terminated halfway with a break or return statement, there will be a "memory leak" because t.__orderedIndex = nil was never called to release the memory.

Issue number 2 would be that because a new table is made on every orderedPairs() call, calling it a lot of times very frequently will produce a lot of garbage (if the table is large) to be collected. However, because a new table is made, the function is re-entrant and you can use an orderedPairs() within an orderedPairs().

Ok let's try again. You have this table.

t1[300] = "ghi"
t1[100] = "xyz"
t1[200] = "abc"
t1[1000] = "def"

You can't use pairs(t1) because it would iterate through the 4 entries in a random order.

What you do is create a temporary table, say t2, and fill it up like this

t2[1] = 300
t2[2] = 100
t2[3] = 200
t2[4] = 1000

Then you sort t2 to get:

t2[1] = 100
t2[2] = 200
t2[3] = 300
t2[4] = 1000

Then you loop over t2 from t2[1] to t2[4] and use the value stored to access the values stored in t1 in order. So, the whole code looks like this

local t1 = {}
t1[300] = "ghi"
t1[100] = "xyz"
t1[200] = "abc"
t1[1000] = "def"

-- Create/use a temporary table
local t2 = {}
local i = 1
for k, v in pairs(t1) do
    -- Take all the keys of t1[] and put them in t2 as values
    t2[i] = k
    i = i + 1
end
table.sort(t2)

-- Now print out key = value in sorted order
for i = 1, #t2 do
    print("[" .. t2[i] .. "] = " .. t1[t2[i]])
end

The fancy orderedPairs() function you see in the link you provided, is just a much fancier way of doing the exact same thing, and requires you to understand what iterators are.

Quote from Ketho

For the rest, I didn't really understand all that programming terminology since im just noob. But you are saying rearranging it is not how it works and there are variations on how to implement it and this is how it should kinda work right.

Pretty much! For some of the variations, have a look at

http://lua-users.org/wiki/LuaDirectory

I think the code you're already using is based on the "sorted iteration" link on that page, but some of the more popular variations are also there.

Here's a simple example. If I have a table with three string keys, "foo", "bar", and "baz", there's no telling what order they're in behind the scenes. I might write the table like this:

T1 = {
  ["foo"]   = .......,
  ["bar"]   = .......,
  ["baz"]   = .......,
}

but that doesn't have anything to do with how they're arranged in memory. Lua will sort them internally however Lua feels like sorting them.

If I want to arrange them in some order, I create a second table like this:

T2 = {
  1 = "foo",
  2 = "bar",
  3 = "baz",
}

Now I can rearrange that table however I feel like. In particular, I can use the table.sort() routine, which does an in-place sort according to whatever comparison function I pass in. By default it's just alphabetical:

T2_sorted = {
  1 = "bar",
  2 = "baz",
  3 = "foo",
}

Now if I loop over that table in standard key order (using ipairs or the usual numerical for loop), the values from T2_sorted become the indexes to use into T1, and the result is plucking out entries from T1 in alphabetical order of its keys.

Well lets see, how many seconds are there in 4 months?

60 seconds * 60 minutes * 24 hours * 120 days = 10 368 000 seconds

That's over 10 million seconds since the start of F&F alpha. Is 3.1 million characters really that unrealistic? They probably have a lot of internal testing as well done on character copying/transferring from live servers.

Of course it doesn't have anything to do with time lol.. What would happen if 100 people created a character at the same time otherwise (say on launch day)?

What about this:

local t = { --[[ random indices ]] }

for i = 1, table.maxn(t) do
	local v = t[i]
	if v then
		print(i, v)
	end
end

Is this very bad in comparison?

Hmm, yeah I guess. =P I suspected it could be a problem if the max value was very high, which it is.. nevermind me!

What do you try to do with the UnitGUIDs?

some thoughts:

- the UnitGUID in WoW is a 64-bit hexadecimal string. do not use tonumber(). you will get trouble if you do this.

- a WoW UnitGUID looks like: 0x040000000A182FE0
- 0x040 = battlegroup identification (globally unique)
- 000000A182FE0 = character identification (globally unique because of battlegroup identification)

- do not use excessive code execution in COMBAT_LOG*EVENT(s). minimalism rules.

- disable guid scanning/digging/catching in combat!

- simply save the whole UnitGUID and you can sort it easily.

- digging for UnitGUIDs on a test/beta realm is really useless. nearly all characters are created in a very small period of time. if you try to test code for testing purpose, okay, but ptr/beta servers are slow, really very very slow compared to live servers.

- the UnitGUID is definitly date/time based!!! (date/time of character creation! but there is no way to get this info. there is only an estimated date/time based on very large data and (server-based/WoW) experience).

- it's not possible to get a creation date unless you link the UnitGUID with the information someone can see in the account management side (this is the only place where you can see _when_ an account! (not a char!) was created (date only, no time). nobody with brain would allow some external code dig data from the WoW account management side --- or you have a SendAddonMessage() addonbot that sends played time data to you (but played time is not creation date)...).

- UnitGUIDs are incremented exactly by 1. i have catched hundreds of such UnitGUIDs on live servers.

- UnitGUID != BN/RealID. there is currently no way to link these two IDentifiers with the Lua API (which is good and VERY VERY IMPORTANT!!!, and for the sake of privacy concerns hopefully Blizzard will never change this!!!)

- check out GT100GCX aka 'Gnomish Top100 GUID Catcher Xtrem'. the current release version available here at wowace.com can catch up to 1000 UnitGUIDs per server (main purpose of this addon is to get old characters, and well i am currently doing a rewrite). in local tests i tried 5000, 10000 and even 250000(!!!): after digging nearly 1 year with 250000(!!!-one server only) i have not seen that much different UnitGUIDs on my server (and my server is one of the best visited and one of the oldest in europe). conclusion: your number of 3 million UnitGUIDs is not real, even on a ptr/beta server where people from the whole world join. you simply can not dig that much UnitGUIDs in such a short period of (ptr/beta) time. impossible!

- a high or low UnitGUID says nothing without a very large amount of comparable data and server-based experience.


sorry, don't know if this is offtopic or useful

while we're discussing GUIDs... I see that you can pull GUIDs out of combat logs... and from the code posted it looks like the 12th argument of chat events seem to be GUIDs too (although I can't find it mentioned in documentation... is this new?)

Anyway Q1: if I have a Guid can I look up a player?

Practical example... I have a friend called "John" with a GUID (partial) of 1234567
I would like to check when I log in if name(GUID(1234567)) == "John" and if not then it looks like John has had a namechange. (witness protection?)

I don't mind if it's only run on online characters

Q2: if I have a player can I look up a Guid without waiting for a chat event or combatlog event?

Thanks

Kaz

1. If you have a only the GUID, you can't do anything with it. There is no WoW API that takes in a GUID.

2. If you have a player, you can only determine his GUID using the UnitGUID() command with a valid unitID handle (like "party3", "raid34pet", etc), or using the chat events or combat log which also use GUIDs.

Thanks Xin... really appreciate the quick response.

I think I need to do something hackey to get my idea to work.

It might also be interesting to note that when using private chat channels in WoW, when the current moderator leaves the channel, the next person to get moderator is the person with the lowest GUID.