satisfactory: game.enableSeasonalEvents says what it does (7.0.0+upv1.9.10)

game.seasonalEvents was handed to the container unchanged, into the image's
DISABLESEASONALEVENTS. Its default true therefore wrote
DISABLESEASONALEVENTS=true: the seasonal events were OFF in every install
this chart has ever produced, while values.schema.json described the very
same key as "true means events are enabled" (#215).

Of the two ways out, this is the loud one. Inverting the template under the
old key would have flipped the behaviour of every existing release in
silence - the same class of mistake that created the issue. Renaming the key
cannot be missed: game.seasonalEvents no longer exists, additionalProperties
is false on the game block, and a values file that still carries it fails
schema validation on upgrade instead of quietly meaning the opposite.

The new key is positive (enableSeasonalEvents) to avoid a double negative,
so the chart negates it on the way into the env var. Go's "not" cannot do
that: it reads every non-empty string as true, and the schema deliberately
accepts the string form of booleans, so "false" would have flipped the wrong
way. The helper compares explicitly and fails on anything that is neither
true nor false rather than filing it under "off".

The default is enableSeasonalEvents: false, which renders the
DISABLESEASONALEVENTS this chart has always rendered. At chart defaults the
6.1.0 and 7.0.0 manifests are identical, so upgrading alone moves no server;
switching the events on is now a deliberate act with a key that means it.

Separate finding from the same issue, fixed here because it lives in the
block being touched: "--set game=null" - or a leftover "game:" whose
sub-keys were deleted - aborted the render with a nil pointer at
.Values.game.maxPlayers. The game block never got the null-safe treatment of
#99 that probes, security contexts and resources have. It now falls back to
the documented defaults, and the schema accepts the null accordingly. The
same gap remains in the dev and server blocks; it is reported, not fixed
here.

Major bump: a values key is removed, and the schema rejects it.

satisfactory/templates/NOTES.txt

@@ -17,9 +17,10 @@
 {{- if and (kindIs "float64" $startup.periodSeconds) (kindIs "float64" $startup.failureThreshold) -}}
 {{- $budget = printf "%.0fs x %.0f = %.0f minutes" $startup.periodSeconds $startup.failureThreshold (divf (mulf $startup.periodSeconds $startup.failureThreshold) 60.0) -}}
 {{- end -}}
-{{- $seasonalRaw := printf "%v" .Values.game.seasonalEvents -}}
-{{- $seasonalOff := eq (lower $seasonalRaw) "true" -}}
-{{- $beta := eq (lower (printf "%v" .Values.game.experimental)) "true" -}}
+{{- $game := fromYaml (include "satisfactory.game" .Values.game) -}}
+{{- $seasonalEnv := include "satisfactory.disableSeasonalEvents" $game.enableSeasonalEvents -}}
+{{- $seasonalOff := eq $seasonalEnv "true" -}}
+{{- $beta := eq (lower (printf "%v" $game.experimental)) "true" -}}
 {{- $debug := eq (lower (printf "%v" .Values.dev.debug)) "true" -}}
 {{- $outOfRange := or (lt $gamePort 30000) (gt $gamePort 32767) (lt $msgPort 30000) (gt $msgPort 32767) -}}
 {{- $skipRaw := "" -}}
@@ -213,14 +214,37 @@ RESOURCE LIMITS ARE COMPUTED FROM limitFactor ({{ $factor }})
   unlimited container gets throttled rather than killed — a memory limit can
   end a session, a missing CPU limit only slows it down.
 
-game.seasonalEvents IS PASSED THROUGH, NOT INVERTED
-  The chart hands game.seasonalEvents to the container as
-  DISABLESEASONALEVENTS unchanged. It is currently {{ $seasonalRaw }}, so the container
-  runs with DISABLESEASONALEVENTS={{ $seasonalRaw }} — seasonal events are {{ if $seasonalOff }}OFF{{ else }}ON{{ end }}.
-  {{ if $seasonalOff }}To turn them ON, set game.seasonalEvents: false.{{ else }}To turn them OFF, set game.seasonalEvents: true.{{ end }}
-  Read that twice: the value behaves as the opposite of what its name suggests
-  and of what values.schema.json claims. Believe this paragraph and the
-  rendered env var, not the key name.
+SEASONAL EVENTS — THE KEY WAS RENAMED IN 7.0.0, AND IT IS BREAKING
+  Seasonal (holiday) events are {{ if $seasonalOff }}OFF{{ else }}ON{{ end }} in this release: game.enableSeasonalEvents is
+  {{ $game.enableSeasonalEvents }}, which the chart negates into DISABLESEASONALEVENTS={{ $seasonalEnv }}.
+  {{ if $seasonalOff }}To turn them ON, set game.enableSeasonalEvents: true.{{ else }}To turn them OFF, set game.enableSeasonalEvents: false.{{ end }}
+
+  UPGRADING FROM 6.x — WHAT YOU HAVE TO DO
+  The old key game.seasonalEvents IS GONE. It is not deprecated and not
+  quietly accepted: values.schema.json rejects it, so a values file that still
+  carries it fails the upgrade with a validation error instead of installing
+  something you did not ask for. That noise is deliberate — see below.
+
+  Remove the old key and, if you want the events, add the new one:
+
+    game:
+      enableSeasonalEvents: true    # false, the default, keeps them off
+
+  AND THE MEANING IS INVERTED FROM WHAT THE OLD KEY'S NAME SUGGESTED
+  Up to 6.1.0 the value was handed to the container UNCHANGED, into a variable
+  whose name says the opposite: game.seasonalEvents: true wrote
+  DISABLESEASONALEVENTS=true. So the shipped default had the events switched
+  OFF, in every install, for as long as this chart has existed — while
+  values.schema.json described the same key as "true means events are
+  enabled". If you left the default alone believing that description, you have
+  never had seasonal events, and the new default (enableSeasonalEvents: false)
+  changes nothing about that: it renders exactly the DISABLESEASONALEVENTS
+  this chart has always rendered, so upgrading alone does not move your
+  server. You have to ask for the events, and now the key name means what it
+  says when you do.
+
+  Only true and false are accepted, boolean or quoted; anything else aborts
+  the render rather than being guessed at.
 
 THE USER ID IS PINNED, AND PUID/PGID DO NOTHING
   The pod runs as 1000:1000 because the image supports rootless operation only