v0.0.5 - Pre-Alpha Playtest

Pre-Alpha Playtest

Pre-alpha. Most features have been verified end-to-end in playtesting but a few item types remain untested at runtime - see "Known issues" below. If you join a multiworld with this release, mention to your group that you're running a pre-alpha; otherwise it should behave well in single-player and small multi-player setups.

Provided as-is, no warranty. The authors are not liable for any issues arising from use.

v0.0.5 is a Hazardous Weather trap mechanism overhaul over v0.0.4. The visible behavior change: a Hazardous Weather trap now arrives with the game's native 3-day "Drought/Badtide approaching" countdown notification, hazardous runs its full intended duration, and the cycle ends cleanly afterwards. v0.0.4's extended-badtide bug (~17-day hazardous instead of 7) is fixed.

Why the redesign

v0.0.3 / v0.0.4 used temperate-shortening (reflection-write <TemperateWeatherDuration>k__BackingField to currentDay + 3) and let the game's natural cycle transition fire hazardous. UX was correct (3-day countdown) but the trap-induced badtide ran far longer than intended on long-running saves like Crator. Drought testing on v0.0.4 surfaced the symptom as "water spawning broken in the following temperate cycle." Cause was misdiagnosed as state-bleed across the cycle boundary.

The v0.0.5 first attempt was direct-trigger via StartHazardousWeather(). That fixed the duration math but produced wrong player UX - the hazardous fired instantly with no notification.

The v0.0.5 final design (this release) returns to temperate-shortening but also writes GameCycleService._cycleDurationInDays to match the new TempDur + HazDur. The discovery during Session J runtime verification: _cycleDurationInDays is a CACHE computed at cycle start from the registered ICycleDuration providers, and the game's OnDaytimeStart cycle-end check (day > _cycleDurationInDays → StartNextCycle()) reads the cached value, not the live providers. Mutating only TemperateWeatherDuration shortened the temperate phase but left the cycle running its original full length, so hazardous extended from the (correctly early) transition all the way to the original cycle boundary - typically ~17 days instead of HazDur=7. The water-spawn regression observed in v0.0.4 was almost certainly the prolonged badtide depleting water-source state past quick recovery, not a state-bleed across cycles. Writing both backing fields together fixes the duration AND the regression at its root.

Trap behavior in v0.0.5

• Trap arrives during temperate → game's native "Drought/Badtide approaching" notification appears with 3-day countdown widget in the top-right
• After 3 in-game days, hazardous fires via the game's normal WeatherService event chain; drought-vs-badtide is whatever the game's own HazardousWeatherRandomizer had pre-rolled for the cycle
• Hazardous runs its full intended duration (HazDur, randomized per cycle)
• Cycle ends naturally at newTempDur + HazDur days; next cycle starts in a clean state via GameCycleService.StartNextCycle(), which re-randomizes TemperateWeatherDuration and recomputes _cycleDurationInDays from fresh providers
• During an active hazardous (or while another trap is still queued), additional traps queue with trap_mode: queue (default) or are discarded with trap_mode: skip

Everything shipped in v0.0.4 is also in v0.0.5

For the full v0.0.4 fix list, see the v0.0.4 release notes. For the bigger v0.0.3 feature/fix list (crash fix, PostLoad boost re-apply, ConnectionBlocked reset, DiscoverBonusIds validator, reflection dry-runs, filler goods injection fix, ExtraEarlySurvival option, population milestone threshold bump), see the v0.0.3 release notes.

Known issues (unchanged from v0.0.4)

• Hungry / Thirsty Beavers traps silent no-op. NeedManager reflection paths (<AllNeeds>k__BackingField, Need.NeedId) don't resolve against the current Timberborn.NeedSystem.dll. The trap-fire summary log line ([Archipelago/Trap] HUNGRY_BEAVERS fired: affected=0) now appears even when the effect can't be applied, giving trap-delivery visibility we didn't have on v0.0.4.
• T3 progression items can land at T1 shop slots. Fill algorithm places items based on slot access rules but doesn't tier-gate by item requirements.
• Boosts apply to bots in addition to beavers. BonusManager attaches to both.
• "Unknown location: Victory: Population" warning on goal completion. Cosmetic, goal still fires correctly.
• Water Storage goal silent-fail on both factions (broken GoodId reflection path; deferred to v0.0.6+).
• Bots goal unwinnable on Folktails (no faction-gating in _resolve_goals; deferred to v0.0.6+).

Installation

1. Extract Archipelago.zip into your Timberborn mods folder (Documents/Timberborn/Mods/)
2. Place timberborn.apworld in your Archipelago custom_worlds/ folder
3. Requires Archipelago 0.6.7

YAML template

Timberborn.yaml attached - a verbose weighted YAML template with every option documented. Drop into your Archipelago Players/ folder as a starting point.

Changelog since v0.0.4

Mod:

• v0.0.5 Hazardous Weather trap redesign: queue + temperate-shortening + cycle-duration cache write + passive OnCycleStarted hook + EventBus injection
• Bump manifest to v0.0.5.0

APWorld:

• Bump archipelago.json world_version to 0.0.5 (no functional APWorld changes from v0.0.4)