j.foucher
43a6070a65
Bug : à chaque install, la popup « Vérification de la santé système / X
blocs vont être mis à jour » apparaissait alors que la source `_steamvr/
steamvr.vrsettings` n'avait pas changé entre les sous-versions. L'opérateur
voyait le launcher toucher au fichier SteamVR de manière répétitive et
inutile.
Root cause : le diff comparait TOUS les blocs racine du source vs target.
Or le fichier source contient (légitimement, pour la doc opérateur) des
blocs user-/machine-spécifiques copiés depuis une machine de référence :
• DesktopUI (position fenêtres SteamVR — varie par poste)
• GpuSpeed (calibration GPU — RTX 3080 chez l'opérateur vs autre
GPU chez le client)
• LastKnown (HMD info — Focus3 ou autre)
• dashboard, steamvr (settings UI — installID utilisateur, etc.)
• trackers (mapping device — déjà configuré côté client)
Ces blocs DIFFÈRENT toujours entre la machine de référence (où le source
a été capturé) et chaque poste client → faux positif de diff systématique.
Fix : on restreint la diff + le push aux blocs racine `system.generated.*`
(typiquement system.generated.openxr.proserve_ue_5_5.proserve_ue_5_5.exe,
etc.) qui contiennent les bindings tracker workshop URLs — la VRAIE config
que le launcher est censé pousser. Tout le reste du fichier source est
maintenant ignoré.
Sémantique précise pour un bloc system.generated.* :
• ABSENT côté target → push complet (les 4 leaf keys CurrentURL,
PreviousURL, AutosaveURL, NeedToUpdateAutosave)
• PRÉSENT côté target → check sur les seules leaf keys *_CurrentURL_openxr
et *_PreviousURL_openxr. Si elles matchent → skip silencieux. Si elles
diffèrent (= opérateur a updaté la binding workshop) → réécriture des
2 leafs ciblées, les autres (AutosaveURL, NeedToUpdate) sont laissées
intactes (gérées par SteamVR).
Cleanup : helpers `DeepMergeInto` et `WouldDeepMergeChange` retirés (plus
référencés). Nouveau helpers ciblés `OpenXrBindingUrlsDiffer` (check) et
`ReplaceOpenXrBindingUrls` (write). Doc XML mise à jour côté interface.
Bump : 1.0.0 → 1.0.1 (patch fix).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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 souswww/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.