diff --git a/ROADMAP.md b/ROADMAP.md index 12c6e34..32b0175 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -284,10 +284,34 @@ Durchgemessen über die öffentliche Adresse, nicht über localhost: > binnen Millisekunden ist immer ein *Connection refused*, und dann stimmt eine > Portnummer nicht. -### ⬜ Als Nächstes +### ✅ Fertig — Schritt 3, der Fotostudio lädt selbst hoch -**3 · `server/upload.lua` im Fotostudio — geschrieben, im Spiel noch nicht -gelaufen.** Liegt in `d4rk_photostudio` (eigenes Repo, `D:\FXServer\txData\…`): +**Am 11.08.2026 im Spiel gelaufen.** `/studio shot adder`, und die Konsole sagte +in zwei Zeilen, was passiert ist: + +``` +[photostudio] Upload nach https://fivemanage.d4rkst3r.de — Dienst antwortet. +[photostudio] adder freigestellt abgelegt (129 KB) +[photostudio] adder hochgeladen: https://fivemanage.d4rkst3r.de/f/vehicles/adder.webp +``` + +Von der Dienstseite gegengeprüft, statt der Logzeile zu glauben: 132 908 Bytes +hier wie dort, **derselbe SHA-256** (`f14dfc5b…5515e`), ausgeliefert als +`image/webp`, und die ersten Bytes sind `RIFF….WEBP` — ein echtes WebP und +kein falsch benanntes PNG. + +Damit ist auch die letzte offene Frage aus dem Prüfstand beantwortet: +`PerformHttpRequest` verhält sich in FiveM wie die Fälschung, Kopfzeilen und +base64-Rumpf kommen unverändert an, und der Rückruf erreicht den +Event-Handler. + +**Was noch niemand gemessen hat:** ein ganzer Serienlauf über 900 Fahrzeuge — +also 900 Uploads hintereinander, mit dem, was dabei an Fristen und +Gleichzeitigkeit auftreten kann. Und `Upload.put`, die wartende Form, ist +ungenutzt: der Lauf nimmt `Upload.send`. Sie steht da, weil die ROADMAP sie so +benannt hat, und ist damit ungeprüfter Code. + +Der Quelltext liegt in `d4rk_photostudio` (eigenes Repo, `D:\FXServer\txData\…`): ``` server/upload.lua Upload.send(pfad, bytes, cb) und Upload.put(pfad, bytes) → url @@ -309,21 +333,12 @@ einer nackten Zahl; Status 0; und dass die Frist den Rückruf nicht ein zweites Mal auslöst. Der Rumpf, den die VM erzeugt hat, ging danach **unverändert an den echten Dienst** — hochgeladen, abgerufen, Byte für Byte identisch. -**Was offen bleibt, bis es einmal im Spiel lief:** ob `PerformHttpRequest`, -`SetTimeout` und `promise` sich in FiveM so verhalten wie die Fälschungen, und -ob der Event-Handler den Rückruf sauber erreicht. Dafür fehlt genau ein -Handgriff, und er braucht die Serverkonsole: +**Damit ist erreicht, worum es ursprünglich ging.** Ein Bild entsteht im Spiel, +wird freigestellt, landet auf der Platte und liegt Sekunden später unter einer +vorhersagbaren Adresse — ohne Fivemanage, ohne PostgreSQL, ohne MinIO, ohne +einen einzigen Handgriff von Hand dazwischen. -``` -refresh -ensure d4rk_photostudio (bzw. restart d4rk_photostudio) -``` - -Beim Start sagt die Resource in einer Zeile, ob der Dienst antwortet. Danach -`/studio shot ` im Spiel — das Bild muss unter -`https://fivemanage.d4rkst3r.de/f/vehicles/.webp` stehen. - -Nach diesem Schritt ist das erreicht, worum es ursprünglich ging. +### ⬜ Als Nächstes **4 · Dashboard.** React 18, TypeScript, Vite 5, Tailwind 4 (CSS-first), Lucide, Zustand. **Kein Konsta** — das ist für die Handy-Oberfläche richtig,