EnigmaGrey

TL;DR: It's generally best to start fresh when adding maps to the game. They should be added before you run the server for the first time. (This is E from my initial list, btw.) I can confirm Lake Ivy works perfectly fine if only you add it to the server config before starting a new server. I don't totally understand why you did it the way you did, but at least the video allowed us to reach a conclusion instead of fumble around more. The long version: Against my better judgement, I took another look: A) You're not actually doing a clean install. You can't trust that the reinstall feature provided by a web interface is clearing the game's installs and save files correctly. (This probably doesn't matter, but it can be the source of many unexplainable issues. [And no, verifying files in Steam isn't enough. It'll often leave stuff behind or ignore small changes.]) B) You're modifying the server config after starting the server for the first time and while the server is still running. If you had checked the save files after shutting it down, you'll see map_zones was generated on save / quit. This means you're now stuck with Muldraugh, KY's zones, it seems. C) There's an error on restart relating to a bad path for the zomboid/mods directory. (It probably doesn't matter, but it's weird.) D) You didn't have to create a character or select a spawn point, so we know the server-side data for your character and map was never actually cleared. That's weird? E) The colors in debug don't correspond to zone type. They're the boundaries for the isobuilding generated by the map tool. They have nothing to do with zones. F) If you had looked at the zones in debug at this point, you'd have known that the ammunition store in Ivy Lake never showed up as TownZone. It's a deep forest. G) You deleted the server save without restarting the server, it looks like? (Or that was cut out of the video.) So there's no chance the map_zones.bin will contain Lake Ivytown's zones H) Adding a mod that "fixes foraging zones" isn't going to make any of this easier. Why are you doing this ... Let the ForagingZ mod thing go rather than complicate this. It's already broken ... more mods aren't going to make it suddenly work more better ... So, in short. It's generally best to start fresh when adding maps to the game. They should be added before you run the server for the first time. (This is E) from my initial list, btw.) I can confirm Lake Ivy works perfectly fine if only you add it to the server config before starting a new server. I don't totally understand why you did it the way you did, but at least the video allowed us to reach a conclusion instead of fumble around more. Now as to why I originally assumed it might be a problem with Lake Ivy that and ForageZ? It seemed like you were simply refusing to research it. Lake Ivy's author expressly states that only downtown area contains a (small) townzone. So, respawn isn't going to work in many homes and outlying areas on that map. Then you insisted on using a mod that alters zones in some way (likely adding a crap-ton of DeepForest zones and possibly conflicting with Lake Ivy). It also has -very specific- instructions in how it should be added to the server. Then all the questions about it that frankly don't appear to have any relevance to the matter and make assumptions about non-existent problems really confused things. And that's not even getting into how you treated me in this thread. I don't appreciate it and no "with all due respects" and "but I love the game!"s makes up for that sort of behaviour. It's not conductive to getting help or answers, frankly.

Oh so banned.

As I said, I cannot offer support for specific mods. You’ll have to contact the mod author. I would highly recommend that you read the descriptions and comments of the mods you have chosen to install (both ivy town and foraging Z) to understand what is happening. I suggested everyone (anyone) using mods do this earlier, but you both have told me that that is too basic/dismissive to be helpful now. So I am going to bow out of this conversation. Have a good day.

I tried. Then you accused me of being disingenuous. And on a weekend, to boot. Unlike Jaxcze, you've given me nothing to go on, so I'd suggest making your own thread with detailed information about your issue instead of participating in this thread further. I get being frustrated about a problem and not getting the answer you want, but that's really demotivating, lol.

I'm unsure what you want me to say here, as I can't reproduce the issue on a clean install of the game. For me, it works. If you can figure out what might break it and a means to reproduce it, then I'll happily look further. Though I think it's safe to say that "swapping mods like crazy" isn't going to be the thing that does it.

There's nothing special about loot respawn. After X time passes, the game calls RollContainer again. Lua doesn't control this. I can't really help with mod support. I'd recommend following up with whomever wrote ForagingZ. Just in case: # List Workshop Mod IDs for the server to download. Each must be separated by a semicolon. Example: WorkshopItems=514427485;513111049 WorkshopItems=2252982049 # Enter the mod loading ID here. It can be found in \Steam\steamapps\workshop\modID\mods\modName\info.txt Mods=lakeivytownship # Enter the foldername of the mod found in \Steam\steamapps\workshop\modID\mods\modName\media\maps\ Map=li_township;Muldraugh, KY # After X hours, all containers in the world will respawn loot. To spawn loot a container must have been looted at least once. Loot respawn is not impacted by visibility or subsequent looting.\nMinimum=0 Maximum=2147483647 Default=0 HoursForLootRespawn=1 That's all it should take. Looks like it's also working at the ammunition store for me. Edit: Just to confirm, @jaxcze: are you deleting the server-side save data, as well? The client-side stuff really shouldn't matter as it'll get pulled from the server. You'll want to clear out the /saves/multiplayer/YourServerNameHere folder on the server, not just the client data. Apologizes in advance if I read that wrong.

Seems to be working fine in both MP and SP, so long as there's a valid townzone at that part of Lake Ivy Township. I don't think it's an issue of overlapping zones between the two maps? Just ignore the respawn options in sandbox settings; use the ones in server settings instead. It's confusing, I know, but the servertest.ini is where you want to make these changes, not sandbox_vars. Otherwise, it could be a lot of things: A) There's lots of lake ivy maps; maybe you're using an out of date one B) Lots of mod packs include mods with identical loading IDs, causing several to be loaded at once, and conflict C) Maybe that area of the map really is poorly zoned; in which case there's nothing really to do beyond give the modder a heads up D) Bad config (max items per container; construction prevents loot respawn; mixing up sandbox and server settings (understandably; the duplicates are fixed in b42, iirc) E) Removed a map without resetting the existing world; the old map_x_y.bins will still contain the old map data, just without the zones and some other meta data; clear your local saves and the server saves when changing map mods, just to be safe. (You don't have to, but if the new or removed map mod overwrites an area you've already explored, nothing's going to change without purging the old files on the server.) F) The server is improperly configured by the host and does not do the following when shutting down: calls save, waits for save to complete, then quits the server. Instead it 360 no-scopes the process, causing data loss. This is highly likely for VPSes and server managers that manage shutdown for you. G) Desync? Somehow? I don't think that's very likely given the above posts H) Not looting the container of its items initially? If it still doesn't seem to respawn, try walking far away from the chunk then returning after a few hours. In general (more for people reading this than yourself, OP, as I see you reduced the complexity of the problem in your latest post): KISS works best for this sort of thing. Verify vanilla works; add one mod; see if it breaks. If it doesn't, change one option and restart the server or reset the map entirely and see if it works. Repeat until you know if it's the mod or vanilla or not. Don't throw hundreds of mods on as sever and expect to sort it out later. Don't just install mods, research them first. Don't customize things first; see if they work first.

Think of it like this: Mac was always a very small portion of the player base (maybe half a percentage?). Apple then split that small fraction into an even smaller number, between arm and intel. For many companies, Mac support wasn’t profitable enough to support dedicated devs, but releasing a x86 build didn’t require much additional work to pull off (depending on how the game was built, anyway), so why not do it. But the changes requited to get a native ARM build are fairly involved and require all third party libs we use to also support arm. Same thing for Metal vs OpenGL, albeit on top of the switch to ARM. That’s partially why Rosetta “just working” was such a boon to game developers, otherwise there’d be only a few hundred m1 native titles right now (ignoring Apple Arcade). For example, this list has 1440 games that will work to some extent on m1, but only 288 are native. The rest rely on emulation. It’ll likely be a very long time before everyone else catches up, assuming arm is the future. But, for now, Mac has been surpassed by Linux for gaming, and seems to continue to decline. Basically it’s the 90s in reverse: apple moved on from Power PC to x86, allowing for a huge number of games to be ported over “easily” but by extension wiped out the native powerpc games. (Emulation was very primitive back then, however.) https://www.applegamingwiki.com/wiki/M1_perfect_games_list

Unfortunately, the future on M1 is not especially bright for Project Zomboid. Initially, we were quite excited to see that the game played well despite being virtualized (Rosetta), but subsequent updates on Apple’s side introduced a stutter when moving that we never could figure out.* Worse, Apple could pull OpenGL support at any time, as it was deprecated in 2016, and we don’t realistically have enough Mac users nor devs with Mac experience to do a complete rewrite in Metal, Apple’s replacement for OpenGL. I’m not saying that support for m1 can’t happen in the future, but we can’t make any promises. If the uncertainty is a concern and you’re past the cutoff for Steam’s automated refund system, you can still manually submit a support ticket to Steam. Just explain why and link this thread in the ticket. if you would rather not refund the game, a workaround might be using Mesa drivers on Mac (but you might have to compile it yourself). Another option is to dual boot linux, assuming the distro includes Mesa’s m1 driver, Ashai. Parallels (vm software on Mac, as Faalagoon mentioned above) might also work, but last time I tested it, I had quite a few errors related to openGL and it performed poorly. If parallels gets hardware acceleration, it might perform better. * for the stuttering, you could try turning off or lowering advanced settings like reflections/dynamic skybox in the game’s Options menu. They’re near the bottom.

Trees block vision. Shoving a zombie onto/behind a tree therefore blocks your ability to see it.

That’s right. LuteBoxes, macrotransfers, deal-c, sisään passé, expulsions. Jack up the price to $120 as befitting “early access.” Gotta catch em all.

To say the least, we’re not going to get into copyright and trademark issues or licensing agreements with gun manufacturers. more guns will likely be added when we do update the system, but don’t expect true to reallife branding.

Note that the hallway has windows and glass doors at its entrance, even if it’s not necessarily realistic that light would make it around the 90 degree corner and to the end of the hall. You can see how much darker it is in the starting room, so I don’t really get why the empty hallway is the focus. Either way, toning down the color filter will result in a darker hallway as there’d less luminescence over all.

As I understand it, it’s not possible. To get higher performance, we’ve moved from crawling individual tiles to having one large image stitched together. To get an effect like the old builds would require regenerating that larger image any time the player’s view changes, negating the performance increase. PZ, as its grown, has kind-of ended up as a case study for why the older 2D approaches died off at the turn of the millennium. They just don’t play well with modern 3-D graphics cards, and it gets worse the more complex the world gets.. Tinting options should be doable.

Turning the map into a Garmin because you find a compass is just taking it too far. We’re fine with it being s trinket. At best, all it can reasonably be is a reminder for where north is for those new to isometric games. (Or for dead reckoning w a map that has coordinates … but you can largely do that already because your screen is a compass.)

Compasses aren’t gps units. They just give bearing — in our case, the screen does this for you. I don’t think we need to make it even easier to navigate. The ingame map is already generous enough.

edit: missed the post about rabbit stew. Makes a lot more sense as to why this would be a problem. I’ll leave the following up however in case it’s at all helpful and double check. ? What I think you’ve explained previously is … Level 7 cooking. Can of fresh corned beef starts at 720. It rots. Great. Now it’s 720 * 0.0386 … Whole 27 cal left that I can salvage thanks to the cooking skill. I split it into portions for some reason. Now it’s 9 cal. I gain 30% cal because of my cooking skill. Great. Now it’s 12.05 cal. Or 11.45. Or something close enough, because internally these numbers could be something like 0.3860000073909759521484375 due to the nature of floats. 0.3, 0.24, and 0.77 within the calc introduce further errors, compounding for a swing (in either direction) of around 1 cal. I assume that’s what you’re talking about as otherwise I don’t know how you could get to the point where you only have 11 cal left over. In this case, you’re not losing 710 cal. You never had it in this scenario because the food rotted. (Mind is without testing it in game. Will double check later.)

Is it wild? Unless I’m misreading this, we have a loss of ~1 calorie after taking some numbers that a computer can’t accurately store as a float (like 0.1 or 0.3), doing things with them while cutting off or adding trailing digits, then displaying a further approximation of the result. It’s expected behaviour; sacrificing some accuracy for speed and the amount of space taken up in memory. This is a tradeoff that’s acceptable in games but not at a bank. You can read more about it here: https://en.m.wikipedia.org/wiki/Floating-point_arithmetic https://docs.python.org/3/tutorial/floatingpoint.html

It’s just going to be a rounding between different number types and the division thereof or loss of precision when transitioning between Java and Lua. You can’t expect high precision with this sort of thing.

Point stands. It doesn’t have any use or utility due to the fixed camera.

Nothing in the included screenshot is being done by the game server. We can’t really help with docker images. We don’t create them, maintain them, or use them. Normally, these files are created on first launch. I assume the docker includes its own version so you can configure the server before launching it the first time, but this is not how the game usually works.

If you’re using a Magic Keyboard, hold fn down then press f11.

Outline is just distance. It doesn’t indicate timing and doesn’t predict success. Not a bug.

Yeah, the first two clips make it look like it doesn't target the leading zombie if the spear's target falls onto the head of the nearest zombie. Not sure what's going on there or if it's a case of debug misleading us all. Either way, it feels wrong. In the third one, I think it's because you were turning from one zombie to another and started the shove too late / while trying to turn into the hit? What makes it hard to interpret these things after the fact is that the overlay isn't predictive in any way; it doesn't give cues to timing (purely distance) and I suspect in this scenario you probably have to swing a little earlier than you are (making up for the time to react and commit to the swing), as I think you're only reacting to it turning green and by then the zombie has gotten closer. Unless I'm mistaken, you also don't have multihit on, which makes fighting multiple zombies this way a very bad idea. I would suggest always kiting in these scenarios, especially with the spear and multiple zombies.

If you download the latest version of lwjgl and it’s components, you can replace the game’s jars and dylibs with its contents. It at least works as a drop-in replacement on Windows. I can’t say if that will work for yours, specific issue, but hopefully it’ll I’ll get you started.