Survive the Storm

The overhaul mod this workspace is building: a crossover of Against the Storm and Surviving Mars, for the base game. These pages are the mod's design and current state: most features are built (untested in-game), a few still planned - each feature's Status says which.

Three pillars: randomize (each run is unique), rebalance (no single best path), escalate (harder over time). Each feature has a status (Planned, Confirmed with the designer, Built untested, Implemented) and the base-game code that identifies the target.

Feature groups

• Cut features - base-game features the mod removes (the "No ..." list).
• Randomization - what makes each playthrough different.
• Rebalance and difficulty - retuned mechanics and rising pressure.
• Resupply cost rebalance - retuned Earth import costs and weights, plus the Supply Pod price (own page).
• Special projects - every special project you send a rocket to: the Trade projects (one per rival), the SETI Satellite / Comm Satellite / Contract Exploration Access reworks, and the vanilla projects, with the launch-fuel rule (own page).
• Food spoilage - from Sol 15, about a quarter (random) of stored Food rots every night, everywhere it is kept (own page).
• Test mode - one development switch that cheapens and lightens all Earth imports to a tenth and unlocks the food-testing conveniences; off in every shipped build (own page).
• First rocket loadout - the first cargo rocket you call in-game opens pre-filled with a default loadout you can edit; optional RC Explorer added when the rocket has room (own page).
• Cycle-clock - planned Against-the-Storm-style dial showing the colony's place in a repeating 12-sol Cycle (three 4-sol phases); design spec.
• Ideas - unbuilt, unscheduled ideas for the mod.
• General Balance - the general vanilla-number rebalances (buildings, food, economy, rivals) built into the mod.
• Run setup - how each run's map conditions and its sponsor / commander / mystery are randomized and decided in-game (overview; differs from vanilla).
• Sponsors and Commander Profiles - the sponsor and commander-profile rebalances built into the mod.
• Applicant generation - how fast each sponsor's recruit pool fills, the Tourist share, how applicants leave the pool, and the reworked "Live From Mars" tech.
• Trading - each rival colony offers its Trade Good as a Special Project, bought with Rare Metals instead of selling to your own sponsor.

Cut features

Base-game features the mod removes entirely: the "No ..." list. The Status column tracks each feature from design to in-game test (Planned, Confirmed, Built untested, Tested). The Base-game code column names where the feature lives; the Implementation column records how the mod removes it.

Sources

Base game (Steam app 464920) plus the Space Race (gagarin.hpk) and Below and Beyond (picard.hpk) DLC, decompiled (method: docs/reading-surviving-mars-code.md). Asteroid and underground content is switched off while Below and Beyond stays loaded (its darkness overlay powers "Map black at start"): IsDlcAccessible("picard") reads the shared g_AccessibleDlc table (Lua/init.lua:29-30), so setting g_AccessibleDlc["picard"] = false turns off every runtime picard check at once (resource, rocket, UI, tech and building filters). The mod requires every DLC and warns at load if any is missing (Code/StS_RequireDlc.lua). See also docs/rival-tech-exchange.md.

Randomization

What makes each playthrough different: randomized values, and information hidden or chosen during play so no two runs start the same. Status is Planned, PoC built, or Built. The last column points to the base-game code, with UNVERIFIED for a spot not yet located.

Map black at start (hidden map) - full documentation

The surface starts fully black and is uncovered by scanning. Implemented and tested in-game as Code/StS_HiddenMap.lua. Requires Below & Beyond (picard): the darkness is that DLC's underground overlay, forced onto the surface.

Three stages of visibility

Every sector is in one of three stages, re-evaluated as sectors are scanned. A sector is stage 3 when it is unexplored and none of its eight neighbours is scanned; stage 2 when it is unexplored but touches a scanned sector; stage 1 when it is scanned.

• Stage 1, scanned: fully revealed, full sector rollover. The game already scans one or two starting sectors at colony start (Exploration:InitialExplore, Lua/Exploration.lua:983-1035, picked by InitialReveal at :896-981), so there is always a lit starting point.
• Stage 2, next to a scanned sector: partly revealed (a scanned sector's reveal circle spills into its eight neighbours), rollover still shows the "High chance this Sector contains" hint and the buildable area, and it can be scanned.
• Stage 3, everything else: dark; its rollover shows only the sector status (no buildable area, no resource hint); it cannot be selected for scanning; and it lies outside the build radius, so no building can be placed there (see below). Exploration spreads outward from already-scanned sectors.

The darkness overlay

Surviving Mars has no surface fog of war; the terrain is fully visible from the first frame. The only real terrain-darkness is the Below & Beyond underground overlay, and it can be driven on the surface:

• Enable: the engine render var hr.RenderRevealDarkness. The surface ships with it 0 (off); setting it to 1 turns the pass on. This one flag was the whole blocker. Found via ChoGGi's "Show All Underground" mod, which sets it to 0 to reveal everything.
• Band: the darkness is a height-band fog, set by hr.RevealDarknessY / RevealDarknessYThreshold / RevealDarknessRevealed (false = darkness active) / RevealDarknessFalloff. The mod computes the band once per map from the terrain height (GetActiveTerrain():GetAreaHeight()).
• Re-assert: the game flips RenderRevealDarkness back to 0, so a real-time thread re-applies the vars every 0.5 s, but only while a map with sectors is live (calling GetActiveTerrain off-map throws a terrain != nullptr error).
• Reveal a sector: place a RevealDarkness object at the sector centre with SetRadius. The radius is not in world units: ~600 covers one sector (a sector is ~40960 wide), roughly an 88x scale, so a world-unit value reveals the whole planet. Placed for every scanned sector at start and on Msg("SectorScanned", ...) (Lua/Exploration.lua:120).

The base game ships only stubs (Lua/RevealDarkness.lua:9,21, CanReveal returns false), which is why the DLC is required. It coexists with "No underground / No asteroids": that content is removed in code so the DLC can stay loaded for this overlay (see Cut features).

Rollover, scan, and build blocking

Four base-game methods are wrapped at ClassesBuilt:

• Rollover. OverviewModeDialog:GenerateSectorRolloverContext (Lua/UI/OverviewModeDialog.lua:522-664) concatenates the whole rollover body into one RolloverText (the "High chance..." hint at string id 4053, the buildable area at id 4051). For a stage-3 sector the wrap replaces that body with just the status line, hiding the buildable area and the resource hint while leaving the scan-interaction hint.
• Scan queue. MapSector:CanBeScanned (Lua/Exploration.lua:166, gated by QueueForExploration at :596) returns false for stage-3 sectors, so they cannot be queued; the "scan available" notification and the rollover scan hints read the same method and follow.
• Orbital probe. OrbitalProbe:ScanSector (Lua/OrbitalProbe.lua:87) scans without checking CanBeScanned, so the wrap ignores stage-3 targets there too (blocks Blue Sun / AdaptedProbes probing a far tile).
• Construction. ConstructionController:UpdateConstructionStatuses (Lua/Construction/Construction.lua:1582) gathers the placement cursor's statuses; the wrap appends an error-type status (StS_DarkSector) when the cursor sits outside the build radius. The build radius is the on-screen boundary around scanned sectors: a spot is buildable while it is within BUILD_RADIUS_PCT of the sector width from the nearest scanned sector centre, and blocked past that. On the standard sector width of 40960 world units and the default BUILD_RADIUS_PCT = 130 that is a radius of 53248 world units. Lower BUILD_RADIUS_PCT to decrease the radius. Placement is refused when the first status is an error (:1883) and any error sorts ahead of every warning (:80-87), so the cursor turns red and the click does nothing. The base game's own "Unexplored sector" status is only a warning (:26), which is why building in the dark was allowed before. This blocks every building, Sensor Towers included.

Known caveat: zoom / camera

The darkness is a height-band fog, so it is camera-height dependent: zoomed in a sector reads black, zoomed far out more of the map reads revealed. Caves never show this because underground clamps the camera zoom; the surface allows full zoom-out. Tuning the band, or constraining zoom, is the open item.

Base-game alternative not used: camera lock

Considered but not used, kept as a fallback if the DLC dependency is ever dropped: LockCamera / UnlockCamera freeze all camera movement while leaving the UI clickable (Lua/Camera.lua:29-37, Lua/PhotoMode.lua:171-174), and cameraRTS.SetCamera aims at the starting sector (Exploration.InitialSector). That hides the map by pinning the view rather than darkening the terrain, and needs no DLC.

Sources

Base game, paths relative to external/SurvivingMars. Sensor scanning, sector reveal and the initial reveal are in Lua/Exploration.lua; the sector rollover and scan click in Lua/UI/OverviewModeDialog.lua; orbital probe scanning in Lua/OrbitalProbe.lua. The underground darkness system is in Lua/RevealDarkness.lua (base stubs), driven in the Below & Beyond DLC and via hr.RenderRevealDarkness (found in ChoGGi's "Show All Underground"); camera locking in Lua/Camera.lua and Lua/PhotoMode.lua.

Random colony site - full documentation

The pre-game Colony Site screen is skipped: the player never picks a landing spot and never sees the map's Threats and Resources in advance. Clicking NEXT on the rocket payload screen starts the game on a random landing spot, and that button is relabeled START ON RANDOM SITE. Implemented as Code/StS_RandomColonySite.lua. No DLC required.

Requirement: every existing landing spot equally likely

A landing spot is a whole-degree (latitude, longitude) coordinate on Mars, and the map is a deterministic hash of that coordinate (seed = xxhash(lat, long), Lua/UI/PlanetUI.lua:1591), so each coordinate is one fixed map. The requirement is that every such coordinate has the same chance of being drawn. Two of the game's own helpers are deliberately not used because they violate this:

• GenerateRandomMapParams (Lua/PreGameMission.lua:655) draws only from the 5 landing spots flagged quickstart, so it can produce just 5 maps.
• GenerateRandomLandingLocation / SeedToSpherePoint (Lua/UI/PlanetUI.lua:1605) picks a point uniformly over the sphere's surface area. Because meridians converge at the poles, a 1°×1° cell near the equator covers far more area than one near a pole, so equator coordinates would be picked far more often and pole coordinates rarely - not equal per spot.

Instead the mod draws latitude and longitude directly and uniformly over the whole-degree grid, so every coordinate (poles included) is equally likely: lat = (AsyncRand(181) - 90) * 60 gives -90..90° and long = (AsyncRand(360) - 180) * 60 gives -180..179° (180 and -180 are the same meridian, so 360 distinct values avoids double-counting). AsyncRand(n) returns 0..n-1 (Lua/PreGameMission.lua:664); coordinates are in arc-minutes (degree×60), the unit the presets and RoundCoordToFullDegrees use (Lua/UI/PlanetScene.lua:248).

The pre-game flow it changes

New Game runs one dialog (PGMission) with three internal screens in order: sponsor, payload, landing (Lua/XTemplates/PGMission.lua:11). The payload screen's NEXT action only switches the dialog to the landing screen (OnActionEffect="mode", OnActionParam="landing", Lua/XTemplates/PGMissionPayload.lua:141-147). That landing screen is the Colony Site (PGMissionLandingSpot), which lists THREATS (string id 4271) and RESOURCES (id 4270) and whose START button picks the map and begins the game (Lua/XTemplates/PGMissionLandingSpot.lua:192-197,361,401). The mod makes the game start at the point the Colony Site screen would open, so that screen never functions.

Skipping the screen

The Colony Site screen builds its context object through the global LandingSiteObjectCreateAndLoad (Lua/UI/PlanetUI.lua:1515). The same function feeds two other screens - the challenge landing screen and the in-game planetary view for expeditions and asteroids - so it must not be hijacked wholesale. The three callers are distinguishable by their flags: the challenge screen passes challenge_mode = true, the planetary view passes planetary_view = true, and only the pre-game mission call passes neither (Lua/XTemplates/PGMissionLandingSpot.lua:7, PGChallengeLandingSpot.lua:7, PlanetaryView.lua:7). The mod wraps the function and acts only when both flags are false, leaving the other two screens untouched.

Picking the site and starting

• Random spot. Latitude and longitude are drawn uniformly over the whole-degree grid (see the requirement above): every existing landing spot equally likely. The chosen lat, long are passed to GetOverlayValues, which writes latitude, longitude and seed onto g_CurrentMapParams (Lua/UI/PlanetUI.lua:1594-1602) - the fields START requires. The rocket name chosen on the payload screen is left untouched (unlike GenerateRandomMapParams:670, which would regenerate it).
• Start. The exact sequence of the screen's own START action, run in a CreateRealTimeThread: WaitWarnAboutSkippedMods(), MarkNameAsUsed("Rocket", g_CurrentMapParams.rocket_name_base), GenerateCurrentRandomMap() (Lua/UI/PreGameMenus.lua:241, matching Lua/XTemplates/PGMissionLandingSpot.lua:192-197).

Relabeling the NEXT button

Because NEXT now starts the game, the payload button is relabeled. Its label is the string NEXT (id 5453), shared by the sponsor, payload and landing screens, so the shared string is left alone; instead the mod sets ActionName on the one payload next action node inside XTemplates.PGMissionPayload (found by a small recursive walk of the template tree). Setting a template action's ActionName at run time is the game's own idiom (Lua/XTemplates/GameCheatShortcuts.lua:440, Lua/XTemplates/PlanetaryView.lua:1165). The new label is Untranslated("START ON RANDOM SITE"), which sidesteps any translation-id clash. Both the wrap and the relabel install at ClassesBuilt.

What is given up

Skipping the screen also removes its CUSTOM-coordinates entry, which let a player type exact coordinates to replay a specific map (Lua/XTemplates/PGMissionLandingSpot.lua:247), and the up-front Altitude / Temperature / Topography readout, not only Threats and Resources.

Choose your Commander - full documentation

The Commander Profile is chosen in two stages. On the setup screen the Commander row is a multi-select "Possible Commanders" checklist of which commanders can appear this run (all checked by default; Below and Beyond commanders and vanilla Politician hidden). The colony then starts with no commander, and a non-dismissable "Select your Commander" notification appears on the map at colony start; clicking it opens a choice of a random three drawn from the checked commanders and the chosen one's bonuses are applied live. In Code/StS_CommanderChoice.lua, matching the sponsor choice; the setup checklist is the shared framework in Code/StS_MissionPoolUI.lua (mechanism described under Choose your Mystery). No DLC required.

The choice notification. A non-dismissable "Select your Commander" notification is added on CityStart and LoadGame (guarded, so it never shows once the commander is chosen). Clicking it opens the choice; picking a commander removes the notification. Same click-notification pattern as the sponsor and the "Map Conditions" readout (AddCustomOnScreenNotification / RemoveOnScreenNotification, Lua/UI/OnScreenNotification.lua:708,778); the callback is a named global so it persists by name across a save.

No commander at start

The commander is read everywhere through GetCommanderProfile() (Lua/PreGameMission.lua:268-276) and applied at colony start in Colony:Init (Lua/Colony.lua:53, :81) and Colony:GameStart (Lua/Colony.lua:396, :403); its bonus_rockets is read by GetStartingRockets (Lua/City.lua:310-313). The mod wraps GetCommanderProfile to return a custom no-effect placeholder (PlaceholderCommanderProfile, defined in items.lua) until the player has chosen, so every start-time read gets an empty profile and the colony begins with no commander bonus. The placeholder replaces the game's built-in None profile, a degenerate stub with no display name or effect that made the in-game Mission Profile dialog throw when it resolved the commander text, hiding the Mission Goals list; the placeholder carries the same no-effect behaviour but valid, neutral fields, so the dialog renders and the goals show. Reading at the consumption point makes this immune to the pre-game flow resetting mission params. The "chosen" state is a key on g_CurrentMissionParams, which is wiped per new game by InitNewGameMissionParams (Lua/PreGameMission.lua:187-209) and persisted by PersistSave (:221-225), so it is false for a fresh colony and restored on load.

Hiding the commander from the setup UI

Three separate places show the commander before the game, each patched additively:

• The selector row is dropped from GetMissionParamUICategories (Lua/X/XPGMission.lua:172-190), the same wrap used for the Game Rules row.
• The "Effects" summary on the Mission Setup screen is GetDescrEffects (Lua/PreGameMission.lua:535-566), which reads the raw g_CurrentMissionParams.idCommanderProfile (:550) and prints a "Commander Profile:" header plus effect only when that effect is non-empty (:554-558). The mod runs the original with the commander forced to None (whose effect is blank), so the whole block is skipped, then restores the value.
• The "Welcome to Mars, Commander!" popup at game start (PopupNotificationPreset WelcomeGameInfo, Data/PopupNotificationPreset.lua:319-330) hardcodes a "Commander Profile: <commander_name>" line that with no commander renders empty. The mod rewrites that preset's text to the same body and Sponsor line without the commander line.

The event and applying the bonuses live

Clicking the "Select your Commander" notification shows WaitStoryBitPopup (Lua/MarsStoryBits.lua:58-79), the game's own choice popup, with a random three drawn from the full commander pool (every profile except the None and Random placeholders, so the mod's added Prospector is included), re-rolled each game. On the pick it reproduces every bonus colony start would have applied:

• Effect bonuses - profile:EffectsApply(UIColony) runs Funding, ModifyLabel (via SetLabelModifier, which applies to existing and future buildings), GrantTech (colony:SetTechResearched) and ModifyLabelOverTime (Lua/MarsGameEffects.lua:85,164,398).
• Bonus techs tech1..tech5 (the non-effect grants, e.g. City Mayor's Mars Nouveau) - granted with UIColony:SetTechResearched (Lua/Research.lua:269), the same call GrantTech uses.
• Bonus rockets (Rocket Scientist's +1) - spawned exactly like City:CreateSupplyShips (Lua/City.lua:305-306): PlaceBuildingIn(GetRocketClass(), map_id, {city}).
• Start-with-a-deposit-revealed (Astrogeologist's Rare Metal and the mod's Prospector's Water) - not an effect object; the base game does it once at start in Exploration:InitialExplore (Lua/Exploration.lua:1002-1024) for its Hydro Engineer and Astrogeologist, which never fires with no commander, so the mod replicates it on the pick (find the nearest unplaced SubsurfaceDepositMarker near the initial sector and PlaceDeposit). In this mod the Water deposit belongs to the new Prospector, not Hydro Engineer (see the rebalance below).
• Keep 1 unresearched revealed tech per field - a commander grant researches a tech via SetTechResearched, which (unlike normal research) reveals no replacement while the field still has research available (Lua/Research.lua:293-297), dropping the field below the 1 from 1 tech revealed per field. The mod tops every discoverable field back to 1 revealed-unresearched with DiscoverTechInField (Lua/Research.lua:214); researched techs are always also discovered (:278), so discovered - researched is the revealed-unresearched count.

Audit and status

The commander roster is built from scratch (full list: Commander Profiles): every offered profile is wiped and rebuilt to one perk, one free tech and one prefab or unit, sorted into four groups (Water, Colonist, Economy, Other), 16 profiles, 4 per group. The apply path is unchanged - EffectsApply runs the perk (Effect_ModifyLabel) and the prefab (Effect_GrantPrefab), tech1 grants the free tech, bonus_rockets spawns Rocket Scientist's rocket, the deposit reveal covers Prospector and Geologist, and a supply-pod cargo drop delivers the three rover units (RC Transport, RC Explorer, RC Commander). The vanilla preset ids are reused so id-coupled perks still fire - only Psychologist needs it, its +5 rest-sanity reading Lua/Units/Colonist.lua:1692. The pick mechanism (checklist, notification, popup) is tested; the from-scratch roster is Built, untested (v2.95). As a PoC this targets new colonies; on load of a picked save the choice and its baked-in bonuses persist and nothing re-applies.

Choose your Mystery - full documentation

The Mystery is chosen in two stages. On the setup screen the Mystery row is a multi-select "Possible Mysteries" checklist of which mysteries can appear this run; the colony then starts with no mystery, and on sol 50 an event offers three of the checked mysteries and the chosen one starts live. In Code/StS_MysteryChoice.lua, with the shared checklist framework in Code/StS_MissionPoolUI.lua. No DLC needed.

The setup-screen pool

The base game already appends every accessible mystery to the Mystery row's item list at ClassesBuilt (Lua/PreGameMission.lua:154-178). The mod replaces that row's list item with a checkbox item (cloned from the shipped Game Rules checkbox, Lua/XTemplates/GameRuleItem.lua, using GetCheckboxImage, Lua/GameRules.lua:112) whose checkbox toggles a set on g_CurrentMissionParams, and hides the "Random"/"None" pseudo-entries. Mysteries you have not finished are pre-checked and finished ones start unchecked, read from AccountStorage.FinishedMysteries (set on MysteryEnd, Lua/Mysteries/Mysteries.lua:102-110); finished mysteries keep their green check. The collapsed row shows "All possible" or "N of M possible" by wrapping PropChoice:OnPropUpdate (Lua/XTemplates/PropChoice.lua:28-56). The set persists and resets with the rest of the mission params (PersistSave / InitNewGameMissionParams, Lua/PreGameMission.lua).

No mystery at start

At colony start Colony:Init calls SelectMystery (Lua/Colony.lua:63), which reads g_CurrentMissionParams.idMystery and sets self.mystery_id (Lua/Mysteries/Mysteries.lua:11-44). The mod overrides it to select nothing for a normal game (tutorial and challenge keep the base behavior). The override must be installed on g_Classes.Colony, not the Mysteries parent: HGE flattens inherited methods into the subclass at build time, so overriding the parent after ClassesBuilt does not reach Colony's already-flattened copy.

The sol-50 20:00 event

At sol 50 20:00 - checked on NewHour, firing once day == STS_MYSTERY_DAY and hour >= STS_MYSTERY_HOUR (or any later sol, as a load backstop), the same evening hour as the Sol 1 survey and the goal picks - a WaitStoryBitPopup (Lua/MarsStoryBits.lua:58-79) offers three mysteries drawn from the checked pool: one random pick from each difficulty tier where the pool has one, then the remaining slots filled from the rest of the pool. Difficulty is the mystery class's challenge_mod - 20 Easy, 40 Normal, 60 Hard - and the label is already in the display name ("... (Easy/Normal/Hard)"). If the pool is empty (every mystery unchecked) it falls back to the full accessible list. Picking one starts it by replicating CheatStartMystery (Lua/Mysteries/Mysteries.lua:114-165) minus its cheat gate: set mystery_id, add the mystery's techs to research, then InitMysteries which creates the mystery object and fires MysteryChosen.

Status

Tested (v2.41, in-game). The colony starts with no mystery, the setup checklist pre-checks unfinished mysteries and shows the "N of M possible" summary, and the sol-50 event offers three from the checked pool. New colonies only; a chosen mystery persists in the save. The v2.42 follow-up hides Below and Beyond mysteries from the list (built, not re-tested in-game). Known base-game trait: mysteries are authored to begin at colony start, so a chosen mystery's opening event may fire right away when it starts on sol 50.

Pre-Founder event choice - full documentation

The vanilla Pre-Founder Stage event pool is emptied and replaced by the mod's own hand-authored events. In the night between Sol 2 and Sol 3 the mod force-fires one of them at random: the player never picks which event fires, only how to answer its replies. So exactly one pre-founder event happens per game. In StS as Code/StS_PreFounderEventChoice.lua. No DLC required. The vanilla pool - 19 events, triggers, choices and rewards - is documented in story-events.html.

Emptying the pool

The pre-founder events are the StoryBits with Category = "Tick_BeforeFounders" (Data/StoryBit/Boost*.lua, 19 in the base game). The engine adds each to the per-game triggerable list at game start only if it is Enabled and passes its EnableChance roll (Docs/ModItemStoryBit.md.html: EnableChance is "the initial chance for this StoryBit to be added to the list of StoryBits which may be triggered in each game"); the runtime list is g_StoryBitStates, keyed by id (Lua/Buildings/PlanetaryAnomaly.lua:171). At ClassesBuilt the mod sets EnableChance = 0 and Enabled = false on every such StoryBit, so none is added at start and none fires on its own. Verified by the CityStart log line, which lists the pre-founder ids still in g_StoryBitStates (expected: none). Rocket Short-circuit (Boost17) is not in this category - it fires on a manual rocket launch, its own trigger - so it is left untouched.

The event and firing one live

In the Sol 2 to Sol 3 window (checked each game hour and on load; skipped under the tutorial and the Story Bits Disabled game rule), the mod picks one of its own StS_PF_ events at random - only ones the player currently qualifies for, i.e. whose every StoryBit Prerequisite passes now (the same cond:Evaluate the engine runs to gate a normal tick; the pre-founder prerequisites are colony-wide, and the events with none always qualify), and drops any whose reward would be redundant. The chosen event is force-fired with ForceActivateStoryBit(id, MainMapID, false) - the same call shipped code uses (Lua/Buildings/PlanetaryAnomaly.lua:338) - which starts the event immediately, ignoring suppression, delay and prerequisites (Docs/ModItemStoryBit.md.html, ActivateStoryBit). The chosen preset is flipped back to Enabled / EnableChance 100 just before, so its one-time state records normally. The chosen id and a "shown" flag live on g_CurrentMissionParams (wiped per new game, persisted on load), exactly as the Commander and Mystery choices; a force-fired one-time StoryBit records its state, so nothing re-fires on load.

Status

Built, untested (v48). Two engine behaviours the build's logs confirm: that disabling keeps the events out of g_StoryBitStates at start (the CityStart log), and that ForceActivateStoryBit fires the chosen event despite the empty pool (the fire log prints state_before=false state_after=true).

Map conditions foundation - full documentation

The shipped code in Code/StS_MapModifiers.lua is the foundation of the map-conditions system: it rolls each colony's conditions, stores them, exposes them to the per-condition code, and shows the notification. It applies no gameplay effect - every condition's effect is built in its own follow-up file. The full per-condition design and game-code translation is on the Map conditions page; this section documents only what the foundation does. No DLC required.

The roll

Five conditions are rolled once per colony; the sixth (Topography) is derived from the map, not rolled. Each rolled condition has one medium value (rocket "pods", the others "even") and two extremes (rocket fast/big, weather dust/cold, funding metals/tourism, sensor range/boost, vistas vistas/research). Across all six conditions every run lands on exactly two medium and four extreme. Topography is not rolled but counts toward the target (rough is its medium, flat/steep its extremes), so the five rolled conditions fill the rest: rough Topography leaves one medium and four extreme among the five, an extreme Topography two medium and three extreme. Because Topography is only known reliably in-game, the roll persists a plan - a Fisher-Yates-shuffled priority order of the five plus a drawn extreme direction for each - and StS_GetMapCondition resolves the medium/extreme split on demand against the live Topography (the first N in the order are medium, N = 1 if rough else 2). Draws use AsyncRand(n) (0..n-1).

Persistence

The plan (the priority order plus each extreme's direction) lives in one GlobalVar("StS_MapConditions", false), which the engine serializes into the save automatically (Docs/LuaSavegame.md.html:11,19). It is rolled in OnMsg.NewGame - which fires on a new colony but not on load - guarded by an "already set" check, the same pattern the base game uses for its own session randomness (g_SessionSeed = g_SessionSeed or AsyncRand(), Lua/Colony.lua:89-94). This replaces the earlier three binary slots and their StS_GetMapModifier API; the only external reader (Code/StS_HarsherDisasters.lua) fetches the old function with rawget and treats it as absent, so dropping it does not crash.

The read API

Three globals, for the per-condition files to consume (they fetch via rawget(_G, "StS_GetMapCondition"), since reading an undefined global throws in the mod sandbox):

• StS_GetMapCondition(name) returns a condition's current value: for a rolled condition, resolved from the stored plan against the live Topography (see The roll); topography itself is derived live. Topography reads the active map's challenge rating (ActiveMapData.challenge_rating, engine-populated per map, so it is valid in-game and after load, for random and fixed maps alike) and buckets it the way the game's own local MapChallengeRatingToDifficulty does (Lua/UI/PlanetUI.lua:93-103): ≤59 flat, ≤99 rough, else steep (folding the game's Steep and Mountainous). A value not rolled returns nil, which every consumer treats as its default.
• StS_MapConditionText - a table each condition fills at ClassesBuilt with a function returning its readout line (StS_MapConditionText.sensor = function() ... end). Empty in the foundation.
• StS_MapConditionOrder - the fixed display order rocket, weather, funding, sensor, vistas, topography.

The notification

A pinned notification is added on CityStart and LoadGame with the game's modding hook AddCustomOnScreenNotification (Lua/UI/OnScreenNotification.lua:708) as dismissable = false, expiration = -1 so it stays for the whole run (idempotent by id, so re-adding on load does not duplicate). Clicking it opens a CreateMessageBox (Lua/UI/MarsMessageQuestionBox.lua:133) that walks StS_MapConditionOrder and prints one line per condition: the condition's own readout if it has registered one, otherwise a Label: value fallback so the notification is meaningful before any effect file ships. The click callback is a named global so it need not be persisted. Player-facing wording is a first draft.

Status

Tested v2.9. The roll, persistence, read API and notification are in place, and all seven per-condition effects are now built (untested) in their own files. Targets new colonies: a colony started before the foundation shipped has no roll, so it shows no notification until a new game.

Rebalance and difficulty

Retuned mechanics and rising pressure: no single best path, and a game that gets harder over time. Status is Implemented, Confirmed, or Planned. The last column points to the base-game code, with UNVERIFIED for a spot not yet located.

Feature	Status	What it does	Base-game code
Building and tech descriptions	Tested v2.56	Every building the mod rebalances states its new, non-vanilla values on its own in-game description, and the tech that unlocks it does the same, so the player reads the change where he builds or researches instead of guessing from remembered vanilla values. Covers MOXIE, Power Accumulator, Sensor Tower, the three large factories and the Ranch, plus the unlock techs Low-G Hydrosynthesis, Micro Manufacturing and 3D Machining. Set on BuildingTemplates[id], ClassTemplates.Building[id] and the tech's TechDef[id] at ClassesBuilt, with the base text stashed once so reloads never compound. In StS across the building rebalance files (for example Code/StS_MoxieRebalance.lua, Code/StS_FactoryStaffingCurve.lua, Code/StS_FoodRebalance.lua).	description on BuildingTemplate (Data/BuildingTemplate.lua); tech description via the TechDef GlobalMap (ClassDef-PresetDefs.generated.lua:1116); translated-string append (CargoTransporter.lua:978)
Resupply cost rebalance	Tested v2.9	Retunes Earth import costs and weights plus the Supply Pod price. Singly-bought items (per unit): Orbital Probe 100 to 200 M and 1,000 to 2,000 kg (Adapted Probes still halves the price to 100 M), Supply Pod 100 to 200 M, Drone Hub 150 to 200 M, Drone weight 1,000 to 500 kg. Bulk resources (per 5 units): Food 20 to 40 M and 2,000 to 5,000 kg, Machine Parts 90 to 100 M, Polymers 70 to 150 M, Electronics 100 to 150 M; Metals and Concrete unchanged. In StS as Code/StS_ResupplyCosts.lua.	Data/Cargo.lua; Lua/ResupplyItems.lua:19-72; sponsor pod_price (Lua/Buildings/SupplyPod.lua:165-171)
Rocket launch fuel	Tested v2.121	Every rocket needs 40% more Fuel to launch, for every sponsor - extending to the whole map the launch-fuel drawback the Paradox Interactive sponsor carries alone in vanilla. It is a percentage on each rocket's own launch fuel, so a standard rocket rises from 50 to 70  and SpaceY's lower-fuel Dragon Rocket scales from its own base and stays proportionally lower; Paradox keeps its own flat +30 on top (a standard rocket 70 + 30 = 100). The Advanced Martian Engines tech's flat -20 then lowers a standard rocket to 50 (its description now states this). The map-wide rule is announced on the General Rules readout, not on a building. In StS as Code/StS_RocketFuelCost.lua.	each rocket's launch_fuel (standard rocket base 50, Data/BuildingTemplate.lua:2910) via a percent modifier on the AllRockets label - the same Effect_ModifyLabel path the Paradox sponsor's flat +30 uses (Data/MissionSponsorPreset.lua:857-861, Lua/MarsGameEffects.lua:164-176); modifiers combine as base × (100 + Σpercent) / 100 + Σamount (Lua/Modifiers.lua:24,99); applied on CityStart/LoadGame, idempotent (Lua/LabelContainer.lua:38-43)
Inflation always on	Tested v54	A custom inflation, always on for every colony (the player cannot turn it off, the Game Rules selector is removed). It replaces the base game's Inflation game rule (+10% every 20 sols) and is faster and broader: prices rise by 1% of their base each sol starting on sol 2 (sol 1 stays at base, +0%; sol N is +(N-1)%), capping at sol 201 (+200%, triple price) and held flat after - the shared sol-201 endpoint of the Escalate ramps. Applied to every import (all resources, all prefabs, rovers) plus the Rocket purchase price and the Supply Pod price. In StS as Code/StS_Inflation.lua.	cargo via ModifyResupplyParams (Lua/ResupplyItems.lua:93); Rocket price g_Consts.RocketPrice (Lua/X/XPGMission.lua:398); Supply Pod price GetMissionSponsor().pod_price (Lua/Buildings/SupplyPod.lua:166); driven each sol on NewDay (Lua/DayTime.lua:56)
Research output decay	Tested v2.31	Every research point the colony earns is worth less the longer the game runs - the output-side mirror of an additive cost inflation, replacing the old per-field cost ramp. Each tech keeps its honest base cost; instead the value of each point falls on the shared sol-201 curve: output = 100 / (100 + steps), steps = clamp(sol - 1, 0, 200), so 100% at sol 1, 50% at sol 101, 33% at sol 201, then held. Drives both real accrual and the on-screen "Research per Sol". In StS as Code/StS_ResearchOutputDecay.lua; overview Escalation to sol 201.	Research:ModifyResearchPoints (Lua/Research.lua:624) - the chokepoint every earned point flows through (AddResearchPoints :680) and what GetEstimatedRP returns for the UI (:805); paired with UnmodifyResearchPoints (:634) so the leftover carryover (:698-699) stays exact. Wrapped on g_Classes.Colony (flattened).
Terraforming tech cost	Tested v2.251	Green Planet ships every Terraforming research tech at twice the standard per-tier cost: the field's 22-tier cost curve is the standard 1000..40000 curve every other field uses, doubled to 2000..80000, and only the Terraforming Initiative sponsor discounted it, so for every other sponsor terraforming cost double. This halves the field's base costs, so terraforming techs cost the standard per-tier amount for all sponsors. The Terraforming Initiative sponsor's own discount is a separate lever, retuned from 50% to 30% (in Code/StS_SponsorEffects.lua), so that sponsor pays 30% below a standard tech (0.7x) instead of merely cancelling the old doubling. New colonies only (an existing save baked each tech's cost at colony start). In StS as Code/StS_TerraformingTechCost.lua.	field costs armstrong/Presets/TechFieldPreset.lua vs the standard curve Data/TechFieldPreset.lua:5-28, read once per colony by Research:InitResearch (Lua/Research.lua:153-166); the sponsor's Effect_TechBoost {Field="Terraforming"} applied via BoostTechField and combined as MulDivRound(cost, 100 - boost, 100) in Research:TechCost (Lua/Research.lua:356-382,400), field boosts summed and capped at 80% (:412)
Harsher disasters	Tested v2.9	Dust Storms and Cold Waves escalate over the game, each rising linearly from 10% of sols active on day 1 to 50% on day 201 (20% by day 51, 30% by day 101), then capped. Intent: start around High and reach roughly Extremely High by day 51, then climb past any vanilla level - the numbers are kept round (10-50%) for readability, so they do not match vanilla exactly. From day 100 the two can run at the same time. Overrides the landing site's rating so every run escalates the same. Storm type is pinned to a third each (plain / Great / Electrostatic), ~67% dangerous. The build drives the linear duty-cycle curve above (see notes). Full matrix: disaster difficulty.	disaster data (see disasters.html); Lua/MapSettings.lua, Lua/DustStorm.lua, Lua/ColdWave.lua
Meteor Storms scatter map-wide	Tested v2.14	A regular (weather) Meteor Storm drops its meteors on independent random passable tiles across the whole map instead of concentrating them in one drifting ~1 km capsule. Vanilla covers only ~13% of the map in a single stripe, so a storm either misses the base or hammers one spot of it; this keeps the same meteor count and cadence (~58 per sol) but spreads the barrage map-wide, so most storms clip the colony in rough proportion to its footprint rather than wiping one area. Scripted story/mystery strikes (the "Meteor Storm on your colony" punishment, the Bomb, the Last War bombardment) are left aimed at their dome. In StS as Code/StS_MeteorScatter.lua; base mechanic and coverage math in meteors.html; difficulty scale in disaster difficulty.	Lua/Meteors.lua:88-106 (SpawnMeteor: no pos uses GetRandomPassable, uniform whole-map, Lua/Pathfinding.lua:1-6); ambient storm call has no pos (:304) vs scripted strike passing a dome pos (Lua/ClassDefs/ClassDef-Effects.generated.lua:2504); thread keying via CurrentThread() (Lua/Buildings/BaseBuilding.lua:400)
Meteor and Dust Devil escalation	Tested v2.9	The mod escalates Meteors and Dust Devils over the game to fixed abstract targets, scaling linearly from day 1 to day 201 then held: Meteors 0.1% to 1% of the map struck per sol and Dust Devils 0.1% to 1% of the map covered (both 0.325% by day 51, 0.55% by day 101). These are abstractions, not game settings - see Disaster abstractions for how they are translated into the spawn parameters that produce them (storm-driven meteors; devil wave interval). Alongside the amount, every meteor is pinned large and every devil Major and Electric. Sits alongside the live Meteor scatter and the Harsher disasters (Dust / Cold) curve. In StS as Code/StS_MeteorDevilEscalation.lua. Full matrix: disasters.html.	Meteors storm_spawntime / spawntime / multispawn_chance (Data/MapSettings_Meteor.lua, Lua/Meteors.lua); Dust Devils spawntime / count_min/max / spawn_chance / major_chance (Data/MapSettings_DustDevils.lua, Lua/DustDevils.lua); driven per sol like Code/StS_HarsherDisasters.lua
Dust Devils during Dust Storms	Built, untested (v1.9)	In the base game Dust Devils cannot exist while a Dust Storm is up - the wave scheduler parks and a starting storm deletes every live devil. The mod lets the two coexist (as it already does for Dust Storm + Cold Wave), so the escalating devil coverage is not throttled by the mod's frequent storms. Done additively, without replacing the base scheduler or removing the deletion: on storm start a mod handler respawns and then maintains the day's target devil population until the storm clears. In StS as Code/StS_DevilsInStorms.lua (see notes).	base pause on HasDustStorm (Lua/DustDevils.lua:192,203, markers :154); storm-start wipe OnMsg.DustStorm (Lua/DustDevils.lua:472) fired by StartDustStorm (Lua/DustStorm.lua:142); spawn via GenerateDustDevilIn
Cold ground rewards	Built, untested (v2.7)	Turns cold ground (surface heat below 210, the vanilla cold-penalty threshold) from a pure penalty into a tradeoff: Solar Panels and Wind Turbines on it produce +20% power, research buildings in a dome on it produce +20% research, and every building on it accumulates 20% less dust (passive, storms and devils). Re-checked hourly so it follows cold waves, heaters and terraforming; the vanilla cold penalty is left in place. Full logic and hooks: Cold ground page. In StS as Code/StS_ColdGround.lua.	see the Cold ground page Sources; key hooks Lua/Buildings/ColdSensitive.lua:40-42, Lua/Heat.lua:165, Lua/RequiresMaintenance.lua:178
Earthsick from Morale	Built, untested (v2.96)	Earthsick no longer comes from Comfort hitting 0. Instead each sol a colonist below Morale 50 has a chance to turn Earthsick - chance = 100 - 2 × Morale percent, certain at Morale 0 and none at 50+ - and recovers once Morale reaches 70. Comfort still matters, but only as one of the three stats that feed Morale. Immunities are unchanged (Martianborn, Refugee, the IMM sponsor, Iron Colonists), and each fresh case still removes 2 applicants. In StS as Code/StS_EarthsickChance.lua; full page: earthsick.html.	Colonist:ChangeComfort (Lua/Units/Colonist.lua:3256-3281) replaced to drop the Comfort trigger and clear; per-sol roll and recovery on NewDay (Lua/DayTime.lua:56) over UIColony:GetCityLabels("Colonist"); GetMorale (Lua/Units/Colonist.lua:3285-3287); warning text Lua/StatusEffects.lua:323

Research cost ramp - removed

This mechanic is no longer in the mod. It was replaced by research output decay (Code/StS_ResearchOutputDecay.lua): instead of making techs more expensive, the mod now shrinks research output over time. The detailed notes below describe the old cost ramp and are kept only until this section is rewritten.

Each technology already researched in a field adds a flat +10% to the research-point cost of every other not-yet-researched technology in that same field. It is additive, not compounding: with N techs already researched in the field, an unresearched tech in it costs base × (100 + 10×N) / 100 - so the 1st tech in a field is base cost, the 2nd +10%, the 3rd +20%, the 4th +30%, and on. Fields are independent: researching in Physics never changes a Biotech cost. Intent: an incentive to skip the techs you do not need, field by field. Implemented as Code/StS_ResearchCostRamp.lua. No DLC required.

One cost function, paid and shown together

Research:TechCost(tech_id) (Lua/Research.lua:356) is the only function that returns a tech's point cost. It is what the colony pays - the research-completion check reads it (AddResearchPoints, Lua/Research.lua:686; also the cheapest-tech pick at :654 and the queue-cost preview at :395) - and what the player sees: the "Research cost" line in a tech's rollover flows GetResearchInfo (Lua/Research.lua:751) -> TechPreset:Getcost (Lua/ClassDefs/ClassDef-PresetDefs.generated.lua:1140) -> the rollover text (Lua/Research.lua:1351). Wrapping this one function makes the ramp both real and visible with no second edit.

Counting per field

For the priced tech's field (its own status.field) the wrapper counts the other techs actually researched in that field: it walks the field's tech list, skips the priced tech itself, and counts only those whose status.researched is greater than 0. Both rules are necessary, and together they make the tech-select rollover and the research-queue line show the same number:

• Skip the priced tech. A tech must never inflate its own cost. This also removes a select-vs-queue mismatch: the queue prices each entry through ResearchQueueCost (Lua/Research.lua:384-398), which temporarily writes the priced tech's own status.researched before calling TechCost (its way of pricing a repeatable tech queued more than once). Counting the priced tech would then read that temporary value and add a bogus +10% to the very first queued tech, so the queue read 1,100 while the rollover read 1,000. Excluding the priced tech makes both paths agree.
• researched > 0, not merely set. In this Lua build 0 is true, and the temporary value ResearchQueueCost writes for an unresearched tech is 0. The game's own Research:IsTechResearched returns that 0 (truthy), so counting by truthiness would miscount an unresearched tech as researched. Testing researched > 0 explicitly avoids that.

• Repeatable techs (e.g. Martian Patents). Their status.researched is a count that is >= 1 once researched, so a repeatable tech is counted once from its first research and its repeats never add; and being self-excluded, it never ramps its own repeat cost.
• Free techs from a sponsor or commander are exempt. A tech handed to the colony for free - the base sponsors' Effect_GrantTech bonus, the mod's per-sponsor starting tech, and the picked commander's tech1..5 (e.g. City Mayor's Mars Nouveau, Prospector's Deep Water Extraction) and Effect_GrantTech (e.g. Deep Scanning) - is excluded from the count, so it never raises its field's cost: it is completely free, and the other techs in its field do not get more expensive because of it. It has to be tracked explicitly, because SetTechResearched records nothing that tells a free grant from paid research (both set status.researched = 1). Each grant site records the tech id into a per-colony, save-persisted set (StS_FreeGrantedTechs) - the sponsor techs on the StS_SponsorChosen event (StS_SponsorStartingTech), the commander techs when the profile is applied (StS_CommanderChoice), both re-marked on load - and the per-field count skips any tech in that set. (Before v3 a free tech counted like any researched one and raised the rest of its field +10% from colony start.)
• Breakthroughs. Every breakthrough shares the group "Breakthroughs" (Lua/Research.lua:299; Data/TechFieldPreset.lua:203, a non-discoverable field) and is listed into tech_field["Breakthroughs"] at InitResearch, so each researched breakthrough raises every other breakthrough by +10%. Mysteries and Storybits are their own separate groups (Data/TechFieldPreset.lua:211,220) and ramp only within themselves.

Implementation

One hook. At ClassesBuilt the mod wraps TechCost on g_Classes.Colony - the class UIColony is actually instantiated from (Colony:new(), Lua/Colony.lua:99) - not on the Research parent it is inherited from. HGE flattens inherited methods into the subclass at build time, so overriding the parent after ClassesBuilt does not reach Colony's already-flattened copy; this is the same log-confirmed reason StS_MysteryChoice overrides g_Classes.Colony.SelectMystery rather than the Mysteries parent. The wrapper runs the original, reads the field's count of OTHER researched techs (priced tech excluded, researched > 0, free sponsor/commander techs excluded), and returns MulDivRound(cost, 100 + 10×N, 100) (integer fixed-point, this is an integer-only Lua build). Because the result is a multiplier, the true original is stashed once on the class table and the wrapper is always rebuilt from that stash, so the re-firing ClassesBuilt never double-wraps or compounds. No cap: with many techs in a field the last few get expensive, which is the point.

Status

Tested. In-game on a fresh colony every field's first tech reads its base cost, identical in the tech-select rollover and the research queue (the earlier select-vs-queue +10% mismatch is gone), and the ramp is per field. Verified from the colony-start dump (base = select = queue in every field at zero researched) and confirmed in play.

Disaster abstractions - read before implementing

The mod's disaster difficulty is written as abstract target numbers, one per threat, chosen to be human-comparable (the matrix on the Disasters page):

• Dust Storm / Cold Wave - % of sols the disaster is active, each rising linearly day 1 to day 201: 10% / 20% / 30% / 50% at days 1 / 51 / 101 / 201 (cap). Built in v1.9 - Code/StS_HarsherDisasters.lua.
• Meteors - % of the map struck by meteors per sol, linear: 0.1% / 0.325% / 0.55% / 1% at days 1 / 51 / 101 / 201 (the meteor count the implementer solves for, all large).
• Dust Devils - % of the map under a dust ring at any moment, linear: 0.1% / 0.325% / 0.55% / 1% at days 1 / 51 / 101 / 201 (all Major and Electric).

For whoever implements the Meteor and Dust Devil scaling (LLM or human): these target numbers are not game settings and cannot be written into a preset directly - the game has no "meteors per sol" or "percent of map covered" field. You must translate each target into the spawn parameters that produce it, running the wiki's derivations in reverse:

• Meteors - first turn the coverage target into a per-sol count (coverage x 4096 x 4096 m map / average blast disc, ~1,516 sq m at the vanilla 10% large-share), then meteors per sol = 58 x (storm active share) + (individual events per sol) x (meteors per event). Solve for the gaps: storm_spawntime for the storm part, spawntime / multispawn_chance for the individual part. Derivation: meteors.html, disasters.html.
• % of map covered = (avg devils present) x (avg dust-ring area) / map area, with avg present = spawn rate x lifetime. Solve for spawntime, count_min/max, spawn_chance (and major_chance for the ring mix). Derivation: dust-devils.html#coverage.

Always verify the implemented spawn settings reproduce the target number (in-game or by the formula), not just that the code runs. The abstraction is the spec; the preset values are the means.

Harsher disasters - full documentation

Dust Storms and Cold Waves escalate over the whole game and, from sol 100, can run at the same time. The mod drives each of the two to a fixed duty-cycle curve - the fraction of the time that disaster is active on the map - and overrides whatever Dust Storm / Cold Wave rating the landing site rolled, so every run follows the same escalation. Built in v1.9 and awaiting its first in-game test - Code/StS_HarsherDisasters.lua. No DLC required (both are base-game disasters). The base mechanics and the numbers this builds on are in disasters.html.

Each disaster is active on a plain linear ramp: 10% of sols on day 1 to 50% on day 201 (20% at day 51, 30% at day 101), overlap unlocking at day 100. (Meteors and Dust Devils escalate on the same 0.1% -> 1% curve, in disaster abstractions / StS_MeteorDevilEscalation.lua.) The curve is the matrix; it is absolute, replacing the site's rolled intensity entirely.

The abstraction: duty cycle

Duty cycle is the share of the time one disaster is active: d = length / (length + gap). Dust Storm and Cold Wave each target the same d independently. In the base game the two never overlap and are not frequent or long enough to fill much of the time (see how much of the time a storm is running and how the two are kept apart); the mod raises each toward half the sols and lets them overlap past day 100 (below).

The escalation curve

Each disaster's duty rises on a fixed linear curve, the same for every landing site:

From the curve to storm numbers

To climb the curve the mod scales each storm's length up and the gap between storms down together (an equal split, so "longer" and "more frequent" contribute the same): the target ratio r = length/gap = d/(1 - d), and each storm is scaled from its day-1 baseline (Dust Storm 30 h / 180 h, Cold Wave 60 h / 360 h, both r0 = 1/6) by f = sqrt(r / r0) - length len0 * f, gap gap0 / f - with a +/-25% random band. The resulting averages:

There is no length step-down: each disaster's duty is independent, so overlap unlocking at day 100 (below) changes only whether the two may co-exist, not the length/gap math.

Overlap from sol 100

The base game allows only one weather disaster at a time through the shared IsDisasterActive() check in each scheduler (see disasters.html). From sol 100 the mod wraps that check so a lone Dust Storm or Cold Wave no longer reports the map as busy to the other, letting the two run together; a Mystery Dream or Rain disaster still blocks, as before. Every disaster effect - freezing, dust, solar penalty, grounded rockets, stalled construction - reads HasColdWave / HasDustStorm directly, not IsDisasterActive, so both storms keep full effect when they overlap; only the screen tint shows one at a time.

Storm type

Each Dust Storm rolls plain, great (double dust) or electrostatic (lightning) at about a third each, replacing the base game's low great / electrostatic chances. Set in the storm-type roll (Lua/DustStorm.lua:376-385) by raising both chances; the engine's 0-100 roll makes it 33.7 / 32.7 / 33.7.

Weather condition: Dust Storm vs Cold Wave prevalence

The Weather map condition re-weights the 50/50 split between the two disasters: a Dust:Cold prevalence edge of +/-33% (dust / even / cold). Inside the same OverrideDisasterDescriptor wrap, each disaster's target duty is multiplied by its share (dust: Dust x1.33, Cold x0.67; cold: the reverse; even: x1). The two shares always sum to 2, so the combined weather load stays exactly on the curve - only the mix shifts. Read from StS_GetMapCondition("weather"); it replaces the earlier duration-bias slot (the retired STS_WEATHER_LENGTH_BONUS_PCT / StS_GetMapModifier).

Implementation

Implemented as Code/StS_HarsherDisasters.lua (v1.9, first in-game test pending). Integer fixed-point throughout - this is an integer-only Lua build, so the curve math uses MulDivRound and the integer sqrt, no floats. Four parts, all on data the schedulers already read:

• Curve math. Pure functions: duty per-mille d(sol) (linear 100 -> 500), then r = d/(1-d), f = sqrt(r/r0) with r0 = 1/6, length len0*f and gap gap0/f, each emitted as a +/-25% min/max band. The weather condition scales each disaster's d by its prevalence share first.
• Force both on and override the site. On CityStart/LoadGame point ActiveMaps[MainMapID].MapSettings_DustStorm/_ColdWave at a non-forbidden preset so both always run, restarting the scheduler GlobalGameTimeThread if the site had that threat off (the dead-thread restart pattern from Lua/Disasters.lua:56-72).
• Inject the per-sol numbers. The game routes every disaster descriptor through OverrideDisasterDescriptor (Lua/MapSettings.lua:130), its own extension hook, once per storm cycle. The mod wraps it to write the current sol's length (min_duration / max_duration) and gap (spawntime / spawntime_random) plus the 34/33 storm-type chances onto the descriptor. Absolute values every call, so no compounding.
• Unlock overlap at sol 100. Wrap IsDisasterActive (Lua/MapSettings.lua:181): nothing active -> false; before the overlap sol -> vanilla; Mystery Dream / Rain up -> still blocks; else (a lone Dust Storm and/or Cold Wave) -> report not-busy, so the two stop blocking each other.

Test switches in the file: STS_DEBUG (extra logging plus a one-shot forced overlap at sol 6, via the schedulers' own trigger messages so no "already present" assert) and STS_OVERLAP_SOL (lower it, e.g. to 5, to reach overlap without waiting). Both ship at release values (false / 100); turning them on prints the per-sol numbers and forces a Dust Storm + Cold Wave overlap at sol 6, so the escalation can be checked without a 100-sol wait.

Dust Devils during Dust Storms - full documentation

The base game never lets a Dust Devil exist while a Dust Storm is on the map: the devil wave scheduler parks whenever HasDustStorm is true (Lua/DustDevils.lua:192,203, and the fixed-spot markers at :154), and a starting storm deletes every live devil through OnMsg.DustStorm (Lua/DustDevils.lua:472, fired by StartDustStorm's Msg("DustStorm"), Lua/DustStorm.lua:142). Because the mod drives Dust Storms up to 50% of sols by day 201, that suppression would keep realized Dust Devil coverage far below the escalation target, so the mod lets the two coexist - the same idea as the Dust Storm + Cold Wave overlap above. Built in v1.9, awaiting its first in-game test - Code/StS_DevilsInStorms.lua.

Why not the storm / cold-wave trick. That overlap was unlocked by wrapping one function, IsDisasterActive, which only the two schedulers read while the actual effects read HasDustStorm / HasColdWave directly. Dust Devils read HasDustStorm directly, and that function is shared with every storm effect, so it cannot be wrapped globally - and there is an active per-storm deletion to fight on top. So the same one-line trick does not apply.

The approach: respawn and maintain, fully additive. Rather than replace the base scheduler or remove the deletion handler (both need engine-internal reach), the mod leaves the base untouched and fills only the storm window:

• Clear time stays 100% the vanilla base scheduler, spawning devils at the mod's driven rate through the usual descriptor injection.
• Storm start: the base wipe runs as normal, then an added OnMsg.DustStorm handler starts a game-time thread. The thread sleeps a tick first, so it is guaranteed to run after the base deletion regardless of handler order, then seeds the day's target population and keeps topping it back up until HasDustStorm goes false.
• Storm end: the thread exits and the base scheduler resumes for clear time. So exactly one spawner is ever active - the base while the map is clear, the mod while a storm is up.

How many to spawn. Not a live count - the base wipe runs before the mod handler, so the pre-storm number is already gone by the time we could read it, and it fluctuates anyway. Instead the target is the average devils-present N the escalation already aims for, derived from the live descriptor (count per wave x lifetime / wave interval, matching coverage = N x dust-ring area / map area). Because GenerateDustDevilIn always bakes a full fresh trajectory (no public way to seed a half-spent devil), the thread staggers its spawns by the descriptor's spawn delay so their deaths desync into the steady-state spread rather than a synchronized cohort. Minions add almost no area (dust-devils.html), so with the storm suppression removed the coverage target maps cleanly onto spawn rate x lifetime x ring area.

All through public calls the base game already uses - GenerateDustDevilIn, HasDustStorm, GetRandomPassableAwayFromBuilding - with no GlobalGameTimeThreadFuncs swap, no OnMsg removal and no bytecode probe. The base wipe is a one-shot at storm start (OnMsg.DustStorm, Lua/DustDevils.lua:472), so a devil spawned after that Msg("DustStorm") is not wiped and lives out the storm.

Sources

Base game, paths relative to external/SurvivingMars; Space Race in gagarin.hpk (decompiled). Disaster mechanics: disasters.html.