I pulled the source map for the Neopets renderer, and had Claude compare it to ours. It noticed the key issue responsible for a high number of unsolved rendering issues: we weren't setting up the `MotionGuidePlugin`, which I've never heard of before. Whoops!
In addition to this, we made some other minor fixes for consistency:
- Use whatever Stage object the library exports (will sometimes be StageGL)
- Resize the stage rather than the clip (shouldn't matter?)
- Send a callback to the library when done (I'm not aware of any anims that use this but some may!)
The specific item I was debugging was "Food Fight Shower", and it works now! But I also know we've had a solid handful of similar inexplicable wild rendering bugs, which I imagine this solves as well.
We might want to consider auditing our Known Glitches on SWF assets to see how many of them can be removed, now that this is resolved.
No specific motivation here, no awareness of security issues; this is just an important gem to be unusually on top of, to prevent XSS attacks.
We were previously on 6.1.3, the previous release, and the only changes were Ruby compatibility and additionally supported CSS properties (which we don't use). But this just keeps us more easily plugged into potentially important fixes down the line.
This is a Ruby LSP that I no longer use, because I'm on RubyMine full-time.
My immediate motivation for this change is that solargraph's eventual dependency on the `parser` gem triggers warnings on all Rails commands, hinting that it doesn't support the *exact* Ruby version we use.
This could potentially be resolved by upgrading Solargraph or some of its dependencies, but since I'm not using it anyway, may as well just remove!
We discovered a previous string encoding bug fix that was causing crashes for some items, was casuing *other* items to get reencoded incorrectly.
In this change, we make the reencoding conditional, only if parsing as UTF-8 is failing.
We also include a temporary repair script, to run in production then delete—but held here in git history for posterity.
It says "This item is part of a deluxe paint brush set.", with a period instead of exclamation mark.
There are also a couple cases where the paint brush item additionally has an "inspired by" credit after the first sentence. Rather than get picky about the pattern, we expand the `pb?` method to just check for the sentence as a substring, like the DB filter logic for `Item.is_pb` already does.
We run DTI on a few different architectures in practice, and the `vendor/cache` directory can be a bit confusing to manage when switching dev machines.
In this change, we add all our common dev machine platforms to the Gemfile.lock, so precompiled gems for all of them are cached, granting us resilience against the possibility of Rubygems going down, and speeding up deploys & installation.
The connection_pool gem changed their API, which caused a breakage in our react-rails gem.
It turns out though, we're not actually using react-rails anymore. It's primarily for React server-side rendering, which we don't do. Our React code is bundled as normal Javascript via our usual asset pipeline.
So, to resolve the gem incompatibility, we remove react-rails altogether. Neat!
Added prominent warnings in multiple locations to prevent accidental
database migrations that would break Impress 2020:
README.md:
- Added critical warning in "OpenNeo ID Database" section
- Highlighted that Impress 2020 directly accesses both databases
- Added warning in "Deployment" section about schema compatibility
- Linked to detailed documentation
docs/impress-2020-dependencies.md:
- Clarified both databases are directly accessed by Impress 2020
- Added new "Database Consolidation Blocker" section
- Documented that consolidation migration is ready but blocked
- Provided options to unblock (retire I2020 or coordinated deployment)
This ensures future developers (including future me!) are aware of this
critical dependency before proposing database schema changes.
Related: feature/consolidate-auth-database branch contains a ready-to-go
database consolidation, but it's blocked on Impress 2020 retirement.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Added critical information about database consolidation blocker:
- Impress 2020 directly accesses BOTH openneo_impress and openneo_id databases
- Any database consolidation must wait until Impress 2020 is retired
- Database migration is ready on feature/consolidate-auth-database branch
but is blocked on this dependency
This ensures we don't accidentally deploy the database consolidation
before addressing the Impress 2020 dependency, which would break
authentication for users accessing the site through Impress 2020.
Updated sections:
- Deployment Architecture: Clarified both databases are accessed by I2020
- After Full Migration: Noted database consolidation is ready but blocked
- Added new "Database Consolidation Blocker" section with details
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
First actual feature I'm letting Claude run! We worked the exploration of the updated API together, then it ran with the implementation.
I left this hanging for a long time.... good to finally have it updated!
I'm not sure if this is a Mac-only problem or what, but we were getting incompatible-function-pointer errors when trying to build the RocketAMF C extensions. This fixes that! (Maybe it's like, Mac-only but as of Ruby 3.4 in specific? We're running RocketAMF in production on Ruby 3.4 right now without this. Shrug.)
I'm starting to learn how AI agent stuff works, and a lot of what I'm finding is that rushing them into feature development sets you up for disaster, but that having strong collaboration conversations with helpful context works wonders.
So, I'm starting by creating that context: I had a little "here's the codebase" walkthrough conversation with Claude Code, and it generated these docs as output—which came out solid from the jump, with a few tweaks from me for improved nuance.
My hope is that this can serve both as an improved starting point for human collaborators _and_ if I let future Claude instances play around in here. That's a big theme of what I've found with AI tools so far: don't try to get clever, don't expect the world, just give them the same support you'd give people—and then everybody wins 🤞
Just because I'm poking at archiving again, I'm noticing failures when trying to run the `rails swf_assets:manifests:load` job, something to do with an "unacquired resource" with the connection.
Maybe this is a bug that an update will fix? May as well try!
