Search results

The first thing I would do is test in a clean Orbiter 2016 installation with just the XR vessels and XRSound. If you can duplicate the CTD in that configuration, please paste the scenario file. Otherwise, you can continue testing by installing one additional add-on a time, testing each time...

I found the relevant parts of the build log and spliced them back together: 31>------ Rebuild All started: Project: XRSound_dll, Configuration: Debug x64 ------ 31>Building Custom Rule D:/GitHub/orbiter/Sound/XRSound/XRSound/src/XRSoundDLL/CMakeLists.txt 31>DefaultSoundGroupPreSteps.cpp...

Thanks for the information! The key point I was missing was needing to run the CMakePredefinedTargets -> INSTALL project instead of just "Rebuild All". To sum up, I was successfully able to build a working Orbiter installation without using (the buggy) Ninja CMake in the latest VS 2019 patch...

Today after I installed the version 16.11.1 VS 2019 update and went to open the Orbiter folder again, CMake appears to finish, but the Project and Build folders in VS 2019 remain disabled, with the menu option "Cancel CMake Cache Generation" stays enabled indefinitely. i.e., VS 2019 appears to...

FWIW, I agree -- it's a lot easier for end users to post a log file than try to copy down the cryptic stuff that pops up on an assert's dialog box, IMO. Another similar approach is to define your own macro (maybe named "PRODUCTION_ASSERT(...)"?) that invokes your own custom, static function...

For what it's worth, in my experience and from what I've read, the contents of the assert macros should never contain code that needs to run in production. i.e., the assert documentation says this: The contents of the (uppercase) ASSERT macros in Visual Studio are only ever compiled into debug...

No worries, I just pulled the latest change and tested it. I needed to make a tweak to the new macro's default value so it works out-of-the-box, and I just pushed the commit to the XRSound-lib-linktest branch. So now it should be ready for merge! (y)

Yes, both the Release and Debug binary packages run fine for me. I checked the Orbiter.log from that instance, and the DLLs that work are: 000000.000: D3D9 DLLs : C:\WINDOWS\SYSTEM32\d3d9.dll [v 10.0.19041.928] 000000.000: : C:\WINDOWS\SYSTEM32\d3dx9_43.dll [v...

I have the x64 D3D9 client built and linked successfully now, but I'm having trouble running it from my x64 Orbiter install. I activated the module successfully, but it fails during load with this: I think it needs the 64-bit DX9 runtimes? I installed the runtimes from...

So you were right -- CMake from the command line did end up in a copy loop of some sort: I wanted to delete my D3D9Client folder today, and got an error from the path being too deep. It turns out CMake from the command line created a (very very long) path like this...

Thanks for the tip on searching higher up in the log! There was indeed an error about 30 lines up (highlight added): In case anyone else hits this in the future, here is how I fixed it: Deleted the four build output folders under orbiter\out\build. Selected build target x86-Debug in Visual...

Yeah, definitely a challenge! :) When I pull those latest changes to CMakeLists.txt, the build fails with a cryptic error for me whenever I try to build Orbiter x86 Debug or Orbiter x86 Release (both x64 builds succeed, however). I triple-checked that it isn't trying to build the documentation...

Sure! So I pulled the latest changes from the trigger_sound_build_cmake branch and built the x86-Debug version of the XR1, but it appears that the XRSoundD.lib versions that are being built by both Orbiter x86-Debug and Orbiter-x86-Release is the 64-bit version of XRSoundD.lib: So then I...

Just to double-check, you are building in the trigger_sound_build_cmake branch, right? The latest commit in that branch I have is hash 68f6967e0afd17812d4366f7c5603fc3356da439 from 6-Aug-2021 at 17:14:51. In any case, since it's clearly working for you, that means the releases will have the...

XR crew is (was) managed by UMMu, but UMMu is not compatible with Orbiter 2016, so I had to temporarily disable that in the XR vessels. However, there is an open-source replacement for UMMu in development, oMMU. Once that is ready, I will update the XR vessels to use it.

Hmm, I'm still getting the result of both XRSound.lib and XRSoundD.lib both being the same build type (either both Debug or both Release versions) depending on which Orbiter target I build. I tested the generated libraries by linking the XR1 with the generated XRSound.lib for Release and...

Well, it's getting closer, but not quite there yet. :) (Note that I'm linking with the x86 Orbiter-generated XRSound.lib, since I don't have the XR vessels ported to x64 yet.) The XRSoundD.lib is now a Debug version, so that's good! However, now XRSound.lib is also a debug version, albeit with...

Are there any configuration steps necessary in order to build the D3D9 client using CMake? What I did was: Clone that latest D3D9 repo to a new folder: git clone [email protected]:jarmonik/D3D9Client.git Run "C:\Program Files (x86)\Microsoft Visual...

Are you running "Orbiter.exe", or are you running "Orbiter_ng.exe"? If you run Orbiter_ng.exe (which stands for "Orbiter no graphics"), you won't have a Video tab until you install the D3D9 graphics client for Orbiter and activate the D3D9 module in the "Modules" section. Orbiter.exe, on the...

Welcome to Orbiter-Forum! From looking at the log, I noticed this: So it appears that Orbiter is configured for 16-bit color mode and to not use "T&L" (Transform & Lighting). The first thing I would do is go to the Video tab in the Orbiter Launchpad and select "Direct3D T&L HAL" to enable...