Commit graph

2054 commits

Author SHA1 Message Date
29aa769bda Oops, tiny copy edit for alt styles page
Right, missed this when renaming them, lol!
2024-10-22 16:44:42 -07:00
66438eae1a Add mode to keep labeled alt styles until they're all labeled
If you check this box, it'll keep you in a mode where saving an alt
style redirects you to the *next* one that needs labeling, until
they're all done. Useful for big drops!
2024-10-22 16:39:25 -07:00
d8ff99475e Add the Rails tests to the pre-commit hook
I'm gonna work on adding modeling tests, and I want to not be breaking
them without realizing! The trade history ones are good to be checking
more often like this, too.
2024-10-21 14:35:26 -07:00
9726ecb1a5 Fix trade activity tests: use a valid item fixture, not a placeholder
In 540ce08caa, I updated the Item class
to be more explicit about what fields are required, so this test would
fail in a more helpful way, instead of just crashing from `name` being
`nil` when trying to infer the Dyeworks info.

Now, we update the test to use Rails's standard "fixture" system to set
up a more-correct placeholder item, instead!
2024-10-21 14:26:36 -07:00
540ce08caa Handle invalid Item state a bit better
Catch missing fields in validation before sending it to the DB, and
skip the Dyeworks stuff if the name is missing.

I ran into this looking into `test/trade_activity_test.rb`, which fails
right now because we try to create a boring placeholder item with
minimal fields, which Dyeworks can't call `name.match()` on!

Now, the test fails with a more helpful error about the item being
invalid. Next, I'll fix that!
2024-10-21 14:24:45 -07:00
881e63cfbd Output JSON from rails pets:load[pet_name]
Gonna use this for making mock data for automatic testing!
2024-10-21 14:03:56 -07:00
09e5a39b4c Whoops, fix alt styles when modeling real pets wearing them
Just never did this, I guess!! 😅
2024-10-18 19:16:41 -07:00
bf20c9bb31 Ah beans, I goofed alt style modeling *again*
Feeling for-real about getting a test suite set up because oh my god
2024-10-18 19:01:26 -07:00
7607c2c015 Oops, fix sloppiness about pet service refactor
I guess I like super didn't test this end-to-end, oops!!
2024-10-18 18:14:01 -07:00
abfe1e6df7 Extract neopets_origin into a config value 2024-10-18 18:00:48 -07:00
e36e273d50 Extract Neopets::CustomPets service from the Pet class
Just getting this stuff out of Pet, in part because I want to start
being able to unit test modeling, and that will require stubbing out
what this service returns!
2024-10-18 17:40:31 -07:00
83e5ad6bcc Update alt styles copy to adjust for them not all being Nostalgic now 2024-10-18 17:29:48 -07:00
acb52cb870 Move NCMall and NeoPass services into a Neopets module
Just a bit more clarity of grouping! I'm also thinking about extracting
modeling APIs into a service file like this too, in which case I think
this would help clarify what it is.
2024-10-18 17:27:15 -07:00
7ef689d658 Remove unused ostruct import
Only noticed it cuz there's a deprecation warning, and so I was like,
do we use it? I think not anymore!
2024-10-18 17:20:02 -07:00
23c083ff1d Use "real" series name field when editing alt styles
Just a little improvement to the form, so when there's no series name,
the text field is empty—even though in most contexts we *pretend* it's
"<New?">
2024-10-18 17:13:16 -07:00
6b7c73870a Stop inferring AltStyle series name, now that it's getting more varied
They're not all Nostalgic anymore! Oh, how the times have changed!

This way, new ones will appear as "<New?>", until support staff come in
and label them (with our cool new tools!)
2024-10-18 17:07:38 -07:00
e7a0ff1234 Make deleting an AltStyle also delete its ParentSwfAssetRelationships
Not relevant in-app as such, I'm just deleting records to re-test
things in development, and it helps to keep things in a more consistent
state!
2024-10-18 17:06:13 -07:00
50c9ba53e7 Add announcement explaining alt style bugs
so people know it's fixed and can model them now lol
2024-10-18 17:04:44 -07:00
89c729ecbe Oops, fix bug preventing new alt styles from being saved
Whoops, I didn't realize this change I made to validation for the alt
style editing form, was goofing up alt style modeling!

The trick is, the validation was happening before the `before_create`
hook. Now I've reformulated these as `before_validation` hooks, so
we're not rejecting new alt styles for having no thumbnail!
2024-10-18 17:04:26 -07:00
bb83f6fd36 add redirect from /alt-styles to /rainbow-pool/styles
In a recent change, I changed the path for this page—but forgot to
keep the old URL available as a redirect, for older links! Fixed.
2024-10-18 14:25:03 -07:00
7891acd3b1 Oops, missed a spot for Modeling -> Rainbow Pool link updates
Whoops, clicking the *paint brush image* still linked to the Modeling
Hub, instead of the Rainbow Pool. Fixed!
2024-10-12 14:17:49 -07:00
16deee94e4 Remove now-unused pet state show page 2024-10-11 17:48:23 -07:00
2cc0c5b031 Link pet states to outfit editor instead of their not-useful show page
I was considering doing more with the show page at one point, but ehh,
I think the outfit editor is the better place for that stuff anyway.
2024-10-11 17:44:56 -07:00
381a892af8 Add a bit more space around Rainbow Pool filter forms 2024-10-11 17:39:35 -07:00
1a0fb68b1c Add more explanation copy to Rainbow Pool pages 2024-10-11 17:38:34 -07:00
4f9fbc1ac0 Improve pet type "Added" timestamp styles 2024-10-11 16:24:47 -07:00
ad51690617 Sort pet types alphabetically when filtering the Rainbow Pool
The default is latest first, but when you're searching a color or
species, you probably just want a consistent alphabetical order.
2024-10-11 16:24:24 -07:00
5648f55d2c Add date to pet types in Rainbow Pool 2024-10-11 16:00:07 -07:00
6934b636fb Update Pet Styles copy 2024-10-11 15:50:31 -07:00
83fe0d20e0 Add Rainbow Pool breadcrumbs to Pet Styles page 2024-10-11 15:42:19 -07:00
be5ad31a1d Link alt styles to the outfit editor, rather than to the big image URL 2024-10-11 15:40:20 -07:00
1626f0706c Move Alt Styles into /rainbow-pool URLs, say "Pet Styles" more in text 2024-10-11 15:37:37 -07:00
7fad6abfed Add homepage link to Rainbow Pool, and move Modeling Hub to footer 2024-10-11 15:27:36 -07:00
c985c50a1b Add special styles for the placeholder option in select tags
Noticed this for the Rainbow Pool filters!
2024-10-11 15:23:35 -07:00
bba863b94b When filtering to a specific pet type, redirect right to it!
That is, if you filter to "Candy Chia", we just redirect straight to
it, if it exists; rather than showing you a results page.
2024-10-11 15:13:59 -07:00
7c1b3ca447 Add "no results" output for Rainbow Pool filters with no results 2024-10-11 15:13:22 -07:00
71f0aa4908 Oops, fix modeling logic
Oh huh, I guess most of the new items we had when I rewrote this were
Maraquan, and I didn't test enough on standard species-specific items.

Before this change, partially-modeled items for standard pets would
appear as fully modeled, because the presence of the "nonstandard"
color Orange (because of the Orange Chia) meant that the "standard" key
didn't actually have any unique bodies (it was all `["standard", 47]`).

Here, I take my own comments' advice and move away from the standard
label as part of the logic. Instead, we look first for nonstandard
colors with unique bodies, which we'll call out as modelable; and then
check whether there are any basic bodies *not* covered by those special
colors.

That way, compatibility with the Maraquan Acara (a unique body) means
we'll treat Maraquan as a modelable color; and then we'll ignore the
basic bodies, even though it *does* fit the basic Mynci, because there
aren't any compatible basic bodies that aren't *also* Maraquan bodies.

This also means that compatibility with both the Blue Acara and Orange
Acara does *not* preclude a normal item from needing basic pets for
models: because, while Orange is a slightly nonstandard color in the
case of Chia, it doesn't have its own unique body for this item, so we
ignore it when predicting compatibility with basic colors.
2024-10-08 22:46:11 -07:00
13a0362e6d Use PetState#updated_at for the supported pose cache key, not latest ID
This is because labeling poses with the Support tools *should*
invalidate the `PetState.all_supported_poses` cache! But the previous
cache key would only invalidate when a new pet state is *added*, not
when one is *edited*.
2024-10-07 17:56:42 -07:00
fe67211fdf Add created_at/updated_at to PetState
This has just been absent for too long! We've lost a lot of data about
when poses were first modeled, which is a shame.

But I want this in now, because I was just doing caching on
/rainbow-pool.json, and realized that _labeling_ poses is another way
pet states can update rather than just being created!

So we need an `updated_at` field, to be able to quickly detect edits
that require us to invalidate the cache on
`PetState.all_supported_poses`. I'll do that next!
2024-10-07 17:54:54 -07:00
0244653cb0 Add /rainbow-pool.json for all species, colors, and poses
This clocks in a bit bigger than what Impress 2020 does in terms of
binary encoding (with gzip it's at 11K instead of 4K), but I'm okay
with that for the simplicity win.

Gonna try to swap this in for where we're still using Impress 2020 for
the species/color picker in the outfit editor!
2024-10-07 17:38:53 -07:00
2c0d55edd1 Remove unused code related to no-longer-present asset downloads 2024-10-07 17:06:14 -07:00
be0faaa36e Improve top nav support on mobile for responsive design pages
Before this change, pages that opt in with `use_responsive_design`
would often have the top nav be real cluttered for logged-in users. (I
think I happened to first test this responsive design without being
logged in on my dev box, oops!) Because the home link and `#userbar`
were absolutely positioned on the page, they would frequently overlap.

Here, I stop doing our old tricks to make the top nav load last on the
page. (This was to get "main content" loading faster, which I think is
a. not as relevant today with more commonly faster connections, and b.
was a bit naive to think that it'd be helpful to have to wait a long
time to _navigate_ if a page is unexpectedly large.)

These tricks used to leave some padding at the top of the `#container`,
which these elements would then visually fill via `position: absolute`
once they load.

Next, I update the CSS (for the responsive design pages only) to use
the new `#main-nav` container to lay them out in Flexbox: all in one
row if possible, or wrapped if needed.

Some designs hide stuff like this into a hamburger menu or such when
the screen gets small. I haven't done that here! No specific reason,
I'm just not sold that it's that much better, or worth the trouble.

I tested this on the following combinations:
1. Logged out, homepage
2. Logged in, homepage
3. Logged out, `/items`
4. Logged in, `/items`
5. Logged out, `/items/89487-Dyeworks-Purple-Haunted-Sky-Background`
6. Logged in, `/items/89487-Dyeworks-Purple-Haunted-Sky-Background`

Hope it's solid! 🤞
2024-10-05 17:52:38 -07:00
f87f4e61b3 Add extra support info to Rainbow Pool pet types
Easy-to-notice hints for which pet types need more labeling!
2024-10-04 19:24:40 -07:00
dfca88bed3 Oops, use the Rainbow Pool list styles under "Other" show/hide 2024-10-04 18:46:53 -07:00
bd001e643e Oops, avoid scooping up weird Chia bodies in predicted_body_ids
Before this change, a fully-modeled item (Dyeworks Burgundy: Gown of
the Night) was displaying as still needing the Chia. This was because
looking for "standard" body IDs like this caught up some of the weird
Chia bodies.

I think there's probably something here where we need to like, relabel
certain colors? But honestly, the better version of this logic would
probably be to lean more into the `basic` label in this logic.

But hey, that's a refactor for another time. I gotta go eat!
2024-10-03 15:39:35 -07:00
1d51e28144 Post perf upgrades announcement (and job-hunting ask 💖️) 2024-10-03 15:09:38 -07:00
fe4db1b605 Improve prediction for what pets need modeling for an item
Noticing a lot of Maraquan items on the homepage today, and they're
doing that thing of expecting standard body types to be relevant too,
because I think we wrote this logic before the Maraquan Mynci ended up
having the same standard Mynci body? (Maybe? Or maybe I'm being
ahistorical and I just wrote this wrong to begin with lol)

In any case, this is more accurate, and I think I'm also maybe
incidentally noticing that it's running faster, at least in my brief
before/after production testing? (There's *more* queries, like 100! But
many of them are *very* fast lookups, coming in at under 1ms—and also a
lot of them are dupes being served by Rails's request-scoped query
cache.)
2024-10-03 13:49:15 -07:00
860b8eef72 Remove not-very-useful caching for homepage modeling
Huh, I hadn't realized that like, we'd already set up the controller to
always *run* basically all of the modeling logic, and the caching in
the view layer wasn't saving us any queries anymore. Kinda silly!

Remove the caching call, just to simplify the codebase (I like to avoid
caching things that don't specifically need it!).

And hey, love that the modeling code in the controller is now *way*
faster to run! You love to see it!
2024-10-02 18:26:49 -07:00
61e22e3943 Oops, remove no-longer-true comment about a code block I just deleted! 2024-10-02 18:20:22 -07:00
03e4233f67 Use cached compatible body IDs on homepage modeling code
This should make it load way faster! Maybe don't even need to mess with
caching the resulting HTML anymore, like we currently do?
2024-10-02 17:55:20 -07:00