Forums → Games → GC:CS New gem recipes are finished and ready to use!

In kiwi, I offered to test the 128-(7 amps) killgem and a 128-(256 amps) killgem (the latter can be calculated in 30 seconds thanks to precomputed values from the omnia programs!). ieee then offered to make a 512-semi-optimal and 512-1024 spec, bashed together from managem specs, so the gems are not exactly the 'best' 512 spec, and thus not included in the repository.

Left is 512-29 and right is 512-1024

I performed a 9-combine on the 512-29 + amps to make the set cost the same as the 512-1024. In a trap...

The 512-29+9c gem deals 123.6% more damage than the 512-1024 version! Now, what if the gems were in towers?

In a tower, while the difference decreases, the 512-29+9c gem still deals 71.6% more damage!

Now that the math is proven to work with killgems, shard-farming can be modified to use duplicates of the tower gem + any amp gems you have enough mana to spend it on.

I have long felt (and said so early on) that psorek and ieee were approaching it backwards. They made the programs to find the best gem for a given amp, and then to design the amp.

We know that the higher grade and 'c' of the amp, the stronger it is. We know that starting an amp off with anything other than grade 1 gems results in a weaker amp. In all of the pics shown here, the gem with the higher grade amps had a larger boost from those amps. Even after doing the 9c the 1024 killgem amps still boosted the 512s killgem a lot more than the 29+9c amps boosted the 512+29c killgem.

Again, this tells me that things have been done backwards. Their work was not in vain, and I appreciate it. Quite clearly, the idea that the amps are optimally lower grade than the managem or killgem is rather obvious.

It is apparent to me then, that the trick is to pick the upgrade plan you intend to use, and thus the amplifier, and use the gem that is optimally suited for it. For using a 1024c killgem upgrade, then, it appears we need a 16k killgem. I'm not entirely sure what the managem is, for a 1024c amp.

Get ready for a wall of text, I'm in the right mood this evening!

I'm sorry, I cannot really understand what you mean, but I assure you I did extensive math (and psorek checked and validated it) to make sure my program does not "make thing backwards" and instead gives the best possible gems.

EDIT: I understood what Astro meant in the hour it took me to write this, I wrote about it in the last section, jump at the ** for it.

I could outline the math behind amped spec-combine, but it'll take a lot of time (I have half a notebook full of gem math) and would be of little to no help, because, although math is self-documenting, it's not very intuitive (source: my 8 math exams in the last 3 years).

So now I'll try to explain what the omnia programs do, and to try to outline the compromise between reasonable computation time, actual in-game time spent combining and the pre-existing method I built upon.

If you (generic you, not aimed at Astro) find a flaw in how the program reasons I would be happy to hear.

If instead you are like "...but doing this completely different thing would be better because anecdotal evidence" I'll not consider you till you can provide some results your method is actually better than mine and psorek's.

If you call kgomniaquery (over the right tables) this happens in sequence:

1) ./kgomniaquery NS NC

Why you need to tell the program the speccing and combine number?

Ofc using a spec that uses, say, e33 mana would yield a better gem, but would be impossible to perform and useless at e31 mana, so I went with the established practice of a recipe that mixes colors and another that keeps upgrading this gem.

Why you don't need to tell the program the amp speccing number?

Because it's not a degree of freedom, it's like imposing the ratio between yellow and black, you can't know that, the program will find out by itself.

2) The program then fetches the killgem speccing pool up to NS.

In this pool we have all the possible killgems (discarding the useless ones) that can be built with 1,2,3,....,NS-1,NS gems and all their combining history, so that I know how to make them in-game.

3) The program fetches the killgem combining pool of length NC.

In this pool we have all the possible combining killgems recipes (discarding the useless ones) that can be built with NC base killgems and all their combining history, so that I know how to make them in-game.

4) The program fetches the amplifier pool up to NA=max(2*NS, NC).

In this pool we have all the possible amplifiers recipes (discarding the useless ones) that can be built with 1,2,3,....,NA-1,NA gems.

Why NA is so strange?
Because we'll look in the amp pool both for and amp spec and an amp combine.

Note that for an amplifier a speccing recipe and a combining recipe come from the same pool but are NOT the same thing:
a speccing amplifier recipe is built from g1s and will be paired with the specced killgem, while the amp combine is a NC combine performed from already big amplifiers to upgrade them along with the killgem.
The spec and the combine are different in 99% of the cases!

5) The program gives itself a huge amount of gems
(and I mean huge, I used numbers like e25 gems at the beginning)

After receiving this free mana the program is simply told:
you have this number of gems, you know all the recipes I put in your memory before, build me the best killgem you can.

How is this accomplished? This way:

a For every NS gem spec you have
b Pair it with every amp you have of every value in 1,2,...,2*NS
(this 2*NS is to be sure I don't overlook high amps, but the program chooses itself lower ones)
c Compute how many NC combines you can do with the remaining gems
(the bigger the amps, the less combines you can perform and vice versa)
d Use on the killgem and on the amps every respective NC combine the number of times we computed above

This gives us a huge amount of killgem setups that have value e25, the program computes the total kill power of every of those, and chooses the better one.

Then it tell you the values and the 4 recipes:
- killgem speccing of length NS, to be used at the beginning
- amp speccing of the optimal length, to be used at the beginning
- killgem combine of length NC
- killgem combine of length NC

There is no way to do better, this the best setup you can have at a given cost and yes, I tested for different total costs: results are the same from 10k gems to e80 gems, so if you can gather over a million mana that is the best killgem you can make.

Now, if you use longer specces and longer combines the results improves, but they are difficult to perform and compute, it's up to the user what to use.

Now, I understand people don't like learning 8 different recipes, so there are some shortcuts you can take to pay a liiittle efficiency but cut in learning:

* use the same combine for both the gem and the amps:
if you do this the combine used must be the one made for the killgem, NOT the amps

** use the amp combine (that could possibly be also the killgem one) as amp spec:
this is what Astro was talking about with his 16k spec killgem, to do this I should build a program that exchanges steps a and b and build the killgem around the amp.

The problem of this approach is that you are forcing a particular recipe to be both the amp combine and the amp spec, and this is NOT guaranteed to give the best result: I built my programs to find the mathematically best gems, and Astro's approach cannot do that (it will get close, ofc).

Building a program that does things the other way will also have a huge computational problem:

The best killgems I can make are 128spec, the best managems are 600spec,
using the rule of thumb that killamps should be 16 times less costly than the killgem (8 times for managem) we get that for an estimated 8 value amps I could provide the companion killgem,
but I could NOT go higher than 8, so that you will be stuck with 8 value combines till psorek finishes university and builds a better algorithm (probably not).

Even hacking together pieces from managems I could provide only up to the 32 combine:
gemcrafting techniques will roll back to this summer's level with no chance of improvement just to get a little convenience.

So, what (else) can I say?
Our approach is not "backwards", more like "make it computationally feasible and mathematically perfect at the exchange of some convenience"

Did you really read all this? Congratulations, don't forget to to post some thoughts below, I like talking about gemcrafting when I have some free time, but it seems I was some months late to the party, since there are like 10 people that seems to still read this things.

As a last note I wonder how a company like AG can have a forum so ****ty, to compose this huge thing I had to use the editor of another forum then paste the result here.

Happy gemcrafting

12345ieee

At least with version 1.1 we may not have to deal with so many unclear variables (dependent on play-style, acceptance of tedium, macro programming ability, number of weeks willing to be spent on one map using enough cpu power to cure cancer, etc) and can find a best solution to gembuilding. Granted, since a white/or grade 25 is all you'll need for the highest range of xp cap given without huge game changes it'll be a pointless solution, but it will be the best

While I was asleep, ieee told me of a 16k for killgems (computed from approximate killgem tables) that is supposed to be much better than the one pulled from the managem combining tables. At present the best combine for orange (262144) also happens to work best with black and yellow. I hope this new, more optimal 16k combine would be an improvement over the 262k as well as the following combine for killgems:

Equations:
(val = 1) 0 = g1 k
(val = 2) 1 = 0 + 0
(val = 4) 2 = 1 + 1
(val = 8) 3 = 2 + 2
(val = 16) 4 = 3 + 3
(val = 32) 5 = 4 + 4
(val = 64) 6 = 5 + 5
(val = 3) 7 = 1 + 0
(val = 4) 8 = 7 + 0
(val = 5) 9 = 8 + 0
(val = 7) 10 = 9 + 1
(val = 11) 11 = 10 + 2
(val = 19) 12 = 11 + 3
(val = 35) 13 = 12 + 4
(val = 67) 14 = 13 + 5
(val = 131) 15 = 14 + 6
(val = 9) 16 = 10 + 1
(val = 12) 17 = 16 + 7
(val = 17) 18 = 17 + 9
(val = 24) 19 = 18 + 10
(val = 35) 20 = 19 + 11
(val = 54) 21 = 20 + 12
(val = 89) 22 = 21 + 13
(val = 156) 23 = 22 + 14
(val = 287) 24 = 23 + 15
(val = 10) 25 = 10 + 7
(val = 14) 26 = 25 + 8
(val = 19) 27 = 26 + 9
(val = 26) 28 = 27 + 10
(val = 37) 29 = 28 + 11
(val = 56) 30 = 29 + 12
(val = 91) 31 = 30 + 13
(val = 158) 32 = 31 + 14
(val = 6) 33 = 9 + 0
(val = 8) 34 = 33 + 1
(val = 11) 35 = 34 + 7
(val = 15) 36 = 35 + 8
(val = 20) 37 = 36 + 9
(val = 26) 38 = 37 + 33
(val = 36) 39 = 38 + 25
(val = 48) 40 = 39 + 17
(val = 65) 41 = 40 + 18
(val = 91) 42 = 41 + 28
(val = 128) 43 = 42 + 29
(val = 184) 44 = 43 + 30
(val = 275) 45 = 44 + 31
(val = 433) 46 = 45 + 32
(val = 720) 47 = 46 + 24
(val = 12) 48 = 34 + 2
(val = 20) 49 = 48 + 3
(val = 57) 50 = 29 + 49
(val = 92) 51 = 50 + 13
(val = 8) 52 = 9 + 7
(val = 27) 53 = 27 + 52
(val = 38) 54 = 53 + 11
(val = 16) 55 = 17 + 8
(val = 64) 56 = 40 + 55
(val = 90) 57 = 56 + 28
(val = 128) 58 = 57 + 54
(val = 184) 59 = 58 + 30
(val = 276) 60 = 59 + 51
(val = 434) 61 = 60 + 32
(val = 35) 62 = 28 + 16
(val = 47) 63 = 62 + 17
(val = 63) 64 = 63 + 55
(val = 89) 65 = 64 + 28
(val = 127) 66 = 65 + 54
(val = 183) 67 = 66 + 30
(val = 27) 68 = 37 + 10
(val = 92) 69 = 41 + 68
(val = 129) 70 = 69 + 29
(val = 13) 71 = 25 + 7
(val = 18) 72 = 71 + 9
(val = 25) 73 = 72 + 10
(val = 89) 74 = 56 + 73
(val = 23) 75 = 55 + 10
(val = 30) 76 = 75 + 10
(val = 40) 77 = 76 + 25
(val = 55) 78 = 77 + 36
(val = 21) 79 = 55 + 9
(val = 27) 80 = 79 + 33
(val = 38) 81 = 80 + 35
(val = 50) 82 = 81 + 17
(val = 66) 83 = 82 + 55
(val = 93) 84 = 83 + 68
(val = 123) 85 = 84 + 76
(val = 163) 86 = 85 + 77
(val = 218) 87 = 86 + 78
(val = 307) 88 = 87 + 74
(val = 436) 89 = 88 + 70
(val = 619) 90 = 89 + 67
(val = 894) 91 = 90 + 45
(val = 1328) 92 = 91 + 61
(val = 2048) 93 = 92 + 47

Also, that tower spec I volunteered to test may need to be rebuilt due to that compressed parenthesis bug being discovered afterwards.

The one you posted here is the highest exact combine I can do (pulled from table_kgcomb, for who has kept pace with the program's internal format).

Computing of an exact 4096c would require months, so I moved to an approximate combine builder, I got satisfactory results yesterday first, so now I'll give out some stats:

Combine -------------------------------------------------- Growth
2048c exact, posted by borthel: --------------------- 1.438554
16384 appr. (the one borthel was talking about): 1.441460
262144c leech, that you can find in the repo: ----- 1.441735
65536 appr that computed overnight: -------------- 1.443748

So 16k comb is still not on par with the huge leech one, but the 65k starts to get an advantage.

I still need to tweak the program and review the results before I publish them (waiting two days to see how the 65k combine comes out slows quite a lot a development cycle), but there is some hope for the gem addicts.

I did the same thing with managems, too, but the improvement I got from the leech one at 262144 gems is so small that I don't thing it's worth it to learn another huge combine (0.645635 vs 0.645544)

I'm also very sorry about the bugs that plagued the killgem omnia builder, here follows the best appr. tower spec for 64 combine, in case you want to try it out:

https://gist.github.com/12345ieee/7d5436a66b732f246520

Happy gemcrafting
12345ieee