Thanks for the report. I've not had a problem with it myself, but I'll drop this into the backlog all the same. Unfortunately it's very unlikely to be triaged in for investigation at any point in the near future due to the very limited impact such an issue would have. (Debug is not technically a supported feature)

Hi Dylan,

That's brilliant, thanks for letting me know!

Cheers,

Lee

Thanks for confirming Dylan, I'll log this as an urgent issue to investigate for the next maintenance pass. It might be the case that it could end up being fixed on Apple's side or we might need to see if there's an update for Steamworks on our side.

I don't think we have an Mac in the company anymore so it might be a little while till we can test internally and confirm. I'll try to keep you posted.

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 tested the worker case your opened with on the level which you showed. I couldn't replicate it, though I did find a trap did exist on that tile it seemed you must have already destroyed it? In any case my workers did not ignore the tiles, they would flee from the trap while it was present and this was clearly indicated. This indicates a high liklihood you ran into a bug but I have no idea what it could be without being able to see it first hand. A save file is a must for this kind of issue because that would be able to be inspected more closely to find if there was incorrect data. Whether we could fix from there I have no idea.
• I tested the cultist case (see below) and could not replicate though found another potentially related issue.
• I have responded on your complaint regarding the savegame categories.
• I have responded on your complaint regarding the UI scaling issue.
• I have responded on the reloading a level twice kills the UI.

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).

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.

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 ?!?!?!

So I tested this as part of my response here, I created four test scenarios:

1. Cultists dropped into combat in an empty room
2. Cultists dropped into combat in an archive
3. Cultists, assigned to the archive, dropped into combat in an empty room
4. Cultists, assigned to the archive AND the peaceband, dropped into combat in an empty room

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 

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).

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.

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...

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.

Hi Dylan,

Sorry to hear you're having issues with the game. I've never seen that error before and it looks like it's not part of our codebase that's firing it off... I'd be a bit concerned that it might be something in Unity otherwise it's possibly code used for a third-party plugin. .cpp means C++ while Unity's script 

That something like this would suddenly start falling over suggests there's been a change somewhere along the line. As we've not pushed any updates since August it's certainly not a change we've pushed. I note that Mac OS v12.1 is a recent release (December?) I wonder if your Mac updated to a new version and with this it's broken something fundamental used here?

Are you able to confirm whether there were any software updates on your side when the game broke? Update history on Mac OS?

In the meantime I'm going to mark this down as something for us to look into as soon as I can get some code time resource on WFTO. (It's in maintenance mode right now)

I'm currently on holiday until Wednesday (New Years and all that) so I'll try to look into it a bit further when I'm back at work and ask around. 

A very quick google shows this problem pops up for quite a few games running on different engines and I found some reference that this is a Steamworks issue (Valve's API for Steam). About 2/3 through the loading bar is when WFTO checks for Steam so that seems to possibly add up. A user I saw having this issue with another game simply had to restart their steam client and the issue was resolved. Maybe give that a try and update me. :)

Cheers,

Lee

Gave this a shot but I was able to complete the level as normal. The gate only becomes vulnerable after the objectives are complete. With that said I have one potential theory that I'll look into for the cause of this.