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

repayr of-boats Ying Tae tent
the het INTE Tae Boat vitnut and TVO-Nanded veapon
Start Tae Engin Andes Siloam
Stop by the Andes het
BAG

http://www.youtube.com/watch?v=AGIrP-bfTL8

Hello,

thank you for the response. However, we cannot determine what exactly caused your game to crash. It is necessary you triy to run your Arma without any mods. If the crashes still happen then, please send another crashdumps.

If the crashes stop (on Arma without mods), please try to activate mods one by one until you find out which one causes the crashes.

Mods are not official content from Bohemia Interactive and it is very likely that the CTDs you are experiencing are caused by collisions between two or more mods.

Please let us know, thank you.

No response from reporter, closing.

Hello,
could you please upload Launcher logs (in the Options menu, there's the menu item "Export Launcher logs to desktop...") and point me to when and what mod you we're updating?

It may take time for Steam to re-download the file, providing it even bother to do that, so there might be a delay between the mod is repaired.

Hello,
according to the system can't render the main window of Launcher. Please do start Launcher in safe-mode and let it disable it's hardware acceleration (by holding Ctrl+Shift while you start it, more at http://arma3.com/launcher/troubleshooting) or use the -nohwa command line parameter.

Hello,

it looks like the crash dumps were not created (we need rpt + bidmp + mdmp file). It could be that your game actually did not crash or it crashed and was killed off (via task manager) too quickly for crashdumps to create.

Next time it freezes, please try to wait a minute or two so the dumps have time to create. If there are no crashdumps after then, we'll try to find another solution.

Thank you

Hello,

thank you for the response. However, we cannot determine what exactly caused your game to crash. It is necessary you triy to run your Arma without any mods. If the crashes still happen then, please send another crashdumps (make sure there is rpt + mdmp + bidmp created).

If the crashes stop (on Arma without mods), please try to activate mods one by one until you find out which one causes the crashes.

Mods are not official content from Bohemia Interactive and it is very likely that the CTDs you are experiencing are caused by collisions between two or more mods.

Please let us know, thank you.

Hello, can you please be more specific?

Please add detailed reproductions steps to your ticket.

Best regards

Hello,
the description for that error and possible solutions are listed on our community wiki: https://community.bistudio.com/wiki/Arma_3_Unusual_process_exit#0x00000035_-_ERROR_BAD_NETPATH

I have had this issue already before the 28th Dec, when I submitted this ticket. Verifying Arma 3 files, or resubscribing etc. didn't help.

For the mods from Steam Workshop the authors are not read from the mod.cpp file (which might not be even downloaded at the time the mod is listed in Launcher), but instead taken from Steam Workshop metadata, and the author name resolution on Steam is failing in this case, hence author unknown.

Might be possible change in future if we find some time to properly separate author and publisher information fields.

Just wanted to mention, that the author attribute is missing for every workshop mod at them moment. It seems the author name resolution is failing for everyone.

Hello,
it's known to happen time to time. It should fix itself after some time, or you can try to restart Steam client to see if that helps.
But we look into it anyway just to be sure, thank you.

I think that I may have sorted out my problem...

A feature was introduced called 'Stream Friendly UI'
And it was set to 'enabled' as default, disabling this seems to have rectified my problem and the chat is working as it should again.

Just in case anyone else has this problem here's a link to the feature and how to switch it off...
http://thezombieinfection.com/wiki/index.php/Stream_Friendly_UI

Duplicate of #0003901

never mind after 2,5 hours in the hc get the time out.

Player headlessclient: Signature check timed out

same issue here, i am running server and headless client on the same machine, both in seperated chroot environments.

my command line for hc uses -cpucount=1 and i connect with global ip adress not with the local 127.0.0.1
im not loading any mod at hc or server.

i ve scripted an auto reconnect for the hc so that it connects 1 minute after disconnection.
in my logs i can see that it is disconnected after nearly exact 2 and a half hour every time.
if i watch cpu consumption of the hc process then I can see it raising within those 2.5 h from 15-20% at the beginning to 100% at the end of that time.
that was testet with an altis domination mission, mission was started but no one was playing.

Had it run for about 4 hours with -cpucount=1 without any problems so far. Nevertheless I hope that this will be fixed soon.

I get the same problem with ubuntu 14.04 LTS.

Would it not be nice and kind of a solution to allow a IP list that is excluded from signature checks?

BTW did you guys tried the -cpuCount=1 param, for me its looks like its fixing the problem, I know its not great but at least it will work until a fix.
Both HC and Server are on the same Server for me.

Linux is a 2nd class citizen with these guys. They can't even get the Linux client updated from 1.42, they've teased us with talk a 1.52 version for a few months, but we're not seeing any dev branches updates to help them with testing. Now they have 1.54 version on Windows and no timeline for Linux Battleye support, so a Linux client is pretty much useless for multiplayer.

This is still broken.

Can confirm. Tested on debian 8.x and ubuntu 14.04 LTS, both either crashes with signature verification timeout or just fails to verify signatures (BIS A3 ones, not mods) just at start.

After additional testing, I was able to get Linux HC to work on a separate (Ubuntu 15.10 on VMware) single core/cpu VM. I was not able to get it to work on the same VM as the server (2 core/cpu VM), even when I used taskset to run both processes on the same core/cpu. It appears that there is a race condition specific to the Linux HC, when running on multi-core/cpu machines.

Related
http://feedback.arma3.com/view.php?id=22914

Encountered the same issue. I was able to get the headless client to connect by making the VM single core. Obviously, not an acceptable solution. I suspect a race condition exists, probably in the handshake.

Additional details: Both the server and the HC are running on a Ubuntu 15.10 VM (running under VMware). I was able to get the HC to connect and FuMS to run correctly, however both processes were running on a single core. When I increased VMs core, the issue manifested.

Oddly enough, I also don't get this issue doing the reverse; a headless client on linux connecting to a dedicated server on windows.

Maybe it's a problem with isolation? I'm curious what will happen with a linux everything on two different machines, virtual machines/containers, or different users on the same machine?

Interesting, sqwishy, that means that it's likely the -client parameter in Linux that makes it time out.

I tried running everything from a separate folder alltogether to see if that changed things, but unfortunately it didn't. Setting up a VM seemed counterproductive given ARMA's ill nature toward VM:s performancewise.

I tried with the arma 3 server running in a docker container and the headless client on the host and the headless client still froze up. I don't have the resources to try running each on separate linux machines. But that isn't really a viable workaround anyway, and neither is using visualization as you pointed out.

This issue doesn't occur when testing a headless client on windows connecting to a dedicated server on linux.

This have been tested with 1.54 AND the latest perf v7

Hello,

we are sorry for the trouble you are having with the game.

Could you please tell us if this happens everytime after the 10 hours or does the time of the crash vary? How many players are connected to the server?

Any information will help us greatly and will be appreciated.

Thank you

Another option would be to add an attachTo tool within 3DEN, which would allow you to place two objects down and click attach. Say:

1 - Place two objects.
2 - Right click the object you are attaching.
3 - Select "Attach To".
4 - Draw line to/ select object you are attaching to.
5 - Script works out relative pos with worldToModel and get/setVectorDirAndUp..

6 - WIN

I want to look into doing this but could be something devs are planning on.

Have you tested if sitting doesn't recover the stamina faster as well?

Stance has no effect on stamina recovery. Prone, crouch, standing and sitting all result in the same recovery rate.

Sad to me, this is so. would Like to have influence positions

@Khaosmatic no I have not tested this