I've been using the x64 build basically exclusively since I started playing Oolite (last week) on 2 different laptops with no discernable problems. I'm stumped about the difference between Oolite.exe and OoliteDeployment.exe - probably something obvious I just haven't noticed yet. I do know that on the lesser of the two machines the plain Oolite exe just flashes up the splash window for a second then nothing else whereas the deployment exe plays normally.
The regular build plays so badly on there that I've got low detail and wireframe permanently on and sometimes when I paste my ship on the side of a docking bay and explode all exe versions crash so I don't think that's a specific x64 issue!
One question: is there any changes in the save games between x86 and x64?
Save game file compatibility - given how long it takes to get to Elite and given that's nowhere near the "end of the game" - is one of the crucial things: your save game will work on any computer which can run Oolite, and you will be able to take a save game made in any previous release and load it in the latest release without errors or data loss.
OoliteDeployment is the version without various extra bits of debugging support, testing code, etc. It should also be at least somewhat faster and less memory-heavy than the other version. Unless you're writing OXPs (or a few other minor cases) you should stick with the deployment build.
I've just found an error in my most recent log file, and thought it might be worth posting here. The relevant chunk (which I quote whole, i.e. there is no abridgement within this chunk) is as follows:
I'm running the '0.3' version. I didn't get a crash. So the only evidence that I've seen that something is wrong (aside, perhaps, from a bit of in-game stutter) is this log material.
I'm running the '0.3' version. I didn't get a crash. So the only evidence that I've seen that something is wrong (aside, perhaps, from a bit of in-game stutter) is this log material.
I have a guess at what this might be - a few questions to see if that's plausible:
1) For how long had you been playing (without dying) when the error occurred?
2) How many OXPs do you have installed? (no need for the full list)
3) What is your computer's CPU?
1) For how long had you been playing (without dying) when the error occurred?
2) How many OXPs do you have installed? (no need for the full list)
3) What is your computer's CPU?
1: About 40 minutes, I think, and in several systems including interstellar space.
2: Er, 160! [Edit: shocked by this, I've had a cull. I was ruthless. Now I have . . only . . 153!]
3: Intel Core 2 Quad Q6700 @ 2700 MHz.
That will have been a Javascript garbage collection then, I think. The way Javascript manages memory leaves it wanting to pause for a little while every so often to clean up, which if it happens in the middle of a scripting task on a relatively old CPU causes a sufficient pause to run out the time limiter. With 40 minutes of continuous play and lots of OXPs, probably most of which do something with Javascript even if it's just "add some more ships with a default ship script", this seems plausible.
Possibly you notice it now on 64-bit if you haven't on 32-bit because 64-bit code does use a little more memory than 32-bit, so the Javascript memory cleanup will need to happen slightly more often than before.
In the 1.79 code the game forces collections at witchspace entry and docking (where a short pause is more acceptable), and tries to schedule the in-flight ones (which are then rarely needed) while JS code is not actively running. So you shouldn't see this problem in that version, when it's available.
Ahh.. that would also explain the regular 'script timeout' errors I see on the antique machine that is my main Oolite computer.
Most games have some sort of paddling-pool-and-water-wings beginning to ease you in: Oolite takes the rather more Darwinian approach of heaving you straight into the ocean, often with a brick or two in your pockets for luck. ~ Disembodied
Ahh.. that would also explain the regular 'script timeout' errors I see on the antique machine that is my main Oolite computer.
Well ... I wouldn't also rule out inefficient scripting, if it seems to regularly happen in the same (parts of the same) OXPs. Additionally, the test release of Oolite has a much shorter script timeout, if you're using that.
Additionally, the test release of Oolite has a much shorter script timeout, if you're using that.
Nope.. bog-standard 32-bit deployment builds, here.. Cabal_Common_OXPStrength seems to be the main offender. CPU is an old Athlon XP2500+.
Most games have some sort of paddling-pool-and-water-wings beginning to ease you in: Oolite takes the rather more Darwinian approach of heaving you straight into the ocean, often with a brick or two in your pockets for luck. ~ Disembodied
This is a question that has its roots in ignorance.
For what reason would one choose the 64 bit version of Oolite over the 32 bit version when running on a 64 bit operating system?
FWIW, my system specs:
Intel Core i7-2720QM @ 2.20GHz processor
16GB RAM
256 SSD (hosts OS)
512 SSD (hosts programs when I remember to redirect the installation location)
Windows 8.1 Enterprise x64
Commander Bugbear
Cruising chart 5 in a Boa Class Criuser: Quantum Pelican I
Vigilante, trader, gems and precious metals hoarder.
Black Monks bothering performed at no extra charge.
For what reason would one choose the 64 bit version of Oolite over the 32 bit version when running on a 64 bit operating system?
The main reason would be that the x64 version does not have memory access limitations. The x86 version can access up to about 3GB of memory. In practice, it will be very difficult to reach such heavy memory requirements, unless you decide to load every existing OXP under the sun (btw, this has been tried by someone in the past). Theoretically, on the x64 flavor you can load as many heavy OXPs as you like and they will still work even if their combined memory requirement exceeds 3GB or more.
On a more practical level, the 64-bit flavor of the Windows port is confirmed to be between 20 and 25% faster than the 32-bit one. This is not because of bitness, but because the game executable and all supporting libraries have been built with maximum optimizations enabled and are tuned for the more recent CPU types.
Commander Bugbear
Cruising chart 5 in a Boa Class Criuser: Quantum Pelican I
Vigilante, trader, gems and precious metals hoarder.
Black Monks bothering performed at no extra charge.