RXP

Thank you for the additional information. Can you please post the content of the RXP log files? (see User's Manual fro file/path). Also, what about trying with a default/stock simple aircraft like the Mooney?

Hi, I've sent you a PM.

Hi David, Can you please describe in more details what do you mean with "can't be loaded in the sim"? For example, are there any error message? What are the symptoms? What actions are you doing in sequence, what are you expecting from these actions, and what is the actual outcome of these actions? PS: also can you please refrain from posting the same message multiple times? Thank you!

Isn't the building to the left a little bit melted? 🙂

Don't worry, I take no offense except that I might have failed to express myself clearly enough, therefore I'll try more! At least I believe I perfectly understand what you're trying to achieve, so let's try to find a way. You might want to think of this not from a window manager standpoint, i.e. the "active" window, or the "focus" window would be the one receiving inputs. In effect, each device is standalone and has even no knowledge it is in a window (well technically it does otherwise it wouldn't draw, but it is rendering output surface agnostic in design and can draw on 3D panel, on popup window, etc...). Or said otherwise, the window state (focus) is not a RXP gauge state itself (and actually this state is not accessible via the SDK, it is something solely handled and managed by the simulator itself). Instead, each device can be configured to receive commands from various inputs (keyboard, hardware, other gauges and modules), and each is individually binding to its own set of commands. Which means the selection/triage of what commands goes from your hardware to the simulated device must reside at the hardware level, not the simulated device level (i.e. at the source, not the destination). In the particular case of the frequencies, since the GTN or the GNS V2 are synchronizing bidirectionally with the simulator, if you flip flop the simulator COM2 for example, the RXP GTN or GNS V2 device configured with COM2/NAV2 will automatically sync the change as well on its own display. So in this particular case, if you can manage to dynamically configure the Knobster to send COM1 flip flop or COM2 flip flop commands at will, then it will work as expected too with the RXP devices. Now having said this, if you find the way to do this with the knobster, then it will be as-easy to extend this concept of dynamically changing the set of commands for more commands, including those pertaining to the rest of the GTN and GNS V2 controls. So, maybe the easiest would be for the company making the Knobster to support dynamic banks of commands at runtime to get started. If they already do, then what would remain is finding a way to swap banks based on an external signal, but in this case, if it is about detecting which window is active because you've clicked on it, it is out-of-gauge jurisdiction and solely in the hands of the simulator. At this stage, wouldn't it just be easier to use 2 Knobsters instead, and if not for the GTN and/or the GNS V2, you can still use both for many different things (OBS, CRS, autopilot altitude input, vs input, etc...). Hope this helps!

It would depend how good it is done and the material it is dithering of course, but usually, because it is a fixed screen space dithering, it might not be as good in VR when moving the head vs on a fixed monitor. Furthermore, like white noise, it is not easily filterable and in my opinion could increase aliasing, or conversely, the dithering effect could be partially reduced too much, because of the post-processing happening further down the stack in VR after the submitting the dithered image (motion smoothing, view warping, etc...). I'll tell you more about the alternative once I'm done coding and testing it though!

@BiologicalNanobot I believe most of the banding problems aren't due to using textures vs computed. I'm working on this right now with the OpenXR Toolkit and the main reason is sampling errors from a higher bit depth color into a lower bit depth gamma space one. In other words, when converting a float32 linear space color, into an uint8 gamma space one, you'll have banding no matter what.

Hi, If I understand correctly, you'd like a single hardware controller to selectively control one or the other GTN? If this is so, the problems boils down to how would you tell the knobster that at one point in time it'd send commands for COM1/NAV1 for example, and at another point in time it would be for COM2/NAV2. This in itself is not a RXP related question but a more general one: - how to bind 1 hardware device onto 2 different sets of commands dynamically. Posing the question leads to the answer: is there any way you can do this with the Knobster regardless of RXP? If so, what is the "trigger" or the "state" which determines which COM/NAV set the Knobster is controlling at any given time? Once you get a "trigger" or a "state" to look for, it will become much easier to also use this state to just bind GTN1 or GTN2 controls dynamically as well.

I honestly like the CTRL+E option for those moments I want to please myself with a flight but don't have much time ahead for the pre flight. This doesn't disqualify the intrinsic nature of a simulator to me for a simple reason: the aircraft is still intrinsically modeled from authentically recreated simulated systems, whether I manually flip a series of switches in sequence, or I let automatism doing it for me. However, I don't find the remark about FBW funny at all. As a matter of fact, I'm quite amazed of the many things they are achieving with the A320 (given the "platform" it is running onto), and I'm even a little sadden they seem to be completely left aside even though they've proven they are probably mastering the JS/HTML and the system simulations at least equally as well in my opinion (if not better) than some others who are much more privileged right now.

I thank you for your kind words and support! You can rest assured we're working on XP12 already 🙂 and we'll definitely support P3D5 and P3D6 as well* *unless they drastically change the SDK so much and they completely ignore us and don't answer our emails (or worse...)

Speaking of "way back then", we're a few weeks away from our first product release 20 years ago, the Apollo GPS. This has been an incredible journey with you all ever since and I feel privileged and blessed to have the chance to meet everyone of you virtually or in real life. I thank you for your enduring journey with RXP, and I hope we'll continue to provide you many more hours of enjoyment and authenticity with our future products!

beware with the analogy because by the current way of saying things in the forums about the choice of simulators, you'd keep both at home and continue "using" the old one while enjoying the new one... 🤣

thanks for the link! very easy to find out what they did to it: - open the uncompressed 2022_2_3__9_4_44.bmp in a paint program - zoom in, and you can see a classic Bayer 8x8 dithering in action 🙂 This looks good in their 3D screenshots but I believe there is an issue with this type of dithering when in VR. This is why I'm implementing something different and which doesn't add high-frequency components in the signal.

I didn't notice the first time I saw the pictures, you have eagle eyes! (or I'm getting too old). I'm certain they'd correct this for the release (it is a screenshot from a beta version for now). PS: why am I jumping on answering this? because amazingly, I've been working lately on this specifically to enhance the OpenXR ToolKit shaders, and I'm still gauging different techniques to find a sweet spot! 😎

Hi, Did you also enter your F1 account credentials and/or your info (address, email, CC # etc..)?

How do you define "performant" exactly? Because although there is no doubt any modern Web engine can render a simple drawing like this relatively fast, what matters is also how it behaves when there are another couple dozen gauges also rendering this kind of graphics at the same time per-frame. This quickly adds up in a simulator where each resources (CPU/GPU/RAM/VRAM/Bus) are heavily shared amongst all there is to render and compute in a single frame, every frame. So what about it? - Taking less RAM? less VRAM? - Reducing PCIe bus traffic? - Reducing CPU load overall? on 1 core? on x cores? - Scalable (i.e. you can render 10x these displays for less than 10x the resources to render 1)? And are you saying WASM+inNative can be performant to draw these things, because it is the SDK way to get access to the HTML+JS SDK but from C++?

I'm glad you've sorted this out and all is ok now! As for the popup, I'm not sure to understand the issue? The 3D instance and the popup instance are both displaying the same content alright.

update: coupons are now re-uploaded and should be working! I'm sorry for the inconvenience and thank you for your patience!

wow, I don't know what has happened but indeed, it seems all coupons are expired. I'm working on it right now and I'll update this post once updated.

Hi, I'm not sure to understand what the nature of the problem is. Is any message containing the words "License or expiry" displaying when: - loading an aircraft with the RXP GTN? - during installation with the e-commerce installer? - when downloading the e-commerce installer? Could you please detail a little bit more exactly what you're doing, which steps, leading to what outcome (eventually sharing a screenshot if this could help further)?

Hi, thanks for the heads up! I'm looking into this right away... edit: indeed there was a problem with the coupon, it shall be working now. Thank you!

The latest update includes specific changes for the latest P3D5 update which are not applying of course to the older simulator versions our product is compatible with. However, all our updates in general also include additional enhancements and corrections, either significative enough to be listed, or minor and not listed in the update notes.

@fppilot I believe the OP was in the wrong forum and I've moved it back.

@ptyler687 both the RXP GNS V2 and GTN are sharing the exact same code regarding TCAS. Are you sure you're using latest versions for both, and you've enabled TCAD on the GTN too?

What about running it then? PS: You can cross-check it is the latest installer for the latest version easily: right click the file > Properties > Details > File version number.