@Geez Allow us to help you reproduce the issue. The sound seems more pronounced at higher wind magnitudes when your character is near a conifer. It's a constantly repeating "tsh tsh tsh tsh..." sound. I don't see how you can miss it. Video below.

In T185470#2689046, @Nate_LapT wrote:

but what does "Fixed" mean...
Like is it actually fixed, or actually still bugged..
An updated spec document would be useful here to help with confusion.

I believe the way it is now is the way it was always intended to be - the restock timer triggers when an item his its <min> value, and one of each item is spawned at an interval of <timer> seconds until it gets back to <nominal>.

In T185454#2686391, @Traqu wrote:

This isn't footsteps sound though

This also happens on Sakhal, so likely not map-specific. Hopefully not intentional as it would be a very strange decision in a multiplayer sandbox to use ambient sounds to imply humans or animals that aren't actually there.

Would like to echo some of the sentiments regarding the CE changes. If there's a philosophy behind these changes, please let us know. If it makes sense, many server admins may like to remain in line with vanilla.

This is a good point, I think. I'm not sure how extreme the planned reductions are, but maybe it's a bit onerus in forcing players down a specific path when outfitting their characters.

@bhaal Some servers use providers that proxy Steam query requests from AnyCast POPs all over the world, so the "latency" reported to your client will be that of the AnyCast POP closest to you.

Leaving it out of the patch notes was likely just an attempt to get pure feedback without preconceived notions. I can kind of understand that, as long as they accept the feedback.

Intentional or not, I think it's strange that the developers aren't noticing a difference, unless I'm misunderstanding Geez' reply.

@Geez Noticed this ticket was marked as resolved. Just curious, did this get fixed for an upcoming update? Thank you.

@WeirdXone I think DayOne just had some weather persistence weirdness when going from vanilla weather --> cfgweather.xml. This was done to make it always sunny (which DayOne often does with Livonia), but we could sit there in Community Online Tools and watch the rain value increase despite overcast was pegged at 0. We even set the reset flag in cfgweather.xml to '1', and we were stable to observe the same issue.

@DeGrinchy I think his issue is that he can't assign the same RCon port to an instance bound to a different IP. In terms of how IPv4 works, using the same port on a different IP address should absolutely be possible. If RCon doesn't allow for that, then it's a bug or limitation with how RCon is implemented and/or configured, and worth reporting to the developers (or Battleye).

Can confirm that 'clientPort' in the server.cfg does not appear to work. Tried connecting using the Official launcher as well as the in-game browser, and the client is still using a Windows ephemeral port. This was verified with Wireshark running on both the client PC and the server.

Nice work. The issue with the restock setting has been reported for nearly 4 years. Maybe your ticket will bring it back to attention.

This is happening as of today's update and it's killing server performance towards the end of the restart cycle.

In T176997#2539977, @Progger wrote:

If this error were to exist community-wide, this tracker would be flooded with reports, but it's not. Two options are left:

1.Bad server setup
2.Bad host.

We also have several reports of this issue. There doesn't seem to be any pattern to it which would help us identify a cause, as it only affects a subset of players, but it seems to affect them consistently. Usually trying again using the in-game server browser (provided the proper mods are loaded) works.

I understand now that's how it works. "Spawning Gear Configuration" on the Wiki documentation implied to me that it was replicating the functionality from init.c that allows us to force random spawn gear while still allowing the player to choose their character model. If this new system completely overrides the character, that's fine - we'll just keep doing it through init.c. Thank you, as always.

@Geez When we create the loadouts through init.c, the players can choose a custom character model from the main screen and keep that character model - only their clothing/inventory is randomized by the init.c configuration.

@Salutesh This has been an issue since 1.21. Was reported to the FT on June 6 ( https://feedback.bistudio.com/T173136 - Geez made that one private). Unfortunately it seemed to get worse with 1.22. Hopefully it's been resolved with 1.23 but there's been no mention of it in the Experimental patch notes.

@Klaas They actually fixed this in 1.23. They removed "vehiclesparts" from cfglimitsdefinitions and replaced it with "lootdispatch", which gets assigned directly to car parts in the types file. They removed "vehicleparts" from mapgroupproto.

We are seeing multiple of these "DIVIDE_BY_ZERO" crashes per day across all of our servers (DayOne). The pattern holds with what has been stated above - always after a player disconnects. It *seems* to hold true that the player has recently died, but lots of people log out after dying, so there may be nothing to that.

Unless something has recently changed, correcting the spelling issue in mapgroupproto.xml actually messes up spawning parts like doors and wheels since they will spawn inside cars like any other loot item. With an invalid category ("vehicleparts" without the extra 's') specified, the configured proxies take over and those parts spawn properly aligned with the body of the car.

Just wanted to boost this report. The sound is awful in itself, and the volume makes it worse. Please remove or rework this. It's very bad.

For what it's worth, I have run into this, as well. Say I want:

@Beavis It's possible they are painting areas with the "Historical" usage using the CE editor, and we won't see it until they publish the 1.21 CE files to their Github. We run a vanilla Exp server and the medieval gear is spawning.

Is it presumptuous to assume this was unintentional and will be removed? Can we get confirmation either way, please? Thank you.

@tantan https://feedback.bistudio.com/T168720

We believe this is the result of a mod conflict. This report can be closed. Thank you!

In T168720#2378053, @ItzMikeDocherty wrote:

I have saw many many reports of the ADS bug being worse than ever this patch. From my personal experience it is related heavily to performance / connection / ping on whichever server you are playing. I generally play lightly modded servers from my own region where ping is low and connection is good, the ADS bug for me is very rare. But if I ever play a US server or something very heavily modded, I start to notice it a LOT more. Hopefully its fixed soon, great feedback post btw

In T168720#2378031, @Jaakael wrote:

In T168720#2377911, @sanguine00 wrote:

I don't mean to undermine this wonderfully-detailed report, but this was reported nearly a year and a half ago, with a lot of community input and an acknowledgement from the developers:

https://feedback.bistudio.com/T159299

Still no fix, however.

I did assume there were probably some posts similar to this however I wasn't using actively using the feedback tracker at that time, and I haven't seen any posts on this issue since I have been.

So I figured it can't hurt to post something, maybe it'll help them, maybe it'll be completely useless, either way its gotta be worth a try.

Apologies if this is seen as a useless spam/repost ticket.

Based on the information provided and length of time since that ticket, things aren't looking very promising :/ If this post ends up being useless then that's fine, I just hope they can find a solution eventually and we can all enjoy a slightly less buggy DayZ. 👍

I don't mean to undermine this wonderfully-detailed report, but this was reported nearly a year and a half ago, with a lot of community input and an acknowledgement from the developers:

DayZ Expansion is fixing this on their side, soon.

Noticed that on Chernarus, the StaticPoliceSituation event config had the following flag set:

I can recreate this by running the game fullscreen, tabbing out, waiting a few minutes (maybe go afk for 5-10 minutes), then tab back in. Windows 10 + Geforce GTX 3080, but I know the issue happens with other cards, as well, spanning several driver versions.

I believe Battleye made changes a few patches ago that has caused the ping kick to be *way* too sensitive. Even a momentary blip in connectivity or a small flood of data going from the server to the client can cause players to get dropped. On servers with large queues, it's not currently usable. This results in having *no* max ping setting which opens the server up for laggy players causing issues for everyone.

@alexsys mentioned they were playing fullscreen. I can confirm I get this issue in fullscreen, but can ALT-TAB for hours in Windowed mode without any issue. Would prefer to play in fullscreen though due to better performance, overall.

It's an odd change, for sure. I'm not entirely opposed to cookware degrading with use, but it should be more at the rate of shoe wear than just a few minutes.

Been thinking about the ADS bug more with regards to the below code change from 1.07. It stands to reason that the "ghost bullet" issue that this code change intended to fix is essentially the "reverse" of the ADS bug:

In T137112#2293085, @freerider3434 wrote:

@sanguine00 Hey Erik, what do you think about my suggested solution. You seem to be more knowledeable on the subject than me.

The mapgroupproto.xml from 1.16 --> 1.17 seems to have a suspiciously large number of changes, including the following bit which is normally at the top of the file is now missing:

I'm not an expert on the DayZ CLE, but it seems like the system sees that it needs to fill in a certain item, so it begins searching for spawn points and just plops one down as soon as it finds a suitable spot.

This would be a nice enhancement to the CLE. You can kind of get around this by using your server mod to create duplicates of the items (SparkPlug_T1, SparkPlug_T2, etc.) and then create separate entries in types.xml for each one. Very tedious, though. It would be *much* better if this capability was built in.

@gjvdheuvel Based on the logs you posted, the Repeater hits were all arm and hand shots, which will only do 10% damage.

We've received some reports of similar behavior. Most-recently on a Namalsk server running 1000+ server FPS with 40/40 pop. We're not sure if this is an extremely short server-side hiccup or perhaps something is causing the players' clients to be flooded, briefly.

The first error regarding the strings of "--" in the default cfgspawnabletypes.xml is something that would need to be fixed on the DayZ dev side. While it does not prevent the configuration from being read, it does cause validation to fail which can be a bit of a headache for modded/community servers.

Wasn't 1.15 already supposed to rebalance this? It was in the initial changelog:

Please give server admins a way to disable this via config. It might be a good candidate for the cfggameplay.json file.

Looks like the files have been updated. Thanks again!

Thanks Geez!

I have found that if you correct the typo in mapgroupproto, vehicle parts start spawning inside the vehicles instead of properly attached to them. I think it's best to leave the typo in or remove the line entirely.

We had a massive spike in reports of this with 1.13. Battleye seems more sensitive to the time it takes clients to load in, and it's causing people with older or slower PC's to have issues they didn't have prior to 1.13.

Agree with a lot of the feedback on this change. It seems like the intent may have been to make it more difficult to lock up zombies and get out unscathed (?), but it just feel cheap. Really cheap.

Sorry to add more noise, but I think it's worth mentioning that we've been struggling with this bug to varying degrees for quite some time, and we think it can possibly be traced to changes made on 2/20/2020 related to a fix for "ghost bullets":

The ADS bug appears to be a desync where the server recognizes the command, but your client does not. This is why if you get the bug you will also be forced to move slowly - the server is correcting your movement speed to be what it would be if you were *actually* ADS-ing.

That's a bit disappointing if there's no intention of changing or at least improving upon this behavior. I had always assumed it was "placeholder" to some degree, because it results in some silly infected behavior.

Yes, the 1.10 Changelogs indicate this feature was implemented, but it either does not work, or it is not clear on how to use it. Priority.txt is locked during runtime so it's not possible to edit it on the fly.

DayOne is seeing a 60-70% decrease in server FPS as of the 1.10 patch. During normal operation it is playable, but there is no headroom for the frequent performance dips which result in the typical issues (doors and inventory lagging, players stuttering, awkward zombie combat, desync).

I don't think it will matter, moeb1us. We've already increased spawns around Sitnik, Grabin, etc. with only marginal success. The ultimate goal is to be able to configure the spawn system so that it simply selects spawns using "pure RNG".

It seems like some older persistence backup must have gotten in the way of testing, because after another wipe I can't reproduce this issue. Sorry for the erroneous report.

I did some more testing and it seems that when shooting a dummy with buckshot from ~10m or so away, it only takes 2 shots to kill, but if you walk up to the dummy and shoot them at point-blank, it takes 3 shots. It seems like the spread of the pellets gives it a better chance to hit multiple hitboxes on the player, which amplifies the damage.

It looks like this has been resolved as of the June 18th Experimental release (1.08.153212). I dropped my spawn jeans and a ruined steak knife and logged out to watch the logs: