Pokemon Count BBCode

I don't believe I've seen this suggested before- let me know if it has been ^^; Basically, the way this would work is similar to the inventory count code. It would keep track of a certain species of Pokemon, and separately of Shinies, Albinos, and Melans. The way this would look is: [fields=Shuppet] would return the number of Shuppet you have in your fields. It also includes Shinies, Albinos, and Melans in that count. (It might be cool to have it where it works not only by name, but also by dex number.) If you had 3 Shuppet in your fields, it would return the number 3. [fields=shiny_Shuppet] would show only shiny Shuppet in your fields- not regular Shuppet, albino Shuppet, or melan Shuppet (even though you could argue that melans are technically shiny, this would work better for inventory's sake). You get the idea- it would also work that way for albinos and melans. Hopefully I don't have to write it out ;p The main uses this would have is for shop inventory and for hoard tracking. In a shop, you could list the amount of shinies you have for sale and have it automatically updated. And the hoard count would just be cool for bragging rights. Perhaps a [field=all] as well as [field=shinies_all] (etc.) could also be added to show the total amount of Pokemon/shinies/etc. that you have. I know the main argument against this suggestion is going to be the possibility that it may strain the system, and I have both a counterpoint and a remedy. The number of Pokemon by species is already tracked by the field search, so I can't think of a reason that it would be any worse when implemented in BBCode. If it is a problem for some reason, it can be helped by having the numbers update hourly. That way the system doesn't have to recalculate every time someone loads the page. Thanks for the read!

It has, and it was rejected. Inventory is literally a count of your items. Your suggestion would involve re-counting every single time. No way. Not happening.

Would caching help?

No. Aside from the weight of calculating in the first place, people would be incredibly confused by it not being up to date.

Frankly, I don't really understand how it would be any more stressful than the field search function, since it essentially does the same exact count. What if it refreshed at most once an hour, and if it's been more than an hour without anyone viewing the page, then it refreshes the next time someone views the page? Even if it's not quite up to date, if someone has 20 shinies in stock, you'd know they're not close to running out. So it'd help in that regard. It'd also be very nice for hoard counts, regardless of how often it refreshes.

Right, because the system that already handles your population can totally be just plugged into forum posts. - Group all Pokémon you own and count them - Get the number of a specific one you own. Totally the same. Why can't people just believe me when I say somrthing will not work? Why must it turn into an argument? In which I will always be the bad guy because I'm "totally shooting down the suggestion" even though I know exactly what is and isn't possible in the system that I built?

I wasn't trying to make you 'the bad guy' or whatever. I was just asking for clarification as to why it wouldn't work, since it seems like a very similar process.

X and Y both have the same ^V top half, but are completely different. Just because both things are somewhat related to counting Pokémon... I mean yes, but you're totally ignoring the context. One is in a private view, that only uses your own data and performs a single grouped count. The other is accessing someone else's data (the post author when you're the reader) to perform a single count for each code (one BBCode can't pass its calculations to the next) and you're also suggesting further filters on that too... They're nothing alike, and the latter is impossible. EDIT: okay, not impossible, but laggy as all heck.

Yeah, that makes sense. Thank you for the clarification.