first commit
This commit is contained in:
lucasdpt
@@ -0,0 +1,165 @@
|
||||
# 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:win # build l'installeur + upload latest.yml/installeur/.blockmap
|
||||
```
|
||||
|
||||
`scripts/publish-gitea.mjs` crée la release `latest` si besoin, supprime les
|
||||
anciens assets puis uploade les nouveaux. URL/owner/repo/tag sont surchargeables
|
||||
via les variables `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 »). Il build l'installeur Windows sous
|
||||
Linux via Wine (image `electronuserland/builder`) puis publie 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) ; le token auto
|
||||
`secrets.GITEA_TOKEN` suffit s'il a le droit d'écrire les releases.
|
||||
|
||||
> 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
|
||||
```
|
||||
Reference in New Issue
Block a user