Thank you for the feedback everyone! I've pushed out some more changes today:

Cache Improvements

The cache has been working really well - and the amount of information it takes in about items is easy to build on, and add things like what you're mentioning (items being available outside of user shops in bulk, or for cheap in shops where you can buy from a NPC)

Quest Request Improvements

More flexible item selection for quest item pools giving me the ability to increase total size of the pools, but still limit the number of items asked for. There are now three modes:

• legacy mode: Continues current behavior where each rule selects its amount independently (and can ask for a lot of items). this is the default for existing quests
• AND mode: Runs all rules, mixes items together, then selects a specific number randomly for more varied requests. sagg has been updated to this in testing! this is how most of the legacy / main site quests work.
• OR Mode: Randomly selects rules first, then takes one item from each. e.g. we have a quest giver who asks for a weapon and a purple item, we want to make sure it's always a weapon and purple item, not a weapon+weapon or purple+purple. most existing kumos quests will switch to this mode.
• admins can now set a total item limit across all rules to prevent overwhelming requests

Sagg is the guinea pig

Saggitarius gets to be the test subject for the above changes! He now has a much larger pool, asking for a broader range of items and not just jewelry. His pool went from 687 items to 6,236 items 🤯.

Let me know how these quests feel compared to before, hopefully you should get asked for a lot less of the same item.

The changes in this thread are from changes pushed to production yesterday - so wouldn't have any impact on quests prior to that. The changes yesterday (and a few up) and broad attempts to address feedback. Hopefully the Saggi changes feel good, and I can continue to make improvements to the rest of the quest givers. Sorry that you have been suffering a bad experience!

Another piece of interesting data ( sorry I didn't tag before!)

These are the current item pool sizes, as you can see Saggitarius now has a very healthy set of items to draw from now, and the Wizard only has 117 items 😬 That'll be the next one I try to get bumped up!

Pushing up a fix for that, and some wonky button alignment in the quest bar!

The point of the quests isn't to be able to get every item from the main shops.

Maleria's quests not working

"Unable to start quest: Could not find enough available items that meet the quest requirements. This usually means there are not enough items available in shops or the required items are too rare. Please try again later when more items become available."

Hey folks - I've got some changes coming to quests that I've been working on based on your feedback, I really appreciate it! Just wanted to acknowledge that I see it :)

I've just given myself some additional tools on the backend, but also wanted to make sure to get some things out. After running 25 quests and using the price of the item in user shops, this is what came back.

Every quest is profitiable, with an average of 100,000sP over those 25 quests. This includes the same pool of items you're being requested from. How does this feel?

- 100k profit is not the same as 100k payout. The quest system aims for items that cost roughly X and pays out X + profit margin. So if items cost 500k total and the quest pays 600k, that's 100k profit. The actual payout scales with what's being requested.

If that still isn't enough for a single quest, I'm not sure we're going to end up in alignment. I'm in charge of building a game, and part of that is making sure that the economy, to some degree, works. Creating tens of millions of sP, per user, per day, for doing quests is just not something that we can continue doing. Check out the number of threads and posts asking me to also address the price of Cash Shop Credits or Custom Wearables - the reason those items shoot up by millions per month is because we're printing sP elsewhere. The other solution is to make sure that everything we release going forward is only available via some kind of gated new currency that you can only earn doing specific activities. sP is almost impossible for us to consider for new releases now.

How should I price a new R99 item in shops? Should I price it for the new user who has, on average, 3,000,000sP after their first week? Or for the average user of 10 years, who has hundreds of millions of sP? Or should we just keep pricing things at 5,000sP in main shops even though that's a drop in the bucket for almost every category of user except someone who literally just signed up? I am honestly asking here, because it feels like folks would like for me to give out tens of millions of sP and keep everything cheap and make the price of credits come down. I don't think those things are compatible.

The "same items being requested" issue is something I'm actively working on - there are supposed to be systems preventing that, but clearly they're not working as intended yet. That's exactly the kind of thing beta testing is for.

Regarding the comparison to legacy Subeta quests: yes, they've worked for years, but they're also built on a completely different codebase that I can't just copy-paste over. Kumos quests are being rebuilt from scratch, which means I'm essentially reverse-engineering the "feel" of those quests while building new infrastructure. It's going to take some iterations to get right.

I hear the concern about profitability. The goal isn't to make any quest a loss - it's to make quests a reasonable, sustainable income source rather than a money printer. I'm still tuning the numbers based on actual data from you all testing it. Keep in mind that I can see the data from the quests you're completing.

(And yes, I see the irony in asking people to test something that might lose them money. If you're not comfortable with that risk during beta, that's completely valid - sit this one out.)

Got some fixes in place for Sagg!

And some technical insights into what went wrong here: I recently upgraded the Kumos quests to be able to generate their own pools of items from a set of keywords, and find "nearby" items (e.g. items in the same shop, items that share a tag, or items that might be similarly priced). This has been the culminiation of weeks of work of making our items more understandable to the backend, and being able to pull up specific information much easier on them. This is how all of the new wishlist functionality on the trees works, and the Mysterious Melody updates that I pushed out yesterday. We have tens of thousands of items on the site that quests can ask for, and whittling that down into pools that themeitcally make sense (sorry -- I am not interested in every quest being the same, even if you complete them in 30 seconds each and don't read the page!)

The end result was that it narrowed in to a very specific set of "nearby items" when the original pool went above the prices that it should, and instead of falling back (like the legacy site does) on either a random item or just not asking, it kept asking for the same items.

That shouldn't happen again going forward, and I'm going to monitor before migrating any of the other quests over to upgraded pool mechanism.

Okay, I am finding a way that works for me to (fingers crossed) communicate much more smoothly in a more... change-log esque way. There is a new forum for quest specific bugs, and feedback!

TLDR: What I've been doing for the last few weeks is updating a file, CHANGELOG.md alongside doing actual work in code. If I make a change to a feature, I can really easily just say "updated file at tile with [change]" and have a system automation pretty easily. Then, recently, I hooked that file up to those Kumos changes, and can import them and then write a little bit more in that field. That is what I've been linking to folks in the discord recently (granted - their feedback is what is getting me to make changes, but those changes are resulting in on site communication).

Now: I'm making it so that those changes are attached to features, which are attached to forums. When I make a change, I can automatically make a new thread with the same details as above. I can get the feedback on that change, right there. Hopefully this will make communication on things like this feature much easier 🤗