Cut Questable POIs to 50% of all POIs

Status
Not open for further replies.
Your suggestion doesn't improve anything. It just reduces variety.

I agree, however if this is just about Grandpa configuring his own server, it doesn't really matter. He's free to experiment, right? "Common Sense" can be proven to be better than actual expertise about 1 in 20 times, so you never know. I'd be entertained to read what he learns from it. I've even been willing to provide suggestions that would let him do it, though I don't get the sense anyone is interested in the configuration changes so much as just talking about it.

TFP, on the other hand, will weigh the suggestion with their direction and inside knowledge, and come to their own independent conclusion.
 
If your still not understanding it than...
A) look in the mirror and ask yourself why is it so many players, streamers and veterans of this game believe a16 and prior was a better state of the game than it is now?
B) Than ask yourself what changed to cause that

**note on steam discussions, 7d2d forums, youtube, blah blah anywhere
i have never heard one person claim any alpha after a16 was the best state of the game that exists
so once again what is the X factor that changed the game after a16?
People will have many reasons why they think a certain version is best. Some like LBD, some want empty jars, some don't like traders at all, some don't like quests, etc. None of those have anything to do with reducing the number of questable POI. There are so many things that have changed since A16 that you can't make a claim that everyone who prefers A16 or older does so because of the quests. And even if that were true, if people don't want quests, they don't have to do quests. Servers can set daily quests to 1 (maybe to 0 even, though I don't know if 0 is possible). And lowering questable POI won't reduce questing. It'll just reduce variety as has been explained repeatedly.

And you're certainly lying about never hearing anyone say they like an alpha after A16 better or consider it the best version. Either that, or you are blind. There have been many people who have said that on this forum alone. And I'll say it myself just to make it impossible for you to claim that no one has every said it... I consider 1.4 to be the best version of the game to date. I haven't tried 2.3, so maybe the changes in that will be enough to make me consider that to be the best version, but at this time, 1.4 is the best version of the game for me. There, you can never again claim that no one has said that even if you won't acknowledge the many posts by people who say that.
 
And you're certainly lying about never hearing anyone say they like an alpha after A16 better or consider it the best version. Either that, or you are blind.
Tihihi, it's hard to hear if you're blind, I heard. Saw? Chainsaw? Chainsaw massacre? Are you implying that Roland fosters a herd of serial killers? .. Sorry, grandpa's style of logic seems infectious. :)
 
TFP, on the other hand, will weigh the suggestion with their direction and inside knowledge, and come to their own independent conclusion.
look, im not just blowing smoke to people i run one of the most populated servers in the world and have so for many years in this game, which means i litterally see and hear from thousands of players each seed that tell me things im trying to pass along to you guys.
I would luv to go in great detail why this or why that when i get more free time but atm having to tend to our server.
 

Attachments

  • Screenshot 2025-07-26 124718.png
    Screenshot 2025-07-26 124718.png
    13.5 KB · Views: 12
Placing a land claim block remove this issue completely, therefore it's already addressed and you are just refusing to use the game mechanics.



Common sense answer would actually be that number of questable POIs changes nothing if the number of active quests stays the same. If the actual strain is chunk reset, the strain remains the same as long as there is at least as many questable POIs as there are players on the server getting quests and resetting chunks.

Hyperion hasn't provided any answer to anything, he has just thrown insults around while trying the classical jargon overload approach. Like all your other buddies (assuming they are in fact separate people), they do not bring coherent arguments. It's always either inflammatory interactions or AI assisted/generated answers.




Repeating your AI assisted points doesn't make them true.
I have absolutely provided an answer. You're ignoring it. I don't know why...

You levy credentialism and popularity against knowledge and intelligence. Saying my badge is evidence that I don't know something? Is this Reddit? Do we judge people's knowledge of how IT works based on how many times you've commented and been a member of a group? Because that's called an echo chamber, and we all know how those go down.

So, I'll start over. This is about getting the game running properly without server crashes, and as far as technology and troubleshooting goes, the primary culprit is network congestion.
 
Last edited by a moderator:
I would luv to go in great detail why this or why that when i get more free time but atm having to tend to our server.
You can start by responding to the points I made in red and the points theFlu made about your list. I can't see any possible way you can spin your suggestion of reducing questable POI by 50% as a way to solve any issues you brought up (not that most are even related to questing). You do understand that you can change quests per day, which will do what you want, right? If you have quests per day set to 4 and reduce it to 2, then you're going to reduce quests by 50%. Technically, people can still quest, but they won't get the credit for it, so it probably won't reduce questing by the full 50% because some will just keep questing, but you'll get a reduction. Your suggestion won't reduce anything.
 
I wouldn't mind server improvements, even if they do nothing for my SP games. The studio just won't. To join your little pressure campaign, I would just need some details; what are we actually looking for. Some actual actionable suggestions.

Because, given the recent track record with badges etc, we can safely bet that if we convince TFP to "improve servers" by the ideas you've displayed here; we end up with another Live Service Slop. The world will get static'ed, the POIs will get put behind portals to be isolatable and we'll get a badge-worthy Zombie Season Pass every few months to pay for the amazon clusters.

Dunno about you, or grandpa, but I don't want that.

Zombie games have always been something that a lot of folks want to be involved with, especially multiplayer. Even multiplayer on a large scale. I recall Resident Evil Outbreak being a huge hit because you finally weren't alone against the horde. Left 4 Dead was also one. The idea that it is only a SP game, or that we should only limit it to 8 people, is ridiculous. If so, the option for pvp wouldn't be promoted so heavily.
 
Last edited by a moderator:
This is about getting the game running properly without server crashes, and as far as technology and troubleshooting goes, the primary culprit is network congestion.
No. The current topic is specifically about reducing questable POI by 50%. See the topic title and original post. GM claims that doing so will help with networking, but that's not really true. If you want to discuss issues that actually impact network performance, a new topic would be the place to do so. Otherwise, you are just off-topic.
 
ask yourself why is it so many players, streamers and veterans of this game believe a16 and prior was a better state of the game than it is now?
I think the actual answer to that question is likely incredibly complicated, and it's not likely one single reason.

If the hypothesis is that it's because of too many questable POIs, how would you be able to prove this is not the case? This sounds like an unfalsifiable claim.
 
Just for reference, it is very easy to make a map that has fewer questable POI. Just remove the questable POI you don't want from the game folder before making your map. You will then have fewer questable POI. And you'll quickly see that it doesn't really improve anything. And if you have players who like to quest, you'll likely just make them unhappy with your map.

Since you can control this already without TFP doing a thing, and since most people who enjoy questing want MORE questable POI rather than fewer so there is more variety, it is not a good suggestion to reduce the number of questable POI. And I doubt we'll ever see TFP do so.
 
Just remove the questable POI you don't want from the game folder before making your map.
once again your not understanding, no one has recommended removing prefabs from the map, if anything im 100% for adding more prefabs to the map.
The recommendation is to reduce the amount of prefabs that are on the map from being questable (as it is now 90%+ of all prefabs on map are questable)
 
The idea that it is only a SP game, or that we should only limit it to 8 people, is ridiculous.
8 ppl, ridiculous? It's a fact, that's what the studio is aiming for. It's also common knowledge; just checked couple separate server admin guides - for example valvesoftwave dev guide: 8 is supported, from 20 onward issues start.


You want me to read, well, here I go ;)
 
Last edited by a moderator:
look, im not just blowing smoke to people i run one of the most populated servers in the world and have so for many years in this game, which means i litterally see and hear from thousands of players each seed that tell me things im trying to pass along to you guys.
I would luv to go in great detail why this or why that when i get more free time but atm having to tend to our server.

Okay, and I'm not the one to evaluate your bona fides or weigh your recommendations for anything beyond my own irrelevant opinion.

What I can do is tell you your goal of reducing the number of POIs with quests is doable with the mechanisms TFP has given you. It is just data. It can be changed. In a previous post I listed the XML to change. Can I provide you any further information that would allow you to achieve your goal for your server?
 
in case some of you are still a little confused
this is what happens when any player resets any prefab because of a quest
now keep in mind also when a prefab resets from a quest the whole chunk gets reset from bedrock to sky

Immediate Performance Effects​

CPU Spikes: When chunks reset, the server has to regenerate all the terrain, structures, blocks and entity data for those chunks. This creates temporary CPU spikes as the world generation algorithms run, which can cause brief lag or stuttering for players.

Memory Usage: Freshly reset chunks need to be loaded into RAM again. If many chunks reset simultaneously, this can cause memory usage spikes, especially on servers with limited RAM.

Disk I/O: The server needs to write new chunk data to storage and potentially delete old chunk files, creating increased disk activity that can slow down other operations.
 
now keep in mind also when a prefab resets from a quest the whole chunk gets reset from bedrock to sky
... And your suggestion does not reduce those events by a single one. How is this difficult?

Player goes to trader, sees 5 quests listed, takes a quest, goes and does it.
You're only changing Which 5 are shown to him, not that there ARE 5 shown to him.
He will do just as many quests, just at different locations.
 
suggest on this...

When a chunk gets reset the server has to do some heavy lifting, and that can affect performance in a few ways:

🔹 What Happens Internally​

  1. Unload Old Data
    • The server clears all block/entity data for that chunk from memory.
    • Any player-built blocks, loot containers, or entities in that chunk are deleted.
  2. Rebuild from Prefab/World Gen
    • The chunk is regenerated using its original prefab or random-gen template.
    • The server runs world-gen code to re-populate terrain, POIs, loot containers, and decorations.
  3. Save to Disk
    • The new chunk state is written back into the save files.
    • This means extra I/O load, especially on HDDs vs SSDs.

🔹 Performance Impact​

  • CPU Spikes: The reset involves recalculating terrain and regenerating structures, which can briefly spike CPU usage.
  • Disk I/O: Writing/rewriting chunk data can cause latency, particularly on slower drives.
  • Network Sync: If players are nearby, the server must re-send the updated chunk data to them, adding extra network load.
  • Temporary Lag: Nearby players might see a stutter, hitch, or rubberband as the server finalizes the reset and pushes the new chunk.

🔹 Factors That Affect Severity​

  • How many chunks reset at once: mass resets (e.g., automated cleanup scripts) can cause major lag.
👉 In short: Resetting a quest prefab chunk causes temporary CPU + disk I/O spike, and if players are in the area, it can result in lag or rubberbanding. On good hardware mass quest resets can hammer server performance.
 
Player goes to trader, sees 5 quests listed, takes a quest, goes and does it.
You're only changing Which 5 are shown to him, not that there ARE 5 shown to him.
He will do just as many quests, just at different locations.

The player might spend more time traveling if the available quests are farther away, which might happen if there are very few of the quests for the trader to offer. While that itself might reduce the amount of chunk resets, traveling leads to more chunk loads. I suspect that travel translates into more Disk I/O and churn in the RAM as the game loads more chunks. Or, if those chunks have not been explored, then those chunks are being generated as they travel into unexplored space, right?

My suspicion is that chunk loading and handling is about as optimized as it can be, unless they Devs can change the algorithm to do partial chunk work over multiple times through whatever the game loop is, spreading out the processing some way. But that's a wild guess as I don't have any access to that source code or any inclination to decompile it and look. Maybe you could have POIs reset in partial steps and players have to wait 5 seconds to start their quest -- assuming TFP came up with an algorithm for that -- but when it comes to travel I think you're probably stuck at the mercy of the hardware and the network. People like to run the speed of their vehicles up to the point where they outpace the computer's ability to put a world before them.

A reminder -- this is a theoretical exercise for me since I don't work in TFP's code. I can't possibly do more than guess.
 
Status
Not open for further replies.
Back
Top