Commit graph

1802 commits

Author SHA1 Message Date
965725f9e9 Oops, fix silly bug in Dyeworks Owls date parsing
Oh right, if I assume "date in the past means it's for next year", then
that means that, when the date *does pass*, we won't realize it!

e.g. if Owls says "Dyeable Thru July 15", then on July 14 we'll parse
that as July 15, 2024; but on July 16 we'll parse it as July 16, 2025,
and so we'll think it's *still* dyeable. Under this logic, it's
actually impossible for a limited Dyeworks date to *ever* be in the
past, I think!

I think 3 months is a good compromise: it gives Owls plenty of time to
update, but allows for events that could last as long as 9 months into
the future, if I'm doing my math right.
2024-06-20 14:05:00 -07:00
341a8dd89c Disallow text wrapping in the "Total" cell in Item Getting Guide
The table layout algo can get a bit funky about how it assigns extra
space, I want to encourage things like "Total: 5 items" etc not to
wrap, esp in the Dyeworks case where it's quite long!
2024-06-20 13:55:04 -07:00
3d6abc84dd Layout tweaks to Dyeworks in Item Getting Guide
There's more and more going on in here! Let's omit the base item name,
increase the table width a bit in this case, and tweak the rest a bit
while we're here.
2024-06-20 13:50:48 -07:00
cec29682c4 Add NC Trades button to Dyeworks in Item Getting Guide 2024-06-20 13:50:04 -07:00
589d728c76 Add clearer Dyeworks explainer
I uhhh literally didn't know Dyeworks was a gacha system until Kaye
from the Owls team told me lmao

I should maybe uhh read more guides instead of assuming I've osmosed
things correctly oops!
2024-06-20 13:21:56 -07:00
2e3d5d2020 Vaguer potions info for Dyeworks in Item Getting Guide 2024-06-20 13:14:51 -07:00
97abd6e438 Add probabilities to Dyeworks items in Item Getting Guide
I'm gonna better explain the gacha nature, I'm doing this part first!
2024-06-20 12:54:39 -07:00
b6bd539fed Oops, fix indentation in Item::Dyeworks
Ahh, I started a tabs-y file (as I default to these days), but copied
code from a spaces-y file, and didn't notice. (My laptop editor isn't
configured to flag this for me, oops!)

Fixed!
2024-06-18 16:50:43 -07:00
10301900e2 Credit the Owls team for Dyeworks extra info in the Item Getting Guide 2024-06-18 16:49:09 -07:00
ec476f4c65 List the specific Dyeworks end date in Item Getting Guide, if we know 2024-06-18 16:47:05 -07:00
a9f44c0aa6 Configure the application's default time zone to NST (US Pacific)
This doesn't affect a lot right now, it was previously defaulting to
UTC I think? And I've confirmed that, while timestamps are stored in
the database as UTC, they're not interpreted any differently with this
setting. (Or, rather, it's loaded as a `DateTime` object for the same
moment in time, but in the NST time zone. Good!)

But this feels like a more useful default for displaying things for
development etc, and moreover, I'm working on some logic for things
like "when do limited-time Dyeworks items expire exactly?", and that
logic is made *much* simpler if we can just compare dates in NST by
default rather than fudge around with the zones on them and figuring
out the correct midnight!

(Although, as I type this, I think I maybe have thought of an easier
way to do it? So maybe this change won't actually be necessary for
that, but it still feels like a more sensible default for us
regardless!)
2024-06-18 16:39:37 -07:00
4e2110bf25 Add comment to Item#inferred_dyeworks_base_item 2024-06-18 15:26:28 -07:00
c6fbb9b797 Reorder Item::Dyeworks methods a bit 2024-06-18 15:23:39 -07:00
98ecbf029d Be case-insensitive when checking Owls values for Dyeworks status
Just to be a bit more resilient! I'm not aware of any issues rn but
this seems wise!
2024-06-18 15:22:15 -07:00
015010345a Extract Dyeworks methods into Item::Dyeworks module
There's just starting to be a lot going on, so I pulled them out into
here!

I also considered a like, `Item::DyeworksStatus` class, and then you'd
go like, `item.dyeworks.buyable?`. But idk, I think it's nice that the
current API is simple for callers, and being able to do things like
`items.filter(&:dyeworks_buyable?)` is pretty darn convenient.

This solution lets us keep the increasing number of Dyeworks methods
from polluting the main `item.rb`, while still keeping the API
identical!
2024-06-18 15:21:43 -07:00
26dfe13b0e Parse "Limited Dyeworks" items from Owls
Yay thank you Owls team! I might also try to parse the dates too, the
format seems to be "Owls: Limited Dyeworks - Dyeable Thru July 15"
2024-06-18 14:59:09 -07:00
4d24a9577f Only run public_data:pull if there are no pending migrations
Oh this was a fun little dev environment bug: I ran `public_data:pull`
on my laptop before migrating my database, so the `items` table pulled
as the latest production version, which included the migrations, but
they hadn't been marked as "run" yet.

So Rails was still telling me I needed to run them, but the migrations
themselves were crashing, with stuff like "there's already a column
with this name!"

This change ensures that `public_data:pull` won't run until migrations
are done, to prevent silly accidents like that.
2024-06-18 14:52:54 -07:00
1acb00e35a Add NC prices to item pages 2024-06-18 13:25:29 -07:00
bbd1849e19 Oops, fix crash for Dyeworks without Owls info in Item Getting Guide
Silly mistake, right, we might not have a trade value listed! This is
relevant for the new Dyeworks items that just came out like a few hours
ago, which Owls doesn't have info for yet.
2024-06-17 13:07:03 -07:00
598a9dac52 Oops, fix crashing bug when Item Getting Guide has *no* Dyeworks
Lmao I've been testing with an outfit that has all the kinds of items,
so I didn't notice that this new refactor to `@items[:dyeworks]` style
of tracking the items returns `nil` when there's none, instead of `[]`.
(I always make this mistake when I use `group_by` lmao sob)

In this change, we give the `@items` hash a default value, so that will
stop happening!
2024-06-17 13:03:12 -07:00
9f536f81b3 Refactor to use a new Item#source method for where an item is from
I'm doing this in preparation for maybe trying to load some of this
info into the outfit editor, too!
2024-06-16 12:37:53 -07:00
77f01a6cb9 Edge case: say "0 NC" for cost of no potions in Item Getting Guide 2024-06-16 12:26:55 -07:00
cd28c26ae7 Make thumbnail_url a manually overridable field for Alt Styles
Oh jeez, okay, the latest batch of Alt Styles are using a different URL
format for the thumbnail image!

This isn't something we can import via modeling, so we're gonna have to
keep on top of it manually. For now, I'll keep inferring the previous
format in case they keep using it, but here's also a console script to
fix up the latest batch. (At time of writing, not all of these are in
our database, which is fine; when pasting it into the console, those
lines will error and the script will continue.)

```rb
def update_style(color_name, species_name, thumbnail_url)
	AltStyle.find_by_color_id_and_species_id(
		Color.find_by_name(color_name),
		Species.find_by_name(species_name)
	).update!(thumbnail_url:)
end

update_style "Grey", "Blumaroo", "https://images.neopets.com/items/c0gk16fk.gif"
update_style "Grey", "Bori", "https://images.neopets.com/items/55qvx6mr.gif"
update_style "Grey", "Bruce", "https://images.neopets.com/items/6y6pyiuw.gif"
update_style "Grey", "Buzz", "https://images.neopets.com/items/7fh4avry.gif"
update_style "Grey", "Chia", "https://images.neopets.com/items/7b2jtn10.gif"
update_style "Grey", "Elephante", "https://images.neopets.com/items/0ne41rao.gif"
update_style "Grey", "Gnorbu", "https://images.neopets.com/items/75mwtqmh.gif"
update_style "Grey", "Hissi", "https://images.neopets.com/items/dxdi2mhm.gif"
update_style "Grey", "Kiko", "https://images.neopets.com/items/b9yiruxt.gif"
update_style "Grey", "Lenny", "https://images.neopets.com/items/c6cboc7e.gif"
update_style "Grey", "Lutari", "https://images.neopets.com/items/33fs4eqf.gif"
update_style "Grey", "Nimmo", "https://images.neopets.com/items/4karmgbl.gif"
update_style "Grey", "Ogrin", "https://images.neopets.com/items/dlw78fhk.gif"
update_style "Grey", "Quiggle", "https://images.neopets.com/items/0aipl0iw.gif"
update_style "Grey", "Ruki", "https://images.neopets.com/items/bjnjxsem.gif"
update_style "Grey", "Tuskaninny", "https://images.neopets.com/items/7rh57a0o.gif"
update_style "Grey", "Vandagyre", "https://images.neopets.com/items/6p8sgs69.gif"
update_style "Grey", "Xweetok", "https://images.neopets.com/items/bge9vp5e.gif"
```
2024-06-15 17:35:12 -07:00
36452a4704 Flag items you already own in the Item Getting Guide 2024-06-15 15:47:52 -07:00
56fe5e4889 Oops, fix bug in recent movie-pausing bugfix!
Oh right, this previously logic was silly: we can't count on the
*interval itself* to be reliably resetting the FPS counter state,
because the interval might not be firing!

I think this fix worked when I tried brief tests, but didn't work when
I did an (accidental) longer test, because the browser switched to a
more aggressive throttle mode, and the previous mode was close enough
on the resets for it to be fine, whereas this time the FPS counter
state got way too old.

Now, we reset the FPS counter state *exactly* when the page comes back.
2024-06-12 17:14:16 -07:00
60e9130891 Fix bug where changing tabs would *always* pause the outfit animations
We have a feature to check the movie's FPS, and pause it if it gets too
low, as a guard against especially low-performance movies. But this was
triggering in an *expected* case, where browsers intentionally throttle
interval events when a page is in the background (e.g. you switch to
another tab).

Now, our rendering is aware of page visibility: when the page is
hidden, don't bother rendering, and keep resetting the FPS counter
state, so that we can pick up with a fresh FPS counter when the page
comes back.
2024-06-12 17:05:53 -07:00
cedceeaf3c Set production hostname to impress.openneo.net
This doesn't matter-matter, it's mostly just so that when we SSH into
the production machine, the prompt presents itself as `impress` rather
than as `localhost`!
2024-06-10 13:09:37 -07:00
3310394fb8 Improve Owls value presentation in Item Getting Guide 2024-06-09 19:22:34 -07:00
be525d1d67 Oops, fix bug with empty subtitles in Item Getting Guide
Oh weird, even with `flush: true`, `content_for` will ignore an empty
block and *not* flush out the previous content. This could cause rows
whose subtitles *should* have been empty (e.g. no NC trade value) to
display the previous row's value instead.

Let's make this whole situation a bit more robust by having the
*template* clear out the subtitle right before calling the block. That
way, a previous row's value *can't* get in, no matter what.
2024-06-09 15:40:58 -07:00
3dbcf41e4f Restyle Owls link a bit in Item Getting Guide
I think it helps a bit to have only the label be dotted-underlined, to
hint that I'm offering help about what that *means*, but clear the way
for the value itself to be more visible and less cluttered.
2024-06-09 15:22:21 -07:00
9bc6be05f8 Add "Permanent" label to permanent Dyeworks items in Item Getting Guide 2024-06-09 15:21:42 -07:00
a3f910b7ce Add more line breaks to Item Getting Guide template source
Idk, as things get more complex, it was starting to get too crunchy!
2024-06-09 15:05:00 -07:00
1f0c8b87a6 Move Item Getting Guide subtitle UI out of helpers, into templates
I thought to myself, "I wonder if it's possible to use a sneaky hacky
`content_for` trick to be able to run this code in the template." And
indeed it is!

It's tricky cuz like, I want to render this template, and I want to
provide _multiple_ slots of content to it. So, in this variant, we keep
the block as being primarily for the actions, but also optionally
accept `content_for :subtitle` inside that block, too.

Executing that correctly is a bit tricky! The subtitle comes *before*
the actions. So, we `yield` the actions block immediately, save it to a
variable, and *then* get the subtitle block.
2024-06-09 15:03:35 -07:00
b22ccbc2a3 Use Owls to check for Permanent Dyeworks items
Previously, I added a Dyeworks section that was incorrect: the base
item being available in the NC Mall does *not* mean you can necessarily
dye it with a potion!

In this change, we lean on Owls to tell us more about Dyeworks status,
and only group items in this section that Owls has marked as "Permanent
Dyeworks".

We don't have support for limited-time Dyeworks items yet—I've sent out
a message asking the Owls team for more info on what they do for those
items!
2024-06-09 14:46:24 -07:00
5de9e2a27b Add Dyeworks section to Item Getting Guide (but it's currently wrong!)
I started writing this up, then sent a preview to a friend, and he was
like "oh cool, but also this is not correct?"

I didn't realize Dyeworks has limited-time support to be *able* to dye
certain items. Hey, glad we're writing this guide for people like me,
then! lol

I wonder if we can lean on Owls for this. It seems like they already
list "Permanent Dyeworks" for some items, I wonder if they say
something special for active limited-edition Dyeworks items!
2024-06-09 13:25:59 -07:00
857cb547ed Add Item#dyeworks_base_item database field, and populate it
In this change, instead of *always* inferring the Dyeworks base item
from the item name at runtime, we now have a database field that tracks
it, and auto-populates whenever an item *seems* to need a Dyeworks base
item but doesn't have one yet.

This will enable us to set the base item manually in cases where it
can't be inferred, and load Dyeworks base items for the Item Getting
Guide in one query with `includes(:dyeworks_base_item)`.

This migration does a bit more of the fix-em-up scripting work *in* the
migration itself than I usually do, mainly because there's so much in
this one that I think being extra-explicit is useful. We make sure to
do it gracefully though!
2024-06-07 20:10:06 -07:00
68cb44d159 Add logic to infer the base for Dyeworks items
This works for most of the current 1,094 Dyeworks items! But there are
a few exceptions, for cases where the base item name is not quite the
same (e.g. the Dyeworks version is more concise). Maybe we'll add a
database field to override this?

- Dyeworks Baby Blue: Baby Valentine Jumper
- Dyeworks Baby Pink: Baby Valentine Jumper
- Dyeworks Black: Field of Flowers
- Dyeworks Black: Games Master Challenge 2010 Lulu Shirt
- Dyeworks Blue: Field of Flowers
- Dyeworks Blue: Stars and Glitter Facepaint
- Dyeworks Brown: Hanging Winter Candles Garland
- Dyeworks Green: Stars and Glitter Facepaint
- Dyeworks Magenta: Lovely Berry Blush
- Dyeworks Orange & Pink: Winter Lights Effects
- Dyeworks Orange: Games Master Challenge 2010 Lulu Shirt
- Dyeworks Peach: Lovely Berry Blush
- Dyeworks Purple: Baby Valentine Jumper
- Dyeworks Purple: Games Master Challenge 2010 Lulu Shirt
- Dyeworks Purple: Hanging Winter Candles Garland
- Dyeworks Purple: Stars and Glitter Facepaint
- Dyeworks Red & Green: Winter Lights Effects
- Dyeworks Silver: Hanging Winter Candles Garland
- Dyeworks Soft Pink: Lovely Berry Blush
- Dyeworks Yellow & Magenta: Winter Lights Effects
- Dyeworks Yellow: Field of Flowers
2024-06-07 19:35:43 -07:00
341869fb17 Oops, say "these items" plural for basic colors in Item Getting Guide
We could do a whole thing about like, checking singular vs plural, but
I'd rather just keep it simpler; I think it's clear from context that
we're talking about a category, so plural is fine even if it's not
actually more than one.
2024-06-05 19:51:11 -07:00
31c281390d Add explanations for why Item#pb_{species,color} would return nil 2024-06-05 19:46:12 -07:00
a3bd841bb8 Fix handling of basic PB items in Item Getting Guide
Okay so, like 30 minutes ago I added fallback behavior for cases where
we can't correctly infer the color from a PB item's name… and then I
pulled it up in the color and found that, oh, right, there are already
3 PB items that *correctly* return `nil` for `Item#pb_color`: Aisha
Collar, Elephante Hat, and Ixi Collar.

This is because they're common items that apply to many colors, like
the basics, but also many other less-special or older color variants.
They are the most likely case where we'll return `nil`.

So, I've updated our fallback UI to, instead of talk vaguely about
missing data, just assume that we're dealing with basic items. In the
rare window of time where a new color is released, and we have PB items
for it but no manual color data yet, this can just incorrectly say
"Basic Colors" and that's fine.
2024-06-05 19:45:39 -07:00
bd6b6450d9 Handle newly-released species in Item Getting Guide
This is less likely than the newly-released color case for PB items,
but I figure let's be resilient anyway, especially since it's so easy
to—and also I figure this is less likely to be triggered by an *actual*
new species, and more likely to be triggered by a surprise in an item's
naming conventions.

But yeah, if `Item#pb_species` returns `nil` upstream, it'll be passed
to `Color#example_pet_type`, which will crash trying to read its ID. So
in this change, we update `Color#example_pet_type` to accept a `nil`
value, and fall back to the first Species (Acara) in that case.

This means that, if you e.g. take the Mutant Aisha Collar and delete
the word "Aisha" from the name, then load it in the Item Getting Guide,
you'll see a thumbnail of a Mutant Acara. Good enough!
2024-06-05 19:27:38 -07:00
3dab235335 Handle newly-released PB items in Item Getting Guide
Oh right, it's possible for `Item#pb?` to return true, but
`Item#pb_color` to return `nil`, if the item has the paintbrush item
description but we can't find a color whose name matches the item name.
This would be expected if a new color were added to Neopets, and PB
items for it were modeled by the community, but we hadn't manually
added the color to the database yet.

Previously, the Item Getting Guide would crash in this scenario. Now,
it correctly handles the possibility of a `nil` value for `pb_color`,
and shows some placeholder info.

To test this, I temporarily edited some item names to not contain the
color name anymore (e.g. "P-rate Elephante Shirt and Vest"), then
loaded the guide and made changes until it no longer crashed.
2024-06-05 19:23:57 -07:00
e1c598e591 Remove unused sqlite3 gem
Oh huh, I guess we used to use this for automated testing, but since
then I've moved the test database to just be in MySQL like everything
else, so I think we don't need this adapter anymore! Goodbye!
2024-06-04 12:23:39 -07:00
3fa724bbc4 Upgrade to Rails 7.1.3.4
Motivated by a security patch, I don't think we're affected by it but
whatever, it's a convenient time to get it done!
2024-06-04 11:32:51 -07:00
193b1fa5e3 Improve performance for occupies:X searches
I noticed in the app that these queries were slowwww! I was able to
track it down to a bad query plan, as we explain in the comment.

I searched online for "mysql query performance filter on one join table
sort by another", and was surprised to find this answer suggest a
subquery, which I've often been told to expect to be slower compared to
joins? But it certainly worked in this case!

https://stackoverflow.com/questions/35679693/mysql-optimize-join-with-filter-and-order-on-different-tables
2024-06-03 11:45:51 -07:00
aa3dc9549f Add index to items.name database field
I am. Kinda surprised we didn't have this already, huh?? I guess in
most searches, the difference isn't very noticeable, because we don't
have a lot of item names to sort anyway? But we do this *so often* that
I think an index will certainly help! Let's add it!
2024-06-03 11:44:06 -07:00
63abfa51f7 Redesign "Get these items!" button to use a cart icon instead
This helps it fit in the kinda crunchy horizontal space a lot better!
2024-05-31 17:38:25 -07:00
d3d0cda81f Oops, fix symlink for /public-data/latest.sql.gz
Oh whoops, I was symlinking to the *full* path of the latest dump,
which includes the site version directory in it. This meant that, if 5
new versions of the app were deployed since the most recently public
data commit (and so that version is deleted), the symlink fails.

In this change, we just symlink to the filename, which behaves as a
relative path and should be completely resilient to deploys changing
where these files ostensibly live!!
2024-05-29 19:01:23 -07:00
1e99376449 Remove hundreds of unnecessary queries from /alt-styles page!
I think the Rails query cache handled these anyway? But `SwfAsset` has
a `before_save` hook that checks its zone's info, and
`SwfAsset.preload_manifests` saves all the assets, on the assumption
that saving is a no-op when the record didn't change anyway. And it
basically is!

But I figure that, now that I'm realizing hooks exist, simply not
attempting to save unchanged records is probably a better
representation of what we intend to do. So I'm fixing it like that!

Another potential fix would be to preload the zones for these assets,
but I think that confuses the intent too much; the method itself isn't
using the zones, it's just a weird incidental thing that a save hook
happens to use. (Would probably be better to refactor this old save
hook into a different situation altogether, but that's for another
time!)
2024-05-29 18:52:36 -07:00
244bb7627a Remove outdated info from Alt Styles page
Apparently I correctly updated the first paragraph, but not the third
one, oops lol!
2024-05-29 18:47:06 -07:00