Simplify release process

[hiran]

While I played around with the build process I eventually downloaded one of the Windows builds.
It contained my intended changes but did not run. Strange error message in the logs.
Then I downloaded the original latest build and tried that one, which failed exactly the same way. So it is not the modifications I made but likely the environment. I am testing on Windows 11 running as VirtualBox appliance.

Here is the content of Latest.log:

Code: Select all

Opening log for Oolite development version 1.91.0.7439-230618-78c8be1 (x86-64 test release) under Windows 10.0.22621.1702  64-bit at 06:56:09.
Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz 4 processors detected. System RAM: 8179 MB (free: 5491 MB).
Build options: OpenAL, GLSL shaders, new planets, JavaScript console support, OXP verifier, localization tools, debug GraphViz support, JavaScript profiling.

Note that the contents of the log file can be adjusted by editing logcontrol.plist.

06:56:09.347 [dataCache.notFound]: No data cache found, starting from scratch.
06:56:09.388 [sound.initialization.error]: Failed to open default sound device
06:56:09.388 [sound.init]: Sound system disabled.
06:56:09.389 [display.mode.list.native]: Windows native resolution detected: 1024 x 768
06:56:09.418 [rendering.opengl.state]: Incorrect OpenGL state in -[MyOpenGLView initSplashScreen] (line 801)->OOSetOpenGLState
06:56:09.418 [rendering.opengl.state]: Expected previous state: <canonical initial state>
  06:56:09.418 [rendering.opengl.state]: GL_ACTIVE_TEXTURE should be ENABLED but is ENABLED.
  06:56:09.418 [rendering.opengl.state]: GL_CLIENT_ACTIVE_TEXTURE should be ENABLED but is ENABLED.
06:56:09.418 [rendering.opengl.badExtension]: ***** An uninitialized OpenGL extension function has been called, terminating. This is a serious error, please report it. *****

Closing log at 06:56:09.

I am getting surprised to read ...should be ENABLED but is ENABLED...

On top of that I experienced that no start menu entry was created, and the application did not register it's uninstaller. Is this 'normal'?

[another_commander]

No, not normal.

Your OpenGL drivers are bad. I suggest you install on a machine running Windows and avoid VMs. Even if you do get it to run on a VM, expect bad performance.

[hiran]

No, not normal.

Your OpenGL drivers are bad. I suggest you install on a machine running Windows and avoid VMs. Even if you do get it to run on a VM, expect bad performance.

I do not have access to a Windows machine to install games. But if what I perceived is what I paid for I shall be satisfied, since I had just gone for
https://developer.microsoft.com/en-us/w ... -machines/
OpenGL performance is not an issue when testing to install and uninstall software.

What about the start menu entry? What about the uninstaller?

[another_commander]

Whatever graphics driver gets installed with the VM is not OpenGL capable. At least, not capable to the level that will be able to run Oolite.

What about the start menu entry? What about the uninstaller?

No idea. The problem with VMs is that you can't possibly know what is going on when things don't go as planned. Note that your sound system under Windows is also busted.

FWIW, I can install the latest nightly just fine on a VM with the Windows 11 Sandbox. Uninstaller works fine as well.

[another_commander]

A very quick search online came up with this:
https://forums.virtualbox.org/viewtopic.php?t=101304

Looks like OpenGL 3 is not supported very well in VirtualBox (current Oolite requires OpenGL 3.3) but there seems to be a way to make it work described in that thread.

[hiran]

A very quick search online came up with this:
https://forums.virtualbox.org/viewtopic.php?t=101304

Looks like OpenGL 3 is not supported very well in VirtualBox (current Oolite requires OpenGL 3.3) but there seems to be a way to make it work described in that thread.

Ack. I have not yet made it work, but maybe I need to try harder.

When did the requirement for OpenGL 3.3 actually come up? Oolite 1.90 runs on my standard VirtualBox Linux appliances quite fine.

[another_commander]

When did the requirement for OpenGL 3.3 actually come up? Oolite 1.90 runs on my standard VirtualBox Linux appliances quite fine.

When we switched to the new renderer in 1.91, about a year ago. The actual commit was https://github.com/OoliteProject/oolite ... 975fd95a76

[Commander_X]

Running Oolite for Windows under Linux is quite straightforward under Wine. Here, my last own built:



One caveat, when choosing to run Wine as a desktop window, trying full screen in Oolite will not do it right (there will be a window the size of the desktop but not "full screen"-ed -- it will be positioned wrong, and it will have windows decorations). I don't mind though, as I play most of my games in windowed mode.
I didn't try Wine full screen, or Wine rootless.

[hiran]

Another caveat I had to learn about:
The working directory seems to matter when you start Oolite.

Not on Linux - you use oolite-wrapper.sh and everything is good. But on Windows, if you run oolite.exe from any other directory than oolite.exe's parent the game will terminate. No log message, no console message and no window will ever acknowledge that the program has run at all.

[another_commander]

Another caveat I had to learn about:
The working directory seems to matter when you start Oolite.

Not on Linux - you use oolite-wrapper.sh and everything is good. But on Windows, if you run oolite.exe from any other directory than oolite.exe's parent the game will terminate. No log message, no console message and no window will ever acknowledge that the program has run at all.

?

Is this another VM thing? Because I can create shortcuts and run the game from anywhere. I can also run it by double clicking on the .exe (located in oolite,app, which is not the parent folder of the executable's location). Can you describe how exactly you are trying to run it and confirm whether this is a VM or not?

[Commander_X]

Another caveat I had to learn about:
The working directory seems to matter when you start Oolite.

[...] But on Windows, if you run oolite.exe from any other directory than oolite.exe's parent the game will terminate. No log message, no console message and no window will ever acknowledge that the program has run at all.

You are right.
It is also true I never even thought to try running Oolite from command line in Windows.

For those interested, in order to reproduce this:
1. start cmd.exe
(in Command Prompt window)
2.

Code: Select all

%SystemDrive%

3.

Code: Select all

cd %USERPROFILE%

4.

Code: Select all

<fully_qualified_path_to>\oolite.exe

(e.g. z:\mygames\oolite\oolite.app\oolite.exe)

Confirmed under Windows10 and Wine.
In both cases, starts all right by double clicking and/or run from the Start/Run.

[hiran]

Another caveat I had to learn about:
The working directory seems to matter when you start Oolite.

[...] But on Windows, if you run oolite.exe from any other directory than oolite.exe's parent the game will terminate. No log message, no console message and no window will ever acknowledge that the program has run at all.

You are right.
It is also true I never even thought to try running Oolite from command line in Windows.

For those interested, in order to reproduce this:
1. start cmd.exe
(in Command Prompt window)
2.

Code: Select all

%SystemDrive%

3.

Code: Select all

cd %USERPROFILE%

4.

Code: Select all

<fully_qualified_path_to>\oolite.exe

(e.g. z:\mygames\oolite\oolite.app\oolite.exe)

Confirmed under Windows10 and Wine.
In both cases, starts all right by double clicking and/or run from the Start/Run.

I ran into the problem since OoliteStarter invokes Oolite programmatically. And my code was successfully running on Linux like this:

Code: Select all

1            List<String> cmd = new ArrayList<>();
2            cmd.add(configuration.getOoliteCommand());
3            log.info("executing {}", cmd);
4            ProcessBuilder pb = new ProcessBuilder(cmd);
5            pb.redirectOutput(ProcessBuilder.Redirect.INHERIT);
6            pb.redirectError(ProcessBuilder.Redirect.INHERIT);
7            Process p = pb.start();
8
9            p.waitFor();

To make it run in Windows I had to add just one line - the one that sets the working directory (the not-numbered line):

Code: Select all

1            List<String> cmd = new ArrayList<>();
2            cmd.add(configuration.getOoliteCommand());
3            log.info("executing {}", cmd);
4            ProcessBuilder pb = new ProcessBuilder(cmd);
            pb.directory(new File(configuration.getOoliteCommand()).getParentFile());
5            pb.redirectOutput(ProcessBuilder.Redirect.INHERIT);
6            pb.redirectError(ProcessBuilder.Redirect.INHERIT);
7            Process p = pb.start();
8
9            p.waitFor();

I had investigated it via the command line, just as you described.
And for everone who thinks doubleclicking works as well: Windows configures the current working directory per default as the one containing the executable. You can check when you configure a shortcut. Right-click it, edit the properties and you should be able to configure the target and the working directory.

You can see it in this picture: [img]about:blank[/img]
Mind the fact that there is a "Target" (the executable) and another field labelled "Start in".

[another_commander]

Confirmed from me as well. Can't believe that this has gone unnoticed for more than ten years!

I think I have a fix though. Can you please test this executable? https://we.tl/t-X3SFuWdypr
It works perfectly under Powershell and almost perfectly under cmd.exe for me. By perfectly I mean that it works from any folder and with both absolute and relative paths. On cmd.exe it seems that relative paths still have an issue, but given that Powershell works, I would dare suggest a potential problem with cmd's path handling.

Anyway, if you can let me know how this one goes for you, we should hopefully be able to commit the fix soon.

[hiran]

Confirmed from me as well. Can't believe that this has gone unnoticed for more than ten years!

I think I have a fix though. Can you please test this executable? https://we.tl/t-X3SFuWdypr
It works perfectly under Powershell and almost perfectly under cmd.exe for me. By perfectly I mean that it works from any folder and with both absolute and relative paths. On cmd.exe it seems that relative paths still have an issue, but given that Powershell works, I would dare suggest a potential problem with cmd's path handling.

Anyway, if you can let me know how this one goes for you, we should hopefully be able to commit the fix soon.

I downloaded your executable into my VirtualBox VM and overwrote the existing file. When running it with a relative path like this

Code: Select all

C:\Users\User>\Oolite\oolite.app\oolite.exe

I get no UI, no error message but the next prompt.
However in the logfile I see

Code: Select all

Closing log at 2023-06-27 21:02:20 +0000.

However when I cd into the application's directory and run it like

Code: Select all

C:\Oolite\oolite.app>oolite.exe

I still do not see any error message or window. But in the logfile I see a lot more now:

Code: Select all

Opening log for Oolite version 1.90 (x86-64 test release) under Windows 10.0.22621.1848  64-bit at 2023-06-27 14:04:25 -0700.
Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz 4 processors detected. System RAM: 8179 MB (free: 5897 MB).
Build options: OpenAL, GLSL shaders, new planets, JavaScript console support, OXP verifier, localization tools, debug GraphViz support, JavaScript profiling.

Note that the contents of the log file can be adjusted by editing logcontrol.plist.

14:04:25.763 [dataCache.rebuild.datesChanged]: Cache is stale (modification dates have changed). Rebuilding from scratch.
14:04:25.788 [sound.initialization.error]: Failed to open default sound device
14:04:25.789 [sound.init]: Sound system disabled.
14:04:25.792 [display.mode.list.native]: Windows native resolution detected: 1024 x 768
14:04:25.822 [rendering.opengl.state]: Incorrect OpenGL state in -[MyOpenGLView initSplashScreen] (line 801)->OOSetOpenGLState
14:04:25.822 [rendering.opengl.state]: Expected previous state: <canonical initial state>
  14:04:25.822 [rendering.opengl.state]: GL_ACTIVE_TEXTURE should be ENABLED but is ENABLED.
  14:04:25.822 [rendering.opengl.state]: GL_CLIENT_ACTIVE_TEXTURE should be ENABLED but is ENABLED.
14:04:25.822 [rendering.opengl.badExtension]: ***** An uninitialized OpenGL extension function has been called, terminating. This is a serious error, please report it. *****

Closing log at 2023-06-27 14:04:25 -0700.

Yes, I have not fixed the OpenGL problem. But with the path fix I would have expected similar behaviour in both cases, which I did not see.

Edit: I just noticed that I may have patched Oolite 1.90 with your executable. Does that make any sense?

[another_commander]

cmd.exe has issues with relative paths. Have you tried the same test under PowerShell?