EnigmaGrey

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.

Understandable, but I'm at a loss as to what. The last update to the game would have been in December 2022, so if it only started misbehaving in December 2023, it's probably something that changed on your computer. What though, is very hard to know. For example, is the additional 4 GB of Samsung(or kingston ram) new? If it's mismatched, that could affect performance to some extent. If not, maybe it's getting hotter than it used to and just needs a dusting or new thermal paste? Perhaps the latest Intel driver is just bugged; maybe reverting to an older one will help (though I'd be cautious here -- normally these CPUs won't run the game at all). Just throwing some ideas out there, though.

You're going to have a very hard playing the game with that system, I'm sorry to say. HD Graphics never played well with the game, to the point that we removed integrated graphics from our minimum requirements at all. But, generally the cuttoff is HD 3000/4000; on yours, I'm sorry to say, it shouldn't be able to run at all. This likely means it's doing almost everything with software rendering; that's very slow. The way Intel integrated graphics works on Windows involves doubling the amount of RAM the game needs for its textures; so you'll be losing at least 2-4 GB of system RAM to just that. In addition, the Intel GPU has been given 2.5 GB of "dedicated" system RAM. The game then uses 2-3 GB for its heap. Windows 10 will also use at least 1 GB (more likely 2). You can see why you'd run out quickly? All I can really recommend is dual booting Linux or drastically cutting down any performance related settings in-game. If your friend has a dedicated GPU with around 1-2 GB of RAM, it'd make all the difference, despite it being an older system. Something like a Radeon 5760 from 2010, for example, should be able to run the game (at least on Windows Vista, maybe 8).

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.

No update to give: We don't host servers, individual users do. Steam provides matchmaking services and a means to make connections; any problems on their end will result in players not being able to connect to (Steam-enabled) servers.

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.

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.