New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A recent chobby update prevent it to launch #755
Comments
How recent? There was an engine update yesterday. |
I'll push itch ZK with the new engine today, maaybe that will fix it. The Linux binary hasn't been updated in years AFAIK, but Zero-K.exe from website also not working is concerning. |
GoogleFrog : I posted the issue the day I noticed the problem, if that is your question. Downloaded a few minutes ago the Zero-K semi-portable Version 64 posted 1 day ago, still the same errors. |
Downloading and running itch semi-portable package works for me on Ubuntu 20.04, implying it's something system-specific. What is your version of mono and related packages? ( |
I updated a machine to Linux Mint 20 (MATE) last night, coincidentally, and I was able to reproduce the 'Unhandled Exception' issue with the itch semi-portable build OOTB when running ./Zero-K_linux64.sh. A workaround for the same error on Terraria Servers works on my Linux Mint 20 install of Zero-K. For me, that was to It took a while before any activity happened, but it did continue on and fully load Chobby. EDIT: What on earth? Chobby runs as long as any TERM value is set. It doesn't have to point at a terminal or valid command. It also succeeded when replacing xterm with gibberish or even left as a blank space. $ TERM= ./Zero-K_linux64.sh After some circling back to your post, this might not help ZK run on your system, but might be useful for other people trying to load the itch build or finding the source of the issue. I also installed the Steam version to make sure that wasn't affected. The game launches from Steam without needing any workarounds, though Zero-K_linux64.sh still cannot be run directly. |
I tested and confirm Chobby DO launch with
That did the trick but I'd really like to know why this SUDDEN behavior as it worked without that last week :/ Here is the output of the console
|
Perhaps something that is neither mono nor zk changed on your system? @Porkch0p 's original workaround seems to require installing xterm, so perhaps that package got actually removed or something. |
I was surprised to not see it installed in the first place. I uninstalled xterm after that branch of testing, so my TERM= ./Zero-K_linux64.sh is being done without xterm present. If it just started happening to @versus666 after a recent package update there might be some relevant changes near the end of /var/log/dpkg.log or /var/log/apt/history.log It seems like the problem will probably be related to this issue in Mono mono/mono#6752 or maybe ncurses. Really strange that it should be showing up now. |
Update :
Sadly I can't paste the neat display of my updates so here is the raw content of /var/log/dpkg.log, knowing I played the 16th after the updates, didn't play but only made updates the 18th and then noticed chobby didn't launch anymore the 22th. Many reboots during and after that period.
@Anarchid : never fiddled with xterm, Linux Mint have xterm by default and it is working. |
Update 2 Then began the debug. Restored the original files and renamed ONE AFTER THE OTHER ALL the folders of the original spring folder and put the v65's folders instead : After an hour and all the folders tested, out of patience, I overwrote everything in the original spring folder with the v65's folders :+ I begin to think it just nag me. |
I didn't see anything obvious in the list of package updates after it stopped working, but your crash state in Update 1 seems like it might be kicked off by PlasmaDownloader. If you encounter that crash again, maybe try starting Zero-K without an internet connection to see if it bypasses the error? Also, that crash looks to be the same as ZeroK-RTS/Zero-K-Infrastructure#2301 |
Without internet connexion :
|
Standalone requires internet to update. You can put it into dev mode (see the wiki somewhere) to disable that, but then will break in other ways if it required the update. |
Tried with the Zero-K semi-portable v66 from yesterday overwriting my dirs, got this :
We'll see if it will still work at the next reboot... |
And the fun was short.
Time to overwrite again... |
Found something, I share it may helps.
Maybe a corrupted update ? After fiddling with the files I know overwriting cache/repositories.json with the file from the semi portable archive v66 triggers the message Zero-K.exe Information: 0 : PackageRefresh complete - packages changed and its size increase from 8m to 11 megs. Overwriting the folders with the V66 doesn't allow it to run. Even the pristine just extracted v66 doesn't run with the usual TERM= ./Zero-K_linux64.sh |
I tried grabbing the v67 semi-portable itch build on Linux Mint 20, and during extraction got a Data Error on the same file referenced at the top of your log. Chobby appears to open for me even with these problems when setting TERM. Also of note, v67 seems to not have the libc update in ZeroK-linux64.sh to allow the game to run on non-debian distros out of the box. |
Tried the v69, overwriting my dirs. Succeeded to launch and I got this when playing a solo game
No crash, let's see how long it will works.
"Magic number is wrong" imply a corrupted file but why would it works with TERM and without TERM with double click ? [EDIT] I usually tried with Linux Mint default console (GNOME Terminal 3.36.1.1). Tried (again ?) with xterm console instead. Worked fine WITHOUT (obviously) the TERM workaround. As expected you could say. -> So something in the default console of Linux Mint do block the expected behavior of Zero-K_linux64. (but doesn't explain why it suddenly wouldn't work anymore) |
Guess what ? Worked yesterday, not working anymore :/ No update except 1 related to GRUB. The only real difference is the game file updated :
Any idea ? |
Working again with with v70.
Doesn't work without TERM, as usual. |
And as usual it worked 2 days ago, now doesn't work anymore for no apparent reason...
|
Me again ! Same thing as usual. Error in the system console :
infolog_full.txt from the last games from the 30th (quite long) : |
Guess what !! Yesterday I tried Zero-K.exe with WINE and it ran ! It updated some stuff (and changed the executable) and took a looong time to check the filesystem/files. And worked fine. BUT THEN today I tried to launch it with TERM= ./Zero-K_linux64.sh and it worked, unlike the last few days !!!! So it seems there is a second-best option to play but the mystery thicken for the reasons behind the problem... |
I can confirm that after a week the native ZK lobby crash at launch and I have to launch Zero-K.exe with WINE, it update ZK menus (or a name like that) then check the filesystem for a dozen of seconds. Then the native linux, after another lengthy check on his side, works fine for a week. And crash suddenly after that. Had that after exiting today's session, don't know if it's related 👍
|
Long time no see ! ZK behaved fine for a while then the dreaded bug shown it's ugly face today
But that would be fun if the now usual way to get the game working with wine worked. And I'm out of options... |
I realized it decided to try to use a very old Wine ( 3.6 ), so I did a very vile hack (/opt $ sudo mv wine-staging wine-staging- && sudo ln -s /home/versus666/.PlayOnLinux/wine/linux-amd64/wine-6.0-staging-tkg-amd64 wine-staging + copied wine.desktop from wine-staging-/share/applications to the new linked dir so I would still be able to launch .exe from the GUI ) and I managed to launch Zero-K.exe who updated itself, scanned the archives like it was newly installed, then I exited and I launched the usual :
Who scanned again the archives and finally ran before I exited manually. So anyone got an idea to fix this ? |
Don't have a fix for you at the moment, sorry, but have a couple developments with our old friend TERM=
If this is a more widespread issue across linux distros preventing people from launching on Linux, it might not be a terrible idea to set a TERM= line inside the shell script at some point. 'TERM=linux' appears to be a fairly sane default. Also, both my Linux Mint and Manjaro systems are using 'xterm-256color' by default. If I manually set 'TERM=xterm-256color' in the script, it will crash 🤔 |
Coincidentally, a support thread on discord just ran into this same problem, this time for an Arch user. We had to manually set TERM in order to get the shell script to run. |
Linux Mint 20, no recent update to mono.
Haven't played for a few days, chobby was working fine, now it won't launch. Getting this on the console :
Checked on the web, redownloaded https://zero-k.info/lobby/Zero-K.exe, no change.
Tried this as I saw it fixed the problem for similar cases :
Tried to remove the file packages/2e6ae03f98f334ae8cea377e78198675.sdp
No change
Added official repositories for mono and updated it :
(updated it with synaptic then)
Went from 6.8.0.105 to 6.10.0.104
No change.
I read it's about dependencies but I don't know if it's on the client or at the file/package/project compilation.
Saw on https://zerok.itch.io/zero-k Zero-K semi-portable Version 62 was updated 4 days ago and that match the window.
The text was updated successfully, but these errors were encountered: