Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

9 Neutral

About Darinth

  • Rank
  1. TL;DR: The controller's purpose is to guide the rest of the horde to you and aid them in combat. It does not engage in direct combat, but instead finds a high location where it can focus on the player and guide the rest of the horde to you. Mechanics: Spawns at a high location, capable of climbing walls but not leaping like the spiders. Once it spots it's target, it locks on to them. When this happens, the player should get some highly visible UI effect (such as an overlay of the zombie's face or similar) so that they know they've been found and targeted by a controller. Targeted player receives an exponentially stacking debuff that increases the damage they take. Starting off at 25% increased damage and doubling every 10 seconds. After 10 seconds it'll be 50%, after 20 seconds it'll be 100%, after 30 seconds 200%, etc... The goal here is mostly to make sure that even for tanky characters this isn't a party boon. It may be beneficial during a blood moon to let a tankier character keep the debuff for a little while... but after just 1 minute, they'll be taking 16x damage. The controller forces retargeting of AIs to their target. If there aren't nearby zombies for them to control, they will summon more similar to screamers and force them to target their target. So the horde is going to go after that player. Cops will spit at them. Vultures will go after them, etc... Finally, the player's vision is constantly being drawn towards the controller. This is both positive and negative. Certainly nobody wants their aim being messed with, but it also makes it fairly easy to find the controller. Just move your aim to follow where it's already being drawn and you are guaranteed to eventually be aiming directly at the controller's head. Useful during a blood moon when night visibility can make it hard to find the loan zombie who isn't moving. More advanced variants could do things like pull your vision towards it, but never actually on to it, pull your vision towards it, but push your vision away from actually being able to aim directly at it, push your vision away from it entirely, cause increased hunger or thirst when it targets you, or other effects.
  2. I would absolutely love to see multi-part blocks implemented. It's one of those consistent frustrations for both myself and some of my other players to be able to put bars on two sides of the same block space. It's probably my personal priority 2 as far as 'things that just need to be here for basic game functionality'. Priority 1 is multiple people being able to access a chest at the same time.
  3. This is actually a specific topic that I want to talk about. Voxel-based games can support multiple voxels in a single block space, the minecraft modding community does it via various multipart APIs. Unfortunately, based on previous comments you (I think? maybe it was another dev?) have made, it would probably require block entities that require individual draw calls which are inefficient. It basically requires one block that acts as a container for the other blocks and some mechanics that control which blocks can simultaneously occupy the same place. Means you can do things like have a block that has bars on both sides and a satchel in the middle.
  4. No it isn't. It causes problems with wanting to move the LCB for legitimate reasons. A better counter is to remove all decos above the old limit when a new one is placed at a different location, but even this causes issues. 4 people can claim 4 adjacent areas and pump a huge number of decoratives into a single chunk by placing all 4 lcbs such that they meet in the middle of a chunk. Depending on the complexity and technical requirements and limitations, it's feasible to pump so many objects into a single chunk that as soon as someone walks into distance to allow the chunk to render... the game crashes due to graphics memory limitations. Not 'has poor performance', just outright crashes. I don't unfortunately know enough about the technical limitations 7 days is on. I've written a simple voxel-based engine, but sadly I never got it to do a lot of the cool stuff 7dtd can do and eventually ended up giving up on it. Hope to pick it up again some day... but it's too much work for a single developer. At least for me.
  5. Lets be honest Gazz... when modders make it and terrible things happen people are gonna yell at you anyways. 😛 Not supporting the idea the you need to make these assets available for player placement, just making fun of the average gamer's inability to recognize that performance issues caused by mods aren't really your guys responsibility.
  6. I've been running a vanilla server with a half-dozen+ people for over a month and nobody has complained about disconnected cities or any particularly terrible world gen. Some road intersections are a *little* messed up (terrain goes up or down in weird locations) but... overall it worked pretty well. I may try a nitro-gen for my next run after A19 goes to stable, but the vanilla world gen certainly doesn't seem to be as horrible as you make it sound. It does take forever and a day though... (40+ minutes to generate)
  7. And after doing a little more research and looking through the XML , I've realized that the reason I had behind manipulating the time isn't actually valid. I thought that gamestage was based on world time partially. So my goal was to keep the world time from going too far forward. Now that I know (per the xml) exactly how it's calculated, I've realized that I can just safely leave the time alone and turn blood moons on/off as I want (for my group, that's likely to be a set schedule. We like the impending doom that is an upcoming event that if we don't take time to prep for will murder us, but we also like to be able to log on and play whenever). Given that... most of this topic actually seems kinda silly now.
  8. Week 2 of multiple blood moons very successful. No issues with the blood moons themselves. It's pretty easy to turn them on and off. Issues with the game in general: If the game moves forward to x day and you move back to y day, many of the spawn mechanics can get @%$*#!ed up until you make it back to day x. No supply drops. We had little-to-no zombies spawning just roaming around. Screamers and hordes stopped spawning in response to heat. It was a little disheartening. The trader inventory can be refreshed manually be switching into debug mode and using the admin option to force a restock, but that's at best tedious. It's mostly acceptable... but I'd really like to have a way to fix these issues, which at this point means looking further into the modding API.
  9. I get so much insight just into where the game is going by occasionally skimming through here for the dev posts.
  10. The point that Gazz makes above about some weapons may be weaker if looked at in isolation, but that they come as part of a particular package is really important. All of the weapons don't actually need to be (and I'd argue really shouldn't) be balanced against each other. They're each part of various sets that you get for specing down a perk tree. Maybe knives and bows are weaker in a one-on-one fight, probably not the best option for a character designed to stand toe-to-toe with creatures on a blood moon. But they're a park of agility, which gives you the ability to stealth through POIs and complete fetch quests sometimes without ever killing zombies. When you do need to kill them, you can frequently kill a zombie in a room with another zombie, walk through that room and might not ever realize the other zombie was there to begin with. Because it also never found you when you missed it. I promise you my junk turret's 'ttk' is lower than what my friends get with shotguns or rifles. I can drop my pair of tricked out turrets in the room with 5 zombies and drop my friend in a room with 5 zombies and a shotgun with relevant perks and he'll clear out the zombies from his room and come finish mine off. But the junk turret's ability to stagger a bit on every hit and continuously auto-target the closest zombie makes them an indispensable aid on blood moon nights to keep the zombies from swarming up the ramp too quickly. Combine that with the intellect tree's reduced forging costs and faster crafting time (which can add up when you start crafting bulk amounts of all sorts of materials), their ability to choose up to 2 of 5 quest rewards (as opposed to 1 of 2), the increased dukes that they get, etc... and I'm certainly not going to call it 'OP', but certainly I don't feel like I'm so far behind that it's not worth it.
  11. A good bit of luck manually using commands from the console to enable-disable blood moons on demand. We had our first set of back-to-back blood moons today. 2 in a row. A minor glitch that I think at least in 1 case was the AI glitching out. Console showed all 40 zombies (5 of us, 8 zombies each) were spawned... but nothing was assaulting us the second blood moon. Reset time, zombies unloaded, and when the blood moon came around again we were gold. The only major issue I've ran into is that since I'm not always around and am currently manually reseting the date from time to time, the trader restock date is actually a week+ into the futurebecause that's how far the clock had gotten. Don't know how to resolve the restock date issue. Also, trader jen has fallen into the floor. But that's a different unrelated issue. lol.
  12. I'm curious if there's a way (either within a setting, which I doubt, or if the modding API is strong enough to do it) to decouple the day/night cycle from the in-game 'date' and instead tying it to real world time passage. Example: Tying each in-game date change to real world date change, without affecting day-night cycle. The game would still cycle through day and night normally (60 real world minutes to 1 day) but it would repeat 'day 1' until 1 real world day has passed, at which point it would continue on to day 2 until a full real-world day has passed, etc... My goal is to give players more incentive to want to spend time playing the game and not to have to limit play time to when most players are able to play so that we're not wasting the precious in-game clock between blood moons. So that people can log in and play as much as they want, and should generally be rewarded for doing so, knowing that say every tuesday... we're going to have hordes to survive. And I'm fine (in fact think it'd be really cool and interesting) if literally every night on the real world tuesday we had to deal with a blood moon. I can, probably, do most if not all of this by manually doing things like changing the blood moon frequency on tuesday to be 'every day' and otherwise turning it off and resetting the time from time occasionally. I might even be able to automate it by writing a program that will connect to the telnet port, and change the game parameters at appropriate real world times. I seem to recall running into an issue with the game not liking the idea of repeating blood moons that have already been passed (so once the day 7 blood moon has occured, it can't occure again even if I reset the time to day 7 at 20:00 and wait for it to continue on to 22:00) Does anybody else have good ideas to make a setup like this work?
  • Create New...