Crater Creator

We don't know what that is. For clarity, the official, verified 7 Days to Die twitter account is here. https://twitter.com/7daystodie/.

What it really comes down to is if you accept or reject the premise that you're trying to survive. If you do, then the choice is clear: take the honey. I happen to think of this as a survival game, so that's how I would play. Even if you're not playing permadeath, and you would respawn and keep playing, dying would mean you lost that 'round' of trying to survive. Death is failure in a survival game, even when there's flexibility in what happens afterwards. -- So, the zombies are really unsure what to do with you at first glance, eh? While I don't exactly interpret 90% infection as meaning that you are 10% human and 90% zombie, this could be a cool feature. As you get increasingly desperate and throw caution to the wind hunting for a cure, at least the zombies are a bit less sensing of your presence at higher levels of infection. I think it's cool for a game to adjust the blend of challenges like that, instead of merely tacking more onto the baseline.

The tempered and serrated blades, at least, always seemed clear to me. If the mods were themselves separate blades you were just sticking on, then you could probably stick them on anything. The fact that these mods only work on bladed weapons suggests to me that you’re modifying the blade that’s already part of the weapon. I assume the two axe head type mods only work on axes, but I haven’t specifically verified this. I take the icon art to be representational. Meaning, that if you have a wood cutter mod on a stone axe, it’s still a stone axe, but the shape of the stone blade is modified appropriately(whatever that looks like) to be better at chopping wood.

For sure. There are wall safes which fit the bill, and last I knew they're in at least one of the bank POIs.

If you see no text (e.g. “Metal Drawer” or similar) when aiming at it, then it’s not the loot container version and there can’t be anything inside. There are some blocks, like paintings, that can be placed over a hole in the wall to hide a different, lootable block. But the metal drawers used here aren’t one of those.

You don't want it to be confusing, but you don't want to have to make an entirely new kind of UI thing either. And the game doesn't have prompts like you're describing, that I can recall. That's why I suggest e.g. colorizing the number of parts. But it could also be one of those notices on the bottom of the screen, or an informational buff, unless that's too hard to see under the crafting menu. I'm not too worried, because at least the way I play, I wouldn't go to craft something without grabbing as full a stack of each ingredient as I have in storage. I'd have to go out of my way to grab 10 pistol parts when I have 30 - it wouldn't happen by accident.

And people = testers in particular. Nothing's worse in testing than regressing on a bug someone reported that's actually from a deprecated build of the game. I second your prediction that it'll be gone (by default) when the game goes gold.

The first problem I don't think is unique to my solution. In the current game, you could just as easily craft a low-quality weapon, then upgrade the skill, and then lament that you used up your parts with no way to retrieve them beyond scrapping the item you made. I'm just putting the choice in the player's hands of what quality to build instead of forcing max quality on them. Just to spell out the idea more, if for some reason you wanted an item at lower quality than you had the parts for, you could put away some parts and leave the rest you want to use in your backpack. But I'm sure the most common use case would be players that want to craft the best quality they can with the parts they have. With that said, I would welcome higher quality items scrapping for more parts. And/or, there could be a skill that improves your ability to recover parts from scrapping. Heck, even with the system we have now, I wouldn't be as scared to craft a low-quality item, if I knew that I'd consistently only be down 25% of the parts when scrapping and rebuilding it to a higher quality. On the second problem, yes, it should be clear when you could make a higher quality if you had more parts. That's why I propose colorizing the parts seen in the crafting recipe window, with the appropriate journal entries updated to document this. I admit colorized text isn't perfect since some people are colorblind, but I'm thinking in terms of a minimalist solution that requires the least UI work: less work than repurposing the trader reward UI or adding a new widget for quality selection and re-arranging the crafting window.

I completely agree, and this is the perfect way to implement it. The game simply makes the highest quality item possible with the number of parts you have in your backpack at the time (assuming you have the skill to craft that level). At most, it would be nice to colorize the parts in the crafting UI to highlight that you could craft higher quality with more parts, but otherwise no UI work is necessary.

My thoughts on this may not be original, but to add to the voices: The designer in me instantly wants to know what happens if I destroy the pipeline between the valve and the fire. I look forward to finding the answer... and I appreciate how in any other game the answer would be, "What? You can't just break the pipe anywhere you want. It's just a game, don't expect so much." It feels off that closing the valve, so that something making noise makes less noise, wakes up the zombies. It would help plausibility if, instead of a tiny pfft sound, there was a more jarring sound, like an exaggerated metallic shudder of the valve shutting. If you have the art budget to do that... could you please revisit the flamethrower trap concept? Nothing fancy, just a big open flame like this that consumes gas when turned on. Dungeon crawling is great, but crafters & builders want to enjoy fire hazards, too!

Both good questions. On the coding cost, I don't think it would be worse than adding arrows. Those arrows would have to be coded to render only when placing the block, and not render at other times. So coding the door to play an animation (which already exists) when placing it would be no worse than that, coding-wise. As for PC load from having another animation loaded, I don't know if the game is optimized to unload animations for blocks not currently in the world. There aren't a lot of these animations compared to, say, enemy animations or player character animations, but it would still be a good optimization to have. Even if it is, we're talking about having one more animation for the few seconds it takes a player to place the door, before the door is placed and will have that animation loaded forever after. The player can't have more than one block equipped at once. Compared to all the other types of doors etc. that are typically loaded in the world at any given time (at least when around POIs), each of which has their own open/close animations, the one added animation would have minimal impact. For that matter, the blocks may already be playing a looping 'stay closed' animation while you're placing them, that happens to include no movement.

This occurred to me during a discussion on the Steam forum. Problem: players don't know which way many doors, hatches, and drawbridges will be placed. They run the risk of installing them backwards, which can render them ineffective, ugly, and/or costly to fix. Solution: what these problem cases have in common is that the block animates. So when the game shows a ghostly version of the block to indicate where it will be placed, this ghost version should be animated, playing its opening or closing animation on a loop. Then the player would always see its orientation, range of motion, where space for it is needed, which side the hinge is on, etc., without requiring arrows or other new art assets.

I've cleaned up recent posts, so that the thread can stay on the topic of the Darkness Falls mod without distractions. The last thing I want to say about it is that the forum does have a block/ignore feature, as described in the Explanation of Features and Guidelines.

I take your point that the behavior is working as intended. However it's overzealous to say that's not a bug. It can still be a localization bug, if the game tells the player "NO TRADER" in situations where that's an objectively false statement. The fix could be what Blake's talking about where the mission resolves itself, or it could be changing the localization to say "No traders meet criteria" or similar.

Scripted enemy encounters get repetitive when you're making multiple visits to a POI in a playthrough. More importantly for this game, scripted enemy encounters don't mix well with 100% destructible worlds. I guess it depends on how much scripted stuff you're envisioning, but the dynamic, world-aware behavior needs to be there, and robust enough to kick in at any time. One feature TFP discussed publicly not long ago is sleeper zombies that roam through a POI, instead of them all being stationary (a feature I insist be called sleepwalkers, because come on ). From a technical perspective, that sounds exactly like entities that travel along patrol routes, so if implemented, it sounds perfect for bandits.

The weird thing is, I remember a dev video (A17 or so?) where Madmole talked about adding this feature. As I recall, they may have even demoed it in the video. I don't know what would have changed their minds.

That'd be hilarious. TFP: Here are your bandits! TFP: *replaces zombie grunts with Trader Rekt voice lines* TFP: *makes no other changes*

faatal said, "They will not loot stuff or destroy things unless they are in their way just like the AI currently does." The 'bandit screamer' idea is designed to work within that framework, while still allowing your stuff to be a risk factor for how often bandits appear. A 'bandit screamer' would focus on loot only in the same way that a zombie screamer focuses on forges. Your stuff triggers them to spawn, but they don't attack or loot your stuff. Again, I'm trying to work within the rules faatal has revealed on how bandits will work. I didn't say anything about friendly NPCs. These bandit screamers could be a separate system independent from other bandit encounters, the same way zombie screamers work independently from sleeper zombies in POIs.

That's one reason why they'd operate on the same basic idea as screamers. Nobody sits in their base 24/7 because of screamer hordes, right? So players wouldn't do that for bandit hordes, either. There could even be a bandit 'screamer' that comes first, and whistles loudly or calls in on their walkie talkie if they see you. Like anything else, the frequency of bandit hordes should be balanced appropriately so it's fun rather than tedious. But it seems to me like a natural consequence of having a big, fancy base with a lot of valuable stuff should be that you're a bigger target for bandits. After all, bandits are robbers by definition. They should launch opportunistic attacks, rather than solely playing defense or lying in ambush. And "a lot of valuable stuff" is probably the easiest option to quantify since everything already has an EconomicValue.

Hmm. That's actually disappointing, to me. Bandits that don't care about loot wouldn't be very bandit-like. Perhaps the spawning of bandits could be affected by loot, even if their targeting/pathing isn't. The game could (infrequently) add up the EconomicValues of the player-placed items in every container in the chunk, and ever so often this value could add to an 'economic activity' map. When the economic activity reaches a threshold, the game spawns a scouting party of bandits. In other words, it's a rinse and repeat version of the activity map that generates screamers. That, and air drops, seem like two targets in which bandits should be dynamically interested.

Welcome to the forum. I'm not a dev, but having followed them long enough, I know that this has been asked before. Brass being a non-mineable forge resource is no accident. It's part of the vanilla game's design, that you can't make bullets through mining alone.

I'll move this to the Support forum. So you know, a null reference exception is the game equivalent of your car's check engine light. It's a generic error, which doesn't really narrow it down to a particular class of problems. The pinned thread in Support should provide instructions for providing a log file among other things.

I think you're right. And the conclusion for me is, this is why we can't have nice things: the nice thing in this case being knowledge of who reacted to your post. If the forum were less transparent and didn't identify who reacted, then seeing those unattributed, impersonal reactions would be easier to tolerate. Yet it's ironic that the solution (short of removing negative reactions entirely, which would be stifling) is anonymity, since that only allows for more 'cowardice' as Fox would call it.

Do people still interpret reactions that way? I never have. A negative reaction - even on platforms where a downvote does mean negative fake internet points - doesn’t mean, “I deem you a bad person.” It means, “I didn’t like your content,” e.g. your post when it’s a forum. That’s why the reaction is permanently tied to the post that triggered it. This isn’t directed at Roland: I don’t understand someone who takes, “I didn’t like something you wrote,” as a personal affront, that requires retaliation against something the reactor wrote. No one would respond to a written out post that way, right? If you write up a treatise on how to fix farming in A20, and someone says they think you’re all wrong in a reply, you don’t go looking for one of their posts to rant against out of spite, right? Or if someone downvotes your YouTube video or your Reddit post, you don’t track down the user and downvote some of their content, and shake your fist if they’re just a lurker with nothing to downvote. I guess my point is, there are Kuosimodos on every site where content has an up/down rating system (and as Roland points out, we don’t even have that). Usually you don’t know or don’t care who they are; you just look at how people react in the aggregate.

Sure, a user's IP is logged. It's logged on every... post. (not to mention how IP address isn't as uniquely identifying as it once was). I'd think it was a weirdly configured bot account - a fluke of programming - except that then I'd expect other accounts to behave similarly. Still, absent more information I wouldn't say we have carte blanche to call Kuosimodo names, whoever or whatever it is. I also recall that the last time it came up, Kuosimodo had a healthy mix of positive and negative reactions. It's true that people take more notice of negative reactions. One could argue that Kuosimodo was influential in removing the poop reaction... kind of like the buddy I played with that killed his teammates incessantly in the spawn room in Team Fortress 2, until the admin relinquished and turned off friendly fire. Now, the worst Kuosimodo can do is thumbs-down your post, unless they ever want to speak up.