# 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` on the runtime owner property. If the setting is also a console variable, keep the existing `ConVarAttribute` next to it.

s&box whitelist mode blocks runtime reflection APIs such as `Assembly.GetTypes()` and `PropertyInfo.GetValue()`, so the game does not discover host settings at runtime. Instead, run the repo-time generator after changing `[HostSetting]` attributes:

```powershell
dotnet run --project Tools/HostSettingsGenerator
```

To verify the checked-in generated registry is current:

```powershell
dotnet run --project Tools/HostSettingsGenerator -- --check
```

The generator writes `Code/Game/Host/Settings/HostSettingsRegistry.Auto.cs`, which contains direct typed accessors. That generated file is normal game code and is safe for the platform whitelist.

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.