j.foucher 7cb2b01403 v0.23.3 — Mode safe : OpenVR sans vtable (Phase 1 stripped down)
Init OpenVR + binding de la vtable IVRSystem_022 fonctionne (confirmé par
les logs : "OpenVR state: Ready, vtable IVRSystem_022 bindée"), mais le
PREMIER appel vtable crashe en AccessViolation natif. Pas une race au
boot — ça plante même 8s après que vrserver est apparu, et probablement
à n'importe quel moment de la session SteamVR.

Diagnostic : les fonctions de la vtable (IsTrackedDeviceConnected,
GetBoolTrackedDeviceProperty, etc.) accèdent à des shared memories avec
vrserver qui peuvent être (re)mappées dynamiquement quand un device se
connecte/déconnecte. L'AccessViolation natif passe au travers du CLR
via Marshal.GetDelegateForFunctionPointer — non rattrapable par
catch (Exception) ni catch (AccessViolationException).

Fix : on retire TOUS les appels vtable. OpenVrService.Query utilise
maintenant uniquement l'API flat C qui ne fait pas de SHM/IPC :

  - VR_IsRuntimeInstalled() — lookup statique dans la DLL
  - VR_IsHmdPresent() — consulte un mutex/event nommé, pas de SHM
  - GetProcessesByName("vrserver") — process check Windows

Résultat : check VR robuste mais réduit à "SteamVR actif + HMD présent
oui/non". Plus de batterie, plus d'info per-device, le device picker du
dialog devient cosmétique (tous les aliases retournent la même réponse).

La batterie + l'info per-device reviendra en Phase 1.5 via une approche
sub-process : un PSLauncher.VrProbe.exe séparé qui fait les vtable calls
et communique par stdout JSON. Si VrProbe crashe en AccessViolation, le
launcher voit juste "exit code != 0" et report "VR query failed" sans
être affecté lui-même.

Le code de la vtable (delegates, BindVTableDelegates, Init/Shutdown) reste
en place dans OpenVrService.cs comme référence pour Phase 1.5 — n'est
juste plus appelé depuis Query.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-03 20:16:16 +02:00
2026-05-03 10:58:51 +02:00

PS_Launcher

Launcher Windows pour l'application UE5 PROSERVE : gère plusieurs versions cohabitantes, téléchargement et installation de nouvelles versions depuis un serveur, validation de license, release notes.

Composants

  • src/ — Solution C# / .NET 8 / WPF (Visual Studio 2022 + SDK .NET 8 requis)
    • PSLauncher.App : UI WPF (style Epic Games Launcher)
    • PSLauncher.Core : services (Manifest, Download, Install, Process…)
    • PSLauncher.Models : DTOs partagés
  • server/ — Code serveur PHP 8 (à déployer sous www/PS_Launcher/ sur OVH mutualisé)

Démarrage rapide (dev)

dotnet build PS_Launcher.sln
dotnet run --project src/PSLauncher.App

Pour produire un binaire autonome distribuable (un seul .exe ~70 Mo) :

dotnet publish src/PSLauncher.App -c Release
# Sortie : src/PSLauncher.App/bin/Release/net8.0-windows/win-x64/publish/PSLauncher.exe

Configuration locale

Le launcher écrit sa config dans %LocalAppData%\PSLauncher\config.json au premier lancement. Édite serverBaseUrl pour pointer vers ton serveur :

{
  "serverBaseUrl": "https://ton-domaine.com/PS_Launcher/api",
  "installRoot": "C:\\ASTERION\\GIT\\PS_Launcher\\ASTERION_VR"
}

État (roadmap)

  • v0.1 — Scan + lancement de versions installées
  • v0.2 — Manifest distant, download ZIP, install cohabitante, release notes Markdown
  • v0.3 — Reprise (HTTP Range), retry Polly, state.json
  • v0.4 — License (MySQL + Ed25519 + DPAPI)
  • v0.5 — Settings, suppression manuelle versions, toasts
  • v1.0 — Auto-update launcher, MSI installer

Voir le plan détaillé pour la roadmap complète.

Licence / interne

Repo interne ASTERION. Ne pas distribuer.

Description
No description provided
Readme 170 MiB
Languages
C# 46%
HTML 29%
PHP 23.3%
CSS 0.6%
Batchfile 0.5%
Other 0.6%