Crater Creator

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!

Please post in English. You may post in other language(s) below the English text, wrapped in a spoiler tag, if you like. And as Star69 says, please post support issues in the General Support section, following the pinned threads for instructions.

Star69 is correct.

It's noisy even with the silencer. I'd opt for the magazine extender.

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.

Oh, my childhood! Y'know, that game had crafting, traps, melee & ranged combat, tools, procedurally generated worlds... you may be onto something there.

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.

Madmole is taking the "get off your ass" mantra to a new level. A21 will pair with smartwatches and other wearable devices. Actions in game that expend stamina will only work when your real life heart rate is over 120 bpm.

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.

Okay, I understand now. "Extended to the wall blocks" sounded like you were asking to extend coverage to blocks outside of the sleeper volume (trigger area). I see the potential benefit of what you're asking. But I would also note that sleeper volumes are not matched with walls in a consistent way. Sometimes the sleeper volume is large enough to include the walls, and sometimes it isn't. So relying on blocks being in the sleeper volume or not to trigger the zombies within would yield inconsistent results, unless a design pass was done on the sleeper volumes to establish consistency.

The trigger areas are box-shaped volumes, hand-placed by the level designers. It seems unlikely a programmatic solution would work in all POIs, without taking away the designer's control (e.g. making the zombies wake up too early in some cases).