Mods / Komet - Performance Mod

Tags:
Shaders Client Visual
Author:
xToast
Side:
Both
Created:
Aug 30th at 5:44 PM
Last modified:
4 days ago
Downloads:
2182
Recommended download (for Vintage Story 1.22.0-pre.1 - 1.22.7):
Komet_v1.2.0.zip  1-click install

Komet is a universal performance mod. It rewrites the hot paths of the render loop — the visibility sweep, occlusion culling, draw-range batching — and smooths the rest: chunk loading, stutter from GC pressure and driver syncs, shadow artefacts, VRAM held by empty pools. Without changing what ends up on screen: on every build the culling core is verified byte-identical against vanilla before anything is timed.

Every number on this page was measured, not estimated — in the mod's benchmark on real game data structures, or in-game with the built-in stress test and .komet report. Where a vanilla figure does not exist, this page says so instead of inventing one. Gains grow with view distance, which is why the measurements were taken at view distance 1536.

2.8×
frame rate, same scene
16.8 → 6.1 ms/frame
5.9×
visibility sweep
177,000 mesh parts
2.1×
fps at the horizon (new in 1.2.0)
53 → 113 fps, far LOD
3,120/3,120
identical to vanilla
checked on every build

Frame rate: in-game stress test, one feature switched back to the vanilla code path in the same loaded scene, interleaved baselines so scene drift cancels out. The rest: see the tables below.

Vanilla → 1.0.0 → 1.2.0

The mod's own benchmark runs the real culling code on real game data structures and proves the output byte-identical to vanilla before it times anything. It re-measures vanilla in every run, so both baselines are shown — each Komet figure is compared against the vanilla of its own run.

Benchmark, view distance 1536 Vanilla Komet 1.0.0 Komet 1.2.0
Visibility sweep, per frame
in-game pool shape, 177,000 mesh parts
9.61 ms
8.76 ms
1.96 ms
4.9×
1.49 ms
5.9×
Occlusion pass, per frame
74,034 rays; Komet also moves it off the main thread
85.0 ms
73.6 ms
4.3 ms
19.8×
4.6 ms
16.0×
Draw ranges handed to the GPU, per pass
fewer, larger batches; deterministic, hence unchanged
4,424 2,541
−43 %
2,541
−43 %
Sweep at a small load, per frame
24,000 parts, three sweeps (opaque + both shadow passes)
1.16 ms not published 0.94 ms
1.2×

1.0.0 column: benchmark run of 30 Aug 2026, as published on the 1.0.0 page. 1.2.0 column: median of five runs on 7 Sep 2026, same machine. The occlusion pass got no faster between the two — its factor moved because the vanilla baseline in the newer run came out faster, which is exactly why both baselines are printed rather than one. The last row is the one that went the other way: at a small load the sweep is 1.2× where 1.0.0-era code reached 1.8×, because the far LOD needs twice as many LOD levels per grid cell and the shared worker pool costs a little more per batch than the dedicated threads it replaced. At the in-game pool shape — the row that decides frames — it is unchanged at 5.9×.

Measured in the running game

These come from the stress test and .komet report, not the benchmark. The first row is new in 1.2.0 and was measured for it; the three below it were taken in Aug 2026 and have not been re-measured since, so they carry no version column — nothing after them touched those paths, but an unrepeated measurement should not be reprinted as a new one.

In-game, view distance 1536 Vanilla path Komet Change
Looking at the horizon, far LOD off → on — same spot, same world, same settings; 16.1 M → 6.9 M triangles in the camera pass 19.0 ms
53 fps
8.9 ms
113 fps
2.1× fps
Visibility sweep, stress test — same session, only the sweep switched 16.8 ms
≈ 60 fps
6.1 ms
≈ 164 fps
−64 % frame time
Chunk tesselation during world load — adaptive inflow + loading pipeline 12 ms/chunk
82 chunks/s
3.4 ms/chunk
279 chunks/s
3.4× throughput
Scene full of block-entity renderers — firepits, signs …; vanilla never distance-culls them 21.7 ms
46 fps
13.2 ms
76 fps
+65 % fps
Driver syncs while chunks stream in — per-frame GL error checks skipped −2.3 ms/frame no vanilla base — delta only (±1.5 ms)

The far-LOD row compares the feature off vs. on in an otherwise identical Komet frame, not vanilla vs. Komet — vanilla draws what “off” draws, plus everything else Komet already saves. The block-entity row compares distance culling off vs. on; “off” equals vanilla behaviour, which ignores the renderers’ own RenderRange entirely. Komet’s other optimisations were active in both, so a pure vanilla frame of that scene would be slower still. The chunk-load row is the same world and scenario measured before vs. after the adaptive inflow shipped, not a same-session A/B.

A real session, straight from .komet report

Komet ships its own measurement layer — an F7 HUD, a hitch log, a per-renderer profiler and .komet report, which writes one complete diagnostic block to client-main.log. These are two such blocks, unedited, from the same spot in the same world at view distance 1536 — the first without the far LOD, the second with it. This is the measurement the feature was built on, and the one that decides whether it was worth building:

Frame
19.0 → 8.9 ms
53 → 113 fps
GPU time
14.9 → 7.0 ms
per frame
Camera pass
16.1 → 6.9 M
triangles per frame
Opaque pass
11.7 → 4.2 ms
GPU, bottom-of-pipe
Beyond 640 blocks
12.7 → 2.6 M
triangles per frame
Looking down
5.3 → 5.9 ms
the ground view pays a little

The last tile is the honest other half: a view with nothing far in it gains nothing from a far LOD and carries its pool entries anyway. KometBaseline is a separate download on this page — a measurement-only twin built from the same source files. Disable Komet, enable the baseline, press F7, and read the same numbers for vanilla on your own world.

Not measured, therefore not shown: GPU utilisation in percent (the report reads GPU frame time), RAM footprint vanilla vs. Komet, and a full-frame vanilla twin of the session above.

Why you can trust the numbers

  • 3,120/3,120 culling sweeps produce byte-identical triangles, in identical order, to vanilla — checked on every build, alongside 1,440/1,440 with the pool-level early-out and 2,304/2,304 pixel-equivalent gap-merge checks.
  • The far LOD is checked the same way: on twelve random terrains its picture is compared against the cell picture computed from the heightmap alone — every face, both levels, in the right render pass — and the level rules are driven through the sweep and its vanilla reference.
  • Every optimisation is individually toggleable in komet.json; .komet safemode flips everything that affects what is drawn back to vanilla, live, mid-session.
  • Stress-test deltas use interleaved neighbour baselines, so linear scene drift cancels out; deltas smaller than their ± spread are reported as noise.
  • Release builds are reproducible: the same commit produces the same bytes, and the SHA-256 on this page is also written by the build job onto the GitHub release — so it can be recomputed rather than trusted.

How the comparison is computed: ×-factors are vanilla ÷ Komet; percentages are (vanilla − Komet) ÷ vanilla for times and (Komet − vanilla) ÷ vanilla for rates and fps. Test machine: 12-thread CPU, AMD Radeon RX 9070 XT, Linux/Mesa, Vintage Story 1.22.7, view distance 1536 unless stated. Absolute numbers scale with view distance and hardware: the render-loop gains grow with view distance, while the loading, stutter and GC improvements apply at any distance.

What Komet actually changes

  • Far LOD — beyond the far distance a chunk is drawn as cells of two blocks, beyond twice that as cells of four; built from the engine's own tesselation, no shader changes, reversible mid-session.
  • Visibility sweep — spatial grid per mesh pool, AVX2 kernel, own worker threads, bit-identical results.
  • Occlusion culling — parallelised and moved off the main thread.
  • Draw-range merging incl. bridging over frustum-clipped gaps → fewer, larger GPU batches.
  • Distance culling for block-entity renderers, whose own RenderRange the engine ignores.
  • Chunk loading — adaptive inflow brake, tesselation-thread tuning, neighbour prefetch, window pipelining; visible border holes are repaired first.
  • Shadows — a coverage margin so the far cascade's throttle also saves while you move, a near cascade at its own map size, depth-only shader and back-face culling for the solid passes, texel snapping against crawling edges, and knobs for the rest.
  • One worker pool for every background job the mod owns — culling, occlusion, prefetch, animation warm-up — sized against the physical cores the render and tesselation threads leave.
  • VRAM and GC — empty mesh pools reclaimed, mesh buffer recycler, clone compaction.
  • Measurement built in — F7 HUD, a window on Ctrl+F7, a per-mod profiler on Shift+F7, hitch log with 1 % and 0.1 % lows, GPU time per stage and per pass, stress test, .komet report.

Compatibility

  • A plain Harmony mod, zero setup. Komet patches the stock engine in memory when it loads — no forked client, no separate installer, no downloaded or decompiled game data. Drop the zip into Mods; delete it to uninstall.
  • Shader mods. Komet replaces no shader or asset files; its changes are engine-side code patches, so shader packs keep their visuals on top of it.
  • Komet names conflicts instead of hiding them: it reports when another mod patches the same engine method, with a severity and a reason, and fingerprints the engine at world start. .komet conflicts lists it.
Sheydermod Fully compatible and supported
Tungsten Unsupported
Optimum Unsupported
Optitime Unsupported

About Optimum — and why you should still go look at it.

Optimum ships a separate patched client instead of patching the stock one in memory. That means both mods rewrite the same hot paths of the render loop in two different ways, and they cannot be run together: earlier versions of this page called that “partially supported”, which was too generous. Treat it as not compatible and run one or the other.

That is a technical statement, not a verdict on the project. Optimum is serious, ambitious work, it goes places a Harmony mod cannot follow, and its author has been at this longer than Komet has existed. If a patched client is a trade you are willing to make, check it out — and if you want an ordinary mod you can drop in and delete again, that is what Komet is for.

Install

Drop the zip into your Mods folder. Needs Vintage Story 1.22.0 or newer; built and verified against 1.22.7 — on other 1.22.x builds any patch whose engine code changed logs a warning and switches itself off individually, and the game keeps running vanilla in that spot. Client-side; safe to add or remove at any time.

In game: F7 toggles the performance HUD · Ctrl+F7 opens the window · Shift+F7 the per-mod HUD · .komet opens the window or prints the numbers in chat · .komet report writes the full diagnostic block to the log · .komet safemode reverts all visual changes live. The HUD and the chat replies follow the game language; English and German ship with the mod. Logs and reports stay English on purpose — they end up in bug reports.

Mod Version Mod IdentifierFor Game version Downloads Released Changelog Download 1-click mod install*
1.2.0 komet
1.22.0-pre.1 - 1.22.7
547 4 days ago Komet_v1.2.0.zip 1-click install

Changelog:
## 1.2.0 Release

SHA256 Checksum: 4a1d0352e5d6e2fa017e3a6909ed54b5eb3ecacbdd6291dc37df82d5b74a2cb7 Komet_v1.2.0.zip

Github Release: https://github.com/xToast-dev/komet/releases/v1.2.0

Everything since 1.1.0, in one list. The four pre-releases and the work after them add up to: a far LOD that finally fixes the frame rate when you look at the horizon, the GPU side of the shadow passes, a worker pool instead of four thread sets, a measurement layer that can now answer “CPU or GPU?” and “which of my mods?”, and two crashes that should never have shipped.

The headline: a far LOD

  • Beyond the far distance a chunk is drawn as cells of two blocks, beyond twice that as cells of four. At view distance 1536 the camera pass drew 16,1 million triangles when looking at the horizon, 12,7 million of them beyond 640 blocks — where a block covers one to three pixels and the chunk vertex shader still exports thirteen vec4 and evaluates 3D noise for each of them.
  • Measured in the same scene, same session: 53 → 113 fps (19,0 → 8,9 ms/frame), camera-pass triangles 16,1 → 6,9 million, GPU frame 14,9 → 7,0 ms, and the camera opaque pass — timed bottom-of-pipe with a GPU elapsed query — 11,7 → 4,2 ms.
  • The picture is built from what the engine already tesselated, on the tesselation thread: unit faces mark their block solid, air floods through the rest, a cell is solid if any of its blocks is, and each solid cell gets one face per air neighbour carrying a real source face's texture, light and colour map. No shader is touched.
  • Plants, leaves, stairs and fences keep one representative per cell, scaled to fill it — a tree stays a tree, a house stays a house. The picture is never thinner than the world, only up to a block fatter, which is why chunks at different levels never leave a gap.
  • The engine's own meshes are not modified and not re-tesselated: they simply stop at the far distance. Switch the feature off and they are drawn everywhere again on the next frame. The shadow maps always use the engine's meshes, never the pictures.
  • Costs about 1,3 ms per chunk on the tesselation thread and roughly a third more vertices in the mesh pools. FarMesh, FarMeshDistance, FarMeshTier2; .komet farmesh <blocks|off|on> and .komet toggle farlod2 live.

Faster

  • One dynamic worker pool instead of four thread sets that could not see each other. Five cull helpers, four occlusion helpers, a window-prebuild thread and a prefetch thread became one pool whose workers take whichever job is worth most. Same sweep on fewer threads: 0,70 ms against 0,77 ms, and the workload that holds cores for milliseconds can no longer starve the one on the frame's deadline.
  • The far shadow map is no longer redrawn on every frame while you move. It was kept for a few frames and reprojected exactly, but a reprojection cannot extend what a kept map covers — so 15 cm of camera movement forced a redraw and the saving existed only while standing still. The map is now drawn 16 blocks wider than the fade needs, which is exactly the room the camera needs, and the redraw threshold rises with it.
  • The near shadow cascade gets a map of its own size (4096 px). The engine allocated both cascades from one expression, so a cascade covering the 39 blocks around you had over a hundred texels per block against the far map's fifteen.
  • The solid shadow passes use a depth-only shader and back-face culling. The engine's shadow shader samples the terrain texture and discards for every fragment of every pass; a closed block's back faces sit behind its front faces along the light ray too. Same depth map, half the faces, no texture fetch. Leaves and grass keep the engine's shader and cast from both sides.
  • The near cascade stops drawing what cannot cast a shadow on anything visible — the half of its depth range that faces away from the light, and casters that cannot reach a receiver on screen.
  • Far-detail stand-in geometry stays out of the shadow maps where the detailed version is already in them, decided per grid cell. On by default now; the old per-pool test never fired in a streamed world.
  • A new creature type no longer costs a hitch the first time you see one. The engine builds an animation's frames on the main thread the moment it first plays: 12 ms for a rooster, 53 ms for a pig, always in the frame the animal comes into view. They are now built on a worker while the entity is still held back.
  • The edge-repair sweep stopped rehashing the whole tesselation queue every 50 ms (4,6× to 7,3× on that sweep), the neighbour prefetcher stopped re-walking the same queue front hundreds of times a second, and the window prebuilder now predicts the chunk the tesselator will really mesh.
  • World joins hitch less and entities are finished under a per-frame budget, nearest one first. Distant creatures animate every second or third frame with the skipped time folded in — same speed, sampled less.
  • Server packets that are not chunk data run under a per-frame budget instead of stopping one frame dead, and the hitch that remains names the packet type behind it.
  • Less garbage per chunk. The mesh buffer recycler, tight clones, a pooled extras store and now the far LOD's own output arrays: 45,6 KB → 0,8 KB allocated per chunk build, measured against a real recycler.
  • Particle instance buffers are renamed instead of waited on, so a frame does not block on a buffer the GPU is still reading.

New

  • A performance window on .komet and Ctrl+F7 — nineteen pages, one per question, with every switch flippable in place. It takes no measurement of its own; the blocks it draws are the same methods the overlay and the report call.
  • A mod profiler with its own HUD (Shift+F7). Which of your mods costs what per frame, what each one does (patched methods, registered classes) and what it cost during loading, client and integrated server separately. .komet mods prints it as text for a bug report.
  • 1 % and 0,1 % lows, and a live frametime graph, next to the averages the mod always showed — the numbers that describe stutter rather than throughput.
  • A three-way answer to “CPU-bound or GPU-bound?”: GPU time per render stage, the driver's own busy figure where the system exposes it, and per-pass GPU timings measured bottom-of-pipe with fragment counts — the one measurement that tells fill rate from geometry without arguing.
  • The camera pass's triangles by render pass, distance band and LOD level, which is what turned “the horizon is slow” into a number and then into the far LOD.
  • .komet alloctrace [seconds] — the process records its own allocations with call stacks into a file next to the logs.
  • Komet notices when another mod patches the same engine method and says so once, with a severity and a reason, and fingerprints the engine at world start so a game update that changed a patched method is named instead of silently misbehaving. .komet conflicts lists it.
  • A warning at world join when Optimum or OptiTime is present. Both replace the same engine code, each unaware of the other; finding that out used to need a bisect. Komet stays enabled — which side should win is your call.
  • The HUD and the chat replies speak German when the game does. Logs, reports and hitch lines stay English on purpose: they end up in bug reports.
  • Server-side sync tuning for singleplayer — position updates thin out with distance, entity tracking gets a hysteresis band, attribute paths whose bytes did not change are not sent.
  • Live knobs for the visual trades, all reversible mid-session: .komet farmesh, .komet foliagerange, .komet shadowfoliagerange, .komet shadownear, .komet shadowneardepth, and a toggle table that lists every one of them with what it does.

Fixed

  • Crash on joining a world (NullReferenceException in WeatherSystemClient). The new task budget could spread a join's backlog over frames and let a renderer draw before the packet that initialises it had run. Joining is lifecycle, not load: the budget now starts only once the world is finalised.
  • Crash on the first frame with the Optimum client build (MissingFieldException: ClientMain.MainThreadTasksLock). The fork declares that field with a different type. It is now read by name and locked the way its type demands.
  • A German client's log filled with “Translation string format exception” — an error and a warning per HUD refresh for every label with a number, thousands per session.
  • Two budgets could stop for good instead of falling back. If their frame-boundary reset ever stopped arriving, entity tesselation skipped every further shape and held entities never loaded. Both now detect it, run vanilla and count it. A budget that loses its reset has to degrade to slower, never to never.
  • The patch guard was quiet about the collisions that matter most — where Komet replaces an engine method outright, another mod's transpiler never runs. Reported as high severity now, with the reason.
  • One malformed animation no longer costs a creature its whole warm-up, and the shadow cull range no longer forgot the light eye's 50-block offset.
  • Two toggles reported success and did nothing. Several measurements were booked to the wrong place: particles folded twice, GPU timing and GC statistics while the HUD was closed, mesh pool allocations, hitches in the 2D stage now name the dialog that caused them, and no more false hitch reports while the pause menu is open.

Changed

  • Config layout is now version 26 (a great many new settings since 1.1.0). An existing komet.json is backed up next to itself and regenerated from the current defaults — re-apply your custom values afterwards.
  • CullingThreads and OcclusionCullingThreads are gone, replaced by the worker pool's own sizing (physical cores minus two, so the render and tesselation threads keep theirs).
  • The mod zip is stored, not compressed (~180 KB → ~450 KB). Identical data does not give identical deflate streams across zlib implementations, so compressing would make the checksum below unreproducible on a different machine.
  • Minimum game version stays 1.22.0. Built and verified against 1.22.7; on other 1.22.x builds any patch whose engine code changed logs a warning and switches itself off individually.

Internals

  • The culling core is still proved byte-identical to vanilla on every build — 3.120/3.120 sweeps with identical triangles in identical order, 1.440/1.440 with the pool-box early-out, 2.304/2.304 pixel-equivalent gap merges — and the far LOD's picture is checked against the cell picture computed from a heightmap alone, on twelve random terrains, at both levels.
  • Every build runs on GitHub Actions: both mods built, the full patch and behaviour suite executed against the real game assemblies, the packaged zips attached to the run.
  • Release builds are reproducible: the same commit produces the same bytes, so the checksum below can be recomputed rather than merely trusted.
1.2.0-pre.4 komet
1.22.0-pre.1 - 1.22.7
143 5 days ago Komet_v1.2.0-pre.4.zip 1-click install

Changelog
## Komet 1.2.0-pre.4

SHA256 Checksum: d643a8e24ac1ce5e514fec3746f3e07f689b51bec6563de6ceccc2f74425590d Komet_v1.2.0-pre.4.zip

Github Release: https://github.com/xToast-dev/komet/releases/tag/v1.2.0-pre.4

Changes since 1.2.0-pre.3. This release is mostly the GPU side of the frame: the first report
that could measure it found the two shadow passes taking 86 % of a GPU-bound frame, and four of
the five performance changes below come out of that one number.

### Faster

- The far shadow map is no longer redrawn on every frame while you move. It was already kept
  for a few frames and re-projected exactly — but a re-projection can only keep a kept map
  correctly *positioned*, not extend what it *covers*, so any camera movement of 15 centimetres
  forced a redraw. Walking, and especially flying, meant the saving never happened; it existed
  only while standing still. The map is now drawn a little wider than the shadow fade needs
  (16 blocks by default), which is exactly the room the camera needs to move without leaving it,
  and the redraw threshold rises to about 14 blocks in step. Costs about 6 % coarser far shadows;
  `ShadowFarBoxMargin` sets the trade, `.komet toggle shadowmargin` flips it live.
- The near shadow cascade gets a map of its own size. Both cascades used to be allocated from
  one expression, so the near map was as large as the far one — over a hundred texels per block
  for the ~39 blocks around you, against the far map's fifteen. Now 4096 px by default: a third
  of the fill rate for a difference nobody can see. `.komet shadownear 3072` changes it live.
- The solid parts of the shadow passes do a lot less work per fragment. Back-face culling
  drops half of every solid face before a fragment exists (a closed block's back faces sit behind
  its front faces along the light ray too, so the depth map is identical), and a depth-only shader
  spares the rest a terrain texture lookup. Leaves and grass are untouched and still cast from
  both sides.
- Far-detail stand-in geometry stays out of the shadow maps wherever the detailed version is
  already in them — the shadow pass had no distance rule at all and rasterised both.
- A new creature type no longer costs a hitch the first time you see one. The engine builds an
  animation's frames on the main thread the moment it first plays — 12 ms for a rooster, 53 ms for
  a pig, always in the frame the animal comes into view. They are now built on a worker while the
  entity is still held back, and the main thread finds them ready.

### New

- A mod profiler with its own HUD (Shift+F7). Every measurement this mod made so far named a
  part of the *engine* — a render stage, a renderer, a tick listener — and none of them answered
  the question somebody with forty mods installed actually asks: *which of mine is it*. The
  overlay lists your mods by what they cost per frame, what they do (engine methods patched,
  block/item/entity classes registered) and what each one cost during loading, client and
  integrated server separately. `.komet mods` prints the same as text for a bug report.
- It also prints what it cannot see instead of leaving it out: a Harmony patch runs inside the
  method it patches, so its time is booked to the engine — which is why the patch count sits next
  to the milliseconds — and block entity ticks, mod worker threads and GUI dialogs are not
  attributed at all.
- A warning at world join when Optimum or OptiTime is present. Both replace the same engine
  code Komet does, each unaware of the other, and finding that out used to take a bisect. Komet
  stays enabled — which side should win is your call.

### Fixed

- Crash on the first frame with the Optimum client build (`MissingFieldException:
  ClientMain.MainThreadTasksLock`, reported with Optimum v0.3.14). The fork declares that field
  with a different type, so the mod's binding no longer resolved. It is now read by name and
  locked the way its type demands; anything unexpected leaves that part vanilla instead of taking
  the client down.
- German clients filled their log with "Translation string format exception" — an error and a
  warning per HUD refresh for every label containing a number, thousands per session.

- A ton of more Bugfixes :)

### Changed

- Config layout is now version 15 (eight new settings since pre.3, five of them
  shadow-related). An existing `komet.json` is backed up next to itself and regenerated with
  defaults — re-apply your custom values afterwards.
- Minimum game version stays 1.22.0. Built and verified against 1.22.7; on other 1.22.x builds any
  patch whose engine code changed logs a warning and switches itself off individually.

Check with `sha256sum Komet_v1.2.0-pre.4.zip` (Linux) or `Get-FileHash Komet_v1.2.0-pre.4.zip`
(PowerShell). Release builds are reproducible: check out the tagged commit, run
`./build.sh release`, and the file comes out with exactly that checksum on any machine.

1.2.0-pre.3 komet
1.22.0-pre.1 - 1.22.7
90 6 days ago Komet_v1.2.0-pre.3.zip 1-click install

Changelog:
## 1.2.0-pre.3

SHA256 Checksum: d80c94ed06854f9a8d7cdcfc7fd56272481df03e1efcbc11ab7ef4b99be9fb59  Komet_v1.2.0-pre.3.zip

Github Release: https://github.com/xToast-dev/komet/releases/edit/v1.2.0-pre.3

Everything here answers a report from someone running pre.2, or follows from one.

### Fixed

- Joining a world could crash the client with a `NullReferenceException` in
  `WeatherSystemClient.OnRenderFrame`. pre.2 introduced a per-frame budget on the main-thread
  task drain, and a world join queues hundreds of those tasks — including the one that
  finalises the level. Spreading that backlog over frames let a renderer that was already
  registered draw before the packet initialising it had run. The budget now starts only once
  the world is finalised: everything a join queues runs in the frame it arrives, exactly like
  vanilla. Joining is lifecycle, not load, and it is not the place to save milliseconds.
- Two budgets could stop working instead of falling back. The entity tesselation and
  entity loading budgets reopen their window on the frame boundary and nowhere else. If that
  signal ever stopped arriving while the patch stayed applied, the tesselation budget skipped
  *every* further entity shape — permanently, for every animated creature in the world — and
  held entities were never loaded. Both now notice the missing signal, run vanilla instead,
  and count it on the HUD; and neither arms itself at all if the measurement it depends on
  failed to apply. A budget that loses its reset has to degrade to slower, never to never.
- The patch guard was quiet about the collisions that matter most. Where Komet replaces an
  engine method outright (its prefix returns false), another mod's transpiler never runs, a
  prefix ordered behind Komet's is never called, and a postfix sees the result of Komet's
  transcription rather than the original's. All three used to be reported as "info". They are
  now high/high/medium with the reason spelled out — this is the shape behind reports of the
  "entities are invisible since I installed this mod" kind, and it should not need a bisect.

### Added

- German HUD and chat. The F7 overlay and the `.komet` replies follow the game language;
  English and German ship in `assets/komet/lang`. Missing translations fall back to the English
  text in the source, never to a raw key.
- **Reproducible release builds with a published checksum.** The same commit produces the same
  bytes, so the SHA-256 on the download page can be recomputed rather than merely trusted. The
  number is also published on the GitHub release, written by the build job.

### Changed

- Logs, reports and hitch lines are English. They used to be German. These end up in bug
  reports and get read by people who do not run the client that produced them — the HUD and the
  chat replies are the surfaces that follow the player's language, and nothing else does.
- The mod zip is stored, not compressed (~180 KB → ~450 KB). Identical data does not give
  identical deflate streams across zlib implementations, so compressing would have made the
  checksum unreproducible on a different machine. The download is larger; the promise holds.
- The unused `MeasureRenderStages` setting is gone from the config class. It was never read.
  The config layout version stays at 11 on purpose: an existing `komet.json` keeps working,
  the leftover key is ignored, and nobody's settings get regenerated over a dead entry.

### Internals

  • Every build runs on GitHub Actions: both mods built, the full patch and behaviour suite run
      against the real game assemblies, the packaged zips attached to the run, previews published
      under Releases. The SDK version is pinned in `global.json` — a different patch level produces
      a different assembly, which is measurable and would otherwise break reproducibility silently.
    - Source folders sit next to the project file and each one is its own namespace
      (`Culling/` → `Komet.Culling`, `Measure/` → `Komet.Measure`). Not cosmetic: an editor rule
      that derives namespaces from paths had rewritten a generated file and silently disabled the
      engine-drift check.
1.2.0-pre.2 komet
1.22.0-pre.1 - 1.22.7
112 Sep 3rd at 12:06 AM Komet_v1.2.0-pre.2.zip 1-click install

CHANGELOG:

  • Fixed measurement patch failures on overloaded engine methods

  • Fixed frozen GPU timing and added GPU usage tracking

  • Fixed GC/allocation statistics when HUD is disabled

  • Improved CPU thread budgeting for low-end hardware

  • Fixed excessive shadow map quality on low-end GPUs

  • Ignored false hitch reports while the game is paused

  • Fixed misleading Linux thread priority reporting

  • Added Harmony patch collision detection

  • Added engine build fingerprint verification

  • Added client-side allocation tracking and GC survivor statistics

  • Added allocation sampling by thread and object type

  • Added server block packet source tracking

  • Added mesh pool allocation tracking

  • Added per-stage GPU timing

  • Added dialog identification for large Ortho hitches

  • Improved diagnostics and crash/report accuracy

  • Expanded verification and regression test

1.2.0-pre.1 komet
1.22.0-pre.1 - 1.22.7
120 Sep 1st at 8:30 PM Komet_v1.2.0-pre.1.zip 1-click install

Changes

  • Incremental Cull Cache Removal
    • Replaced full cache rebuilds with direct slot removal for re-tessellated chunks.
    • Reduced unnecessary cache misses across 4–8 pools.
    • Added support for open appends during streaming to avoid unnecessary rebuild fallbacks.
  • Rebuild Attribution in Hitch Logs
    • Hitch log entries now report rebuild contribution as (X rebuilds, N pools).
    • Makes it easier to identify whether 11–16 ms sweeps are caused by cache rebuilds.
  • Frustum Culling for AnimatableRenderer
    • Added stage-specific frustum checks for animated block entities.
    • Skips rendering only when fully outside the relevant stage frustum.
    • Shadow stages use the corresponding light-space bounds.
    • Avoids unnecessary shader, lighting, uniform, UBO, and draw calls.
  • Dedicated Pool for Chunk Mesh Clones
    • Added size-class pooling for per-face arrays and custom-part data.
    • Reduced recurring 18 MB/s clone allocations.
    • Objects are now recycled instead of being allocated and discarded after Gen1 promotion.
    • Pool return is handled via TesselatedChunkPart.AddToPools rather than Dispose.
  • Added new Compact F7 Hud (Toggle by Pressing F7)
1.1.0 komet
1.22.0-pre.1 - 1.22.7
1072 Aug 30th at 9:43 PM Komet_v1.1.0.zip 1-click install

New

  • Visible border holes close first. While chunks stream in, the repair of an already-visible chunk border used to wait at the back of the tesselation queue, behind thousands of chunks nobody can see yet — up to several seconds of staring at a hole in the terrain (most obvious on the ocean surface). These repairs now jump the queue and upload immediately. Capped so block edits are never delayed noticeably; toggle live with .komet toggle edgeprio.
  • Allocation attribution. The F7 HUD and .komet report now split the process allocation rate by thread (main / network / prefetch / tesselation / rest) — the number that matters when hunting GC stutter.

Changed

  • Minimum game version is now 1.22.0 (was 1.22.7). Built and verified against 1.22.7; on other 1.22.x builds any patch whose engine code changed logs a warning and switches itself off individually — the game keeps running vanilla in that spot.
  • Config layout is now version 2 (new setting EdgeRetessPriority). An existing komet.json is backed up next to itself and regenerated with defaults — re-apply any custom values afterwards.
  • The edge-priority stat row always shows its sweep count while the feature is on, so a healthy-but-idle feature can never look like a broken one.
1.0.0 komet
1.22.0-pre.1 - 1.22.7
98 Aug 30th at 7:48 PM Komet_v1.0.0.zip 1-click install

- Initial release


83 Comments (oldest first | newest first) (threaded | flat)

wildforester, 1 hour ago (modified 1 hour ago)

Really an amazing mod, the performance increase I'm getting with it is fairly substancial! Although it'd appear I'm getting worse stuttering... gl on the rewrite! 
Side-note, the default ctrl+F7 screen isn't accessible on kde plasma, that keybind opens a window filter view.

Also suggestion for an fps cap when the window is minimized/in the background or hasn't been touched for a while.

NeoB, 1 day ago

It seems to work well with simple water tweaks

JustRichardTbh, 2 days ago

this mod is also incompatible with Synergy if it's installed client-side. Komet still works if Synergy is only installed on the server side.

xToast , 2 days ago
@JustRichardTbh: this mod is also incompatible with Synergy if it's installed client-side. Komet still works if Synergy is only installed on the server side.

Thank you for the report, I'll include this in the next feature release.

The next release may take a while, since I am doing a full rewrite of the entire Mod.

B0YAR, 3 days ago

Our players have lag spikes with this mod. Also sometimes we have flickering texture of player model. Also, when players try to mold something or carve some kind of tip, they catch microfreezes. When we removed the mod and reset the visual settings, everything returned to normal.

Electricboots, 3 days ago

Hello!

1.2.0 does not immediately crash or freeze my game, but I do freeze after a certain number of minutes. Examples:

  • game freezing while I was digging dirt, and I had to kill the process (log)
  • game freezing while I was on the water using my reed boat, and I had to kill the process (log part 1 - log part 2)

 

Thank you!

T3thys, 3 days ago (modified 2 days ago)
@Electricboots: Hello! 1.2.0 does not immediately crash or freeze my game, but I do freeze after a certain number of minutes. Examples: game freezing while I was digging dirt, and I had to kill the process (log) game freezing while I was on the water using my reed boat,

Also experiencing something similar after attempting to update to 1.2.0. The issue also seems to persist even though I no longer receive error messages when loading into a savegame and even if I disable komet. Let me know what logs I can provide to help with debugging.

 

Update: I opened the info panel using f7 and noticed that, when the game freezes up, the "outside" line under "frame breakdown" spikes above 50%, after which the panel becomes virtually useless as the entire game only updates every 30 seconds or more until I decide to force-close the game

xToast , 4 days ago

1.2.0 is now released!

TL:DR: Now with a new InGame Window by pressing CTRL+F7 or typing .komet into chat:

AND A LOT MORE, check out the release notes here!

Release Notes

Changelog:
## 1.2.0 Release

SHA256 Checksum: 4a1d0352e5d6e2fa017e3a6909ed54b5eb3ecacbdd6291dc37df82d5b74a2cb7 Komet_v1.2.0.zip

Github Release: https://github.com/xToast-dev/komet/releases/v1.2.0

Everything since 1.1.0, in one list. The four pre-releases and the work after them add up to: a far LOD that finally fixes the frame rate when you look at the horizon, the GPU side of the shadow passes, a worker pool instead of four thread sets, a measurement layer that can now answer “CPU or GPU?” and “which of my mods?”, and two crashes that should never have shipped.

The headline: a far LOD

  • Beyond the far distance a chunk is drawn as cells of two blocks, beyond twice that as cells of four. At view distance 1536 the camera pass drew 16,1 million triangles when looking at the horizon, 12,7 million of them beyond 640 blocks — where a block covers one to three pixels and the chunk vertex shader still exports thirteen vec4 and evaluates 3D noise for each of them.
  • Measured in the same scene, same session: 53 → 113 fps (19,0 → 8,9 ms/frame), camera-pass triangles 16,1 → 6,9 million, GPU frame 14,9 → 7,0 ms, and the camera opaque pass — timed bottom-of-pipe with a GPU elapsed query — 11,7 → 4,2 ms.
  • The picture is built from what the engine already tesselated, on the tesselation thread: unit faces mark their block solid, air floods through the rest, a cell is solid if any of its blocks is, and each solid cell gets one face per air neighbour carrying a real source face's texture, light and colour map. No shader is touched.
  • Plants, leaves, stairs and fences keep one representative per cell, scaled to fill it — a tree stays a tree, a house stays a house. The picture is never thinner than the world, only up to a block fatter, which is why chunks at different levels never leave a gap.
  • The engine's own meshes are not modified and not re-tesselated: they simply stop at the far distance. Switch the feature off and they are drawn everywhere again on the next frame. The shadow maps always use the engine's meshes, never the pictures.
  • Costs about 1,3 ms per chunk on the tesselation thread and roughly a third more vertices in the mesh pools. FarMesh, FarMeshDistance, FarMeshTier2; .komet farmesh <blocks|off|on> and .komet toggle farlod2 live.

Faster

  • One dynamic worker pool instead of four thread sets that could not see each other. Five cull helpers, four occlusion helpers, a window-prebuild thread and a prefetch thread became one pool whose workers take whichever job is worth most. Same sweep on fewer threads: 0,70 ms against 0,77 ms, and the workload that holds cores for milliseconds can no longer starve the one on the frame's deadline.
  • The far shadow map is no longer redrawn on every frame while you move. It was kept for a few frames and reprojected exactly, but a reprojection cannot extend what a kept map covers — so 15 cm of camera movement forced a redraw and the saving existed only while standing still. The map is now drawn 16 blocks wider than the fade needs, which is exactly the room the camera needs, and the redraw threshold rises with it.
  • The near shadow cascade gets a map of its own size (4096 px). The engine allocated both cascades from one expression, so a cascade covering the 39 blocks around you had over a hundred texels per block against the far map's fifteen.
  • The solid shadow passes use a depth-only shader and back-face culling. The engine's shadow shader samples the terrain texture and discards for every fragment of every pass; a closed block's back faces sit behind its front faces along the light ray too. Same depth map, half the faces, no texture fetch. Leaves and grass keep the engine's shader and cast from both sides.
  • The near cascade stops drawing what cannot cast a shadow on anything visible — the half of its depth range that faces away from the light, and casters that cannot reach a receiver on screen.
  • Far-detail stand-in geometry stays out of the shadow maps where the detailed version is already in them, decided per grid cell. On by default now; the old per-pool test never fired in a streamed world.
  • A new creature type no longer costs a hitch the first time you see one. The engine builds an animation's frames on the main thread the moment it first plays: 12 ms for a rooster, 53 ms for a pig, always in the frame the animal comes into view. They are now built on a worker while the entity is still held back.
  • The edge-repair sweep stopped rehashing the whole tesselation queue every 50 ms (4,6× to 7,3× on that sweep), the neighbour prefetcher stopped re-walking the same queue front hundreds of times a second, and the window prebuilder now predicts the chunk the tesselator will really mesh.
  • World joins hitch less and entities are finished under a per-frame budget, nearest one first. Distant creatures animate every second or third frame with the skipped time folded in — same speed, sampled less.
  • Server packets that are not chunk data run under a per-frame budget instead of stopping one frame dead, and the hitch that remains names the packet type behind it.
  • Less garbage per chunk. The mesh buffer recycler, tight clones, a pooled extras store and now the far LOD's own output arrays: 45,6 KB → 0,8 KB allocated per chunk build, measured against a real recycler.
  • Particle instance buffers are renamed instead of waited on, so a frame does not block on a buffer the GPU is still reading.

New

  • A performance window on .komet and Ctrl+F7 — nineteen pages, one per question, with every switch flippable in place. It takes no measurement of its own; the blocks it draws are the same methods the overlay and the report call.
  • A mod profiler with its own HUD (Shift+F7). Which of your mods costs what per frame, what each one does (patched methods, registered classes) and what it cost during loading, client and integrated server separately. .komet mods prints it as text for a bug report.
  • 1 % and 0,1 % lows, and a live frametime graph, next to the averages the mod always showed — the numbers that describe stutter rather than throughput.
  • A three-way answer to “CPU-bound or GPU-bound?”: GPU time per render stage, the driver's own busy figure where the system exposes it, and per-pass GPU timings measured bottom-of-pipe with fragment counts — the one measurement that tells fill rate from geometry without arguing.
  • The camera pass's triangles by render pass, distance band and LOD level, which is what turned “the horizon is slow” into a number and then into the far LOD.
  • .komet alloctrace [seconds] — the process records its own allocations with call stacks into a file next to the logs.
  • Komet notices when another mod patches the same engine method and says so once, with a severity and a reason, and fingerprints the engine at world start so a game update that changed a patched method is named instead of silently misbehaving. .komet conflicts lists it.
  • A warning at world join when Optimum or OptiTime is present. Both replace the same engine code, each unaware of the other; finding that out used to need a bisect. Komet stays enabled — which side should win is your call.
  • The HUD and the chat replies speak German when the game does. Logs, reports and hitch lines stay English on purpose: they end up in bug reports.
  • Server-side sync tuning for singleplayer — position updates thin out with distance, entity tracking gets a hysteresis band, attribute paths whose bytes did not change are not sent.
  • Live knobs for the visual trades, all reversible mid-session: .komet farmesh, .komet foliagerange, .komet shadowfoliagerange, .komet shadownear, .komet shadowneardepth, and a toggle table that lists every one of them with what it does.

Fixed

  • Crash on joining a world (NullReferenceException in WeatherSystemClient). The new task budget could spread a join's backlog over frames and let a renderer draw before the packet that initialises it had run. Joining is lifecycle, not load: the budget now starts only once the world is finalised.
  • Crash on the first frame with the Optimum client build (MissingFieldException: ClientMain.MainThreadTasksLock). The fork declares that field with a different type. It is now read by name and locked the way its type demands.
  • A German client's log filled with “Translation string format exception” — an error and a warning per HUD refresh for every label with a number, thousands per session.
  • Two budgets could stop for good instead of falling back. If their frame-boundary reset ever stopped arriving, entity tesselation skipped every further shape and held entities never loaded. Both now detect it, run vanilla and count it. A budget that loses its reset has to degrade to slower, never to never.
  • The patch guard was quiet about the collisions that matter most — where Komet replaces an engine method outright, another mod's transpiler never runs. Reported as high severity now, with the reason.
  • One malformed animation no longer costs a creature its whole warm-up, and the shadow cull range no longer forgot the light eye's 50-block offset.
  • Two toggles reported success and did nothing. Several measurements were booked to the wrong place: particles folded twice, GPU timing and GC statistics while the HUD was closed, mesh pool allocations, hitches in the 2D stage now name the dialog that caused them, and no more false hitch reports while the pause menu is open.

Changed

  • Config layout is now version 26 (a great many new settings since 1.1.0). An existing komet.json is backed up next to itself and regenerated from the current defaults — re-apply your custom values afterwards.
  • CullingThreads and OcclusionCullingThreads are gone, replaced by the worker pool's own sizing (physical cores minus two, so the render and tesselation threads keep theirs).
  • The mod zip is stored, not compressed (~180 KB → ~450 KB). Identical data does not give identical deflate streams across zlib implementations, so compressing would make the checksum below unreproducible on a different machine.
  • Minimum game version stays 1.22.0. Built and verified against 1.22.7; on other 1.22.x builds any patch whose engine code changed logs a warning and switches itself off individually.

Internals

  • The culling core is still proved byte-identical to vanilla on every build — 3.120/3.120 sweeps with identical triangles in identical order, 1.440/1.440 with the pool-box early-out, 2.304/2.304 pixel-equivalent gap merges — and the far LOD's picture is checked against the cell picture computed from a heightmap alone, on twelve random terrains, at both levels.
  • Every build runs on GitHub Actions: both mods built, the full patch and behaviour suite executed against the real game assemblies, the packaged zips attached to the run.
  • Release builds are reproducible: the same commit produces the same bytes, so the checksum below can be recomputed rather than merely trusted.
snowgeese14, 5 days ago

Thank you so much for this. Brings up fps from a inconsistent 100-120 fps up to a smooth and stable 170. I've used optimum for a while but I've found it can have some weird conflicts and bugs. I was wondering what makes Optitime unsupported and is it still possible to have both enabled? Also would you ever consider adding FSR or any sort of upscaling?

xToast , 4 days ago (modified 4 days ago)
@snowgeese14: Thank you so much for this. Brings up fps from a inconsistent 100-120 fps up to a smooth and stable 170. I've used optimum for a while but I've found it can have some weird conflicts and bugs. I was wondering what makes Optitime unsupported and is it stil

Well, regarding FSR or Upscaling, I didn't had any plans yet, since I am a fan of actual graphics (so raster graphics), not "ai enhanced" graphics like DLSS, FSR etc.. But if theres more demant, I might possibly add it to the roadmap.
Optitime patches similar paths, which breaks some of the implemented systems.

Rythillian, 5 days ago

"Optitime     Unsupported", does that mean we have to uninstall optitime or can both run at once?

xToast , 5 days ago
@Rythillian: "Optitime Unsupported", does that mean we have to uninstall optitime or can both run at once?

You can only run one, not both.

So you need to decide if you want to use Komet or Optitime.

ScatteredA, 5 days ago

This mod is incredible!!! I love to play highly modded games (115 in my current game) but I have to drop my view distance very low which is really immersion breaking for me. Been playing with my view distance at 800 with komet and it makes the game so much nicer to play

Lalatinala, 5 days ago

Thought this was compatible with optitime, but Just saw the message. on world join from the latest update

Electricboots, 5 days ago

Hello!

  • pre.1 works for me (log)
  • pre.2 would outright crash my game
  • pre.3, the world loads but the game freezes (not responding) until I kill the process (log)
  • pre.4, the world loads but the game freezes (not responding) until I kill the process (log)

 

This is on multiplayer on game version 1.22.5.

I also tried with my shader and "LOD" mod removed but it didn't help with pre.3 or pre.4...

Thank you!

xToast , 5 days ago (modified 5 days ago)

New pre-release!:

TL:DR

More Bugfixes!

Better performance!

A new Mod Hud Profiler (SHIFT+F7)

Better language support!

Read the entire Changelog here:

Detailed Komet 1.2.0-pre.4 changelog

Changelog
## Komet 1.2.0-pre.4

SHA256 Checksum: d643a8e24ac1ce5e514fec3746f3e07f689b51bec6563de6ceccc2f74425590d Komet_v1.2.0-pre.4.zip

Github Release: https://github.com/xToast-dev/komet/releases/tag/v1.2.0-pre.4

Changes since 1.2.0-pre.3. This release is mostly the GPU side of the frame: the first report
that could measure it found the two shadow passes taking 86 % of a GPU-bound frame, and four of
the five performance changes below come out of that one number.

### Faster

- The far shadow map is no longer redrawn on every frame while you move. It was already kept
  for a few frames and re-projected exactly — but a re-projection can only keep a kept map
  correctly *positioned*, not extend what it *covers*, so any camera movement of 15 centimetres
  forced a redraw. Walking, and especially flying, meant the saving never happened; it existed
  only while standing still. The map is now drawn a little wider than the shadow fade needs
  (16 blocks by default), which is exactly the room the camera needs to move without leaving it,
  and the redraw threshold rises to about 14 blocks in step. Costs about 6 % coarser far shadows;
  `ShadowFarBoxMargin` sets the trade, `.komet toggle shadowmargin` flips it live.
- The near shadow cascade gets a map of its own size. Both cascades used to be allocated from
  one expression, so the near map was as large as the far one — over a hundred texels per block
  for the ~39 blocks around you, against the far map's fifteen. Now 4096 px by default: a third
  of the fill rate for a difference nobody can see. `.komet shadownear 3072` changes it live.
- The solid parts of the shadow passes do a lot less work per fragment. Back-face culling
  drops half of every solid face before a fragment exists (a closed block's back faces sit behind
  its front faces along the light ray too, so the depth map is identical), and a depth-only shader
  spares the rest a terrain texture lookup. Leaves and grass are untouched and still cast from
  both sides.
- Far-detail stand-in geometry stays out of the shadow maps wherever the detailed version is
  already in them — the shadow pass had no distance rule at all and rasterised both.
- A new creature type no longer costs a hitch the first time you see one. The engine builds an
  animation's frames on the main thread the moment it first plays — 12 ms for a rooster, 53 ms for
  a pig, always in the frame the animal comes into view. They are now built on a worker while the
  entity is still held back, and the main thread finds them ready.

### New

- A mod profiler with its own HUD (Shift+F7). Every measurement this mod made so far named a
  part of the *engine* — a render stage, a renderer, a tick listener — and none of them answered
  the question somebody with forty mods installed actually asks: *which of mine is it*. The
  overlay lists your mods by what they cost per frame, what they do (engine methods patched,
  block/item/entity classes registered) and what each one cost during loading, client and
  integrated server separately. `.komet mods` prints the same as text for a bug report.
- It also prints what it cannot see instead of leaving it out: a Harmony patch runs inside the
  method it patches, so its time is booked to the engine — which is why the patch count sits next
  to the milliseconds — and block entity ticks, mod worker threads and GUI dialogs are not
  attributed at all.
- A warning at world join when Optimum or OptiTime is present. Both replace the same engine
  code Komet does, each unaware of the other, and finding that out used to take a bisect. Komet
  stays enabled — which side should win is your call.

### Fixed

- Crash on the first frame with the Optimum client build (`MissingFieldException:
  ClientMain.MainThreadTasksLock`, reported with Optimum v0.3.14). The fork declares that field
  with a different type, so the mod's binding no longer resolved. It is now read by name and
  locked the way its type demands; anything unexpected leaves that part vanilla instead of taking
  the client down.
- German clients filled their log with "Translation string format exception" — an error and a
  warning per HUD refresh for every label containing a number, thousands per session.

- A ton of more Bugfixes :)

### Changed

- Config layout is now version 15 (eight new settings since pre.3, five of them
  shadow-related). An existing `komet.json` is backed up next to itself and regenerated with
  defaults — re-apply your custom values afterwards.
- Minimum game version stays 1.22.0. Built and verified against 1.22.7; on other 1.22.x builds any
  patch whose engine code changed logs a warning and switches itself off individually.

Check with `sha256sum Komet_v1.2.0-pre.4.zip` (Linux) or `Get-FileHash Komet_v1.2.0-pre.4.zip`
(PowerShell). Release builds are reproducible: check out the tagged commit, run
`./build.sh release`, and the file comes out with exactly that checksum on 

ZapLizard, 5 days ago

This mod feels like those snake oil optimization tricks for a lot of games like Starbounds multi-core "fix", but it actually works. Honestly feels like magic. 

xToast , 6 days ago (modified 6 days ago)

Heya new Komet Pre-Release!

(As always, when reporting a Bug, please attach your log files! Without them I am unable to help or fix the issue in future releases!)

TL:DR for this Patch:
- A ton of Fixes!

- English HUD + Logs.

- Regarding the Maltiez Situation, I decided to implement a verification process. Therefore every release/patch will have an SHA256 attached to the release notes. The Mod is not being build on my machine, rather it's being build via. Github-Actions on the official Komet Repository (https://github.com/xToast-dev/komet), everyything is now easier to verify that the source code is the actual code ending up in the release!

Detailed CHANGELOG 1.2.0-pre.3

Changelog:
## 1.2.0-pre.3

SHA256 Checksum: d80c94ed06854f9a8d7cdcfc7fd56272481df03e1efcbc11ab7ef4b99be9fb59  Komet_v1.2.0-pre.3.zip

Github Release: https://github.com/xToast-dev/komet/releases/edit/v1.2.0-pre.3

Everything here answers a report from someone running pre.2, or follows from one.

### Fixed

Joining a world could crash the client with a `NullReferenceException` in
  `WeatherSystemClient.OnRenderFrame`. pre.2 introduced a per-frame budget on the main-thread
  task drain, and a world join queues hundreds of those tasks — including the one that
  finalises the level. Spreading that backlog over frames let a renderer that was already
  registered draw before the packet initialising it had run. The budget now starts only once
  the world is finalised: everything a join queues runs in the frame it arrives, exactly like
  vanilla. Joining is lifecycle, not load, and it is not the place to save milliseconds.
Two budgets could stop working instead of falling back. The entity tesselation and
  entity loading budgets reopen their window on the frame boundary and nowhere else. If that
  signal ever stopped arriving while the patch stayed applied, the tesselation budget skipped
  *every* further entity shape — permanently, for every animated creature in the world — and
  held entities were never loaded. Both now notice the missing signal, run vanilla instead,
  and count it on the HUD; and neither arms itself at all if the measurement it depends on
  failed to apply. A budget that loses its reset has to degrade to slower, never to never.
The patch guard was quiet about the collisions that matter most. Where Komet replaces an
  engine method outright (its prefix returns false), another mod's transpiler never runs, a
  prefix ordered behind Komet's is never called, and a postfix sees the result of Komet's
  transcription rather than the original's. All three used to be reported as "info". They are
  now high/high/medium with the reason spelled out — this is the shape behind reports of the
  "entities are invisible since I installed this mod" kind, and it should not need a bisect.

### Added

German HUD and chat. The F7 overlay and the `.komet` replies follow the game language;
  English and German ship in `assets/komet/lang`. Missing translations fall back to the English
  text in the source, never to a raw key.
- **Reproducible release builds with a published checksum.** The same commit produces the same
  bytes, so the SHA-256 on the download page can be recomputed rather than merely trusted. The
  number is also published on the GitHub release, written by the build job.

### Changed

Logs, reports and hitch lines are English. They used to be German. These end up in bug
  reports and get read by people who do not run the client that produced them — the HUD and the
  chat replies are the surfaces that follow the player's language, and nothing else does.
The mod zip is stored, not compressed (~180 KB → ~450 KB). Identical data does not give
  identical deflate streams across zlib implementations, so compressing would have made the
  checksum unreproducible on a different machine. The download is larger; the promise holds.
- The unused `MeasureRenderStages` setting is gone from the config class. It was never read.
  The config layout version stays at 11 on purpose: an existing `komet.json` keeps working,
  the leftover key is ignored, and nobody's settings get regenerated over a dead entry.

### Internals

  • Every build runs on GitHub Actions: both mods built, the full patch and behaviour suite run
      against the real game assemblies, the packaged zips attached to the run, previews published
      under Releases. The SDK version is pinned in `global.json` — a different patch level produces
      a different assembly, which is measurable and would otherwise break reproducibility silently.
    - Source folders sit next to the project file and each one is its own namespace
      (`Culling/` → `Komet.Culling`, `Measure/` → `Komet.Measure`). Not cosmetic: an editor rule
      that derives namespaces from paths had rewritten a generated file and silently disabled the
      engine-drift check.
    Spoiler

    Changelog:
    ## 1.2.0-pre.3

    SHA256 Checksum: d80c94ed06854f9a8d7cdcfc7fd56272481df03e1efcbc11ab7ef4b99be9fb59  Komet_v1.2.0-pre.3.zip

    Github Release: https://github.com/xToast-dev/komet/releases/edit/v1.2.0-pre.3

    Everything here answers a report from someone running pre.2, or follows from one.

    ### Fixed

    Joining a world could crash the client with a `NullReferenceException` in
      `WeatherSystemClient.OnRenderFrame`. pre.2 introduced a per-frame budget on the main-thread
      task drain, and a world join queues hundreds of those tasks — including the one that
      finalises the level. Spreading that backlog over frames let a renderer that was already
      registered draw before the packet initialising it had run. The budget now starts only once
      the world is finalised: everything a join queues runs in the frame it arrives, exactly like
      vanilla. Joining is lifecycle, not load, and it is not the place to save milliseconds.
    Two budgets could stop working instead of falling back. The entity tesselation and
      entity loading budgets reopen their window on the frame boundary and nowhere else. If that
      signal ever stopped arriving while the patch stayed applied, the tesselation budget skipped
      *every* further entity shape — permanently, for every animated creature in the world — and
      held entities were never loaded. Both now notice the missing signal, run vanilla instead,
      and count it on the HUD; and neither arms itself at all if the measurement it depends on
      failed to apply. A budget that loses its reset has to degrade to slower, never to never.
    The patch guard was quiet about the collisions that matter most. Where Komet replaces an
      engine method outright (its prefix returns false), another mod's transpiler never runs, a
      prefix ordered behind Komet's is never called, and a postfix sees the result of Komet's
      transcription rather than the original's. All three used to be reported as "info". They are
      now high/high/medium with the reason spelled out — this is the shape behind reports of the
      "entities are invisible since I installed this mod" kind, and it should not need a bisect.

    ### Added

    German HUD and chat. The F7 overlay and the `.komet` replies follow the game language;
      English and German ship in `assets/komet/lang`. Missing translations fall back to the English
      text in the source, never to a raw key.
    - **Reproducible release builds with a published checksum.** The same commit produces the same
      bytes, so the SHA-256 on the download page can be recomputed rather than merely trusted. The
      number is also published on the GitHub release, written by the build job.

    ### Changed

    Logs, reports and hitch lines are English. They used to be German. These end up in bug
      reports and get read by people who do not run the client that produced them — the HUD and the
      chat replies are the surfaces that follow the player's language, and nothing else does.
    The mod zip is stored, not compressed (~180 KB → ~450 KB). Identical data does not give
      identical deflate streams across zlib implementations, so compressing would have made the
      checksum unreproducible on a different machine. The download is larger; the promise holds.
    - The unused `MeasureRenderStages` setting is gone from the config class. It was never read.
      The config layout version stays at 11 on purpose: an existing `komet.json` keeps working,
      the leftover key is ignored, and nobody's settings get regenerated over a dead entry.

    ### Internals

    • Every build runs on GitHub Actions: both mods built, the full patch and behaviour suite run
        against the real game assemblies, the packaged zips attached to the run, previews published
        under Releases. The SDK version is pinned in `global.json` — a different patch level produces
        a different assembly, which is measurable and would otherwise break reproducibility silently.
      - Source folders sit next to the project file and each one is its own namespace
        (`Culling/` → `Komet.Culling`, `Measure/` → `Komet.Measure`). Not cosmetic: an editor rule
        that derives namespaces from paths had rewritten a generated file and silently disabled the
        engine-drift check.
TheBronzeWarrior, 6 days ago

installed, and now EVERYTHING is invisible

xToast , 6 days ago
@TheBronzeWarrior: installed, and now EVERYTHING is invisible

Could you provide me your client-main.log file?

T3thys, 6 days ago

Installed, and animals are now invisible. Turned it off and the animals were back to normal. Tested by switching to creative and spawning (invisible) chicks which reappeared after disabling the mod.

T3thys, 5 days ago
@xToast: Could you provide me your client-main.log file?

Looks like things are back to normal. Would you still like the client-main.log file before I update the mod?

xToast , 5 days ago
@T3thys: Looks like things are back to normal. Would you still like the client-main.log file before I update the mod?

Please use Pre.4 and drop me a log file if the issue still persists :)

T10, Sep 3rd at 9:56 AM

I installed pre2 and game crashed, reverted back to pre1 and it works fine.
Details:

Spoiler

Title: [1.2.0-pre.2] Main-thread task budget can render before LevelFinalize, causing WeatherSystemClient NRE

Vintage Story 1.22.7, Windows 64-bit. No Optimum or Optitime installed.

After updating Komet from 1.2.0-pre.1 to 1.2.0-pre.2, loading my existing singleplayer world crashed in:

System.NullReferenceException
  at WeatherSystemClient.OnRenderFrame(...) line 150
  at ClientEventManager.TriggerRenderStage(...)
  at ClientMain.TriggerRenderStage_Patch2(...)

The shipped 1.22.7 symbols map line 150 to:

WeatherDataAtPlayer.LoadAdjacentSimsAndLerpValues(...)

WeatherDataAtPlayer is initialized by WeatherSystemClient.LevelFinalizeInit.

The archived failing log never reaches “Handling LevelFinalize packet” or “Done init WeatherSystemClient” before the crash. After rolling back only Komet to pre.1, the same profile and world load successfully and both messages appear normally.

Pre.2 regenerated its configuration with AttributeMainThreadTasks enabled and MainThreadTaskBudgetMs set to 3.0. Its new ExecuteMainThreadTasks prefix can requeue remaining tasks for another frame instead of fully draining the queue. Since the level-finalize packet handler is a main-thread task, this appears to permit the Before-stage weather renderer to run before level finalization initializes WeatherDataAtPlayer.

Expected: lifecycle-critical tasks complete before registered world renderers run.

Actual: the weather renderer runs with its vanilla initialization incomplete and crashes the client.

Spoiler

Title: [1.2.0-pre.2] Main-thread task budget can render before LevelFinalize, causing WeatherSystemClient NRE

Vintage Story 1.22.7, Windows 64-bit. No Optimum or Optitime installed.

After updating Komet from 1.2.0-pre.1 to 1.2.0-pre.2, loading my existing singleplayer world crashed in:

System.NullReferenceException
  at WeatherSystemClient.OnRenderFrame(...) line 150
  at ClientEventManager.TriggerRenderStage(...)
  at ClientMain.TriggerRenderStage_Patch2(...)

The shipped 1.22.7 symbols map line 150 to:

WeatherDataAtPlayer.LoadAdjacentSimsAndLerpValues(...)

WeatherDataAtPlayer is initialized by WeatherSystemClient.LevelFinalizeInit.

The archived failing log never reaches “Handling LevelFinalize packet” or “Done init WeatherSystemClient” before the crash. After rolling back only Komet to pre.1, the same profile and world load successfully and both messages appear normally.

Pre.2 regenerated its configuration with AttributeMainThreadTasks enabled and MainThreadTaskBudgetMs set to 3.0. Its new ExecuteMainThreadTasks prefix can requeue remaining tasks for another frame instead of fully draining the queue. Since the level-finalize packet handler is a main-thread task, this appears to permit the Before-stage weather renderer to run before level finalization initializes WeatherDataAtPlayer.

Expected: lifecycle-critical tasks complete before registered world renderers run.

Actual: the weather renderer runs with its vanilla initialization incomplete and crashes the client.

xToast , Sep 3rd at 1:52 AM (modified Sep 3rd at 1:54 AM)

Heya snowgeese14 and MrFastZombie your crash logs suggest that something is overriding the patches, possibly another mod interfering with Komet.


Could you try launching the game in a world without any mods except Komet to see if the issue still occurs?


If it does, please also share your client-main.log.

 

Retroficient might be onto something, since it worked on his end after removing the potentially conflicting Maltiez mods.
You both appear to have libraries from Maltiez installed. This is just a guess, but it’s possible that a Maltiez library is causing the crash.

 

EDIT:  It could also be Optimum, since we both write to similar paths.

I still need to get more information from you guys, so that I am able to fix the issue :/

snowgeese14, Sep 3rd at 2:13 AM
@xToast: Heya snowgeese14 and MrFastZombie your crash logs suggest that something is overriding the patches, possibly another mod interfering with Komet. Could you try launching the game in a world without any mods except Komet to see if the issue still occurs? If

Updated to the latetest ConfigLib version (I wasn't aware of what happened with it until just now but damn that stuff is wild) - Crashing persists. Loaded optimum w/only Komet 1.2.0-pre.2 and crashing persists as well. Here is the crash log.

Crash Report
Running on 64 bit Windows 10.0.26200.0 with 32537 MB RAM
Game Version: v1.22.7 (Stable) + Optimum v0.3.14
9/2/2026 7:06:57 PM: Critical error occurred in the following mod: komet@1.2.0-pre.2
Loaded Mods: game@1.22.7, komet@1.2.0-pre.2, creative@1.22.7, survival@1.22.7
Involved Harmony IDs: komet
System.MissingFieldException: Field not found: 'Vintagestory.Client.NoObf.ClientMain.MainThreadTasksLock'.
   at MonoMod.Core.Interop.CoreCLR.V60.InvokeCompileMethod(IntPtr functionPtr, IntPtr thisPtr, IntPtr corJitInfo, CORINFO_METHOD_INFO* methodInfo, UInt32 flags, Byte** nativeEntry, UInt32* nativeSizeOfCode)
   at MonoMod.Core.Platforms.Runtimes.Core60Runtime.JitHookDelegateHolder.CompileMethodHook(IntPtr jit, IntPtr corJitInfo, CORINFO_METHOD_INFO* methodInfo, UInt32 flags, Byte** nativeEntry, UInt32* nativeSizeOfCode)
   at Komet.Patches.MainThreadTaskPatches.Execute(ClientMain game)
   at Komet.Patches.MainThreadTaskPatches.Execute(ClientMain game)
   at Komet.Patches.MainThreadTaskPatches.Prefix(ClientMain __instance)
   at Vintagestory.Client.NoObf.ClientMain.ExecuteMainThreadTasks_Patch1(ClientMain this, Single deltaTime)
   at Vintagestory.Client.GuiScreenConnectingToServer.RenderToDefaultFramebuffer(Single dt) in C:\Users\office-desktop2\Documents\game\VintagestoryLib\Client\MainMenu\Screens\GuiScreenConnectingToServer.cs:line 298
   at Vintagestory.Client.ScreenManager.Render(Single dt) in C:\Users\office-desktop2\Documents\game\VintagestoryLib\Client\ScreenManager.cs:line 783
   at Vintagestory.Client.ScreenManager.OnNewFrame(Single dt) in C:\Users\office-desktop2\Documents\game\VintagestoryLib\Client\ScreenManager.cs:line 686
   at Vintagestory.Client.NoObf.ClientPlatformWindows.window_RenderFrame_Patch1(ClientPlatformWindows this, FrameEventArgs e)
   at OpenTK.Windowing.Desktop.GameWindow.Run()
   at Vintagestory.Client.ClientProgram.Start(ClientProgramArgs args, String[] rawArgs)
   at Vintagestory.Client.ClientProgram.<>c__DisplayClass10_0.<.ctor>b__1() in C:\Users\office-desktop2\Documents\game\VintagestoryLib\Client\ClientProgram.cs:line 131
   at Vintagestory.ClientNative.CrashReporter.Start(ThreadStart start) in C:\Users\office-desktop2\Documents\game\VintagestoryLib\Client\ClientPlatform\ClientNative\CrashReporter.cs:line 95
Crash Report
Running on 64 bit Windows 10.0.26200.0 with 32537 MB RAM
Game Version: v1.22.7 (Stable) + Optimum v0.3.14
9/2/2026 7:06:57 PM: Critical error occurred in the following mod: komet@1.2.0-pre.2
Loaded Mods: game@1.22.7, komet@1.2.0-pre.2, creative@1.22.7, survival@1.22.7
Involved Harmony IDs: komet
System.MissingFieldException: Field not found: 'Vintagestory.Client.NoObf.ClientMain.MainThreadTasksLock'.
   at MonoMod.Core.Interop.CoreCLR.V60.InvokeCompileMethod(IntPtr functionPtr, IntPtr thisPtr, IntPtr corJitInfo, CORINFO_METHOD_INFO* methodInfo, UInt32 flags, Byte** nativeEntry, UInt32* nativeSizeOfCode)
   at MonoMod.Core.Platforms.Runtimes.Core60Runtime.JitHookDelegateHolder.CompileMethodHook(IntPtr jit, IntPtr corJitInfo, CORINFO_METHOD_INFO* methodInfo, UInt32 flags, Byte** nativeEntry, UInt32* nativeSizeOfCode)
   at Komet.Patches.MainThreadTaskPatches.Execute(ClientMain game)
   at Komet.Patches.MainThreadTaskPatches.Execute(ClientMain game)
   at Komet.Patches.MainThreadTaskPatches.Prefix(ClientMain __instance)
   at Vintagestory.Client.NoObf.ClientMain.ExecuteMainThreadTasks_Patch1(ClientMain this, Single deltaTime)
   at Vintagestory.Client.GuiScreenConnectingToServer.RenderToDefaultFramebuffer(Single dt) in C:\Users\office-desktop2\Documents\game\VintagestoryLib\Client\MainMenu\Screens\GuiScreenConnectingToServer.cs:line 298
   at Vintagestory.Client.ScreenManager.Render(Single dt) in C:\Users\office-desktop2\Documents\game\VintagestoryLib\Client\ScreenManager.cs:line 783
   at Vintagestory.Client.ScreenManager.OnNewFrame(Single dt) in C:\Users\office-desktop2\Documents\game\VintagestoryLib\Client\ScreenManager.cs:line 686
   at Vintagestory.Client.NoObf.ClientPlatformWindows.window_RenderFrame_Patch1(ClientPlatformWindows this, FrameEventArgs e)
   at OpenTK.Windowing.Desktop.GameWindow.Run()
   at Vintagestory.Client.ClientProgram.Start(ClientProgramArgs args, String[] rawArgs)
   at Vintagestory.Client.ClientProgram.<>c__DisplayClass10_0.<.ctor>b__1() in C:\Users\office-desktop2\Documents\game\VintagestoryLib\Client\ClientProgram.cs:line 131
   at Vintagestory.ClientNative.CrashReporter.Start(ThreadStart start) in C:\Users\office-desktop2\Documents\game\VintagestoryLib\Client\ClientPlatform\ClientNative\CrashReporter.cs:line 95

 

Loaded vanilla VS w/ only Komet 1.2.0-pre.2 loaded and no issues! Optimum is definately interacting w/ the newer version of your mod in some odd way. Hope this is some help! If you need any other logs or anything lmk

snowgeese14, Sep 3rd at 12:24 AM

Installed the most recent release and CtD when joining a server. Attachted the crashlog for you to take a look at. lmk if you need any other logs

Crash Report
Running on 64 bit Windows 10.0.26200.0 with 32537 MB RAM
Game Version: v1.22.7 (Stable) + Optimum v0.3.14
9/2/2026 5:21:19 PM: Critical error occurred in the following mod: komet@1.2.0-pre.2
Loaded Mods: chiseltools@1.17.6, rlldtco0001@1.4.1, ggbcsmodeltweaks@1.0.6, gltextureinvisiblechunkbugfix@1.0.0, jsonpatcheslib@1.5.3, limestonefromcaves@1.0.2, overhaulliblegacycompat@1.2.5, overhaullib@2.0.10, plainsandvalleys@1.0.13, renderfat@1.2.0, spinningwheel@1.2.0, usefulshears@1.0.0, vanillapluspatch@1.4.0, game@1.22.7, vsimgui@1.2.7, algernonsterrainsampler@1.3.0, animationslib@0.0.2, anvilperformanceoptimization@1.0.0, beamtweaksmod@2.0.0, bettererprospecting@3.2.2, betterruins@0.6.3, bettertraders@0.2.0, commonlibforked@2.8.1, configlib@1.12.0, fornax@1.3.1, helvehammerextcontinued@1.9.1, immersivewoodworking@1.0.0, knapster@4.0.0, komet@1.2.0-pre.2, majesticmaple@1.4.0, opineuponpine@1.1.0, quickmode@1.1.0, realsmoke@1.3.1, sheydermod@1.1.3, shipwright@1.4.1, smithingplus@1.9.0-rc.1, tasshunting@0.14.32, temperatureheighttweak@0.4.0, improvedmetallurgy@1.1.8, toolsmith@1.2.19, vintagehorizons@0.3.1, creative@1.22.7, vsroofing@1.7.1, survival@1.22.7, vsvaogc@1.1.3, wildfarmingfork@2.1.5, frameforgetsr@2.5.1, betterinsulation@0.3.0, combatoverhaulfork@0.18.1, gridforbeams@2.0.189, jammorefruitin@1.0.2, prospectorsdispatch@1.2.0, realsmokeqppatch@1.0.1, seraphleveling@1.14.0, smithingplusbugfix@2.0.0, tasshroomhardcorewinter@0.8.2, armoryfork@1.11.0
Involved Harmony IDs: komet
System.MissingFieldException: Field not found: 'Vintagestory.Client.NoObf.ClientMain.MainThreadTasksLock'.
   at MonoMod.Core.Interop.CoreCLR.V60.InvokeCompileMethod(IntPtr functionPtr, IntPtr thisPtr, IntPtr corJitInfo, CORINFO_METHOD_INFO* methodInfo, UInt32 flags, Byte** nativeEntry, UInt32* nativeSizeOfCode)
   at MonoMod.Core.Platforms.Runtimes.Core60Runtime.JitHookDelegateHolder.CompileMethodHook(IntPtr jit, IntPtr corJitInfo, CORINFO_METHOD_INFO* methodInfo, UInt32 flags, Byte** nativeEntry, UInt32* nativeSizeOfCode)
   at Komet.Patches.MainThreadTaskPatches.Execute(ClientMain game)
   at Komet.Patches.MainThreadTaskPatches.Execute(ClientMain game)
   at Komet.Patches.MainThreadTaskPatches.Prefix(ClientMain __instance)
   at Vintagestory.Client.NoObf.ClientMain.ExecuteMainThreadTasks_Patch1(ClientMain this, Single deltaTime)
   at Vintagestory.Client.GuiScreenConnectingToServer.RenderToDefaultFramebuffer(Single dt) in C:\Users\office-desktop2\Documents\game\VintagestoryLib\Client\MainMenu\Screens\GuiScreenConnectingToServer.cs:line 298
   at Vintagestory.Client.ScreenManager.Render(Single dt) in C:\Users\office-desktop2\Documents\game\VintagestoryLib\Client\ScreenManager.cs:line 783
   at Vintagestory.Client.ScreenManager.OnNewFrame(Single dt) in C:\Users\office-desktop2\Documents\game\VintagestoryLib\Client\ScreenManager.cs:line 686
   at Vintagestory.Client.NoObf.ClientPlatformWindows.window_RenderFrame_Patch1(ClientPlatformWindows this, FrameEventArgs e)
   at OpenTK.Windowing.Desktop.GameWindow.Run()
   at Vintagestory.Client.ClientProgram.Start(ClientProgramArgs args, String[] rawArgs)
   at Vintagestory.Client.ClientProgram.<>c__DisplayClass10_0.<.ctor>b__1() in C:\Users\office-desktop2\Documents\game\VintagestoryLib\Client\ClientProgram.cs:line 131
   at Vintagestory.ClientNative.CrashReporter.Start(ThreadStart start) in C:\Users\office-desktop2\Documents\game\VintagestoryLib\Client\ClientPlatform\ClientNative\CrashReporter.cs:line 95
Crash Report
Running on 64 bit Windows 10.0.26200.0 with 32537 MB RAM
Game Version: v1.22.7 (Stable) + Optimum v0.3.14
9/2/2026 5:21:19 PM: Critical error occurred in the following mod: komet@1.2.0-pre.2
Loaded Mods: chiseltools@1.17.6, rlldtco0001@1.4.1, ggbcsmodeltweaks@1.0.6, gltextureinvisiblechunkbugfix@1.0.0, jsonpatcheslib@1.5.3, limestonefromcaves@1.0.2, overhaulliblegacycompat@1.2.5, overhaullib@2.0.10, plainsandvalleys@1.0.13, renderfat@1.2.0, spinningwheel@1.2.0, usefulshears@1.0.0, vanillapluspatch@1.4.0, game@1.22.7, vsimgui@1.2.7, algernonsterrainsampler@1.3.0, animationslib@0.0.2, anvilperformanceoptimization@1.0.0, beamtweaksmod@2.0.0, bettererprospecting@3.2.2, betterruins@0.6.3, bettertraders@0.2.0, commonlibforked@2.8.1, configlib@1.12.0, fornax@1.3.1, helvehammerextcontinued@1.9.1, immersivewoodworking@1.0.0, knapster@4.0.0, komet@1.2.0-pre.2, majesticmaple@1.4.0, opineuponpine@1.1.0, quickmode@1.1.0, realsmoke@1.3.1, sheydermod@1.1.3, shipwright@1.4.1, smithingplus@1.9.0-rc.1, tasshunting@0.14.32, temperatureheighttweak@0.4.0, improvedmetallurgy@1.1.8, toolsmith@1.2.19, vintagehorizons@0.3.1, creative@1.22.7, vsroofing@1.7.1, survival@1.22.7, vsvaogc@1.1.3, wildfarmingfork@2.1.5, frameforgetsr@2.5.1, betterinsulation@0.3.0, combatoverhaulfork@0.18.1, gridforbeams@2.0.189, jammorefruitin@1.0.2, prospectorsdispatch@1.2.0, realsmokeqppatch@1.0.1, seraphleveling@1.14.0, smithingplusbugfix@2.0.0, tasshroomhardcorewinter@0.8.2, armoryfork@1.11.0
Involved Harmony IDs: komet
System.MissingFieldException: Field not found: 'Vintagestory.Client.NoObf.ClientMain.MainThreadTasksLock'.
   at MonoMod.Core.Interop.CoreCLR.V60.InvokeCompileMethod(IntPtr functionPtr, IntPtr thisPtr, IntPtr corJitInfo, CORINFO_METHOD_INFO* methodInfo, UInt32 flags, Byte** nativeEntry, UInt32* nativeSizeOfCode)
   at MonoMod.Core.Platforms.Runtimes.Core60Runtime.JitHookDelegateHolder.CompileMethodHook(IntPtr jit, IntPtr corJitInfo, CORINFO_METHOD_INFO* methodInfo, UInt32 flags, Byte** nativeEntry, UInt32* nativeSizeOfCode)
   at Komet.Patches.MainThreadTaskPatches.Execute(ClientMain game)
   at Komet.Patches.MainThreadTaskPatches.Execute(ClientMain game)
   at Komet.Patches.MainThreadTaskPatches.Prefix(ClientMain __instance)
   at Vintagestory.Client.NoObf.ClientMain.ExecuteMainThreadTasks_Patch1(ClientMain this, Single deltaTime)
   at Vintagestory.Client.GuiScreenConnectingToServer.RenderToDefaultFramebuffer(Single dt) in C:\Users\office-desktop2\Documents\game\VintagestoryLib\Client\MainMenu\Screens\GuiScreenConnectingToServer.cs:line 298
   at Vintagestory.Client.ScreenManager.Render(Single dt) in C:\Users\office-desktop2\Documents\game\VintagestoryLib\Client\ScreenManager.cs:line 783
   at Vintagestory.Client.ScreenManager.OnNewFrame(Single dt) in C:\Users\office-desktop2\Documents\game\VintagestoryLib\Client\ScreenManager.cs:line 686
   at Vintagestory.Client.NoObf.ClientPlatformWindows.window_RenderFrame_Patch1(ClientPlatformWindows this, FrameEventArgs e)
   at OpenTK.Windowing.Desktop.GameWindow.Run()
   at Vintagestory.Client.ClientProgram.Start(ClientProgramArgs args, String[] rawArgs)
   at Vintagestory.Client.ClientProgram.<>c__DisplayClass10_0.<.ctor>b__1() in C:\Users\office-desktop2\Documents\game\VintagestoryLib\Client\ClientProgram.cs:line 131
   at Vintagestory.ClientNative.CrashReporter.Start(ThreadStart start) in C:\Users\office-desktop2\Documents\game\VintagestoryLib\Client\ClientPlatform\ClientNative\CrashReporter.cs:line 95
Retroficient, Sep 3rd at 12:44 AM
@snowgeese14: Installed the most recent release and CtD when joining a server. Attachted the crashlog for you to take a look at. lmk if you need any other logs Crash Report Running on 64 bit Windows 10.0.26200.0 with 32537 MB RAMGame Version: v1.22.7 (Stable) + Optimum

I recently updated this and joined my private server with 128 mods (I did uninstall the old one, AKA removing it from my mods folder), and it worked just fine. I know it doesn't help directly, but I've been running stable with it. No 3rd party server either, just the main exe from the base game. 

snowgeese14, Sep 3rd at 12:49 AM
@Retroficient: I recently updated this and joined my private server with 128 mods (I did uninstall the old one, AKA removing it from my mods folder), and it worked just fine. I know it doesn't help directly, but I've been running stable with it. No 3rd party server eith

Interesting. Ahh well no worries. I am running a couple mods that may be causing some issues. I went back to version 1.1.0 and the issue seemed to resolve itself. I'll try it out again later and see if I can come up with anything else for you

MrFastZombie, Sep 3rd at 1:18 AM (modified Sep 3rd at 1:23 AM)
@Retroficient: I recently updated this and joined my private server with 128 mods (I did uninstall the old one, AKA removing it from my mods folder), and it worked just fine. I know it doesn't help directly, but I've been running stable with it. No 3rd party server eith

Do you use Optimum? I believe the crash me and snowgeese14 are experiencing may be a conflict with 1.2.0-pre.2 and Optimum so it might help to know if you don't.

Retroficient, Sep 3rd at 1:27 AM
@MrFastZombie: Do you use Optimum? I believe the crash me and snowgeese14 are experiencing may be a conflict with 1.2.0-pre.2 and Optimum so it might help to know if you don't.

I currently do not. I just use the vanilla server launcher, though I've thought about switching to that Fork just to see if my performance has increased. 

 

Funnily enough, en lieu of recent controversy, when I updated this mod, and also updated to the non-malware version of ConfigLib, my server and game has been running immaculate lol. 

snowgeese14, Sep 3rd at 1:50 AM
@MrFastZombie: Do you use Optimum? I believe the crash me and snowgeese14 are experiencing may be a conflict with 1.2.0-pre.2 and Optimum so it might help to know if you don't.

I do use optimum yes. Version 1.1.0 had no issues w/ optimum. I was also joining a server running Stratum which may be contribute as well, but still no issues w/ either on 1.1.0.

xToast , Sep 3rd at 1:57 AM (modified Sep 3rd at 2:08 AM)
@snowgeese14: I do use optimum yes. Version 1.1.0 had no issues w/ optimum. I was also joining a server running Stratum which may be contribute as well, but still no issues w/ either on 1.1.0.

Optimum might be the culprit here. Since the first preview release, I’ve worked hard to implement many more improvements and performance fixes.


It may well be that Optimum is the issue. It’s still a great mod, but I think Komet and Optimum won’t be compatible at all going forward.


We follow different coding philosophies: I use Harmony patching without modifying any DLLs. This allows Komet to be safely removed and makes installation easy, without requiring external Downloads or an Installer.


Optimum, on the other hand, patches the DLLs directly, which may have caused these incompatibilities.
Komet has expanded far beyond just “tweaking” fixes. It now also includes server patches, bug hole fixes, improved chunk loading, performance enhancements, extensive tweak sets, and more (take a look at the patch logs or the repository if you’re interested).
Komet will become a fully fledged performance mod for both server and client.


Shader mods such as SheyderMod and also LOD mods should remain compatible in the future.
Depending on how I decide to improve the mod, I might also implement my own version of FarLODs.


Komet is intended to be an all‑in‑one mod without limitations or issues such as mod conflicts. That’s why, in 1.2.0‑pre.2, I implemented an engine check that logs potential conflicts in client-main.log.


As you’ve seen in the patch logs, Komet 1.2.0 will be a huge update, adding a ton of new features. On my todo list, I also want to add an improved HUD with language support.

xToast , Sep 3rd at 12:10 AM

Hello guys, I've released a new Preview Build! (V.1.2.0-pre.2)

Changelog:

  • Fixed measurement patch failures on overloaded engine methods

  • Fixed frozen GPU timing and added GPU usage tracking

  • Fixed GC/allocation statistics when HUD is disabled

  • Improved CPU thread budgeting for low-end hardware

  • Fixed excessive shadow map quality on low-end GPUs

  • Ignored false hitch reports while the game is paused

  • Fixed misleading Linux thread priority reporting

  • Added Harmony patch collision detection

  • Added engine build fingerprint verification

  • Added client-side allocation tracking and GC survivor statistics

  • Added allocation sampling by thread and object type

  • Added server block packet source tracking

  • Added mesh pool allocation tracking

  • Added per-stage GPU timing

  • Added dialog identification for large Ortho hitches

  • Improved diagnostics and crash/report accuracy

  • Expanded verification and regression tests

 

Please note that this is a preview/beta build, it might be unstable, if you encounter any issues, submit an Issue on Github or on the official VS Discord Server in my "Mod Thread".

MrFastZombie, Sep 2nd at 11:06 PM

On 1.2.0-pre.1 the world seems to get stuck after loading in. Some chunks will load, and then it stops loading anything visually, but the chunks seem to actually be loading as I can see entities walking across the unloaded terrain and interact with the blocks I can't see. This is with Optimum so if you can't reproduce it might be that? I am aware that the compatibility isn't confirmed. Combining it with 1.1.0 seems to be working fine so far though I've just been flying around some worlds to test, not actually playing.

xToast , Sep 3rd at 12:11 AM
@MrFastZombie: On 1.2.0-pre.1 the world seems to get stuck after loading in. Some chunks will load, and then it stops loading anything visually, but the chunks seem to actually be loading as I can see entities walking across the unloaded terrain and interact with the bl

If you like to, you can try out the new 1.2.0-pre.2 Version out!

If you have any Issues (or even if it works!) it would be cool, if you could drop a comment :)

MrFastZombie, Sep 3rd at 1:01 AM (modified Sep 3rd at 1:01 AM)
@xToast: If you like to, you can try out the new 1.2.0-pre.2 Version out! If you have any Issues (or even if it works!) it would be cool, if you could drop a comment :)

Getting this crash upon loading the world with Optimum.

Crash Report
Running on 64 bit Windows 10.0.26200.0 with 65230 MB RAM
Game Version: v1.22.7 (Stable) + Optimum v0.3.14
9/2/2026 7:50:39 PM: Critical error occurred in the following mod: komet@1.2.0-pre.2
Loaded Mods: betterforest@0.1.2, blackraspberry@1.2.6, deciduoustrees@1.8.2, duncansgrass@1.0.1, floralzonescaperegion@1.0.35, floralzonescaribbeanregion@1.0.27, floralzonescentralaustralianregion@1.0.25, floralzonescircumborealregion@1.0.0, floralzonescosmopolitanregion@1.0.12, floralzoneseastasiaticregion@1.0.22, floralzonesmediterraneanregion@1.0.22, floralzonesneozeylandicregion@1.0.22, fruitrefreshed@1.1.0, jsonpatcheslib@1.5.9, leaflitter@1.2.6, primitivesurvival@5.1.3, seasonalflowers@1.1.2, terratag@0.6.0, game@1.22.7, vsimgui@1.2.7, wetcrops@1.2.2, zipline@1.0.8, aculinaryartillery@2.0.0-dev.21, algernonsterrainsampler@1.3.0, apegrapes@1.4.0, blocksoverlay@4.11.6, boatspeedtweaks@1.0.5, configlib@1.13.2, dairyplus@2.0.0-pre.2, farseer@1.4.0, fastmap@122.5.1, fiddleheads@1.0.0, grapplinghook@1.2.0, helianthus@1.0.5, herbarium@1.4.4, immersivemodularbackpacks@1.7.9, itempickuphighlighter@1.3.0, komet@1.2.0-pre.2, mealrecipefix@2.0.3, morefogplease@0.0.1, ingamedevtools@0.4.2, placeonslabs@1.2.0, projectiletracker@1.0.7, ricepaddies@1.0.4, snowcaps@0.0.1, statushudcont@4.4.0, tasshunting@0.14.41, temperatureheighttweak@0.4.0, tentbagreworked@3.2.4, terraprety@7.11.1, usefulstuff17@1.6.3, vintagetweaks@4.2.0, creative@1.22.7, vsecomachina@0.6.1, survival@1.22.7, watersheds@7.0.4, wcfefcompat@1.2.7, densegroundstorage@0.3.3, expandedfoods@2.0.0-dev.12, terrainslabs@1.0.17, wildcraftfruit@1.5.0, wildgrasscontinued@1.4.0, efchefstricks@1.0.0-dev.3, efmealsmodule@1.0.0-dev.5, haveyourberriesandeatthemtoo@1.0.0
Involved Harmony IDs: komet
System.MissingFieldException: Field not found: 'Vintagestory.Client.NoObf.ClientMain.MainThreadTasksLock'.
   at MonoMod.Core.Interop.CoreCLR.V60.InvokeCompileMethod(IntPtr functionPtr, IntPtr thisPtr, IntPtr corJitInfo, CORINFO_METHOD_INFO* methodInfo, UInt32 flags, Byte** nativeEntry, UInt32* nativeSizeOfCode)
   at MonoMod.Core.Platforms.Runtimes.Core60Runtime.JitHookDelegateHolder.CompileMethodHook(IntPtr jit, IntPtr corJitInfo, CORINFO_METHOD_INFO* methodInfo, UInt32 flags, Byte** nativeEntry, UInt32* nativeSizeOfCode)
   at Komet.Patches.MainThreadTaskPatches.Execute(ClientMain game)
   at Komet.Patches.MainThreadTaskPatches.Execute(ClientMain game)
   at Komet.Patches.MainThreadTaskPatches.Prefix(ClientMain __instance)
   at Vintagestory.Client.NoObf.ClientMain.ExecuteMainThreadTasks_Patch1(ClientMain this, Single deltaTime)
   at Vintagestory.Client.GuiScreenConnectingToServer.RenderToDefaultFramebuffer(Single dt) in C:\Users\office-desktop2\Documents\game\VintagestoryLib\Client\MainMenu\Screens\GuiScreenConnectingToServer.cs:line 298
   at Vintagestory.Client.ScreenManager.Render(Single dt) in C:\Users\office-desktop2\Documents\game\VintagestoryLib\Client\ScreenManager.cs:line 783
   at Vintagestory.Client.ScreenManager.OnNewFrame(Single dt) in C:\Users\office-desktop2\Documents\game\VintagestoryLib\Client\ScreenManager.cs:line 686
   at Vintagestory.Client.NoObf.ClientPlatformWindows.window_RenderFrame_Patch1(ClientPlatformWindows this, FrameEventArgs e)
   at OpenTK.Windowing.Desktop.GameWindow.Run()
   at Vintagestory.Client.ClientProgram.Start(ClientProgramArgs args, String[] rawArgs)
   at Vintagestory.Client.ClientProgram.<>c__DisplayClass10_0.<.ctor>b__1() in C:\Users\office-desktop2\Documents\game\VintagestoryLib\Client\ClientProgram.cs:line 131
   at Vintagestory.ClientNative.CrashReporter.Start(ThreadStart start) in C:\Users\office-desktop2\Documents\game\VintagestoryLib\Client\ClientPlatform\ClientNative\CrashReporter.cs:line 95

I did try loading it without Optimum, and that has stopped the crash so it does appear that 1.2.0-pre.2 is incompatible with Optimum 0.3.14.

I also tried 1.2.0-pre.1 again without Optimum and the issue I reported before was not occuring. So it seems that Optimum users should stick with 1.1.0 for now as long as it doesn't have any issues.

Balbrock, Sep 2nd at 11:00 AM (modified Sep 2nd at 11:02 AM)

It works extremely well for me with a Ryzen 7 3700X and an RX 9070 XT running in Fedora with 512 view distance, the game hits 210 FPS on Ultra settings with 170 mods installed! Performance is actually better than the vanilla, unmodded game.

DinoYeOldy, Sep 1st at 10:26 PM

I tried the preview build and had a problem.

The whole world got frosen visually after about a minute. Door still opens and it's hitbox highlights correctly as open or closed but its texture stuck as ghost. Same with anything like breaking a block or picking something up with carry on.

I tried restarting the game, reloading shaders and textures, running .komet safemode but nothing helped.
After downgrading back to 1.1.0 all got fixed. Updating broke it again so it's not a fluke i think. 

xToast , Sep 2nd at 6:49 AM (modified Sep 2nd at 6:50 AM)
@DinoYeOldy: I tried the preview build and had a problem. The whole world got frosen visually after about a minute. Door still opens and it's hitbox highlights correctly as open or closed but its texture stuck as ghost. Same with anything like breaking a block or pick

Hey DinoYeOldy, thank you for testing the preview build.

Would you be able to submit your log files (after you crash) to the Github Repository and open up an Issue?

Otherwise I am also available to contact via Discord at the official VS Discord.

Inside the #mods thread, you should be able to find my Thread. If you are already on the Vintage Story Discord Server, you can also open this Link: Komet Thread

Since without any logs, I am unable to help you sadly :(

DinoYeOldy, Sep 2nd at 1:49 PM (modified Sep 2nd at 2:30 PM)
@xToast: Hey DinoYeOldy, thank you for testing the preview build. Would you be able to submit your log files (after you crash) to the Github Repository and open up an Issue? Otherwise I am also available to contact via Discord at the official VS Discord. Inside th

Sorry if I wasn't clear.

Game did not crash. I can still play as normal, walk around, break blocks or open chests.
But if I break a block it's ghost still be there and I can walk through it or place something in it's place.
Doors still function the same but ghosts are not moving.

Could you tell me which logs should I send as I'm not sure if it's showing in them.

Also i'll try to record a screen capture and send it to discord to show the issue better. 

xToast , Sep 2nd at 7:06 PM
@DinoYeOldy: Sorry if I wasn't clear. Game did not crash. I can still play as normal, walk around, break blocks or open chests.But if I break a block it's ghost still be there and I can walk through it or place something in it's place.Doors still function the same but

Heya DinoYeOldy,

please send me the client-main.log and possibly also the client debug log file.

Also a Video File would be awesome.

When I receive them I'll take a look and try to fix it in the next preview release :)

abculatter_2, Sep 3rd at 1:20 AM
@xToast: Heya DinoYeOldy, please send me the client-main.log and possibly also the client debug log file. Also a Video File would be awesome. When I receive them I'll take a look and try to fix it in the next preview release :)

I recently tried this mod for the first time and also had this same issue. I for now I won't be able to send logs though I can later, and won't be able to send video though I can send pictures,

El_Neuman, Sep 1st at 8:47 PM

Gott, das ist ja pures Gold, mein Freund. Du bist eine Legende.
Ich werde das gleich auf meinem alten Laptop testen!

xToast , Sep 1st at 8:34 PM

Heya PandaBearJelly, Shey and DinoYeOldy. I've released a Preview Build of 1.2.0-pre.1, with more improvements and fixes. 

Try them out and let me know if you encounter any issues!

PandaBearJelly, Sep 1st at 5:19 AM

I'm not seeing any benefit from this at all. Identical performance with or without it. I have a higher and machine so maybe that's why? 9070xt, 9800x3D, 32gb

Shey, Sep 1st at 9:13 AM (modified Sep 1st at 10:13 AM)
@PandaBearJelly: I'm not seeing any benefit from this at all. Identical performance with or without it. I have a higher and machine so maybe that's why? 9070xt, 9800x3D, 32gb

For me it also makes no difference either with 5600H and RTX 3050 50w or 5950x and RTX 3080 but that really depends on the settings i use but that does not mean it doesn't work.
My Render distance is not great enough for the mod to show its effects.

The mod description states quote: " (...) The render-loop gains grow with view distance (...)" which is actually very important because this needs to be the case or sort of.
On the stronger machine i had at 1k blocks render distance 70 ish FPS without the mod, 110 ish with it. So the strength of the mod is present when it comes to insane render distances on slower IPC processors.

This is just an assumption but this is my guess why it behaves like that.
VS main thread where most of the logic of the game is being handled is only as fast as a single core on your machine. In your case your single threaded performance is outstanding which gives the main thread many head room for tasks in its queue which means when you add mods or render distance to your game the added amounts of work on the main thread doesn't matter because your single core performance is so fast it doesn't need the extra head room. Since the mod, pressumably, doesn't change the method in general how things get computed you won't feel a noticable increase in performance cause the method itself used by the game starts being the bottleneck at this point and not the amount of CPU overhead. Thus smaller systems that run faster into overhead feel the difference and you not, just by you simply posessing an outstanding processor.

snowgeese14, Aug 31st at 10:43 PM

Loaded it w/ Optimum playing on a Stratum server and have had no issues so far. Game runs insanely well now it's crazy thank you so much

ImpureSoul3, Aug 31st at 10:26 PM

this needs to be compatabile with stratum and optimum the biggest optimization going on rn they have a discord check it out

UsulMuadib, Aug 31st at 10:05 PM

does this conflict with farseer?

xToast , Sep 1st at 8:05 AM
@UsulMuadib: does this conflict with farseer?

Hello UsulMuadib,

it should be compatible with Farseer, Distanthorizons and other LOD Mods :)

Stahl, Aug 31st at 6:07 AM

In the mod description is says Side: Both. Shouldn't it be client only? 

xToast , Aug 31st at 6:21 AM
@Stahl: In the mod description is says Side: Both. Shouldn't it be client only?

Both is correct. Komet has a small server-side component that tunes the integrated server's chunk pipeline (worldgen thread count, request queue size) via komet.json, it never touches your servermagicnumbers.json and rolls back automatically when the mod is removed. Everything rendering-related is client-only. The mod works fine on a client joining a vanilla server, and a server running Komet doesn't require clients to have it.

Cuttlebear, Aug 31st at 1:09 AM

This brought my heavily modded (like 120 mods) game from 25 fps to  74 fps. This is crazy. Thank you so much!

DinoYeOldy, Aug 30th at 11:08 PM

Could you explain partial compatibility with optimum? Do i need to disable something in optimum or komet for the best results?

xToast , Aug 30th at 11:17 PM (modified Aug 30th at 11:42 PM)
@DinoYeOldy: Could you explain partial compatibility with optimum? Do i need to disable something in optimum or komet for the best results?

Hey DinoYeOldy


by "partially supported" I mean that Optimum and Komet patch the engine in different ways.

Optimum modifies copies of the Vintage Story assemblies directly, while Komet patches the engine at runtime via Harmony.

Since both touch the same rendering paths, running them together could potentially be unstable.
A tester ran both together and it worked fine, but I haven't been able to test it myself yet, that's why it's only marked as partially supported for now.

You shouldn't need to disable anything in either mod; if you run into issues, let me know which Optimum settings you're using.


Once I get more feedback, I'll update the tag accordingly

DinoYeOldy, Aug 30th at 11:54 PM
@xToast: Hey DinoYeOldy by "partially supported" I mean that Optimum and Komet patch the engine in different ways. Optimum modifies copies of the Vintage Story assemblies directly, while Komet patches the engine at runtime via Harmony. Since both touch the same re

Speaking of it

Crash Report
Running on 64 bit Linux (KDE neon User Edition) [Kernel 7.0.0.30] with 11844 MB RAM
Game Version: v1.22.7 (Stable) + Optimum v0.3.14
8/31/2026 2:49:07 AM: Critical error occurred
Loaded Mods: walkingstick@3.0.10, beamsgoinminingbag@1.0.0, bola@1.4.2, catchledge@0.7.1, craftfirepit@1.0.0, crawlanddive@0.2.5, creaturefootsteps@1.3.1, curefirewood@1.0.1, darkvision@1.3.6, deciduoustrees@1.8.2, earthfed@1.1.0, farmlandnutrientmanagement@1.5.2, freelook@1.0.5, leaflitter@1.2.6, moredrygrassfix@1.1.0, moredrygrass@0.2.0, dinocompmod@0.0.1, primitivesurvival@5.1.3, prospecttogether@2.2.1, p3bagtweaks@1.0.0, p2lumbersling@1.0.3, sconce@1.0.6, fixscythe@0.2.1, shelfobsessed@2.2.1, stonequarryrepckfipil@3.6.3, subtleparticlesplus@1.2.0, vaultandroll@0.1.2, visibleoresandminerals@1.4.1, game@1.22.7, vsimgui@1.2.7, zoombuttonreborn@2.0.4, airthermomod@0.5.0, alchemy@2.1.21, alternativegliderimplementationreforged@1.0.3, altmapiconrenderercontinued@1.6.0, ancienttoolsresinharvest@1.0.0, archering@1.0.7, attributerenderinglibrary@3.2.0, egocaribautomapmarkers@5.0.3, bearsshiftyearth@1.2.1, bedspawnv2@1.7.1, betterentityinteraction@1.0.5, bettererprospecting@3.4.8, betterhandbook@1.0.9, betternails@3.0.3, bloodtrail@1.2.5, bowpatch@1.2.0, bradyladder@1.2.2, butchering@1.14.3, carryon@1.14.3, caveinfix@1.0.5, chiselwiz@5.1.0, climbmountain@0.2.4, composterrepack@0.3.2, configlib@1.13.0, critcherscalculator@1.3.0, danatweaks@4.0.1, daytrader@1.0.6, equipstats@1.0.5, expandedbeekeepingfork@0.3.1, extrainfo@2.2.1, farmlanddropswithnutrients@1.2.2, fixperishrate@1.0.1, flameagainstrust@1.22.3-dev.0, foodshelves@3.0.5, footprints@1.2.5, groupedorenames@1.1.0, handbookdeclutterer@2.0.1, hudclockpatch@4.4.1, hudshelf@0.3.2, invfarming@1.0.4, immersivebackpacks@1.3.4, immersivemodularbackpacks@1.7.6, itempickuphighlighter@1.3.0, itempickupnotifier@2.2.0, itemsyncfixes@1.0.9, justthepepper@3.0.0, komet@1.1.0, morepiles@3.0.1, mycoboost@0.0.4, navi@1.0.10, nomusicinterruptionmod@1.0.0, oreveintracers@1.2.0, particlesplus@2.5.8, pencil@2.2.0, pinmatrix@1.7.0, postsandbeams@1.5.1, precisionknapping@1.4.3, purposefulstorage@2.1.1, quickarrowselection@1.0.1, restfulsit@1.2.0, ropeladderplacement@1.0.2, scaffolding@1.3.1, securecookingpots@1.0.3, statushudcont@4.4.0, stoneprospect@1.0.1, substrate@2.0.0, synergy@1.1.25, tentbagreworked@3.2.4, translocatorpaths@1.2.2, treetapredux@1.2.7, unofficialbugfix@0.1.2, vintagetweaks@4.2.0, creative@1.22.7, vsroofing@1.7.2, survival@1.22.7, wallkickswillwork@1.2.0, wildfarmingfork@2.1.9, autoconfiglib@2.0.10, butcheringpoultry@1.2.1, butcheringtooldurability@1.0.0, freshnessoverlay@0.4.37, gravestones@0.2.0, heatretentioncontinued@1.0.3, hudshelfessentials@0.5.1, immersivebackpackscompattweaks@0.0.3, storagetweaks@1.4.1-rc.3, universaldisplaylib@1.1.2, windowdisplaypatches@1.0.4, windowdisplay@1.0.4
Involved Harmony IDs: komet
System.IndexOutOfRangeException: Index was outside the bounds of the array.
   at System.Collections.Generic.HashSet`1.AddIfNotPresent(T value, Int32& location)
   at Vintagestory.Client.NoObf.ClientWorldMap.MarkChunkDirty_Patch3(ClientWorldMap this, Int32 cx, Int32 cy, Int32 cz, Boolean priority, Boolean sunRelight, Action OnRetesselated, Boolean fireEvent, Boolean edgeOnly)
   at Vintagestory.Client.NoObf.ClientWorldMap.SetChunksAroundDirty(Int32 cx, Int32 cy, Int32 cz)
   at Vintagestory.Client.NoObf.ClientWorldMap.OverloadChunkMT(Packet_ServerChunk p, ClientChunk newchunk)
   at Vintagestory.Client.NoObf.ClientMain.ExecuteMainThreadTasks(Single deltaTime)
   at Vintagestory.Client.GuiScreenRunningGame.RenderToPrimary(Single dt)
   at Vintagestory.Client.ScreenManager.Render(Single dt)
   at Vintagestory.Client.ScreenManager.OnNewFrame(Single dt)
   at Vintagestory.Client.NoObf.ClientPlatformWindows.window_RenderFrame(FrameEventArgs e)
   at OpenTK.Windowing.Desktop.GameWindow.Run()
   at Vintagestory.Client.ClientProgram.Start(ClientProgramArgs args, String[] rawArgs)
   at Vintagestory.Client.ClientProgram.<>c__DisplayClass10_0.<.ctor>b__1()
   at Vintagestory.ClientNative.CrashReporter.Start(ThreadStart start)

I don't think i changed any settings in optimum except maybe particle render distance.

xToast , Aug 30th at 10:42 PM

Now with some example images! :)

xToast , Aug 30th at 9:05 PM

Art_Master, I'm already on it and fixing stuff :)

Art_Master, Aug 30th at 9:11 PM
@xToast: Art_Master, I'm already on it and fixing stuff :)

Amen, mein bruder von einer anderen Mutter! Throw me a message so I get pinged when it's updated :D My low spec laptop will love this mod!!!

Art_Master, Aug 31st at 6:48 PM
@xToast: Updated :)

My man! You are legen - wait for it... DARY!!

I can confirm that this mod works on my low end laptop that normally sees around 30 fps with the game on the absolute lowest settings possible including 50% resolution scaling at 720p :D

With the exact same settings, I'm getting a stuttery 55 fps in open planes, and 40 fps in the dense forest. Much better than what I had!

Art_Master, Aug 30th at 8:51 PM (modified Aug 30th at 8:57 PM)

This mod does not work for 1.22.3 (stable) ;((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((

"Unabe to load mod. Requires dependency game v1.22.7"