BeaverBuddies Stability Fork — 1.1.10

The current release, on top of 1.0.9. It contains everything from the three 1.1.10 pre-releases (1.1.10-release-candidate, -2 and -3): a cheaper pass over every entity on each tick, a plainer connection panel, and chat drawn in the color of each player's cursor. See the changelog.

Played in multiplayer: the fork owner played 1.1.10 over Steam invites for more than an hour, in large colonies (300+), and reported that it worked very well. Screenshots of a host and a guest show the panel rows, the bold own row, the header without its dot, the boxed collapse button and whole chat lines in each player's color. Not checked: how much time the entity pass saves has not been measured, and lines already written changing color after a cursor color is changed has not been checked. The zip is a fresh build of the same source as -3 with only the version changed to 1.1.10; the checks below ran against it.

Every player should install this build: the join check compares the mod build, so it will not join a session with an earlier version, including the pre-releases. Nothing new is sent over the network.

The pass over every entity on each tick is cheaper

Before each batch of entities ticks, this mod visits every entity in it to keep the animation of the ones that walk in step between the players. It looked up a component on every entity, on every tick, and folded every entity into two hashes that only the detailed log prints. In a two-player recording of a colony with 11,464 entities (361 of them walkers, speed 7, 11.7 ticks a second) that pass took about 7 ms a tick, about a fifth of the guest's 36 ms tick; roughly 3.3 ms of it was that lookup.

It now remembers which entities walk, and the two hashes are only kept while detailed logging is on. Nothing that is simulated, sent or saved changes. Expected saving: roughly 3 to 6 ms a tick (an estimate, not yet measured). It does not fix the frame rate that falls over a long session at a high speed: that time is spent in Unity's late-update phase, outside this mod.

A plainer connection panel

• One dot. While the panel is expanded, the dot beside the sync status is the only one. A collapsed panel keeps its own.
• A player's row is a name and a ping. The "You" and "Host" tags are gone. A guest reads its own ping to the host on the host's row.
• Your own row is bold, with a dash where the ping would be.
• The collapse button has a box around it, so it is not mistaken for that dash.

Chat takes the cursor colors

A chat line, name and message, is drawn in the color you see on that player's cursor: the color they chose, or the one you set for them under Options → Player cursors. Changing that color recolors lines already written. Your own lines use your Ping Color.

Validation

Steam and non-Steam release builds with no warnings · 210/210 StabilityTests · 69/69 RuntimeChecks against the built mod · 3 Python checks. None of them can draw the panel. The README, changelog and panel document in the zip describe 1.1.10, and the website has been updated for it.

Install

1. Fully close Timberborn on every computer.
2. Delete the old BeaverBuddies-Stability-Fork folder from Documents\Timberborn\Mods, then extract BeaverBuddies-Stability-Fork-1.1.10.zip and copy the BeaverBuddies-Stability-Fork folder in.
3. The mod list shows version 1.1.10.

Check the download against 1.1.10-SHA256SUMS.txt:
Get-FileHash .\BeaverBuddies-Stability-Fork-1.1.10.zip -Algorithm SHA256

BeaverBuddies Stability Fork — 1.1.10-release-candidate-3 (pre-release)

A pre-release for testing, built from commit 29729da (the tag v1.1.10-release-candidate-3), on top of 1.1.10-release-candidate-2. It contains everything in that pre-release (the plainer connection panel and chat in the cursor colors), everything in 1.1.10-release-candidate (the cheaper pass over every entity on each tick) and everything in 1.0.9. The latest stable release is still 1.0.9.

Every player should install this build: the join check compares the mod build, so it will not join a session with a different one. It does not include the frame rate log from the 1.0.10-perflog-preview pre-releases. It changes one thing, and it is presentation only: no gameplay change, no fix, nothing new sent over the network.

Changed: the collapse button has a box around it

In 1.1.10-release-candidate-2 the button that collapses the panel (a small "-", or "+" while collapsed) sat at the right edge of the header, directly above the "-" that stands for your own ping, and the two looked alike. The button now has a thin box around it so it reads as a button. It does what it did before, and clicking the title still collapses and expands the panel.

What has been seen in a game

Screenshots of 1.1.10-release-candidate-2 (a host alone, then with a guest) showed the panel changes working: the header without its dot with the sync dot as the only one, player rows that are a name and a ping, your own row in bold with a dash, and that the game's font draws bold. They are also what showed the two dashes stacked, which this release addresses.

Validation

Steam and non-Steam release builds with no warnings · 210/210 StabilityTests · 69/69 RuntimeChecks against the built mod · 3 Python checks. None of them can draw the panel. The DLLs in this zip are the ones those ran against.

Not tested: how the boxed button looks in a game, and chat lines in the cursor colors, also after a color is changed. A screenshot with a few messages from both players, and one after changing a player's cursor color under Options → Player cursors, is the useful thing to send back.

Install

1. Fully close Timberborn on every computer.
2. Delete the old BeaverBuddies-Stability-Fork folder from Documents\Timberborn\Mods, then extract BeaverBuddies-Stability-Fork-1.1.10-release-candidate-3.zip and copy the BeaverBuddies-Stability-Fork folder in.
3. The mod list shows version 1.1.10-release-candidate-3.

Check the download against 1.1.10-release-candidate-3-SHA256SUMS.txt:
Get-FileHash .\BeaverBuddies-Stability-Fork-1.1.10-release-candidate-3.zip -Algorithm SHA256

BeaverBuddies Stability Fork — 1.1.10-release-candidate-2 (pre-release)

A pre-release for testing, built from commit 7639ea9 (the tag v1.1.10-release-candidate-2), on top of 1.1.10-release-candidate. It contains everything in that pre-release (the cheaper pass over every entity on each tick) and everything in 1.0.9, and changes how the connection panel looks and what color chat is drawn in. Not yet run in a game. The latest stable release is still 1.0.9.

Every player should install this build: the join check compares the mod build, so it will not join a session with a different one. It does not include the frame rate log from the 1.0.10-perflog-preview pre-releases. What it adds is presentation only: no gameplay change, no fix, nothing new sent over the network.

Changed: a plainer connection panel

• One dot. While the panel is expanded, the dot beside the sync status (green, yellow or red with the status) is the only one. The dot beside the title and the dots beside each player are gone. A collapsed panel is one line with no status row, so it keeps its own dot.
• A player's row is a name and a ping. The "You" and "Host" tags are gone. The host reads each guest's ping. A guest reads its own ping to the host on the host's row, and the ping the host measured for every other guest. Over 80 ms the number is yellow and over 160 ms red, and "No response" is red.
• Your own row is bold, with a dash where the ping would be, since you have no ping to yourself.

Changed: chat takes the cursor colors

A chat line, name and message, is drawn in the color you see on that player's cursor: the color they chose (their Ping Color), or the one you set for them under Options → Player cursors. Change that color and the lines already written change with it, within a moment. Your own lines use your Ping Color. A player who has left, or whose cursor is off, keeps the color you saved for them, else the one their messages carried. A color too dark to read on the panel is lightened, as before. Before, only the name was colored, and always in the color the player chose for themselves.

What to look at

This is the first time any of the panel and chat changes are seen in a game, so a screenshot of the expanded panel with a few chat lines is the useful thing to send back. In particular: whether your own row really draws in bold (it depends on the game's font), that the header no longer has a dot, and that a chat line changes color when you change that player's cursor color. The panel screenshot in the README still shows the 1.0.9 layout.

Validation

Steam and non-Steam release builds with no warnings · 210/210 StabilityTests (two new: the ping on every row, and the color saved for a player who is not connected) · 69/69 RuntimeChecks against the built mod · 3 Python checks. The DLLs in this zip are the ones those ran against.

Not tested: how any of the panel and chat changes look in a game. That includes the header without its dot, the player rows, whether the game's font draws your own row in bold, and chat lines in the cursor colors, also after a color is changed. The interface cannot be built outside the game, so none of it can be checked without one. The entity pass from the release candidate has not run in a game either.

Install

1. Fully close Timberborn on every computer.
2. Delete the old BeaverBuddies-Stability-Fork folder from Documents\Timberborn\Mods, then extract BeaverBuddies-Stability-Fork-1.1.10-release-candidate-2.zip and copy the BeaverBuddies-Stability-Fork folder in.
3. The mod list shows version 1.1.10-release-candidate-2.

Check the download against 1.1.10-release-candidate-2-SHA256SUMS.txt:
Get-FileHash .\BeaverBuddies-Stability-Fork-1.1.10-release-candidate-2.zip -Algorithm SHA256

BeaverBuddies Stability Fork — 1.1.10-release-candidate (pre-release)

A pre-release for testing, built from the branch entity-pass-rc, on top of 1.0.9. It contains everything in 1.0.9 (the Steam ping fix, the fix for controls that stopped answering, the frame rate easing, and the compact chat and panel layout) and changes one thing. Not yet run in a game. The latest stable release is still 1.0.9.

Every player should install this build: the join check compares the mod build, so it will not join a session with a different one. It does not include the frame rate log from the 1.0.10-perflog-preview pre-releases.

Changed: the pass over every entity on each tick is cheaper

Before each batch of entities ticks, this mod visits every entity in it to keep the animation of the ones that walk in step between the players. It looked up a component on every entity, on every tick, and folded every entity into two hashes that only the detailed log prints. In a two-player recording of a colony with 11,464 entities (361 of them walkers, speed 7, 11.7 ticks a second) that pass took about 7 ms a tick, about a fifth of the guest's 36 ms tick; roughly 3.3 ms of it was that lookup.

• It now remembers which entities walk, and only asks the game again when a different entity turns up at a position. Adding or removing an entity just makes the shifted positions get asked again.
• The two hashes ("Order hash" and "Move hash" in the detailed log's per-tick line) are only kept while detailed logging is on, and start from zero when it turns on, so both players' lines agree from the first one. Their values are not comparable with a log from an earlier build.
• Nothing that is simulated, sent or saved changes.

Expected saving: roughly 3 to 6 ms a tick, between about 8% and 17% of the guest's tick in that recording. That is an estimate; it has not been measured with this build.

Not fixed

The frame rate that falls over a long session at a high speed (in the same recording the guest went from 23 to 8.5 frames a second in about seven minutes) is not caused by this pass. Most of that time was spent in Unity's late-update phase, outside this mod, and what runs there is not known. Restarting the game brings it back for a while. Lowering the game speed, or turning off Remove the large colony speed limit on the host, lowers the tick rate and keeps a slow guest well clear of it.

Validation

Steam and non-Steam release builds with no warnings · 208/208 StabilityTests (9 new, including a randomized add-and-remove test against a real sorted list) · 69/69 RuntimeChecks against the built mod · 3 Python checks. The DLLs in this zip are the ones those ran against.

Not tested: the pass itself has not run in the game. It works on Unity's entities, which the checks cannot create, so the cache is checked on its own with stand-ins and the patch is covered only by the build and by the runtime checks loading the mod. It relies on an entity not gaining or losing its walking component once it is ticking. How much it saves in a real colony is not known.

Install

1. Fully close Timberborn on every computer.
2. Delete the old BeaverBuddies-Stability-Fork folder from Documents\Timberborn\Mods, then extract BeaverBuddies-Stability-Fork-1.1.10-release-candidate.zip and copy the BeaverBuddies-Stability-Fork folder in.
3. The mod list shows version 1.1.10-release-candidate.

Check the download against 1.1.10-release-candidate-SHA256SUMS.txt:
Get-FileHash .\BeaverBuddies-Stability-Fork-1.1.10-release-candidate.zip -Algorithm SHA256

BeaverBuddies Stability Fork — 1.0.10-perflog-preview2 (pre-release)

A pre-release for testing, built from pull request #28, on top of 1.0.9. It contains everything in 1.0.9 (the Steam ping fix, the fix for controls that stopped answering, the frame rate easing, and the compact chat and panel layout). Not yet run in a game. The latest stable release is still 1.0.9.

This replaces 1.0.10-perflog-preview. Do not mix the two: the join check compares the mod build, so every player must install this one. It adds no gameplay change and fixes nothing. It only adds a way to find out why the recurring drops in frame rate happen in co-op.

What the first recording showed

The synchronisation between players costs almost nothing (0.3 to 0.5% of frame time) and nobody waited on anybody. Both computers collect garbage about once a minute, but one freezes for about 0.7 s and the other for about 0.1 s. About 600 to 720 KB of garbage is made every tick. One player sits at about 31 fps, with most of each frame outside anything the first log measured. This version records enough to say why.

Added to the frame rate log

• Where the garbage comes from: the allocation of each timed section, and a second file (...-profile.csv) with an estimate of the time and garbage per tick of every entity prefab and every singleton, naming the mod each comes from.
• Why a frame is slow when none of that is the cause: the spread of all frame times (vertical sync shows as peaks at 16.7 and 33.3 ms), the time in each of Unity's phases of a frame, the processor time the game thread used against the wall clock, Unity's own frame timing and draw call counters where the game has them, and counts of the hot patches.
• Why two computers differ: each header records launch options, boot.config, the game's garbage collection state, display and refresh rate, graphics API, and how big the heap was while the game loaded.
• What this mod itself costs: the entity pass split into its lookups, walker updates and the rest, plus this mod's animation replacement, speed changes and the wait for the parallel tick, each timed alone.
• An optional experiment, off by default (Frame Rate Log: GC Experiment): about 9 minutes in, if the game is not collecting garbage incrementally, it tries to switch that on and writes down whether it worked, so the collection pauses before and after can be compared. It changes how the game collects garbage, never what it simulates.

It still only observes. It never records or replays an action, never uses the game's random numbers and never changes anything the simulation reads. With the log off, each measured point reads one flag and nothing is installed. With it on, nothing is allocated per frame, the files are written by threads of their own, and the parts that exist only while a log runs are removed when it ends. The log measures its own cost and records it for every frame (overheadUs).

RuntimeChecks/compare_perf_logs.py (in the repository) reads both players' files and their profiles: it checks the mod lists and builds first and stops if they differ, then lines the files up by tick and reports what happened.

How to run it (the one recording that is wanted)

Every player, before hosting or joining, in Mod Settings → BeaverBuddies: turn Log Frame Rate Details on and Frame Rate Log: GC Experiment on, and leave the other two settings alone. Change nothing else: same save, mods and graphics settings as when you saw the drops. Play at least 25 minutes (use the slower speeds and speed 7 for a good while each), write down roughly when you notice a drop, let the game autosave once, and leave through the menu. Send four files: the two files from each player in %USERPROFILE%\AppData\LocalLow\Mechanistry\Timberborn\BeaverBuddiesDiagnostics (perf-host-...csv and perf-host-...-profile.csv, and the same for the guest). Say whether Always Use Detailed Logging was on. The full instructions, and what every column means, are in PERFORMANCE-LOG.md (in the zip, and here).

Validation

Steam and non-Steam release builds with no warnings · 249/249 StabilityTests (run three times in a row) · 69/69 RuntimeChecks against the built mod · 49 checks for the analysis script, plus the 2 existing Python checks. The DLLs in this zip are the ones those ran against.

Not tested: a real session with this version. Nothing this release adds has run in the game. That includes Unity's player loop markers, profiler counters and frame timing, the patch timing the singletons (if the game's JIT inlined the method it patches, the profile has no singleton rows), the garbage collection experiment, and the part of the header that reads Harmony's records. Each one records in the file whether it worked. Whether the log is cheap enough on your computer is also unmeasured: the header records what it measured, and every frame records what it estimated.

Install

1. Fully close Timberborn on every computer.
2. Delete the old BeaverBuddies-Stability-Fork folder from Documents\Timberborn\Mods, then extract BeaverBuddies-Stability-Fork-1.0.10-perflog-preview2.zip and copy the BeaverBuddies-Stability-Fork folder in.
3. The mod list shows version 1.0.10-perflog-preview2.

Check the download against 1.0.10-perflog-preview2-SHA256SUMS.txt:
Get-FileHash .\BeaverBuddies-Stability-Fork-1.0.10-perflog-preview2.zip -Algorithm SHA256

BeaverBuddies Stability Fork — 1.0.10-perflog-preview (pre-release)

A pre-release for testing, built from pull request #28, on top of 1.0.9. It contains everything in 1.0.9 (the Steam ping fix, the fix for controls that stopped answering, the frame rate easing, and the compact chat and panel layout). Not yet run in a game. The latest stable release is still 1.0.9.

Every player should install this build: the join check compares the mod build, so it will not join a session running a different one. This release adds no gameplay change and fixes nothing. It only adds a way to find out what causes the recurring drops in frame rate in co-op.

Added: an optional frame rate log

Log Frame Rate Details, in Mod Settings under BeaverBuddies and off by default, writes a CSV file for every slow frame and every long wait for the other player, keyed on the game tick so two players' files can be lined up. For each it records where the time went: the entity hash, replaying, serializing, hashing, compressing, sending and receiving events, Steam, log lines, detailed-logging work, the panel and saving, plus garbage collections, the managed heap and how fast the game was running. A summary row every so many ticks records what normal looks like. The header lists every enabled mod with its version and which mod has patched which method.

It only observes: it never records or replays an action, never uses the game's random numbers and never changes anything the simulation reads. With it off, each measured point reads one flag. With it on, nothing is allocated per frame and the file is written by a thread of its own.

RuntimeChecks/compare_perf_logs.py (in the repository) reads both players' files: it checks the mod lists and builds first and stops if they differ, then lines the files up by tick and says whether each slow stretch was a hitch on one player with a matching wait on the other, garbage collection on both, waits with no local cause, or a catch-up burst.

How to use it

Every player, before hosting or joining: turn on Mod Settings → BeaverBuddies → Log Frame Rate Details, play 15 to 20 minutes the way you normally do, and note when you see a drop. Leave the game normally, then find the file in %USERPROFILE%\AppData\LocalLow\Mechanistry\Timberborn\BeaverBuddiesDiagnostics (perf-host-...csv or perf-guest-...csv). Send the file from both players. The full instructions, and what every column means, are in PERFORMANCE-LOG.md (in the zip, and here).

Validation

Steam and non-Steam release builds with no warnings · 230/230 StabilityTests (27 new; run six times in a row) · 69/69 RuntimeChecks against the built mod · 33 checks for the analysis script, plus the 2 existing Python checks. The build in this zip is the one those ran against.

Not tested: a real session (nothing has been recorded in the game yet), the part of the header that reads Harmony's records (it only runs inside the game; if it fails the header says patches-unavailable and the rest of the file is still written), and whether the log is cheap enough in a large colony (the file records its own cost per frame, in probeUs).

Install

1. Fully close Timberborn on every computer.
2. Delete the old BeaverBuddies-Stability-Fork folder from Documents\Timberborn\Mods, then extract BeaverBuddies-Stability-Fork-1.0.10-perflog-preview.zip and copy the BeaverBuddies-Stability-Fork folder in.
3. The mod list shows version 1.0.10-perflog-preview.

Check the download against 1.0.10-perflog-preview-SHA256SUMS.txt:
Get-FileHash .\BeaverBuddies-Stability-Fork-1.0.10-perflog-preview.zip -Algorithm SHA256

BeaverBuddies Stability Fork — 1.0.10-panel-design-preview (pre-release)

A pre-release for testing, built from pull request #30, on top of 1.0.10-perflog-preview2. It contains everything in 1.0.9 and in that pre-release (the Steam ping fix, the fix for controls that stopped answering, the frame rate easing, the compact chat and panel layout, and the optional frame rate log). Not yet run in a game. The latest stable release is still 1.0.9.

It changes how the connection panel looks and what color chat is drawn in, and nothing else: no gameplay change, no fix, nothing new sent over the network. Every player should install this build: the join check compares the mod build, so it will not join a session running a different one.

A plainer connection panel

• One dot. While the panel is expanded, the dot beside the sync status (green, yellow or red with the status) is the only one. The dot beside the title and the dots beside each player are gone. A collapsed panel is one line with no status row, so it keeps its own dot.
• A player's row is a name and a ping. The "You" and "Host" tags are gone. The host reads each guest's ping. A guest reads its own ping to the host on the host's row, and the ping the host measured for every other guest. Over 80 ms the number is yellow and over 160 ms red, and "No response" is red.
• Your own row is bold, with a dash where the ping would be, since you have no ping to yourself.

Chat takes the cursor colors

A chat line, name and message, is drawn in the color you see on that player's cursor: the color they chose (their Ping Color), or the one you set for them under Options → Player cursors. Change that color and the lines already written change with it, within a moment. Your own lines use your Ping Color. A player who has left, or whose cursor is off, keeps the color you saved for them, else the one their messages carried. A color too dark to read on the panel is lightened, as before. Before, only the name was colored, and always in the color the player chose for themselves.

What to look at

This is the first time any of this is seen in a game, so a screenshot of the expanded panel with a few chat lines is the useful thing to send back. In particular: whether your own row really draws in bold (it depends on the game's font), that the header no longer has a dot, and that a chat line changes color when you change that player's cursor color.

Validation

Steam and non-Steam release builds with no warnings · 251/251 StabilityTests (two new: the ping on every row, and the color saved for a player who is not connected) · 69/69 RuntimeChecks against the built mod · 51 Python checks. The DLLs in this zip are the ones those ran against.

Not tested: how any of it looks in a game. That includes the header without its dot, the player rows, whether the game's font draws your own row in bold, and chat lines in the cursor colors, also after a color is changed. The interface cannot be built outside the game, so none of it can be checked without one.

Install

1. Fully close Timberborn on every computer.
2. Delete the old BeaverBuddies-Stability-Fork folder from Documents\Timberborn\Mods, then extract BeaverBuddies-Stability-Fork-1.0.10-panel-design-preview.zip and copy the BeaverBuddies-Stability-Fork folder in.
3. The mod list shows version 1.0.10-panel-design-preview.

Check the download against 1.0.10-panel-design-preview-SHA256SUMS.txt:
Get-FileHash .\BeaverBuddies-Stability-Fork-1.0.10-panel-design-preview.zip -Algorithm SHA256

BeaverBuddies Stability Fork — 1.0.9

The current release. It contains everything from the four 1.0.9 pre-releases (1.0.9-tickspeed-preview, 1.0.9-control-fix-preview, 1.0.9-framethrottler-preview2 and 1.0.9-chatbox-fix-preview): a ping over Steam that no longer grows with the game speed, controls that keep working after a session ends, a host that can ease off for a slow guest's frame rate, and a compact chat and panel. See the changelog for each.

Played in multiplayer: the ping fix (a session at a true speed 7 with the ping under 100 ms, where it had been 200 to 300 ms) and the controls after a disconnect. Not played yet: the current frame rate easing rule (an earlier version of it was played once), the chat and panel layout, the other cases the controls fix covers, and this combined build as a whole. The four changes were each built and tested on their own, then merged into this release; the merged build passes every suite, and they meet in the replay service and the connection panel.

Every player should install this build: guests now send the host one more number than before (their frame rate), and the join check compares the mod build, so it will not join a session with an earlier version.

The ping over Steam no longer grows with the game speed

A good ping at a low game speed, 200 to 300 ms at a high one. Steam was only served from the game thread once per frame, and a ping probe passes four of those pumps on its way round, about a frame and a half per player. At a high speed most of a frame is simulation, so frames stretch and the ping followed them; the same waits delayed every guest action and every tick the host sent. The tick loop now lets Steam move data between the buckets of a tick. It moves data only and stays on the game thread. In a model with the real transport, 100 ms frames on both sides gave 323 ms once per frame and 13 ms with the extra pumping. The log writes a Steam link timing line once a minute that shows both. The guest's frame length at a high speed was never measured, so the cause is inferred from the game's code and a host log.

Controls and the menu keep working after a session ends

Five separate causes left the game running but ignoring the player: a failed action blocked the menu too, a dropped connection left a dead session installed and showed no message, a cancelled or failed join or host left a dead session in the main menu, Steam's overlay could close under a dialog and leave an invisible panel eating every key, and held input was not cleared. The session now ends the way a desync does, says why, and leaves the menu and controls working. Confirmed after a disconnect; the other cases come from reading the code and are covered by checks only.

The host can ease off for a guest's frame rate

New host choice Ease off below (Off, 20, 30, 45 or 60 fps), a clickable line in the connection panel and a mod setting. Guests report their frame rate in the ping reply; the host looks at the middle of the last five reports, drops 10% of the chosen speed while it is below the floor, climbs back 5% after six good reports, and remembers the speed that caused trouble so it does not climb straight back into it. It only changes how fast the host works through ticks, never what happens in them.

A compact chat and a panel that lines up with the game's own

The chat has a fixed short height, the panel is as wide as the game's beaver counters, the labels are shorter, and the panel is drawn in front of the game's alerts while you type. None of this has been seen in the game.

Validation

Steam and non-Steam release builds with no warnings · 199/199 StabilityTests (38 new since 1.0.8) · 69/69 RuntimeChecks against the built mod · 3/3 Python checks · the README, changelog, panel and Steam docs and the website are updated. The zip was built from the commit that is tagged, and its DLL contains every change (checked in the compiled code).

Install

1. Fully close Timberborn on every computer.
2. Delete the old BeaverBuddies-Stability-Fork folder from Documents\Timberborn\Mods, then extract BeaverBuddies-Stability-Fork-1.0.9.zip and copy the BeaverBuddies-Stability-Fork folder in.
3. The mod list shows version 1.0.9.

Check the download against 1.0.9-SHA256SUMS.txt:
Get-FileHash .\BeaverBuddies-Stability-Fork-1.0.9.zip -Algorithm SHA256

BeaverBuddies Stability Fork — 1.0.9-tickspeed-preview (pre-release)

A pre-release for testing, built from pull request #22, which is still under review. It contains everything in 1.0.8. Not yet played in a multiplayer session, and not run with real Steam. The latest stable release is still 1.0.8.

Every player should install this build: the join handshake compares the mod build, so both computers need the same one.

Fixed: the ping over Steam grew with the game speed

A good ping at a low game speed, 200 to 300 ms at a high one.

What was happening: Steam was only served from the game thread once per frame, and a ping probe passes four of those pumps on its way round (the host sending it, the guest receiving it, the guest sending the reply, the host receiving that). That is about a frame and a half per player. At a high speed most of a frame is simulation, because the game ticks as many buckets per frame as the elapsed time times the speed asks for, so frames stretch as the simulation load grows and the ping followed them. In a host log at a true speed 7 the simulation took 51% of the main thread and frames were 17 to 19 ms, about twice what they are at speed 1. A computer nearer its limit, and a guest that is catching up, has much longer frames. The same waits delayed real traffic: every action a guest made and every tick the host sent.

What changed: the tick loop now lets Steam move data between the buckets of a tick, at most once a millisecond, and straight after a tick has queued its events for the guests. It moves data only, on the game thread like every other Steam call, and does nothing outside a Steam session. Direct-IP connections are not affected.

In the test model (the real transport, server, client and ping tracker over a fake Steam network, 5 ms each way), ping in ms:

Host frame	Guest frame	Once per frame	Between ticks
17 ms	17 ms	58	18
17 ms	100 ms	177	17
100 ms	100 ms	323	13
200 ms	200 ms	713	13

What is left is the part of a frame that is not simulation (rendering, the garbage collector), which nothing can serve.

A line in Player.log to check it with

Once a minute while someone is connected, both computers write, for example:
Steam link timing over 60 s: data waited for the game thread 17.3 ms on average and up to 118 ms if Steam were only served once per frame (4 gaps over 50 ms); with the pumping between ticks it waited 1.6 ms on average and up to 24 ms (0 gaps over 50 ms).
The first figures are what the old once-per-frame pump would have cost in that session and the second are what it cost, so one session shows both. Compare them with the ping in the connection panel at speed 1 and at speed 7.

What is not confirmed: the guest's frame length at a high speed has never been measured, so it is not known that this accounts for all of the 200 to 300 ms. If the panel ping is still high with this build, the timing line above and each computer's frame rate are what to send back.

It cannot change what anyone simulates

It only changes when data moves between the computers. Every event still carries the tick the host gave it, so the two computers cannot disagree; a guest's action just reaches the host, and lands on a tick, sooner.

Validation

Steam and non-Steam release builds with no warnings · 166/166 StabilityTests (5 new) · 64/64 RuntimeChecks against the built mod · 2/2 Python checks. dotnet run --project StabilityTests -- --ping-report reproduces the table above. Nothing here has run in the game or with real Steam.

Install

1. Fully close Timberborn on every computer.
2. Delete the old BeaverBuddies-Stability-Fork folder from Documents\Timberborn\Mods, then extract BeaverBuddies-Stability-Fork-1.0.9-tickspeed-preview.zip and copy the BeaverBuddies-Stability-Fork folder in. The other 1.0.9 previews use the same folder name, so only one of them can be installed at a time.
3. The mod list shows version 1.0.9-tickspeed-preview.

Check the download against 1.0.9-tickspeed-preview-SHA256SUMS.txt:
Get-FileHash .\BeaverBuddies-Stability-Fork-1.0.9-tickspeed-preview.zip -Algorithm SHA256

BeaverBuddies Stability Fork — 1.0.9-framethrottler-preview2 (pre-release)

A pre-release for testing, built from pull request #20, which is still under review. It contains everything in 1.0.8 and in 1.0.9-framethrottler-preview. Not yet played in a multiplayer session. The latest stable release is still 1.0.8.

The network format is the same as 1.0.9-framethrottler-preview. Only the host's build decides how the easing behaves, but install it on every computer anyway so the mod lists match.

Fixed: the frame rate easing see-sawed

The first preview was played with the floor at 20 fps. No desync, and the guest's average frame rate went from 5 to 11 fps (1.0.8, same colony, true speed 7) to 21 to 27 fps. But the host changed speed 68 times in seven minutes, between 60% and 95%, and never settled:

• The guest's one-second frame rates are noisy, anything from 2 to 59 fps within a few seconds, because a garbage collection or an autosave takes most of one second. Three bad seconds in a row were enough for a drop.
• After every drop the host climbed straight back, 5% every three seconds, into the speed that had just caused the trouble.

What changed

• The rule looks at the middle value of the guest's last five reports, which one or two bad seconds cannot move. Below the floor: drop 10%, then wait for five fresh reports, so the next decision only sees frame rates from after the drop.
• Speeding back up takes six good reports in a row instead of three.
• The percentage the host had to drop from is remembered. It does not climb back to it for a minute of play, then tries once. If that fails from the same percentage, the wait doubles, up to four minutes. Changing the floor, switching it off, or the guest leaving forgets it.
• The line in Player.log also gives the middle value the decision was made on.

In a model of a guest that is fine up to 80% of the chosen speed and collapses above it, the host stays between 75% and 85% and tries the higher speed at most six times in eighteen minutes. The first preview tried every twenty seconds.

It cannot change what anyone simulates

It only changes how fast the host works through ticks, never which tick anything happens on.

Validation

Steam and non-Steam release builds with no warnings · 177/177 StabilityTests · 64/64 RuntimeChecks against the built mod · 2/2 Python checks.

Install

1. Fully close Timberborn on every computer.
2. Delete the old BeaverBuddies-Stability-Fork folder from Documents\Timberborn\Mods, then extract BeaverBuddies-Stability-Fork-1.0.9-framethrottler-preview2.zip and copy the BeaverBuddies-Stability-Fork folder in.
3. The mod list shows version 1.0.9-framethrottler-preview2.

Check the download against 1.0.9-framethrottler-preview2-SHA256SUMS.txt.