co-

I'm using Linux too but microphone works just fine. What distro are you using? Also does your microphone work with other applications?

I confirm there's definitely a bug in PZ RCON implementation. For example when I send the SERVERDATA_AUTH packet to pz server, when everything goes fine the response is 14 bytes long, but sometimes it's 28 bytes long. For example, when I send this exact same payload multiple times: 12000000414243440300000031323334353637380000 sometimes the response is valid (14 bytes): 0a00000041424344000000000000 but sometimes not (28 bytes): 0a000000414243440000000000000a00000041424344020000000000 When it fails you can clearly see the response contains twice the expected response payload. Here's a python code sample I've been using to troubleshoot this issue: #!/usr/bin/python3 import os import socket import struct def serverdata_auth(socket, rcon_id, passwd): passwd = bytes(passwd, encoding='ascii') rcon_type = struct.pack('I', 3) packet_size = struct.pack('I', 10 + len(passwd)) payload = packet_size + rcon_id + rcon_type + bytes(passwd) + b'\x00\x00' print(payload.hex()) return socket.send(payload) def serverdata_auth_response(socket, rcon_id): response = socket.recv(4096) print(len(response)) print(response.hex()) if len(response) != 14: raise Exception('Invalid response length') size, sess_id, rcon_type, b1, b2 = struct.unpack('IIIcc', response) def rcon_command(host, port, passwd, command): sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect((host, int(port))) rcon_id = b'\x41\x42\x43\x44' #os.urandom(4) print('RCONID: %s' % rcon_id.hex()) serverdata_auth(sock, rcon_id, passwd) serverdata_auth_response(sock, rcon_id) rcon_command('127.0.0.1', 27015, '12345678', 'players')

Hello, I think there is an issue with release 41.64 regarding the comparison of mod files on client and server side. After release 41.64 I'm getting the infamous error: Workshop item version is different than the server's The workshop ID provided in the error is 2640351732 (See screenshot attached), which is a mod I'm developing named "Spear Traps" (see https://steamcommunity.com/sharedfiles/filedetails/?id=2640351732) Yet, all the files from my mod are identical on both client and server. See following output as proof: Copying my mod files from Steam workshop local directory to a directory named client: $ cp -r ~/.steam/steam/steamapps/workshop/content/108600/2640351732/mods/SpearTraps/ client Copying my mod files from Steam workshop on my server to a directory named server: $ scp -r pztest:pzserver/steamapps/workshop/content/108600/2640351732/mods/SpearTraps/ server Computing MD5 hash for every file in client directory, saving output to a file named client.md5: $ find client/ -type f -exec md5sum {} \; | sort -k 2,2 | awk '{ print $1 }' > client.md5 Computing MD5 hash for every file in server directory, saving output to a file named server.md5: $ find server/ -type f -exec md5sum {} \; | sort -k 2,2 | awk '{ print $1 }' > server.md5 Comparing the result, we can see both files client.md5 and server.md5 are identical, meaning all the hashes of each file are the same in both client and server: $ md5sum client.md5 server.md5 eed766a149a2d1eb295446f2efde3202 client.md5 eed766a149a2d1eb295446f2efde3202 server.md5 Both files client.md5 and server.md5 are provided as attachment, and also the zipped folders client and server are attached in case you want to check. Is there something that comes into play other than the content of the files to decide if there's a mismatch between client and server files? client.md5 server.md5 client.zip server.zip

It seems the procedure I described in my previous post is not working for all cases, so here's another solution if your server mods are not updating correctly. For the next steps it is assumed that: - pzserver is installed in ${HOME}/pzserver - steamcmd.sh is installed in ${HOME}/Steam Update the commands according to your setup # Stop pzserver type "quit" in pzserver console, press enter, and wait for pzserver to shutdown # Delete steamapps folder rm -rf ${HOME}/pzserver/steamapps/ # Update pzserver using SteamCMD ${HOME}/Steam/steamcmd.sh +force_install_dir "${HOME}/pzserver" +login anonymous +app_update 108600 +quit # start pzserver ${HOME}/pzserver/start-server.sh

I just realized the whole problem is because my file was named `items.txt`, which overrides the items.txt from vanilla. But still...

So, this one is a bit tough to explain, please bear with me. I discovered this issue (painfully) while I was working on one of my mods. I wanted to add a new item, so I simply created the file media/scripts/items.txt in my mod folder and added the following content: module Base { item GrassCuttings { DisplayCategory = Material, Weight = 0.1, Type = Normal, DisplayName = Grass Cuttings, Icon = GrassCuttings, WorldStaticModel = GrassCuttings, } } At that point, I had not created the Icon and the WorldStaticModel yet. In the meantime, I discovered my mod name was invalid in mod.info, due to a mistake in my previous release. So I switched to fixing that issue first, because it seemed important enough (the mod was still working, but it was hard to find in mod list due to the invalid name). I updated my mod.info, published a new release to Steam workshop, and went back to working on my new item. That's where the pain started... Unfortunately I wasn't careful enough and my new release included the new items.txt file mentioned before. In the next few hours, I received a multitude of messages on my workshop page about my mod being responsible for breaking saved games, for both single and multiplayer. In particular, my subscribers where complaining about the following issues: - The mod triggers errors when starting a new game - The mod breaks vanilla items (objects disappearing, not available, or not working when interacted with) - The mod breaks vanilla recipes (not possible to use some recipes) - The mod breaks ripping cloth (trigger a red square error when right-clicking any cloth item that prevents users from interacting with cloth) So of course at first I was a bit skeptical because I couldn't imagine how my mod could be responsible for all these problems, especially since it doesn't do anything related to items or recipes or ripping cloth. But then I couldn't deny the facts when I discovered in horror it was all true after I tried it myself. When I realized the issue was related to this new items.txt file, I simply deleted it from my repository and published a new release, fixing the problem for my subscribers. I can't deny I have my fair share of responsibility for this whole issue. I'm aware I've been sloppy and that I really f*cked up at multiple stages. But I also strongly believe a game (or any software in general) shouldn't fail in such dramatic ways for a simple mistake like the one I made, which is to unwillingly ship a mod with an incomplete item. The consequences are way too heavy to wear on my single shoulders alone. The game engine should have failsafes to prevent this kind of issues and just ignore the bogus items when it can't find the corresponding Icon or WorldStaticModel (and of course show an error message in console.txt for easier troubleshooting). Anything that comes from a mod should be checked before use and ignored in case it's not valid, with a proper message sent to console.txt I've included the following files: - broken-items.txt (errors about broken items) - broken-recipes.txt (errors about broken recipes) - errors-on-start-new-game.txt (errors on starting a new game) - error-when-right-clicking-a-cloth-item.txt (error on right-clicking a cloth item) Please don't let sloppy modders like me break your beautiful game! Implement more failsafes to prevent this kind of issues in the future! I'm available if you need more info, or anything really. Just reach out to me on your discord. broken-items.txt broken-recipes.txt errors-on-start-new-game.txt error-when-right-clicking-a-cloth-item.txt

It seems the mods installed on a pzserver are not being updated, even when the pzserver is restarted. The only workaround I found so far is to stop pzserver, delete the following file: steamapps/workshop/appworkshop_108600.acf And then start pzserver again. Would it be possible to make pzserver to update the mods on restart? Lot of users seem to have issues because of this, so it would probably help with support too. Also, bonus point if you can make it possible for an admin to trigger the mod update process from inside the game without restarting pzserver (I understand it might not be as simple as it sounds though).

41.60 release introduces new global Lua method `getGameVersionInfo`, but it seems the buildDate field is wrong? I'm getting this: 19.09.2021

About using git, if using the command line tool you can do something like this: git checkout-index -a -f --prefix=/destination/path/ The trailing slash is important or it won't work as expected. That would strip out the .git folder. You'd still get the .gitignore etc though. You could also do this: git archive --format zip --output /tmp/YourModRelease.zip main The "main" part is the branch you want to archive, could be different for you, like "master" maybe. Alternatively, on Github you can create tags and releases. This would create a downloadable archive which would also not contain your .git folder.

Great, congrats on finding the bug! Keep up the good work! Love the game

Oh, and the bug happens only when I quit current game, or start a new game, or load a saved game. It's never happened while I was playing. And when I said the game is freezing, it's a real freeze like I have to force kill the game to be able to use it again.

It is definitely not the case, the mod you see are mod I made myself, they don't put allocated objects in GlobalModData or do anything with ModData in general, even less in a for loop. As mentioned earlier, I had the same bug even before I knew the existence of mods (I started to play Zomboid around august of this year). And this console log is from yesterday. The bug also happens when I only start new games each time instead of loading saved games. You can find a zip of my mod folder attached to this post. One (zReload) is an empty mod with no code in there, I just use it to force reload the Lua from mod screen. The other, OffTheWindow, is a mod I started yesterday to allow players to throw zombie corpses out of windows. It's just using the event OnFillWorldObjectContextMenu to add a context menu entry when you click a window. mods.zip

Sure I will. That said, when I first started playing the game, even before I was aware I could download or make mods, I still had the same issue. So it's definitely not related to the mod you see in the log. Furthermore, after I posted this bug report, other people confirmed to me they had the same issue. Also, even assuming a bad mod allocating too many objects, the game engine should still free the memory when you quit the current game and start a new one .

When I start a game or load a saved game multiple times, without quitting to desktop, quitting the current game takes more and more time to perform each time, until the game becomes completely unresponsive. The problem is present on vanilla even without any mod loaded. The computer I'm using has 32GB of RAM and it's far from being full when the problem happens. I usually start to feel the lag after approximately 10 games loaded or started, and the freeze usually happen after I start or load a few more games. The error I get in console.txt is: Exception thrown java.lang.OutOfMemoryError: Java heap space at HeapByteBuffer.<init> Here's the stack trace when this is happening: LOG : General , 1637028655102> EXITDEBUG: Core.quit 1 LOG : General , 1637028655103> EXITDEBUG: Core.quit 2 LOG : General , 1637028655103> EXITDEBUG: onMenuItemMouseDownMainMenu 3 LOG : General , 1637028655103> EXITDEBUG: IngameState.updateInternal 1 LOG : General , 1637028655103> EXITDEBUG: IngameState.updateInternal 2 LOG : General , 1637028655305> reanimate: saved 0 zombies LOG : General , 1637028655311> Saving GlobalModData ERROR: General , 1637028658210> ExceptionLogger.logException> Exception thrown java.lang.OutOfMemoryError: Java heap space at HeapByteBuffer.<init>. ERROR: General , 1637028658211> DebugLogStream.printException> Stack trace: java.lang.OutOfMemoryError: Java heap space at java.base/java.nio.HeapByteBuffer.<init>(Unknown Source) at java.base/java.nio.ByteBuffer.allocate(Unknown Source) at zombie.world.moddata.GlobalModData.save(GlobalModData.java:252) at zombie.GameWindow.save(GameWindow.java:1281) at zombie.gameStates.IngameState.updateInternal(IngameState.java:1420) at zombie.gameStates.IngameState.update(IngameState.java:1356) at zombie.gameStates.GameStateMachine.update(GameStateMachine.java:101) at zombie.GameWindow.logic(GameWindow.java:285) at zombie.GameWindow$$Lambda$202/0x0000000800cfcc90.run(Unknown Source) at zombie.core.profiling.AbstractPerformanceProfileProbe.invokeAndMeasure(AbstractPerformanceProfileProbe.java:71) at zombie.GameWindow.frameStep(GameWindow.java:726) at zombie.GameWindow.run_ez(GameWindow.java:642) at zombie.GameWindow.mainThread(GameWindow.java:471) at zombie.GameWindow$$Lambda$77/0x0000000800ac5818.run(Unknown Source) at java.base/java.lang.Thread.run(Unknown Source) LOG : General , 1637028658211> EXITDEBUG: IngameState.updateInternal 3 LOG : General , 1637028658213> removing all player data LOG : General , 1637028658213> - player: 0 LOG : General , 1637028658213> removing player inventory LOG : General , 1637028658214> removing buttonprompts LOG : General , 1637028658214> removing loot inventory console.txt.zip

When an IsoWindow is oriented either East or South, the property Facing of the window indicates a wrong value, respectively West and North. For example, given an IsoWindow that is oriented East, the following code would print W in the console instead of E: print(isoWindow:getProperties():Val("Facing")) When the IsoWindow objects are oriented either North or West, then we get the proper values, respectively N and W Here's the code I'm using to print the values in the console: function onFillWorldObjectContextMenu(player, context, worldobjects, test) for _, object in ipairs(worldobjects) do if instanceof(object, 'IsoWindow') then local orientation = object:getProperties():Val('Facing') print('DEBUG: Window facing ' .. orientation) end end end Events.OnFillWorldObjectContextMenu.Add(onFillWorldObjectContextMenu) Note: I had to crop the screenshots to fit the 4MB upload limit, but I can provide the full version if needed, just ask.