Moddingflow ist eine Community-Plattform für Mods, Builds, Guides und Spieldiskussionen. Du kannst Inhalte suchen, eigene Arbeiten veröffentlichen, Fragen stellen und Antworten anderer Mitglieder lesen.
Die wichtigsten Bereiche liegen im Forum, die Spieleliste findest du unter alle Spiele.
Die wichtigsten Dokumente sind öffentlich: Website-Regeln, Nutzungsbedingungen, Datenschutz und Cookie-Richtlinie. Diese Links öffnen sich in der aktuell gewählten Sprache der Website.
Ja. Die Public API enthält jetzt stable catalog reads mit cursor-first keyset pagination, direkte creator upload sessions in den storage mit status/complete/abort lifecycle endpoints, async job processing über GET /v1/uploads/{upload_id}, Download-/Install-plan endpoints für den Mod Manager und delegierte Agent Gateway Tools im v1 contract. Catalog cursors sind opaque v1 tokens, die an resource, normalized filters, sort und den insertion snapshot der ersten Seite gebunden sind. Wiederverwendung mit geändertem Kontext liefert 400; nach Seite eins eingefügte Zeilen bleiben außerhalb dieses cursor snapshot.
Ein erfolgreicher Version-Write bestätigt ein committed private/no-store Ergebnis. Anonyme Catalog-/Version-GETs revalidieren den shared cache bei jeder Wiederverwendung; das Catalog-Freshness-p95-SLO beträgt 15 Sekunden, der Search Index 30 Minuten. Mod/ModVersion PATCH sendet einen starken ETag in If-Match: Ohne ihn folgt 428, bei einem stale validator 412 mit dem aktuellen ETag. Vor Provider Signing begrenzt Download Resolve die Concurrency auf 2 anonyme oder 4 authentifizierte Leases pro Actor und 16 pro Client. Die cached PublicModVersion artifact expansion erfordert scan_status=clean, lifecycle=ready und publication state=published und bleibt eventual. Direct Download Resolve und Install Plan sind private point-in-time reads über ein eligible target, dessen established database state approved oder published sein kann; direct targets sind nicht published-only und nicht legacy-only. Upload Status zeigt den current database state zum Request-Zeitpunkt, Worker-Transitions sind eventual und progress.available=false bedeutet unknown, nicht zero. Webhooks sind feature-gated: Wenn sie aktiviert sind, ist Delivery eventual, at-least-once, replayable und unordered; solange einer der Gates deaktiviert ist, wird keine Delivery versprochen.
Aktueller Status, verfügbare Endpoints und künftige Integrationsregeln stehen auf der API-Seite.
Die Upload API ist für Autoren, Teams, CI pipelines und tools gedacht, die Publish to Moddingflow nutzen wollen, ohne bei jedem release durch die browser form zu gehen. Baue lokal oder mit GitHub Actions, lade direct-to-cloud hoch, warte auf scan/validation und veröffentliche eine new version erst, wenn die API ready zurückgibt.
Nutze individual API keys oder OAuth/PAT tokens statt das main account password zu teilen. Vor dem Erstellen einer Session kann CI POST /v1/uploads:validate aufrufen; diese validate-only Prüfung erstellt keinen Upload und schreibt keine Bytes. Nutze einen stabilen Idempotency-Key pro logischem Upload: Ein Retry mit demselben Body verwendet dieselbe durable Reservation, ohne das Byte-Quota doppelt zu belasten; ein geänderter Body führt zum Konflikt. Große Archive nutzen resumable multipart upload in Cloudflare R2: status.progress und completedParts abfragen, nur URLs für missing parts erneuern und dieselbe Session bis zu 48 Stunden fortsetzen, während jede signed URL kurzlebig bleibt. Wenn eine Datei validation nicht besteht, quota erreicht, eine version dupliziert oder in quarantine/review geht, erhält der client einen machine-readable status, einen error code wie duplicate_version und eine request_id für support; eine abgebrochene Session liefert lifecycleStatus cancelled. In production erfordert die Veröffentlichung ein clean malware verdict: eindeutig gefährliche oder infizierte Archive werden abgelehnt, während nested archives, executables und ungeprüfte RAR/7z-Dateien bis zur MFA-geschützten staff review in private quarantine bleiben. Die Account Inbox versucht eine deduplizierte Benachrichtigung bei failed scan, required review und erfolgreicher Veröffentlichung, aber deren Ankunft ist kein Lifecycle Acknowledgement; Clients müssen den machine-readable Status weiter pollen.
Wenn complete einen AsyncJob liefert, hat der Service die hochgeladenen Bytes zuerst in einem privaten server-only Seal isoliert; Checksum, Validation, Scan und Final Copy lesen diesen immutable Seal statt des client-writable Staging Keys. Der Seal Key wird dem Client nicht ausgegeben und muss nicht verwaltet werden. Frage job.statusEndpoint ab: queued und processing sind non-terminal; succeeded, rejected, failed und cancelled sind terminal. job.progress zeigt ehrlich 0/1 completion statt eines geschätzten scanner percentage. Nutze createdAt, updatedAt, startedAt, completedAt, retry.attempt, retry.maxAttempts, retry.nextAttemptAt, retry.retryable und Retry-After zur Diagnose von wartender oder erneut versuchter Arbeit. Ein terminal failure liefert einen stabilen reason code, niemals raw provider prose.
Automation sollte auch den HTTP-Status von complete auswerten: queued oder processing liefert 202 Accepted mit Location gleich job.statusEndpoint. Ein bereits terminaler Job, einschließlich eines Replays desselben abgeschlossenen Ergebnisses mit dem ursprünglichen Idempotency-Key, liefert 200 OK, ohne die Operation zu wiederholen.
Jedes team member erstellt einen eigenen resource-scoped key über POST /v1/api-keys und erhält niemals die owner session cookie. Create und rotate erfordern Idempotency-Key. Derselbe Header mit demselben Request wiederholt die credential mutation nicht; weil das raw secret niemals gespeichert wird, liefert ein abgeschlossener Replay idempotency_replay_unavailable ohne operation-shaped committed metadata. Prüfe den Key über GET /v1/api-keys oder widerrufe ihn, bevor eine neue Mutation gestartet wird. Das raw secret wird one-time gezeigt, der Server speichert nur token_hash und safe fingerprint; GET /v1/api-keys/capabilities zeigt scopes und projects. Die Rollen owner, maintainer, publisher und reviewer begrenzen mods:write, versions:write, files:upload, versions:publish, versions:archive, files:manage und teams:admin. Rotation läuft über POST /v1/api-keys/{api_key_id}/rotate, revoke über DELETE /v1/api-keys/{api_key_id}; last_used_at und key id/fingerprint bleiben ohne secret im audit.
Teile nicht einen owner key, das owner password oder eine session cookie. Gib jeder Person einen individual resource-scoped key für den Ziel-Mod mit den smallest scopes, die ihre Rolle benötigt. Weise owner, maintainer, publisher oder reviewer unter Einstellungen > Entwickler zu. Das raw secret wird one-time angezeigt.
Prüfe last_used_at und den safe key fingerprint, nutze rotate beim geplanten Austausch und revoke den Key sofort nach vermuteter Offenlegung oder wenn ein Teammitglied geht. Audit records identifizieren actor und key, ohne das secret zu speichern oder anzuzeigen.
Veröffentliche, benenne oder verpacke ein Archiv nicht neu, um einen failed scan zu umgehen. Eine abgelehnte oder unklare Datei bleibt private mit failed oder quarantined/review Status. Öffne Einstellungen > Entwickler oder rufe GET /v1/uploads/{upload_id} auf und bewahre supportCorrelationId (auch als X-Upload-Correlation-Id zurückgegeben), request_id, trace_id sowie einen error code wie av_scan_rejected für den support auf. Die correlation id darf mit dem support geteilt werden, ersetzt aber keine Autorisierung.
Bekannt gefährliche oder infizierte Archive werden abgelehnt. Dateien mit unklarer Evidenz bleiben bis zur manual review private. Folge den recovery details, warte auf die angeforderte review und erstelle eine new session erst, nachdem das erkannte source- oder Archivproblem behoben wurde.
Beide Wege nutzen dasselbe upload-session backend, private Cloudflare R2 storage, validation, scan und quarantine/review gates. Die manual browser form ist eine geführte Wahl für gelegentliche Releases. API upload ist für wiederholbare local tools und CI ausgelegt, mit Idempotency-Key retries, resumable multipart transfer, status.progress und machine-readable failures.
Automation schwächt die security checks nicht und macht eine Datei nicht früher öffentlich. Wähle die passende Oberfläche; dieselben security gates müssen vor publish ready melden.
Für einen signed single PUT müssen beide Clients alle zurückgegebenen Header einschließlich If-None-Match: * senden. Ein conditional 412 bedeutet einen ambiguous existing write und keine Erlaubnis zum Überschreiben: Rufe denselben complete Endpoint auf; danach bestimmt server verification über HEAD, immutable Seal und SHA-256 das Ergebnis.
Ja. Nutze die official GitHub Action oder CLI und speichere MODDINGFLOW_API_KEY in einem GitHub environment or repository secret. Lege ihn niemals in workflow YAML, repository variables, logs, command arguments, artifacts oder einer committed state file ab.
Nutze einen resource-scoped, least-privilege key, bevorzuge für staging und production ein protected environment mit approval, behalte permissions: contents: read, solange der Workflow nicht nachweislich mehr benötigt, und pinne die Action auf einen geprüften 40-character commit SHA. Nach einer Offenlegung rotate oder revoke den Key. Den vollständigen Workflow findest du in den API docs.
Beginne mit den API docs, öffne danach die API reference oder lade das OpenAPI JSON herunter. Das SDK ist bis zum package publishing ein repo-only source artifact und not published to npm, PyPI, or NuGet; öffne den SDK source page und nutze dann local imports aus sdk/csharp/Moddingflow.PublicApi, sdk/typescript/src/moddingflow-public-api.ts oder sdk/python/moddingflow_public_api.
Die aktuelle Support- und EOL-Matrix ist in docs/public-api/SDK-SUPPORT-AND-EOL.md dokumentiert. Dies sind Preview source artifacts: Package-Version und Contract-Version werden getrennt geführt, und eine Registry-Veröffentlichung, Support-SLA, Signatur oder stabile EOL-Zusage gilt erst nach einem unveränderlichen Stable Release.
Nein. Deprecation ist ein migration signal, keine sofortige Änderung des runtime behavior. Stable v1 hält old clients mindestens 90 days oder two stable API releases notice lauffähig, je nachdem welches Fenster die sicherere Migration ermöglicht.
Deprecated operations oder capabilities nutzen Deprecation und Sunset response headers, wenn sie zur HTTP response-Zeit signalisiert werden können, plus migration guide und changelog entry. Während des notice window behalten old clients same status codes, same field types, aliases, scopes, Problem Details codes, cursor semantics und upload/download/webhook lifecycle behavior. Das Repository Release Gate lehnt Sunset ab, solange ein committed migration guide, ein bereiter non-deprecated replacement, dated telemetry evidence und ein support plan mit explizitem owner und approver nicht an dieselben deprecation- und sunset-Daten gebunden sind.
Release Notes, Migration Guides und Changelog-Eintraege für Deprecation Paths stehen auf der API-Changelog.
Der Auth Lifecycle der öffentlichen API nutzt OAuth unter https://api.moddingflow.com. Entwickler registrieren self-service user applications unter Einstellungen > Entwickler auf /account/developer/applications. Authorization Code + PKCE zeigt die angeforderten scopes und erklärt, dass genehmigte Berechtigungen für alle Ressourcen gelten, auf die das Konto zugreifen darf; resource-restricted automation nutzt stattdessen einen PAT. Grundlegende Lese- und Installations-scopes werden für die Anwendung automatisch genehmigt, sensible scopes brauchen review und eine aktuelle AAL2-Bestätigung mit 2FA, bevor die Zustimmung abgeschlossen werden kann. Der Client erhält ein kurzlebiges Access Token und darf das Nutzerpasswort nicht speichern. OAuth Access Tokens autorisieren API-Aufrufe; ein separates OpenID Connect ID Token bestätigt nur die Identität gegenüber dem Client. OIDC-Clients fordern openid mit einem frischen nonce an und prüfen RS256-Signatur, issuer, audience, time claims und nonce über Discovery/JWKS. Ist OIDC Discovery nicht verfügbar, muss der Client OAuth-only bleiben.
Device Flow clients müssen interval und backoff nach slow_down beachten; Nutzer können eine Anfrage mit access_denied ablehnen. Refresh Tokens wechseln bei jedem refresh, und die Wiederverwendung eines älteren Tokens widerruft sofort die gesamte refresh family. Personal Access Tokens werden einmal angezeigt, nur als hashes gespeichert und unterstützen create-before-revoke rotation mit höchstens 10-minütigem overlap, scopes, expiry, last used timestamps und audit trails. Jede API-Anfrage braucht einen aussagekräftigen User-Agent im Format ApplicationName/ApplicationVersion; PAT mutations brauchen zusätzlich stabile X-Moddingflow-Client- und X-Moddingflow-Client-Version-Header. Ungültige Identity liefert invalid_client_identity vor Rate Limiting oder einer Business-Änderung. Details zum aktuellen Vertrag stehen auf der API Seite.
Die Public API prüft Route-, Body-Size-, Byte-Budget-, per-user-, per-application- und per-token limits vor Storage-, Signing-, Upload-, Download-, RPC- oder Agent-Gateway-Side-Effects. Zu große request bodies erhalten 413. Überlastete oder auffällige clients erhalten 429 als application/problem+json mit Retry-After sowie RateLimit-Limit, RateLimit-Remaining und RateLimit-Reset, wenn ein bucket verfügbar ist; retries sollten erst danach mit backoff erfolgen. Bei einem download-spezifischen 429 speichert der Client download_job.id, grant_id, bytes_received, etag und next_attempt_at und sendet nach Retry-After job_id mit monotonem progress erneut; Server hält denselben Job und reservierten Grant ohne weiteren Provider-Effekt.
Operational dashboards und Audit Trails gruppieren diese Ereignisse nach client_id, actor_user_id, token_id_or_api_key_id, scope und token_kind, damit Maintainer normale Traffic-Spitzen von token abuse unterscheiden können.
Public API webhooks nutzen owner-scoped subscriptions und stabile event names: mod.updated, version.published, file.ready, file.failed, upload.completed, scan.completed, token.changed und app.changed. Jeder delivery body enthält delivery_id, kind, created_at und data, und jede Anfrage wird mit X-Moddingflow-Signature als HMAC-SHA256 over `${timestamp}.${raw_body}` plus X-Moddingflow-Timestamp signiert.
Webhook-Delivery ist at-least-once, replayable und ungeordnet. Ein Receiver sollte schnell 2xx zurückgeben, asynchron verarbeiten, veraltete Timestamps ablehnen, Business-Effekte nach event_id deduplizieren, delivery_id für Diagnosen behalten und vor Änderungen den neuesten Resource-State abrufen. Nutze GET /v1/webhook-deliveries für die Attempt-Historie und POST /v1/webhook-deliveries/{delivery_id}/redeliver mit Idempotency-Key für eine verknüpfte Redelivery. Wiederholte terminale Fehler können disable the subscription. Der ganze Vertrag steht auf der API Seite.
Nur über delegierte Agent Gateway Tokens. Der Agent erhält ein kurzlebiges Token mit audience agent-gateway, engen Scopes und actor/delegation metadata; er erhält keinen vollständigen User Session Token.
Read tools können Mods suchen, Mod-Details lesen, install plans aufbauen, Versionen vergleichen und sichere download resolves ausführen. Write-fähige Tools laufen standardmäßig als dry-run, und publish, delete/archive, permission changes sowie paid/restricted access changes brauchen explicit confirmation.
Nein. Die Public API verwendet stabile UUIDs oder lifecycle ids für Spiele, Mods, Sammlungen, versions, logical files, physical blobs, upload sessions, download grants, tokens und webhook deliveries, wenn diese Ressourcen öffentlich sind. Interne forum/topic IDs bleiben Website-Details und sind kein externer Vertrag.
So funktionieren alte Seiten weiter, während Mod Manager und Integrationen canonical resources ohne forum naming leaks erhalten. Slugs, filenames, storage object names und hashes sind aliases oder verification data, keine durable external keys. Renames, metadata rebuilds und slug changes behalten public IDs; das Ersetzen von Datei-Bytes erzeugt einen neuen physical blob und kann eine neue logical artifact/version binding erzeugen.
Die Website unterstützt Russisch, Englisch und Deutsch. Die Hauptsprache der Oberfläche wählst du in den Einstellungen; sie wird im Profil und Cookie gespeichert.
Die Auswahl der Inhaltssprache bleibt nur in regulären Forenbereichen erhalten, wo sie Themen in der gewählten Sprache anzeigt. Mod-Kataloge, Build-Kataloge und Suche zeigen standardmäßig alle Sprachen.
Während du tippst, zeigt die Website leichte Vorschläge aus Titeln, Autoren, Spielen und Tags. Die vollständige hybride Suche startet nach dem Absenden: Exakte Treffer werden aus Titeln, Tags und Suchbegriffen bewertet, während die semantische Suche relevante Texte findet.
Neue Mods, Builds, Themen und Antworten gelangen über einen Hintergrund-Worker in den Suchindex. Das ist normalerweise schnell, aber ein neu veröffentlichter Inhalt kann mit kurzer Verzögerung in der Suche erscheinen.
Nein. Öffentliche IDs sind opaque UUIDs und hängen nicht von Slug, Titel, Dateiname, URL, CDN, Hash oder Speicheradresse ab. Umbenennungen und reine Metadatenänderungen behalten die ID. Neue Bytes erzeugen einen neuen Blob und, wenn sich die logische Datei oder Version ändert, eine neue Artifact- oder Version-ID.
Archivierte und zurückgezogene Ressourcen können über einen erlaubten Lifecycle-Übergang wiederhergestellt werden. Eine dauerhafte Löschung hinterlässt einen Tombstone: Der Lookup liefert HTTP 410 Gone, und die alte ID sowie ihre Quellbindung werden nie einer anderen Ressource zugewiesen.
Warte kurz und nutze dann die Schaltfläche zum manuellen Öffnen, falls dein Browser den neuen Tab blockiert hat. Lass die Moddingflow-Seite offen, bis der Download-Link erscheint.
Wenn der Download weiter fehlschlägt, versuche es nach einem Wechsel deines Netzwerks oder VPN-Routings erneut. Die Website prüft die primäre Cloudflare-Route, bevor sie das Backup-CDN nutzt.
Cloudflare R2 bleibt die Hauptquelle für Mod-Archive. Bunny CDN wird nur als Pull-CDN-Fallback genutzt, wenn die primäre Route für dich nicht erreichbar ist.
Fallback-Links sind kurzlebig und an eine bestimmte Datei gebunden. Sie sind keine dauerhaften öffentlichen Mirrors und umgehen keine Download-Limits, Inhaltswarnungen oder Kontoprüfungen.
Der Mod Manager fragt zuerst einen install plan mit Spielversion, platform, loader, release channel, typisierten required/optional/conflict/embedded dependencies, ausgewählten artifacts, decision reasons, stabilen plan/item IDs, Installationsreihenfolge, expected archive layout, warnings und per-file hashes ab. Identischer normalized input liefert bei unveränderten catalog data dieselben IDs; embedded dependencies erzeugen keinen eigenen download step, optionale steps nur auf Anfrage. Download resolve erstellt danach einen kurzlebigen download grant und liefert primary/fallback route, den legacy alias sha256, hashes.sha256 als canonical SHA-256 verifier, size_bytes und resume policy. SHA-256 prüft das vollständige gespeicherte Objekt: Der Client setzt alle Range-Teile zusammen, vergleicht size_bytes und prüft erst dann den Digest. ETag ist ein opaque Validator für eine transport representation und conditional resume; er ist kein kryptografischer Digest oder file identity und wird nicht zwischen Providern übernommen. Der resolve endpoint liefert einen 200 JSON grant, verwendet keinen 302 redirect und streamt keine binary data. Der aktuelle signed transport garantiert RFC 9530 Content-Digest oder Repr-Digest nicht. SHA-1 oder MD5 können nur als optionale compatibility metadata erscheinen.
Eine Version response kann zusätzlich PublicModVersion.artifacts enthalten. Dieses optional expansion gibt es nur für ein managed primary artifact mit size_bytes > 0, exaktem sha256/hashes.sha256, actual AV scan_status=clean aus der current upload session, die sowohl file_id als auch final_blob_id abgleicht, lifecycle=ready, publication state=published und managed resolve eligibility. Stabile artifact_ids bleiben vorhanden; bei einem legacy artifact wird artifacts omitted, statt erfundene Metadaten zu liefern. download_metadata enthält nur einen relative resolve_endpoint und einen wahrheitsgemäßen range_supported-Wert: Eine provider URL ist nie enthalten und darf vom Client nicht konstruiert oder gespeichert werden.
Ja. Wenn dein VPN Cloudflare erreichbar macht, nutzt der Download den primären Cloudflare R2-Link.
Wenn der Browser den Cloudflare-Probe nicht abrufen kann, kann Moddingflow einen kurzlebigen Bunny-Fallback-Link für dasselbe Archiv anfordern.
Prüfe, ob die E-Mail richtig geschrieben ist, ob das Passwort die Anforderungen des Formulars erfüllt und ob die Bestätigungsmail im Spam liegt. Wenn der Bestätigungslink abgelaufen ist, starte die Registrierung erneut.
Wenn das Konto bereits existiert, versuche dich anzumelden oder setze das Passwort über die Login-Seite zurück.
Mit einem Konto kannst du Themen, Mods, Builds und Guides veröffentlichen, kommentieren, reagieren, Inhalte beobachten und dein öffentliches Profil verwalten.
Nach dem Login öffnest du den Kontobereich, um Profil, Sicherheit und Abo-Einstellungen zu verwalten.
Das Archiv wird direkt aus deinem Browser über eine kurzlebige signierte URL zu Cloudflare R2 hochgeladen. Das ist der primäre Speicher von Moddingflow für Archive von Mods und Modpacks.
Die Website erstellt eine Upload-Sitzung und prüft die Datei vor der Veröffentlichung. Die Datenschutzerklärung beschreibt, welche technischen Daten Cloudflare/R2 und Moddingflow verarbeiten können.
Normale Konten können bis zu 3 Hauptdateien mit je 500 MB und bis zu 5 optionale Dateien mit je 100 MB veröffentlichen. Premium behält dieselben Datei-Slots bei, erhöht aber die Größe auf 4 GB pro Hauptdatei und 250 MB pro optionale Datei. Minecraft nutzt ein separates Limitsystem.
Du kehrst zum Mod-Upload zurück, und die Felder sowie ausgewählten Dateien bleiben erhalten, solange der Tab geöffnet bleibt.
Temporäre Bilder und Dateien, die während des fehlgeschlagenen Versuchs hochgeladen wurden, werden automatisch bereinigt. Prüfe nach dem Fehler die Meldung im Formular und veröffentliche den Mod erneut.
Den Nickname änderst du im Profilbereich deines Kontos. Prüfe danach die öffentliche Profilseite, damit Name, Avatar und Beschreibung richtig aussehen.
Die Kündigung findest du auf der Zahlungsseite. Nutze die Kündigung der Verlängerung, wenn du die nächste automatische Abbuchung stoppen möchtest.
Nach der Kündigung bleibt Premium bis zum Ende des aktuellen bezahlten Zeitraums aktiv. Wenn ein genaues Enddatum verfügbar ist, erscheint es im Zahlungsbereich.
Ein 14-tägiger Vertragswiderruf kann beim ersten Premium-Checkout oder beim Übergang von Testphase zu Zahlung verfügbar sein. Eine normale automatische Verlängerung öffnet kein neues automatisches 14-Tage-Fenster.
Wenn der Widerruf verfügbar ist, zeigt die Zahlungsseite die Widerrufsaktion und die Berechnung des ungenutzten Zeitraums. Wenn automatische Erstattung nicht verfügbar ist, geht der Antrag in manuelle Prüfung oder eine andere dokumentierte Lösung.
Belege öffnen sich von der Zahlungsseite auf Stripe-gehosteten Seiten. Kartendaten werden nur im Stripe Portal verwaltet.
Wenn du Support zu einer Zahlung kontaktierst, nenne die Konto-E-Mail und die Stripe-Beleg-ID. Sende keine Kartennummern, CVC-Codes oder Screenshots mit vollständigen Zahlungsdaten.
Öffne deinen Kontobereich. Dort erscheinen deine Themen, Beiträge, Mods, Builds und andere öffentliche Materialien, wenn sie mit deinem Konto verbunden sind.
Profil, Avatar, Titelbild und Bio bearbeitest du im Kontobereich. Lade nur unterstützte Bildformate hoch und nutze kein fremdes Material ohne Erlaubnis.
Wenn du Premium-Profilgestaltung nutzt, müssen GIFs und visuelle Effekte weiterhin den Website-Regeln entsprechen.
Das öffentliche Profil zeigt Anzeigename, Avatar, Bio und öffentliche Veröffentlichungen. Private Zahlungsdaten, E-Mail, Sicherheitseinstellungen und interne Einträge werden nicht angezeigt.
Der Umgang mit Kontodaten wird im Datenschutz erklärt.
Ein Build-Autor kann beim Veröffentlichen oder Bearbeiten eines Builds einen eigenen Fragen-und-Antworten-Block hinzufügen. Er ist für Installation, Konflikte, Anforderungen und Hinweise zum Durchspielen gedacht.
Dieser Block erscheint auf der Build-Seite im Tab FAQ oder Questions and answers. Er ist getrennt von dieser allgemeinen Support-FAQ.
Wenn du angemeldet bist, änderst du das Passwort in den Sicherheitseinstellungen deines Kontobereichs. Wenn du dich nicht anmelden kannst, nutze die Passwortwiederherstellung auf der Login-Seite.
Zwei-Faktor-Authentifizierung aktivierst du im Sicherheitsbereich deines Kontos. Sichere den Zugriff auf deine Authenticator-App, bevor du dich abmeldest.
Ja. Unter Einstellungen > Entwickler kannst du eine OAuth-Anwendung deaktivieren oder Personal Access Tokens und API keys ersetzen und widerrufen. Das Deaktivieren einer Anwendung wirkt sofort: Neue authorization und token requests werden blockiert, und für die Anwendung ausgestellte access tokens werden abgelehnt. Der Widerruf über https://api.moddingflow.com/oauth/revoke widerruft die refresh family; die Wiederverwendung eines älteren refresh token widerruft ebenfalls die ganze Familie. Bei PAT rotation bleibt das alte secret höchstens für einen 10-minütigen overlap gültig, damit der Client sicher wechseln kann; ein ausdrücklicher revoke wirkt sofort.
Beginne mit der Passwortwiederherstellung auf der Login-Seite und prüfe deine E-Mail. Wenn das Konto moderativ gesperrt wurde, lies den Grund genau und vergleiche ihn mit den Website-Regeln.
Die Kontolöschung startest du im Kontobereich, wenn diese Funktion für dein Profil verfügbar ist. Lade vorher Daten herunter, die du behalten möchtest.
Einige öffentliche Materialien können gespeichert oder anonymisiert werden, wenn das für Diskussionskontext, Sicherheit, rechtliche Pflichten oder Moderation nötig ist. Details stehen im Datenschutz.
Der Datenexport befindet sich im Kontobereich. Er hilft dir, eine Kopie der Profildaten und zugehörigen Einträge zu erhalten, die die Website dem Nutzer bereitstellen kann.
Große Datensätze werden in begrenzten Abschnitten exportiert. Wenn ein Abschnitt gekappt wird, enthält die JSON-Datei Fortsetzungsmetadaten, damit der Support erkennen kann, welche Daten noch verbleiben.
Die rechtliche Grundlage der Datenverarbeitung findest du im Datenschutz.
Öffne die Inhaltsmeldung im Footer der Website und füge Links zum Original, zur strittigen Veröffentlichung und zu Nachweisen der Urheberschaft hinzu. Eine genaue Meldung hilft der Moderation schneller.
Verbotene Handlungen mit fremden Mods und Dateien sind in den Website-Regeln beschrieben.
Eine Übersetzung darfst du nur veröffentlichen, wenn der Originalautor, die Lizenz oder die Regeln der Quellplattform es erlauben. Nenne den Autor, verlinke das Original und beschreibe die Nutzungsbedingungen.
Wenn die Erlaubnis fehlt oder Weiterverteilung verboten ist, lade keine fremden Dateien hoch. Du kannst stattdessen eine Anleitung veröffentlichen und auf den Original-Mod verlinken.
Die vollständige Version steht auf der Seite Website-Regeln. Prüfe sie vor dem Veröffentlichen von Mods, Builds, Übersetzungen oder sensiblen Inhalten.
Veröffentliche keine Raubkopien, gestohlenen Mods, Malware, Stealer, Miner, Doxxing, Belästigung, illegalen Inhalte, DRM-Cracks, Warez oder Inhalte, die Spiel- oder Plattformregeln verletzen.
Für NSFW- und 18+-Inhalte gelten eigene Einschränkungen. Prüfe vor der Veröffentlichung die Website-Regeln.
Die Moderation kann Inhalte ausblenden, Dateien entfernen, Warnungen vergeben, Kontoaktionen einschränken oder Konten sperren. Die Maßnahme hängt vom Verstoß, der Kontohistorie und dem Risiko für Nutzer ab.
Das Entfernen eines einzelnen Inhalts bedeutet nicht, dass alle anderen Inhalte des Autors automatisch freigegeben sind. Jeder fragliche Inhalt kann separat geprüft werden.
