Hello Geez, my ticket https://feedback.bistudio.com/T160803 is a duplicate of this issue, could you merge them?

@Geez This persists in 1.15 Experimental. Grabbed better video of the issue:

I believe this ticket can be closed, I had missed this line in the wiki about the cfggameplay:

Thankfully it still works as intended if the line is left in serverDZ.cfg.

I am fairly okay with the basic idea - if I get hit I will know where I got hit - but the current implementation in experimental is awful. Three things:

@Geez after 1.14 this has started happening again. Several vehicles parked inside garages have ben bashed up and destroyed. Since I have set "remove if damaged" to 0 on my servers the evidence can be found sometimes half sunk into the ground, sometimes on the roof of the structure the vehicle was parked in, and sometimes just a little damaged.

Came here to report this very issue, had an influx of players on my Takistan server who fell to their deaths in Hachaman, thought it was a Takistan issue but turns out it is Land_Smokestack_Big on whatever map... Nice to see it is acknowledged.

Yeah, that happened to me too but only with modded car parts, so it stopped happening after I gave them a separate category in order to force them to garages and workshops. Might be that the "typo" is half intentional to dodge the issue until a thorough cleanup of old loot points (from before the wrecks were added) can be done.

Yeah, 1.14 on experimental and still the same impossible placement restrictions. Found a lovely spot to set up a couple of tents, in the end I had to abandon the idea because it was impossible. And the ground was level - all that was there was grass. This really needs to be looked at.

Fix for this in the latest 1.14 experimental build seems to be working. Crashed my Ada into a car wreck doing about 20 kmph today and it was NOT totalled! I didn't want to sacrifice my ride to see where collisions start doing significant damage, but definitely progress here. Thanks guys!

This is STILL an issue in 1.14 Experimental (and of course 1.13 Stable).

Please?

Just remembered I had posted this suggestion: https://feedback.bistudio.com/T149490 about felled trees and bushes not respawning if a tent or base structure had been built nearby. Maybe link the ticket or close the older one as duplicate?

Shameless bump to this old suggestion. Shouldn't be too much of a hassle - no new animation required, just use the regular “raised item” (for throwing) hands movement. Would be a nice little addition for RP.

Still an issue in 1.13 experimental.

it would be nice if the knife sheath could be given the hidden selection camo slot, to make it possible to retexture.

Still happening in 1.13 Experimental.

Adding to my comment from April - I have had the feature activated on my servers through a mod since I noticed it was intentionally disabled, and I have noticed no detrimental effect on server performance.

Still an issue in 1.13 experimental. Thrown objects need to make sounds so they can be used to trick players as well as infected.

Adding to this since it is kinda related - maybe add the possibility to stack long sticks? At least two or three, and possibly firewood too?

Tent placement (and hence probably fences too) is still a nightmare on 1.13 experimental. Really, the logic around where placement is allowed needs some work. I hate using BuildAnywhere because it opens the door to so much wonky building that shouldn't be possible, but with the frustratingly restrictive placement what choice do we have?

Since this topic is again being discussed, this time around 1.13 experimental, I thought I'd try and revive this post. TheRunningManZ wrote this nice entry on the topic:

Chiming in to give this suggestion a bump. I see no reason headtorch and NVG:s should not handle the same when it comes to what inventory slot they occupy. Headtorch blocking the head slot make them very awkward to use in the permacold DayZ environment.

In T159206#2205782, @NAyRAM wrote:

Also about Radios, a Radio right now weights 2kg, not sure if I am the only one thinking that it could be lowered to 1kg.

Simplest and best solution would be to have voice communication always on and only use push-to-talk for the radio. This would be realistic and make discord/teamspeak meta more awkward, but it would be potentially awful for streamers who need be able to talk to chat without everyone in their vicinity hearing it... Could get around that with two microphones so maybe.

Smashing open a can of peaches with a baseball bat (or a broom...) would be awesome if it had an animation... Leave 10% of the contents or so and it is okay :)

Thank you Geez. I never realised there were two different classes for indoor fireplaces so I simply assumed the OvenIndoor was the stone oven and just had a funky classname. Now I realise the upgrade doesn't have a classname of its own so there is no way to customise its persistence in the economy files.

Thanks!

Thanks for the response anyway Geez, I know we can be harsh in here sometimes. Don’t shoot the messenger and all that...

Swapped the video, the first one had audio out of sync.

@Geez Any hope of this issue ever getting dealt with?

I would change the severity of this issue to major. It is an incredibly annoying meta - people sprintwiggling and shooting from their hips with accuracy. It looks stupid and gives an unfair advantage vs players who don't want to abuse the mechanic.

Awesome, thank you!

Fix seems te be working. I loaded a bunch of various mods to a server using condensed names, and loading in to the server as player - using "local mod" since the launcher can still not automatically load mods from the main game's workshop folder - I could enter the server without issue.

Thank you Geez for the swift response, you're a gem!

Sadly not many modded servers on exp to try with, possibly due to Ticket T156324 making it very awkward to enter a modded experimental server.

Sounds more like someone is harvesting your fences for materials. Either that or the server has messed up its persistence or economy files. Nothing like this happens on any of the servers I play on. (Both official and community).

Point still stands- keep it closer to reality. No unsuppressed firearm discharge will ever be completely inaudible below 1,000 meters. I’d say bump pistols up to the same level as the smg:s (same ammo!) shotguns twice that, AR:s to 2,500 and leave the biggies at 3,500 meters.

Found this, an interesting read on the subject. Probably not feasible to put all these factors into the calculation of how long gunshots are heard in-game (I can only imagine the effect on server performance...), but nevertheless an interesting read:

How about sticking to somewhat reflecting reality instead of inventing arbitrary fantasy levels in the name of gameplay "balance"? It is going down a road of arcadish "gamey" changes that - to put it bluntly - does not belong in DayZ.

Hello again, I tested this again by removing the profile and logging in again - and this time the values were again 2200 and 1375.8242 respectively. So I will change the Reproducibility to Sometimes.

With 1.12 now on Stable I took the time to look through the melee config and to me the damage values look mostly okay. There are some things that are strange - all knives being equal for example, realistically the steak knife wouldn't be any more efficient in combat than the stone knife, yet it is equal to a combat knife...

It was HeadTorch_fix. It’s in the workshop folder with all other mods, but in the meta.cpp file the name is just HeadTorch instead of the workshop title which is HeadTorch_fix. That was enough.

Finally got it sorted, there was this one mod that had an incorrect name in meta.cpp. Apparently that is enough now...

I give up, there is nothing more I can do on my end. No matter what I do the result is the same. I'm getting pretty damn sick of seeing this one:

I used to just simplify the mod name by removing spaces, apostrophes, underscores, hyphens and other crap that tends to cause problems. Tried putting them all back, didn’t work so now I have vanilla servers again... 😬

If this was solved there would be more modded community experimental servers - and the current situation with mods not loading (T157911) would have been spotted before stable.

This popped up on Twitter:

Weird. Would that thing with folder names be the name as written in the meta file? Underscores, apostrophes and all?

Yeah I put my modded servers on hold for the time being, no use bashing my head against that particular brick wall. Either it is the launcher that is borked so it doesn't actually load the mods it is told to load, or the validation logic gets false positives. I don't think it has to do with the number of mods, I got it with only one mod loaded. And I know how to make sure the mods are up to date on both server and client - and the key in the keys folder. There's something going on here.

Hello, I noticed this when I was editing a copy of the economy files to make my deathmatch experimental server, but now that I check the original chernarusplus mission files that I started with, that is not the case. So it would seem the copy/paste mishap was at my end!

I have not met another person on Exp since I wrote that so I have not had an opportunity to test it...

Ok, thank you for the response.

Thank you Geez, can you answer if they were changed with the update yesterday, or are they still 1.5x?

Sorry, I can't quite understand the reasoning behind these changes. Interestingly the STAB vest - which is supposedly designed for law enforcement to use as lightweight protection from knives and other melee violence - is MUCH better vs projectiles than vs melee. Also, in the current 1.12 the hit point changes to tactical and leather vests make them superior to the STAB vest vs melee. It is downright silly, I'm sorry but it is.

Thank you Gews! @Geez guys please acknowledge this issue while 1.12 is still in experimental. These numbers should not be allowed to slip into stable...

This has been the case ever since the game was released. Hence BuildAnywhere or similar mods are used on nearly all community servers. I prefer vanilla, but this issue drove me to add mods to my servers.

Got another suggestion from a player on my servers - tie the mechanic to the flag pole. Something like "RespawnTreesInFlagRadius=0" and no felled tree/bush within the flag pole's refresh radius would regenerate at server restart. It would allow dedicated base builders to clear ground without the need of a proximity check vs individual tents/walls etc.

Any possibility you guys could look into this @Geez? I've had players on my servers asking me about this, and it really would make a lot more sense. Might be possible to mod this, but that shouldn't be necessary.

Still an issue in 1.12 experimental.

Thanks Gews, well formulated!

Thank you Gews for posting this, I dearly hope the devs listen!

Hello, I saw this ticket about a body disappearing and then reappearing in a moving vehicle. https://feedback.bistudio.com/T157684

This may actually be related to the premature despawning of player bodies that keeps happening. (Ticket https://feedback.bistudio.com/T145488) Maybe the bodies aren't actually cleaned away by the server (=despawned) but somehow hidden or not loading properly for players? In other words, is it possible that the body state can cause a desync error hiding the body?

@Geez Do you know if there are any plans to revert this change in the future? I made a server side mod that community servers can use, but I am still curious if and when they will start fighting each other on vanilla again. Tricking zombies to turn up and fight the wolves was a valid (and entertaining) way to escape a difficult situation, now they gang up on the player instead. If a bear comes walking he'll camp the player too - it is actually unfair...

Any news on this? Launcher still behaves like this in 1.12 experimental.

Hello, I have also noted that the zombies will fall backwards towards the player 100% of the time, while the natural way to fall for most weapons would be forward on their face.

Very good post, the melee behaves very weirdly on experimental in general. The above values really should not be allowed to go on to stable, something is definitely not right. Also, why have infected received magich helmets reducing melee damage to the head by 50%? Combined with nerfed damage of all weapons and increased attack speed of the infected, and less ability of melee attacks to stagger them, this is a very poorly designed change. Please revert the head damage reduction.

Such an old suggestion - but still relevant. Allow sunglasses and dark moto helmets to reduce sun glare. There are mods that do it with a few lines of code - so there is really no excuse not to do this.

As predicted, the battery drain feature brings nothing but frustration in this form. Naturally a mod popped up pretty much instantly (indeed, he already had the scripts for the E-cart mod) that fleshes the feature out to what it should be. Please, consider making batteries charge in a car with the engine running.

Ah thank you, I believe there was in older Legacy builds though, before 0.63. Thank you for clearing that up anyway, then I need not try more key combos!

Okay, fair enough. But, with all due respect, then there really should not be a feature that drains the battery either. I would suggest the 1.11 battery drain is put on ice until charging when driving is a thing. Being forced to take the battery out to charge it will become a very annoying meta game.