Yea, you are going in the right direction. So more or less the weights are kind of like a bias to doing something or picking one thing over another. In the case of "k" : "Float_PreferLowerMovementFactorWeight", Influence Factor Weight for preferring moving less. A positive value would make moving less more desirable. So this is set to a negative value to make the AI move more. You can set it, or any other variable high enough that it will do just that as its main concern for its action. In the case of this one, in beta I've had a lot of trouble with it conflicting with Bulwark, melee, staying in good defensive spots, moving for the sake of it and ending up with worse odds/angels to hit and all the other issues you could think of encountering.
It's likely -0.9 isn't high enough for lightly armed, but fast units. However, when testing this with the normal speed units (4/6 TT speeds like the HBK) setting it even a little higher than what modded global has makes reliable Bulwark and other tactical considerations much harder to clench. I still have a problem with it now moving Bulwarked units for no good reason. But then moving up the Bulwark Threshold also makes that too strong, and in the end everything just ends up at higher values with no real effect as they are all equally boosted higher.
I want to see if kicking it up to -2.0 fixes it in a general sense, even if the scouts start moving to odd places for the sake of moving farther. The other problem is it judges by distance and not by pips earned. Most units get capped at 4 or 5. Something like a LCT or JR7 doesn't need to move the max distance to gain that and if the variable instead was looking for pips earned, it might work better by default. It might not look for pips because that wasn't the original Evasion method. Back in Beta 1, distance moved for to-hit bonuses was far, far harder to rack up in a meaningful amount and sprinting, as a mode, gave 50% dodge chance regardless of distance moved. So it's likely that variable was from before the current evasion mechanics was even a thing.
I just got done with the Acceptable Heat and and moving to "Float_ExistingTargetDamageForOverheatAttack", on a hunch set the Acc.Heat to 2.0 and TgtDmg to 0.01 (basically no dmg) to start that testing. Initial impression is amazing. With this kind of set, 2.0 still makes the AI not want to breach the overheat line and get out of it in the next round. While the basically zero threshold for allowing overheating attacks lets the AI really open up the firepower once the first few hits have been landed on a unit. Right now this would be really exploitable as is, but I have a feeling something like AccHeat around 2.2-2.4 and TgtDmg to about 10-33% would be the settings that would let the AI really open up and not kill itself with self inflicted damage. The AI was still very conservative until some hits landed, and anyone with jumpy snipers could keep the AI stuck in conservative mode. So I will want the lower cap, but also lower the threshold for when the AI can start thinking about ignoring it. However, on my lunar map test bed with FS9, VND, GRF-1N and AWS-8Q, two of the four ended up killing themselves via overheating shots. While one of them was the lastman (and thus set to do desperate moves like that) they never shutdown except by my own FS9's flamers.
One huge problem I noticed the AI has, is that there is no check at all if overheat dmg will cause a location to be destroyed, even the CT. On the up side, 1.1 lets the AI take an unsteady unit and move it ASAP, jumping queue even if it would have been the very last unit to move normally. This is a major improvement and I hope we get better sanity checks like that in the future. HBS AI devs, if your reading this: My next one would be the check for overheating destroying parts as long as the unit isn't LastMan.
