If it wasn't working correctly, could you please remind me what the problem was? I thought the bug report on ornament garlands was the only one we didn't fix last year.

(Also, thanks for the note about the CW link- I fixed it!)

At the moment, we have support for day mode and night mode. It is too early to give any guarantees, but we would very much like to provide color customization options and site themes! So, too early for promises or concrete plans, but we definitely intend to try for this down the line.

Ooh I gotchu. Yes, staff are in support of the suggestion! Better gift blocking options would be great. We haven't posted on the topic because we... just have not had the bandwidth to really look at the suggestions forums for a while. (2020 has really ...been a year.)

By Luminaire this year - unfortunately, no, not with 1.5 hours to go. It might be something we can do during the holiday, but no promises. The thing with gift blocking is that it would be faster to implement if it were more straightforward. As it is, there's like 4 different ways to gift people and if we have options to block non-friends, block anon, block all, etc - to all of those gift options - it just gets complicated real fast. At the same time, I see not everyone would like these to be consolidated, so it's likely this is something that would take more user and staff discussion (which means more time, alas) to figure out exactly how it would work.

Yes, that's still on our radar, but we're not certain yet what we want to do about it. Something we've been discussing in the backend is the suggestion to retire it: Retire "Richest User"?

Good points were brought up both for and against retirement on that topic, and people seem to split in opinion, though the bulk of the discussion happened 3 years ago so I'm not sure if any opinions have changed. However, we came across a new consideration we have to factor in, which is how much strain this ranking calculation can put on the website.

At one point in the past few years, we actually temporarily disabled the richest user ranking because we were trying to pinpoint site lag bottlenecks, and it turns out that was a huge one. Every time you visited the ranking page, it would have to do this MASSIVE computation, where it adds together the sP on hand, sP in vault, and shop till sP (so it has to look in the database to see what shops you have, and get the till amount for each one) - for every account on the website (there are hundreds of thousands of accounts, literally) - and then sort all the numbers, then count how many are richer than you - and this was happening any time anybody visited their Dashboard.

I can't remember how we changed it; I think we just made it compare vault sP only, hoping that would be good enough (and I think this was meant to be temporary), but this results in inaccurate counts since people mostly don't store all their sP in their vault.

So it just may not be feasible to fix the calculation, and even if we can fix it, it might not be worth the server resources it would strain, just for a single achievement. It is a tough call to make, and there's no final decision just yet - which is why we haven't said anything - but yeah, retiring it might be on the table.

The backups are not live databases, they are database dumps (so just massive files, but not in a form that's easily queried.) To actually query a database backup, we have to actually start a new database server, load the dump into it (which usually takes several hours, since the dumps are quite large), and we pay for that server as long as it's running. Running a backup is very expensive and time-consuming, so we don't use the backups unless we really need to.

The computation already excludes frozen and inactive users, but this doesn't help the efficiency that much. The main bottleneck is just the multiple queries required to check for all the different places you can have sP. That's also why we can't easily exclude people below a certain amount of sP, because to figure out who has less than X amount of sP, we have to still calculate how much sP they have.

The problem with coding a "total sP" is that it violates the rule of "single source of truth" which will definitely cause inaccuracies - if we ever update your sP amount but forget to update the total sP along with it, then suddenly they are out of sync and that causes the computation to be incorrect for everyone. This will happen more often than you might think, even if our code is correct, because random flukes can cause queries to break before executing all of them, etc...

I think that only doing the computation once a month is a fine suggestion, but I'm not sure how everyone would feel about an achievement that you can only get if you manage to rank number 1 at a specific day of the month, and if you miss that chance, you don't get another chance until the next month. And knowing that the ranking on your dashboard is only where you ranked last month. You wouldn't get the satisfaction of seeing your rank go up as you get more sP. So I think this solution would just feel bad for a lot of people.

But ultimately the call we may have to make is that, no matter what hacky solutions/workarounds we come up with to make it still work, it's looking to be more effort/resources than we should spend on a single achievement, especially one that most users don't expect to achieve.

Lol you think we have documentation :'(

Oh I think I see what you mean about the old API subdomain. It's been taken care of now.

[edit] If you notice anything like that again in the future, please file a ticket to let us know!