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

10325 profile views
  1. Thanks, that shines some light on a number of gray areas for me when it comes to how the process was/is handled with custom ArmA assets, as my perspective on those aspects of it varied between "from the sidelines" to ""from out in the stadium parking lot." After years of messing about with missions in ArmA, this will be my first serious attempt at making my own mod, and I' have no desire to hide my 'modding noob badge,' and all the mistakes and a bit of naive optimism that comes with it. Everybody's got to start somewhere, of course. I'm up for the challenge of figuring all this out - "getting in over my head" is one of my favorite ways to learn stuff. Eventually, I'll learn the ropes, though a combination of tripping over them, getting tangled up in them, and occasionally being shown them.
  2. Duly noted. I know I need to tread very carefully here, as I have done a good bit of freelance graphic design and IT work in the past, and I do not want to dance right into the "do this for free for the exposure" minefield. I hope you realize that my intent and reasoning behind this proposal was about having a collection of small,very basic, common items that could be useful across many different mods, made and submitted by those with the desire and skills to do contribute to it. I was picturing something along the lines of "requested assets: a piece of coal, an old coffee can, a candle, a jar of honey, etc" and if someone wants to help out and make it, cool. I'm NOT talking about "I need an extremely detailed model of a wrecked and rusted MiG-15, or a ArmA hilux pickup truck with a tow winch in the back so I can have a tow truck mod" and expect everyone who has the skills to spend dozens and dozens of hours on it out of the goodness of their hearts at the drop of a hat. Also, I would assume there's nothing stopping someone from sharing a basic, lower resolution model of something freely, and adding "if you're interested in something that's much higher quality version of this for your own mod, let's talk," IF that is something they would be open to doing. I can understand why some people would not be interested in such a thing, and I have no problem with that. I also could understand why some other people would be interested in contributing for no other reason than they want to.
  3. Now that we finally have a modding section for DayZ SA, I'd like to suggest something that I've been thinking about for a long time now that could be helpful to us all. All of us that are interested in modding DayZ have vastly different levels of experience and areas of expertise. Some of us here are very familiar with modding ArmA in the past, some are completely new to it and eager to learn, and the rest are somewhere in between. As we get closer to the new modding tools to be released, I think it would be a good idea to create a dedicated sub-section of the modding section, focused on two things: A place for anyone interested in modding to introduce themselves, and include some basic info about their skills and any past experience with scripting, modeling, mission design, etc. in ArmA and other games, or for those completely new to DayZ modding, what particular aspects they are interested in learning. This could be very useful to help the community overall, by having a place where we can get to know each other's skills. For example, someone who feels comfortable with writing scripts, but has no modeling experience can find those who are good at making asset models and may be interested offering up their skills. The easier it is for us to know who's out there and what they can do, the greater the benefits to us all. An "Asset Exchange" thread or section, and the idea of a "Community Asset Pack". People can post a request for a certain item or item to be made, and if there's a modeler that wants to make it, they can submit their design for consideration. Ideally, those submitted assets could be made available to all modders, so that we can reduce the chances of us having 10 slightly different versions of some basic item (ex. a opened tin can, a handful of wires ripped from a wrecked car or home appliance, a liquor bottle, a brick, etc). Of course, there will be some very work-intensive stuff that some modders would like to keep to their own mods (vehicles, firearms, entirely new buildings, etc), but I'm talking more about about the (relatively) basic stuff here that would be useful in many different mods. Additionally, we could have links to BI's wiki pages that list existing ArmA assets, so that people don't waste time making something from scratch that could be just ported over. The goal here is to avoid wasting modeler's valuable time by letting them focus on different things, rather than duplicating things whenever possible. As time goes on, it would be possible for assets submitted to that part of the forum section could, with the permission of those modelers, be compiled into a "Community Asset Pack" mod through the Steam workshop either as a single mod or broken into 2-3 separate categories (environmental, structural, or miscellaneous items), and updated every month or two. As for who would be the one responsible for curating/compiling that and the general logistics of handling that, I'm open to suggestions. Figuring out the process at first will be tricky, but I think the potential benefits of it is worth seriously considering. (In many ways it's similar to the CUP mods in ArmA as the end result, but what I'm focusing on is how we can create a submission/compilation process that has the best chance to draw in new talent as well as have the support of those with a great deal of previous experience in ArmA) Just to explain a bit about where I'm coming from with this and why I'm making this suggestion: I've got my own plans for a DayZ mod that I've been thinking about for a coupe years now. I've dabbled here and there with mission designs and taking apart PBO files over the last 6+ years in Dayz and ArmA to understand how they work, and observing in particular how DayZ's new code has been evolving over time. I feel reasonably confident that I can make the core concept of my mod work, but when it comes to making a small number of fairly baisic asset models for the various little additional things I'd like to have in the mod, I'm going to need to find someone that would be willing to help with that. I have no doubt there are many other people in the same situation, so why not propose something that might make it easier for everybody?
  4. Stress Test vol.41

    If you're just comparing the states of the exp and stress branches right now, calling it 'redundant' is not entirely wrong. However, that's only because these server performance issues have delayed the exp pushes and blurred the lines. If you look at the custom spawn config options for the stress tests (custom loadouts, all spawning within 1km of each other, etc.), the differences in intent and purpose is more clear, and the continued focus on pushing the servers to the limit in "survival mode" to solve these damn bugs ASAP, the stress test branch is doing exactly what it should be for. Once the crashes and kicks are resolved, this will go to exp, and things will return to normal. Until we hit 1.0, "stable" should just be thought of as "reasonably acceptable for general use with the current feature set, and monitored for bugs/exploits/issues that were not seen during experimental testing," that allows the devs to focus on forward progress rather than maintenance of the stable branch as much as possible. After 1.0, the stable branch should take much higher priority (I guess a better name for it at that point would be "public branch," or something along those lines), and the exp branch taking a more secondary role for testing sets of fixes and additional content. Of course, that's just my understanding of it. While I don't work in programming, I work in an area closely related to it, so while my terminology may be wrong, I don't think I'm that far off base
  5. Stress Test vol.41

    Just finished a 5-hour session with this patch with a friend, the first half was on NE 2-1 and the second half on NE 2-2 (for reasons I'll explain in a moment) Lag/desync - Almost none at all. No issues with door states, no rubber banding for me or the person I was playing with, no issues with infected movements or following my position after aggro for melee, etc. The only things I encountered that may be lag/desync related is that I was often having issues with reloading magazines and crafting an improvised backpack. Often, but not always, the reloading and crafting actions would start, then immediately finish without performing the intended action. When this happened, it would usually require 3-4 attempts before the action worked properly. I don't know for sure that lag/desyc has anything to do with that, but I could see that being a factor if the action procedure has some form of sanity check/monitor in it that requires some form of verification with the sever that the items being changed/removed/created are legitimate. Server Notifications - Impending restart notifications were very unreliable. Sometimes the messages were completely incorrect and the actual restart would happen half a hour later than announced. Other times it appeared as if they would give a 5-minute warning message, then after 5 minutes they would still be active (meaning one would think this is another false message), only to kick everyone off about 3 minutes later. Random server kicks/kick loops - I was only randomly kicked maybe 3 times in that 5 hour session, which is significantly better than in previous patches. Only once was I kicked repeatedly upon re-joining the server, and at that point we switched from NE 2-1 to NE 2-2. The only times we were kicked from the second server was for server restarts, but other than the frequent lies the server was telling us about impending restarts that I mentioned above, things were fine. Animal/infected AI and fruit/mushroom spawns - I expected the spawn rates for these would be extremely reduced and that it is intentional to primarily help find the causes for the performance issues. The range at which infected spawns are triggered by player proximity felt like it was reduced even more compared to the last patch. In 5 hours, starting a Nizhnoye, and passing through Dolina, Polana, Gorka, Severograd, Kamensk, Stary Yar and finally Tisy, we found one pear, one apple, and one mushroom, and encountered one domestic pig and a herd of 5 goats. At Kamensk, we found evidence of wolves, in the form of two separate stacks of 10 wolf steaks left by another player. Overall Loot Economy Observations - 7.62x54R ammo seems excessively rare. The only places where we found any at all was in Kamensk and the summer camp just east of Tisy. UMP mags, as well as the UMP itself seemed unusually high at any structure with military loot spawns. Stary Yar had quite a few P-07 pistols. Otherwise, the loot system seemed to be behaving "normally." Finding food and drink to prevent starving/dehydration after spawning, and then finding bottles/pots and having food to save for later was sufficiently challenging for the first 25-30 minutes to keep it a main priority. A small increase in the spawns of blunt melee weapons (pipes, crowbars, etc) would be nice in the near-coastal areas. Doing that would result in two things: One, it allows edged weapons to retain their value for opening cans and melee strengths. Two, it helps address that "artificially enforced challenge" feeling one can get when you've searched two or three towns and still have no melee weapon, but just start noticing all the possible weapons you could have made out of any of the furniture, appliances, or junk piles along the way.
  6. Stress Test vol.32

    As far as I can tell, It seems the M4 and its mags have not been added to the loot table files for offline mode. Not that it's a big deal, but I thought I'd mention it so that people who want to test it out in offline mode aren't looking for something that isn't there.
  7. 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.
  8. 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)
  9. 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).
  10. 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.
  11. 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.
  12. 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
  13. 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.
  14. 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
  15. 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.