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

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

Testing in an actual release build would be the next step to confirm, but that takes even longer and there's also nothing unique about release builds in this regard so is assumed unlikely to turn up anything. To that point, unfortunately by now I've already put waaaaaaaaay too many hours into this for what is a very unimportant issue, so I've decided it will live on forever!

That makes sense. I'm actually a bit surprised that you even tested it this much because i thought you'd already said that you wouldn't investigate further in the past.

Anyhow, even if you won't investigate it further, i'm still going to do so as much as i can!
I remembered that you do upload your streams, which i could check to see if you experienced the bug in them. I think i'd done that in the past, but didn't find any occurence.
However, some of your more recent streams involve Garrisons and branches... Okay this one is from a year ago, but you can clearly see the bug happening on your computer at 2:30:25 :
https://youtu.be/3lea1bK5o-s?t=9025

(You get the branch(access) intel in the previous same-floor Factory map at 46:19)


Unless i'm missing another possibility, i think all this is enough to prove that your debug environment is different from a release build in some way.
So even though i've just said i would still try to investigate it as much as i can, i don't think i can do much more. My investigation ends here as well!

Yep, my first inclination purely from the logic has been Linux-only, but that wouldn't make much sense given its nature. Of course if any other Linux players are happy to try it out from here and confirm that'd be fine, too

There is no "grab the stairs sprite from outside the game." This would be some other sort of game-specific memory state issue.

Testing in an actual release build would be the next step to confirm, but that takes even longer and there's also nothing unique about release builds in this regard so is assumed unlikely to turn up anything. To that point, unfortunately by now I've already put waaaaaaaaay too many hours into this for what is a very unimportant issue, so I've decided it will live on forever! Pretty rare that that happens, but it's both rare and inconsequential so that's okay. I'm pretty curious about this one, to be sure, but not curious enough to continue derailing development for it

Yeah it's not a bug, just a built-in limitation of the faction system. You can actually create similar situations with Golems elsewhere, not just there. They don't have their own faction and when spawned hostile will actually share a certain faction that might be used for non-0b10 unaffiliated hostiles in other cases. This is just how it's built and is not currently planned to be expanded since the assembled don't have or generally need their own faction. Golems hostile to you will technically be friendly with some other interesting parties in the caves!