Add Velocity calculation logic and GUI toggle (end-to-end MVP).

[M1DNYT3]

This PR completes velocity transmission end-to-end, adding RPC settings and a GUI toggle on top of the foundation from #1754.

What's added:

• Protobuf velocity transmission via ProtobufBridge, per-tracker
• RPC settings support - toggle persists across restarts
• GUI toggle in General Settings with i18n

Toggle's GUI Path:
Settings > General > Tracker Settings > Toggle is at the very bottom of the section.

Technicalities:
Most of the line count (~400) comes from regenerated ProtobufMessages.java. The handwritten change itself is small.

Depends on SlimeVR/SolarXR-Protocol#202, should be merged only after the submodule is updated to the tracked HEAD.

Addresses the issue: #25

[M1DNYT3]

Force pushes in history are changes made by spotless.
For some reason, one application wasn't enough for it to fix all the issues in Tracker.kt, so I had to push it twice, and I didn't want to make 2 separate commits for spotless alone.

[M1DNYT3]

At some point, I had a conversation with @ButterscotchV in DMs, and there was a recommendation expressed to ship the whole feature (Implying a toggle, nothing overkill) in one PR.

The description is edited accordingly to reflect each affected part of the code.
The handwritten part (meaning not regenerated flatbuf, and not regenerated ProtobufMessages) follows the existing code architecture 1:1 and reuses the methods, styles, and classes, where necessary.

[M1DNYT3]

I had some additional feedback from @ButterscotchV in DMs, addressed it all + rebased to the latest main + also did some changes of my own.

Feedback changes:

• drop applyVelocityPolicyTo() in VRServer.kt; initially made for expandability, but turned out to be redundant because VRConfig.applyVelocityPolicy() already covers expandability.
• replace System.nanoTime() with Kotlin's TimeSource; self-explaining, did precisely that.

My own improvement:
Noticed that I forgot to wire hasVelocity instead of allowVelocity in the ProtobufBridge.kt; the former was created for a safeguard to not send anything if we don't have any velocity in the tracker. Technically, both calls would result in the same behavior, but hasVelocity follows architecture better and explicitly states that there has to be something for it to be sent, whereas allowVelocity simply states whether the toggle is on or off.

[M1DNYT3]

Review changes were shipped and tested E2E with SteamVR.

One thing to note. Jitter is still noticeable. I may think of a one-euro filter or some velocity smoothing added, but I suggest that to be a separate PR once this one is shipped.

[ButterscotchV]

Looks fine, SolarXR needs to be merged/fixed before this PR.

[M1DNYT3]

Hey @ImSapphire, the last CI run was failing, but not because of my code.
https://github.com/SlimeVR/SlimeVR-Server/actions/runs/25044370421/job/73885369136

This step failed on the GCC lib installation.

I also rebased my branch to the current state of main to make it easier to merge.
If the GCC issue was a one-off or already fixed in main, can you re-run the CI?
Much appreciated!

[ImSapphire]

yeah, unfortunately that CI step is a bit flaky right now, due to Canonical being the target of a sustained DDoS attack over the past few days. I've let the CI run again

[M1DNYT3]

Hi @Erimelowo and @loucass003,

Just wanted to give a quick heads up since you both are showing as the final decision makers in the chain.
CI is all green, solar-xr submodule is merged into main, the branch is rebased to the current main, I did a smoke test after a rebase as well to verify both GUI and Server are running, and nothing is crashing during the operation around the areas that my changes affected.

Anything else you may need from me, or I just need to just wait for the merge to take place?
Thank you in advance!

[loucass003]

sorry im just a bit slow to process stuff that i am not 100% in the loop.
Can someone send a screenshot of how the gui part look?

[M1DNYT3]

sorry im just a bit slow to process stuff that i am not 100% in the loop. Can someone send a screenshot of how the gui part look?

Sure thing.
The green outline highlights the part that this PR adds.

One toggle, off by default. Nothing else. Either transmits velocity to SteamVR or not.

Velocity is derived from position delta over time, following the tick rate of the updates that the server sends. Micro-jitter in FBT is hard to deal with, so me and @ButterscotchV agreed that this PR will ship just the core functionality and figure out the jitter later. Potentially can be fixed by a one-euro filter or smoothing to reduce collision with SteamVR's prediction.

[loucass003]

I will also note that i would love to have you around for the server rewrite that is going on soon. Since the feature is gonna have to be re-implemented from zero because of the massive architecture changes. #1798

[M1DNYT3]

I will also note that i would love to have you around for the server rewrite that is going on soon. Since the feature is gonna have to be re-implemented from zero because of the massive architecture changes. #1798

Yeah, sure, no problem at all, either ping me on GitHub or on Slime's Discord server (nickname matches the GitHub one), I'm totally up for supporting the code in the near future.