[script][combat-trainer] Stop training untrainable weapon skills in CT - optional feature

[mdr55]

Extra logic to stop training a weapon that can't be trained, due to:

1. at max mindstate
2. skill is being used against a mob that's not high level enough (overhunting)
3. skill is being used against a mob that's too high level where there are strings of consecutive misses.

It will do so before the action_count threshold (eventually) takes effect; target_increment is not applicable here.

For 1, the logic will simply speed up weapon switch to something else that needs training
For 2 and 3, the logic will blacklist the weapon skill for a given run of CT, and move onto next weapon

The logic is turned on by declaring "combat_trainer_gain_check: <value>" in char-setup
initial setting of 5 is suggested pending further experience. Enabling gain_check will allow some finetuning of existing action_count threshold to reduce unnecessary weapon switch.

If the setting is not included in the yaml, the new logic will not be activated.

[Kiriawen]

What happens if all weapons fail to gain mindstates?

What happens if all weapons are at 34/34?

[mdr55]

What happens if all weapons fail to gain mindstates?

What happens if all weapons are at 34/34?

All weaps already at 34/34 is already accounted for (already observed before this PR and this PR would not change the existing behaviour of using the same weapon when 34 for all weaps was reached).
All weapons fail to gain mindstates -> each weapon will be progressively removed from the list upon failing check so you end up - most likely - dancing. I'll check for unexpected side effects.

update
there's an unexpected outcome if all weapon skills are removed. CT remains practically functional but I'll have to see how I can fix it properly

update2
ok, so if i remove that last one weapon there are some funky stuff happening outside of my scope (who runs CT with an empty weapons list?!), and I don't want to try to resolve that here. I'm just going to leave the last weapon in play regardless of mindstate movement.

[mdr55]

You angle to the side and retract your arm.
A snowbeast pales and shakes under the strain of your attack!
The air cracks as you unleash a palm strike at a snowbeast!

Your palm lands a massive strike (11/23) to a snowbeast's head!
A snowbeast lets loose a blood-curdling howl and falls into a heap.

[You're adeptly balanced]
Roundtime: 2 sec.

• As if effort and skill were a bad thing, a snowbeast claws at you. You block with a lumium round sipar.
  [You're nimbly balanced and in very strong position.]

[combat-trainer: updated @no_gain_list: {"Small Blunt"=>0, "Brawling"=>6}]
WARNING: Supppressing Brawling due to skill not training
[combat-trainer]>get my throwing.club

• Moving in like a timid schoolboy, a snowbeast claws at you. You block with a lumium round sipar.
  [You're nimbly balanced and in better position.]

You get a steel throwing club from inside your carryall.

Example of feature in action. Brawling had exceeded its gain_check threshold, is suppressed (removed from the training list), and switches to another weapon.

[MahtraDR]

What's this assignment for?

[mdr55]

We've just switched weapons so the old @last_exp is no longer valid. The new weapon's @last_exp = -1 guarantees it will pass the mindstate portion of the check. Its not strictly necessary, worst case is new weapon gets a mark against it, only to be reset to 0 at the cycle after. But its nice to reset properly on weapon change, seeing as line 176 does something similar.

[MahtraDR]

So, you can add an attr reader for it in GameState, then just reference game_state.last_exp here instead

[mdr55]

aaah right, scoping, i'll fix that. it mustn't have been working before?

[mdr55]

Please hold review for a bit. I've discovered an edge case where a weapon can get prematurely blacklisted.
The skill_done? check is executed every main CT cycle, and it is possible for a number of cycles to occur without any combat activity (e.g. aim period). I've just seen this in some other testing I was doing - it may not be very typical in practice but I'd like to cover off this case by tying the check closer to an actual attempt to attack, rather than inferring an attack has occurred because a cycle has.

[mdr55]

Please hold review for a bit. I've discovered an edge case where a weapon can get prematurely blacklisted. The skill_done? check is executed every main CT cycle, and it is possible for a number of cycles to occur without any combat activity (e.g. aim period). I've just seen this in some other testing I was doing - it may not be very typical in practice but I'd like to cover off this case by tying the check closer to an actual attempt to attack, rather than inferring an attack has occurred because a cycle has.

Ok fixed, please continue :) What I was seeing was actually masking an underlying issue with bows... it was more than an edge case. Its fixed now by checking action_count so that the mindstate check only occurs when there has been some action, and not assume a CT cycle = attack action performed. It seems to work well in test.