Mods / Komet - Performance Mod
- Tags:
- 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.
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:
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.
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 safemodeflips 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
RenderRangethe 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 conflictslists 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 Identifier | For Game version | Downloads | Released | Changelog | Download | 1-click mod install* |
|---|---|---|---|---|---|---|---|
| 1.2.0 | komet | 547 | 4 days ago | Komet_v1.2.0.zip | 1-click install | ||
Changelog:
| |||||||
| 1.2.0-pre.4 | komet | 143 | 5 days ago | Komet_v1.2.0-pre.4.zip | 1-click install | ||
Changelog
| |||||||
| 1.2.0-pre.3 | komet | 90 | 6 days ago | Komet_v1.2.0-pre.3.zip | 1-click install | ||
Changelog:
| |||||||
| 1.2.0-pre.2 | komet | 112 | Sep 3rd at 12:06 AM | Komet_v1.2.0-pre.2.zip | 1-click install | ||
CHANGELOG:
| |||||||
| 1.2.0-pre.1 | komet | 120 | Sep 1st at 8:30 PM | Komet_v1.2.0-pre.1.zip | 1-click install | ||
Changes
| |||||||
| 1.1.0 | komet | 1072 | Aug 30th at 9:43 PM | Komet_v1.1.0.zip | 1-click install | ||
|
New
Changed
| |||||||
| 1.0.0 | komet | 98 | Aug 30th at 7:48 PM | Komet_v1.0.0.zip | 1-click install | ||
|
- Initial release | |||||||



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.
It seems to work well with simple water tweaks
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.
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.
Heya, I am currently doing a full rewrite of the entire Mod since the Mod grew so fast and my initial system are not really fitting for what I am building.
Regarding the Lagspikes, could you maye provide logs? For example the client-main.log file.
https://dropmefiles.com/Cd5Ce
Hello!
1.2.0 does not immediately crash or freeze my game, but I do freeze after a certain number of minutes. Examples:
Thank you!
Thank you for the detailed report! I will try to resolve the issues for 1.2.1!
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
It would be really helpful, if you would include your client-main.log file after running .komet report
The next release includes a full rewrite of the entire Mod, so that may take a while.
Looks like the issue resolved itself somehow. Happy I didn't lose my savegame permanently lol.
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!
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
FarMesh,FarMeshDistance,FarMeshTier2;.komet farmesh <blocks|off|on>and.komet toggle farlod2live.Faster
New
.kometand 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..komet modsprints it as text for a bug report..komet alloctrace [seconds]— the process records its own allocations with call stacks into a file next to the logs..komet conflictslists it..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
NullReferenceExceptioninWeatherSystemClient). 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.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.Changed
komet.jsonis backed up next to itself and regenerated from the current defaults — re-apply your custom values afterwards.CullingThreadsandOcclusionCullingThreadsare gone, replaced by the worker pool's own sizing (physical cores minus two, so the render and tesselation threads keep theirs).Internals
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?
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.
Fair enough! I wasn't aware FSR, DLSS, so on was AI-related. Whatever optimization and/or features get added to this will be a plus regardless of what they are.
Well, you're right, maybe I will add this maybe in future releases!
"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.
And what about synergy and tungsten?
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
Thought this was compatible with optitime, but Just saw the message. on world join from the latest update
Hello!
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!
Thank you for the detailed report!
New pre-release!:
TL:DR
More Bugfixes!
Better performance!
A new Mod Hud Profiler (SHIFT+F7)
Better language support!
Read the entire Changelog here:
Changelog
## Komet 1.2.0-pre.4
SHA256 Checksum:
d643a8e24ac1ce5e514fec3746f3e07f689b51bec6563de6ceccc2f74425590d Komet_v1.2.0-pre.4.zipGithub 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
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.
Well, if you want to know how it works, read the source code, everything is publicly readable <:
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!
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
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.
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
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.
installed, and now EVERYTHING is invisible
Could you provide me your client-main.log file?
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.
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?
Please use Pre.4 and drop me a log file if the issue still persists :)
I installed pre2 and game crashed, reverted back to pre1 and it works fine.
Details:
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.
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.
Hey T10, thank you for your detailed report. I will fix this issue for the next preview build :)
Just to report, I also occasionally have this error, though it doesn't CTD all the time.
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 :/
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.
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
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
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.
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
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.
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.
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".
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.
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.
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.
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.
Watch out for the next release, I've implemented much more Stuff ;)
I will release the next preview build this week!
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.
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 :(
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.
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,
Gott, das ist ja pures Gold, mein Freund. Du bist eine Legende.
Ich werde das gleich auf meinem alten Laptop testen!
Kein Ding :)
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!
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.
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
this needs to be compatabile with stratum and optimum the biggest optimization going on rn they have a discord check it out
It is already compatible with Stratum :) I am aswell on their Discord!
does this conflict with farseer?
Hello UsulMuadib,
it should be compatible with Farseer, Distanthorizons and other LOD Mods :)
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.
This brought my heavily modded (like 120 mods) game from 25 fps to 74 fps. This is crazy. Thank you so much!
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
Speaking of it
I don't think i changed any settings in optimum except maybe particle render distance.
Does the crash also happen on the Vanilla Client without Optimum?
I'm not sure i can check it cause crash happen randomly while i was running. after restart all worked fine.
Now with some example images! :)
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!!!
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!
well, you will see even more performance imrpovements in future releases. :)
Check from time to time into the ModDB Page.
This mod does not work for 1.22.3 (stable) ;((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
"Unabe to load mod. Requires dependency game v1.22.7"