Hey,
thank you for reporting the problem, I have assigned it internally.

It looks like there isn't any "rule" regarding the fact of opening two Steam sessions from the same computer, I had the occasion to note the following behaviors on the beta client:

• Session break (but the client is working)
• No change on already opened sessions

Could give some details?

• Do you use Steam beta client?
• Is your OS up to date?
• Do you use an administrator session?

i can also

I can replicate this

Same issue here, empty dump and crash in loop at every reboot of my server :(

I am such an idiot. I had no idea you can bind keys. Ever since the beginning of the game. No idea. Holy ****. I don't know how to delete this feedback post. Bohemia Interactive, everything you do is correct. <3

Really hate when people act like game development is some easy walk in the park, job/activity.

"guaranteed network messaging"
Didn't BI say something about that? Like in the change log or something?

In light if what the OP posted, can you not roll back stable to a version thats actually "stable"?

@padoopatel
Hey! Let's stay civilized! I know this is a big issue, but insulting someone won't help fix it either!

For the time being, I advise you to revert back to 1.24.
Do this by Rightclicking ArmA3 in Steam -> Properties -> Betas -> Enter: Arma3Legacy124 -> Click CheckCode -> Select "legacy (1.24)" from the list
It is an 1.1Gb Update, should not take too long + it is playable.

Btw. I think this is happening because of packet flood. They called it "guaranteed network messaging", so now every packet is sent when before some where lost? (not a pro on this topic). Which then causes a flood, which is blocked by the router (my guess). Anyway, my f***ing Telekom router won't let me change anything regarding flood or firewall :/
Needed Ports are all open.
BI, we need a fix ASAP!

I like many others have been suffering from massive amounts of desync ever since the last update... All of arma 3 MP is completely unplayable for me.. This needs to be fixed ASAP

your patches make a shitty engine worse , thanks for going backwards, you guys should move your offices to Nigeria

Related to : <a href="http://feedback.arma3.com/view.php?id=20363">0020363</a>. It may be DayZ, but its happening on many servers. Both Main and Dev branch.

Please help us out here! We all at the Breaking Point community are in shambles over this last update! The desync is absolutely gamebreaking. Thanks guys and good luck finding the problem.

In the meantime Servers have been restarted a couple of times:

25/08/14 17:41 Server <5> Crash
https://www.dropbox.com/s/srl3x3coboh765f/Crash_5_25_08_2014_17_41.rar
It created Crashdumps with a filesize this time.

When i noticed @ 18:21, i clicked okay on the Application Crash notification. It immediately crashed Server <4> (same machine)

25/08/14 18_21 Server <4> Crash
https://www.dropbox.com/s/1lv2p1gtyopsw8l/Crash_4_25_08_2014_18_21.rar
It created Crashdumps with a filesize this time.

The RPT's look like they are related.

I've uploaded 4 more Crashdumps. "Crash_4_27_08_2014___4StackOverflowCrashDumps.rar"

The Frequency of the stackoverflow related crashes is increasing rapidly.

I have a hunch this might be related to the proliferation of Client_RC, Client_Perf1 and client_Perf2 users trying to join the server.
When Players on those client-versions get killed on the server (1.26 vanilla), they encounter a CTD.

The last 2 crashes documented in crashfile "Crash_4_27_08_2014___4StackOverflowCrashDumps.rar", conincided with a player getting killed and receiving a CTD, they both were client_Perf1 and Client_Perf2 respectively.

The RC2 that Dwarden has has published, fixed the Issue. No more Stackoverflow's causing Server-Crashes.

Thanks.

----

Steam-beta-key: Hotfix126Arma3
[27.08.2014 18:22:28] -[EUTW]- E.C.I.D.: so, how do i get the proper server binaries ?
[27.08.2014 18:23:00] Dwarden (David Foltyn): https://www.dropbox.com/sh/582opsto4mmr [^] ... ixRC2?dl=0
requiredBuild = 126951; Require clients joining to have at least build 126951 (1.26 Hotfix2) of game, preventing obsolete clients to connect
guaranteedUpdates = false; // Experimental Command by Dwarden

The issue should be fixed in latest dev version. Check pls.

Hey,
thanks for reporting the issue. However, the crashdump file (bidmp) is completely empty and cannot be analyzed. This can be caused by insufficient time given the client to create the dumps (killing it via task manager) or the program performed an emergency shut down instead of crash. Could you please try to crash the serve again and give it more time before killing it? If that is not your case, please let me know, thank you!

Î checked the Ôther 4 servers for the RPT's and Bidumps, and they all are 0 Byte sized.

I am assuming, this is a "Feature" of this Crash ??

A crash like this has not occurred naturally since this report.

I have not found a way to reproduce it as of yet. The only thing that they all (the 5 servers that crashed) have in common, is the Rcon-Log entry indicating the server trying to contact a BE-master and failing in doing so.

Mass-closing all resolved issues not updated in the last month.

Please PM me in BI Forums (http://forums.bistudio.com/member.php?55374-Fireball) if you feel your bug was closed in error.

Appears to be fixed as of rev 127225 (18/09/2014 - update to rotorlib 4.1.1). Issue can be closed.

The wreck is not supposed to be there at all, only the pilot and some rubbish.

Hey i think your latest patch/hotfix (applied today) has fixed it. At least, i still have that registry setting altered (linked above) but things are looking good.

I'll outline what has happened.

Was in a game with a buddy when we lost the session and everyone got kicked. Looked like the server we were on got updated to this new version. Got kicked back to the multiplayer list and bugger me if the list populated as you would expect it to. This was BEFORE i updated my client as i was still ingame. Therefore whatever you have done server side seems to have resolved this problem that i (and seemingly quite a few people online) was getting.

Thankyou very much - hopefully this issue keeps you informed on, for all i know, what may be an unexpecteed outcome to your update. Nothing has changed hardware-wise my end, nothing at all.

Great, i have lots of servers in my list and my internet connection is completely unaffected when i pull the list of servers down!

I tested it out today. while looking at the rotor RPM, there's a direct correlation between reduction in rotor RPM and the degree of collective being raised. At collective lowered to flat pitch, the rotor RPM is within normal limits, but of course there is no lift. at middle ranged collective, the RPM drops to the lower limit, but doesn't produce enough lift to hover. full collective creates enough lift lift off, but the rotors immediately drop to well below limits, causing the aircraft to drop. It's not even like there's no governor, it's actually more like the engine is at idle.

Also, there still isn't any explanation for the drop in rotor RPM as a result of forward cyclic. As far as my knowledge of helicopters and aerodynamics goes, this will never happen in real life. I'm aware of transient torque, but that only increases torque during left banks, which could result in a drop in rotor RPM.

I think, I know, what your problem is.

As far as I understood, you always flight with maximum raised collectives and have problems with simple changing directions?

Do NOT raise the collective to maximum. Stay on or under the last collective line (75 %).

Use maximum collective only in emergency situations (f.e. gaining height very fast).

You will overtorque the rotor if you always use maximum collective. Overtorquing the rotor causes damages on your engine and lost of RPM. Loosing RPM causes fatal or no proper maneuvers.

This has been happening on our server as well, not sure if after hotfix or latest stable (1.28 or 1.26). Seems to disappear after death/respawn on our co-op mission.

Issue still persists.

Issue persists in all helicopters (tested Ghosthawk, Hellcat and Hummingbird)

If Q worked like cruisecontrol, that would've been great, but it is this useless limiter thingy. E is just a secondary for SHIFT + W, so it can be overwritten.