Duplicate T188872

TY

Resolved for 1.3.0.104 and higher.

A would be correct but I believe B would not do anything either

In T189290#2762190, @Firewalker wrote:

Seems to be something else other than just airdrops causing this.

At this point, if airdrops are disabled, both my servers run normally. I've been trying different things on both servers when players aren't on in order to cause a crash, but just not having any luck.

The randomization is making it difficult to nail down a culprit.

I'll continue to follow this thread and if I can find a way to cause a crash without airdrops I'll report back.

Fire

Heya @Geez just to be more clear to other users do you mean

I have gone as far as removing every single mod except for CF, and GSC gameworld assets, and PripyatGamma. Even tho I removed almost every mod, I still was getting the access violation error and GSCgameworl assets and PripyatGamma are the map mods required for PripyatGamma to run. Thats bare minimum on the mods and still ran into this error.

Hello again.
There is a workaround at the moment, you can bypass the issue by removing "cheat check" from the cfgignorelist.xml file located in offline mission folders.
Regards,
Geez

Hello SmallZzy.
There is a workaround at the moment, you can bypass the issue by removing "cheat check" from the cfgignorelist.xml file located in offline mission folders.
Regards,
Geez

So this will be an issue present in the next stable release? Will change the game a bit for sure

Resolved for 1.3.0.102 and higher

Fixed for one of the future experimentals

Resolved for 1.3.0.102 and higher.

Area is not supposed to be moved. If you do move in real time in scenario, you have to make sure that the same operation is done for all join-in-progress players. This is not supported by default.

Thank you for your feedback! This has been communicated to the designer team and will be taken into account.

Hello SirLucient.
We have tested this on our end but we were unable to reproduce the issue.
Regards,
Geez

Resolved for 1.3.0.102 and higher.

Resolved for 1.3.0.102 and higher.

Resolved for 1.3.0.102 and higher

Resolved for 1.3.0.102 and higher.

Resolved in 1.3.0.102 and higher.

Resolved for 1.28

https://feedback.bistudio.com/T188872

Thank you for the report.
We have tested this on our end but we were unable to reproduce the issue.
Regards,
Geez

We have tested this internally but we are unable to reproduce the issue described.
We are however aware of the feedback about the current state of footsteps and it is being taken into account.
Regards.
Geez

I just want to add we have disabled Expansion Airdrops on our server as of 2 days ago and there has not been one server crash since. We also have quite a lot of map edits on the server too that we load with the EditorLoader mod and this has not caused any crashes so far.

Hello Ninjakill96.
This appears like a network issue as it seems your client cannot communicate properly with the server causing such desynchronisation.
Regards,
Geez

@Geez I have been playing around with this for hours now and I still cannot wrap my head around it. This must be some kind of desync issue. Here is what I have found

• I modified the mission server to save the last logged out player and not delete the player when the client logged out. Also in the OnClientReadyEvent I do GetGame().SelectPlayer(identity, oldPlayer) and ignore the player loaded from the DB and the same problem occurs
• I tried resetting entity flags, entity events, physics, simulation and more things I cannot remember anymore and none of them seem to fix the problem
• Each time I select the player again I have to wait even longer than I had to wait the previous time. For example after the first time it takes 7 seconds to catch up, then 14 seconds and then 21 seconds. It seems like the sync of the player happens after x seconds after the player is spawned. That would explain why I can immediately select a newly spawned player, but a player, that already existed for a few seconds, takes longer

Thank you for the report.
All hacking incidents are being investigated by BattlEye.
Regards,
Geez

In T189590#2763730, @tjensen wrote:

@CosmoDayZ Thanks!

@Geez I ran Uninstall_BattlEye.bat to uninstall BattlEye and then ran Install_BattlEye.bat to re-install it. This did not fix my issue, however, as DayZ is still exiting early during loading.

T189372
T189596

Information shared about gameplay that affects usage needs to be fixed soon.

I don't have video, it's that floor where are 2 story beds located. If you can place it there or anywhere else on the ship means it was glitch on my side, in that case don't bother. But if you can't place it too on that floor - please take a look. Thank you

Im getting same error. Tried everything. Just crap... worked great and then nothing. 15 min same error. Illegal read

What was the solution? Same problem

This happens to me as well in Official servers, mainly with knives and various other tools & items, please fix <3 , it really breaks the immersion of the game, and i can't tell when i take out items.

It appears that this is fixed in 2.19.152675 -- not sure if " Tweaked: inAreaArray/inAreaArrayIndexes array of positions has been unified and can accept positions in format array, object, group, location, marker (while ignoring nils) " in that update was what fixed it or what, but the antistasi code now works fine :)

In T189611#2763784, @bloxi wrote:

That sounds really frustrating! 😓 It seems like a possible issue with input lag or frame rate desync between the game and the cursor. Have you tried adjusting your Xbox display settings or lowering the frame rate mode to see if it improves? Hopefully, the devs address this in a future update!

That sounds really frustrating! 😓 It seems like a possible issue with input lag or frame rate desync between the game and the cursor. Have you tried adjusting your Xbox display settings or lowering the frame rate mode to see if it improves? Hopefully, the devs address this in a future update!