Lock Server To Specific Game Version

[Phelms215]

Context

Implement new environment variable that allows the server own to lock the game version to a specific version. Creates a "fake" acf file to allow for easy upgrades and version unlocking by removing or modifying the environment variable.

Choices

Initially planned to utilize clean version numbers (1.3.0,1.4.0). However this would require an update every version. Utilizing the manifest ID allows for future updates.

Test instructions

1. Add DEPOT_MANIFEST_ID environment variable, based on options
   1.3.0 | 1354752814336157338
   1.4.0 | 4190579964382773830
   1.4.1 | 6370735655629434989

Checklist before requesting a review

• I have performed a self-review of my code
• I've added documentation about this change to the README.
• I've not introduced breaking changes.

[MSpreckels]

Nice. I wonder how do you know which manifest id belongs to which palworld version?

[Phelms215]

Nice. I wonder how do you know which manifest id belongs to which palworld version?

@MSpreckels

Using SteamDB and matching up the mainfests to the update times
https://steamdb.info/depot/2394012/manifests/

[xHyperElectric]

Nice. I wonder how do you know which manifest id belongs to which palworld version?

@MSpreckels

Using SteamDB and matching up the mainfests to the update times https://steamdb.info/depot/2394012/manifests/

why not use build ids since steamdb shows what update version each build ID's are? (The unlabeled ones are hotfix. 1.3.0 hotfix, 1.4.1 hotfix)
https://steamdb.info/app/1623730/patchnotes/

[Phelms215]

why not use build ids since steamdb shows what update version each build ID's are? (The unlabeled ones are hotfix. 1.3.0 hotfix, 1.4.1 hotfix) https://steamdb.info/app/1623730/patchnotes/

Because the steamcmd download_depot requires the manifest ID. So with build Ids we'd still have to then do a rest api call to get the manifest ID. Not really seeing the benefit

[Phelms215]

Also the build ID is actually the same.

1.3.0 - Manifest ID: 1354752814336157338- Build ID: 13378465 - https://steamdb.info/depot/2394012/history/?changeid=M:1354752814336157338

1.4.0 - Manifest ID: 4190579964382773830 - Build ID: 13378465 - https://steamdb.info/depot/2394012/history/?changeid=M:4190579964382773830

1.4.1 - Manifest ID: 6370735655629434989 - Build ID: 13378465 -
https://steamdb.info/depot/2394012/history/?changeid=M:6370735655629434989

[xHyperElectric]

Also the build ID is actually the same.

1.3.0 - Manifest ID: 1354752814336157338- Build ID: 13378465 - https://steamdb.info/depot/2394012/history/?changeid=M:1354752814336157338

1.4.0 - Manifest ID: 4190579964382773830 - Build ID: 13378465 - https://steamdb.info/depot/2394012/history/?changeid=M:4190579964382773830

1.4.1 - Manifest ID: 6370735655629434989 - Build ID: 13378465 - https://steamdb.info/depot/2394012/history/?changeid=M:6370735655629434989

good catch. Could we cross reference the build id page for automated version numbering?

[Phelms215]

By automated version numbering are you referring to the more friendly 1.3.0,1.4.0 etc?

The issue is the old manifests are not attached publicly to the server app. So the depot lookup is basically a reverse lookup (starting with files and figuring out which is which).

I couldn't think of an easy way to implement it that didn't remove a lot of functionality for people being locked on specific hot fixes or other missed scenarios.

[xHyperElectric]

By automated version numbering are you referring to the more friendly 1.3.0,1.4.0 etc?

Yes, if you could request to download a specific manifest number from steam cmd then you could first check the build id page to see what number it was and allow for an env variable of an easy version number

[Phelms215]

I don't really think getting that clean of an environment variable is viable. Or at least any solution to implement it feels way over engineered. Determining which one was 1.3.0 would be hard enough let alone a non numbered hotfix.

Though I did find of an easy way to switch to Build ID and look up the manifest id in the depot with an api call so I'll move to that. Folks will still have to figure out which is which, but a bit easier.
https://steamdb.info/app/2394010/patchnotes/

I'll change the environment variable to TARGET_BUILD_ID as well as I think it fits better

[xHyperElectric]

Though I did find of an easy way to switch to Build ID and look up the manifest id in the depot with an api call so I'll move to that. Folks will still have to figure out which is which, but a bit easier. https://steamdb.info/app/2394010/patchnotes/

So you don't think it would be viable to compare the dedicated server build id dates to the client palworld instance build id dates to figure out version numbers?

For example, the 25th of January client build id is: 13269235 which is version 0.1.3.0. Therefore the 25th of January build id for dedicated server (13269059) must also be version 0.1.3.0. Same thing for version 1.4.0 and 1.4.1

[Phelms215]

Client Side and Dedicated Server are separate applications within steam. An update on one doesn't have to occur on the other. How would you select the 27th build? What happens if a same day hotfix occurs? Or server only patch?

Way too much effort for the task

[xHyperElectric]

Good point. Yeah it's probably not gonna work

[thijsvanloef]

@Phelms215 During testing I run into the following error:

palworld-server  | Connecting anonymously to Steam Public...OK
palworld-server  | Waiting for client config...OK
palworld-server  | Waiting for user info...OK
palworld-server  | Downloading depot 2394012 (1629 MB) ... 
palworld-server  | Depot download complete : "/home/steam/steamcmd/linux32\steamapps\content\app_2394010\depot_2394012" (46 files, manifest 4190579964382773830)
palworld-server  | Work thread 'CJobMgr::m_WorkThreadPool:2' is marked exited, but we could not immediately join prior to deleting -- proceeding without join
palworld-server  | /home/steam/steamcmd/linux32/steamapps/content/app_2394010/depot_2394012/ does not exist.
palworld-server  | DOWNLOAD OF REQUESTED MANIFEST ID 4190579964382773830 FAILED!
palworld-server exited with code 0

[Phelms215]

@thijsvanloef Sorry about that - looks like the check code got reverted earlier when I pulled out the logging functions. Was using fileExists vs dirExists. Will push that change again in a bit for completeness.

That being said there is a bug in this I discovered last night. If someone were to remove the flag and attempting to update would not happen due to the manifest file being incorrect.

Steam's API only tracks the latest Build ID inside of the depot, not easily linking them. SteamDB.info doesn't have a public api so the only way to properly link the Build ID and Manifest ID would be to use a steam api key. This doesn't sound like a viable option

So I think the actual best course of action would be to move the update flag checks from BuildId to ManifestId as that is guaranteed to be unique per version and would not require the user to submit both a BuildId and ManifestId to lock the version.

Also if my other pull request #356 is okay this one should wait until after that is completed to make the changes cleaner all around.

Probably best to close this one out and resubmit but let me know how you'd like me to proceed

[thijsvanloef]

@Phelms215 You can either close this one and reopen or mark this one as draft, whichever you prefer

[Phelms215]

Closing to move to new branch/PR