Print

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

[R-26 Lightspeed]

While trying¹ to assimilate a cave Behemoth, i discovered i could just keep "f" pressed to keep trying to hack them.
However, when releasing the key, the game continues to try to hack the Behemoth for a period of time relative to how long i had pressed the key and to my distance to the Behemoth, where pressing the key for longer/being far from the Behemoth made that time period longer.

It's like the game "stores" key inputs until the game requests them.
To be clear, there is a bug caused by Proton (1.6-x to current steam version(?)) which causes games to "stores" key inputs until the game requests them, so this is probably the same thing.

However, i know of one game where using Proton does not cause that bug, so maybe there's something you can do about it?
Actually, there's probably something you can² do about it, since for some reason keeping a key pressed in Cogmind seems to be enough to trigger the bug (it shouldn't be³), which implies that Cogmind receives a continually pressed key as constant key presses instead of, well, a continually pressed key.

Regardless, it's not exactly a big problem, i just thought you might want to be aware of it.

¹It took a while, but i gave up.
²I have no idea what the code looks like, so for all i know it might requires rewriting a lot of code and be completely unrealistic.
³The only way i can sucessfully recreate this bug in other games requires me to remap mouse movement to keys to create a LOT of key events fast.

[Kyzrati]

which implies that Cogmind receives a continually pressed key as constant key presses instead of, well, a continually pressed key.

That is the intended behavior of holding a key. There is no "continually pressed key" state. As per normal Windows OS key behavior, when you hold a key the game is receiving multiple keypresses (at an interval called the key repeat rate), and will continue to process them from the command queue until all of them have been cleared.

Holding keys in a roguelike is usually not a good idea, but you're allowed to do it if you want to reap the consequences

The main key you're intended to hold in some situations if you prefer is the wait key, as described in the list provided in the manual, which will indeed start blocking further wait actions for a bit once the assumed desired goal is achieved. Also keyboard-based movement to repeatedly bump targets in specific instances, also as listed in the manual--see Key Holding under Advanced Commands. Holding a fire key, or really almost any other keys, is not something where the game will protect you from the results of doing so.

(Note the game you link there is a realtime game, all of which treat held keys differently than turn-based games by default due to their nature.)

[R-26 Lightspeed]

There is no "continually pressed key" state.

I know that there isn't, my phrasing was very weird. I meant that Cogmind seems to check whether there's a keypress, as opposed to checking whether the key is pressed.

0=release;
1=press;
2=repeat; (those are the values within key events that accompany each scancode (and other stuff), at least on Linux.)

As i understand it, the basics are :
To check whether there's been a keypress, you check if there's either 1 or 2 next.
To check if a key is being pressed, you check if there's 1 next, then you watch out for 0.

Consider the following two scenarios :
-The way it seems to me Cogmind (through Proton) is going with, is to check whether there's been a keypress like so :
If the next value is 1 or 2, wait until you can use that action, then check the next value, and repeat.

-To check if a key is being pressed for a turn-based game like this one, one way is to watch out for a 1, make one action, then check if the next value for that scancode is 0 or 2. If it's 0, don't repeat action. If it's 2, then repeat action every possible moment and ignore all further 2s until 0 is received.


The difference is that for the first will complete the action tied to the key a number of times equal to the number of 1s and 2s in the queue, which means possibly continuing to act long after the player has released the key, while the second will stop once the player releases the key.

At least i think that's how it works? I'm mostly guessing based on my knowledge about how key/relative events are sent, how some games sometimes behave, and how the Proton bug i mentioned behaves.

which implies that Cogmind receives a continually pressed key as constant key presses instead of, well, a continually pressed key.

That is the intended behavior of holding a key. There is no "continually pressed key" state. As per normal Windows OS key behavior, when you hold a key the game is receiving multiple keypresses (at an interval called the key repeat rate), and will continue to process them from the command queue until all of them have been cleared.

Are you sure it's normal for Windows games (and other softwares too then?) to queue key events like Proton seems to do? Doesn't that have the consequences of, well, this bug exactly?

Holding keys in a roguelike is usually not a good idea, but you're allowed to do it if you want to reap the consequences

The main key you're intended to hold in some situations if you prefer is the wait key, as described in the list provided in the manual, which will indeed start blocking further wait actions for a bit once the assumed desired goal is achieved. Also keyboard-based movement to repeatedly bump targets in specific instances, also as listed in the manual--see Key Holding under Advanced Commands. Holding a fire key, or really almost any other keys, is not something where the game will protect you from the results of doing so.

I'm not sure why you're telling me this? You seem to be talking about the consequences of something suddenly changing while the player is holding a key, while i'm talking about how a key "stays pressed" long (as long as a few seconds) after i've stopped pressing the key on my keyboard, which is very different.

(Note the game you link there is a realtime game, all of which treat held keys differently than turn-based games by default due to their nature.)

I reproduced this bug successfully on two other real-time games, both of which are more fast-paced that that one.

[Kyzrati]

I meant that Cogmind seems to check whether there's a keypress, as opposed to checking whether the key is pressed.

Yep, that's exactly what it does. Pressing a key (or a combination of keys) is an action/command, and commands are queued to be processed one by one. Again this isn't a bug, it's just a common way to handle input.

which implies that Cogmind receives a continually pressed key as constant key presses instead of, well, a continually pressed key.

That is the intended behavior of holding a key. There is no "continually pressed key" state. As per normal Windows OS key behavior, when you hold a key the game is receiving multiple keypresses (at an interval called the key repeat rate), and will continue to process them from the command queue until all of them have been cleared.

Are you sure it's normal for Windows games (and other softwares too then?) to queue key events like Proton seems to do? Doesn't that have the consequences of, well, this bug exactly?

If you hold a key it will keep sending that keypress into the queue, even if it can't be processed immediately, and the game will eventually get to them all (which won't be immediately, of course, because it may take some time to process each one, hence the continued processing even after you release a key--the commands you entered are still there, being processed one by one!).

Have you ever held a key while typing in a word processing program, or writing an email or forum post? It's like that, only putting a character on the screen is fast so it'll basically stop when you stop, but it's a visual way to see an example of a key repeat rate (which doesn't usually start immediately, but some time after the first down press). And if you happen to have something which is slowing your word processor or computer down for some reason, even after you release the key it will still type a bunch of extra characters to clear the queue.

Holding keys in a roguelike is usually not a good idea, but you're allowed to do it if you want to reap the consequences

The main key you're intended to hold in some situations if you prefer is the wait key, as described in the list provided in the manual, which will indeed start blocking further wait actions for a bit once the assumed desired goal is achieved. Also keyboard-based movement to repeatedly bump targets in specific instances, also as listed in the manual--see Key Holding under Advanced Commands. Holding a fire key, or really almost any other keys, is not something where the game will protect you from the results of doing so.

I'm not sure why you're telling me this? You seem to be talking about the consequences of something suddenly changing while the player is holding a key, while i'm talking about how a key "stays pressed" long (as long as a few seconds) after i've stopped pressing the key on my keyboard, which is very different.

Right that was just an addendum about key holding in general in roguelikes, and how certain actions in Cogmind where you might do so are explicitly blocking the command for a period of time, even though technically those commands are still coming in because you were holding the key, so it could apply here if you have a slow computer, for example.

I reproduced this bug successfully on two other real-time games, both of which are more fast-paced that that one.

Sounds like those games have their own issues then! It's normal for many turn-based games to accept a held key as multiple keypresses, but not so common among realtime games like FPSes because there's a lot of key holding and a need for instant reaction times, so input processing works differently in those cases.

[R-26 Lightspeed]

Yep, that's exactly what it does. Pressing a key (or a combination of keys) is an action/command, and commands are queued to be processed one by one. Again this isn't a bug, it's just a common way to handle input.

While that's true, Proton is creating an additional difference, one which might be considered a bug. (Although if you can reproduce the exact same bug on your side (Windows), it might just be "normal" behaviour that wouldn't normally happen on Linux.)

Sounds like those games have their own issues then! It's normal for many turn-based games to accept a held key as multiple keypresses, but not so common among realtime games like FPSes because there's a lot of key holding and a need for instant reaction times, so input processing works differently in those cases.

It's not a bug with those games, it's a Proton bug. It doesn't happen with, say, Proton 4.x-x. (Which could actually just mean that later Proton versions recreated a Windows bug.)
It's also not usually as easy to trigger on those games as it is for Cogmind, since for those games it requires me to remap mouse movement to key events to be able to create enough events to cause the bug, while for Cogmind i just needed to keep one key pressed.

After testing the exact same situation (trying to assimilate a Behemoth while keeping "f" pressed) with Proton 4.2-9, the bug does not occur.
On 4.2-9, when i release the "f" key, the game instantly stops trying to hack. The difference is really noticeable.
And it's not like higher Proton versions are slowing the game down; During my test with Proton 4.2-9, the game was even having some small slowdowns!

With Proton 6.x-x, it feels like inputs are only processed when the game uses them to do a command, as if there was a difference between Cogmind (and other games) receiving an input that could be carried out and receiving one that couldn't yet be carried out that would then be "ignored", a difference which affected whether Proton removed them from the queue or not.

Another theory is that Proton "separates" events in some way that can be processed in this buggy way.

[Kyzrati]

(Which could actually just mean that later Proton versions recreated a Windows bug.)

Yeah this definitely happens sometimes. Proton actually handles some things better than Windows does in some cases, so technically it's no longer "accurate" and can also create different behavior, which may or may not always be beneficial. Windows has plenty of its own bugs and issues, of course

Whether or not to recreate them when games and other programs might even rely on these quirks to operate properly is a big issue, I imagine!

But yeah I don't know what they're really changing or doing over there. From a past experiment I did I know that not only do they not treat some very fundamental calculations and behavior identically to Windows' own approach, but sometimes they even make their own unique twist in some version, start discovering why it doesn't really work, then revert it in a later version, or... simply don't discover or revert it and now it's messed something up :/

[R-26 Lightspeed]

I've done some more testing.
It's not related to Polymind, but it is related to game performance :
When the game is running slowly, this issue occurs consistently (by the way, because they're not key events, mouse scrolling is less effective at idling when the game is running slowly, because relative events don't get queued, at least not in the same way. In other words, some mouse scrolling that would usually skip over 10 turns only skips 1-3 turns with slow game speed.)
When the game is running smoothly, this issue doesn't occur.

Something i noticed when trying to test whether the issue also exists with Proton 4 is that the game's performance resets when save-quitting then launching the game again, but builds up again with... time? turns?
In any case, there seems to be some issue that's causing the game to slow down after a while (moving to a new map doesn't make it better).
If i had to guess, i'd say it's a memory-related issue, like memory fragmentation.

[Kyzrati]

Hm, interesting, would this be on a low spec machine? I know a lot of people use Proton+Cogmind, but those same people tend to have faster machines. There's definitely going to be more performance overhead related to running Cogmind under an emulator (the greatest overhead comes from modern Macs, where there's multiple layers of abstraction necessary to get it running xD).

In cases like this I'm guessing you can likely use Luigi's performance mods made available here on the forums to resolve that issue. That mod can increase Cogmind's speed by a very significant factor, one that won't usually make a difference on Windows (where it's easy for most to always stay at the default 60 FPS cap anyway), but again on non-Windows systems things get a lot more demanding.

Another thing you can do is turn on the FPS counter to see what kind of numbers you're getting on your machine at various points. I can't imagine memory issues that don't reset going from map to map coming from Cogmind's normal behavior, since most everything is indeed reset when you make that transition, except for some global stuff, not to mention the overall footprint is low. No idea what Proton's doing though...

[R-26 Lightspeed]

Considering that my machine isn't low specs, and more importantly that alt-tabbing while not in fullscreen causes a lot of lag (i've seen another game's graphics freeze when alt-tabbing on Proton 1.6, and outright crash on 1.7), i'm guessing there's a memory issue in how newer Proton versions handle graphics for Cogmind?

I might try Luigi's performance mods, and will report results if and when i do so.

I forgot to check the FPS (by the way, i can't find how to change the FPS cap anymore? I know i used to know, and that i found that option myself, but apparently i've since forgotten).

[Kyzrati]

I forgot to check the FPS (by the way, i can't find how to change the FPS cap anymore? I know i used to know, and that i found that option myself, but apparently i've since forgotten).

It's in the system.cfg file.

[R-26 Lightspeed]

I forgot to check the FPS (by the way, i can't find how to change the FPS cap anymore? I know i used to know, and that i found that option myself, but apparently i've since forgotten).

It's in the system.cfg file.

Thanks, i had forgotten there was a third settings file.

I forgot to check my FPS during things like waiting being held for too long, but i did see that when going up the log by holding +, the game dropped as low as 6 fps.