Document alpha 11 publication
This commit is contained in:
1 parent
4d9e6d9185
commit
67abdf13b0
2 files changed
+7
-7
No files matched your search
@@ -45,15 +45,15 @@ Im Godot-Projektordner:
|
||||
|
||||
Ohne `-Apply` läuft zuerst der Server-Simulationstest und dann ein SHA-256-Vergleich; es wird nichts hochgeladen. Mit `-Apply` lädt das Skript nur bei einer Änderung hoch, prüft den Hash, sichert die bisherige Serverdatei mit Zeitstempel, ersetzt sie, startet **nur** den Nakama-Container neu und wartet auf dessen `healthy`-Status. Bei einem Fehler nach der Aktivierung nicht blind erneut starten; zuerst Logs prüfen und bei Bedarf die gemeldete Sicherungsdatei wiederherstellen. Der Unraid-SSH-Zugang ist serverweit mächtig: Pfade und Containername im Skript nicht ohne Prüfung ändern.
|
||||
|
||||
Am 10. Oktober 2026 wurde für Alpha 10 das Server-Bundle mit SHA-256 `1b0a0922a1a289d7bb1ccf12269732ea57853eab9f60353757656a7c0fdd0917` aktiviert; Nakama meldete `healthy` und der Zwei-Konten-Test für Freundschaft, Status und Einladung bestand. Die RPCs `create_unlock_code`, `list_unlock_codes` und `invite_friend` sind registriert. Die PHP-Codeverwaltung aus Gitea-Commit `3e6132e` wurde am 9. Oktober manuell auf Netcup bereitgestellt; danach wurde die automatische Website-Bereitstellung eingerichtet und getestet.
|
||||
Am 10. Oktober 2026 wurde für Alpha 11 das Server-Bundle mit SHA-256 `b522531f8ae6c4ec12b2001db9fbee9fb47b3f48611c58aaab9a07439309d399` aktiviert. Nach dem gezielten Containerneustart meldete Nakama `healthy`. Das Bundle enthält die Freundesnamenssuche, automatische Online-Rundenberichte und die serverseitige Halbierung des ersten Welle-5-Boss-Schilds. Die wiederherstellbare Serverkopie liegt unter `/mnt/user/appdata/void-bastion-online/nakama/modules/build/index.js.pre-20261010-201010`.
|
||||
|
||||
## Windows-Release und Homepage
|
||||
|
||||
Den Windows-Export mit `packaging/windows/build.ps1` erstellen und die exportierte EXE vor dem Upload mit `--headless --quit` starten. Das Skript benötigt den Godot-Konsolenpfad und optional `-MakeNsisExe` mit der **echten** NSIS-Binärdatei (auf diesem PC `C:\Users\Domin\AppData\Local\Programs\NSIS-3.13\Bin\makensis.exe`; die gleichnamige Datei eine Ebene höher ist nur ein Starter). Produkt-, Installer- und Projektversion gemeinsam erhöhen. Das Skript gibt Größe und SHA-256 des Setups aus.
|
||||
Den Windows-Export mit `packaging/windows/build.ps1` erstellen und die exportierte EXE vor dem Upload mit `--headless --quit` starten. Das Skript benötigt den Godot-Konsolenpfad und `-MakeNsisExe` mit der **echten** NSIS-Binärdatei. Auf diesem PC funktionierten Godot 4.7.2 unter `C:\Users\Domin\Downloads\Godot_v4.7.2-stable_win64.exe\Godot_v4.7.2-stable_win64_console.exe` und NSIS unter `build\nsis-portable\nsis-3.13\Bin\makensis.exe`. In der eingeschränkten Ausführungsumgebung schlug NSIS mit einem Windows-System-DLL-Ladefehler fehl; der Installer ließ sich mit derselben Build-Anweisung außerhalb der Sandbox erstellen. Produkt-, Installer- und Projektversion gemeinsam erhöhen. Das Skript gibt Größe und SHA-256 des Setups aus.
|
||||
|
||||
Im öffentlichen Gitea-Repository `Emporex/Void-Bastion-Releases` zuerst einen **Entwurf** für den neuen Tag erstellen, dann `Void-Bastion-Setup-x64.exe` anhängen. Den hochgeladenen Entwurf mit den über Git Credential Manager gespeicherten Zugangsdaten erneut herunterladen und SHA-256 vergleichen. Erst danach den Entwurf veröffentlichen. Keine Zugangsdaten oder Token in Skripte, Dateien oder Chat kopieren. Der vorhandene Gitea-Token hat `write:repository`, aber kein `read:user`; ein `GET /api/v1/user` kann deshalb trotz funktionierendem Release-Zugriff 403 liefern.
|
||||
Im öffentlichen Gitea-Repository `Emporex/Void-Bastion-Releases` zuerst einen **Entwurf** für den neuen Tag erstellen, dann `Void-Bastion-Setup-x64.exe` anhängen. Das Release-Repository ist unabhängig vom Spiel-Quellcode-Repository: `target_commitish` muss daher auf dessen existierenden Branch (derzeit `main`) zeigen, nicht auf den Commit-SHA des Spiels. Den hochgeladenen Entwurf mit den über Git Credential Manager gespeicherten Zugangsdaten erneut herunterladen und SHA-256 vergleichen. Erst danach den Entwurf veröffentlichen. Keine Zugangsdaten oder Token in Skripte, Dateien oder Chat kopieren. Der vorhandene Gitea-Token hat `write:repository`, aber kein `read:user`; ein `GET /api/v1/user` kann deshalb trotz funktionierendem Release-Zugriff 403 liefern.
|
||||
|
||||
Die Website liest den neuesten **veröffentlichten** Release mit passendem EXE-Asset automatisch über `https://void-bastion.gergames.de/latest-release.php`; der Ingame-Updater liest die Release-Liste. `.../releases/latest` ist zur Alpha-Prüfung ungeeignet, da Gitea Vorabversionen dort nicht berücksichtigt. Nach jeder Veröffentlichung beide tatsächlichen Endpunkte und den öffentlichen Download testen. Alpha 10: `v0.1.0-alpha.10`, Setup SHA-256 `8B86ABC1EBF95252BD5C3C08156B9DD92BE6585A47E9DA323043D6483FED7287`.
|
||||
Die Website liest den neuesten **veröffentlichten** Release mit passendem EXE-Asset automatisch über `https://void-bastion.gergames.de/latest-release.php`; der Ingame-Updater liest die Release-Liste. `.../releases/latest` ist zur Alpha-Prüfung ungeeignet, da Gitea Vorabversionen dort nicht berücksichtigt. Nach jeder Veröffentlichung beide tatsächlichen Endpunkte und den öffentlichen Download testen. Alpha 11: `v0.1.0-alpha.11`, Spiel-Commit `4d9e6d9`, Website-Commit `0f953f0`, Setup SHA-256 `399ADD8FCC28A4DB36B01F477DA856E95F78628E7372CB4870E9E94554858895`. Der öffentliche Download und `latest-release.php` wurden nach der Veröffentlichung geprüft; die heruntergeladene Datei stimmt bytegenau mit dem lokalen Setup überein.
|
||||
|
||||
## Absicherung und Wiederherstellung
|
||||
|
||||
|
||||
Reference in new issue
Block a user