Great, seeing that my final program gives correct results I've decided to release the final version of all the gemforce results, including the one of my final program:
read the release notes and/or the readmes at the various folders to find all the informations you need.
Feel free to comment/ask question on this thread, I'll try to answer when I have time.
For who is still reading, I'd like to say I had a lot of fun with this project and learnt a lot, hope this may be useful also to you guys, I'll now move on to other projects, I'll come back here to check out 1.1 when it will be released.
In the kiwi yesterday, 12345ieee basically hung up his hat. He started University last week, and no longer has the time to devote to this as a project.
He was also fairly distraught when I showed him "real world" example of the weak amp not being successful - I was not able to get as far into an Endurance run using the 64-10 killgem setup as I was with a 32-64 killgem setup (64 spec killgem with 10c amps, all upgraded with 64c, vs 32 spec killgem with 64c amps, all upgraded with 64c). Number of monsters killed was significantly lower with the 64-10 setup than the 32-64 setup.
He did, however, provide Borthel and I executables for his optimized gem creation programs that he developed with psorek. I've got one running right now, for some 14 hours or so at the time I type this, attempting to find the best 512 spec managem using 1024 gems for each of the amps. The way they set it up is you tell the program how many gems you want to limit the main gem to, and then the total number of gems involved, between the main gem and the six amps. After a while (depending on the calculations it needs to make) it will spit out the best it could come up with.
12345ieee was saying something about setting it for whatever with something like 10,000 total gems, and then refining that second number down based on the gem results given, but I didn't really get what he was trying to say. He then said that he was going to leave that as an exercise for us to figure out.
The program assumes the gem is in a trap with six amps, so the following values dictate the gem value at the end of a particular run. For example,
whatever_you_named_your_compiled_exe -pitel 3248
The first number is the upper limit of the value of the trap gem. The second number is the value of all seven gems. Those example values produce a 30-value killgem with 3-value amplifiers (rounded up from 2.67 for each amp). For a 32-spec gem, the run restarts in the following pattern, after 44 gems:
and continues infinitely, for as long as the program is running. For low amp values (close to first value), the infinite pattern-start point is needed to get the first maximum-value trap gem before the start point. Note that the start point moves slower than the growth of the amps, so for e.g. amp-1, or even amp-3 (32 128 and 32 56 respectively, for 32-spec), you can safely optimize for amp +(-3 + n) and higher and always get an exact grade gem.
To get the second number such that n�0, divide or multiply the first number by whatever value gets you the desired ratio for one amplifier. Then, multiply the amp value by 6 to get the total amp cost. Add that value to the first one to get the "correct" second value.
The maf -pitel 512 6656 finished running today. That was the managem program, 512 spec gem, with 1024 gem amps. This is what it told me, for those of you who like parentheticals :
Edit: Numbers mean "combined gems of base gem" so 1 is clear, 2 is updated once, 4 twice, 8 three times and 16 four times.
Reads IMHO better than
(((((((k+k)+(k+k))+((k+k)+(k+k)))+(((k+k)+(k+k))+((k+k)+(k+k))))+((((k+k)+(k+k))+((k+k)+(k+k)))+(((k+k)+(k+k))+((k+k)+(k+(k+(k+(k+k))))))))+(((((k+k)+(k+k))+((k+k)+(k+k)))+(((k+k)+(k+k))+((k+k)+(k+(k+(k+(k+k)))))))+((((k+k)+(k+k))+((k+k)+(k+(k+(k+(k+k))))))+(((k+k)+(k+(k+(k+(k+k)))))+((k+(k+(k+k)))+((k+(k+k))+((k+(k+k))+(k+(k+(k+(k+(k+k))))))))))))+((((((k+k)+(k+k))+((k+k)+(k+k)))+(((k+k)+(k+k))+((k+k)+(k+(k+(k+(k+k)))))))+((((k+k)+(k+k))+((k+k)+(k+(k+(k+(k+k))))))+(((k+k)+(k+(k+(k+(k+k)))))+((k+(k+(k+k)))+((k+(k+(k+k)))+((k+(k+k))+((k+k)+(k+(k+(k+(k+k)))))))))))+(((((k+k)+(k+k))+((k+k)+(k+(k+(k+(k+k))))))+(((k+k)+(k+(k+(k+(k+k)))))+((k+(k+(k+k)))+((k+(k+k))+((k+(k+k))+(k+(k+(k+(k+(k+k))))))))))+((((k+k)+(k+(k+(k+(k+k)))))+((k+(k+(k+(k+k))))+((k+(k+k))+((k+(k+k))+(k+(k+(k+(k+(k+k)))))))))+(((k+(k+(k+k)))+((k+(k+k))+((k+k)+(k+(k+(k+(k+k)))))))+(((k+(k+k))+((k+(k+k))+(k+(k+(k+(k+k))))))+(((k+k)+(k+(k+(k+(k+k)))))+(((k+k)+(k+(k+(k+(k+k)))))+((k+(k+(k+k)))+((k+(k+k))+((k+(k+k))+(k+(k+(k+(k+(k+k))))))))))))))))
I will compare this recipe when I've built my killgem. I plan to compare against straight 'u', 16c, 64c and maybe 1024c.Right now I've just done it once to a pure yellow, so that is not really comparable. But give e a few days, atm I am pre-endurance/permafreezing with 2.7e34 mana and won't just rush...
I'm pretty sure, I won't do a 4096c. I did 2 Iterations with a pure yellow and right now the order is as you predicted. 1024c is missing (but works pretty good as mana-amp!) A simple 8c (2+1+1+1+1+2) is not soooo bad, too, I would remommend it to lazy people
Astro prefers trees, AFAIK... I put the parenthesis formula to an editor with parenthesis-highlighting, such as 'Notepad2' Then I shorten the long line in blocks, first opening parenthesis ends at the end of the complete gem, I look, where the second opening parenthesis is closed, after the closing parenthesis is a '+' sign, after that plus, I make press return for a new line. Now I have two gems, with which I start that procedure again. Then I use the replace-option of the editor: I replace every (g+g) by 2g After that I look for repeating patterns, build subgems (as in my example A, C, D) and use again the replace-option of the editor. Then I replace things like (1+(1+(1+2))) with the equivalent 2+1+1+1 for more clearness... The final combining is strictly from left to right, remaining parenthesis are one gem! hth
