Moved Terasology.jar to libs subfolder to avoid confusion.

[shartte]

Replaced Windows launchers with new JLI based launchers and removed old one.
Remade TeraEd.exe to prefer 1.8 JRE.

[Cervator]

Alright, looked at it some :-)

Comments

• Moving Terasology.jar into libs - it is a tradeoff. Less confusion double clicking perhaps, more confusion what to java -jar perhaps. Dunno which is better, Not particularly worried which we pick so sure, lets see how it goes. Maybe add a Terasology.bat that runs the jar, at least for the generic distro? Or just tweak our docs.
• Applet build locally didn't add Terasology.jar to its lib, although I haven't play tested it, just built it.
• Would you mind if we move the https://github.com/shartte/TerasologyJavaLauncher repo to MovingBlocks? The JRE one too
• Do we need both .exes or can we use a single one? Can we launch a 64-bit jre from a 32-bit exe, or is that the problem now that the exe and java are more closely integrated, so you get the task bar icon properly? It sounds like Win10 will still support 32-bit so if the .exe was always 32-bit yet launched the higher available bit count Java that would be handy (might well not be possible tho)
• Can we make it clearer if you launch using a 64-bit exe that you can get the "No java" even if you have Java installed, but at the wrong bit-count? I installed Java8 32-bit first and got the usual error running the 64-bit exe that I had no suitable Java 8. Might make some users rageface.
• Running via .exe gets logging in the command prompt, yay! So this fixes Launch using .exe does not print any output #1401 + Game detaches from command prompt launch on Windows #1339
• Added after some of the comments below Wait .. is there supposed to be a pause at the end of game exit in a command prompt, that you get out of by hitting enter? If you do Terasology.x64.exe -help you get the help text, but no next prompt, it pauses waiting for the user to hit enter, yet gives no indication of that. Maybe we can take that out? Maybe the game is disposing after all
• If I run Terasology.x64.exe -homedir -headless then wait for the server to start, I can hit enter and the process partially disconnects, giving me a normal ready prompt again, but Terasology.x64.exe keeps running and actually logs to the same window. Very weird! It still catches CTRL-C and exits correctly at that point
• Pinning the executable to the task bar works and looks great :-)
• Haven't tested TeraEd, at least not yet. Does it actually work nowadays? Heh.

Hit an error on running with 32-bit exe + 32-bit Java (but I believe this is due to my video card driver screwing up again - more notable for the CR interaction later)

19:50:49.197 [main] ERROR o.terasology.engine.TerasologyEngine - Failed to initialise Terasology
java.lang.RuntimeException: Can not initialize graphics device.
    at org.terasology.engine.subsystem.lwjgl.LwjglGraphics.initDisplay(LwjglGraphics.java:180) ~[engine-0.48.1-SNAPSHOT.jar:null, , null, pre-alpha]
    at org.terasology.engine.subsystem.lwjgl.LwjglGraphics.postInitialise(LwjglGraphics.java:98) ~[engine-0.48.1-SNAPSHOT.jar:null, , null, pre-alpha]
    at org.terasology.engine.TerasologyEngine.postInitSubsystems(TerasologyEngine.java:266) ~[engine-0.48.1-SNAPSHOT.jar:null, null, null]
    at org.terasology.engine.TerasologyEngine.<init>(TerasologyEngine.java:169) ~[engine-0.48.1-SNAPSHOT.jar:null, null, null]
    at org.terasology.engine.Terasology.main(Terasology.java:119) [Terasology.jar:null, null, null]
Caused by: org.lwjgl.LWJGLException: Pixel format not accelerated
    at org.lwjgl.opengl.WindowsPeerInfo.nChoosePixelFormat(Native Method) ~[lwjgl-2.9.2.jar:na]
    at org.lwjgl.opengl.WindowsPeerInfo.choosePixelFormat(WindowsPeerInfo.java:52) ~[lwjgl-2.9.2.jar:na]
    at org.lwjgl.opengl.WindowsDisplay.createWindow(WindowsDisplay.java:253) ~[lwjgl-2.9.2.jar:na]
    at org.lwjgl.opengl.Display.createWindow(Display.java:306) ~[lwjgl-2.9.2.jar:na]
    at org.lwjgl.opengl.Display.create(Display.java:848) ~[lwjgl-2.9.2.jar:na]
    at org.lwjgl.opengl.Display.create(Display.java:757) ~[lwjgl-2.9.2.jar:na]
    at org.terasology.engine.subsystem.lwjgl.LwjglGraphics.initDisplay(LwjglGraphics.java:175) ~[engine-0.48.1-SNAPSHOT.jar:null, , null, pre-alpha]
    ... 4 common frames omitted

@msteiger - after I got the CR with the above error and X'ed out of the window (on the first page) the game didn't dispose :-( Not fully terminating on the X? Although on retesting even going through each page doesn't seem to eventually dispose. Oddly I can't even find the process holding a lock on the command prompt, but it stays stuck till I CTRL-C

Running with the old .exe got me a popup instead and no CR (and no disposal - splash screen stayed up forever). That's kind odd, but I guess the new .exe handles a broken video driver better somehow?

Huh, oddly I get the same popup with the new 64-bit .exe. But the 32-bit hits the CR ... probably not good reports due to screwy graphics issues.

I can't actually test the game right now, will have to get back to that later. Why oh why did I accept the prompt to update my video card drivers to the latest version ... first BSOD then better but still brokeny :-(

When we're ready to merge this I'd like to run a final stable build so I can call that the last Java 7 build - although not really since you can still launch Java 7 without the .exes. But anyway.

Thanks for the good work! Feels like we're very close :-)

[Cervator]

Oh, on the .exe names I didn't think about the OS+bit specific zips. So I guess if you download Win64bit the 64bit exe would rename to Terasology.exe?

And yeah the weird CR interactions + disposal must to some degree relate to the strange "Press enter to disconnect" thing

[msteiger]

The problem that the game does not dispose all thread pools on crashs is independent from CR, I think. The splash screen should close in any case though. Will have a look at that.

[shartte]

Would you mind if we move the https://github.com/shartte/TerasologyJavaLauncher repo to MovingBlocks? The JRE one too

Not at all, I was hoping that to be the plan anyway :)

So I guess if you download Win64bit the 64bit exe would rename to Terasology.exe?

Yes, that's the plan.

Regarding the single exe:
We might be able to make a Terasology.exe that chooses automatically based on JRE availability, although right now i wouldn't put in the work since only advanced users should have this issue anyway. It should be possible to improve the ErrorMessage though.

I will also check the console attach issues. It's a bit finnicky in Windows, sadly.

[shartte]

I checked what we can do about the GUI program detaching but still controlling the console: not much, really.
We can try wrapping it in a batch file but the experience is still terrible. It might be a better idea to pop up a swing window as soon as possible and log to that. Other possibilities include showing a window in the launcher and logging to that... I am not sure yet.

[Cervator]

Looking around a bit it appears an assortment of improvisations have been used, I wonder if any of them are good enough. Like one suggests a way to avoid the "double window" approach of supporting both and redirection to the GUI app if no arguments:

http://www.tillett.info/2013/05/13/how-to-create-a-windows-program-that-works-as-both-as-a-gui-and-console-application/

Did you see that or similar ones? It seems to emulate an "enter" press at some point. I could see how that would make "terasology -help" feet right (it would exit back to the prompt immediately after printing the text), but I'm not sure if that would help the headless server.

Unless - could we somehow choose to just log a quick snippet when headless "Starting headless server - this prompt will exit, please review the log file to check on the server and terminate it by .." ... uh, not sure how you would actually terminate it...

Come to think of it, if you're running an exe manually you're almost guaranteed to be on a headed Windows system, meaning you could indeed launch a server admin window and forego the console hook to the prompt. If you're wanting to run as a service there are alternative options available, probably excluding the exe.

What we really want:

• User runs exe with no arguments or double-clicks => Run the game GUI, ignore console
• User runs exe with -help => Print help text to console and exit immediately.
  ** User who does this in the Windows "run" box is a bad person and should feel bad! Okay, not that bad, but we shouldn't need to care in this case, that's a general Windows usability thing and not our problem
• User runs exe with -headless => Pop up server admin panel, ignore console

The third scenario's window could be delayed till later so we can move forward in the meantime. Which still leaves the question of what to do there. We can't lock on the console and log to it or we'll get the weird "user can hit enter and get strange behavior"

I'm beginning to question my desire to support in-console help text with the .exe. Instead pop up a simple help window with an exit button like you suggested on IRC. Would work in "Run" as well. Headless could do the same with a simple button to exit the server. It ... feels wrong, somehow. But then Windows is hardly OS nirvana.

Headless server with exe not being "Windows" headless. Wee!

[shartte]

Headless on Windows would be a service executable, which is a whole lot different from what we are currently doing. We should probably provide one later, but that might be a separate distribution, really.

For now I would remove the AttachConsole thing entirely and focus on other ways of debugging.

[Cervator]

Alright, fixed my system, actually able to launch the game again, with this setup live :-)

Agreed on service executable for consistent headless, we worry about that later.

The quirkiness sucks, but what can we do, oh well. It works!

Want to go ahead then and remove AttachConsole and make the .exe launch "silent" from command line again? I think we can merge with that in place, then after make some future goals to get to later.

Anybody else want to take it for a spin or provide more feedback? @msteiger @skaldarnar @mkalb etc? We might want to tweak the readme sometime with a note on the exes.

[shartte]

I will remove the AttachConsole part. Do you think having a TerasologyCli.exe would have any actual benefit? I highly doubt it to be honest since for actual servers as a service it would not help.

[Cervator]

Nah, I'd leave out CLI. If for some reason there's more of a point to it later one day we can deal with it then.

[shartte]

Allright i updated the launchers and removed AttachConsole. Instead I added an option to the launcher cfg file that will redirect STDOUT/STDERR to a log file (filename can be specified). This helps with debugging launcher issues since sometimes the JVM just writes an error to stderr and fails (even in UI mode). I can't really catch those errors since it just calls ExitProcess to exit :-/

[shartte]

A bit about the config file:

The native launcher reads a file that is named the same as the exe, but with the cfg extension. I.e. Terasology.x64.exe automatically reads Terasology.x64.cfg.

Supported options:

• jvmarg (repeatable) sets JVM command line parameters like -Xmx
• arg (repeatable) sets Program command line parameters (that come after -jar ...)
• jredir sets a custom JRE if the user wants to use their own JRE from somewhere other than the registry
• log sets a logfile location for the launcher log (if it's missing there is no log)

Lines starting with ; are ignored
Keys and Values are trimmed

Example:

jredir = C:\MyJre\
arg = -homedir
arg = C:\Special\Home\Dir\
jvmarg = -Xmx2G
jvmarg = -Xms2G
; uncomment this to enable log
; log = launcher.log

The plan is to have the launcher write this file when the user clicks launch. Then run the executable appropriate for the platform.

[Cervator]

Thanks for the extra info :-)

Most my early evening went poof for RL reasons, so not enough time to test this tonight, just merged a couple quick PRs. Will do a stable build after work tomorrow then merge this in and announce Java 8 requirement for using the Windows exes

Curiously, how do the Linux/Mac launch scripts relate to the new fancy config file? Only works for the exes I figure? And should we use a different comment symbol like # or // ? edit maybe that's a Windows thing

There's some talk about logging over in #1574 including some difficulty with the initial logging / initial log file rolling. Maybe we could work something helpful for that in later? Although it sounds like we'd eventually be at risk for making a mini-launcher of some sort, heh

[shartte]

Adding such a launcher-config file for the linux/macosx launcher scripts is a todo i'll tackle when we get to the Terasology Launcher part. It's a multi-step process to get where we wanna go.

[Cervator]

Agreed - submitted #1588 for later since a related Mac scenario came up again :-)

Tested around some more. Noticed the splash screen doesn't appear when launching from .exe, is that on purpose or not working? I see a removal of from("${sourceSets.main.output.resourcesDir}/splash.jpg"), was it meant to be bundled in the .exe like the icon somehow?

I did notice it work (exceedingly briefly) with java -jar libs\Terasology.jar -help which is probably not intentional, heh :D

Thanks for the work and patience!

[Cervator]

Can also confirm applet still looks good. Yay!

http://jenkins.terasology.org/job/TerasologyApplet/lastSuccessfulBuild/artifact/build/distributions/applet/index.html

[shartte]

Regarding the splash screen: I thought that the splash screen was read from the jar file (?)

I might need to check on that.

And thanks for mergin!

[msteiger]

The splash is part of the jar file and loaded directly by the Java Runtime. The filename is specified in MANIFEST.MF.

This page gives a nice (short) overview on how it works:
http://docs.oracle.com/javase/tutorial/uiswing/misc/splashscreen.html