EnigmaGrey

Fellow, you popped up, lectured us on programming and game design, and yet you've been unable to find a way to do any of this yourself in a few weeks now? You're a programmer or someone with programming experience. This shouldn't be a problem. You're not going to get anywhere being so dependent and I'm not your Mom. Java -is not remotely- hard to decompile, repair, and rebuild even back when it was just AndroChef ( that program produced terribly broken code; that's how I got started modding PZ. Really, why are you trying to tell me the basics of what I learned the hard way and just worked through myself a decade ago? Get on with it. You can do this. ) let alone now that you can do it in an IDE, 13 years later. Google how to do thIngs. If you get stuck, identify your weaknesses and fix them before asking others to do it for you or trying to argue. Seek out others who are actually interested in this sort of thing -- I'm not it. I'm out.

:/ The lua scripting is largely self documenting, the game is in an easily decompiliable and recompiliable language; the modding sections have links to guides; the wiki contains yet more guides and links to the javadoc; the Discord has an extremely active modding channel. You have everything you need. I have already told you I'm not comfortable helping with this. Please respect that.

Unless you activate every single chunk in the game by being present near each one, this is unknowable. Can't count what doesn't exist. You'd have initialize the entire map: teleport through all the points of a grid made up of 20x20 tiles, wait until all chunks fully initialize around you and only then jump again, throughout the entire ingame world. It'll take a very long time, generate hundreds of thousands of files, and use a few gb of disc space. It's doable, but it's not practical. (I've done this before to generate the entire map for servers so that we didn't have to force users to download the map packs. it's worth it in this scenario if you have a couple gigabytes of maps.) otherwise you're left with just guessing based on the existing pop in each cell in debug, as suggested above. But it's likely to be wildly inaccurate.

Sometimes "a massive improvement" just has to be good enough. There's no need to overdo it, imo -- but you never know what might come up in the future.

We've always recommended creating private servers instead of public servers -- they are by far what most of our users use. It's the easiest way to prevent cheating. It's quite unlikely we'll ever truly be able to lock down the game entirely short of using something like Goldeneye or doing a total rewrite (like minecraft bedrock edition). We can only do the best we can with what we have, otherwise. Some of this will likely improve with build 42 though I can't speculate on this specific issue -- I believe it might be the first time it's been reported. We'll take a look.

Almost none of this fits Project Zomboid. :/ 50/50 fences? Sure, maybe. Zombies already differ in physical state. We are not going to L4D it. Discount the human characteristics from Romero zombies and focus on Brook's stuff to get a better idea of why we've landed on what we did.

*shrugs* To be blunt: We fundamentally disagree on game design and what PZ should be. So your only alternative is mods. Edit: just to be sure, I do agree with you in principal. Project Zomboid has certain design choices that does not make it a good game in a traditional sense. That's one of the things that likely most frustrates players who find themselves on the fence. The trouble is ... a lot of things that work in other genres don't work in a "realistic" survival game when combined with an open world sandbox and PZ's setting. Events have to happen more organically (and unfortunately sometimes it means not at all); progression and survival become risk aversion and hoarding; death is one wrong move away; the mechanics are mostly nondeterministic (but have just enough wiggle room that you can still master them if you pay attention and experiment); tedium, when done right, even feeds into the feeling that this is "real" and discourages some bad behaviours (see mods that remove weight limits eventually bricking saves because people collect so much when there's no impediment); and, worst of all -- the game either ends in your death or your player bored out of their gourd in purgatory -- how very existential and uncomfortable. It's a very strange tightrope to walk versus the usual thing you would do when making a game. And it's simply not done yet; that as more content gets into the game, I feel many of these problems are going to slowly fall away, albeit in unexpected ways. But, it won't work for everyone. :/ I appreciate the enthusiasm. Please don't let me discourage you -- there's lots to work with, it's just a lil ' bit niche. :p

Gotta disagree about most of this. Mods more often fill niches we're not interested in exploring, in ways that we feel would not be fitting with the game; Mods often scratch that power-fantasy itch that some expect from their games; mods often turn something more organic ( and yes, playing it safe is the natural outcome of that in this setting ) into something more gamey if that's what players want. This may sound judgmental, but it's all good to me -- the whole point of supporting mods is to let you do your own thing (up until it impinges development) while we do ours, after all. It's just that people as a group also do not agree on everything and don't seem to have a grasp on what they actually like. They often ruin the fun for themselves because of this. We can't make millions happy - sometimes we can't even make ourselves happy because working in a team is always going to be some of compromise, even while pursuing a specific vision. PZ can't be all things to all people short of recreating the universe atom by atom: you see needless grind, other people see 400 hours of gameplay inexplicably chasing those skills (when they could just change the XP modifier). I'm personally bewildered by this and we'll likely change the skill system to what we feel are it main detractors, but you do you. Same thing for combat. Some people do not seem to want to put in the time to plan ahead (anticipate momentum, know when they pushed too far for the underlying mechanics) or learn how it works (trial and error; change behaviour; die a lot) -- so be it, there's a mod for that. Some people do not like randomness in games at all -- so be it, someone will probably mod it out one day. But ... we're not going to take on things we feel would hurt the game or slow/distract development just because server owners are way too liberal with mod selection. :/ We respect your right choose, to customize the game. Just remember that our goals might not match your taste (same for individual servers). In practical terms? just got to get out of your own head and have some fun. That's all that matters (so long as you're not hurting other people). Don't worry about ruining the vanilla experience for yourself. Mod it, tweak it, or don't touch anything and embrace the suck. Don't overthink it, unless that's fun in itself, ofc. :p

IsoThumpables are objects that can be thumped; it's inherited by IsoObjects which may be things like IsoDoor -- but every IsoDoor is ultimately an IsoThumpable. It's not that convoluted. You're looking at byte flags for loading isoThumpables from a save file. *Shrugs* I don't see how replacing a couple if statements with a full on trait system would make a difference in loading files that are so tiny. It's premature to blame your problems on load speed, frankly. OOP is often needlessly complex/verbose to the point it's difficult to conceptualize and expand upon. It's increasingly fallen out of favour for game development, giving way to entity-component systems. It's really what we should have done back in the day. Regardless, there'll be a lot of jank that developed out of necessity or while transitioning from C# to Java from back in the day. Welcome to the infinitely interleaving alpha-beta-release-maintenance cycle that is Agile.

Yes, distance is a factor. But remember that 3D game engines have been built to handle this via decreases in detail or even basic fog to optimize it. We don't benefit from any of that/have to roll our own stuff because the game is 2D and isometric. Everything is drawn to a larger-than-the-screen texture (twice the size to facilitate zoom but this amounts to like .. a 5 tile border). That's how things like holding ctrl and dragging the mouse to the side of the screen work. This is also why 4K is such a boondoggle because now you're working with an 8-12K texture instead of "4k." That's a lot of pixels to push for any GPU on top of waiting for a theoretical 50 x 50 x 8 tiles and everything else on the pile (overlays, fov, lighting, objects, moving objects .etc) to be sorted. This shouldn't matter in b42. You can optimize this to a limited extent to gain a bit of performance (maybe draw the tiles in a circle so that there's 1/16-1/8th as many) but it's not really worth it. (Or you reduce the size of that texture and just let people deal with the black borders if they move too quickly or zoom out. That's a no-go.) In AoE, buildings were simple 2D sprites, weren't they (a composite of a base image and a depth image to fake 3D effects?)? I can't imagine it was costly at all (especially given the lack of variety). Older games tend to use tricks like this or baking everything into the ground plane (like C&C, Baldur's Gate), whereas we have separate Z levels (think the early 90s X-COM. In fact, X-Com Apocalypse is probably a good analog for the challenges that PZ faces in its current, public form). Most 2D isometric games don't do this even today. Rhino: If you have the option to use JDK 17 or above and can use the ZGC pauseless garbage collector then I'd do it. But if Rhino requires reflection to facilitate scripting, you're going to have a similar bad time to us with Khalua2. You need to avoid small allocations in Java to avoid it bogging down. Things like foreach can have unexpected costs. Profile constantly. I don't see the point in dick measuring languages -- you can bog down anything or blow your foot off. Use a third party lib for datetime if it affects you (Apache always has good libs)? I mean, my heart belongs to straight C89, but all that matters is you get your work done with what you have. Graphical rendering isn't really done in Java. LWJGL provides bindings for GLFW which provides a wrapper for various DLLs on the system of your choice, such as OpenGL.DLL or Wing.dll. It's no big deal beyond the theoretical overhead of JNI. C++ has the same problem with third party libs being crud. That's just universal to C and C++. Honestly it's why I rarely use either anymore. People tend to resist writing self-documenting code and the preprocoessor + pointers seem to really encourage this, imo. Not a bad thing, but it means you can start a project with a really nice library, hit a wall, go check the source and just have a complete "wtf" moment. With languages like Java or C#, it's usually clearer what the intent was. We'd spend years jamming PZ into an engine that was never built to handle something like PZ. It's custom or bust, really. The only change i"d personally like here is using a proper C build of Lua instead of a Java implementation, as "it'd at least help" with performance. Note that Khalua2 requires reflection, which means an utter crap ton of trash, which means bogging down the rest of the game for the sake of mods / GUI. It's a fair trade, but it's just another hole to fill. (Note this is why we have FPS settings for the GUI in options and cap it at 30 FPS -- or every second frame). I'm not going to touch on duplicating the game, sorry. I'm not comfortable with that.

Sorting in terms of occlusion; the frustum of s 3D fps/3rd person over shoulder will contain far fewer things than an overhead camera giving 360 degrees of vision. AoE capped max units for the entire map. It was a very small number compared to PZ; we'd exceed the cap pretty much immediately on spawn if we were to do that. Red Alert 2 letting its fps chug if too many units were present wasn't a great approach. I just don't get the point of this -- yeah, its cool (I lived through it :p), but we can't roll back the clock and write the game like it's 1999 anymore (though the first versions probably count as they could be run on hardware from 2001 or so. It wasn't until 2018 that PZ required shaders. If Intel GMAs weren't so common, we probably would've advanced a lot faster -- but it couldn't handle the drawing the 3D models with em). Similar thing for Jedi: Academy, but we made a very generalized game spanning 3 platforms simultaneously in Java, not one custom built and optimized for specific hardware, as it's ports likely were. Rewriting the game in C and assembler isn't an option for us. Neither is greatly scaling it down, unfortunately. Iirc, caching is already done for PZ's pathfinding, as is reducing individual zombies into large hordes when unloaded to reduce costs. Modified A* to handle the possibility of 4 walls on a single tile? But again, not my job to know the intricate details of it. Same deal for whatever rendering algorithm is used. You're always welcome to poke around with IntelliJ IDEA's decompiler if you want. It'll probably provide clearer answers.

This is because these objects are composed of multiple tiles and each tile has different lighting. It's not a bug; unsightly, yes, but just an intentional part of the way the game is built. It may change in the future.

A city has tens of thousands of tiles instead of hundreds; thousands of isoobjects (like interior decoration and objects) and up to eight layers to sort through. Trees and grass on one level are much simpler. Think of it like unpacking a Pickup. You have 36 boxes. The only thing you can change is how fast you move them, not how many you move at each time. (The forest.) Now you try to unload a box truck. You have 180 boxes to move. Now imagine that box truck might be 8 trucks high and has half a dozen boxes nested inside each box that need to be sorted first. (A city.) What's going to happen? The job's the same -- move a box. But it takes much longer to complete because there's so many. You can only move them one at a time -- faster when fitter, but still only one at a time. Lot of programming boils down to this sort of thing -- how long it takes to interact with and sort a group of things; and unfortunately you do eventually hit a wall where you just can't go faster without significant consequences (if at all). ( That's also why having an arbitrary goal like using "100%" of your gpu or cpu is meaningless in practice, because sometimes things can only happen one way to get your end result.) (also you have to do it in reverse because the game is 2d and isometric, hence issues with occlusion.) b42 is in theory the fix -- take the cpu out of the equation so it can do other things (depth buffer on the gpu); reduce the number of boxes to sort by putting them all in one big box, etc. But there are trade offs to this -- we can't use that depth buffer for other things anymore, it'll need more ram, or the game will have to reprocess that megabox if something changes. btw, I'm self taught and have only a cursory knowledge of this stuff myself, picking up what I could while I worked here for the past 12 years and I am not the people that wrote it -- tested the results and pointed out things, though. So I'm not going to write an exam on it, frankly. No idea why you'd see the same results on significantly different hardware -- I certainly don't. Iirc in testing, hiding the interiors was simply the difference between 60 fps and 40 fps driving through West Point, on a middling system, so we did it. Easy trade, since most people never noticed. (3D fpses have far less to sort compared to 2d isometric games. Dramatically less. Old isometric games tended to be much simpler and cheat an awful lot to pull it off -- see how many floors you can build in the sims for example. GTA is also full 3D, so isn't applicable.) (and you're not wrong -- zombies are a significant cost themselves. Nothing is free.) (CPU sorts the tiles then passes the list to the gpu; the cpu isn't drawing the tiles unless you're using some sort of software renderer to make up for missing features in your gpu.) (Cores don't matter -- not everything can be multithreaded. You'll be limited by how fast the main thread or the rendering thread runs which will ideally be on different cores, but thats up to your os. And note GHz is fairly meaningless these days; generally cpu manufacturers use other tricks to get more operations per cycle, so you can't compare a 2.4 ghz system from 2024 to 2011 on ghz alone.)

It really is just a cpu issue, as Krazmuze states. More individual items, more sprites to sort, longer it takes to process the list. Single-core performance of the CPU determines how fast that happens. There's not much else to it and we'll see what 42 brings to the table regarding this, as the point is to cache 8x8 groups instead of single tiles, as I understand it. You really shouldn't be seeing any issues with streaming data from your hdd. Any spinning rust after 2015 should be "ok;" any SSD shouldn't even flinch. But it depends just how much is going on in that chunk -- how big it is (individual items and carpentry can push em from 28 kb - 1 mb to 40 mb before the buffer gets overwhelmed, iirc) or what mods use LoadGridSquare.

"bueldia foret-aye." Huh, must be Italian.

Just note that the windows reliability report indicates hardware failure rather than a software issue -- and most of these crashes seem to involve textures. If you're having crashes in other games or programs, something like bad ram, a bad pcie lane, or gpu seems likely. (Power and driver issues can cause similar errors -- it's hard to diagnose.) Even if not, there's not much else we can do beyond point this out. :/ Went through this recently with a 3080. Took me months to accept it was the card, not something else, cause it was sporadic and only affected one game at first. It happens.

Steam is having difficulties right now. There's nothing anyone can do but wait for them to resolve whatever issues are affecting their network.

Unfortunately, I don't have any other suggestions. But if we ever find something, I've got this thread bookmarked.

Sometimes it's down to custom cursors, desktop replacement programs, using the trails option for your mouse pointer, or windows getting a little confused when hdr is enabled ( windows key + alt + b will manually turn it off, then press the combo again to turn it back on, often restoring the missing cursor for me). it makes it really hard to know what really is happening beyond something is going wrong at the OS level with the way it draws the mouse pointer.

Tbh, it could be a lot of things. It's hard to guess without a video of your issue. In general ... it could any of the following: - Mods (including those that claim to fix things) - A server running out of RAM - A server becoming overwhelmed for some reason - An admin teasing someone with admin abilities, such as spawning zombies - Desync between two nearby players and/or lag (wireless connections are especially prone to this) - If it only happens after a restart, then most likely it'd be from the server host (or hosting service) shutting down the sever improperly, without calling save and quit, causing file corruption - If zombies are set very high, this can also put additional strain on the server and cause culling to happen far more often; things can get weird If it's very rare, it'll be even harder to guess.

Am I mistaken, or is there a rifle/pistol shot at the exact same time as they spawn? Makes me feel like there's some sort of intentionality there? Like an event or something that's designed to let you know it's happening. What mods are you using? Some of those twitch integration mods do purposely allow viewers to screw with you, right? assuming what you're showing in the video is identical.

Turn off mod. If there's no problem anymore (ideally start a new game to verify this), then it's the mod.

Yes, it's the right email address. If you haven't in a while, you might want to give Stan another listen. Kinda makes me a teensy bit worried to send someone into the spambox to look.

I mean, you're welcome to use your imagination to fill in any gaps that you'd like? But just wanting something simply isn't enough to justify doing it. As is, we're going to have enough problems with large fields of crops or tons of items on the ground, without having to update the temperature of everything in existence regularly. It's just a bad move. If this were the Long Dark, maybe it'd make more sense? But it's not like we're hurting for food, here.