chambersenator

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.

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.

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.

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.

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 .

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.

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.

There are benefits of having a smaller player pop right now. The quality of players and interactions (be it through talking, shooting, or anything in between) has significantly increased in the last year or so. For example, just look at the success of "RP- encouraged" servers. It wasn't all that long ago that this 'organic middle ground' concept was seen as a curious oddity that was incredibly difficult to create and maintain. Servers were mostly classified as either PvP with KoS seen as standard procedure, or RP servers with many rules governing how you interact and when you could start firing your weapon, and anything that happened naturally in between those two extremes was considered pure luck. Before DayZ mod exploded in popularity and the player count went through the roof towards the end of the summer in 2012, the term 'RP-encouraged' may not have existed, but that mode was by far the most common. Why was that? Because the mod at that time had a large portion of players that approached the game from an ArmA mindset and perspective, and their presence helped acclimate may new players to a similar approach (one that often was very different from anything they had played before). This ArmA mindset is not easy to define - part of it was looking at the game in a TvT way with bandits, heroes, and survivors finding each other and interactions and combat were determined more about the context and situation more than a simple 'predator/prey/rare helpful soul' model. As the player count grew and grew, the chances of new players learning from the ArmA veterans decreased. There simply were too many new people coming in for the existing players to influence. Slowly over time, the 'default' way to approach DayZ shifted away from that 'RP-encouraged' concept, and the idea that PvP vs RP was primarily an either/or decision came about. If a new player came to DayZ (either in mod or SA form), how they learn to play and look at the game is determined by the experiences they have with other players they encounter. If all they know is from years of PvP games with kills and carnage galore, their perspective will be heavily influenced by that. All the interesting videos of cool interactions may have attracted them to the game, but if 99% of the MP games they played were centered around 'find gun, see guy, kill guy,' it's often a lot harder to figure out how to find/make that cool stuff happen, when most of the server is populated by those of similar backgrounds. So RP servers came around, but it seemed that many found engagement rules and restricting access were really the only way to handle the whole KoS problem on RP servers, which eventually reinforced the 'kumbaya" stereotype, making the idea of a balance between PvP and RP appear even more unlikely. But finally, over the last year, I see more and more people getting this whole RP-encouraged idea and actively seeking it out, and those that always favored that concept encouraging it further. To keep things going in this direction, you need good, active admins in charge to handle the riff-raff. This has increased the value of a server with good admins, since more people are seeing just how much better a well-admined server is. The devs may be responsible for the quality of the code, but even if that code is perfect, it's the players and admins that determine the style and quality of the experience. I'd take 6-8k concurrent players that are open to whatever DayZ has to offer every time than have 60k players, 90% of which are just here because it's popular and play it like it's PUBG/BF/CoD/etc with a bigger map with loot storage. So, when .63 comes, and the player pop blows up with new and returning players, its in all our interests to do what we can to acclimate them back into the DayZ mindset. It doesn't really matter what your particular idea of what the 'DayZ mindset' is - the fact that you're here reading this means that you almost certainly believe that DayZ can provide something that no other game can. You want crazy adventures? You want big faction battles? You want political intrigue and dangerous nighttime raids and heists? You want meaning to your characters life and death - something more than just gear up, shoot, and respawn? Do you want to be part of some incredible moment that gets shared and talked about for years? MAKE IT HAPPEN. Get a bus. Find random people. Get weird. Drive a herd of cattle into Stary Sobor in the middle of two other squads fighting. Go to the NWAF with nothing but pens in your inventory and run the length of the runway, knowing that when they loot your body, they will talk about you for months. Find the new people. Teach them. Scare the hell out of them. Find the people have been around for ages, and go do something EPIC. Go fishing. Teach a noob to fish. Beat him to death with the fish they caught while accusing them of being an enemy agent of the moon people. Get serious. Go full on spec ops hardcore milsim, get some people, and go get revenge on that faction that keeps killing you. When the people who are waiting for 63 to come back to the game, we gotta show them what they have been missing on the player side of things. edit: lol, apologies, I got a bit carried away there at the end. What can I say? I love DayZ, and having servers like the Village around and doing so well just makes me happy.

I really hope that we see a SA Modding subcategory on this forum soon - hopefully before the devs open the doors to modding. We really could use a dedicated place for those interested in modding SA to be able to collaborate, share ideas, resources, and tips. I brought this up back in April, but it only received one comment. Right now we have no dedicated place to talk about the subject. We need one here. There are things we can do now to get prepared for SA mods that don't require official announcements or releases of standards and tools. When those things are released, people with any level of modding experience are going to be raiding ArmA assets and code like it's a supermarket's bread and milk aisle before a blizzard. We need to have a place where at least a few experienced ArmA modders can tell them "These models have problems, use these instead." or "This is the proper way that you get permission to use someone else's stuff in your mod," or "That SQF you found is 8 years old, and barely worked back then. Someone made a much better version 3 years ago over here, so if you're going to base your own EnScript idea on something, use that." Let's have separate rooms for the "idea people," the "eager but willing to learn" people, the "I can model like a madman but can't code to save my life" people, and the experienced ArmA people, but let's have all the rooms in the same house. It also makes sense to have the 'home' of SA modding discussions here, rather than scattered about on other sites that focus on ArmA. While my own skills over the years haven't progressed further than 'meddling about,' I can't be the only one who was often frustrated when searching for information to find half a dozen possible answers spread over 5 years that was a confusing mix of conflicting and/or deprecated solutions that only 'kind of' answered your question, and relied on another script that ended up breaking what you were trying to do in the first place. Having a pre-existing sub-forum beforehand can at least help centralize the conversation and resources before someone creates it on another site. There is an opportunity here to look at how modding was handled by the community in the past 10+ years with a critical but fair eye and see what worked and what can be improved. BI and the devs will handle their end of things, but for us, with new tools, new code, and a new engine, let's have whatever our mistakes are to be new too, rather than the old ones.

It's worth mentioning that I think this video is before the stamina system got revamped in A3. Carrying or dragging a body should have a speed limitation, along with the ability to do a short burst of sprinting (but not at 'regular' sprint speeds, of course, though dragging should be a bit faster than carrying). I think the compromise you suggested may be a bit too extreme. If one is carried, it's reasonable for the backpack and the weapon that was in their hands to be left on the ground where they were picked up. If they are dragged, they should only drop the weapon in hand. As long as there is a stamina system in place that allows for short bursts of adrenaline-fueled strength, a balance can be reached that allows for reasonable speed while under fire for short distances (under 50m), and then drastically drops after 100m, then requires the body to be dropped after 150m. As for the despawn timer and exploitations, until a more nuanced solution is found, having the despawn timer unaffected and the body just disappearing is OK by me. When it comes to hiding corpses (as in moving them out of sight, not just despawning them), if there can be a way to have some sort of blood pool or other evidence remain at the body's original location for a few minutes without affecting server performance, that's fine with me too. Also, it would be nice if the "evidence" takes various forms - sometimes there's a lot of blood, sometimes little none at all. No need to get too specific with it, and just leave it fairly random. If the results can be filtered by the way they died (as in someone who is knocked out by a punch does not leave a huge pool of blood, but one that is gunned down usually does), so much the better.

I feel quite confident that it will be added in before the end of beta. However, it's worth pointing out that while the basic idea is straightforward, getting it to behave properly, reliably, and look right may take a little bit longer than one might expect. "The devil is in the details," as they say. Consider the following: Will the carrying/dragging include not just unconscious players, but also tied/handcuffed players, as well as dead players, infected, and animal corpses? Obviously, enabling this for unconscious players would take priority over the other ones, but there could be slight differences in the way the game handles all of those types that may pose some tricky problems. For example, if you are dragging/carrying a bleeding player, and he dies while being moved, will the game be able to properly handle that transition - not just for the two players involved, but syncing that event correctly to nearby players? IIRC, the dying process does have some behind the scenes switcharoo going on when it comes to 'occupied' models switching to 'unoccupied' corpse models that might cause problems with stuff like positional data, proper ragdolling/interaction with other models and collision issues, syncing, etc . MOST IMPORTANTLY - How will moving bodies affect their despawn timers? Will it pause or reset the timers? We shouldn't have players keeping their dead buddies and/or victims (and their gear) around indefinitely just by moving their corpse or carrying/dragging it. If this isn't addressed, such a system could be exploited by players to not just bypass the despawn timers, but use player corpses as a way to transport way more stuff than you could fit in a barrel easily around the map. Need more storage, just carry around a dead guy and dress them up in as much high-capacity clothing you can find, then fill it with more gear. (A possible partial solution would be to have the body automatically drop on the ground 30 seconds before it despawns, allowing the body to be stripped, but that is not really solving the problem, only making it less worse in a very awkward, artificial way.) And that's just the first couple things that popped into my head. So even if the animations are ready to go, and the basic functionality works, there is a whole slew of things that tie into other parts of the code that need to be addressed to make sure the potential problems outweigh the benefits of the mechanic. It's certainly not impossible, it's just... complicated. They'll figure it out, though.

Shotguns are a good weapon to use when you are putting the great advice already given above into practice. Why? Actively working on improving your situational awareness works best when you can focus as much of your brain's resources on it in combat situations. With a shotgun, there's less to think about weapon-wise than if you are using an rifle - no optics to switch to, no mags to switch out, etc. Also, shotguns and ammo are easy to find as a fresh spawn, which is nice because to get as much practice in as you can and test out new methods, you will be learning by finding out what doesn't work a heck of a lot more than what you will learn when things do work. During this time, don't let these deaths bother you. Death is your teacher. Make sure that each time you get killed you go over what happened in your head and learn something from it. Think about what you did right, and what you didn't. Sure, sometimes you'll do everything right and still die, and its just bad luck. The goal here is to learn, not to survive as long as possible and collect all the fancy gear. I can't stress enough how important it is to review the battle in your head afterwards. Close quarters PVP is usually pretty intense, and with the adrenaline pumping in those moments, your brain is not focusing on critical thinking, it's more concerned about the moment. Going over your battles in your head afterwards is what is going to allow those important lessons to get stored properly, so that in your next fight, your brain will find it a lot easier to apply those lessons without consciously thinking about it. These little 'after action reports' don't have to be anything complex. Just take a minute or two and talk it out to yourself, and consider what you did wrong, right, and what you might have done differently. That's it. If you have a PC that can handle recording while you play so you can watch the replay of a particularly intense/interesting/challenging fight, great, but it's by no means required. As you progress in skill, move from the shotguns to another weapon type - pistols, civilian rifles, SMG, assault rifles, etc. Once you have your basic strategy and tactics down, it will make focusing on the strengths and weaknesses of each weapon and how best to use them a lot easier.

I am really into the history and lore of pre-infection Chernarus as well. The amount of work that was put in by the ArmA 2 dev team to bring Chernarus to life through its rich, tragic, and complicated history has always impressed me. Anyone that is even remotely curious about the history of Chernarus should, at the very least, read up on the events of 2009 that are covered in the A2 Harvest Red SP campaign, or play through it themselves. OP, you're correct about DayZ maintaining, and continuing to enrich, the 'canon' pre-infection Chernarus history. While all the other official maps released for ArmA/Operation Flashpoint take place in the same "Armaverse," AFIK, DayZ is the only one that has split off of that into an alternate timeline that starts with whenever the infection occurred. Though I am 100% behind the decision to keep the exact details about the infection vague, I love seeing how the devs have been able to develop Chernarus in a way that makes the country's troubled past even more detailed, while not disrupting it's canon history in any significant way. Just a few examples: Except for the NWAF, military locations along the northern part of the map (that borders with Russia) show evidence of two separate destructive events - the ruined leftovers of the Russian "peacekeeping" operation (read: unofficial support of the Chedaki rebellion to create instability to justify an invasion and occupation/repatriation of the ethnic Russian Chernarussian province of South Zagoria) that were targeted by CDF/NATO operations in 2009, and the hastily made forward operating bases made during the infection. The ruined Russian armored column north of Krasnoe is a nice touch that's worth mentioning. The presence of statues honoring the Soviet general known as Aleksei Vasilii Guba, from OFP The ruins of the village of Kumyrna, which was burned to the ground (and IIRC, along with all its residents) by the Chedaki (AKA Chernarussian Movement of the Red Star - the evil bastards that wore those black berets you find in the game) One of the best things about the Harvest Red campaign was the way your character was thrown right from the start into a complex, ongoing situation with little preparation and that in order to succeed, you needed to learn about far more than just your assigned objectives. Understanding the underlying conflicts between the two main ethnic groups in Chernarus that had been going on for centuries was key to not only winning the 'hearts and minds' of the population to get them to help you, but to use that knowledge to make decisions in the field and have to deal with orders coming from command that are coming from people who may not fully understand what's really going on. This all adds up to one thing - those that have played the Harvest Red SP campaign, or at least have read up on it, will most likely have a much more immersive experience roaming around Chernarus that those that haven't. ------ Here's what I'd like to see in the future that incorporates the history of Chernarus (after the real important stuff is taken care of, obviously): Tweaking of the CLE and heli crash spawns - have NATO/UN helis and equipment spawns favor locations that are south of the NWAF, and Soviet helis and equipment favor the more northerly locations. The NWAF and VMC should be a balance of the two. By 'favor,' I only mean that there should be a somewhat higher chance - NOT that locations spawn exclusively one type of gear/crash site. Even though the infection came at least 3-5 years after the 2009 civil war, and that the UN continued to have a presence in the area to support the CDF (Chernarussian Defense Force), it seems logical that the UN/NATO forces would have been more populous in the southwest and southern coastal areas. Remove the black Chedaki beret from military spawn areas, make it much more rare, and shift the spawns to civilian houses in the northern third of the map. It makes no sense for them to be just lying about in military bases, as it's from a uniform of a rebel force that was defeated years ago, and as such would be something that would have been kept only by sympathizers and rarely, if ever, been worn in public. Put some sort of small monument and area of disturbed ground to mark the location of the mass graves south of Pusta (another Chedaki war crime site). Even if the bodies were dug up and given a proper burial after the 2009 conflict, there should be some small memorial or at the very least, evidence of a large patch of disturbed ground. Same goes for a Kumryna. Add the remains of the Manhattan FOB on the top of Klen mountain. I know there is a small wooden marker there currently, but it would be nice to see a bit more there, even if it's just a few wrecked vehicles and a couple busted up HESCO bastions. No need for item spawns, just the remains of the FOB. Add a few more burned out civilian building ruins throughout the northern third of the map. While the NATO strikes would have focused on strictly military locations, the overall rarity of ruined civilian buildings from that conflict in that area seems a bit odd. And finally, the toughest one to get right - a few scattered remnants of Chedaki and even NAPA rebel camps deep in the woods or other out of the way areas. They shouldn't be anything fancy, or spawn loot in general, but later on when buried caches are in the game, I could see having one of them spawn a hard to detect buried stash at one of them. It should only spawn rarely, perhaps once a week at one of these camps selected randomly. The cache shouldn't be OP, and most of its contents in damaged condition or worse (having been buried for so long and probably not all that well protected), but for those that get lucky and/or desperate, they may provide a serviceable SKS or AK rifle, some ammo (mostly ruined), clothing, and a mag or two, but nothing that you'd want to hang on to for an extended period of time. One last thing - I'm in the process of writing up a series of 6-8 longform articles on Chernarus' pre-infection history that's aimed at exploring the backstory of certain locations and items one finds in DayZ to give players who may not be aware of Chernarus' history a bit more context and significance. I'm trying to keep it as canon as possible and avoid straying into fan fiction territory, and tying together all the info I can from various places on the web, from the Harvest Red mission files itself, and hopefully a little extra info from those who worked on the Harvest Red campaign. It will take some time to complete, but perhaps in a few months, I'll have it ready to share with you all.

Different sized people present a multitude of challenges. From my understanding, the body model, the skeleton, and hitboxes all have to be scaled individually, and then all the movement animations have to be adjusted to the new size, then all wearable items will most likely have to have a proportionally compatible model as well to use for when the character puts it on. It's a ton of labor-intensive and time-consuming work. So much so, that even the ArmA 3 dev team decided not to have any female models at all (unlike ArmA 2). The fact that we have both male and female models in SA is something worth appreciating. I too would love to see us be able to do things like combine the chest holster with the crafted leather vest, or make ponchos or improvised tents out of plastic or canvas tarps in the future. Then there is the whole clipping issue, which is why things like ponchos, belt holsters, robes, long dresses, and long coats like dusters or greatcoats are not in the game (that's why we only have chest holsters and the chest-centered ballistic vest attachment, for example). They need to be able to look right in combination with all other clothes. We may see some of those later on down the road, but probably well after 1.0 at least. You're right about this. While there may be certain things that just aren't possible when it comes to expanding body types and clothing possibilities, the vast majority of things are possible, just not practical when one is prioritizing things and looking at cost/benefit of the time involved, whether your a BI dev or a modder.

So we know the RPG-7 will be in the game. Of course, the ammo will be rare, the launcher heavy and cumbersome, but who needs the launcher when the rockets have so much potential on their own? You see, the rocket for the RPG-7 has its detonation trigger at the tip, of course. There is a little protective cap that you remove from the tip just before firing, since without it, it will go off if it gets enough force applied to it. So, if all you have is the rocket, you have yourself an incredibly dangerous weapon even if you don't have the launcher. Now, what sorts of things can we do with it? 1. Throw it. If done right, this is not as suicidal as it may seem. Since you want it to land with the tip hitting the ground first (and as far away as possible), a rooftop or a cliff's edge seems a good place to throw them from. Once we can fire from vehicles, throwing them from the back of a moving V3S might be a good way to take out that car chasing you. If you're on the ground, and have no other choice, you'd want to throw it underhand with a decent arc with as much force as possible - throwing it overhand just makes it spin end over end, and it *might* not go off. Of course, there is always just taking the F11 route and just slamming it down at your feet, taking everyone else nearby with you. 2. Launch it old school via improvised ballista. A regular bow or crossbow ain't going to cut it, unless you want to have a front row seat to your own dismemberment. You need to go bigger - like *at least* 3x-4x the width and strength of a crossbow for something you could carry short distances (obviously not something you could shoulder or just carry around anywhere) and use it for a high-arc path that probably maxes out at 30ft (perhaps useful for camp/base assault/defense), or go even bigger and mount it to the back of a vehicle like the V3S, and scare the hell out of everybody. In either configuration, something like that is going to require quite a bit of crafting and materials. 3. Incorporate it into a tripwire-triggered trap. It would be hard to conceal in most situations, but as long as you have a way for the armed rocket to drop several feet once the tripwire is triggered, there's not going to be much left of anything that was there just before it went off. 4. IED. If placed properly, and covered by another object to both conceal it and increase it's trigger area (such as a car hood, log, board, sheet of corrugated metal, or something to that effect), driving or maybe even running over it could set it off (perhaps as a base defense to prevent the entry or removal of vehicles from inside). 5. Something in your way, such as a pesky wall, building, or pedestrian? Have no interest in surviving to see the next sunrise? Tell your squad to get out of the vehicle. Have them attach one or more rockets to the front bumper or hood. Approach your target at high speed. Spawn on the coast. So after reading that, one might consider that maybe this particular weapon might be just a little too OP, if we would be able to use it in such a manner. To a certain extent, I agree, but I think there are ways to balance that out. Obviously, making them about as rare as a SVD or VSS spawning with a full mag right beside another full magazine is the obvious first step. Rockets should have and 'armed' and 'safe' action to them. In their armed state, they should be incredibly dangerous to just have jostling around in your backpack, and should have a small chance of going off if you fall or dive to the ground. Even when the safety cap is on, **and** once the devs have a new system for handling inventory damage in place, there should be at least a *small* chance that if the rocket is in your inventory, and is hit by one of the heavier caliber rounds (perhaps .308 or 7.62x54r, for example), it may detonate. While this is probably an incredibly mind-bogglingly rare chance of this happening IRL, if done properly would seem to be a fairly decent risk/reward balance. I would hope that we would see at least some of these possibilities later on in vanilla DayZ, but of course, I don't think we'll see this particular item's full potential until modders get their hands on it. What do you think?

I've heard that arming varies depending on the type, manufacturer, and year of the rocket, and some have a safety pin along with the cap, some only arm after the launch charge is fired, and some are fully armed once the safety cap is removed. I'll see if I can find a link to cite for that.

Looks like there is a new exp patch released today that has a potential fix for TrackIR. Those with head tracking systems should try it out and report any issues to the bug tracker, or at the very least, post a detailed comment in the relevant thread HERE.

No, the sky (including the sun rise and set position, and the moon phases) will return to following their regular IRL patterns at a later stage in development. Right now I believe they are locked to a singe day of the year (or a small series of days, due to the accelerated time scale) that repeats every server restart. Every few months, they adjust it to match the current season. You may have noticed that now the risk of freezing to death is lower, but by mid summer overheating will again be a concern. Also the sun is rising a bit closer to the east and setting closer to the west compared to a few months ago (due to Chernarus' position on the globe - presumably the area where the eastern part of the Ukraine is - the sun will never rise and set directly to the east/west). I'm fairly certain the stars will shift in the sky to be oriented to the proper angle for that particular day the server is simulating. When the servers are released from this sort of "Groundhog Day" loop, the moon will have it's regular cycles back, and moonless nights will be significantly darker. It's also very probable that later on in development, server admins will once again be able to set their server's date to one of their choosing to some extent, as they were able to back in the mod era. Right now, it makes sense to have everyone on the same time frame so that it does not interfere with testing by adding more variables to consider when trying to isolate the causes of bugs or problems.

I know it's a relatively little thing in the big scheme of things, but I've been looking forward to this for a long time. I just checked it out, and the stars are significantly improved - and unless my eyes are deceiving me, I think they are even twinkling a little bit! After all these years running around in Chernarus, I don't really need to navigate by the stars, but I love the fact that it now seems a much more feasible option for those that want to. The only thing that interferes with that now is the limitations to how far one can tilt their head up. However, I understand the purpose of that limitation, and wouldn't want to argue removing that just so I can see a few more stars.

I just did - usually you need to quit Steam and restart it, and the update should show up in your download queue.

Nothing in the OP's question says anything about asking the devs to do it, only if such a list exists. For example, it seems all the stable branch changelogs are all listed here. It's not exactly what the OP is asking about, but it's a ton of useful information that could be combined with the info on the dev blogs to create something very close to what the OP is looking for. If anyone is up for such an undertaking and has the time available to do it, I'd love to see it.

Too late. If I remember correctly, in addition to what's shown here in this trello post, I think the devs have mentioned including things like brake lines and fluid, fuel lines, and engine belts too. I don't have any problem with that, though I could see why some people could find it overly challenging. I would also favor having both diesel and gasoline fuel (which one could differentiate with a simple smell test) and consequences if you don't check to make sure you use the wrong fuel. As for the fuel requirements for aircraft like the small plane (odds are it's a piston engine, so you could probably get away with regular gas for short periods, since we don't have to worry about icing and long term engine wear) and the little bird helicopter (IIRC, it has a gas turbine engine, so it would require Jet-A fuel, or at least kerosene, but I have seen claims of turbine helicopters using gasoline in dire situations, but I can't say if that is possible), I don't think we need to take things that far. At most, if there was both diesel and gasoline in the game (but not kerosene), I wouldn't mind if those were restricted to one fuel type. If you're dislike of those things stems from the difficulty as a lone wolf to get a car up and running, consider thinking about it this way - bringing a vehicle back to a fully functional state is more of a group activity, but stealing that fully functional car is perhaps more suited to a lone wolf. I lone wolf a great deal, and when I'm in the mood to search for camps/bases, I try to pick up a battery and some spark and glow plugs along the way, just in case I happen to find a hidden vehicle. If I find a camp/base first, I can just ditch the car parts if there's anything worth taking.

Tire changes are already ridiculously fast. We don't even need to use a jack to raise the car up. Two, there's not a whole lot a second person would significantly speed up the process (other than holding an extra tire, which they can already do), except for maybe holding onto the lug nuts while the animation is in process. For more complex base building structures, that might be worth considering, but there's a fine line between 'additional players may speed up construction times' and overly micro-managing a relatively small portion of the game unnecessarily.

Once the core elements of this are completed, would I be wrong in thinking this seems to imply that some form of ArmA 3-like 'weapon resting' mechanic would be considerably closer to inclusion in DayZ? Even considering that, at least as I understand it, this part is only half of the equation - the other being adapting/checking the compatibility of various building and object models from SA and various past BI titles (which will no doubt be a very involved process in itself). Given the knowledge that an eventual redesign/overhaul of so much of the code was needed, and the fact that any work done to shoe-horn a weapon resting mechanic into the old system would be wasted once the new system was in, it makes complete sense that it wasn't worth working on. That said, since you are starting with a (relatively) blank slate when it comes to the relevant code for this, what are the dev's opinions on how to best approach finding a balance between weapon sway and (potentially) weapon resting in this new system, and what might be the most challenging elements? They seem to go hand in hand, and I'd assume they should naturally be developed together (even if sway gets to where it needs to be long before resting works reliably everywhere). To me, the current amount of sway is acceptable, as long as there will be a reasonably functional resting mechanic to balance it out before DayZ hits 1.0.

While modding SA is still a long way off, an BI has not released any official info, specs, or tools for modding SA, I think there is value in having a forum category to start talking about the subject. The three main reasons I think it's worth creating now are: To have a place for people interested in any of the different aspects of modding SA (be it concepts, coding, animation, or modelling) to share ideas and info, and to bring together people with different skills to combine their efforts. Modeling discussion. Making quality models takes time. A lot of time. Why not use this time while we wait to consider what kinds of assets can be created and tested in ArmA 3 that should hopefully require little to no conversion? If one avoids weapons, vehicles, and certain types of clothing, as they are probably (AFIK) the assets with the most amount of differences in SA from A3, which would lead to a great deal of conversion/porting issues until we know more, that still leaves us with a ton of possible things to create. Discuss the topic of how the player base and BI can work out the best procedure for submitting, collecting, and distributing mods and asset collections. While the end results would end up in the Steam Workshop, figuring out the most efficient ways to get to that point is worth talking about. Take modeling, for example. If there is a way to have a few 'community asset' packs available of player-submitted models that all mods can use, such as 'industrial items,' household items,' and 'farm items,' we can hopefully avoid ending up with 10 different models of the exact same item. Not only would that make detecting and debugging problems easier, but it would also help modelers make a wider selection of items. While it's perfectly fine to have 3 different kinds of coffee pots, for example, having 16 different models for 'loose wires ripped from an old TV' is overkill. Community asset packs also may help address some of the issues/headaches that involve rights/usage/attribution.