For the past week, we noticed a gradual increase in CPU usage and
request times. Use of a sampling profiler revealed the time waas spent
in serializing/deserializing data stored in Redis. In particular, the
user counter dicts were filtered for calculation of the loggedin/out
counters, but the filtered versions were never stored.
To make concurrency safe, we still filter on every request, but at
least the resting data will eventually be appropriately filtered,
and this data is non-critical regardless.
* Add new /casino route and template
* Consolidate lottery into casino and add initial template for slots
* Change /lottery route to /casino and replace icon with usd symbol and change sitewide const to reflect change
* Hook up new slots method to casino
* Enable Marseybux spending in casino slots
* Add UI for playing blackjack in casino
* First connection of blackjack UI to backend
* Add protective clause thanks to help from carpathianflorist.
* Create new Casino_Game relation and persist inside of blackjack
* Connect new slots behavior to Casino_Game table
* Create UI action management logic
* Add blackjack game status checker which adds persistence for blackjack
* Gonna handle this better, hold on
* Reorganize blackjack helper methods
* Reorganize casino.js to account for new changes
* Connect up to frontend
* Little changes ya know
* Display a message when winning in Blackjack
* Fix some issues with double down and insure
* Revert "remove owoify-py from requirements"
This reverts commit 4454648ea2.
* A little casino styling change
* Reorganize into a casino block
* Smallenize the card'
* Remove references to old game data on comments
* Add sql migration file
* Remove logic to drop old columns
* Fix two forgotten conflicts
Permabanning already prevents users from initiating new DMs, and we
complete this by preventing replying to existing DM chains.
New modmails may still be initiated, and existing modmails may still
be replied to.