search

MitchTalmadge / AMP-dockerized

CubeCoders AMP in a Docker Image. Easily create game servers for games like Minecraft, GMod, TF2, Factorio, and StarBound!
https://hub.docker.com/r/mitchtalmadge/amp-dockerized
Other
91 stars 22 forks source link

Got a ploblem with Valheim #92

Closed kieeps closed 2 years ago

kieeps commented 3 years ago

I haven't tried much else then Minecraft and Valheim, but for some reason i have to run docker exec --user amp amp-linux ampinstmgr --nocache upgradeall after every time i restart the container or the Valheim instances wont start. would it be possible to have the instance upgraded on container start?

It already updates everything else :)

kieeps commented 3 years ago

wait.... i just checked main.sh and it seems to already do just that:

# Upgrade instances
echo "Upgrading Instances..."
su ${APP_USER} --command "ampinstmgr UpgradeAll" | grep --line-buffered -v -E '\[[-#]+\]'

maby just add the --nocache tag then?

EDIT: PR up

MitchTalmadge commented 3 years ago

Thank you, I think this was caused by CubeCoders releasing a patch under the same version number as the original release, which my continuous deployment scripts cannot detect. I've started a release of v18 which should hopefully solve this.

Adding nocache breaks the way this repository works, since I bundle the CubeCoder update file with the container image, and I rely on the cache mechanism to apply the update. I had nocache in the past and it resulted in an update being applied every single time the container was restarted which was very slow due to how CubeCoders limits download speeds.

kieeps commented 3 years ago

I see, yeah that would slow things down for sure :-)

Not sure how often this issue would appear, many it was one weird one time thing since releasing an update with the same version number seems like a human error :-D do they expose the md5/CRC on the update files somewhere?

EDIT: v18 did fix this problem

MitchTalmadge commented 2 years ago

I see, yeah that would slow things down for sure :-)

Not sure how often this issue would appear, many it was one weird one time thing since releasing an update with the same version number seems like a human error :-D do they expose the md5/CRC on the update files somewhere?

EDIT: v18 did fix this problem

Thanks for the suggestion! I found out that they expose a last-modified header on the update file, so I was able to bake that into the auto update workflow here on GitHub. Now this shouldn't happen again :)

Glad to hear it's fixed.