Oolite Bulletins

. . on Windows. I suspect it's a file association problem. The output of the verifier used to open in (shudder . .) WordPad but now no output opens anywhere, though the terminal (or batch) verify command gives no errors. I've still got WordPad installed. Any ideas?

Works as expected here. Make sure that the path to the OXP is correct and that you are verifying an OXP and not an OXZ.

I think the problem I have is that oolite.exe (I am on Windows) is not running from the command line (be that command line admin or not, and be it the standard shell or a third-party one).
with or without arguments, does nothing (!).

Strange. Works fine here. Are you sure you are running the exe from the oolite.app folder?

Yep, I am running it from within that folder. I thought it might be a permissions problem, but I can't see any permissions that would cause the problem.

Is there some switch for Oolite that will display version info, or something? If so, I could try that.

I've found a relevant error message, in the form of a file called 'stderr' in the Oolite .app folder when I try to run Oolite from the command line. Here are the contents of that file:

oolite.exe: Uncaught exception NSInternalInconsistencyException, reason: NSBundle.m:1145 Assertion failed in NSBundle(instance), method mainBundle. NSInternalInconsistencyException

Reinstallation of Oolite did not help. Might this be some sort of library problem?

EDIT: I have a process manager, called ProcessLasso, and I'd told it to limit the number of Oolite processes to 1. Disabling that limitation enabled running Oolite from the command line, with the full path; that had not worked before, but it worked now. Also - good - running the OXP verifier, with the full Oolite path, now works. However, running Oolite.exe without a path (and with or without the verifier switch), and in the oolite.app folder (and with ProcessLasso completely disabled), still produces the error mentioned above.

In short: I've got the verifier to work, but the oolite executable will not work in any way if not run with a path to that executable.

Getting back to this, I have replicated the issue of the game not launching from the command prompt on a few Win10 systems. However, in most cases that I have tried, it has worked correctly. @UK_Eliter: What is your exact version of Windows? I need to know the build number version that is seen when you go Start->Settings->System->About and whether your Windows is Home, Pro, Enterprise or other edition.

Here is the summary of my attempts to run the game (latest trunk in all cases) from the console just by typing the executable name and the results obtained: The failure to launch seems to be due to the executable not being able to retrieve from the OS the full path it's being run from. My understanding of this is that either cmd.exe has been broken in some way in Win10 builds 15063 and later, or it is broken in the OS's Home Edition. In any case, it seems that this is a Win10 issue and not an Oolite thing. The fact that versioning in Win10 is so darn complicated does not help much either.

Solutions (oir rather, workarounds until cmd.exe gets unbroken in the future):
- As you have already found out, type the full path to the exe in the command line. A bit cumbersome, this one.
- Launch cmd as Administrator. You will find that this makes it work fine regardless of Windows version. Still, you should not have to run applications as administrator unless REALLY required, so I think I'd rather just double click the exe and launch it normally (or run it from the Run dialog (Win+R) if i want to pass parameters to it).
- Use Powershell instead of command prompt. Powershell is already replacing cmd in latest Windows builds, so i guess sooner or later you'll have to get to use it anyway. Good news is that typing .\oolite in its prompt works just fine everywhere. OXP verifier works too. I would say that this is probably the closest we have to a solution so far.

another_commander wrote: ↑Mon Dec 18, 2017 10:29 am

Good news is that typing .\oolite in its prompt works just fine everywhere. OXP verifier works too. I would say that this is probably the closest we have to a solution so far.

Nice and Linux-y! However, I still use cmd as against powershell. Perhaps I'll need to look into getting the latter to substitute automatically for the former.

> @UK_Eliter: What is your exact version of Windows? I need to know the build number version that is seen when you go Start->Settings->System->About and whether your Windows is Home, Pro, Enterprise or other edition.

Windows 8.1 Pro x64. Build (you weren't asking me to use . . Metro, were you, another_commander?) 9600.18730.amd64fre.winblue_ltsb.170613-0600