Base Recipe Prices & Profit Off Singles Instead Of Stacks

This can cause some serious skewing of expected profit/loss, depending on the recipe. Take a look at adaman ingots on Ifrit as a prime example. There's rarely any stacks of them on AH. As a matter of fact, the last stack sold was back in May, for a ridiculously low price of 100k, which makes the average stack price 260K. Since the recipes use Stack Price/12, this means the cost of an ingot using that approach is only 21K. Now, if you look at the AH history for a single ingot, the reality is they sell for 50K each, or more. Every single recipe that uses an adaman ingot based on the stack price/12 is off by 29,000 gil.

This is just a single item, and one example. If there are other items whose stack price is radically different from the singles, and singles are where the overwhelming majority of the supply comes from, it's not difficult to ponder how far off the profit/loss could be on recipes that use two or more of these way-off materials. I think a better approach would be to base recipe prices off singles as opposed to stacks. Granted there could be a large difference in prices for items that are sold mostly in stacks, but those items typically have a much lower price point, and the people buying them aren't shelling out as much gil.

Or, perhaps there could be some code that would set a threshold for stacks vs. singles, and is able to detect when the majority of an item is supplied in one or the other, and adjust recipe price calculation accordingly.

Our system currently uses both. It compares the price of singles versus the price of a stack/12 and uses the minimum of the two for the profit/loss calculations. For site performance reasons, the prices for the comparison are taken from the median sales prices over the past X days, which is why it can appear to sometimes lag behind the most recent prices on each item's individual sales pages.

For every suggestion we get saying we should always use the stack price, comes an equal suggestion that we should use only the single price. At this point we feel our system is the best comprimise between the two, and are unlikely to make any changes to our profit/loss calculation formulas from here on out.

How about an option which parses a script client-side so they can select which to choose then? Would require no overhead on the server to calculate since it would be done client-side. The server would simply pass down both avg. stack price and avg. single price, and allow the user to decide which to use. This will help people get an accurate assessment of prices, instead of the wild inaccuracies that plague many recipes.

Here's a mock-up of the concept:



Keep in mind this is made off the recipe listing. It would probably be better if this type of functionality was linked to the item itself to minimize the amount of clutter on the recipe pages. However, this shows the gross disparity between the actual cost of materials/profit/loss and what FFXIAH currently displays. Allowing the user the flexibility to choose whether or not the recipe should be based off Stack or Single price is huge.

It does add a little complexity, as the user needs to choose between stack/single for each item. Perhaps there could be a default "median" price (C) added. The user chooses whether or not to base the recipe off Stack (A) or Single (B) price, then in the value/profit table, chooses whether to calculate the profit off the selections made in column (A) or the selections made in column(B). Or hell, elminate that altogether, and just have it calculate based on what's selected (should have thought of that when I was mocking this up.)

The calculations would use javascript on the client-side, so no overhead for the server to deal with.

Better mock-up that removes the column (A) & (B) junk. Also added the cost of what the user selected to the results table. This would be awesome...



This really underscores the problem with the current system. Sure, this particular synth is a loss, but the real loss vs. what is currently shown by FFXIAH is pretty dramatic. -36,000 versus -125,000. Pretty significant margin. ^^

A note to Fhqwghads. For the item itself, the Adaman Kris on the right side, for a non-stackable item that would be fine the way it is. For what if the synthed item is stackable? We also have to correctly calculate column "Value" using either stacked or single. Your first image was doing it right, have an (A) and (B) for the Adaman Kris, where (A) would take the value of a single item, and (B) would take the value of a stackable item, and use that to calculate the value of the item.

Of course like I stated before, Adaman Kris isn't stackable, so (B) option should be removed/greyed out for that item.

I added my 2 cents many months ago in a similar thread. I still think the easiest option would be to take the item that sells at a faster rate, whether it's stack or single, and use that as the price values. It would require a little more work server-side though. But all that's happening is the server would count how many items were sold in the past 24 hours, and only do it once every 24 hours, and when viewing an item it would gather the information based on whatever item, single or stack, has the greatest activity, which was calculated already at 12:00AM. ( Or whenever they want to run the cron ) I think it would be the better option. I love your suggestion Fhqwghads, but it may clutter things, and it would require everyone who views the website to learn how this feature works.

The functionality I listed would be applied to the items page, rather than the recipe listing. That way the results would always be appropriate, whether the outcome of the recipe can be stacked or not.

And I thought about the added complexity of it also. I think having a 3rd cost, median, would help people who either don't want, don't need, or don't care about this type of granularity. I tend to think that people who play FFXI are pretty used to complexity though. Look at the lengths we go to in order to do something like skillchains (and that's a mild example hehe.) I don't think many players will have a hard time with this. ^^

i would LOVE to see this if it can be done. ^^