ScanArchProjects triggers Integer overflow error when attempting to show achievement toasts

[Vazziera]

1x integer overflow attempting to store 6484948244 string "=[C]": in function format' [string "@Rarity/Core/GUI/FauxAchievementPopup.lua"]:135: in functionShowFoundAlert' [string "@Rarity/Core/EventHandlers.lua"]:718: in function OnItemFound' [string "@Rarity/Core/Collections.lua"]:380: in functionScanArchProjects' [string "@Rarity/Core/Collections.lua"]:308: in function `?' [string "@Ace3/CallbackHandler-1.0-8/CallbackHandler-1.0.lua"]:114: in function <...Ons/Ace3/CallbackHandler-1.0/CallbackHandler-1.0.lua:114>

[string "@Ace3/CallbackHandler-1.0-8/CallbackHandler-1.0.lua"]:24: in function <...Ons/Ace3/CallbackHandler-1.0/CallbackHandler-1.0.lua:20> [string "@Ace3/CallbackHandler-1.0-8/CallbackHandler-1.0.lua"]:59: in function `Fire' [string "@Ace3/AceEvent-3.0-4/AceEvent-3.0.lua"]:120: in function <Ace3/AceEvent-3.0/AceEvent-3.0.lua:119>

[rdw-software]

Uhm, I can't look into this in detail until the new year... but I remember there being an issue with archaeology attempts when Blizzard last changed the API. Some potential causes of this error may be:

1. Blizzard has changed the Archaeology APIs and they're once again storing garbage data in Rarity's DB
2. It's an old SavedVariables file / Rarity database that still has the old "corrupted" attempts stored in it
3. It's because of the new race being added that Rarity isn't yet accounting for

Can you try selecting a new (fresh) profile to see if the error still occurs? If yes, that would hint at 1 - if not, that might be 2. If you're not a returning player who's using an ancient Rarity database then it's likely 3.

Either way, I can't do anything about it right now. I'm guessing lots of stuff needs updating in Rarity to work with DF properly.

[rdw-software]

I originally suspected that the missing entry for the new dragon race (see #529 ) could cause Rarity to initialize attempts to an invalid value. And that may yet be cause for concern. However, there seems to be a separate and more serious problem with the archaeology code (other than the fact it's generally terrible). Specifically, there's this line in the Collections module:

local t = select(10, GetArtifactInfoByRace(x, y))

If I understand the surrounding code correctly, it is supposed to return the number of attempts (solves?). But GetArtifactInfoByRace doesn't have a tenth return value. This means the number of attempts will be nil, and adding nil to any number can explain the strange error that caused this report in the first place.

Case closed, right? But no... there's more:

• Assuming the "Patch Changes" section on Wowpedia is accurate, there never was a tenth parameter. Ever
• So why did the code return this for-ever nil value? I wondered...
• Blame shows clearly, it was changed in this commit, as a "fix" for a similar issue to this one
• I found this ancient WowAce ticket, which seems to be the report that caused the above change
• Indeed users have reported that the fix worked for them. How? Were there other (related) fixes?

Need to review the changes prior to r659 in detail to understand what the context was, but I don't have the time right now.