> ## Documentation Index
> Fetch the complete documentation index at: https://docs.baimoqilin.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Im Multiplayer verwenden

> MineClawd auf dedizierten Servern mit klaren Berechtigungen, Sichtbarkeit und sicherem Rollout betreiben.

## Bereitstellungsmodell

* Installiere MineClawd auf dem Server, damit `/mineclawd` und `/mclawd` funktionieren.
* Die Client-Installation ist für die Kernbefehle optional.
* Die Client-Installation ist erforderlich für:
  * das GUI-Paket von `/mineclawd config`
  * die History-Buch-UI von `/mineclawd history`
  * Popup-Fragen für `ask-user-question`
  * die Overlay-GUI (AssistiveTouch-Orb, Streaming-Anzeige, Sessions und Assets)

<Info>
  Hat ein Spieler MineClawd nicht installiert, gibt es einen Chat-Fallback (`/mineclawd choose ...`). Alle Befehle funktionieren auch ohne Overlay.
</Info>

## Berechtigungsmodell und Admin-Kontrolle

* MineClawd-Befehle benötigen Vanilla-Berechtigungsstufe `2` (`source.hasPermissionLevel(2)`).
* Es gibt keine zusätzlichen Berechtigungsknoten pro Unterbefehl.
* Resultat: Gib OP nur an vertraute Operatoren.

Unterstützt dein Stack eine Remappung auf Befehlsebene, beschränke `/mineclawd` und `/mclawd` auf deine AI-Operator-Rolle.

## Sichtbarkeit auf ausgelasteten Servern

MineClawd speichert pro Spieler eine Sichtbarkeitsoption:

```bash theme={null}
/mineclawd config broadcast-requests-to <self|all|ops>
```

* `self`: Nur du siehst Prompt-Echo und Status.
* `all`: Jeder sieht es.
* `ops`: Nur Operatoren sehen es.

Die Einstellung liegt in `mineclawd/player-settings.json` und gilt pro Spieler-UUID. Du kannst sie auch im GUI-Konfigurationsbildschirm unter „Misc“ als „Broadcast requests to“ setzen.

## Session-Eigentum im Multiplayer

* Session-Daten bleiben pro Owner-Key.
* Spielerbefehle arbeiten mit dem Session-Set des jeweiligen Spielers.
* Konsolenbefehle nutzen einen separaten Owner-Namespace.

Entscheide früh, ob jeder Operator persönliche Sessions behält oder ob alle dasselbe Operator-Konto teilen.

## Dynamic Registry auf dedizierten Servern

Standardmäßig steht `dynamic-registry-mode` auf `AUTO`. In diesem Modus ist die Laufzeit für dynamische Platzhalter auf dedizierten Servern deaktiviert.

Um sie zu erzwingen:

```bash theme={null}
/mineclawd config dynamic-registry-mode enabled
```

Dann startet du den Server neu.

### Was sich ändert, wenn sie aktiviert ist

* Dynamische Item-/Block-/Fluid-Slots sind zur Laufzeit verfügbar.
* Der dynamische State-Sync geht an die Clients.
* Der persistente Weltzustand speichert die Slot-Daten.
* Clients brauchen ebenfalls MineClawd, um dem Server beizutreten.

<Warning>
  Aktiviere die Dynamic Registry auf Produktionsservern nur nach gestaffeltem Test. Die Client-Pflicht stellt eine harte Kompatibilitätsänderung dar.
</Warning>

## Empfohlene Operator-Baseline

| Ziel                        | Empfohlene Einstellung            |
| --------------------------- | --------------------------------- |
| Chat-Rauschen reduzieren    | `broadcast-requests-to ops`       |
| Lange Tool-Loops verhindern | `limit-tool-calls true`           |
| Schleifen begrenzen         | `tool-call-limit 8` bis `12`      |
| Nur Vorfälle debuggen       | `debug-mode true` (vorübergehend) |

## Rollout-Checkliste für Server-Betreiber

1. Lege zuerst deine Operator-Rolle und OP-Richtlinie fest.
2. Setze Provider- und Modell-Zugangsdaten.
3. Bestimme die Broadcast-Richtlinie (`self`, `ops` oder `all`).
4. Entscheide, ob die Dynamic Registry auf `auto` bleibt oder auf `enabled` wechselt.
5. Teste mit zwei echten Accounts (Operator + Nicht-Operator), bevor du öffentlich gehst.

## Verwandte Seiten

* [/commands/overview](/commands/overview)
* [/commands/config](/commands/config)
* [/configuration/complete-config](/configuration/complete-config)
* [/resources/troubleshooting](/resources/troubleshooting)