Closed Cervator closed 8 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?
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 :-)
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.
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.
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..
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
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.
@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.
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 :-)
Can we close this issue?
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 :-)