I was highly unsatisfied with the inefficient means of finding Nectar formulas. I've yet to find anyone who took the formula as found in the reflected DLLs and created a nectar blend generator from that.

So, I did that.

After some testing, I believe what I've produced is a functional base library.

I will, if there is desire, expand it to provide accurate predictors of price based on various factors (eg, Quality of Fruit, skill of user, Challenges completed, etc) via a GUI.

For now, I would like to just contribute the top 20 'Best' blends, and the top 20 most valuable blends. These are different, as the 'best' blends merely have higher multipliers, but the most valuable bends have much higher base values.

Oh, and an interesting note. Pomegranate 1 Lifefruit 9 is, in fact, the most valuable (but maybe not the most efficient in terms of time/cost) blend available.

If there is desire, I will release the application and the source code. It is written in C#, and requires Mono to work accurately. Standard .NET runtime will not work, as it requires the use of the Mono Random function.

Please note that while not all of these blends are "amazing," they should be more price effective than any blend not listed here.

One last note. Any time a bottle is created, there is a fairly large (I believe, I have not confirmed) variance that is possible. Therefore, it is conceivable that one can produce a bottle of nectar that has a base value of less than another, yet with higher resulting value.

The kicker with the Nectar values is that the ORDER the ingredients are inserted into the machine affects the list, since the string has is generated by strcatting the ingredients together in the order they are first encountered on the list, and there does not appear to be any mechanism that sorts the list. Inserting ingredients in a different order will produce a totally different hashstring, and therefore, a totally different outcome.

Grant me the serenity to accept the things I cannot change, the courage to change the things I cannot accept, and the wisdom to hide the bodies of those I had to kill because they pissed me off.

Also in my own tests, I have confirmed that the hash generated by the application does not change. For testing purposes, I created an object which was just a Nectar Maker copy but ran the Hashing/Formula functions (roughly). I did this to confirm

a) That the order does not matter when creating the Hash (it does not, but that's obvious in the code)
b) That the internal Mono engine used in the Sims 3 does not use a different Random class than standard Mono (it does not)
c) That the names of items matched up to what the names of the models they used (they did not, which caused confusion when I first was doing tests).

Oh, and a note. All those generated combos lack the first 3-4 cheapest Nectar items. This is because of a bug with Mono that doesn't allow for huge amounts of data sets to exist on the heap. I either need to recompile Mono with altered settings (bleh) to account for a larger heap space, or I need to optimize my algorithm to reduce memory usage (uncertain how at the moment).

As a result, things like grapes (standard) and Lime are not represented, and may alter the optimal results slightly. It's unlikely that the top value nectars will change, however.

Ah, so they are sorted. Very good, then. Does the intermix ratio matter? I did a quick browse through of it, and it appears that when strcatting the names together, it may be ignoring components of types it has already viewed. One issue with quality prediction, however, is that it is not a reversible process: You can't figure out what the best value is, then reverse the algorithm to determine what the best fruits are, and thus you are essentially still limited to bruteforce scanning.

Grant me the serenity to accept the things I cannot change, the courage to change the things I cannot accept, and the wisdom to hide the bodies of those I had to kill because they pissed me off.

Moved to a perhaps more appropriate place for technical discussion of your program and hashes and whatnot.

Would be darn useful, though IMO it might be more useful simply to edit the nectar making page on the wiki with the best recipes based on the data from your program since it'd be the same for everyone and really, only one person needs to figure out what the recipes are one time.

At first I thought it was ignoring items it found already as well, but what it is actually doing is storing the strings in a Dictionary of string/int where int represents the count of items with that name. That is used later for the purpose of writing out what the blend is (eg, 90% Lifefruit, 10% Pomegranate).

The str itself is expanded for all ten items.

The algorithm _is_ Brute force. I use recursion to build out a data structure that holds all (ordered) combinations.

It ends up consuming 600MB in the standard .NET runtime, but in Mono, when it hits about that 600MB mark, it collapses. I have to reduce the footprint for mono, for now, by dropping the lowest-cost items.

I haven't taken the time to optimize the application (yet).

Although you cannot predict the precise quality of a nectar blend, you can predict its median, max, and min value based on various unique factors (challenges, upgrades, etc).

As a result, you can predict which blends, on average, will have the highest value.

If you don't mind, I'd love to see the source code. Did some playing around with this myself a few months back, but when I realized that taste was entirely dependent on this Rand function that was seeded by the hash from the ingredients, I gave up.

Well, not entirely. I simply duplicated the code for the normal nectar maker but reduced it's production time so I could get nectar in 15 minutes.

Your title indicates a recipe generator. I have been spending an inordinate amount of time trying figure out the formula for creating the multiplier for any blend. I assume you have done this if you have made a generator. Is this something that you are willing to share or sell?
Don