OFLauncher/README.md

# OFLauncher

Launcher Minecraft custom pour jouer à **All The Mods 10** (Minecraft 1.21.1 /
NeoForge / Java 21) entre potes, avec **mise à jour incrémentale du modpack** :
quand tu changes le pack, les joueurs ne re-téléchargent que ce qui a changé.

- **UI** : Electron + React + TypeScript
- **Auth Microsoft** : `prismarine-auth` (cache + refresh automatique)
- **Runtime MC / NeoForge** : `@xmcl/core` + `@xmcl/installer`
- **Java 21** : JRE Temurin (Adoptium) téléchargé et géré automatiquement
- **Sync du modpack** : `packwiz-installer` (delta par hash, conforme CurseForge)

---

## 1. Développement

```bash
npm install        # une fois
npm run dev        # lance le launcher en mode dev (hot reload)
npm run typecheck  # vérifie les types main + renderer
npm run build      # build de production (out/)
```

## 2. Configuration (la seule chose à éditer dans le code)

Tout est dans **`src/shared/config.ts`** :

| Champ           | À mettre                                                              |
| --------------- | -------------------------------------------------------------------- |
| `packTomlUrl`   | URL publique de ton `pack.toml` packwiz (voir §4)                    |
| `azureClientId` | Client ID de ton app Azure (voir §3). Laisse `CHANGE_ME` pour tester |
| `serverAddress` | (optionnel) `ip:port` du serveur pour rejoindre en un clic           |

Les **versions Minecraft et NeoForge ne sont PAS dans le code** : elles viennent
du `pack.toml`. Pour changer de version, tu mets à jour le pack, pas le launcher.

## 3. Auth Microsoft

Par défaut (`azureClientId = "CHANGE_ME"`), le launcher utilise le flow `live`
qui **fonctionne tout de suite** pour tester, sans app Azure.

Pour la version « propre » d'un launcher tiers (recommandé en prod) :

1. Crée une app sur [Azure Portal](https://portal.azure.com) → *App registrations*
   (comptes personnels / *consumers*), avec le scope `XboxLive.signin`.
2. **Demande l'accès à l'API Minecraft** via le formulaire Microsoft — cette
   approbation peut prendre du temps, fais-le tôt. Réf :
   <https://learn.microsoft.com/answers/questions/5768276/>
3. Mets le Client ID dans `config.azureClientId`. Le launcher bascule alors
   automatiquement sur le flow `msal`.

Le login se fait en **device code** : le launcher ouvre la page Microsoft et
affiche un code à saisir. Le token est mis en cache (pas de re-login ensuite).

## 4. Créer et héberger le modpack (côté admin = toi)

Le modpack est géré avec [**packwiz**](https://packwiz.infra.link/) (CLI).

```bash
# 1. Récupère une clé API CurseForge (https://console.curseforge.com) -> CF_API_KEY
# 2. Crée le dépôt packwiz à partir d'ATM10 (depuis le .zip CurseForge d'ATM10) :
packwiz init            # renseigne MC 1.21.1 + NeoForge
packwiz cf import All-the-Mods-10-x.y.z.zip   # importe les mods + configs

# 3. À chaque modif du pack :
packwiz cf add <mod>           # ajouter un mod CurseForge
packwiz update --all           # mettre à jour les mods
packwiz remove <mod>           # retirer un mod
packwiz refresh                # régénère index.toml (le manifeste hashé)
git add -A && git commit -m "update pack" && git push
```

**Hébergement** (à décider) : le plus simple est **GitHub**.

- Pousse le dossier packwiz dans un repo (ex. `OFModpack`).
- `packTomlUrl` = lien *raw* vers `pack.toml`, ex.
  `https://raw.githubusercontent.com/<user>/OFModpack/main/pack.toml`.
- (ou GitHub Pages pour une URL plus propre.)

À chaque lancement, le launcher relit `pack.toml`/`index.toml` et **ne télécharge
que les fichiers dont le hash a changé** ; les fichiers retirés du pack sont
supprimés de l'instance du joueur.

> **Mods CurseForge non-redistribuables** : la grande majorité d'ATM10 se
> télécharge automatiquement. Pour les rares mods qui interdisent la
> redistribution, packwiz les signalera ; au besoin tu peux les héberger
> toi-même (si la licence le permet) via un bloc `[download]` dans le `.pw.toml`.

## 5. Build des binaires

```bash
npm run build:win     # installeur Windows (.exe NSIS) -> dist/
npm run build:linux   # AppImage + .deb -> dist/
```

### Auto-update du launcher (via Gitea)

Le launcher se met à jour tout seul : au démarrage il lit `latest.yml` à l'URL
configurée dans `electron-builder.yml` (`publish.url`), télécharge la nouvelle
version en fond et propose un bouton **« Redémarrer pour installer »**.

Les artefacts sont hébergés sur une **release Gitea à tag fixe `latest`**
(provider `generic` d'electron-updater — il n'y a pas de provider Gitea natif).
À chaque publication, les assets de cette release sont **écrasés**.

Pré-requis côté Gitea (une fois) :

- un repo launcher, ex. `gitea.ldpt.fr/zertus/OFLauncher` ;
- un **token d'accès** avec le scope `write:repository`.

Publier une nouvelle version :

```bash
npm version patch            # bump 0.1.0 -> 0.1.1 (la version EST la source de vérité)
export GITEA_TOKEN=xxxxx     # token Gitea (scope write:repository)
npm run publish              # build Windows + Linux puis upload de tous les artefacts
```

`scripts/publish-gitea.mjs` crée la release `latest` si besoin, supprime **tous**
les anciens assets puis uploade les nouveaux (Windows + Linux). C'est pourquoi on
build les deux plateformes avant de publier (`build:all`) : une publication ne
contenant qu'une plateforme effacerait l'autre. URL/owner/repo/tag sont
surchargeables via `GITEA_URL` / `GITEA_OWNER` / `GITEA_REPO` / `GITEA_TAG`.

**Publier via Gitea Actions (CI, déclenchement manuel)** — au lieu de builder en
local, tu peux lancer le workflow `.gitea/workflows/publish.yml` depuis l'onglet
*Actions* du repo (bouton « Run workflow »). Sur un runner Linux (image
`electronuserland/builder`), il build l'**installeur Windows** (NSIS, via Wine) et
les **paquets Linux** (AppImage + .deb), puis publie le tout sur la release
`latest`. Optionnellement, l'input `bump` (patch/minor/major) incrémente la
version et pousse le commit avant le build. Pré-requis : Gitea Actions activé +
un act_runner enregistré (label `ubuntu-latest`, à adapter) ; un secret repo
`RELEASE_TOKEN` (scope `write:repository`) pour publier la release.

> Tester le flux en dev : `dev-app-update.yml` (déjà présent) pointe sur la même
> URL ; avec une version distante > version locale, le bandeau de maj apparaît
> en `npm run dev` (l'install réelle ne se fait toutefois qu'en build packagé).

## 6. Où vivent les fichiers

Sous le dossier userData d'Electron (`%APPDATA%/OFLauncher` sur Windows,
`~/.config/OFLauncher` sur Linux) :

```
minecraft/    runtime géré par @xmcl (versions, libraries, assets) — jamais touché par packwiz
instance/     mods/, config/, saves/ — cible de la sync packwiz
java/         JRE Temurin 21 géré
auth-cache/   tokens Microsoft (refresh auto)
settings.json réglages (RAM, args JVM)
```

## Architecture (code)

```
src/
├── shared/        config + contrats IPC partagés main/renderer
├── main/
│   ├── index.ts   bootstrap Electron + handlers IPC
│   ├── auth.ts    login/refresh/logout Microsoft
│   ├── java.ts    provisioning Temurin 21
│   ├── install.ts install MC + NeoForge (@xmcl)
│   ├── modpack.ts pack.toml + sync packwiz
│   ├── launch.ts  lancement du jeu (@xmcl)
│   ├── play.ts    orchestration de la séquence "Jouer"
│   └── ...
├── preload/       pont IPC typé (window.api)
└── renderer/      UI React
```