Skip to content

Replace START.cmd with PS1 launcher, fix installer issues, add connection diagnostics#12

Open
plyrthn wants to merge 4 commits intoKuijen:mainfrom
plyrthn:ps1-launcher
Open

Replace START.cmd with PS1 launcher, fix installer issues, add connection diagnostics#12
plyrthn wants to merge 4 commits intoKuijen:mainfrom
plyrthn:ps1-launcher

Conversation

@plyrthn
Copy link
Copy Markdown

@plyrthn plyrthn commented Mar 14, 2026

What this does

The original START.cmd had a few parser-level bugs that caused silent failures in certain setups, and was hitting the limits of what cmd.exe can do cleanly. This replaces it with a 4-line stub that hands off to START.ps1, which contains all the logic.

Both Java and Rust editions updated.


START.cmd → START.ps1

Bugs fixed in the original:

  • Paths containing (x86) (e.g. C:\Program Files (x86)\RTRP) break parenthesized if blocks at parse time — the ) closes the block early
  • %errorlevel% inside a block evaluates when the block is parsed, not when the command runs, so the gnirehtet failure check always saw 0
  • && on the High Priority line was clobbering gnirehtet's exit code before it could be checked
  • copy >NUL suppressed all output including errors, so the config copy silently failed with no message or fallback

New in START.ps1:

  • Debug log at %APPDATA%\rtrp\debug.log — screen stays clean, everything is captured for troubleshooting
  • ADB device checks at startup: unauthorized and offline states shown on screen with a message you can actually act on
  • USB speed check — warns if the headset is on a USB 2.0 port
  • Headset WiFi disabled via ADB on launch (prevents the headset routing over WiFi instead of the USB tether, which is a common cause of disconnects)
  • USB Selective Suspend disabled at launch (Windows power feature that can drop the USB connection mid-session)
  • Config copy now checks the backup source exists first and gives a real error if not
  • Gnirehtet log filtering — only WARN/ERROR lines written, drops the high-frequency connection messages that flood the log with noise
  • Restart loop on gnirehtet failure instead of just exiting
  • After gnirehtet connects, checks whether the headset's rndis0 IP is in the same /24 subnet as any PC adapter. If there's a mismatch, Virtual Desktop will cap streaming bitrate to ~60 Mbps and cause ghosting — this surfaces that as a visible warning so you know why it's happening

Installer fixes

  • OutFile "C:\Users\$PROFILE\Desktop\..."OutFile "$DESKTOP\..."$PROFILE already expands to a full path, so the original produced a broken double-expanded path at build time
  • InstallDir $PROGRAMFILES$PROGRAMFILES64 — was defaulting to Program Files (x86) on 64-bit Windows
  • File /r "C:\Users\KUIJEN\Desktop\Source\"!define SRCDIR "Source" — hardcoded dev machine path, fails for anyone else building the installer
  • Java: Execwait for the Java Runtime installer now guarded with IfFileExists — was failing silently if the Support folder wasn't bundled
  • onInstSuccess: removed Delete "$DOCUMENTS\RT-RP Config.ini" — this was wiping the user's existing config on every reinstall. START.ps1 already handles the missing-config case by copying from the backup

Happy to adjust anything. Tested the PS1 flow on a Quest 2 setup with gnirehtet-g7.

plyrthn added 3 commits March 14, 2026 13:21
START.cmd is now a 4-line stub that calls START.ps1 via PowerShell,
avoiding cmd.exe parser bugs with paths containing parentheses (e.g.
Program Files (x86)) and enabling richer scripting.

START.ps1 adds:
- Debug log at %APPDATA%\rtrp\debug.log (screen stays clean)
- ADB device state checks (unauthorized, offline) with on-screen alerts
- USB 2.0 detection warning
- Headset WiFi auto-disable via ADB to prevent routing conflicts
- USB Selective Suspend disabled at launch
- Config copy failure now shows a real error instead of silently failing
- Gnirehtet log filtering (WARN/ERROR only, drops connection flood)
- Restart loop on gnirehtet failure instead of exiting
- OutFile: replace hardcoded C:\Users\$PROFILE\Desktop with $DESKTOP
  ($PROFILE expands to the full profile path, causing a double-expanded
  invalid path at build time)
- InstallDir: $PROGRAMFILES -> $PROGRAMFILES64 (was installing to
  Program Files (x86) on 64-bit Windows)
- File /r: replace hardcoded C:\Users\KUIJEN\Desktop\Source\ with a
  !define SRCDIR "Source" so the script is portable when building
- Java: wrap Java Runtime ExecWait with IfFileExists guard so it
  doesn't fail when the Support folder isn't bundled
- onInstSuccess: remove Delete of RT-RP Config.ini - was wiping user
  config on every reinstall; START.ps1 handles the missing-config case
After gnirehtet connects, checks whether the headset's rndis0 IP is in
the same /24 as any PC adapter. If not, Virtual Desktop will cap
streaming bitrate to ~60 Mbps, which causes ghosting and compression
artifacts. Mismatch shown on screen in yellow; all detail goes to log.
@Kuijen
Copy link
Copy Markdown
Owner

Kuijen commented Mar 14, 2026

Multiple lines have been changed but remain functionally the same so I don't see why this is needed, especially since I always pack everything up to serve as a ready made package after every update.
Furthermore the RT-RP Config.ini location was very intentional because I want to make things easy, the average user may not know that appdata is even a folder, let alone know how to get there to change a setting.
The change to a different default install directory is also not needed in my opinion because it changes nothing in practice.
also there's no debug text under normal circumstances unless changed in the .cmd so I don't know where you got that from.
I'll take a look at a later date but some of these changes are just unnecessary.

Both RT-RP Config.ini and RT-RP debug.log now live in the user's
Documents folder, consistent with the existing config location and
easy to find without knowing AppData exists.
@plyrthn
Copy link
Copy Markdown
Author

plyrthn commented Mar 14, 2026

Hey, appreciate you taking the time.

The config - we did not move it. RT-RP Config.ini stays in Documents. The only thing that was ever in AppData was the debug log, which we've also moved to Documents in the latest commit - it sits right next to the config as RT-RP debug.log.

The PS1 approach - nothing changes for the user, START.cmd still exists and works the same way. The switch is because cmd.exe has a parser bug with paths containing parentheses - if someone installs to C:\Program Files (x86)\RTRP the ) silently breaks every if block before any code runs. That's exactly what happened on my friend's machine and it was hard to track down because there's no error, things just don't work. PowerShell doesn't have this problem.

The debug log - there was zero diagnostic output before. When the config copy failed, nothing happened and nothing was written anywhere. ADB device state, USB speed, gnirehtet start output, whether the config copied - none of it went anywhere. Debugging my friend's install remotely I had nothing to go on. Now all of that is captured in RT-RP debug.log without touching the screen at all.

The installer - understood you package it yourself. The two things worth keeping: $PROGRAMFILES -> $PROGRAMFILES64 (currently installs to Program Files (x86) on 64-bit Windows), and the Delete "$DOCUMENTS\RT-RP Config.ini" removal - that line wipes the user's config on every reinstall.

Happy to adjust anything, not trying to step on the workflow.

@Kuijen
Copy link
Copy Markdown
Owner

Kuijen commented Mar 26, 2026

Sorry for the late reaction.
While there may be some useful improvements I can't currently merge it because I'll have to familiarise myself with the script that you have written along with becoming comfortable enough to maintain a powershell script which I sadly do not have any experience with yet, along with the reality that I currently juts do not have the time to focus on personal projects like RT-RP due to private matters.
I also think that it would be better to eventually re-write the main script in a different more agnostic language for possible furture-proofing, and to possibly look at bringing it over to linux as well should my needs require it, however that's all still just a vague idea in my head for now.
I'll take a look when I have found the proper time for it which may take a while.

Again, sorry for the late response and I hope you'll understand.

@plyrthn
Copy link
Copy Markdown
Author

plyrthn commented Mar 26, 2026

Hey no worries! Take care of yourself and no issue. This is just what I needed to help someone out who was less savvy. Good luck with everything, and never any pressure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants