Confirmed. This happens in the latest Dev Build. All choppers are effected to my knowledge.

Lol, I destroyed 2 choppers yesterday by entering them. Good thing we didn't even get to take off.

I'm seeing the same thing. Not all glitching players will trigger the rotor collision. If one of the glitching players hits it just right you lose the main rotor. This most likely happens when loading people up but I've seen a chopper get off the ground before having a glitched player collision, sending everyone to their deaths.

Either the floating passenger bug needs to be fixed again or player to rotor collisions need to be exempted. Transport choppers are unusable in this condition.

I'm seeing it in Stable Build.

Confirmed.
Had this issue multiple times on different servers.
It might have something to do with PIP and/or visibility settings.
After decreasing these settings, the error didn't happen to me again, except another player but the pilot and me boarded the chopper.

Confirmed, seen this frequently

Confirmed. Video link here: http://www.youtube.com/watch?v=STNgxhgdUtg

Stable build.

I've seen this on our server as well. It's intermitten but if a player glitches and gets in the chopper the Rotor breaks

Still happening in the current dev build. It's impossible to carry passengers with this bug. Everyone gets stranded as soon as someone collides with the rotors.

Upgrade priority from low

Yeah I had this when I dropped divers off of the MH-9, I made a post on here about it: 0011786. Then again as far as I am aware the engine died instead.

I get this a lot on line. Have added a photo of players 'flying' outside the heli alongside! Not just visual - they crash the helicopters every time. If on ground then the rotors are destroyed.

Confirmed.
We are having this problem also frequently with all helis capable of passengers, more noticeable on a full server when lots of players are online and all slots on a heli are occupied, i.e. with 40/40 players. Please upgrade priority as this is a real show stopper on a busy server. As above, everyone on the servers seem to know and acknowledge the issue as a common problem (the only temporary fix is for those players who are "glitching" to disembark and hope it won't happen again on liftoff) but for some reason it's not getting attention it needs on fixes. Losing the rotor blades because of glitching players and not through any enemy fire at all is rather detrimental to immersion!
EDIT: I have added a forum post on ahoyworld (a server I frequent a lot where everybody seems to know about this issue) and invited them to vote/comment here too. This is just not getting the attention it deserves so I'm getting more proactive to try and help trigger awareness that it isn't (currently) a high-priority to fix. Can I ask you all who have seen this to spread the word on your own gaming forums?

Quote Slugster "Not just visual - they crash the helicopters every time. If on
ground then the rotors are destroyed."

This happens in flight as well. I tried taking off as soon as a "glitching" player entered my chopper and flew fast to prevent this but as soon as you lower your airspeed the glitched player ends up still colliding with the rotors.

Roger that DennisModem.
My screenshot shows some players "hanging around" outside during flight :)
Its a regular occurence seeing the glitching players and I
hope the priority is raised as it will as gigglebok says, greatly effect gameplay.
Have often abandoned flight for a more four-wheeled approach to get to a mission. It might take a lot longer but at least I get to admire the view more I suppose...

Can I also request that this category is changed from "visual-vehicles" back to where it belongs, "Game Physics".
This is NOT cosmetic.
This is seriously affecting gameplay on servers with large amounts of players trying to use helicopters to travel to the next waypoint in a mission.
A heli with 15+ people onboard get very short tempered, very quickly, by yet another glitching player causing the heli to lose the rotors while travelling at speed and crashing and burning in yet another sorry ball of flame.

Agree with gigglebok

think this may have been resolved in version 0.77.109136. I tried duplicating and think it's been fixed.

0.76.109065 still has the problem (non dev beta) as of tonight. DennisModem can you find anything in the changelog that may indicate it's been fixed in dev? Please don't stop the investigations as I think it's still very much there...

This issue is still present in the current dev build (29/08/2013). I had this happen several times yesterday, as well as the other people flying helicopters in the mission. Most of the issues happened when the helicopter landed, probably from people hitting the eject option shortly before touchdown.

I can indeed confirm this problem still exists in the new dev build (29/08/2013) and saw it happen several times on all types of helicopter.

I can also confirm the problem was present playing in the dev build on 30/8/13. I'm seeing it less frequently but it's still there.

This glitch exist since ALPHA but wasn't disturbing until rotors modification.
Now when the player is flying around the helicopter he is destroying the rotors.
It happend when player use copilot or gunner slot inside helicopter.

http://www.youtube.com/watch?v=ktyL66p3L9U

Why is this set to "low priority" ?
It's a game-breaker most of the time when it happens, and it reflects really badly on the game, especially on Altis where Helicopters are even more important for bearable travel time.

I agree this a game breaker when playing MP

They have changed it to High Priority so hopefully this should be fixed soon enough!

This porblem sometimes happen with vehicles too.
When the player is glitching out I can shoot him and he is killable.

Sometimes just im the one who see this gitching, other players in the car dont notice that.

This bug is still a problem. No, actually, it's not just a problem, it completely ruins the game for pilots. And it's been a major issue since the alpha was released.

PLEASE FIX IT.

You have no idea how horrible it is until you sit down looking to relax and ferry a server full of people from A to B, only to have EACH and EVERY take-off and landing marred by this ABSOLUTELY RIDICULOUS, UNNECESSARY BULLSHIT.

Sometimes it will happen multiple times on one take-off attempt until people just leave the server or start arguing with each other. Repair chopper, start engine, break rotor, repair chopper, start engine, break rotor... AGAIN AND AGAIN AND AGAIN.

I'll assume you're actually working and struggling to fix this. It must be really hard to take so long. Or maybe it's just a convoluted piece of botched code caused by gutting the features out of VBS2. I'm just looking for reasons to blame someone for stressing me out over this crap. Sorry.

Just to elaborate on this issue:

It appears to only affect vehicle non-driver crew seats.

ie.

On a tank: It can affect Gunner position, possibly Commander.

On MRAP: It can affect Gunner position, although rarely seen.

On Transport Helicopters: It appears to be limited to co-pilot seats and door-gunner seats.

On attack helicopters: I have not seen the issue on attack helicopters such as the AH-99.

So yeah, vehicle crew seats.

The UH-80 Ghosthawk is especially susceptible to this bug.

It also appears related to multiplayer 'de-sync'.

Updated repro steps, definitely related to server FPS.

EDIT: It also happens to e.g. co-pilot seats.

Did they fix this?

Had the same issue on a wastland server, but then the man who glitched out from the car was in the 50.cal on the pickup!

The problem is still present.
Can we expect a fix with next update ?

Problem is most likely creating a reliable repro. Most of the repro steps were mainly guess work.

On the upside, server stability is being worked on, thus the problem might be less likely occurring, but if it's also related to netcode desync with multiple players it's gonna return like an old but hated "friend".

This problem isn't that hard to reproduce. I regularly play on the 7thCavalry Tactical Realism #1 and #2 servers that run the Invade & Annex mission. It regularly occurs that if someone gets in the co-pilot seat of a Mohawk or Ghosthawk and the player exits the chopper, they pop up and appear to hit the blades.

The thing is that, a server in the wild that occasionally runs into the problem does not mean it's easy to reproduce.

In order to fix the issue a developer needs to reproduce it (more or less) "on key press" in order

a) to understand and debug the problem
after trying a fix
b) to verify that the fix is working

So, if it's related to MP desync you would probably need to run the server for XX hours first and if it doesn't occur it means that you need players playing a mission.

Maybe it's enough if the players are idling, so you can spawn clients, but maybe they need to be actively playing.

Maybe it's related to certain scripts activated remotely and locally on clients a the same time, or overlapping on multiple clients activating them alternating etc. etc.

So, if it's a mission element, you need to discover which one causes it and you need to extract it for the repro.

If it's only a server condition you need a way to reproduce the server condition in order to debug it and you can imagine the devels at BI probably have better things to do than playing Invade & Annex for 4+ hours or so only to MAYBE create an error condition which still needs to be analyzed then.

If it relates to MP desync you need probably something like a virtual firewall with packet queue in order to simulate packet loss and/or high latency, which alone wouldn't be the issue, but then combined potentially with mission elements and multiple (active) players it becomes complex.

You can see, unless you can easily reproduce it from "scratch", it's no easy fix.

Is it possible as an interim measure to change it so that the player model does not register collisions with the helicopter rotor?

After some struggle with finding a workaround to this issue, can confirm that this is an MP desync issue because, the player that is glitching sees himself as perfectly seated within the chopper in his session, whereas everyone sees the player outside of the chopper but following the chopper on the map. The glitching players name is not on the passenger list of the vehicle.

We tried a number of strategies including turning off collision detection. Turning off collision detection doesnt work because the GetIn eventhandler (or alternative vehicle player != player methods) will only fire on the session of the player that is glitching. It will not fire for everyone else because on everyone else's session, the glitching player hasnt actually boarded the chopper yet. If you still want to turn off collision detection, you can still do so for any players coming close to the vehicle but that means you take away the ability of the vehicle to run people over.

In the end, we went back to something simpler. We disabled the co-pilot seat of transport choppers. This is not a perfect fix but it takes away some of the pain.

The problem affects gunner seats also. AH-99 Blackhawks are still vulnerable to this glitch but at least, it affects less people than a transport chopper full of people.

The link below contains our temporary workaround code and observation notes on this issue.

http://www.thelanbox.com.au/forum/topic/90/temporary-pilotcheck-sqf-fix-for-co-pilot-bug/

The cause of the MP desync can be many, and not necessary limited to latency or packetloss. For example, the glitching player may have a different version of truth on which seat is occupied compared to all other players and perfectly unaware that he is occupying a seat that is already occupied by someone else.

If I have the source, I'd look into how vehicle boarding and seat allocation/negotiation is handled in multiplayer mode. Cheers.

Could you please describe how you reproduced the issue most quickly for your analysis, cyckuan?

Can confirm this is still happening as of 113494. Server has been running for at least 10 hours +.

Quote [Cyckuan:"The problem affects Gunner seats also"]

in build 256606 this glitching now happening not only helicopter Class, also all my clients now reports the same about: Kuma`s, T100`s, Slammer`s. PS note that server was full.

Hello,

thanks for updating this issue. We are aware of it, but the problem is we were able to reproduce it only once (quite randomly) in our conditions. May I ask you for as much additional info as possible to help us categorise and reproduce the problem?

Thank you guys a lot.

http://steamcommunity.com/id/Fank/screenshot/46868425648613732 (look under the heli)

Same as #18328 i can only say it appears faster on higher player count, but as you say its "quite random". The only good thing is we got this issue multiple times and the "flying" person does never touched the rotor :P

This is not necessarily--only--a MP locality issue.

I have seen, as a mission designer/scripter/server admin, this issue affect server<-->server as well.

A rough guide to repro:

1. create conditions: write a really nasty piece of code that spams your rpt hard and creates huge file in short time.

2. spawn vehicle: using createVehicleArray at a bis_fnc_randomPos.

3. spawn units: similarly, assign to crew seats and move them in to the spawned vehicle.

Positive confirmation of the above on any vehicle with crew seats. Off the top of my head, I have seen the issue with armed MRAPs, MBTs, and WY-55 Hellcat, though I am confident it would work for any with crew seats.

--

Does it need to be in a MP environment? Unknown. The point of this post is to mention that I have seen AI spawned on the server, be afflicted by the same issue when trying to enter a server-spawned vehicle.

This issue has been present on my unit's server for at least 3 months but it only ever affected people entering the copilot seat when the engine was running. Even then it is intermittent. I believe it went unreported because we run a large number of scripts which makes it difficult to diagnose.

Just in case this information would be useful for testing the issue, our server that we experience the problem on is "[S.O.S] Tactical Gaming".

The following is my most recent script-side workaround for this issue. Obviously this is no match compared to a native solution, hence its just an interim workaround until BI finds the solution. Basically, the boarder attempts to sync with the client holding locality over the vehicle, until the latter can confirm that the boarder is in the vehicle.

confirmGetIn = {
if (player == (driver (vehicle player))) exitWith {};
vehicleSyncNotConfirmed = true;
while { vehicleSyncNotConfirmed && (player != (vehicle player)) } do {

		systemChat "confirming vehicle boarding ...";
		pvConfirmGetIn = [player,assignedVehicle player,assignedVehicleRole player];
		publicVariable "pvConfirmGetIn";
		sleep 1;

};
};

checkGetIn = {
_unit = _this select 0;
_veh = _this select 1;
if (!local _veh) exitWith {};
_seat = _this select 2;
if ((count _seat) == 0) exitWith {};

if (_unit == (vehicle _unit)) then {

		systemChat format ["%1 boarding vehicle",name _unit];
		switch (_seat select 0) do {
			case "Driver" : { _unit moveInDriver _veh; };
			case "Cargo" : { _unit moveInCargo _veh; };
			case "Turret" : { _unit moveInTurret [_veh,_seat select 1]; };
		};
		_unit moveInAny _veh; // backup moveIn if above fails

}
else {

		systemChat format ["%1 boarded vehicle",name _unit];
		pvGetInConfirmed = _unit;
		publicVariable "pvGetInConfirmed";

};
};

"pvConfirmGetIn" addPublicVariableEventHandler {
(_this select 1) spawn checkGetIn;
};

"pvGetInConfirmed" addPublicVariableEventHandler {
if (player == (_this select 1)) exitWith { vehicleSyncNotConfirmed = false; };
};

{
_x removeAllEventHandlers "GetIn"; // change this if its affecting other GetIn event handlers
_x addEventHandler ["GetIn",{

• spawn confirmGetIn;

		false;

}];
} forEach vehicles;
can be optimised by restricting GetIn eventhandler to only playable vehicles
dont forget to apply to newly spawned playable vehicles

It's fixed. Ticket can be closed.