[1.1.4] Factorio becomes non-responsive after switching consoles on linux

[mothringer]

Switching the active console away from the X server (using ctrl-alt-f2 or similar) causes the game to become non-responsive, although sound continues. It appears to be an actual hang rather than just graphics freezing, as it will immediately disconnect other players in multiplayer as well with a server is not responding error.

[Squelch]

Is your attached log from the crashed instance or had you restarted? There does not appear to be any evidence of a crash.

[mothringer]

It's not crashing, the process is still running, but will no longer respond to input from the player or the network, and is no longer drawing any graphics.

[KeepResearchinSpoons]

Pretty sorry if coloring does not suite your eyes or tastes. pls don't wash me to hard.
TL;DR:
[1.1.4] linux; keeps playing just fine really but HAVENT TESTED FULL MP(!); see code below for a random error + also high cpu usage (related); lots of rumbling follows, you've been warned of the spamwall;

TL;DR, (expensive marathon science-x5-per-player mode):
1) tty is not the same as pts if you are into the linux study time.
2) Graphic dies but revives. Sends some log err once in a while (cant reproduce but copied it the second time I managed to get it of about 20 switches)
3) Game still runs (takes rcon input, keeps playing at comfy server) while going to ctrl+alt+f2 and back (tty2 and back)
4) was tested with plasma on board (just as in OP's start logs).


Have seen the logs and see nothing of interest. Btw, iirc KDE (plasma) has a nice option (with a mouse widget included) of multi desktops'.
[offtopic about virtual desktops with plasma]

Try THESE if it is what you *really* want to achieve with ctrl+alts:
A WAY (easy): open up system settings, type virtual desktops;
B WAY (fast): Edit panel (alt+d) (aka widget settings mode)(not necessary if shown) -> select pager (the widget name) -> configure virtual desktops. Then swithcing with meta+numbers or ctrl + f'ss or any keymaps that are within your setup.
It works wonders while keeping the same TTY (see this [1] and also this [2] for TTY explaination if tou want, but really google the *pts vs tty* [3] difference to know more)
links:

1. console in linux https://wiki.archlinux.org/index.php/Li ... ementation
2. more about tty https://www.linusakesson.net/programming/tty/
3. pts vs tty short https://unix.stackexchange.com/question ... ts-and-tty

/[offtopic about virtual desktops with plasma] ah so it is not a collapsing spoiler... meh discord kills good spoilaz...

So. [1.1.4] linux build 57237. KDE etc/
factorio is started with -v in a term emu; zip version.

Whilst I do *think* it's probably not a bug really (X literally waits for a timey) I suppose it's not quite a behavior you expect from a gama' game if it _does_ kick all the players. It may do so if out of res or if server laggs too much behind at certain conditions but meh not a chance testing the scenario rn and not sure if it does kick the players because of the factorio really and not because of the system-setup and all the env and other options.

For me it RARELY starts to spam me with

Code: Select all

11.142 Error GraphicsInterfaceOpenGL.cpp:250: [OpenGL]: Error INVALID_FRAMEBUFFER_OPERATION encountered in frame 6****

after about 20 seconds of waiting at the TTY2... sometimes... not depending on the game state... we have sim in menu now anyways...

Switching to tty2 also:
Keeps sound; Probably keeps running the loop;
It does KILL simulation in BG of the main menu. Forever. Getting back from a game keeps it black. The menu works fine. Can still start a working game just fine.
It BLACKS OUT the surface and entities stuff (escape-menu works fine) in SP /(or MP host); Perfectly revives graphics back with user inputs (time?) again later.
Log/err say *nothing* really. All the time. Just "AppManager: game started" etc. and a terrible 50%+ cpu usage while off screen (see code above as for the apparent reason). Nothing else in logs, just sometimes starts spamming and sometimes keeps silent all the time till revives.
In *connecting to MP* it works just fine! Blackout -> revive -> still connected so no problem at all?

The prev para experience and this one exp may be in a little contradiction with OP post but your results may vary, haven't tested being the *real* host with *human* players.
Can't really test mp with a single X instance, so instead of goin vboxin and vmwarin I made a small rcon client with node.js for my local factorio instance. Yup its easy, just [spoiler]read the specs of source-steam-rcon, Just beware of the REAL long answers and just remember factorio is a bit crazy about forgotten (or multiple) rcon instances sometimes; if so you happen to junk some problems just restart the mp. Click settings while holding ctrl+alt and go to "the rest" to change rcon port and pass with game running, then restart the mp map and make tcp connection, send auth packet and get ready to smash commands with exec packets![/spoiler] What? You say you never launched a rocket in the death world before without rail creep to prevent expansion and thus its too hard for ya? Then try again! Use the almighty fish this time around! ( or use the one cell water wall to wreak bitters yet again )
(yup FF (factorio freeplay) does not warn rcon client for disabling achievements for example. It just does nothing and returns nothing for the first run of /sc. however it announces /sc full-command for the party :> yay. Should we file a bug report for the freeplay now, lol.)
And really;I CAN hear the chat blumbs while rconing from the TTY2 (while the MP is hosted at TTY1)!! It is surely _ded with graphics_ but still good with goin on. So really no problem! Of cause If I surely stop it with sigstop it does _not_ heed my calls but hey it is to be expected.

P.S [THIS IS STRICTLY *KDE PLASMA* RELATED PART!]
There's an old known problem of factorio that it hurts kwin (kde window manager) badly if allowed to "block compositing". You shall need to either (bad hackz) restart kwin with `$ kwin --restart` after the game end (smth of bash/zsh like `$ factorio -v && kwin --restart;` in lnchr OR simply go to your system settings -> display -> compositor -> uncheck "allow apps to block compositing" and Boom the rocket flies! No more all konsoles going to solid transparency until reboot/relog/kill X/etc each time running factorio; No more switching rendering backends for kwin with scripts on the fly! All the fish is yours!!! Even the red fish and the mew fish!
I haven't really seen this problem with other apps but I do recall this from way back to 0.16 at least so probably it's a system thing not a game thing.

[Merssedes]

I'm curious. Are you play fullscreen or windowed mode?

[KeepResearchinSpoons]

Both as a full screen mode and as a window mode give same results.
Not sure if the code of an opengl error is related to the fullscreen only.

Usually the game is at full screen as a separate virtual desktop so as not to bring up a collapsing panel with widgets when moving the mouse to the side.
(so the browser is at say 3rd desktop and the game is at the 4th and say grafana is at 7th and the hot swap is something like ctrl+F3 to bring up the browser window and others at that desktop and ctrl+F4 to bring up the game full screen instantly while ctrl+shift+F3 is to get the metrics should you need them). It does NOT minimise itself when switching virtual desktops so its useful to keep going while you check the launcher output and being able to hot swap back the moment you hear the bitter came to greet your little skeleton leg.

[KeepResearchinSpoons]

[1.1.5] linux almost :> FIXED
somehow at [1.1.5] the black screen has been fixed.
maybe some kovatron lurked in and then lurked out...

EDIT: the main menu simulation dies forever just as earlier; if switched in-game then game works fine (no black) but main menu sim strangely is ded to black (and never revives probably) when i got back to it

[Oxyd]

Hm, when I test this, the game doesn't freeze for me. The menu simulation goes black after switching back to X, but that goes away after resizing the window.