Why a DayZ Setting Is Greyed Out, Blank or Ignored

One Rule Behind All of It

DayZ reads its settings out of files, once, when the server starts. It does not tell you when it ignored something, and for a key it cannot find it does not complain at all — it just uses its own idea of what that key means and carries on.

That is a good way to lose an afternoon. So the Settings tab is built around one rule: show what the game will actually do, and refuse a save that would change nothing. The three sections below are the three places you will see that rule at work.

The Format Hint on a Free-Text Field

Some DayZ settings only accept a value in a particular shape. Where that is true, the field carries a Format line under it saying so in words, with the exact rule beside it.

The clearest example is the map. Map / Mission is a dropdown of the maps your server ships — Chernarus, Livonia and Sakhal — plus a Custom… option for a community map. Choose Custom and the free-text box appears with:

Format: Two parts joined by a dot, like dayzOffline.chernarusplus. Letters, numbers, underscores and hyphens only — no spaces.

Start Time is the other one you will meet:

Format: Either SystemTime, or a fixed time written as YYYY/MM/DD/HH/MM — for example 2024/9/25/08/00 for 8am.

As you type, the field checks what you have written against that rule and says so immediately:

This does not look like the expected format. You can still save it — the server decides.

It is a hint, not a gate

That last sentence is meant literally. The warning does not grey out Save, does not discard your value and does not stop you. GameGrid's job here is to tell you before you restart, not to decide for you — the platform checks the value properly when you save, and the server is the final word on whether it works.

A value that is in the dropdown never shows a format hint, because there is nothing to get wrong.

A Missing Key Shows What the Game Does, Not What We Would Set

The serverDZ.cfg DayZ ships has about 24 of its 72 keys actually written in it. Everything else is absent, and DayZ has its own behaviour for an absent key.

So for 30 DayZ settings the platform records a second fact alongside the recommended value: *what the game does when this key is not in the file at all*. When the Settings tab reads your server and finds the key missing, it shows you the game's answer, not ours.

That sounds like a fine distinction. It is not:

• Your server is doing what the page says. A page that showed the recommended value for a key nobody had written would be describing a server that does not exist.
• Turning something off and leaving it off stays off. 0, false and an empty string are answers, and the panel never overwrites one of them.

This matters most for Use cfggameplay.json. DayZ reads a missing key as *no*, so a server whose serverDZ.cfg never mentions it is not reading the gameplay file — whatever anybody would recommend. GameGrid writes that key for you on a new server so the stated default is real rather than aspirational.

"Could not read" is not the same as "not there"

If the platform cannot reach your server's host at all, it does not guess. It tells you the values on screen are not a reading of your server, rather than quietly filling the page with plausible numbers.

Settings Marked "Ignored"

Nearly 60 of DayZ's settings do not live in serverDZ.cfg. They live in the mission's cfggameplay.json, which DayZ opens only when Use cfggameplay.json is on. Turn that off and the game never opens the file — so every one of those settings has a value, and the game is reading none of them.

The Settings tab does not hide them and does not let you edit them. It shows each one with its current value, a small ignored badge on the label, and the reason underneath:

Use cfggameplay.json is off, so this setting is ignored — turn it on to use it.

The control is replaced by plain text rather than a greyed-out box, because a control that cannot take effect should not accept a keystroke either. And the category itself carries a single notice at the top with a button that fixes it:

Use cfggameplay.json is off, so this setting is ignored — turn it on to use it. 12 settings below are affected. [Turn on Use cfggameplay.json]

Press the button and everything below it comes back to life straight away.

It works in both directions

Five serverDZ.cfg settings are taken over by cfggameplay.json when it is switched on — base damage, container damage, the respawn dialog, personal light and Night Lighting. With the gameplay file on, those five go the other way and read:

Use cfggameplay.json is on, so this setting is ignored — turn it off to use it.

Seven hit-direction settings sit two levels down: they are inside the gameplay file *and* behind their own override switch, so they are marked ignored while either one is off, with the reason that actually applies.

And a save is refused rather than faked

If something does get through — an older browser tab, the Customer API, a preset applied from an event — the platform refuses the write and says why:

Setting "…" is ignored by the game while "enableCfgGameplayFile" is 0 instead of 1, so it was not saved. Change "enableCfgGameplayFile" first.

A refusal you can act on is worth more than a green tick over a file the game never opens.

Everything Still Needs a Restart

None of this changes the basic fact about DayZ: the server reads its configuration once, at start. Every setting is marked as needing a restart, and a save while the server is running is queued and written before the next start — the panel says which happened, and offers to restart for you.

See DayZ Server Settings Reference for what each key does, and cfggameplay.json, Spawn Points and Starting Gear for the gameplay file itself.