Repeated AI actions

Is there a good way to make a compound action that repeatedly executes a specific action? Or do I have to create an observer to queue up tasks and keep queuing them on notify_completed like the find_target_observer does? As it is, ACE’s training task works, but it takes a fraction of a second to think about what to do after it completes, and in that time the trainee starts to head back to patrolling before committing to a new train action.

There is (or at least at some point was) a loop_action.lua. It was limited and posed issues to optimizations, so I’m pretty sure it wasn’t in use by release time. It might still be there though.

1 Like

Thanks, I’ll check it out.

I glanced at it last night, it looked pretty complicated, so I set it aside for the time being. Just looked at it now, and there actually is an action in the game that uses it, so that’s a handy example: stonehearth:fill_storage_from_backpack (via the :loop(...) function of the compound_action_factory).

1 Like

Pardon for the interruption, but I’ve seen a bug before – never considered it really a “bug” but more like a weird behavior/inconvenience… but reading this now, it just occurred to me that could be related to that.

Sometimes when you have a storage with only a few available slots (or just one), hearthlings will try to put more than one thing in it, dropping the rest on the ground next to it.

I’ve noticed this for the first time long ago, when working on Trapper+. Since my drying racks have only 1 slot, it was very common for hearthlings to try to put several pelts on the same rack, leaving the other ones on the ground whenever they tried.

I wonder if it has any relation to that: ie: filters match and it looks like there is space, they just go and try to put everything inside even though there is only one slot left, so the remaining things get dumped on the ground.

And I also wonder if that is fixable?

Hmm, the stonehearth:drop_carrying_in_storage_adjacent action checks both in :start_thinking(...) and in :run(...) for whether the storage is full, and if so it rejects/returns, and the stonehearth:pickup_item_type_from_backpack action cancels when they’re already carrying something, so loop should cancel and at worst not do anything if that condition occurs. (It’s also used as part of a compound action that previously reserved that storage space in the destination storage, but maybe that part isn’t working properly. Or maybe the :is_full() check isn’t working properly.)

Well, it’s easily reproducible should you feel like trying it out :smiley:

Actually, the reserve_storage_space apparently only gets called for the first item. Then they fill their backpack with other nearby items, for which they don’t reserve space. Dropping stuff on the ground is probably not the end of the fill storage action and instead the beginning of some next action that tells them to drop what they’re carrying before going to do something.

It’s been a while since I looked at that code, but it might be that the space reservations are done when a restock errand is assigned or starts executing. It might be overbooking to avoid extra thinking (same reason all errands are the same size instead of sized to an individual’s backpack).

It seems like the real problem with the training is the 'stonehearth:combat:wait_for_global_attack_cooldown' action. While waiting for the cooldown, during which that action is stuck in a “thinking” state, patrolling takes over. Then the waiting finishes, and the higher priority training action kicks back in with another attack. Since there isn’t a real balance issue requiring the global attack cooldown for training, I’ll just switch out usage of that mechanic with running an effect or something.