Jump to content

Modin

Member
  • Posts

    89
  • Joined

  • Last visited

Everything posted by Modin

  1. Thanks for the reply, Beard! After playing more, observing more and thinking more about it, I've come to the conclusion that it's most likely something to do with the time of day. The issues are the worst during peak hours for the server's location, while they are much much lessened during off peak hours. E.g joining the server is extremely slow (5 minutes) during peak hours, extremely fast (10-20 seconds!) during off-peak. I think the most likely explanation is that the server resides on shared server space and its resources are strained during peak hours where there is the most activity and traffic.
  2. When I join, it takes between 30 seconds and 10 minutes to join. The average is more like 5 minutes. Sometimes it takes no time at all, sometimes it takes ages. Often, I have to try to join several times before it finally succeeds. Sometimes it's stuck for minutes at a time at 0/529 map chunks. Often, it never moves and I have to forcefully close the game. I had to download a custom .class file that removed the 60 seconds timeout on downloading chunks, or else the game would keep giving me an error after 60 seconds and force me to close it. Unless chunks download super fast which rarely happens. Sometimes the game simply crashes while joining. Sometimes after I join, the game tells me to make a new character even though I already have one. I've heard that if you do make a character, the previous one is literally just deleted, just like that. While playing, cars are often unresponsive. Start a car, nothing happens. Sometimes, 30 seconds later, the car starts by itself, sometimes it never does and I have to leave and rejoin. Sometimes a car is started but won't move, the engine sound responds in a weird way to my input but there is no movement, and I have to leave and rejoin. When leaving the server, my character is not properly saved. If I leave too fast after picking items up, the server saves that they lleft their container, but not that they entered my inventory = items are deleted. Doing the opposite allows for easy duplication of items. Very very often, a chunk will load slowly as I drive around - orange traffic cones. Very often, as I slow down and wait in front of it, it will not load and stay black forever. In certain cases, every direction around me has black areas and I have to leave and rejoin. My ping is pretty stable at 250 ms, the server is almost on the other side of the world. I don't see anyone else complaining about any of this, but most players are much nearer to the servers than I am. My connection, on my side, is fine. It's sure that mods and server performance cause some of these issues, but it's also clear to me that my distance to the server is exacerbating them. I've tried using a VPN to tunnel to the server's city but it doesn't improve anything (if anything it could make it worse). I'm kind of at my wit's end, I see no way to alleviate or work around these issues - they are making the experience horribly tedious. I spend more time look at the loading screen than playing the actual game given how much I have to leave/rejoin to fix these random issues. What more can I do? Why is it so bugged for me but not so much for the people nearer to the server? I had worse ping and probably worse traceroutes back in 2005, but I still gamed fine back then. Edit: other, closer and less populated servers are a-ok, but not this one - and again the issues seem to frustrate only me and maybe some other foreigners far from the server.
  3. Solution: a trait that removes most happiness penalties from food. Some people don't care what they eat as long as they eat. Can have the opposite, picky eater, even more penalties to happiness (thinking about the chef character in Don't Starve lol). Some more ideas: hunger should make you unhappy. IRL if you are hungry, you are very unhappy, can't focus as well on common tasks, just feel a hole in your stomach. But also, hunger goes mostly away if you ignore it for too long (after like one or 2 days), so maybe the game could reflect that. And when you are really hungry, you can eat almost anything and you'll be content, so maybe happiness penalties should also take into account just how hungry your character is. Imagine an actually realistic and complete hunger/nutrition system! Where hunger and energy stored in your character's body are not necessarily the same. With different metabolisms, etc...
  4. Modin

    Stale zombies

    Just a quick update, adding SetMovingSquare to the applyZombie method works fine to fix an IsoGridSquare's MovingObjects being properly updated when a client sends back a zombie's position to the server. But if the zombie is actually remote, then I believe that the IsoGridSquare's MovingObjects will still not be properly updated as the server simulates the zombie moving around for whatever reason. I believe the server's own update methods for the zombie do not remove or add to any square's MovingObjects, ever. The client, however, will, and that will result in another stale message. This shouldn't harm the player experience much and is why I haven't really given a good look at this, but it's still a bug and still generates "removing stale zombie" messages for clients. I am not 100% sure on this info so it'd have to be verified by devs.
  5. Modin

    Stale zombies

    Alright just add zombie.setMovingSquareNow(); To applyZombie() in NetworkZombiePacker.java After zombie.setCurrent(square); And you're done, no more stales whatsoever. This properly updates the IsoGridSquares serverside as a zombie's current is updated after receiving a packet from a client.
  6. Modin

    Stale zombies

    Back again with more info. Previous post is correct. To summarize: IsoChunk gets removed because it's far enough, 'for' loop initiates to remove everything in that chunk, and inside of that loop zombies are found to be occupying squares, so they get removed. Except! Some zombies are not there. The IsoGridSquares inspected do contain the zombies in their array list, but the zombies are not physically in those squares in the game. The zombies get deleted while being far from said square (e.g stale removal, e.g zombies going poof in front of players). How come? Because the squares are never updated. But why? Because the serverside devs forgot to update them, simply. They are updated properly clientside, which is why the client is confused about the deletions, and displays a "stale zombie" message and times out the zombies. Also why the bug is not present in SP. But the squares are never updated serverside. To be precise, the squares are updated in the postupdate() method in IsoMovingObject, but that code only executes clientside. Serverside, an IsoZombie's current attribute is updated in applyZombie used by parseZombie used by receivePacket all in NetworkZombiePacker, when the server receives an update from a client about a zombie. But that's not enough - 'current' might be updated but the IsoGridSquare arrays themselves (called MovingObjects, containing all moving objects occupying that square) are not. Hence serverside, the first square that a zombie occupies (the one it spawns on) contains it because it is set in setMovingSquareNow of IsoMovingObject (used on zombie creation/reanimation). And then, it's never updated, it contains it forever, no matter where the zombie moves. The solution is to update the squares, as done in postupdate, but to do it in applyZombie for the server.
  7. Modin

    Stale zombies

    Hi I'm back I've investigated the issue on my end with the help of modders The problem, I believe, is that as chunks get unloaded serverside to save on memory when the player moves, so do all the zombies of that chunk. And those zombies include the ones which have moved sufficiently far away to physically in the game world not be in that chunk at all, but in the game's code still technically be in it. The zombies get deleted with the chunk serverside, but not clientside, because the clientside code does not have that limitation (which is why the bug does not happen in SP, only MP). When that happens, the server removes the IsoZombie from the world while the client does not. In the act of removing the zombie, it changes its auth to null however, which the client picks up on. This is why the client then promptly discards the zombie after it's timed out (more than 5000 ms since last remote update). [C] -----------------> (z)-> <-(p) Player (p) is far enough from chunk [C] so that the server decides to unload [C]. Zombie (z) in front of the player visually does not belong to [C] anymore as it has travelled some distance already, but technically still belongs to [C] in the code, as the code has never updated its chunk. (z) is removedFromWorld with [C]. The player's client only receives the command that (z) now has no authOwner (it is now null), so the zombie turns around, awaiting the server to handle it remotely, which does not happen so it stands there and does nothing. 5 seconds have passed since lastRemoteUpdate was last set to 0, "removing stale zombie 5000" message is displayed and the zombie is removedFromWorld on the client's side. That's about it. To fix this issue, the zombie's chunk should be updated live or at least checked during any chunk deletion. I'm gonna try to implement something on my side if we have to wait another year for b42. Kind of a big problem for everyone on MP servers - kills immersion.
  8. I've got a server-side fix for zombie culling. You know, the thing that keeps deleting zombies around players and prevents you from raising the pop. The thing that is fixed by the "zombie fix" mod, provided every player has it -> https://steamcommunity.com/sharedfiles/filedetails/?id=2896255721 This new server-side version of it means you patch your server, and then regardless of what your players have installed, there won't be any zombie culling anymore. The reason I need to "beta test" it is because it might be unstable, and I'd rather not release something that causes problems. Please DM me if you're interested.
  9. Hello, In MP we can see these stats: Total Loaded Simulated Culled Authorized Unauthorized Reusable I am trying to perfect my understanding of what each states means for the client/server. I understand some of them (ex: Culled), but some like "Simulated", "Authorized", "Unauthorized" and especially "Reusable" are still confusing to me. If a dev has a bit of time to write a quick explanation I would be very grateful. Thanks!
  10. Yes at some point I bothered to turn the music off and listen to the calm zomboid tracks independently from the game. Then I just stopped bothering and kept music off forever. Pity, as you say.
  11. Press B, find rip clothing, craft all
  12. Make corpse sickness even worse? Seems like a bad idea to me.
  13. I wish the game would focus on this. Right now things don't really get that much worse besides electricity, water and food. Would be awesome if more things happened over time and progressively the game got harder and harder. You know how 7dtd hits you with a huge wave on the 7th day? I didn't play the game a whole lot so idk if it actually gets worse over time after that but I like that type of idea. Would be cool if huge hordes would form, force you to move, zombies got faster stronger and maybe even smarter, progressively every safe haven that's left would disappear one by one. Humanity would be making one very last stand before going into the deep, long night. Even better if we get hints throughout the game that the virus has spread over the entirety of the earth and that all hope is lost.
  14. It's not the same because zombies won't respawn. Clearing an area (and surrounding areas for migration) = it's clear forever with no respawn. With limited respawn this wouldn't be the case, all areas would keep stocking up for some time. While with your solution, only unvisited areas keep stocking up.
  15. Cause it'd be hard to implement. If zombies can't reach you, then it's too easy. If they can, then there is no point, might as well stand still somewhere and you'll die faster. What would climbing on cars accomplish, for you? Gotta think about it in terms of game design. What does it accomplish for the game?
  16. I also love the game and I also am frustrated by its inverse difficulty curve, as you said. It's why I clicked on the thread. I also wonder what plans are there to be excited about for its future, difficulty-wise. And I think that's all the thread is here for? Discussing the possible future, what could be added to balance the game out and keep players excited? What's feasible or not for the devs, and what we can expect for our favorite game in the coming years? The #1 topic on the subreddit is "What do I do now?" - new players are getting frustrated by a lack of incentive to do anything more than survive at all costs, and are drawn to play in a boring and very safe way. As @IndustryStandard said, the job of a game designer is often to stop players from playing the game in an unfun way. The game needs to shake the player out of that, and I believe it's one of the exciting things about Zomboid, right? You're dropped in the middle of a zombie apocalypse, and zombie apocalypses are culturally understood as anything but boring and easy to survive. I think the fun everybody has in Zomboid comes from the idea that you're always in danger, fighting for your life. The ultimate survival experience. It's what makes doing anything in-game cool. You're not just doing it, you're doing it in a hardcore zombie apocalypse where you could lose everything at any moment if you're not very well prepared and careful. The second a player starts realizing how easy it is to survive in the wilderness (or in your little cleared corner of a town), the illusion is shattered and the game loses its flavor - surviving beyond the first couple weeks loses meaning. The dev team right now is working on adding content that's mostly relevant for long-term games, right? See what I mean? Is that content gonna be relevant if the feeling of surviving a hardcore apocalypse ends after a couple of in-game weeks? I think many of us here feel like there's this elephant in the room and it's not being addressed, and we just want reassurances that this will get looked at eventually. I think this thread makes a lot of sense.
  17. Ah, that is why I'm seeing the moodle constantly popping up! Is it only around the threshold, or do kills continue reducing stress all the time? What's "stress from kills"? Kills don't induce any stress, do they?
  18. Stomping is worse because of less range. It is a bit iffy right now. You can hit consistently if you get the feel for it, but it's just not intuitive.
  19. Game just crashed (it had been open for all of 10 minutes) and upon reloading, all the zombies around were gone. There weren't a lot, but they were there. Honked for a minute, nothing showed up. My system is more than enough for any triple A game I throw at it and this is my first zomboid crash in hundreds of hours. There seems to be something wrong with the way zombies are saved or something? Like Koocai said, crash handling is part of the job after all. I initially thought the game rolled the world back to its 10-minutes-ago state but no.
  20. (NB: the variable is typo-ed in the code) ReleventRange is a variable between 0 and 12 which depends on the player's resolution. The greater the resolution, the closer to 12 - the smaller, the closer to 0. It has a ceiling of 12. It is set during connection/game start, and used for that entire session of play by both the client and the server to determine how far zombies and terrain should be loaded. It is used both in SP and MP. If the player resizes their window or modifies their resolution after that, the value is not updated to reflect the change, resulting in either invisible terrain/zombies, or useless extra load on the server/client. It is moderately abusable in MP if the player wishes to suffer the reduced visibility to make zombies disappear very close to them. Example exploit: get to the "Join Server" step of connecting, resize the window to be as small as possible with the button still clickable, click it, wait to load into the game world, resize the window back to full size. Video of what happens when you do that: To reproduce in MP: 1. Resize your window so it's very small but you can still click "Join Server" 2. After joining, resize it to your full screen Potential solutions: 1. Update ReleventRange and resend to the server every time the resolution is changed 2. Add a floor to the ReleventRange value regardless of resolution (right now it can go as low as 0) 3. Enforce a minimum resolution for the game which won't be abusable or problematic when resizing to big screens 4. Prevent the game from being resized while playing
  21. Modin

    Stale zombies

    Yes of course I verified and reverified. I'd very much appreciate if some trust were thrown my way. I've spent several hours testing this over the last few days. I do believe I know what I'm talking about and I've got my head on my shoulders. You can verify yourself anyway. Look at the videos. There are very few zombies, they're all getting culled. The reason you're seeing more reports now is because, with culling out of the way thanks to the mod, and people now more aware of the issue (and interested in having as few disappearances as possible), stale zombies have become more obvious to us, the players. After all, the mod has removed the cause for ~99% of disappearances. It's only logical that the cause for the remaining 1% would now become much more obvious while before it was invisible. As you can see in the videos, it is happening because I'm herding zombies over some distance. It has now come to my attention that stalled zombies (meaning, zombies that disappear like in my vids) will reappear and reactivate whenever another player comes close (when the stalled zombies enter another player's reality bubble). This means that if I'd stuck around the site of disappearance, and another player had approached my position, the zombies would've popped back into existence right next to me. @fadoli03 I think this might happen because of distance and not because of zombie count. In fact, it might be possible to make an empty server, spawn just one zombie, drag it some distance and see it stall. I'm not sure though, it would have to be tested. As far as I understand, stale zombies are zombies that the server has stopped updating for more than 5s. Apparently according to your findings, the server updates a zombie every 4s if it's simulated by 1 client, and every 0.2s if it's simulated by 2 or more, so it should theoretically never happen that a zombie is not updated. Obviously something else is causing the server to stop updating these zombies - that's for the devs to know. What I'm pointing out is that it's an issue that affects gameplay. I thought that the server doesn't do that anymore? You guys told us how you reworked your implementation of multiplayer so that the server doesn't have to simulate each and every zombie anymore, but rather delegates that weight to the clients, which in turn are kept in agreement with each other by the server whose job is now to decide which client is the authority owner of a zombie. So I'm very confused. Can we get a definitive answer from someone who knows for sure? My intuition, honed by hours of testing, tells me the server does not decide anything about culling. Only the clients do. I can say that it does not matter whether the server is modded with the anti-culling fix or not, Nothing changes. And I can say that the anti-culling mod causes absolutely no desynching problem. Again, this stale zombie thing is a vanilla problem, the mod has nothing to do with it. For sure. Now, in practice, in all my tests, in all reports of everyone playing MP with the mod, nobody ever sees any suspicious activity. And I know I'm repeating myself here, but the stale zombie problem is not caused by the mod, it is present in the base, unmodded game. This is not what is happening. Stale zombies are a problem with, or without a modded client. With, or without a modded server. With only 1 client connected to the server, or more. With inordinate amounts of zombies around, or with a regular apocalypse game with culling in play. You might have not played the game, or tested this enough. Culling is active in both of my videos. The volume of zombies is very low. Not even 100 are chasing me. For comparison, this is what the game looks without culling: 2nd example: Look at the videos again. I think I've made it clear that there is culling in the 2 tests on video here, so moving on: you can clearly see me looking away to run. In fact, with my extensive experience testing culling, I can say culling can and will happen in these situations. You don't need to look away for more than a second for it to take effect. It didn't, in the video, on the groups chasing me. Good! It means culling is for once working correctly, mainly due to the low amount of zombies around. However, in the 1st video you can see it delete a couple of zombies at the end of the trail. This is to say, it is no edge case. It is happening consistently for anyone dragging zombies around on a multiplayer server. Obviously, I am doing so on purpose in my vids to showcase reproducibility, but of course I, and many other players, are organically dragging zombies over such distances while playing normally, and our experience is suffering from these disappearances. House alarms are enough to trigger this bug, for example. Players have been posting videos of weird behavior with zombies that stop moving, and disappear. In fact, it was already something I had witnessed before I even released the anti-culling modded file. I just didn't know better and thought it was part of culling. The diagnostic message might not matter (although I will be investigating more, to make sure it does not). The dragging zombies around, does for sure. I've debated enough about this and this will be my last post addressing this undue skepticism. I'd rather spend my time working on a solution.
  22. Modin

    Stale zombies

    @EnigmaGrey Bit off-topic again but could you kindly re-open this report, please? As I mention in the report, the error is present whether the no-culling mod is used or not. That mod once again has nothing to do with it. It was my mistake to even mention it. What the no-culling mod changes and the only reason I mention it, is that without it (with a vanilla, unmodified game) the errors show up on the server's logs. With it, the errors show up on the clients' logs. I would also appreciate it very much if you could take a bit more time to read my posts in their entirety. It looks very much like you're skimming though them, overlooking important information, and misunderstanding them. I don't mind re-opening a report myself if needed. I hope I haven't offended you in any way.
  23. Modin

    Stale zombies

    To further understand this issue, I decided to run a default vanilla server with no mods whatsoever and try to play semi-normally for an hour, but also trying to stress the server a bit. I wanted to see if there could be non-distance related stales happening. I avoided dragging zombies as much as possible so as to not see any stales. I don't think I ever caused any zombie to be dragged over a sufficiently long distance. Meta-events, honking and gunshots should be the only causes. I didn't see any zombie stalling myself. Here are the results: I had my first stale as I was fighting zombies around a fence. I had ran around but had made sure not to drag any zombie far, utilizing line of sight. There was no shouting, no loud sounds, no meta events that I could hear. Then, very shortly after, as I was looting a house, without having encountered any group or made any sound, I had a batch of removals: I saw several more stales over a few more minutes of staying put: Note that I did not notice any zombies disappearing. After a dozen minutes of running around and causing a ruckus and only seeing one stale disappearance in the logs (29635), I sat still in a room and noticed another batch of removals. (note that I always dragged the zombies over very short distances) Finally I went out in the streets and shot some 50 shells into groups before running away and ending the experiment. In that time I did not see a single stale, however, when coming back out after having drawn many zombies around, I noticed there were significantly less - whether they were removed by culling or stalling, I do not know, but they certainly didn't wander away (I only waited inside for a couple minutes). In conclusion, I did see a lot of seemingly random stales in the logs with no apparent cause, but did not notice any disappearances in-game. It would seem that there are 2 types of stales: "organic" ones that just happen during normal gameplay and happen out of sight, and "artificial" ones that are forced through dragging zombies around. The second obviously breaks immersion as zombies cannot follow you for very long without disappearing, and the first, while invisible, does have an effect on gameplay as it makes zombies non-persistent, which further serves to break immersion. For example in my game, I could draw a number of zombies around, lose them around a corner, stay inside, and when coming out, most of them were gone. Most importantly, stalled zombies, unlike culled ones, stay active and come back to life once the player wanders far enough away. This can cause even more inconsistency with zombie movement/positions, since what the player thought was a safe zone is in fact infested with invisible, stalled zombies that are just waiting for reactivation. Note that all tests here were realized with the same settings as the 2nd video - apocalypse default settings on a vanilla unmodded server, in west point.
  24. Modin

    Stale zombies

    Again, the stale removal error has nothing to do with any mod. It happens with the base unmodified game. I was running the base unmodified game in that vid. You can see some zombies getting culled. No matter, I made a second video with the entire process visible, and if you need anything more, then just tell me: 4 batches of stale removal 1st removal: 2nd removal: 3rd and 4th removals: It would appear, btw, that zombie ids are not directly related to culling-relevant zombie count. I don't know that there were or were not 21k zombies in the first vid, and 9-10k in this one. I couldn't see any culling happening on-screen in the 2nd vid, at least. Finally, I neglected to showcase this but know that, had I backtracked to previous sites of disappearance (if they were far enough away), the "stale" zombies would've freshened back up and been active again as if nothing happened, only to go stale again if dragged over a sufficiently long distance once more. This is off-topic, but @EnigmaGrey there are no desync issues with the mod that I can see. There can't be when you're all alone on the server and the server does not care about the culling algorithm (does not use it, and if it used it, it would use the modded file anyway) - there should be no disagreements anywhere: there is nobody else to disagree with (again if the server ran its own culling check, it would agree: it has the same files as the clients). I tested this myself: separate server with its own files, whether the server is modded or not makes no difference as to what happens in-game and what errors are logged. When there is another client to disagree with: one with the mod, another without, there are no issues. No invisible zombies, no weirdness, not one player seeing something the other can't. It all stays perfectly synched between them. They see the same "stale" zombies go "durr" then "poof", they are attacked by and kill the same zombies, everything is consistent. Only this "stale" zombie problem is compounded for some reason that I'd very much like to figure out hence my interest in this report. When I mean "compounded" by the way I mean that, with no mod, stales happen when dragged over a sufficient distance. The log is not spammed by stale removals if one does not drag zombies over a great distance. With the mod, the log is almost constantly spammed by these, even without dragging zombies, and on top of this of course stales happen when dragging. The world is still filled with a healthy amount of zombies but it does feel as if some of them are disappearing, and then reappearing when the player goes far enough away and then back. This creates a sort of inconsistency which, added up with migration and meta-events. makes it hard to track zombie movement. [EDIT: I was wrong, the log is spammed by stale removals without the mod too. The mod just increases the amount of zombies, and such, the amount of removals. It would appear to be a simple numbers game.]
  25. Modin

    Stale zombies

    Hey again, The issue is 100% reproducible by doing this: Here is the log of when the disappearances happened: Load up a new server, round up some zombies, kite them for a couple minutes, watch them all disappear. The logs say "removing stale zombie 5000". In that example run, there were no other stale zombie removals that I can see. It was only at the end of the kiting. This was with culling still active. Without culling active, the messages show up every few seconds, even without kiting any zombies around. It would appear to be deleting lots of zombies somewhere out of vision. I am unsure what link there is between the two instances of stale zombies.
×
×
  • Create New...