Print

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

[R-26 Lightspeed]

See attached screenshot.
The door had just opened, and the next time it was my turn after that one the operator was listed and i could give them orders again.

I'm sorry i can't provide more info, i only thought about making a save file copy after my very next movement, and i don't know what, if anything, i could've done.

[Kyzrati]

I'm guessing a save will probably not have helped in this case anyway (not for this type of UI state), so that's no big deal. Good to see a screenshot, though I can't think of specifically how to cause this. Would need steps to repeat, which could potentially be quite difficult

Haven't seen or noticed this before, and it's been so long without any changes to that architecture, so who knows if we'll ever know why! The allies list isn't always maintained, only getting updates before each of your actions (if it's visible), or when it's toggled on, or when an ally is destroyed.

I can't come up with a sequence of events that can get around that, maybe someone else has ideas...

[R-26 Lightspeed]

I can't come up with a sequence of events that can get around that,

Well, here's my guesses :
-My turn and a different unit's turn occurred at the same "instant".
-Maybe (you made changes to) the door's architecture (that) can cause their opening's effect on your vision to only be registered after the allies list update?

[Kyzrati]

First one would be impossible since Cogmind logic is purely linear, and turns are sequential--there's no such thing as simultaneous turns.

Nothing was changed around doors or FOV, either (that's all old stuff). I doubt this is some new issue, just an old and incredibly rare one.

[R-26 Lightspeed]

First one would be impossible since Cogmind logic is purely linear, and turns are sequential--there's no such thing as simultaneous turns.

I thought that was how it worked, i meant same "instant" as in a player's turn beginning (or ending) at time index, say, '100.020' when another unit's turn begins at time index '100.020'. I mean i guess it's probably not the cause for this bug, but... you know, programming.

[Kyzrati]

Turns are just a queue, so no that wouldn't matter. There are no time indices at all, and again everything's linear so it's easy to follow the logic of what happens and in what order. Clearly something else must be able to happen in there outside the normal environment update system, but it's never been noted before in all these years, so can't really say much more on it.

[Valguris]

Perhaps another bot opening the door had something to do with this?
E.g., At the start of a global turn (turn #15311 in the picture) the door is closed. Then, e.g., 10 TUs after the turn starts, another bot (Recycler or Sentry in this case) opens the door, so that the Operator is now in view, but is not registered as such, because it wasn't his action nor Cogmind's that did it. After that, e.g., 50 TUs after the turn starts, Cogmind gets to act.

I reported on Discord a problem with Transmission Jammer not working on an enemy that just opened a door (but did not enter the door tile) in one case. Maybe these two bugs are related.

[Kyzrati]

Will explore further.

[Kyzrati]

So on further examination, indeed I think this particular issue is quite likely related to the jammer situation you reported earlier. Good point, Valguris.

Also on further examination, I'm pretty sure this is not technically a bug, but a somewhat rare side effect of how the FOV system is designed to work, and it's likely going to stay this way. The primary reason being that the FOV update system apparently takes some shortcuts to avoid being an overly significant burden on the CPU. So unless at some point it's found to have more serious downsides, the occasional oddity these this will have to be acceptable. It certainly doesn't really come into play very often, but it's nice to now know that's where it's coming from...

Edit: Also I guess I should clarify that yeah these things would appear to be bugs from the player POV, even if the system was designed this way

[R-26 Lightspeed]

but a somewhat rare side effect of how the FOV system is designed to work,

If it's a rare thing then i guess i got lucky : i've had it happen again twice(or maybe thrice?) in the same new run. This did allow me to test and see that it is possible to update the ally list and have it work again. I also learned that the "opposite" effect is also possible : a door closed and i retained the ability to order the operator behind it.
Also, in both cases, it seems that clicking "all" instead of a specific ally actually works correctly too.

[Kyzrati]

Right, the reverse should theoretically occur as well. Also, to be honest it might actually be associated with your FPS

Out of curiosity, do you know the FPS you normally play at?

[R-26 Lightspeed]

Out of curiosity, do you know the FPS you normally play at?

No, i tried enabling the option on steam to show it in-game, but for some reason it didn't work.
Unless you mean my screen's refresh rate? I think it was 59.94 when i had these happen.

[Kyzrati]

Not Steam feature, Cogmind feature. Cogmind is not compatible with Steam's UI (which only supports GPU-based games). Cogmind has settings for displaying your FPS. There are both key commands and system.cfg options.

[R-26 Lightspeed]

It seems to be at ~63 most of the time. By moments it dips to ~59, and i saw it (only once, very briefly) dip to 47.

[R-26 Lightspeed]

Upon further observation, it seems to easily dip to ~30 simply by moving my mouse around (probably due to pathfinding), and even down to as low as ~20 when moving the camera (in an almost fully explored cave, which means less slowdown in smaller levels but more in the main complex's maps). I always knew the camera movement felt subpar, but now i understand why.

[Kyzrati]

Yeah it feels very different if you're actually getting the default cap of 60 all the time, or even better for those who uncap it and get into the hundreds. (I leave mine capped at 60 though, since I don't use the mouse anyway and it's plenty good enough for kb interaction.)

But below 30 you'll definitely notice sluggishness. So seems that my guess was probably right there, that it's your lower FPS which is leading to rare interface glitches...

[R-26 Lightspeed]

I tried moving the cap to 200, and it seems to dip way less easily. Camera movement can still get it low to around ~30 (same map as before), but less easily, and it now feels smoother.
So today i learned that an FPS cap can cause FPS to struggle more often and easily than when the cap is higher. I think i understand why, but it still feels wrong.

[Kyzrati]

Hm, interesting. Really feels different, eh? So apparently your computer is definitely capable of handling higher FPS, in that case... If your cap is 200, what's the actual FPS you get when idling? Still hitting the cap?

[R-26 Lightspeed]

I remembered idling giving me around 160, but my latest test said it hanged around ~90, and went up when moving my mouse or camera around, as far as ~170.

I then did a few more tests and the results are : it hangs around 160-170 and dips when moving the camera/mouse around, though not as far down as below 100, until i click somewhere, press a button, or alt-tab into the game. Afterwards, it behaves as above.

In case it's relevant, i'm playing on Linux through Proton 4-2.9.

[Kyzrati]

Yeah system won't really be as relevant there as hardware (unless on a new Mac, in which case the numerous layers of emulation can really slow it down, hence Luigi's GPU mod). I was just curious what kind of FPS you were getting now compared to before, when it was capped, and how the dipping was behaving for you in each case, so thanks.

My guess is that if you keep it uncapped you will likely not encounter the original issue again.

[Kyzrati]

Got a really good save from N.W.L. for this old issue and was able to track it down. It was an FOV logic timing issue with doors under certain circumstances.