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]
/[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.