theFlu

It happens, rarely. Something like the decorations-phase slapped a loot container (bird's nest, trash, you can guess by the loot you got) and a tree in the same spot and birthed a lootable tree.

Yeh, it's getting pretty wild.. now all we need is micro-nuclear to take off to power it all ...

Long press F opens a dial menu for your choices when available. Taking out a weapon flashlight is good and well, but has some caveats.. you might not have a replacement mod for the damage buff, and then there's the laser dot sight which operates on the same button. The long press is fine, but it's about as fast (and somewhat easier) just to swap to a "modless" weapon to toggle headlamp. EDIT: I used 'F' as per Roland, but I'm not actually sure of the keybinds - my F is "use" ..

And if you run into a Savage Country for "clothes" .. the shirt racks drop shirts, the pants racks drop pants, only the piles on the floor can give other things (like armor parts). Which is nice and immersive, but makes looting the racks mostly useful for dyes.. =/

Yeh, I remember you describing it earlier.. I don't hate it, but I also kinda like how Padded remains a viable alternative all the way to high level military stuff. Taking away some of the early/mid game power via the pocket mods wouldn't really hurt that; if you really want it in late game, you could spec for pack mule. Your way is more likely to please a game designer, for sure ..

The damage reduction isn't horrible, and there's no drawback to it either. So .. still a small win

For me, the armor difference is so small that any reasonable weakness on leather is pretty much always too much. Add the quality difference and mods and Padded will win. One option might be to make them .. "conditionally different". For example, take away the ability to put pockets in Padded. That way, if you want to haul plenty of stuff around, you're better off in leathers. If you want max speed in light loads, padded. Makes no sense logically, but it would at least make it a decision.

Well, you have landed on the General -section of the forum. Here we pretend to know nothing of mods. Modding section thaddaway -> https://community.7daystodie.com/forum/27-mods/ Please find an applicable thread there and post there, possibly a thread mainly about the map, but people in the general DF thread might be able to help as well. Search tools, as they are, at the top of the page, right hand side.

#define "this map" Navezgane #define "research lab" factory_03 eval(OP); >No. For reference, factory_03:

In theory, absolutely. In practice, it would likely need a whole lot of rewrite just for a "side atlas". I mean, there probably are several atlases in different uses already, blocks vs mobs vs weapons as an idea, different things with different requirements. But to get one type to load from several, might be a lot of effort. If even supported by the engine at all - at which point you could modify the engine, but the effort and risks start skyrocketing. There's so much I know I don't know about the situation, and likely 10x more actual issues that I don't have a clue of ... the pimps would probably like to have all of the textures, but they've chosen this amount after serious consideration; I have no choice but to trust them.

Why wouldn't I, every time there's more stamina in the bar than there is empty? Standing at base, staring at camp fire; what do I get from the heavy armor then? Other than "25%" more time spent waddling over from box to box - it affects walking speed too. The book is OP, it single-handedly wins the fighting part of the equation in favor of heavy. But I like clearing things in stealth, and that isn't as easily overcome.. and I like fast paced fights, it's a choice for early game. Might not be optimal in some sense, but once you're used to moving at a 100 all the time, going 70 for scrap armor is like walking in a swamp.. I also skip the bicycle for its inconvenience, bike wins A-to-B over walking, but loses A-to-birdnest!-back-to-bike-duffel-bag!-back-to-bike-wheredidIparkIT-vendingmachine!-damn.fence-backtobike-B ... That often means I'm running everywhere for a week or two, if not Trader-looping for higher tier transports. And once I'm used to it, there's no swapping to heavy until late game with the book and full fittings. Which I often just forget to do ...

I haven't handled them for reals, so some salt to be taken, but one "level" is basically a new bit of addressing to a two-dimensional array. So if you had 16x16 textures earlier, next "optimal" step is 32x32; quadrupling the memory. And then it all depends on the tool chain, GPUs may have demands, the game engine may have demands etc - I don't even know where the thing is actually handled, but wherever it is, there's going to be plenty of algorithmic optimization going on based on some standard solutions decided somewhere at some point in time ...

Jammed modifier keys? Shift, ctrl, alt .. sometimes one of those jams in a down state, especially when swapping programs. That messes some game up properly, haven't seen it in 7dtd though. It should resolve itself quickly, whenever you actually press the button again. But then again, win has had the notorious sticky-keys as a feature...

With 0 overlap, perhaps. But you'll lose your ability to build in POIs. The atlas is the size of "every bit of memory you're willing to sacrifice for it", so you can't load 2 simultaneously. Loading one, takes out the other. Any texture that can be used in an area, must be in the current one. So you couldn't use "blocks of POI 1" in POI 2, and vice versa. Additionally, everything outside the POI in drawing range would need to be from the same atlas, so you couldn't place POI 1 and POI 2 next to one another. Not even in the same town, as you can't have both sides of the boundary visible at once.

Pretty similar, we're both on a diet of boiled and charred meat .. And coffee, naturally.

Yeh, it's just a minor gripe, feel free to disagree Your way is effective, just not efficient. If they fall from a bodyshot, a headshot will kill them; if you miss, just take another in most cases. If you have to walk over anyway to finish with a club, the arrow is pretty redundant.

Maybe A21 things..? In A20, the ammo type for every weapon is always selected. By default every bow uses stone arrows, you'll have to manually switch to any other type. Bows load the next of the selected type if you have any after shooting, crossbows or other firearms don't. Unless you try to fire again while empty, which causes a reload on everything. If you don't have more of the right type for a bow, you'll hear an empty trigger click, you don't get a type change automatically. I guess the difference is due to the double nature of the bow loading, you ready an arrow first, and then you manually draw it. Other weapons you ready and then fire with a button_down on mouse1. Automatics start firing on the reload press if you wait long enough, semiautomatics will wait for a new click for the first shot after loading. For bows the readying is automatic, but for a while it blocks the next draw like a semiautomatic reload. You'll need to wait a bit for the new click.

I'm not sure, but I think they didn't really change the system, they changed the textures available .. all kinds of wallpapers and such taking the space of the Nth color of the same rusty metal. Makes it feel like a color loss, but the system was the same; just less types with more color options.

"Big" deal, not really. But it is the primitive-game gating item. Without having to loot for those, you could just dig an iron node and not have to loot. It's a design decision; one I don't necessarily agree with, but one that does work just fine in vanilla. There's two "loot only" bits gating a forge, pipes and duct tape - you can craft tape, but at the bottom there you'd need jars from loot. In that sense jars are also "gating and gated by" the forge. At the moment there's tree stumps that let you avoid looting jars - but the principle is there; it's there to drive looting for things. And A21 will of course change things again..

Great! Glad to be of help I had a bit of a flicker as well. As the off-cams turn the lights on when coming in, and the on-cams won't see me at the time, the flicker happens when walking between the two fields of view. It might be eliminated by adding a short power duration on the off cams. Instant / 1 sec, or something so the off-cam keeps the lights on until the on-cams see you. But it also may just bug the system, as the off-cam might turn the lights off anyway after the delay - I didn't try it. But it's a whole lot easier than switches as is, so I count it as a win

Had a little test. On the bad news -side: Darnit, I made a mistake earlier. Gen - Cam1 - Cam2 - Cam3 - Cam4 - (load) It looks like the "off" cameras need to be first in the chain, so 1 and 2 Need to be set to Instant/Triggered, then 3 and 4 can be Instant/Always. On the good news -side: I did manage to get the setup working. 4 cams, 18 lights, two virtual doorways with cams pointing down. 18 daisy chained lights. 110W power draw, so three engines minimum. I also added a mute camera between cams one and two, just to test the extension, seemed to work fine.

Ridiculous? Not at all. Ambitious at worst Shouldn't be an issue, basically, where I wrote "Lights" you can put whatever load items, as many as you like. More triggers may make things confusing, but the point of JaWoodle's build was to reset trip wires for traps and it worked, so even those should be fine. 18 lights may require a little extra thinking; I think the limit for connections "out" from one relay is limited to .. 5 or 10, not sure atm. But as long as you don't cross that or the other normal rules for electricity, you can do whatever. 18 lights in series, or five relays in series, each feeding 4 lights separately. By "pointed at", I'll take you mean "connected to"? Pointing sounds like setting the trigger area and you wouldn't point it at a light in that case. Yeah, the same outgoing connections limit applies to cams, you won't get a single line out to each light from one cam.. but a daisy chain aka "in series" should feed fine. So either: (The previous cam setup) - Relay1 - R2 - R3 - R4 - R5 Each R feeding another R and 4 lights - if you want one line per light. Or just (The previous cam setup) - Light1 - L2 - L3 - L4 - ... - L18. Should work.. start simple and test while building. Keep the power on while connecting, pretty sparks, but no harm .. Also, lights are 5W each, I think, so make sure you have enough power in your genny.

Give it a go, I'm curious I would imagine that a setup of 4 cams would work as well as the two, I assume the two "always on"s will turn off just the same with either of the off cams - as long as they're all in the same "detector chain". If you need a "relay" between any of the cams, use another cam instead and it should be fine. If you have two actual doorways: Cam3 and Cam4 inside, above the doorways pointing down (for example). Triggered/Always. Cam1 and Cam2 outside of the doors, similarly pointing down from above. Triggered/Instant. (Or Triggered/30 secs) Generator - Cam1 - Cam2 - Cam3 - Cam4 - Lights. Now, the order of the cams may be important, but one could try another order - depends on the coding, really. If the order doesn't matter, it's likely simpler to wire them from one end of the room to the other, but .. I can't guarantee anything - IS important. And corrected now. And for the relay cams, if needed: The idea is to have "unresponsive" cameras (either blind or just set to never react) as cord extension. The above with a 2 part extension between 3 and 4 would be connected like: Gen - Cam1 - Cam2 - Cam3 - Cam R - Cam R - Cam 4 - Lights. Cam R's are the "mute" ones. EDIT: mistakes were made, some repairs have been done

Yeh, base game should allow for a "blinking" 30 secs by: Cam - rel - light - light JaWoodle made a little hacky looking system to turn things permanently on and then switch off, using two cameras. Was mistakes here, see EDIT2. Cam2 - Cam1 - rel - light - light Cam1: Triggered and power duration "always" Cam2: Triggered and duration "instant" Cam1 turns everything on when it sees you once. Cam2 does as well, but it functions as a turn off, as when you leave its vision, the power goes off. For some reason the Cam2 will reset the Cam1. Point them away from one another so they don't see you at the same time to avoid confusion. You won't get the 30 sec delay, but you get relatively stable on/off switching. And some delay can be achieved by putting the Cam2 further away - but it's still not a delay, just your own two feet being slow. EDIT: The 30 sec delay Might work with Cam2 set to 30 secs, but it also might not reset the system at all. I haven't tested either setup, so I stuck to mainly describing JaWoodle's contraption. This is where he's setting it up, but he's using other triggers along the powered path as well, so it is a little more complicated in the vid: https://youtu.be/p7YycYA3Mc8?t=952 EDIT2: I have the cameras in the wrong order, the instant/always camera needs to be first in chain. I swapped cams 1 and 2 in the chain, so the text became correct.

I'm talking about sacrificing the majority of your damage to simply avoid a 1% bug. I'd rather not. If you can oneshot the @%$# with a bodyshot, you wouldn't opt for a headshot - you've changed the premise.