2.0.10

Removed 'unstripped_corlib' installer as these libs were removed as a dependency from BepInEx. If these files remain, Valheim will crash-loop.

2.0.9

A minor update to deal with BepInEx updates. This change ensures local BepInEx libraries are kept in-sync upon every launch. This became apparent after today's IronGate's Unity update, causing BepInEx to crash the engine. Our client wasn't checking to ensure the local client matched the remote server. Now it does.

Commit 8a49df1 solves the issue.

2.0.8

Changes

• Added "WriteBackendFile" method to capture the originating PhValheim Server details and write them to a local file, per world context. This allows the phvalheim-companion mod to send client-side notifications back to the phvalheim server. The first feature we've enabled is world progression tracking. All worlds will now boss/head icons that light up when the head is hung at the alters, indicating how many bosses have been defeated.
• Corrected a .NET library inclusion issue on Windows. All dependencies are now part of a single .exe.

Demo of the new hungHead feature

Head Hung

Client BepInEx console

Public Interface

See https://github.com/brianmiller/phvalheim-companion for more info.

2.0.7

phvalheim-client v2.0.7

• Linux clients!

  • .deb, .rpm and universal .tar.gz packages

• Repackaged Windows client

  • Packages .NET runtime into a single executable with phvalheim-client
  • Moved to .msi instead of self-extracting exec to mitigate false-positive anti-virus triggers
    • Note: I'll maintain a copy of the old .exe client installer until <=phvalheim-server v2.5 ages out.

• Build process

  • We now have a complete build revamp for the client that results in .msi, .deb, .rpm, and .tar.gz packages in respective docker containers to maintain native library compatibility.

I've tested Ubuntu 22.10, Fedora 34, Fedora 35 and Fedora 37 with their respective packages and the universal tarball. Everything seems to be working properly. I'll be focusing on bug fixes and any issues that come in and building a flatpak option for the Steam Deck 🤞 .

2.0.6

After released phvalheim-client v2.04 that was intended to organize world files under subdirectories with the name of the source phvalheim-server, I missed one condition.

Commit af8cd42 resolves this issue.

The observed behavior:
If the local world files and directories already exist and a new md5 appears (world updates), the client is supposed to delete the local data and replace it with the new payload. This deletion logic was unable to perform the deletion task because the final path was invalid due to the organizational nesting.

The code error:

The corrected code:

2.0.5 Add version checking

This release adds client version checking. Notifications will appear in the launch window indicating version status. phvalheim-client >=2.0.5 will now compare the local version of the client with the latest release tag from this GitHub repository.

If any client >=2.0.5 is out-of-date with this GitHub repo, a notification will appear:

You're running a version that matches the published version:

You're running an older version that what is published:

You're running a newer version than what is published (dev builds):

2.0.4 Organize world files with server name

Issue:

• Connect to server A with world name A
• Connect to server B with world name A

Connecting between these two worlds will always cause the client to resync remote world files. This update simply organizes world files with the source phvalheim server.

phvalheim-client >= 2.04 will now download world files under a subdirectory with the same name as the phvalheim-server the client connects to.

2.0.3 Disparate location support

Solves issue #1

This took more work than I expected. The registry doesn't hold any keys indicating the location of a game. I.e., the Steam library the game was installed into.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall captures the location the game was installed to but is only updated once the game is uninstalled.

Commit c060882 solves the issue with custom logic by using the .vdf and .acf files that the Steam client creates and updates during library population.

I've tested this logic with local disks, local USB drives and network mounted SMB shares. All work as a Steam Library and all now work with PhValheim. I've also tested migration scenarios. e.g., "Move install folder..."

-Brian

2.0.2

Introduced http/https detection for non-tls terminated deployments