H is the final orange/black grade 5 gem with cost of grade 6 and huge specials. You can use this formula only once.
METHOD 2 - SUPERGEM UPGRADING
You can apply it to pure orange, pure black, orange/black and orange/black/red gems.
first, get your gem to upgrade (I'll call it "g"
D is the final supergem with grade +3 and cost x16. You can (even should) repeat this method every time when upgrading gem.
You use method 1 once and then on resulting gem method 2 till your mana ends for mana gem. Just don't forget to add red at some point, best g1 to one of 16 copies of your gem in method 2.
For amplifiers I recommend now pure orange (black isn't amped anymore) so you grab g1 and apply method 2. Amplifiers with this method should be 3 grades lower than mana gem.
[EDIT]
After a moment of thinking I realized that this metod works also for killing gems, but you have to farm kills on black/red gem and add it in some moment. Feel free to try.
@Ahuizotla: can you make your pictures for gem combining methods I'll post? They are really nice and I need such thing for extreme gemcraft guide I'm currently working on
@psorek: Can you post the rough output for the optimal 256 combine? My agglomerative search algorithm couldn't make any substantial improvements over your 64 combine method, though it did help highlight some of the general combining methods that increase efficiency. While my approach helps create an optimal main gem, it doesn't uncover the optimal secondary gems that are merged in with the main gem. Regardless, the optimal methods appear to be based around a very highly efficient gem that everything else is built on: = o2 +o +o +o +o +o2 where o2 = grade 2 orange and o = grade 1 orange. I'm hoping to uncover an efficient upgrading algorithm for 1-step increases (as opposed to 16 or 64-step increases).
Finally, to compare the effectiveness of gems with different costs, I've derived the formula that calculates a simple mana gem's power from its cost: E(Power) = Mana Leech = 3.71 * (1.38)^[log2((cost + 48)/54)] note: mana leech doubles when gem grade is level 7+ (so multiply the formula * 2). Essentially what we are trying to optimize is power efficiency over base gem divided by cost: [ActualPower / E(Power)] / cost
Ah, reinventing indeed.... I'm guessing that you used this as the value function of the dynamic programming problem? Regardless, I think I'm giving up on trying to make improvements. Its tough to compete with dynamic programming. I still suspect that there is something slightly more efficient, but not by much, probably way too complex, and not worth it to find.
16 is fair trade between complexity and efficiency, 64 is nearly optimal but too complex for everyday use for me. Yea, I did use it as one of the value functions, couldn't use it everywhere though.
I found my combinig-method to work very intuitively and, maybe more important, being quite resilient to mistakes. Necessary: Having a second window open with the actual combining scheme. Then:
+ attributing imaginary numbers to the gem slots.
+ for each next step just work with copies of the originals and put it in its new place (example: 15 = 13+3 > duplicate 3 and 13 > put it to place 15)
Second version as I was to slow to edit:
+ it's easy to do a second copy where you can put a high-hitlevel-G2R/B somewhere at the end of the process (useful primarily for the killgem)
(btw, it's not an actual scheme I think, so don't use the pic)
I'm only vaguely familiar with dynamic programming and haven't ever implemented anything with numerical methods (I learned about it with a mathematically tractable problem that can be solved by hand). However, I've been thinking about ways to reformulate the optimization (though this might be exactly what you are already doing). This might be exactly what you are doing, but it seems it would work if you iteratively solved the problem of determining the most efficient gem for a given cost and grade. Start with the lowest cost gem (i.e., a grade 1), then working your way up from there only using the previous solutions to empirically test the next cost. Is this what you are already doing? I'm really curios about the actual implementation - not because I think it can be improved, but rather just curious about the math behind your elegant solution).
@psorek: I'll happily do that For Wednesday-Friday I plan to make one for your 21-step-killing gems. Currently my time for this is really limited, new versions could take up to 10 days (depends on progress with bachelor thesis). Since I'm not able to read all the discussions regularly, please @ -mention me so the forum will send me an email alert (Don't know if there is a private message system, if yes, just use that of course.)
Since reading this thread (but not REALLY understanding the process) I've been doing the following:
1+1+1=2*, dupe twice
2*+2*+2* = 3*, dupe twice
3*+3*+3* = 4* dupe twice
and so on. I will mix in colors and try to evaluate what combinations I need to get the approximate ratio I want (like very little red, roughly equal black and orange for example, maybe 1 or 2 parts red for 8-16 parts black/orange, you know?)
if I understand correctly, at each gem level I should be combining several lower grades as well?
I've been running into a mana pool wall in the mid 40s - I can't seem to get past 45-46 without a ton of effort and restraint. At pool lvl 41ish the mana gain rate vs pool size drastically decreases, compared to the early levels where a few key upgrades of farm gem + amplifiers can see you skyrocket ahead 5-6 pool levels in what seems like a few seconds. Obviously since the pool increase size is greater than linear, and the specials increase for each gem level is less than linear, it will slow down, but I need some help on overcoming this hurdle.
edit - I missed the last page and while I hardly ever drink, tonight I find myself way too inebriated to even consider trying this. Who knows what unholy inefficient monstrosity I would unleash.
I brought this up in another post but thought it was worth bringing up here as well. I'm hoping for a more clear guide since there are lots of missing pieces of information in the steps posted so far in these methods.
The posted variables aren't defined for most all of the steps and various explanations so it would be great if someone posted a clear explanation of what the steps were to do what is being discussed and what exactly the point of any of it actually is in each case. Variables/abbreviations really need to be defined or eliminated thatnks