WowAce

Hi - thanks for a great library.  I tried submitting this as a comment but kept getting a server error.

I'm not sure if any addons are actually using your Chromie Time expansion info function - not just because the main function is called GetChomieTimeActiveExpansion() - but in tinkering with it, I have noticed that the ipairs iterator loop seems to omit Legion at the end.  I don't know why.  When I iterate with pairs it looks reasonable.  Just a strange thing and a potential heads up.  Thanks again - k

Hi :-)

Thanks for your feedback, I'll take a look at it!

Odica

Let's make sure I understand correctly... You are talking about the ipairs on line 2720 of Libtourist-3.0.lua?

	for i, ct_expansionInfo in ipairs(ct_expansions) do
		if ct_expansionInfo.alreadyOn == true then
			info = ct_expansionInfo
			break
		end
	end

 I have found that the behaviour of pairs and ipairs is slightly different:

• pairs() returns key-value pairs and is mostly used for associative tables. key order is unspecified.
• ipairs() returns index-value pairs and is mostly used for numeric tables. Non numeric keys in an array are ignored, while the index order is deterministic (in numeric order)

For the loop in GetChomieTimeActiveExpansion the key order does not matter, as long as all members in the collection can be processed until one is found that is 'alreadyOn'. In other words, for this function it should make no difference whether pairs or ipairs is used.

If you say the GetChomieTimeActiveExpansion function works correctly if pairs is used instead of ipairs, I will change that in the next release.

Odica

It's really weird, - and now I can't find a character that reproduces the problem.  I just know that I when I traced the loop as supplied following 2720, I was getting 5 lines of output, and the one missing was Legion.  When I copied the code to a my own little module and changed it to pairs(), I got 6 lines of output.  I know that ipairs() will stop iterating if it sees a null key, but all the keys from pairs() look legit numeric types, at least now.  Maybe it had something to do with the exact state of timewalking I was in?.  This was my diagnostic code:

local ct_expansions = C_ChromieTime.GetChromieTimeExpansionOptions()
for k, ct_expansionInfo in pairs(ct_expansions) do
    print("ix type "..tostring(type(k)).." = "..tostring(k).." - CT Ex "..tostring(ct_expansionInfo.id)..": "..tostring(ct_expansionInfo.name)..": "..tostring(ct_expansionInfo.alreadyOn).." mapAtlas: "..tostring(ct_expansionInfo.mapAtlas))
end
for i, ct_expansionInfo in ipairs(ct_expansions) do
    print(tostring(i).." - CT Ex "..tostring(ct_expansionInfo.id)..": "..tostring(ct_expansionInfo.name)..": "..tostring(ct_expansionInfo.alreadyOn).." mapAtlas: "..tostring(ct_expansionInfo.mapAtlas))
end

Again, thanks for a great library.

As far as I know they should all be there. The expansion you are timewalking, if any, can be recognized by the alreadyOn attribute. So your character's timewalking state should not be of influence on the number of expansions in the collection...

At the moment I have no explanation for the behaviour you observed. Let me know if you find a way to reproduce it, maybe I can reproduce it too.

And thanks for the thanks ;-) 

If I make it happen again, I will freeze everything and dump it here :) take care

 I will freeze everything and dump it here :)

I can hardly wait LOL

Can I close this issue?