Workers AI/Priorities - Cannot claim ground
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...
Customer support service by UserEcho
It's "funny" to see that this kind of bug (as it is clearly a bug, everyone can see it as I recorded it) will never be fixed.
I guess this game is dead anyway, just look at the news in Steam to see that the only patch is for the Intel bug (but it is a real major one).
Only players who loved DK are still playing this game as there is no alternative...
Can you provide replicable steps for this issue?
In my experience this is a very, very uncommon issue. The video provided does demonstrate a clear bug but I couldn't begin to tell you why until we've seen it ourselves.
Some stuff that would be helpful to know:
If you still have it a save file of the affected game and level would be good as well.
My best guess looking at this is that somehow the tile data has become corrupted for that particular tile and this is causing the workers to not recognise it as claimable, which is why they ignore it. I'd be inclined to believe that it could be something that the map creator inadvertently did somehow, perhaps a script misfired or a combination of how they used the tools resulted in unusually corrupt data.
Edit: Actually looking again I suspect there may be a trap on the enemy tile. This could be why the workers are ignoring the tile as the trap will be generating threat causing them to flee, obviously whatever is there is only triggered if you step on it, perhaps an alchemine, so it causes unusual and undesirable behaviour as the worker is fleeing what is invisible to the player. Did you explore the tile further? Did you try running a possessed unit onto it or rallying your minions onto the tile?
I suspect the other issues on this topic are more generic on the nature of worker behaviour which can at times do things the player does not wish it to do, hence why they are resolved. Fundamentally that's a flaw in the game's design for sure and one that would take a lot of work to address. Where possible the worker AI tries to make sensible decisions and there are tools to override it but they are very broad and not at all as in-depth.
Of course as you rightly identified WFTO does not get many updates now, that's simply a matter of its age and the time our team has available to spend on it. We're a small team and WFTO is a project we released in 2015, it got its last major update in 2018 and honestly that's a pretty long lifespan for a game to receive updates.
Now our team is working on a new project there's precious little time to dedicate to WFTO's maintenance, and only the most disastrous bugs will get immediate attention. While we do want to provide maintenance this must be done on a timescale that does not disrupt our other work significantly. So it is possible other bugs may be addressed in patches but these will be few and far between and not every bug in WFTO will be fixed. That's just the nature of software development and more frankly, the nature of keeping the lights on in the studio.
So, please provide the details you can, I will drop this in our backlog and if we can we will get to it. If you drop a save file in it I might look at it myself as I do play around with WFTO on occasion.
I hope that helps to cast a light on why issues like this go unaddressed but also what you can do to help us if we do get to investigate it further.
It is way too random to reproduce at will.
Let's be honest the whole AI is a joke, you cannot foul anyone.
I still play the game on a regular basis and it is obvious the AI does shit a lot of the time.
Ok, I know it is the hardest part to do but still, when you see how the cultist are fucking bad... You drop them in the middle of a battle, what do they do ? Nothing... Just going back to research... WTF ?!?!?!
You go on something else, yeah I understand that, but, would it be too hard to use fix position for room, spell, creature, etc. ?
Would it be too hard to add the minimize arrow missing from the creatures and sacrifices tab (it is visible on all other tabs... seriously dude...) ?
About the UI size, the option is nice but I guess you never tested it, as there is a HUGE bug on the creature tab... it just makes it not useable (see attached screen).
Even worse, about the UI, when you load a game (while already playing), randomly the UI just drop... I don't even understand how it could happen... Alt F4 mandatory...
This bug can be reproduced at will. I have a saved (custom campaign "Conquest of Aurelis - Level 14" but I guess other levels does the same) doing that each time I load twice in a row...
By the way, why custom campaigns saved are stored in "scenario" ??? Why is there a "custom" (translated from french screen) mode and a "scenerio" one for savegames ?
I know the answer, it is because custom = scenario but you were to lazy to fix that too. Like the loading time when you open custom campaign whereas it is just a listing of file (ok transformed into object, but still, I have 50 campaigns with some having only 1 map... should not take 2 minutes to load that).
So you move on an other project but this one is not even finished but I guess it is too messy to fixe obvious issues that should have been detected just while playing the game but I guess at this time devs no longer play (I don't talk about testing a specific thing) their own game (I have more than 150 hours of play so...).
By the way, Craft The World is from 2014 and it still have patches and official CONTENT... Age of a game is not a valid reason to end support.
Have a good year.
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.