Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

These aren't bugs, they are standard pathing behavior for adjacent robots during combat, which will wait if they're blocked by an adjacent bot that is currently occupying their most advantageous direct path.

You can see the same behavior around doorways or obstacles when fighting enemies at close range, which is why that works as a tactic to begin with.

There will be some occasional alternative behavior coming in Beta 14, but this is all normal.

This isn't a bug, they don't actually get free tracking info when they're attacked, and have to look around. They may or may not find you in time

Yeah his guards will not always leave with him, it can happen under some conditions and is fine. Always been that way.

In the first attached save file, the upper-left thief drone isn't moving to attack, regardless of how long i wait.
This first case resolved after i ordered a drone (i think the one that wasn't moving?) to come back then deployed it again.

In the second attached save file, the bottom thief drone has stolen something, but isn't coming back to me, no matter how long i wait.
This second case resolved when the other drone stole something and returned.

(Sorry, i just realized as i finished writing this report that screenshots might've been useful and would've clarified the situation without the need to load those files.)

In the attached save file (It's the "starting point" for the other two bug reports), if you shoot Zhirov (through the wall) from Cogmind's current location, all three local bots will turn hostile but none will be tracking Cogmind (despite the fact that Cogmind just shot Zhirov). Instead they'll just move randomly independently of each other.
This is true even if the allies i have on the east side of the map are moved to the southern part.

Sometimes Zhirov will instantly run into you, but the bug becomes obvious if you make a restore point at the save file's current position before shooting Zhirov.

In the attached save file, Svarog has not teleported away along with Zhirov and the others, neither before nor after the explosions.
Possibly relevant, Svarog was not within line of sight of Zhirov when Zhirov teleported away/met the conditions to do so.
(Zhirov was on the east side of the map.)

There's a question i never asked because i assumed that your inability to reproduce the bug meant it was more complex than i thought.
However, now that i know that you never actually tried to reproduce the bug in a non-debug environment, and that the bug is otherwise perfectly consistent as far as i can tell, it might actually be relevant.


Apologies if it's a dumb question, but is there actually a check for identified branch exits when entering a map?

To clarify, all my encounters with this bug have led me to the following conclusion on how the exit sprites works :
When you enter an area, the exits are all by default set to "stairs".
The only two things that can change this are :

-Identifying a branch exit. This explains why access(branch) "fixes" the bug; Unlike Signal Interpreters, it always causes an identification even, even when that exit is already identified.

-Launching the game (and other similar "reload" actions). During that process, the game checks if a branch exit is already identified, and if it has, its sprite gets set to the branch exit sprite. This explains why restarting the game fixes the issue.
If some part of the setup or some of your tools like the thing that "teleported" you near the spot in the gif above causes the game to "reload", then this would explain why your attempts at debugging failed.


If what i've described is accurate to how the game handles exit sprites, then that might be where the bug comes from;
When entering an area, you can never have any branch exits identified unless said area is a garrison leading to a branch or a "main map" that you looped back to from a submap.
Even some derelict intel that identifies branch exits can only apply after at least a turn has passed.
And given that you previously wrote the following :

I tried this and you do get instant on-sight identification of previously known exits on seeing them again after looping back to the same map (which is something I was always wondering about before),

Maybe you just... never added a check so that when entering a map, already identified branch exits would be set to the "branch exit" sprite?
That check does exists when loading an area after quitting the game and the such, but maybe it doesn't when entering an area?


Again, apologies if that's a dumb question; I don't want to cause you to waste more of your time with this bug, but i also didn't want to have just never asked that question.

Yep this isn't a bug, it's just their behavior, they need to be properly cleared by a Tunneler for the Complex to consider it an official part of their structure. (Note how Engineers actually special log text for doing that.) It's always been like that for the past 10 years, though wasn't nearly as often noticed before so maybe I'll make an exception now that Subcaves are a thing.

if you mine out the rocks in a room that started filled with rocks before the excavators do it the engineers will fill in the missing rocks with rocks
thats pretty annoying if youre trying to get to the subcaves exit fast

found on the subcaves exit materials prefab via mining with mining laser

Yeah I recall that one, and have noticed it a few other times as well, chalking it up to spotting an exit that was previously known before using the chutes, which is what I thought must be causing the bug, and where all my testing efforts were focused, but I have seen absolutely no evidence of it in the code, regardless of whether it happens in releases xD