All settings saved and xr simulated

Two things.

1. The settings all work as expected now

1. I found an amazing Godot add-on called "XR Input Simulator". But I almost didn't.

I did know a VR simulator for Godot existed, but when I went looking for it all I could find was a Meta Windows/Mac only OpenXR XR Simulator :(

What I found out recently is that the original add-in re-branded as XR Input Simulator . You just install the add-on from the Asset store, then add the single script to your Autoloads and when you start up your game you can use the mouse and keyboard to navigate, no headset required!!

I am in the kernel-ish

Continuing from yesterdays post .

Ugh! Might help if I actually posted what was actually added.

This driver supports graphics boards with the nVidia chips, from TNT
through early GeForce generations (NV4–NV2x: Twintor, Twintor2, Celsius,
Kelvin).
Later architectures (Rankine and newer) are not reliably supported.
For very old chipsets, such as the RIVA128, use rivafb.
If unsure, say N.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/video/fbdev/Kconfig

I really should not be this prideful of such a small change... but

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/video/fbdev/Kconfig?id=ea11284a2be6ce44d4c091d737a4440504cff33d

I am in the kernel

My contribution is part of the Linux kernel!

So did I fix a security issue, write a driver, submit a patch? Not exactly.

Being the die hard Gentoo fanboy that I am, I have to regularly rebuild the kernel from scratch and that involves going through hundreds of options and trying to select the right ones.

Failure to do so results in a machine that cannot boot or in my case crashes during boot. It didn't actually crash but it sure did look that way.

When I analysed my Kernel options I found the culprit was worded in a way that meant I had chosen it, when in fact it should be excluded. So I set about changing it so no one else makes the same mistake in the future.

The option at fault was CONFIG_FB_NVIDIA and the wording made it very clear I should enable it.

This driver supports graphics boards with the nVidia chips, TNT and newer. For very old chipsets, such as the RIVA128, then use the rivafb. Say Y if you have such a graphics board.

Note the and newer . I have a newer NVidia card so I *should * enable it?

Enabling it and booting the new kernel resulted in a list of messages as I expect, but then just stopped after an OK message about logical disk manager

This had me hunting for sometime for disk issues. The real issue was that this was the last output before switching to the NVidia framebuffer driver, which failed silently.

Fast forward and I did some research on Nvidia codenames, this setting and release dates from NVidia.

The references I used to confirm the Nvidia devices affected are

List of devices documented in the kernel code between lines 1228-1277 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/video/fbdev/nvidia/nvidia.c?h=v6.19.6

with more human readable extraction available at https://cateee.net/lkddb/web-lkddb/FB_NVIDIA.html

and the code names for all Nvidia cards are here https://nouveau.freedesktop.org/CodeNames.html

Then I tracked down the correct maintainers mailing-list address and sent a .patch file.

It didn't do quite so well as the response was that attachments are not allowed and that there was bad formatting in the patch.

At least they were helpful and I was able to create a new patch and inline it into a second email and a week later it was accepted.

I checked and it is now in the official source tree!

Oh and that formatting issue did catch me out because...

Kconfig help text should be indented with one tab + 2 spaces, not with 4 spaces.

I really wanted to stop future users reading the "and newer" and enabling it on an unsupported card.

Saving the Ducks

Having completed the fun parts of phase I of the duck Duck Mine VR experience I found I needed to save the settings the user had made.

This should have been easy, or at least straightforward. Godot exposes ResourceSaver and ResourceLoader for this purpose. They work on .tres resource files and are the internal way Godot handles data resources.

I expected to be able to pass in a Godot class instance and save all the properties... it was not that easy.

First off the class has to extend Resource . That is quite reasonable as is this next one.

The properties to be saved must be flagged as @export . Then it gets a little more tricky. Any custom type e.g.

@export var saved_themes: Array[ThemeItem]

must have all its internal properties also set to @export , not to mention it also has to extend Resource

Now we get to the annoying requirements.

Properties must not have defined default values (fails silently).

Classes must not have required fields in an _init function (fails when trying to load data).

Any non @export properties MUST appear after all the @export properties (fails silently).

And my favourite, default values for base types are not saved. So any int set to 0 or string set to empty "" and any enum using the first possible value are just skipped. Very confusing when you are trying to debug what is and is not saving.

I hit every one of these hard! I had all my data set up and working, but with helpful defined default values and _init functions to build new instances. It would have be most helpful if so many of these issues were surfaced in detectable errors instead of some bits working and others not.

Any hoo, it is almost time for Phase II, not sure what to do about sound yet. I added in the controls for volume...