I still haven’t fully recovered from that damned vaccination. I’m not strong enough to do physical work in the forest, and my thinking is fuzzy. However, I’ve never allowed my own stupidity to slow me down in the past, and I’m too old to change.
I think that I should cut back on my expectations for scripting inside reaction texts. The only thing they really need is the ability to direct the flow towards different encounters.
But a new problem has arisen. The calculations of battle casualties must be undertaken at every step of a battle, which means that every option must include a call to some sort of general calculation of changes to the state variables. I could limit this to battle casualties, but I suspect that some of the other encounters might require changes to state variables other than the pValues. Thus, I need a generalized call that specifies the state variables to be changed and the calculation required for their change. This suggests reliance on the calculator scheme I described a few days ago.
Let’s take a stab at the calculation of casualties and how this might affect behavior. I’ve done a lot of combat results calculations over the years, and the most common approach uses the ratio of the strengths of the two opposing forces. But we’re using BNumbers here, so I need another approach. Perhaps something like:
x.Soldiers = BSum(x.Soldiers, -blend(opponent.Soldiers, -0.99, 0.5));
I could replace the final constant, 0.5, with the Leadership value of x:
x.Soldiers = BSum(x.Soldiers, -blend(opponent.Soldiers, -0.99, x.Leadership));
I could place this calculation inside a method called, say, “K”, and then simply call K from a script inside each option. This in turn will require a script-processing method called before any text is displayed. It looks for a script, executes, and strips it from the string that is to be displayed.