Oolite Bulletins

Works well here too. Log is clean. Good work!

EDIT: Actually, no. The second time I ran it (without starting with <shift>), I got a 'ooliteDeployment.exe has stop working message from my Windows 8. (And the same goes for the third time I ran it, this time with <shift> again.

UK_Eliter wrote:

EDIT: Actually, no. The second time I ran it (without starting with <shift>), I got a 'ooliteDeployment.exe has stop working message from my Windows 8. (And the same goes for the third time I ran it, this time with <shift> again.

Do you have any logs from the times that it failed, including any stderr.txt remains? Did it succeed starting again after the second crash attempt? Is the crash reproducible with a specific set of OXPs and if yes, which one?

@another_commander:

ah, sorry, false alarm - and I didn't realise I'd actually posted that. I was causing the problem - by having the 'start in' text of the oolite exe still set to the 32-bit version. The lesson is: make a new shortcut! Since I've done that, everything has been fine.

Works well here:

Windows 7 Ultimate SP1
8GB RAM
Intel Core i7 2.93GHz
GPU NVIDIA GeForce GTX460 768MB

One observation, though, in case it matters. On the "Select Commander" screen, it appears that the 64-bit oolite.exe uses the original oolite.app\oolite-saves folder by default, whereas the ooliteDeployment.exe looks in oolite_x64.app\oolite-saves (unless I've done something odd to confuse matters). You can easily see which has been selected from the "Hold Ctrl and press Return to open parent folder" message at the bottom of the screen.

In actuality I have adopted this experimental version as my main operational version of Oolite as it makes sense to have a 64 bit version for a 64 bit machine.

I've tried the 64 bit oolite.exe (not sure what the ooliteDeployment.exe is) and it works well on:

Windows 7 professional SP1
Intel i7 3770K
8 gb memory
Nvidia GTX 560Ti

Only issue (which may be a coincidence but not seen it before) is the error in the log file:

13:20:25.288 [ai.message.receive]: AI Freighttrain_AIs.plist for Traction Engine 686 in state 'GLOBAL' receives message 'COLLISION'. Context: unspecified, stack depth: 0
13:20:25.288 [ai.message.receive]: AI Freighttrain_AIs.plist for Traction Engine 686 in state 'GLOBAL' receives message 'COLLISION'. Context: unspecified, stack depth: 0
13:20:25.289 [ai.message.receive]: AI Freighttrain_AIs.plist for Traction Engine 686 in state 'GLOBAL' receives message 'COLLISION'. Context: unspecified, stack depth: 0
13:20:25.289 [ai.message.receive]: AI Freighttrain_AIs.plist for Traction Engine 686 in state 'GLOBAL' receives message 'COLLISION'. Context: unspecified, stack depth: 0
13:20:25.289 [ai.message.receive]: AI Freighttrain_AIs.plist for Traction Engine 686 in state 'GLOBAL' receives message 'COLLISION'. Context: unspecified, stack depth: 0
13:20:28.023 [ai.takeAction]: Traction Engine 686 to take action setStateTo: SETUP_FLIGHT
13:20:28.023 [ai.message.receive]: AI Freighttrain_AIs.plist for Traction Engine 686 in state 'GLOBAL' receives message 'EXIT'. Context: changing state, stack depth: 1
13:20:28.023 [ai.message.receive]: AI Freighttrain_AIs.plist for Traction Engine 686 in state 'SETUP_FLIGHT' receives message 'ENTER'. Context: changing state, stack depth: 1
13:20:28.023 [ai.takeAction]: Traction Engine 686 to take action setDesiredRangeTo: 3000000.0
13:20:28.023 [ai.takeAction]: Traction Engine 686 to take action setTargetToRandomStation
13:20:28.024 [ai.takeAction]: Traction Engine 686 to take action rollD: 10
13:20:28.024 [ai.message.receive]: AI Freighttrain_AIs.plist for Traction Engine 686 in state 'SETUP_FLIGHT' receives message 'ROLL_2'. Context: rollD:, stack depth: 2
13:20:28.024 [ai.message.receive]: AI Freighttrain_AIs.plist for Traction Engine 686 in state 'SETUP_FLIGHT' receives message 'STATION_FOUND'. Context: handling deferred message, stack depth: 0
13:20:28.024 [ai.takeAction]: Traction Engine 686 to take action setDesiredRangeTo: 10000.0
13:20:28.024 [ai.takeAction]: Traction Engine 686 to take action setDestinationToTarget
13:20:28.024 [ai.takeAction]: Traction Engine 686 to take action setStateTo: HEAD_FOR_RANDOMSTATION
13:20:28.024 [ai.message.receive]: AI Freighttrain_AIs.plist for Traction Engine 686 in state 'SETUP_FLIGHT' receives message 'EXIT'. Context: changing state, stack depth: 1
13:20:28.024 [ai.message.receive]: AI Freighttrain_AIs.plist for Traction Engine 686 in state 'HEAD_FOR_RANDOMSTATION' receives message 'ENTER'. Context: changing state, stack depth: 1
13:20:28.024 [ai.takeAction]: Traction Engine 686 to take action setTargetToLastStation
13:20:28.024 [ai.takeAction]: Traction Engine 686 to take action setDesiredRangeTo: 10000.0
13:20:28.024 [ai.takeAction]: Traction Engine 686 to take action setDestinationToTarget
13:20:28.024 [ai.takeAction]: Traction Engine 686 to take action checkCourseToDestination
13:20:28.024 [ai.takeAction]: Traction Engine 686 to take action scanForHostiles
13:20:28.024 [ai.message.receive]: AI Freighttrain_AIs.plist for Traction Engine 686 in state 'HEAD_FOR_RANDOMSTATION' receives message 'ENERGY_FULL'. Context: handling deferred message, stack depth: 0
13:20:28.157 [ai.takeAction]: Traction Engine 686 to take action setTargetToLastStation
13:20:28.157 [ai.takeAction]: Traction Engine 686 to take action setDesiredRangeTo
etc etc

The experimental package has been updated to v0.2, with a new download link (see first post in this thread). The only difference to the original is the replacement of the faulty gnustep-base-1_20.dll, which causes the crash on exit, with the one that works. If you have already downloaded the first version of the package and the fixed dll as separate download, you do not need to do anything.

@ DGill: there's no error, just some excessive logging of normal operations.

I'd say that someone forgot to remove the AI logging from their OXP when releasing it. And that someone would be the author of the Freighttrain OXP.

Ok, thanks

Is it possible that the new gnustep-base-1_20.dll has disabled/unmapped the function keys? I'm pretty sure they were working when I first tried the 64-bit Oolite, but they aren't now. The numeric keys still work as normal.

Hurray!

I have literally been waiting for this for years.

Great work!

Off to test ...

Lestradae wrote:

Hurray!

I have literally been waiting for this for years.

Great work!

Off to test ...

Welcome back L. Hope you are well and ready for some 64-bit Ooliting!

JD wrote:

Is it possible that the new gnustep-base-1_20.dll has disabled/unmapped the function keys? I'm pretty sure they were working when I first tried the 64-bit Oolite, but they aren't now. The numeric keys still work as normal.

I can't see how this could have happened. Function keys work fine on my system with the v0.2 experimental. Do you still have the buggy gnustep dll handy by any chance? If so, can you try putting it back and seeing whether function keys get re-enabled? This is strange indeed. What is it exactly that you are trying to do when you find that function keys don't work for you?

Hi A_C. I'm just trying to switch to the various screens and views that the function keys normally call up when docked or in flight.

It looks as though I have a backup copy of the older dll. I'll have a play this evening and see how it behaves.

OK. Also, please make sure to test without any OXPs too, in case you haven't already done so.

Are any of the other testers experiencing problems using the function keys with v0.2 Experimental?