Workers AI/Priorities - Cannot claim ground
Hello,
As all similar post are "solved" (big joke when you play the game and see the stupid AI...) so I open a new one with video as a proof of bug.
It's not the first time I encounter this issue, so I am quite bored/angry about that as this game seems almost dead (from the POV of patch).
As you can see on this video it's pretty obvious there is a flaw on AI...
The only solution to make a worker claims the ground is to clear some gold block just next to the ground so that when you finish to gather the gold they start claiming the ground all around.
As already mentioned by other players the priorities of tasks should be rework totally.
How many times I did not see workers just changing job without any reason, except stupid priorities ?
Why a worker that is claiming ground must change its job to digging ? WHY ?????
Same for claiming a whole room, sometime (a lot of time ?) they just leave not claimed tiles, still without any reason...
Thanks.
Hi Codekiller,
Honestly, while I appreciate your candour and frustration at the myriad of issues that can be found throughout WFTO and that I share your frustration that there are lingering problems and that I am of course aware of quite a few of them. But I'm not sure what you're expecting me to say here.
You say that the age of the game is not a valid reason to end support, but support has not ended simply changed its nature to fit the new cadence of our studio's work. WFTO is not an active project, and therefore it does not have code resource assigned to it because that resource is required elsewhere. Therefore what is fixed from issues reported when we can afford to temporarily assign that resource to the project depends more on who and when I can get them.
We're still going to roll out updates when we can. They're just going to be smaller or more focussed depending on who works on the game and when they do as well as what problems are critical or not. You draw parallels to other games but that's a faulty premise in that we cannot pretend to know the nature of the teams behind those, their reasonings for retaining a greater depth of support for a longer period of time or what stresses they are under and the difficulties of rendering that support for that specific game, I can only provide you context to our situation.
For example if work is required on the AI for units there is one of four coders at our studio who is responsible for that, because that is their speciality, while someone else might be able to take a crack at it working with WFTO's AI is complex and somewhat understandably a mess. That person's work is more required on Project: Aftercare right now and thus it's unlikely their resource would be freed up in a timely manner for me to confirm to you "yes this will get fixed".
Obviously it would be impossible to say that in all circumstances the AI works as intended but as someone who DOES still play the game I think it largely works as expected. I've not experienced any significantly obvious AI issues that couldn't be explained if I changed the way I expected the AI to work. When it comes to AI and ESPECIALLY the worker AI expectation is the important factor and I think what's clear is that it was implemented based on the expectation the coder themselves (an avid player of DK) had on unit behaviour, and in some cases it deviates from rules they had in favour of new rules. The problem there is that not everyone shares the same expectation.
I think given the dozens of reports of workers doing something unexpected it's fair to say that in the case of AI one size most definitely does not fit all when it comes to the autonomous unit behaviour. What makes sense for one person might not for another and I believe this is where most of the complaints about creature AI comes from. This is something I think we'd look more closely at if we were building the AI again from scratch.
Now I'm still of a mind to try and help where I can and to do that I need to get as much information as possible, in case that we can come around and fix things. I would seriously appreciate however if issues came in their own tickets because I cannot track them if they're in a monolith ticket like this one.
I'm aware of this issue and I agree it's a pretty awful bug and one that I want fixed should the right expertise be available. This was a bug that was introduced in one of the last patches with the scaling unit portraits. They scale independently based on the number of units you have. However this doesn't play nicely with you scaling the UI.
The programmer responsible for all UI work in WFTO 2.0 was a third-party contractor and no longer works for us, and it's not really his fault that this happened. But I'm a bit hesitant to say we have to expertise in house to fix it. But it's in my mind one of the more serious issues to fix in a maintenance patch.
I'm kind of a mind to actually try and revert the feature or just killed scaling the hud entirely in the meantime. I will look into it.
So I tested this as part of my response here, I created four test scenarios:
In all cases the 4 cultists I had as part of this test group all entered combat as expected, with one exception. I found that in an earlier group one of the cultists had yet to make his lair and sure enough he seemed to ignore combat and leave to make his lair.
So I couldn't replicate the behaviour you specified by layering on more and more "overrides" to the AI but I did find that for whatever reason the lair task is just so overriding they'll ignore combat. I'd agree that's not ideal
For this specific complaint. There are two separate categories because those are the categories of map that someone making a map can choose between. They have different resources available to them and follow different rulesets. If the map maker chooses "custom" it will be saved to "custom" likewise if they choose "scenario" it will be saved to "scenario". Therefore the creator of the map in your case has selected scenario and it is saving to the correct location. That behaviour is as expected, but I admit is perhaps poorly explained?
Essentially if the map was standalone those are the categories it would appear in via the menus when first selecting the map. As it is in a custom campaign however there's space for confusion, because custom campaigns can actually be a sequence of any map type and therefore should probably have their own category. In hindsight that makes sense but it simply wasn't considered at the time.
I actually experienced this for the first time the other day. I've been struggling to replicate it myself however. I will try the map you suggested.
I actually think it's a new issue in 2.0.8 as I hadn't heard of it prior to that release which suggests it came with either Unity or something else. I think perhaps some middleware (perhaps the UI) doesn't finish loading and the game ends up waiting on it, causing a softlock. As for the cause I'm not all too certain right now.
Will investigate further.