Search results

The official release of Orbiter 2016 - both ZIP and MSI versions, along with the optional high-resolution packs. You can find more information about these files from http://orbit.medphys.ucl.ac.uk/download.html - the content here is just to protect against bit-rot in those links.

The official release of Orbiter 2016 - both ZIP and MSI versions, along with the optional high-resolution packs. You can find more information about these files from http://orbit.medphys.ucl.ac.uk/download.html - the content here is just to protect against bit-rot in those links.

The official release of Orbiter 2016 - both ZIP and MSI versions, along with the optional high-resolution packs. You can find more information about these files from http://orbit.medphys.ucl.ac.uk/download.html - the content here is just to protect against bit-rot in those links.

Yes, that is correct. All source development has switched over to git.

Yes, essentially that. I plan to have a final x86 release that incorporates bug fixes and the handful of feature enhancements since Orbiter 2016 and retains backward compatibility as much as possible. That should happen sooner rather than later. After that, the plan is to drop the 32-bit build...

Just wanted to ask if anybody has tried the latest update to VS 2019 yet in combination with Orbiter/CMake. After reports that the previous update (16.11.1) broke CMake cache generation, I've held off updating my VS installation. According to the release notes, 16.11.2 addresses that problem...

Did you take this into account?

I haven't got my copy of the Guide to hand, but this should be fairly obvious: Ensure approximately uniform anaerobic microbial growth throughout the towel (generally a given for hitchhiking towels) Moisten towel Drape over a rock of suitable size, covering all sides Wait a few days North is...

Edit Config/Sol/Marker/Common star names.mkr

But ultimately futile, I suspect. All the incoming radiation (plus anything generated on the ship) has to be re-emitted one way or the other. If not by direct reflection, then as black body radiation. You may need detectors for a longer wavelength band, but you'd still spot it.

Vantablack? Stylish, but possibly not the best choice for a spacecraft... You might have to upgrade the cooling system, and you will definitely have to fit bigger radiators ...

Yes, it looks like I missed to add the dependencies. Must have been just lucky that I didn't run into that problem myself. I have added the dependencies now and created a pull request. Could you check if this is working for you (you may have to start from a clean build directory to give it a...

Do you know which of the projects is failing? Is it something I should look into?

That doesn't sound good. I haven't yet upgraded to the 16.11.1 version, and maybe I should hold off for now. I just checked that, and while the build folder does have the Debug/Release subdirectory problems, my install folder is ok and does produce a working Orbiter setup. And if I build the...

You are right, the vertex limitation is imposed by DX7, and the Orbiter Mesh class is currently closely following that format. So once the DX7 connection is dropped, that limitation can be relaxed as well. Before that happens, I want to have one more release with x86 architecture and DX7...

That is fine as long as you are not relying on the side effect of the argument of assert() being evaluated even if the assertion is not tested. So you can do res = someFunction() assert(SUCCEEDED(res)) but not assert(SUCCEEDED(someFunction())) if you rely on someFunction() being called.

I have defined my own macros (in Src/Orbiter/Log.h: ASSERT and dASSERT). Log.h isn't currently exported to the SDK, so probably not visible to external plugin code. If it looks useful, I could copy it to Orbitersdk/include.

I finally managed to compile D3D9Client x64 and run it under Orbiter x64! Thanks for your help in getting my problems worked out. FYI, It worked straight away for me when doing a debug build, but to get it to work in a release build, I had to fix problems with _wassert and assert, by adding the...

You are correct. The required libraries will be included in the binary packages, so no need to download any additional libraries and no need to compile anything for end users. Sorry for the confusion.

There is one additional thing I could try if you are interested. Currently the user is required to download and install the irrKlang libraries manually, and to specify the path to them to CMake in order to build the XRSound module. I could try to automate this step and integrate the irrKlang...