EnigmaGrey
-
Posts
13928 -
Joined
Posts posted by EnigmaGrey
-
-
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.
-
On 4/22/2024 at 1:19 AM, SilentLight said:
I think perhaps my views seemed more critical than intended (it sort follows on from the context of the vanilla server discussion earlier).
So earlier in that original discussion, I mentioned I didn't mind other players using mods, I however feel some mods are compensating for unintended gameplay mechanics. I "embrace the suck", as you say, because for me, I'm approaching this game from a beta-test angle.
In gameplay design, there's a view towards protecting a player 'from themselves'. For example, players in video games will often hoard and not use health items, fearing some upcoming boss battle. What ends up happening is not only do they not use the items during the course of the game (which is what they're supposed to be for), they also don't use it during the boss battle. The end result is the player engages in hoarding and micro-management of the inventory in what should be a fast-paced game. Half-life 2 solved this by making medkits instant use. Other games solve this by making stationary healing areas, or by limiting the health item slot to one, encouraging the player to use up spares. Some games lean into the hoarding factor and encourage it, by making it more pleasant by removing inventory micro-management (for example, Link in BotW can hold basically an infinite number of meals. Don't ask where he stores it all).
It strikes me currently that players are so singly afraid of that one-bite-run-ender (especially if one has been squirrelling away a lot of resources), they either play extremely safe, in a way that's arguably not fun and defeats the point of having zombies (go to a remote enough wood area and you're basically in sandbox Minecraft), or upon the tiniest unfair mistake - and they do happen - they fire up debug mode and remove the infection via god mode. The other way being, they invent a mod that mitigates that risk; cures, super-thick body armour, a crap ton of guns.
Essentially it strikes me the players are trying to avoid the key feature of Zomboid, which are the zombies. What you end up with is a sort of... remote wood hoarding simulator. Which suggests to me the gameplay mechanics need an adjustment. I've not yet sussed what the adjustment needs to be as I'm testing the 'hide in a remote house' strategy.
For me, I had the most fun when I was periodically sneaking from house to house, staying for a period of time in each one, trying to conservatively use canned supplies, whilst killing zombies in backgardens, as I didn't have to worry about trying to ferry goods everywhere. At one point, I thought the zombies stopped pursuing you the moment you went indoors. It's not how they actually behave, but I found the idea of zombies losing interest if you go indoors interesting because it invites a stealthy strategy.
I'm having the 'least' fun with the remote house setup. It's safe, but it is... also boring. However, the game hard punishes any exciting playstyles. I tried a run where I was aggressive with a dedicated strength build, and despite capping 100+ zombies (pure melee), it was over by day 3 because of an errant bite. Essentially, the more zombie engagements you have, the higher the probability of a bite, so the game encourages zero zombie engagements.
I suspect this might be because killing zombies themselves does not carry any direct rewards (besides maybe better clothing and a bag). I think zombies ought to be carrying food supplies more frequently, as well as maybe other types of more frequent rewards. That way, the risk has a reward as trade-off.
I also tried the hobo foraging approach, which sort-of works but because foraging does not find food regularly enough, and most of that foraged food goes stale very quickly (sometimes, such as mushrooms, even immediately!), you end up still setting up a collection point, which then turns into a remote wood base.
I'm not sure what the 'right' style of play is, or what the gameplay mechanics should be tweaked to... but I'm not a fan of OCD hoarding where I spend all day inventory sorting, and I'm also not a fan of suicide missions. Still, I think mods are trying to patch the symptoms, and not the cause.*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
- Hugo Qwerty and hellol
-
2
-
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
- Hugo Qwerty, puppers, SilentLight and 2 others
-
5
-
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.
- SilentLight and Hugo Qwerty
-
2
-
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.
- SilentLight and Milove
-
2
-
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.
- Laytep and Hugo Qwerty
-
2
-
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.)
- SilentLight and Milove
-
2
-
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.
-
17 hours ago, Selvamoon said:
"My girlfriend's pregnant too, I'm 'bout to be a father. If I have a daughter, guess what I'ma call her? I'ma name her Build 43."
"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.
-
-
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. -
8 minutes ago, Unctuous Robot said:
Hey we should all be careful, I heard that TIS deletes forum posts containing objective criticism from the community. Especially you EnigmaGrey, EngimaGrey might banish you to the depths of Daikatana like they did to the guy who made this thread.
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.
-
49 minutes ago, Farrold said:
When I saw this thread, I was hoping you guys from the dev team would be able to shed some light on why this *could* be happening and help us out to solve it, since it happens to more people...
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.
When do you think you will run out of players?
in PZ Support
Posted
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.