All Gem Hunt WRs are yours with one simple trick!!! Click here to find out :)

I've been sitting on this for a long while, and its time I finally get this out. Sorry to all of the forum lovers, but I'm forcing you to open a google docky against your will.

docs.google.com/document/d/e/2PACX-1vSTd...CDlnBhuIoERVrYN8/pub

I will not be looking at the forums for a long while after I post this, so if you really want me to see your comments, questions, and/or critiques, don't reply to this thread, dm me on discord or get a middle man if you can't. You can still use this thread for any updates concerning this topic and I'm sure someone will inform me if there are any, but it's very unlikely that I will respond to it on the forums.

Along with my google doc, I have also decided to release a video to go along with it:



You can enjoy it as a normal compilation video or use it to replace whatever ASMR you listen to to help you sleep at night, either way is fine by me.

I would also like to formally resign as mod/helper on the forums right now, since I see I still am one. I see no point in keeping it currently, but I will see how I feel if/when I return to the community proper.

Unrelated to the main topic, but

Mazik wrote: If gem hunt had a live gem counter with all the colored gems and what number spawn you are on

seems like a neat idea. idk about adding it to the game itself, except maybe as a console readout or something, but it does seem like something you'd see in a mod.

Goddamn, Good video.

Little known fact but the 8-bit signed integer variable that keeps track of your Long Break Luck overflows at 127 hours and becomes -128, letting you get good spawns again. Ask anyone who knows how to read the code, they'll concur. Unfortunately, the Short Break Luck counter is a 32-bit signed integer of milliseconds and only overflows after the game has been open for roughly 25 days, since the code uses getRealTime() which reports as an i32 milliseconds (similar bugs have been seen in macOS, actually! any time you see news about "x computer stops working after 25 days, it's probably 32-bit signed integer milliseconds). I recommend keeping multiple copies of PQ open in the background so you can swap to a freshly aged copy if your current one crashes. 🤔 Also there's a legit bug here where certain parts of the code use setRandomSeed(getRealTime()) and if you're exactly on the 50-ish day uptime millisecond where that rolls over, it can set the random seed to 0 and the spawns will be completely non-random and broken (I actually don't know what this will do).

Also if you thought that getRandom() was rigged, it actually is! If the number of gems is not a power of 2, MRandomGenerator::randI will take the modulus of a randomly sampled value in [-2^31, 2^31) with a non-power-of-2 value and return uneven results, skewed towards smaller numbers (e.g. if you pick randomly from 1 2 3 4, except if you choose 4 then switch it with 1, so your distribution is actually 1 2 3 1 and 1 is most likely). Does this actually matter? Technically, yes, it does have an effect! There are fancy math ways to make this not happen, but they aren't used in the Torque engine because nobody actually cared about precisely even probability distributions for random numbers, and "close enough" is what you get from game engines. Also there's a case to be made that LCGs aren't true randomness either, so maybe PQ should require you sample a TPM or something.

Gem spawn likelihood is also affected over the course of a single play: look for the code regarding _spawnWeight in huntGems.cs. The algorithm on that is floor((1 - (<distance from gem to center> / <distance of furthest gem from center>)) * 10). This value gets accumulated for each gem over the course of a play and affects the "spawn block radius" which prevents the next spawn from being too close to the previously chosen center gem (or in MP, the currently winning player). It doesn't seem like this affects spawn chance after a center is chosen.

Type-2 gem group spawns (eg Exoplanet) also have a cooldown system. See _spawnCount in huntGems.cs for this. Each group gets added to a list based on the number of times it has spawned already (less times spawned == on the list more times), then a random group is picked from this weighted sample. On further observation, it seems like _spawnCount actually does not get reset between restarts, so getting extra lucky on one attempt will make you adversely less lucky on future attempts until you change levels or close the game. Same goes for being unlucky. That probably should be fixed, oops. Anyway, within the group, the above gem-specific spawn chance rules apply too. 

Oh and one more fun fact: If you play a level too much and get over 1 million respawns, the respawn counter will break and you will be stuck at 1 million. Dunno if anyone has encountered this yet, but I will congratulate (and offer sympathies to the fingers of) anyone who achieves this without intentionally trying to reach it.



Anyway happy grinding and holy shit you got more points on these levels that I ever expected. Congrats on the WRs to each player over the years.