Jump to content


  • Content count

  • Joined

  • Last visited

About chambersenator

  • Rank
    Helicopter Hunter

Contact Methods

  • Website URL
  • Twitch

Profile Information

  • Gender
  • Location
  • Interests
    Day Z, ArmA, Blacksmithing

Profile Fields

  • Bio
    Old timer, been playing DayZ since April of 2012.

Recent Profile Visitors

10020 profile views
  1. Status Report 3 July 2018

    I would really like to hear more about where the devs are currently with: Hearing someone else's radio: Example: Player A has no radio, but is standing beside Player B who has a radio, and is talking on the radio to Player C (who is far away), Player A should be able to hear both sides of the conversation, not just what Player B says. Being able to turn a radio on, drop it on the ground, and any broadcast the radio picks up on the channel its set to can be heard by anyone near that radio. For me, those two aspects are essential for radios in DayZ SA. Without them, we lose out on so many different gameplay possibilities. Just to be clear, I'm not asking for those capabilities to be put in the game ASAP - it will happen when it happens. I'm just asking for some information on where things are with it, what differences there are with the new code vs the old, what challenges the devs have run into and overcome, and what still remains to be done.
  2. Basebuilding

    That reminds me of an idea I had ages ago for an improvised alarm as part of a mod. First, you need a wrench and a police car wreck, and remove the police siren. A car like that would probably still be using an electrically powered mechanical siren (like this). Easy to remove, easy to wire up to a trigger (a tripwire, a door, etc) and a car battery, and would create a nonstop, deafening scream until disconnected, and could be heard from the furthest distance possible. With the electrical wires that are coming with basebuilding, the siren and battery could be in a different part of the base (perhaps even a separate locked room), which means it may take a minute to be able to stop it. Scripting it should be fairly straightforward, with the trigger tied to the tripwire or the door's open/closed state. Since the door state randomization thing on server restarts could accidentally trigger the alarm, such a door would have to be locked to prevent that (the door state thing likely won't apply to player-made structures, this would only be a concern if the base is incorporated to a pre-existing structure, and uses one of it's doors)
  3. What is the difference between a trigger and a dynamic event?

    Yeah, but then you still can just hop outside the map border and be in total safety. Of course, you could put in that 'contaminated zone' thing, but then what's the point of having the infected on the border? Using the border to escape AI is one of those things that people can be against in general, but eventually a situation will come up where it starts to feel like "It's ok, just this one time. I've got so much invested in this. Who's ever going to know?" I don't know, it just feels like a solution that ends up being more of a problem than it solves. I'd much prefer a solution that does not accentuate a limitation of an unrelated part of the game. It's better have a solution that doesn't include a tempting option to exploit such limitations (the AI border limit) as sort of compromise in order to prevent a more serious exploitation (using the off-map areas for safe travelling in general).
  4. What is the difference between a trigger and a dynamic event?

    Alas, the AI can't cross the map edge as far as I know. I've seen people take advantage of that to escape wolf packs up near Tisy. I almost didn't want to mention it at all, as I see that as unsportsmanlike at best, and exploiting at worst, but knowing about it and using that knowledge to your advantage are separate things.
  5. What is the difference between a trigger and a dynamic event?

    Ah, I see what you mean. That is an option. I don't know exactly how to explain it, but to me that solution feels more artificial than going with something like making the areas outside the map cause you to take damage in some form, and just call it a kind of extreme 'contaminated zone' Whoops, I guess I got my SW and SE corners mixed up. 6 years of this game and ArmA, and I still mix those up. In any case, the devs have said many times over the years that expanding north and west just aren't possible. You're not wrong about the limitations about triggers outside the map borders, but I'm almost positive there IS a way to do create a forbidden/contaminated zone for the areas outside the map, and I think there was even an A2 mod that had it. Of course, the devs would be able to approach this differently, but if I was making a DayZ SA mod, I might do it this way: If I understand this right, you can do it in two steps. First, you place a long, thin trigger area a few feet wide all along the map edge, and set the action to start progressively hurting you when you enter that area. So as soon as you cross that line, the damage starts and doesn't start. Second, you create another, wider trigger area on the inside edge of the first one. That second trigger area checks to see if you are taking that 'outside the map' damage, and if so triggers a stop command for the damage. So it would kind of look like - - - - - map edge - - - - - - - - - - trigger 1 (start taking damage) - - - - - - - - - -- - - - - - - - -- trigger 2 (check if you are taking damage, if so, stop killing you) - - - - - - - - - - - - - - -- - - - - - It probably could be done with a single trigger, but I suspect having them separate would be a more reliable, fault-tolerant method to make sure everything works as intended. It's admittedly a hasty, slap-dash modder solution, but it is fairly straightforward and simple.
  6. What is the difference between a trigger and a dynamic event?

    Unfortunately, do to the way the map system works, it's not possible to expand to the north and west in any practical way. Everything on the map uses the NW corner as a reference point - loot, buildings, trees, rocks, water... everything, and the position handling code has a huge problem with stuff outside the map borders (as it's a negative value, and that causes no end of issues). You might then ask "well, why don't they just move the reference point?" Unfortunately, that ends up forcing you to pretty much re-make the map from scratch, then adjust every single script and line of code that involves, references, or calculates, position data accordingly. It makes the work needed to make a winter version of Chernarus look as easy as making one of those "hand turkeys" kids make in elementary school by drawing an outline of their hand and coloring it in, and maybe gluing some macaroni to it as well
  7. What is the difference between a trigger and a dynamic event?

    Infected "age/life cycles" is something the did some work on quite a while ago, and the devs have some soild concepts about how they want that aspect to work. You have to go back quite a while in the Status Reports to find them, but they have talked about it a good bit. It's quite possible that the reason it's not fully implemented is that at some point, they realized that to do it efficiently and properly, other parts of the code would need to be updated first, so it was put aside until later (like an improved handler for AI behavior, better ways to manage and track AI, etc). IIRC, there can be a 'middle' state for AI that is in between 'despawned' and 'spawned' that is a 'simulated' state (which has been in ArmA for a long time). This means their positions and status are saved, but they are not fully rendered into the game until they are needed. It's a far more efficient way of handling large numbers of AI on a map, without having to devote server resources to managing AI that are miles away from any players. That simulated state might have to be a bit more complex than the one in ArmA, so that it can save their state upon despawning, and when spawned again, their age/life cycle is adjusted accordingly (and adjust that depending on the time acceleration of the server, too). However, there are other challenges to this that need to be considered. If you only use the above system, you're stuck with a set infected population that might be huge when the server starts, but after a couple hours can end up with most of the infected removed from the server. So to balance this out, you have to add in a system that is adding in new infected, but do so in a way that doesn't end up making the 'age/lifespan' thing barely noticeable after a couple hours. So I think we'll be seeing pretty much what you describe down the road, but there may be other new aspects with infected put in the game before that is in that may significantly change/influence it.
  8. What is the difference between a trigger and a dynamic event?

    I agree that having bees and hives you can harvest honey from would be a really cool thing to have in DayZ. The fact that it would be tasty and provide some energy from all the sucrose and glucose it contains is far less important to me than its potential 'improvised' medical applications. Honey has at least some level of antibiotic properties, and could be used directly on wounds and dressings to reduce the chances of infection (which as time goes on, and the medical system is expanded to include more complex wound infection mechanics, could make honey quite a helpful thing to have around). While the bees themselves should only spawn around the hives in warmer months, making hives much easier to detect, but also trickier to harvest. In colder months, the hives would still be there, just a lot harder to find. As for the harvesting process itself, you could have the option of doing it the 'smart' way or the 'painful' way. The smart way would be to use a smoke grenade or torch that's had something to increase the amount of smoke it makes (hot lard maybe? oil? similar to how you can make torches last longer with pine resin right now) to make the bees calm down (it's not exactly how you do it IRL, but its close enough for DayZ). The painful way would be to just start cutting and harvesting, and deal with the angry bees, and the amount of damage/pain you get from the stings per 'harvest honey' action would depend on how much clothing covers your skin (perhaps using whatever system will be put in to handle 'biological' player damage when that is fully added to the game). It's certainly not a high-priority thing, but would be one of those nice 'finishing touches' to the game to see added in one day. Oh, and the other nice thing is, the models for the bees themselves already exist in ArmA 3, they'd just have to be ported over rather than made from scratch
  9. For the Mule in all of us

    To add to the list suggested human-powered cargo ideas for the future: ALICE pack option - ditch the pack, keep the frame The ALICE pack (IRL) is essentially has two parts - the pack itself, and the metal frame and shoulder/belt harness it hangs on (usually what's called the LC-2). If we were able to remove the pack, and keep the harness/frame, we could then be able to attach other large things to it instead using rope. What kind of things, exactly? For starters, an empty barrel tied to the frame seems reasonable, as well as a jerry can, a tire, or even a car door, too. As base building items are added in, it might present a more efficient method of transporting many larger items, or bundled collections of items (within reason), that currently can only be carried with two hands (and balanced out by the fact that you are trading off all your 'normal' backpack space in the process). As the weight/fatigue system is further developed, this could also mean that a barrel carried in this manner would not HAVE to be entirely empty, either. It could be reduced to a fraction of it's usual space when used like that (25-30%), but to access the contents, the pack would have to be dropped and untied in some manner, and take a bit of time to do, preventing players from quickly accessing the contents. Wheelchairs (something for much further down the road) Have a friend with a broken leg or unconscious? Have a prisoner (conscious or not) you want to move around in (reasonable) safety? Just put them in there (via their own power or by carrying/dragging them into it), use rope or handcuffs to secure them to it (if necessary, with the confined player needing a longer time to escape, and have an animation along with it to make such actions much more noticeable), and wheel them away. Admittedly, this would be tricky to code, and the wheelchair should move/handle incredibly badly on any non-paved surface, and would require the ability to carry/drag players in the game to make it worth spending time on, but certainly would offer a lot of interesting possibilities.
  10. Are wounds and puddles still coming?

    Interesting. I'm really looking forward to seeing how all the new code will open up all sorts of possibilities that have not been so easy to do with the legacy code. It will no doubt take me some time to adjust my mindset to that, and not have to think of things in terms of a series of fights/workarounds vs. the old legacy code.
  11. Are wounds and puddles still coming?

    It's important to separate the different blood-related elements into groups based around what parts of the code are involved, as each present different challenges to the devs. The player model showing the location and number of wounds. The current 'fountains of blood spewing from your body' animation Blood trails and pools of blood on the ground/terrain/floor. #1 seems like something that seems reasonably achievable, even if it's just limited at first to a generic set of bloodstains and wounds appearing on the particular area that's been hit (limb/torso/head). As time goes on, a greater variety of wound types could be added based on the particular item that caused those wounds. For example, someone killed by an axe or sword might look different than a gunshot wound, or a visible difference between someone shot in the head vs. someone who decided to do so themselves. #2 certainly needs to be addressed, and it appears the devs are working on something to replace it. #3 is something very different from the others, and perhaps the most challenging one of them all. Instead of a change to a particular part of an existing player model, or an animation attached to it, pools and trails of blood are things that would have to be placed into the game as a separate object (for the pool) or a series of separate objects (for the trail). That's a lot of new stuff for the server to spawn, despawn, and track that it never had to before, no matter how long the 'lifespan' of those things are, when you consider that even if the client has to only handle the blood within X meters of the player, the server has to handle it across all clients on the server. If a workable solution were to be found, this also would offer a way to handle other things like tracks and footprints in the snow from players, vehicles, and wildlife on maps with snow. We do already have a very limited form of this with vehicle trails, and back in the A2 DayZ Namalsk mod, those invisible Bloodsuckers would leave tracks in the snow, but they only lasted a few seconds before disappearing. However, I suspect that those methods may not be feasible ways to go about handling blood pools and trails.
  12. Heavy rain.

    I am fairly sure that's not how the devs want it to be either. The reason why it is the way it is now - with a single, all encompassing 'humidity' value for the player - is due to the limitations of the legacy code (the last of which will be gone with .63). So while each item of clothing has it's own absorbency/water resistance values, and combine to slow down or prevent the humidity value from increasing, once you hit damp, wet, soaked and drenched states, every clothing item you are wearing or pick up, and their contents will change to that state (except of course stuff that is already waterproof and their contents). Another unfortunate side effect of this limitation is that if you are wet, and go inside a building and change out of all your wet clothes and put on dry clothes, you, along with all those dry clothes, are wet. While we do have the option to "wring out" clothing items if we take them off, empty their contents, and put them back on seems to have very small effect on helping you dry out, the rate at which your temperature drops until the fire is going, combined with the rate that a fire drys you makes wringing out clothes a fairly pointless act right now. I wouldn't expect we'll see this system to replaced when we get our hands on .63, as there are many many higher priority things for them to tend to first. However, the new player controller should remove many of those limitations from the old system, giving the devs the ability to rework that aspect of the game. Since the whole wet/dry/temperature aspect will play a significant role with the stuff they have planned for the addition/expansion of the infection/disease system (influenza, the common cold, etc), it's not unreasonable to expect the new versions of those two elements of the game to be added to the game together at some point after the more important stuff is in place and working with .63 .
  13. I'm all for bullet penetration mechanics. A heavy canvas tent should offer no ballistic protection at all. If I know someone is either inside or hiding behind one, I expect to be able to fire through that tent and hit them if I correctly guess where they are (and not make it ridiculously easy by going outside the render distance and seeing the hiding player). The current state of the model penetration overall needs improvement, but that's to be expected when we're dealing with a mix of old A2 building models and newer models (for example, there are certain buildings where shotgun pellets cannot penetrate windows from either side, but all other weapons can). That's a known bug, just like how sometimes buildings like the police station sometimes don't entirely render when you walk through the front door. The tent render distance is a different thing entirely - it's been set at a specific range for a specific reason (which I assume is to reduce lag in certain situations), but has an unfortunate side effect of being able to see through them at long distances. As for the 'obstacle check' you mention, with people being able to shoot through bugged, unrendered building walls (that unlike tents, would stop a bullet), I'm cautiously hopeful that the code that is designed to prevent players glitching into buildings in .63 may also prevent that penetration issue from happening. What I am really curious about is the different factors that combine to create that need to limit the render distance of things like tents at both the server and client end of things in the current version, and how the upcoming patches will address issues like these. It's not just an idle curiosity either - understanding how the new engine approaches these problems differently than how it was approached with the legacy code will help a great deal when creating mods for SA.
  14. My plea regarding modding and the release of server files

    I really don't think you need to be so worried. Yes, mods will be made that will go against everything you hold dear about DayZ. They will be very popular, filled with people who are looking for, and getting, the exact opposite of what you value and love about DayZ. I'm not looking forward to seeing that stuff either, as we probably value many of the same things in regards to DayZ. However, I see no point in blocking everyone from modding DayZ in order to somehow keep DayZ 'pure.' In fact, I welcome them to come and create whatever abominable, horrible mods they can come up with. Bring on the 24/7 day mods, NVGs and thermal optics for all, and the 'pick your spawn point' options, and spawn everybody with an RPG, M249, and a tank. Let them bring over all the ArmA 2 and 3 assets they want, and bring over the maps and converted scripts, too. They'd all be 3rd person servers too, of course. I'm sure if they could, they'd invent the concept of 4th person servers just because 3rd person is just too limiting. Why do I want this? I'm certainly not going to be one of the people playing on those servers. I'll be having fun on the servers that are populated by people who want the same things out of DayZ that I do. The hardcore survival, the 1st person only, the servers that push for realism and make the game harder because they want the challenge, with the full spectrum of KoS, to PvP, to RP, whatever the situation calls for. The servers that are whitelisted, well-admined servers to keep out the riff-raff, scripters, and griefers. Servers that require you to put on your big-boy pants, make a torch, and deal with finding a single can of food on a moonless night while you are starving and freezing to death. And with mods available, I can get even more of that kinds stuff I dig. And don't forget, we can also benefit from the work put into all of those other mods, too. All that porting, converting, and scripting means more stuff to use for mods targeted to players who want to stay close to vanilla DayZ's intent, but wouldn't mind some extra stuff too. That's where I'll be, having the time of my life. Seriously, why worry? If a server is running mods you don't like, and would never go there, who cares if it's empty or full? Who cares if there are 5 or even 10 times as many of those servers than the ones you like? How many servers do you really need? With the people that are waiting for beta return, do you seriously think NONE of them will want to play on servers that value the same things you do? Modding is how DayZ was created. It's going to be OK. You'll see.
  15. Note to mods: I'm posting this here rather than the bugtracker as it's not really a bug to be reported, it's working as it's currently designed, but with unintended consequences. Also, as this post doesn't contain a suggested solution, but is for discussion of possible options, this seemed the logical place to do this. The render distance for tents has a problem. As I understand it, if someone is beyond the view distance of a tent, it's invisible to them, allowing them to see and shoot anyone inside or behind the tent that they obviously shouldn't be able to see. The obvious solution would be to increase that render distance value, but I've been around ArmA and DayZ more than long enough to know that 99% of the time it's never that simple. If it were, it would have been set to match player view distance from the start. This distance was chosen for a specific reason. I would assume the reason it's set so low is related to the lag we often encounter when multiple tents and barrels are nearby. It's a symptom of a larger issue, and this is a way to minimize its effects. If that's true, the current setting is a reasonable temporary solution - frustrating a times, but reasonable. If my assumption is wrong, what is the real root cause? What would happen if the distance was the same as the view distance for other players? Is the problem more of a client-side or server-side issue? Is it related to some attribute about containers specifically, be it anything from protective cases to vehicles? Or is it simply any object that isn't a player, an AI, or part of the map? I would assume that even if the model is not rendered in, the server obviously knows it's there, and at some level the client probably knows it's there too, likely well before it actually renders when the player gets within range. When it comes to unmoving, player-placed objects, what is the difference in workload for the client when that tent is inside the overall object view distance range, but just outside the preset tent render distance vs. inside the render distance? With the advances and optimizations that we will start to see with .63 and continuing onward, in what ways will it address the wider issue (whatever it may be) that necessitated the lower view distance that were not possible and/or practical with the old engine? It seems logical that this draw distance issue would have to be resolved for base building to be even remotely usable. Even if that newly built wooden wall or barricade can, unlike a tent, stop or at least slow down a bullet, having your entire base look like it was made entirely from parts salvaged from Wonder Woman's invisible jet from 500m away is not exactly ideal. I know that many of those questions can only be fully answered/explained by the devs. If they find a moment to do so, great! If not, I hope that they might perhaps consider using this in some form as an example in a Status Report in the future for showing how the new engine is able to handle a problem like this in ways the old engine couldn't.