Clunky Antistall algorithms in Spring AI

Antistall is problematic. In order to prevent an AIs economy hitting rock bottom through overspending, or wasting resources by not spending enough and maxing out storage, antistallguides an AIs behaviour by saying what it can and can’t afford.

So what was the problem?

In theory the NTai algorithm is a perfect model of spring economics. However spring economics does not follow the intended model, and as such the antistall algorithm works better under OTA than spring, for the same reason people like argh complain springs economics are fundamentally flawed.

As a result the anti stall algorithm anticipates a cost and declares a unit too expensive, but in reality the fixed unit costs that are necessary may not be deductable because all the resources have already been used for construction costs, resulting in free resources. Thus the antistall algorithm is deemed to strict and the user complains, and the AI suffers from the flaw.

What was done about it?

To combat this new tags were introduced, to weight the antistall algorithm to be too strict, or too lenient, in order to find a compromise. But this lead to a no win situation where the optimum tag value lead to ok behaviour at the price of random fluctuations, creating decisions that were both too lenient, and too strict, all in the same game.

To deal with this there, were 2 avenues.

1. Predict the cost, based on the past and extrapolate the future economic conditions based on the current direction,then weighted by the cost of the potential construction project being evaluated.
2. Add other systems to catch the stall event and increase economic competency at a common sense level, that did not work on the basis of anticipating the future costs and filtering items that can’t be afforded.

Since a predictive algorithm would be imperfect and would need to be re-evaluated or suffer from unforeseen circumstances such as a unit thatwas reclaiming suddenly stopping and repairing an existing building turning an income into a cost and throwing off the predictions, I decided to take route 2.

To do route 2 I created b_rule, which fitted in with user demand at the time, which complained NTai had no intelligence like AAI or OTAI, and wouldn’t rebuild energy if its energy was destroyed. It made sense, as it made NTai more adaptive.

However it wasn’t enough so b_rule_extreme and the carry versions where introduced. This keyword acted like b_rule but only did so in extreme situations in order to prevent metal leakage or complete nanostall.

So if energy was below a certain set of parameters it would start building energy, or if energy was abundant but metal was not it would choose metal makers, if both resources where nearing the upper storage limit and had big surplus generation it’d build storage, or factories. And if the economy was stable it would just return. That way you could put in lots and lots of the keyword and it would act as a safety net. So much so interpolation was introduced to insert the keyword between every other keyword in tasklists.

An extra 2 keywords were added, b_rule_extreme_nofact, and b_rule_extreme_carry. The first did not build factories and the latter keeps repeating over and over again untill the economy has left the danger zone and re stabilized (aka when it reaches the point where the rules say it should skip it stops repeating and moves to the next task).

This is also where the build algorithm rule values in toolkit come from, the ones in the big 2 columns of text boxes. The values plug directly into the if statements controlling the b_rule mechanisms.

So what did the other AIs do?

Faced with the same problems the other AIs took various routes. Most AIs did not bother at all to handle the issue or simply didn’t get far enough for it to really matter.

AAI initially took the same route as me and had a simple antistall algorithm to nudge its economy in the right direction. However submarine ran into flaws and issues, and the algorithm despite being very simple, crippled AAI, and so it was commented out.

KAI on the other hand took the predictive route. Despite the large effort put into its economy manager classes, it still suffers from issues of either being too strict or too lenient.

Its for these reasons that I personally reccomend that users do not turn on the anti-stall algorithm in their configs. That doesn’t mean that an experienced config builder can’t fiddle around the values to encourage the optimum behavior with it, or that there aren’t alternative tools for preventing nanostall in NTai economics.