In T178978#2757885, @MyrthGraal wrote:

Nitrado offers DDoS protection as part of their service, did we not just have a whole DDoS scenario? Pull the lawsuit out and make a change it's not like Bohemia got paid to only use Nitrado right?

@Geez
Hey you can close this feedback now :) My suggestion was implemented!
Thanks and much love <3

I tested a little and I think that other light sources affect the low FPS. During the day when you can't see that there is a light on somewhere (reflectors of cars, reflectors on bases or kerosene lamps) but it still affects the fps ( three base reflectors decrease fps form 60 to 45 during day ) Sometimes randomly during outside cities and bases, maybe afected by the position of the sun. Anyway, before the last update it ran much better and never dropped to thirty. Tested on an empty official server

আপনি যদি একটি নির্ভরযোগ্য অনলাইন ক্যাসিনো খুঁজছেন, https://jaya9-bet.com/ হল নিখুঁত পছন্দ! স্লট, লাইভ টেবিল এবং স্পোর্টস বেটিং সহ গেমগুলির একটি চিত্তাকর্ষক সংগ্রহ। নতুন এবং নিয়মিত খেলোয়াড়দের জন্য দ্রুত অর্থপ্রদান, স্থানীয় অর্থপ্রদানের পদ্ধতি এবং বোনাস। সমর্থন 24/7 উপলব্ধ, এবং সবচেয়ে গুরুত্বপূর্ণভাবে, সাইটটি আধুনিক এনক্রিপশন দ্বারা সুরক্ষিত। আমি এখানে দীর্ঘদিন ধরে খেলছি এবং আমি প্রত্যেকের কাছে এটি সুপারিশ করছি!

G

Please fiz 2458 on official as fast as possible

In T189290#2764186, @Metasequoia wrote:

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

The problem I am currently facing is very strange. When the server is just started, joining the server will not cause any problems. After waiting for the server to run for a period of time, joining the server will cause the server to crash. During the server's operation, there are no other players, and the server can run for more than 10 hours without anyone else. Only when I enter, it crashes immediately

In T189426#2763038, @Luxas wrote:

In T189426#2763008, @SofTiK_WH wrote:

In T189426#2762918, @Geez wrote:

Hello SofTiK_WH.
It is recommended to run Nvidia Geforce-Experience for now as there are issues with the Nvidia app.
Regards,
Geez

Thanks for the advice, but where can I download GeForce Experience if NVIDIA has updated its application to NVIDIA App. And there is no GeForce Experience on the official NVIDIA website. I'm confused

https://us.download.nvidia.com/GFE/GFEClient/3.28.0.417/GeForce_Experience_v3.28.0.417.exe

This is for the official game. Deer isle is a mod.

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