MovingBlocks / Terasology

Terasology - open source voxel world
http://terasology.org
Apache License 2.0
3.68k stars 1.34k forks source link

Headless launched via jar still shows splash screen? #1571

Closed Cervator closed 8 years ago

Cervator commented 9 years ago

I was testing the headless launch from jar just to make sure I was giving the right command to a user:

java -Xms256m -Xmx1024m -jar Terasology.jar -headless -homedir=server

But running that on my Win7 desktop still popped up the splashscreen? I would expect not to see it.

1501 took it out from running from source in a Jenkins run, but this is technically a different launch scenario. Unless maybe #1550 brought it back somehow? Any clues @msteiger ?

Seems low priority, user ran server fine on a hosted machine and I was able to connect :-)

msteiger commented 9 years ago

Oh well, I made that on purpose, because I did not see a reason to deactivate it :smile: It is displayed whenever a graphics environment is available and the splash image is passed as jvm argument (either explicitly or in the MANIFEST.MF entry in the jar file).

Would you rather have it deactivated it when the runtime arg -headless is passed?

Cervator commented 9 years ago

Yeah, in part because it never closes :D Or at least I didn't notice it doing so. Seems counter-intuitive anyway since it is a "head" for headless of sorts :-)

Cervator commented 9 years ago

Hitching a ride on this issue instead of making a new one - running the game with the -help flag also shows the splash screen, that's probably not desired (it flickers briefly since the help returns very quickly), but unsure how easy it is to distinguish?

Noticed while testing #1575 which also moved the jar so the command is now slightly different when running out of a binary package:

java -jar libs\Terasology.jar -help

On a somewhat related note the new .exes aren't showing the splash screen but that's probably just temporary till @shartte figures it out

There we've also talked a bit about the .exe probably being stuck either as a GUI app or a console app, but not both, leading to a sensible use case where headless is not actually window less - it would make sense in that case to run a log (or even help text) in a basic window. Later that could be turned into a proper server admin tool. So maybe headless showing a splash screen isn't bad if it is part of loading a window anyway.

That scenario is specific to the Windows .exes though. Running via .jar is fine - you can get the logging in the console yet have the game window pop up.

Cervator commented 9 years ago

Bumping this rather than making a new issue: splash screen now seems to trigger in any case (other than when no graphics environment is available, I assume). Still a minor issue at most.

msteiger commented 9 years ago

The library also contains a pure Java implementation of the splash screen. We could remove the native AWT version altogether and configure it's visibility through Java code. This would also fix this issue here. Will have a look..

qwc commented 8 years ago

Huh, this is a major issue if you want to run a REAL headless server as in my docker image. For this case I would call it a show-stopper. Revived my rather old little side docker-image just today, and found out that the server isn't able to run due to this issue.

[Edit] This exception occurs on starting a real headless server:

terasology_1 | java.awt.AWTError: Assistive Technology not found: org.GNOME.Accessibility.AtkWrapper
terasology_1 |  at java.awt.Toolkit.loadAssistiveTechnologies(Toolkit.java:807)
terasology_1 |  at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:886)
terasology_1 |  at java.awt.Image.getScaledInstance(Image.java:178)
terasology_1 |  at org.terasology.world.block.tiles.WorldAtlasImpl.generateAtlas(WorldAtlasImpl.java:327)
terasology_1 |  at org.terasology.world.block.tiles.WorldAtlasImpl.createAtlasMipmaps(WorldAtlasImpl.java:261)
terasology_1 |  at org.terasology.world.block.tiles.WorldAtlasImpl.buildAtlas(WorldAtlasImpl.java:210)
terasology_1 |  at org.terasology.world.block.tiles.WorldAtlasImpl.<init>(WorldAtlasImpl.java:90)
terasology_1 |  at org.terasology.engine.modes.loadProcesses.RegisterBlocks.step(RegisterBlocks.java:53)
terasology_1 |  at org.terasology.engine.modes.StateLoading.update(StateLoading.java:242)
terasology_1 |  at org.terasology.engine.TerasologyEngine.mainLoop(TerasologyEngine.java:414)
terasology_1 |  at org.terasology.engine.TerasologyEngine.run(TerasologyEngine.java:369)
terasology_1 |  at org.terasology.engine.Terasology.main(Terasology.java:143)
terasology_1 | For more details, see the log files in /terasology/server/logs/2016-01-09_18-29-07
msteiger commented 8 years ago

This issue is (should be?) fixed for a long time now. We use our own splash screen implementation now: https://github.com/MovingBlocks/SplashScreen

It checks if a GUI is available and uses a stub implementation if not: https://github.com/MovingBlocks/SplashScreen/blob/master/src/main/java/org/terasology/splash/SplashScreenBuilder.java#L73

@qwc I think that you're having a different issue. According to the log, the world atlas cannot be generated due to a missing AWT implementation. Wild guess: can you verify that the JRE that is used is correct and complete?

@minnesotags has succeeded to install and run a headless server afaik.

qwc commented 8 years ago

@msteiger Oh, then I maybe was mislead through the search for "headless", etc. and my guess was clearly wrong. Sorry about that.

I'm using the openjdk-jre8-headless, same I used before, except the older one was openjdk7, back then.

I'll test with the non-headless, asap.

[Edit] My tests show that you cannot use the jre8-headless version of java. End of story. :) Well, the headless version was nice on linux, because of the small library overhead. The full jre has a big bunch of deps on ubuntu. Most of them unused I'd guess.

Cervator commented 8 years ago

I guess that makes sense then. Is that headless JRE a custom user made thing? If it excludes the class we use to test for whether you're running in a headed or headless system - then yeah it seems like that would fail :-)

Is that commonly used? I've never heard of it before but then I haven't looked. I understand Java 9 might get more modular from the official side so to say, so eventually we'd probably have to deal with that.

Btw my apologies for never getting back with you on automating the docker build with a ping from our Jenkins. Stuck with crazy work for months, finally been able to put some time in here over the holidays. We actually have upgraded Jenkins + Artifactory now, woo.

I re-investigated another similar hook we could use to publish our test coverage results to a site specialized in that. Only hooked it up for testing (again) but last time around that was my goal to handle at the same time as hooking up the docker piece. So getting close again!

But then if the headless JRE thing gets in the way now I guess we have something else to look at first :-)

msteiger commented 8 years ago

Can we close this issue?