Tested with the latest 1.20 stable/experimental 1.21.124799, the issue persist.

If the momentum off the marshall stops at shore, the drive wheels won't engage, and the propels won't provide with trust either way forward or backward. The vehicle gets stuck.

Be careful about dig this to hackers. Its possible yeah we banned two of them permanently but then the 3rd time myself executed the function on mission join.

and im not a hacker and shutdown my server ^^

We've had this issue a few times over the past 3 weeks. We found out that one of the players (who was also a hacker) was remotely calling the "bis_fnc_endmission" somehow. If there was a way to override this to make players not able to call this.

did all the players die and then you got that message, or did just some but not all players die and still randomly got that message?

you haven't really shared alot of information about whats running script-wise. can you upload the mission its happening on?

--

i see they fixed a respawn scripting error related to BASE, do you have your markers set up correctly?
"Fixed: Scripting error when no respawn position was found"

We have the same issue.
We have an altis life server running with about 90 players.

the mission randomly ends after a player connect.

#0 "BIS_fnc_MP_packet" = [0,[[<NULL-object>,true],"initPlayerServer.sqf"],"bis_fnc_execvm",false,false,false]
#0 "BIS_fnc_MP_packet" = [0,["endDeath",false],"bis_fnc_endmission",true,false,false]

Try at first to cut out all your @-folders (for example @JSRS2.0) in the Arma main directory and insert them somewhere else, start the game and take a look at the entries in the expansions directory. If you still find all your mods (@JSRS2.0) there, deactivate them and restart the game.

To deactivate mods, you have to click on the mod (highlight it) and click on deactivate/desactivar (in your language). After that, you have to click on accept/aceptar and restart the game. The mod should be deactivated now.

If you want to uninstall it completely, you have to open your Arma 3 main directory and delete or cut (and replace somewhere else) the "@JSRS2.0" folder.

I hope, it works for you

@Exechino29

Glad I could helped you with that problem.

Please close the ticket, because it is not really an issue.

@Koala Issue resolved (thanks for the info)
A Greeting.

if where?? can not find it.

This should be on the Forums.

Confirmed appearance, however I am unable to reliably reproduce it. Will investigate, you can track the progress in the linked thread (closing this as dupl.)

Thank you for the report!

Does it happen instantaneously (loosing the joystick input) or does it just disappear from the Controls configuration?

I have almost the same setup here, but afaict it has never happened to me.

Otherwise I would generally recommend

• use direct motherboard sockets if possible (3rd party hubs can occasionally be troublesome)
• disallow the computer to turn off the USB device in order to save power in system settings

I have the same problem.

I had it previously with a CH Combatstick USB and CH Pro Pedals USB.

Now, occurring with Thrustmaster HOTAS Warthog joystick, Thrustmaster HOTAS throttle, and CH Pro Pedals USB. Was connected via individual ports, or by a USB hub.

TrackIR is not affected at all.

When I lose the joysticks, unplugging and replugging within the game does not allow the joysticks to show up. However, if I quit Arma 3, unplug hub, replug, and re-load Arma 3, the joysticks appear again. However, I might lose the joysticks 10 minutes later. This makes consistent multiplayer gaming nearly impossible if I have to quit and rejoin just to have my joysticks back.

I heard that there may be a capacitor issue with the USB ports on the motherboard, but have not been able to find more information about this.

It seems like the problem occurs with great frequency if I go to the options menu while playing the game.

Looks like everytime i'm in the game and go to controls the joystick disappears.

Tested with newly created picture and still the same issue. Massive game crashes on client side!

Does this issue still apply even in recent builds (e.g., 1.18)?

We finally found out what caused the problem :D
We are using http://www.dtclan.co.uk/ to manage our different groups of members and added there the clan tags and pictures (paa files). At least one of these clan pictures was corrupted. They all had been shown properly in the game (in the players list and on vehicles), but after removing them from the site and deleting the cache at "C:\Users\%USERPROFILE%\AppData\Local\Arma 3" the game stopped crashing.

You should add a check to your source code, that tests if a picture can be loaded properly and is not corrupted. If the file is damaged you could add an information to the logfile, but the game should definitely NOT CRASH!!!

We've also tested it with ordinary jpg-files (size < 100kb, 256x256 pix) last week and had exactly the same problem.

Today joined a guy from another clan our server and it seems that he had also used a corrupted picture, cause some people got kicked with the same error again . This is really bad. One guy with a corrupted picture can make it almost impossible for many others to play the game!

we did some changes in 1.12 , can you please retest if the server is still crashing by these files ?

Dev version didn't fixed the problem. Game is still crashing, caused by the access violation (logs attached).

Btw the dev version has massive desyncs and frame drops...

Hi.

Where do we have to add these parameters? In the server.cfg, basic.cfg or somewhere else?

And if it's one of the config files, do we have to add it like this?

enableSteamLogs = 1;
debug_steamapi = 1;

To me the problem seems to occur more often when an admin has joined the server. As soon as one admin joined the game crashed and I wasn't able to rejoin again (kept crashing on connect). As soon as the admin left I had no problems rejoining (arma3_2014-02-09_12-51-14.zip).

• Update

As soon as admin joined, 6 people crashed (arma3_2014-02-09_15-34-52.rar)

To summerize our testing; We started the server. Testers; Luxor, 413X, Marty, Skywin, Etienne, Jayjay and one random man who joined.

Luxor crashed instantly as we started. Skywin had his crash after about 2 minutes in. Marty had his game frozen up, but not our issue. After a couple of minutes in, the fps started to jump from 10 fps to 50 fps rapidly making the game unplayable. Jayjay crashed somewhere at this point. Etienne went afk when the fps started dropping and stood desynced on a quadbike 1 meter up in the air. After a few minutes he got disconnected by steam ticket error (unable to verify if he crashed or another issue). The random guy disconnected willingly at some point. When I was all alone on the server I disconnected myself without any crashes. During this time, skywin tried to connect once or twice but was unable to get through the loading screen to the lobby.

Dev version was so unstable we reverted back to stable unless you developers need more testing.

Hi, one of the crashes seems to be related to PhysX and we have done some PhysX fixes in the dev version recently. So I would recommend trying the dev build to check if it's more stable.

What exactly is the relationship between the crashes and kicking? You mean that one client crashes other clients get kicked in response? And server is still running without problems?

Try running the server with these parameters '-enableSteamLogs -debug_steamapi
', it will output more information into the RPT.

Luxor knows more about this issue than me and will implement this as soon as he is available. But to to start you off.

The server is and been having this issue since around the new years relentlessly. Make no mistake, this is a MASSIVE issue on our server. This is our main server; http://arma3.swec.se/server/data/40248 where we can inspect player duration.

If we take an example; http://arma3.swec.se/game/data/1199036
Every single 0.1 milimeter play is a crash on connection. Every single 2-5 milimeter play is a crash after a few moments. Lastly, there are those that can have played for anything between 5 minutes to 3 hours that suddenly get the crash.

People have their game crash. In response, the server kicks them due to the lack of response from their client. It is often that people get 'Player is losing connection' before the steam ticket is issued.

"You mean that one client crashes other clients get kicked in response?"

No. Everyone has the crash but the crash can occur simultaneously where as 6 people get the crash on the exact same thing.

Worked fine for me a month/month and a half ago, since then I switched profiles and yea, see like 2 seconds of camp Maxwell after finishing 'crossing paths' then loads into patrol.

Edited a week after first note was posted - Restarted campaign and it worked this time. Should've tried simply restarting crossing paths but eh. And yesterdays Spotrep#19 said "◾Patrol return points adjusted to be closer to the base", so likely fixed

According to the ticket author that issue got resolved.

Is it only the Ghosthawk? I thought it's a problem with all of the choppers.

I think it might be all choppers - certainly needs looking at +1

I added for comparison chart DayZ Standalone. DayZ Standalone works perfectly. Please fix this problem in Arma 3.

Uploaded another crash.

It's safe to say that the crash only occurs when action is happening, out of the three crashes I've had today (out of 3 sessions) I've crashed in the following situations:

1st - In the gunner seat of an IFRT at the very moment we started taking fire.
2nd - In a bush next to a lot of enemy soldier who I was backstabbing.
3rd - In the gunner seat of a IFV at the very moment I opened fire on a unsuspecting guy next to me.

If you can try:
Use geforce experience to update graphic drivers to beta in clean mode (before install check in window in down and after don't uncheck anything like physx)
If not helped verifity files though steam.

The reason you are moving slow is because you have moved too far to one side and forced your character into a partial lean.

Either remove the Y-axis for leaning in the game or if you really want to use TrackIR for leaning make sure your dead zone in your Trackpoint software is large enough and make sure your TrackIR is properly zeroed while you play.

Although it's true that rabbits aren't fast enough, that's the last of the problems.

In ArmA 3 human with heavy gear (GL rifle, lots of grenades and other explosives, pistol and almost full backpack) can run faster than rabbit.

Yes, its weird and abnormal. I think that rabbits should be faster.

Mass-close of resolved tickets not updated in last two weeks.

seems like they are working in current version - 1.11.115366

It would be nice to add an ability to drag bodies but not to hide them.

This should be on the forums.

BIS Presents
A super smart artificial intelligence version -300
Get it now and make your controlled units so smart so that they will even find a way to get out of your screen and join you in real life!

@shadeofme I changed the title as you suggested. As for repro, I don't really know how to reproduce stupidity.

+1 This problem is compounded by the fact, that when the driver runs into the infantryman, this infantryman, at first fall dead, and subsequently comes alive again! Apparently BIS decided to compensate for the stupidity of the driver, thus. For this reason, unfortunately, this problem is doubly bad

Killzone_Kid you should specify exactly what the issue is and how to reproduce it so the devs know exactly what to deal with , that's what Bouben means

You should edit this ticket and change it to something like

AI ignores Friendlies when driving a vehicle or engaging the enemy

In the Description Describe a scenario (Without personal opinions)

you can add your opinion at the more information tab

If you change it like that , the devs will check it out

Otherwise they will simply ignore this issue (as they should since its not productive)

Another common issue.
And again, its a problem since ArmA 1.

Even your AI squad mates sometimes injuring you while you are trying to get in tank...

This is not a proper ticket. You should make it clear and specific. Admins should close this one.

In soldat(regular) difficulty you can still see the tags if you scroll down...

Observing AI behavior (especially driving) sometimes makes me think they're blindfolded.

Hey and thanks for the report! ;)

The nametags should no longer be displayed with open action menu or commanding menu.

https://forums.bistudio.com/topic/140837-development-branch-changelog/page-34#entry2941711

Regardless the settings they are always displayed with lock-on icon. Please, for now, consider this as an IFF abstraction.

Please fix this. I based an entire game mode on having to tell friend from foe by yourself, and then I got this BS. Hours wasted.

I guess they can make it a separate option to disable it during command menu and other menus that show it.
It completely leaves with Weapon Crosshairs disabled.