I think I found another bug relating to the TT costs. Occasionally, the TT essence cost the game gives is "NaN" (not a number), and when this happens, it's doesn't seem to be possible to pay for a TT option regardless of the accumulated essence.
Looking at the game's code again, it seems that this bug might be triggered when the harmony value is exactly 50; in this case, hdist == 1, and since i > hdist on the first iteration of the for loop, the code inside the for loop never runs at all, meaning that cost never gets set (and, in turn, that ttcost is computed using an unset variable as an input). A quick fix for this issue would be to set cost to be initialized to a value of either 1 or 0 (so that it contains a valid value that's reasonable for the hdist == 1 case if the for loop never runs).
Also, if my recollection is correct, it looks like you may have taken the division by two and moved it from the hdist variable to the cost variable? If so, it's worth pointing out that this will make the TT essence costs more extreme (some harmony values closer to 50 may require less essence, but harmony values that are far away from 50 could have even more obscene essence requirements for TT). Again, fibonacci numbers grow very, /very/ fast, so even halving the outputted fibonacci number is not going to be nearly as effective at reducing large output values other measures (such as division on the input to the fibonacci function) would be.
Also, (again,) you may find it easier to get reasonable scaling out of something other than the fibonacci sequence. For instance, something like "cost = floor(((hdist + 1) ** 2) / 8)" would give:
* a minimum TT cost of 0 (but only for a harmony value of exactly 50),
* a TT cost of 18 for harmony values of 40 or 60,
* a TT cost of 60 for harmony values of 30 or 70, and
* a TT cost of 338 for harmony values of 0 or 100.
In contrast, the current formula can require more than 37,000 essence for a harmony value that's near 100