1. For backwards-compatibility, the system supports "a berry ID and list of targets" in addition to the newer "array of batched interaction objects". Since the code is so old, I can't be completely certain that there isn't still some system using the old style, so first it gets converted to the new style if necessary. 2. Decode the ID of each interaction and validate that the berry being fed is valid. 3. Assert that the count is not over 40 (triggers "interaction overload" error which shouldn't happen, but may occur when some click-fast CSS is used) 4. Ensure that the "token" is correct and corresponds to the interaction data. This uses some fairly rudimentary "encryption" (where the key is embedded in the source code so not exactly "secure"!) to ensure that it is in fact PFQ's code, or at least a relatively recent clone of it, that is making the request. 5. Load each Pokémon's data. This is done from cache if possible, which is usually possible because the Pokémon will have just recently been loaded for you to interact with it in the first place. 6. Assert that all Pokémon are distinct and all belong to the same user ("the Recipient") 7. If the count is 12 or fewer, figure out of it is a Party Click. This is true if all individuals are in the Party right now, were recently in the Party (a "phantom" is cached for a short time when a Pokémon is moved out of the Party to allow for this), or are in the Showcase. 8. If it is NOT a Party Click, assert that they are all in the same Field. There is no "phantom" for this, so if you're mass-clicking someone and they happen to move a thing you were clicking out of the field, the interactions will fail. This is fairly rare though, especially in comparison to moving things out of the Party (looking at PKRS...) 9. Validation complete, initialise buffer for counting results and rewards. 10. For each Pokémon, check to see if an interaction has already been made by the user today. If so, skip it. 11. Get the Pokérus host, Niet's Counter, Garthic's Counter, the V~Wave, the Recipient's Gemwish badges and any other applicable EXP bonuses. This is "loaded" for each Pokémon, but it is memoised so that when the second interaction attempts to load it, it's already in memory so good to go. This means that the code style is inefficient, but the code itself is fine. 12. If it is an Egg, load the Party (also memoised so it's only done once). Check each hatched Pokémon to see if it, when reduced to its base form, matches the Egg's numeric Dex ID (ignoring forms). This involves looking up potential Mega Evolutions and Paradoxes, as well as Forme-changes and regular Evolutions, "reversing" them all to get back to the base stage. This is globally cached so rarely actually needs to be evaluated, but it is done here if needed. 13. If it is a hatched Pokémon, evaluate its Level (this scales EXP gain linearly) and its Nature (for flavour modifiers). Nature data is typically always in cache too, but Level is calculated using a very old and slow linear search through the EXP table. (A level 100 Pokémon involves 100 comparisons to check each threshold. For comparison on PFNext (and PFQrv2) it uses a binary search that requires only 7 "higher or lower" guesses to find the level.) 14. Apply additional modifiers such as Niet's Bonus, the Birthday bonus, Hypermode, PKRS and "helper ranks" (they get +10%) 15. If it is an Egg, also apply a "new user" modifier. New users hatch their first 200 or so Eggs slightly faster to help get them moving. 16. Apply Interaction Point bonuses. 17. Calculate Credits gained. 18. Save the interaction into the queue. Experience is updated in Memcache but is only actually saved the next time the Recipient loads that Pokémon. At this point the queue is processed. This is to adhere to the policy that "only the owner of a piece of data may modify that piece of data" which helps avoid race conditions which would otherwise lead to EXP not being counted. 19. If the user is logged in, check the PokéDex to see if the target is registered in there. If so, Wishforge badge progress can be accumulated. 20. Increment total reward buffers, and go back to step 10 for the next Pokémon. This may repeat up to 40 times for a full Field. 21. Once all interactions are done, apply the total gains to the user (Credits, IP gain, stats, Wishforge progress, Fossil progression...) 22. Record/update stats on "interactions made today" (for History stats) 23. Load the Daycare. Advance its progress by the amount of interactions made. If a cycle completes, process it and produce an Egg if successful. 24. Load the user's Party. If the user has an EXP. Share and/or an active Lucky Egg, grant EXP to party members. 25. Record/update stats on "today's interactions" (for Clickback - note this is a separate record from the similar one in step 22) 26. If the Tournament is an interaction-based one, progress it. 27. Load the Dojo. If there are Pokémon without Training Bags, roll RNG to potentially find one. If they have a Training Bag active, progress it. 28. Check for active Story Events that involve interaction-based objectives and progress them if appropriate. 29. If the user is NOT logged in, check for validity and award Delta Points to the Recipient if applicable. 30. Format the results of the interaction, such as updated EXP bars for the Party page, and return to the browser.

I tried to break it. I could not. It even worked first try in some places. Is this what being a good programmer feels like?

There's no hindrance and it's a fun "minigame" to keep the number from dropping. The "minigame" ends when you're done with the last field and you're rewarded with a stretch/hydrate break.

I found that with my usual setup - QWER binded to left click utilizing the one click CSS in mass clicking and QoL for party clicking. That the biggest impact was finishing a batch of 50 parties/showcases which had the longest wait for the server to receive interactions, however this wait did not feel any different than what is currently on the live server when clicking a 50 list of parties. The counter UI in field clicking is a great visual for understanding what needs to be sent to the server. It is tempting to fight the pending numbers to go up but the more you do that the more you gotta wait when you're at the end of a users field XD As someone who really didnt want anything that might slow down my clicks, this feels seamless. It will take some adjusting especially for users like me who rely heavily on CSS but overall it feels nice!

Testing this update in the dev environment, the differences had to be pointed out to me, because there was no noticeable change to my gameplay. I don't believe that any healthy gameplay style will be adversely affected. Unhealthy gameplay styles... well, maybe reconsider your style. Your hands will thank you.

Changing number in brackets make my brain go brrr. Very satisfying. 10/10

It might just be me but I've noticed that when clicking fields the server is running a lot faster than what it was yesterday. Which is really nice. Either way, watching the (+x) in fields is lovely, and as said by Deadlock makes my brain go brrr. So at least on my end things are going smoothly and I'm liking the change.

As someone who clicks with QoL, stack and two thumbs (mobile moment), I enjoy the (+X) counter, it allows me to see when the interactions have been counted before I swipe off the page: especially important with the blitz of a SLE and/or PokéRus Great addition, for sure!

lunatics who six finger click on mobile with CSS

I use a css (that I don’t really understand bc I don’t code) and it is DRASTICALLY improved! I just tried to beat it, and I couldn’t until I got to the end of my party batch. Thanks again for all the effort you’re putting in! Edit: my daily clicks had been 60k and dropped to 10k lately with all the lagging. This will really help get those variant eggs 😁 EditEdit: I just got 1k party clicks in less than 5 minutes, but it killed my Spotify. I’m gonna jokingly say it broke my phone before it broke the new code. RIP 🪦 My Cleaning Music

The code isn't live yet, this is just a plan XD