[isaacsa2]

What changes for the player?

Updating an unrelated dependency no longer makes openOMSI recompress every cached texture on the next start. Texture-code and decoder changes still invalidate the cache. This targets unnecessary loading work after updates, not the frame rate while driving.

How to test

Load a map to warm the compressed-texture cache, then compare builds that differ only in an unrelated dependency. Existing cached textures should be reused. A decoder or production texture-source change should rebuild them.

Screenshots

No visible change.

What changes, and why?

The source key in omsi-texture/build.rs used every published package in Cargo.lock. It now traverses only the published dependencies of omsi-texture (72 entries with the current lock), and excludes *_tests.rs from the source hash. Target, manifest, cache format, source-file metadata and content checks remain part of the key. Only this build script changes.

The release comparison in fork PR #322 found 8 invalidations in 12 releases with the old key and 4 with this key. That is a cache-key comparison, not a measured loading-time or FPS improvement.

Validation

• Fork PR Self-steering or actively steered rear axles on articulated busses like Van Hool ag and agg300 and ikarus 280. #322: Release, workspace/platform tests, PR checks, CodeQL and secret scan passed on 1e43dda. Its texture suite reported 87 passing tests.
• The branch merges cleanly with current upstream main.
• Independent review: the Rust dependency selector matches a separate TOML traversal on the current lock (72 packages).
• Four direct checks of the actual build script pass: an unrelated rustls-webpki update preserves the key; an image update changes it; a test-only source addition preserves it; a production-source addition changes it.
• Fresh cargo test -p omsi-texture --locked against the branch merged with current upstream main: 87 passed, 0 failed. Size budget, crate layers and whitespace checks passed too.

Limits

The Windows cache hit across a real game update has not been checked here. A missed dependency could reuse stale compressed data, which is why relevant-source and decoder invalidation were checked explicitly.

Performance

No feature added. No new gameplay benchmark or FPS claim.

Source: isaacsa2#322

[github-actions]

Test builds for 1e43dda

Platform	Download
Android (arm64)	android.zip
Linux x64 (game and dedicated server)	linux-x64.zip
macOS (Apple silicon)	macos-arm64.zip
Windows x64 (game and dedicated server)	windows-x64.zip

• Unpack the download into a new folder, not over your openOMSI. The launcher shows the version as ...-pr3360, and a test build is never updated. It shares your settings and OMSI 2 folder; mods you installed into your openOMSI folder are only seen when you unpack it into a copy of that folder.
• Android: the download holds an APK that installs as a separate app, openOMSI PR Textures: keep the compressed cache across unrelated dependency updates #3360, beside the release, and shares its openOMSI folder.
• What to try is under How to test in the description. Please comment with what you found and the version the launcher shows.
• The links work for 14 days after the build.

[thibautgnt]

Thanks @isaacsa2, nice targeted fix: the key now follows only what can change a compressed texture, and I checked that it still does. A cache entry is a function of the file's bytes (xxh64 in Key::new), the extension, the GPU options, omsi-texture's own sources and the decoders, and omsi-cfg only reads the files (whose bytes are in the key), resolves paths and reads sidecar flags that never reach the stored texture. Running the same traversal on the current lock gives the 72 packages, with image, its decoders (zune-jpeg, png, tiff, exr, image-webp, gif, qoi, zlib-rs...), texture2ddecoder and rayon all in, and format_tests.rs / transparency_tests.rs are both #[cfg(test)] only, so leaving them out is safe.

Non-blocking:

1. crates/omsi-texture/build.rs:52: Cargo writes a dependency as "name version (source)" when two packages share a name and version from different sources. split_once(' ') then compares "1.2.3 (registry+...)" with the entry's version, the dependency is skipped silently, and an update of it would no longer invalidate the cache. Nothing in today's lock has that form, but taking only the second whitespace token (dep.split_whitespace().nth(1)) closes it for free.
2. image's feature list lives in the root Cargo.toml ([workspace.dependencies]), which is not in the key (it was not before either). A feature that adds or removes a decoder crate shows up in the lock, so it is covered; one that only toggles code inside image is not. Feeding just that image = ... line would cover it without bringing back the invalidations on unrelated workspace changes. Fine as a follow-up.