theFlu

Hi. Paranoid yet?

Not DEADLY, just a decent grasp of the difference between a hashmap and a proper index; and an educated preference for one of them. But I'm absolutely willing to leave it at that.

Well, now that you said that, I went and checked my game - I wasn't sure if the "self" setting of the motion sensor would recognize the vehicle. Seeing the vehicle instead of the player would be a plausible source for issues, but I'm happy to report it seemed to work fine. Solo game, so the vehicle was placed by me - who knows, ownership might matter...

Cool, that's a respectable start for a career. No snark. Without going into any actual detail, I completed my first software project for a defense contractor .. oh geez, what, 19 years ago? I might be getting old. A little database, nothing fancy, but still. Kinda points to our differences here as well. You're used to the mechanics provided by a game engine, willing to defend them, maybe a little overzealously, but clearly with a decent understanding of them. You're just using the jargon just imprecisely enough that I can have a little amusement by poking at the misnomers. I haven't done anything serious on a game engine, ever - although I might question if anyone has. You know, "serious". And with a little snark: I wouldn't dare to try, dear.

Well, it can work, as long as the lights after Bank2 end up taking up the power first - but nothing is guaranteeing that. With the electric system occasionally being unable to decide whether a component is a Trip Wire or an Electric Fence, I wouldn't trust a "loading order" to remain static for any period of time; which is sorta why I proposed that other loadout, it has a better chance of being stable as it's all in series. And literally, it's ALL in a single series: Bank1 -> cam1 -> cam2 -> light -> light -> light -> light -> light -> light -> Bank2 -> Door -> Door -> Door -> Door -> Door -> Door So, while you Can connect several things outgoing*, you don't want to in this case. *at least from Relays and such, I'm not entirely sure about cams, but I assume so. The first door takes 5W to work, so I think you'll need to hit 1 to 4W coming to Bank2. 5W seemed to randomly bug it out. As those lights are 5W each, you may need something else to hit the 1-4 gap.

(Dear Santa, I guess I do deserve my coal this year - please deliver it to the nearest power plant in need, they seem to suffering. But I'm sure you understand! Your's truly, theFlu) So, the first step for indexing by name is to rename everything? So the name can be a unique identifier. Fair enough, kinda necessary, but.. - So, Timmy_1237987, we're naming things as [Name]_[UID] here? - Yeah, sounds about right. Why? - Well, we need to be careful with that UID part, it can't have collisions or concurrency issues or any of that nonsense, right? - Yeh yeh, that's all trivial, industry standard. Especially simple in a game that runs on two threads. - Soo, we can generate all the UIDs we want? - As I said, barely an inconvenience. - Anything stopping us from, you know, dropping that pointless dozen character string from the front and just using a 4 byte number there instead? - Well, then we wouldn't be indexing by name, now would we? - Indeed, dear 81237987->name, indeed.

Quoting a randomish section.. I ended up testing that version of mine with everything in one chain, and I got it working. Basically: Bank1 (41W) -> Cam (5W) x 2 -> Light (5W) x 6 -> Bank2 (100W) -> Doors (5W) x 6 I had some issues, I couldn't get it properly stable with a 45W Bank1 and lights. One door was doing its own thing. That issue stabilised with the 41W watt bank. The chain drains 40W, so it happens to deliver exactly 1W to Bank2 when activated. That seems perfect to shut Bank2 off while powering as little as possible past it. Basically it looks like "charging" bank 2 doesn't actually cost any power, so the 5W extra was enough to open that one door. Might be worth giving the idea a try.. at least it makes sense this way... Also note, I earlier mentioned turning lights on/off to adjust the power.. seems that my lights were draining their nominal power even while off, so, might wanna verify that. I was using the Industrial Light Bulbs. I edited the above.. EDIT: for a little clarity.

I'm going to let you edit that to include the "what are we trying to solve" part first; and then I'm going ask, "What is this, a job interview? You hiring? No thanks."

Yeh, it's been requested a few times in the past, seems it's not going to happen. Too bad, I wouldn't mind it, this one would be worth some dev time. Although, the sorting buttons made it a lot less of an issue, as you don't need to stay in a box for ages anymore. Add some crafting-straight-from-boxes and it stops being an issue altogether - which might be just as dupable of course, but at least exists as a mod now.

That sounds like a binary tree with words as values, no? "Word tree", afaik, is a net for predicting sentence structure, which would be pretty "irrelevant" here. May well be used for both of course.. But that still doesn't tell me what you're trying to solve with them; it seems you're just arguing against my "you don't index by name". What was the problem that would require indexing by POI name 1) for this feature 2) that isn't already solved in the game somehow? (quest system already knows what the POIs are, the damage tracking is missing, but doesn't have the POI name to begin with) (And I said "you don't index by name" because you don't - values on a tree aren't indexes, the structure of a tree doesn't have indexes. That's why you need to seek in it to find the value. Sure, C# calls some such structures "indexers", but they're free to be silly, sadly. You might want to listen to them, I might be a purist, but hey... they can also be wrong... )

Umm, I know, but welcome to the world of internet forums, where people don't mostly stay on topic I was just adding some possible context to dough-boy's comment, my doing so indicated by my quoting him to reply ...

Depends a lot on how you imagined they should.. The one significant difference a relay does cause is to turn an OR relationship between triggers into an AND: 1) Cam - Trip wire - Dart trap 2) Cam - Relay - Trip wire - Dart trap 1 will fire when either the cam sees something OR the wire is tripped 2 will fire when the cam sees something AND the wire is tripped Basically, the powerless relay in 2) won't give power to the Trip wire, while the (powered but not triggered) Camera in 1) will.

I haven't tried the trick you're trying, only seen it that JaWoodle experiment, so, hefty grains of salt here. That said, I think that trick relies on the fact that a Battery Bank will not provide output power while being charged. It only passes through the power that is being fed to it. So, connecting the BatteryBank1 to the BatteryBank2 (via the cameras), drops the 100W Bank2 power entirely out of the equation. If that's how it works, I would try something like: Bank1 -> sensors -> LIGHTS HERE -> Bank2 -> Doors You're trying to overload the Bank1, so sensors + lights + "Bank2 recharge requirement" should exactly match Bank1 capacity, so the Bank1 can't provide any beyond Bank2 charging. Turn lights on/off for easy adjusting. This of course assumes that the powered components are activated in the order of the connections, I don't think that's an entirely flawless assumption, but it's the best I got.. And yeh, I haven't even tried it in vanilla, and you're playing an overhaul.. might not apply. At all. EDIT: lights might not work as adjustments..

You can do vehicle-detection with at least cameras and trip wires, I haven't tried trigger plates but I would be surprised if not. For cams & wires it isn't even really different from walking detection, I haven't run into any vehicle-specific issues with either. You may have been bugged.

Yup, but since the bedroll check already exists for questing, this feature wouldn't complicate that at all, as it wouldn't even need to touch that. If you are able to index by name then why was it your counterargument earlier? (Same preset, same name -> problem) I may have missed something there. There's also a decent chance that there already exists a suitable data structure to glue this one on. The quest system knows the distance to every quest POI - the way it chooses the closest/suitably distant POIs for questing requires location info. You could get away with a pre-calculated distance for that, but you'd have one of those per trader. Word trees? How many separate entries for "irrelevant" will you find in a word tree?

The horde nights take me straight back to high school... Oh, right.. nevermind!

I think you're right, not an xml setting for that as far as I know. Then again I know basically nothing about modding ... the people who know more may well hang around here on General, but they have their own little hidey hole somewhere around there: https://community.7daystodie.com/forum/27-mods/ They should know better ...

Yer welcome That two-switch idea is simple enough to describe as text, but might be hard to grasp from text, so I figured I might as well do a little backyard demo of it: https://odysee.com/@theFlu:d/doubleSwitch7dtd:d

The explanation is quite understandable, but I guess that's where the good news end. There's no proper way to achieve that in vanilla. The best automated solution would be to overpower a battery bank when a camera sees you - but those are really iffy, they may break on login or even chunk load. (Add just enough batteries to keep the doors open, then add a camera with enough traps/lights/other behind it to go over the output limit) Switches will have the obvious issue of not being able to operate it from both sides. Maybe you don't need to but it's not great. A trickier solution is to build your own switches from relays, that would require using a wire tool to switch. Rather far from automation, but you can achieve two points of switching like that. Basically two sets of three relays ... first one has power coming in to one relay, then two "outgoing" relays. The two "outgoing" are connected to the other switching site to two separate "incoming" relays (one outgoing to one incoming). The 3rd relay at the second site is an output-relay. At the first site, you connect the wire from the power side to one of the in-between lines, and then on the second site, either of the incoming to the output-relay. If you swap the wiring at the first site, you break the circuit there, but also enable the other end to switch it back on by powering the other line. At the second site, there's always a powered relay to connect from, so you choose based on that. Not ideal, far from it, but ... workable. Ish.

Really? Ok, fine. What? A list of integers, one per quest POI, indicating an approximation of the total damage done to the POI. Could use any other data structure if applicable, but for the worst case scenario, a simple array with a lot of zeros on it. You can also trade runtime for memory and implement actual lists/trees, or whatever. What other use should there be? Chunk loader checks for POIs by their coordinates in the chunk, marks them active. Any destroy-block-event checks active POIs against its xy-coordinates. (peanuts-level additions to chunk loading and SI-checks) The existing quest handling already avoids bedrolls, you want to add something there? You don't index things by name. Ever. Too hard? Not really as such, but I agree, I don't see the feature worth implementing even if actually saved programming effort. IMO it wouldn't really fix anything; like I already said.

Login Rally reset.. I would guess that's about resetting the quest if you logout during one, not about resetting the POI. Could be, but .. would the quests even really work without a POI reset?

I can commiserate; I like to build bases, and for co-op I mostly play with one friend who, well, doesn't. Not a huge deal for me, I scratch my building itch in solo games. To offer an idea that might help, maybe try building a small base inside/attached to the chosen sacrificial POI. Spend a day on it while the friends do their thing. Have a good fight, and a safe fallback to wherever they're AFKing (just make sure when your base fails it won't compromise their AFK, that'll upset people). Bring plenty of boombooms since you'll have a multiplied horde, plenty of yellow bags to show for it after the night ...

Keep a list of integers for all quest POIs on the map, increment the number for that POI whenever a block is destroyed in the area. Basically O(1) operations all around, and a reasonably small array of numbers to keep track of. Swap the offered quest type based on the number.

I get the idea, but what are you trying to fix? PvP servers having players who play nomad with the hordes? Friends not willing to build horde bases as long as an exploit exists? If just friends, there's too many POIs in the game to ever really run out anyway, so the fix wouldn't fix much. If PvP.. I dunno, I don't play PvP here, but I'd imagine the advantage isn't that big? Plus you're risking getting players on your poorly defended location.

You're asking for a trailer for your vehicles I suppose? I may be confused as "the old semi" doesn't sound like a vanilla thing, unless you're talking about the 4x4. If so; no, there isn't anything you can tow with a vehicle. Could be fun for moving days, but I don't see such being on the road map for TFP.