Skip to content

Derive the translated resource pack id from the pack contents - #417

Closed
AlexProgrammerDE wants to merge 1 commit into
ViaVersionAddons:mainfrom
AlexProgrammerDE:t3code/deterministic-resource-pack-id
Closed

AlexProgrammerDE wants to merge 1 commit into
ViaVersionAddons:mainfrom
AlexProgrammerDE:t3code/deterministic-resource-pack-id

Conversation

@AlexProgrammerDE

Copy link
Copy Markdown
Collaborator

Description

Fixes #416.

The resource pack pushed to the Java client got a random UUID on every join, so the client's server resource pack cache could never be reused. The client re-downloaded and fully re-applied the entire converted pack on every join, adding a 30-75 second hang on the loading screen (visible in client logs as a new server/0000000X/ cache entry with a fresh UUID per join, followed by a full Reloading ResourceManager pass).

The pack id is now derived deterministically from the content identities of the advertised resource packs together with the ViaBedrock version:

  • Same server packs + same ViaBedrock version -> same id -> the client reuses its cached copy and skips the download
  • Server packs change (new content identity or version) -> new id -> the client re-downloads
  • ViaBedrock update (different conversion output) -> new id -> the client re-downloads

The packs are sorted before hashing so the id is stable regardless of the order the server advertises them in.

Testing

  • gradlew build passes
  • Verified locally against a BDS 1.26.45.1: the pack id is now stable across joins and proxy restarts, and the client no longer shows a full resource reload per join

The resource pack pushed to the java client got a random UUID on every
join, so the client's server resource pack cache could never be reused
and the whole converted pack was re-downloaded and re-applied on every
join, adding a 30-75 second hang on the loading screen.

Derive the pack id deterministically from the content identities of the
advertised resource packs and the ViaBedrock version, so the client
reuses its cached copy across joins and only re-downloads when the
server's packs or the conversion actually changed.
@AlexProgrammerDE

Copy link
Copy Markdown
Collaborator Author

Superseded by draft PR #420, which waits for the effective Bedrock stack and advertises the SHA-1 of the exact converted ZIP so the Java client can cache it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Java clients re-download and re-apply the translated resource pack on every join (random pack UUID)

1 participant