Grid Sage Forums
Cogmind => Bugs => Fixed Bugs & Non-Bugs => Topic started by: Kyzrati on May 11, 2017, 01:13:21 AM
-
It's apparently possible to get the main UI into a state where no commands work.
As reported so far, this has happened a couple of times to magi163 (who was Alt-Tabbing a lot), and once to Koumakan (who had left the game running all night, and probably Alt-Tabbed too).
I'm still waiting to find a specific cause for this, since it's rare, not easily repeatable through testing, and doesn't actually crash--or even stop--the game, making it hard to collect data on it...
For now, if this happens to you (no keyboard presses or mouse clicks do anything while you're in the main UI), you should be able to just close the window and Cogmind will automatically save on exit, then you can restart again where you were with the UI reset to normal.
Also feel free to drop a note in this thread if you have any relevant information, thanks!
Update 191217: Cogmind's latest release (Beta 9.3) includes the fix which I think probably once and for all gets rid of this issue and its various forms, as described in this post (https://www.gridsagegames.com/forums/index.php?topic=791.msg8968#msg8968).
-
I've just entered 7 for the first time and I wanted to start by looking around the map (since I have DC). To get consistency in my map movements, I used the Alt + arrow key system to move, and I took screenshots every so often for later reference. This worked at first, and then suddenly stopped working.
I have tried:
- pressing relevant keys (Shift, Enter, Alt, arrow keys) to ensure they are not stuck;
- ensuring that the issue is not with my keyboard or mouse by using them in other applications;
- escaping to the menu (doesn't work).
I am hesitant to try restarting in case diagnostic data (possibly beyond run.log) would be overwritten by doing so.
The game does not:
- respond to movement commands, whether by mouse or keyboard;
- respond to map movement via Alt+arrows or Enter (Shift+mouse still works, oddly enough);
- allow parts to be activated / deactivated / cycled as a slot type or reassigned using the mouse (no drag-and-drop animation shows up);
- allow parts to be equipped (ditto);
- allow for the primary log to be expanded, the secondary log to have its mode changed changed, the inventory to be sorted in any way, or the part status display to change modes (though for all of these the "you've moused over something" animation and SFX still plays, as with the previous two);
- respond to right-click examine or "s" status;
- open the world map, whether by mouse or keyboard.
The game does still:
- autosave;
- play corruption glitches;
- animate off-map intel labels (such as machine locations);
- open the Scan and Evasion windows on mouseover (though labels do not display whether from the Scan window or by their keys);
- display pathfinding to the cursor as the mouse moves.
I'm really not sure what's up here, and since the game isn't crashing to desktop I may not have a crash log. I think I do have to shut it down by force now, but if you have any diagnostic requests let me know!
-
Update: the "friendly" End Task (the one that gives the process an opportunity to clean up) through my computer's Task Manager sufficed to shut down the game, with the "hibernating" sound played. No crash log was generated. Attached are the following:
- the automated backup save from before this game session, which hopefully allows reproduction just by heading over to 7;
- the final save produced when quitting by force;
- the run.log for that session.
Of note in the run.log is this line:
W=0316075 | BS::placeMachine() | Terminal at (22,72) has more targets than CMachine can display at once: 26
What a juicy terminal for a flight hacker!
Are there any more diagnostics I should try or files I should include before starting the game back up?
-
I've merged this with the older topic it's a part of/related to.
This isn't the first time it's happened, but unfortunately no amount of save data or logs can shed light on this since it's purely a bug in the UI state--the game logic and animations and everything will run fine. It depends on some exact key presses to cause the UI to enter a state where it no longer accepts input, but it's so rare that we have no known way of repeating it.
Somehow on the main UI it's still possible to enter this state, but the UI has so many possible states that I don't know which combination could cause this :/.
Ideally this would happen to me sometime, so that I can just attach the debugger and closely examine the state, but so far I've never seen it xD (having the game produce enough of the right diagnostic data to reliably debug it remotely would be tough). As for others who encounter it, they'd have to remember their exact sequence of key presses before it happened, and be able to repeat it, before I could possibly do so here.
-
Ah, I see.
Ideally this would happen to me sometime, so that I can just attach the debugger and closely examine the state, but so far I've never seen it xD (having the game produce enough of the right diagnostic data to reliably debug it remotely would be tough). As for others who encounter it, they'd have to remember their exact sequence of key presses before it happened, and be able to repeat it, before I could possibly do so here.
Would a sequence of keypresses from entering the map suffice? It was so close to the start of the map (I literally made one move to get my sensors to activate and DC to load up, then looked around) that I remember what I did from that point pretty well. I could try to reproduce it from the pre-lock save (which has the problem that there's an enemy in between who may or may not hit, possibly changing the build), or from the post-lock save, or just say what I did.
-
Anything you could do to repeat this would be great! It shouldn't really have much of anything to do with game logic, so what save you use may not even matter, but certainly keeping as many variables the same as possible makes it more likely to reproduce the same situation, just in case.
Oh, and I forgot to address this:
Of note in the run.log is this line:
W=0316075 | BS::placeMachine() | Terminal at (22,72) has more targets than CMachine can display at once: 26
What a juicy terminal for a flight hacker!
Nothing special there, that's actually not too uncommon. SL3 terminals may sometimes fill up all their slots, and maybe even have too many to show because there are so many possible hacks now and they can only do up to 26 (a~z), in which case they simply can't make all their direct hacks available :P
-
Anything you could do to repeat this would be great! It shouldn't really have much of anything to do with game logic, so what save you use may not even matter, but certainly keeping as many variables the same as possible makes it more likely to reproduce the same situation, just in case.
Hmmm, turns out that the post-bug save won't reproduce it (possibly some elements of the DC data load showing intel labels even if the player doesn't have the secondary log in intel mode, some state carried between maps, or heavy dependence on mouse positioning during my initial broad Shift+mouse look around to see roughly where I was on the map). And the pre-bug save has too much random variation of robot behavior in between the saved point and the bug occurring to get the exact same command sequence to even be accepted and result in the same UI state - different wander paths of neutrals result in hopping at different points, and so forth. Plus in between that saved point and the bug occurring I earned the achievement one would expect to immediately precede a first visit to 7, and that impacts UI state too... Other than that the pre-bug save is exactly what I loaded up when starting that session (I fished it out of the daily backups), but that seems to be enough to prevent reproduction.
Oh, and I forgot to address this:
Of note in the run.log is this line:
W=0316075 | BS::placeMachine() | Terminal at (22,72) has more targets than CMachine can display at once: 26
What a juicy terminal for a flight hacker!
Nothing special there, that's actually not too uncommon. SL3 terminals may sometimes fill up all their slots, and maybe even have too many to show because there are so many possible hacks now and they can only do up to 26 (a~z), in which case they simply can't make all their direct hacks available :P
Haha, I don't dive into the run.log file very much. :P Good to know that that's not the cause.
-
I don't think any of those things are related to the issue, though. To be more specific, by UI state I mean specifically input state, so this is purely some sequence and timing of commands which can do this. Those other factors like robots and achievements and even labels don't affect input, so they're not almost certainly irrelevant for reproduction. (Perhaps it's not impossible that one of the optional windows themselves like Intel could be playing a role, though.)
It'll probably never happen to me because it seems to only affect certain players based on how they interact with the many different potential input schemes. Perhaps we now have a clue that it might have something to do with the mouse? I believe magi163 is a mouse user.
-
Ooof, timing would throw a wrench into things. I can't easily reproduce that, especially now that I know where I'm going! And even trying to get the exact same sequence despite robot movement variation would result in being shot to pieces...
It may well have to do with mouse input; I do use the keyboard for some commands, but I use the mouse extensively both for common commands and for triggering labels on things I want to screenshot (like the entrance to 7 :P ). Mouse input is also harder to reproduce precisely from memory, which doesn't help matters.
-
Timing is just a guess, seeing as it's so rare.
-
Another thought: I wasn't Alt-Tabbing at all in the lead-up to this bug, but I was dodging and avoiding enemies quite a lot, along with toggling parts accordingly. Perhaps the types of input sequences that trigger this bug are more common in stealth gameplay?
-
I just got this (or similar) bug as of Beta 8. Except that I could go to the game menu and save & quit normally.
I missed a datajack shot, parsed a bot with it, and the last command was to close the parse window, either by RMB or Esc. Saves from before and after are attached.
-
Yeah this'd be a new one unrelated to the others in the thread you added to (https://www.gridsagegames.com/forums/index.php?topic=791.0), which are still out there somewhere. (I've moved this to its own topic.)
Update 191115: I've merged this back into the original topic, because although not quite the same thing, I'm starting to think the *underlying* cause is the same or similar based on new discoveries and additional reports in Beta 9. The results are not always the same in every case, but I think architecturally they're all being caused by the same thing.
There were some changes to the robot hacking window for Beta 8, though I'm surprised no one else had this happen yet (since others have been doing datajack parsing as well...). There were no changes to the Parse window though, which is where it seems your specific issue lies, hm.
I don't think saves will be much help here since it's purely something to do with UI state and whatever specific commands you used right before it happened...
I wonder if the fact that you missed your target and ended up parsing something else played a role, though I've tried this a bunch now and can't get anything weird to happen :/
What bot did you end up parsing? Was it far away? The saves don't seem to hold any relevant info.
-
I was aiming at a disabled brawler and hit an allied brawler instead. The allied brawler was (diagonally?) adjacent to me. Maybe, in haste, I tried shooting through my brawler, right after rewiring a previous target.
-
Alright, thanks, I guess I have some more scenarios to try to test then :)
Rare UI state bugs like this without a reliable cause are the hardest to nail down xD
-
Just an update, still haven't been able to repeat this one :(
Guess it'll have to stay here for now...
-
Oh my, I think I may have resolved all these rare but annoying random main UI freezes.
While adding a new feature I actually just came across a way to reliably freeze the main UI in a way similar to what some players have experienced (reliable repetition being key to debugging).
Hours and hours of exploring later and I found a likely potential cause for all of these, and managed to overhaule a very low-level supporting system involved in UI state handling, both simplifying it and making it impossible for freezes to happen, at least those that were happening in the one way I've been able to actually repeat so far to confirm!
The fix is included with the next release (whatever comes after Beta 9.2) but I might leave this thread out in the open anyway to be sure, and for reference in case anyone else comes along with something similar but new.
Hopefully it gets them all, and hopefully it doesn't lead to any new issues because honestly fundamental changes like this to architecture made after having worked on a complex game for so many years is kinda like opening a can of potential worms, especially considering how many well-tested UI features we've accumulated so far! Time will tell...