Combat issues in new "Steam Latest" (559)

Summary:

I’m really not quite sure how to go about reproducing it as I don’t know what triggers it, but… In a nutshell the units will be in combat, and then instead of targeting and attacking the target I select, some of them walk off and go back to patrolling. It was amusing the first few times, but it quickly becomes sad days when a couple of guys die because the units are completely ignoring combat happening next to them (Always fun until someone gets hurt =P). I’m not even sure it’s tied to the targeting either, because I had a cleric walking around “patrolling” earlier instead of sitting on a defense post that was posted for her group.

Steps to reproduce:

  1. Be in combat?
  2. Uhh, target something?
  3. Watch the good guys die because, well… because.

Expected Results:

The good guys fight the bad guys and win!

Actual Results:

Half of the good guys, being secretly paid off, walk away from the bad guys, and they turn a blind eye to the slaughter of their comrades!

Notes:

It seems to correct itself when I remove “Job” and then give it back. Sometimes if I click enough times on various areas on the ground (with either defense or attack commands), the combat units walking away to go “patrol” perk up and go to battle. It doesn’t seem to be a consistent number, or even the same units that are having issues.

I did get an error that prompted me to come to the thread to post about the issue. But I’m not sure if the error is related to the combat issues, or something else entirely!

Attachments:

BoxOfDoomText.txt (1.4 KB)

Version Number and Mods in use:

Stonehearth 0.16.0 (Release 559) x64 build

No mods!

System Information:

Uhh. It’s been a while.

Intel i7-4770
Windows 7
Nvidia GeForce GTX 760

Good luck!

If anyone has more information about units ignoring combat, please chime in. I don’t have a way to reproduce this error or debug it yet.

I streamed it! - I’m sorry for the heavy breathing. I haven’t messed with the settings on my stream in several months as I haven’t been doing it actively. xD

Here’s the vod of how I broke it!

I borked it.

Vod link is current!

The only reason the extra time in the beginning is included, is because I think that taking them off of their job then reposting it was what broke it? Only common issue.

And here are the error reports that popped up in the middle of it!

BoxOfDoomTextV2.txt (4.6 KB)

1 Like

That is why I save before combat as well. I have had similar issues when I have given the defend command, then attack. Its not always consistent for reproduction. So I am not sure what other action I am taking that may be effecting it. The video really captured it.

1 Like

Try enabling the option to show hearthling pathing. I don’t think the combat units are going to patrol, they should be going for food or sleep.

I had a bunch of my combat units want to slowly walk away after a number of fights. No thought bubble but judging from the time and the path they were taking, they wanted to sleep. Forcing a single target attack had them turn around, but a general “attack ground” or move to location didn’t do it.

I’ll try to reproduce this by making my guys hungry or sleepy. Should do the trick.

Also, @Luneli, those errors were healing related. Just before they came up I could see your Clerics wanting to do their single target heal action. Were you clicking the ground attack option a few times in succession before the error?

What do the units do after combat? eat, sleep, patrol? something else?

Hey Albert, this might help for one of the issues. Hungry hearthlings don’t stick around to fight.

Below we have a hungry Cleric hearthling walking to an attack here flag:

The Cleric stands for a moment to cast his one big heal then walks off:

Note my show pathing line. That goes to my crates of food. It better be some good food because I’m demoting this guy to latrine cleaning for a week for this behavior.

Leaving my game paused had the cleric circle back but he was making a b-line for food.

Seems like a conflict of priorities - eat when hungry or help fight? What to choose? Trying to think of a solution for this, would it make sense to implement a hidden debuff for when a unit is in combat? Checks every minute for aggro to/from them or their party and wears off after 3 minutes? If the buff is up, don’t walk away to eat or sleep.

1 Like

Thanks for all the great info! I’ll take a look when I’m done with my current feature.

1 Like

Nah, I pulled up the people roster. They were “patrolling”. Plus, if they’re going to eat they always wask much much much faster.

These three chuckleheads want to go patrol some farmland: How did it happen? Their single-target mob died and I guess they thought that was enough for the day. pff. Four more Kobolds fellas!

Here’s the patrol paths they want to take:

I need to go build some latrines so these bozo’s have something to clean later…

Edit: After a few seconds of walking to patrol, they turned around to… dance or something. I swear it looked like they wanted to heal kite the other units or they were lining up for a big heal. This spot had a defend standard that I removed but they aren’t acting like it’s removed… this was an odd skirmish.

1 Like

I made a mod with a outhouse in it. working on giving it the fly animation LOL

Great stuff this really helps to understand what is going on.

1 Like

This release is unplayable on my current save, unfortunately. The AI confusion is so debilitating that it becomes a never-ending combat scenario that eventually wears down and kills all of my military units. Feels like hotfix territory to me.

FWIW, while testing, I got this engine error too:

2016-05-25 17:05:30.535518 | server | 1 | lua.code | generating traceback…
2016-05-25 17:05:30.536016 | server | 0 | lua.code | – Script Error (lua) Begin -------------------------------
2016-05-25 17:05:30.536016 | server | 0 | lua.code | (8839 Gem Killian) (stonehearth:combat:heal) bad frame transition to “unit_not_ready” from “running”
2016-05-25 17:05:30.536016 | server | 0 | lua.code | stack traceback:
2016-05-25 17:05:30.536016 | server | 0 | lua.code | [C]: in function ‘fn’
2016-05-25 17:05:30.536016 | server | 0 | lua.code | stonehearth/services/server/threads/thread.lua:322: in function ‘private_msg’
2016-05-25 17:05:30.536016 | server | 0 | lua.code | stonehearth/services/server/threads/thread.lua:515: in function ‘_dispatch_messages’
2016-05-25 17:05:30.536016 | server | 0 | lua.code | stonehearth/services/server/threads/thread.lua:379: in function <stonehearth/services/server/threads/thread.lua:360>
2016-05-25 17:05:30.536016 | server | 0 | lua.code | [C]: in function ‘suspend’
2016-05-25 17:05:30.536016 | server | 0 | lua.code | stonehearth/ai/actions/run_effect_action.lua:66: in function <stonehearth/ai/actions/run_effect_action.lua:38>
2016-05-25 17:05:30.536016 | server | 0 | lua.code | [C]: ?
2016-05-25 17:05:30.536016 | server | 0 | lua.code | [C]: ?
2016-05-25 17:05:30.536016 | server | 0 | lua.code | [C]: in function ‘execute’
2016-05-25 17:05:30.536016 | server | 0 | lua.code | …tonehearth/ai/actions/combat/execute_heal_action.lua:108: in function <…tonehearth/ai/actions/combat/execute_heal_action.lua:68>
2016-05-25 17:05:30.536016 | server | 0 | lua.code | [C]: ?
2016-05-25 17:05:30.536016 | server | 0 | lua.code | …
2016-05-25 17:05:30.536016 | server | 0 | lua.code | [C]: in function ‘run’
2016-05-25 17:05:30.536016 | server | 0 | lua.code | stonehearth/components/ai/ai_component.lua:541: in function <stonehearth/components/ai/ai_component.lua:525>
2016-05-25 17:05:30.536016 | server | 0 | lua.code | [C]: in function ‘xpcall’
2016-05-25 17:05:30.536016 | server | 0 | lua.code | radiant/modules/common.lua:257: in function ‘xpcall’
2016-05-25 17:05:30.536016 | server | 0 | lua.code | stonehearth/components/ai/ai_component.lua:525: in function ‘_thread_main’
2016-05-25 17:05:30.536016 | server | 0 | lua.code | stonehearth/services/server/threads/thread.lua:249: in function <stonehearth/services/server/threads/thread.lua:246>
2016-05-25 17:05:30.536016 | server | 0 | lua.code | [C]: in function ‘xpcall’
2016-05-25 17:05:30.536016 | server | 0 | lua.code | radiant/modules/common.lua:257: in function ‘xpcall’
2016-05-25 17:05:30.536016 | server | 0 | lua.code | stonehearth/services/server/threads/thread.lua:246: in function ‘f’
2016-05-25 17:05:30.536016 | server | 0 | lua.code | radiant/lib/env.lua:15: in function <radiant/lib/env.lua:14>
2016-05-25 17:05:30.536518 | server | 0 | lua.code | – Lua Error End -------------------------------
2016-05-25 17:05:30.536518 | server | 1 | lua.code | generating traceback…

Artifacts:
megashub-A16-R559-1463972848122.zip (8.1 MB)
stonehearth.log (199.3 KB)

I have a similar problem even though its more like the other way around. My warriors just run in on the enemys and die i can click them away as much as i want. they just kill themselves…

An update for the combat bug. The combat units aren’t necessarily running back when hungry, it would appear that the mealtime priority to run back around 2pm takes precedence.

Usually around 2:45pm or so my combat units will ignore the attack target action. They will obey move to location but won’t stick around to attack hostile targets.

I’ve been successful in getting hearthlings to attack if I move them to a location first then set up a defend location banner near where they’ve moved. If I just setup a defend banner far away from their current location, they may go eat or they may move to the defend banner. They need to be physically near the defend banner to attack targets near it.

After they eat though, they’ll march to the defend banner if I leave it up. I don’t wait for that though as the encounter will likely despawn before my guys can kill them all.

I’ve also built latrines for the disobedient one’s to clean. Three in total with the one on the right reserved for the really disobedient ones. It’s a firepit meant only for the truly desperate nightly visits.

1 Like

Yes, I got exceptionally frustrated playing yesterday for this same reason. I had zero control over my troops. In the old days you used to be able to make them break combat by sending them to a point outside of enemy range and they’d go back to patrolling or (more importantly) healing up, but yesterday they were just Rambo-ing all over the place. In some cases they weren’t even fighting the same target clusters. I’d have one footman working with my archer while another footman was off across the map charging into a camp by himself. It was a mess.

1 Like