# Host Settings

Host settings are game-rule values authored by the current host and applied to runtime systems. They are separate from player-local settings and from public lobby/server discovery metadata.

## Sources

Resolved host settings come from:

1. Dedicated server `server_settings.json`.
2. Pending main-menu lobby settings for a listen/P2P host.
3. Existing synced session rules, once connected.
4. Code and convar defaults.

The create-lobby UI seeds its pending values from saved local lobby defaults before the lobby is created.

Connected clients should read the resolved values from synced host runtime state, currently `MatchSessionState.RulesJson`, rather than from Steam lobby metadata.

## Registry

Settings that should be discoverable across console, lobby UI, dedicated config, and server-info UI should be marked with `HostSettingAttribute` next to their existing `ConVarAttribute`, then registered in `HostSettingsRegistry.BuildDefinitions()`.

s&box whitelist mode blocks runtime reflection APIs such as `Assembly.GetTypes()` and `PropertyInfo.GetValue()`, so the registry is intentionally explicit rather than reflection-scanned. If we later add source generation, the attribute can become the source of the generated registry entries.

Example:

```csharp
[ConVar( "ttt_karma" )]
[HostSetting(
	Id = HostSettingIds.KarmaEnabled,
	Group = "Rules",
	Label = "Karma",
	Surface = HostSettingSurface.Lobby | HostSettingSurface.Dedicated | HostSettingSurface.Console | HostSettingSurface.ServerInfo,
	Mutability = HostSettingMutability.NextRound
)]
public static bool KarmaEnabled { get; set; } = true;
```

The registry lives under `Code/Game/Host/Settings`.

## Metadata Boundary

Do not use `Networking.SetData`/`GetData` for rich TTT rule settings. The metadata budget is too small and should stay reserved for tiny compatibility hints only when native lobby fields are insufficient. Runtime gameplay settings must be applied by the host and synced through normal networked state after clients connect.