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

It should definitely occur, it happened with the legacy fatigue and in happened in ARMA 2 also. Have you tested if sitting doesn't recover the stamina faster as well?

I've updated my drivers to the latest version, even checked in the software and this problem isn't occurring anywhere else.

Interesting to note. I am able to add 704 Titan AA Missiles into the crate from the Zeus interface.

Execute this from the init of the crate

clearMagazineCargo this; clearWeaponCargo this; clearItemCargo this; while {this canAdd "Titan_AA"} do {this addMagazineCargo ["Titan_AA",1]}

returns the correct 220 number expected. This looks to be a Zeus interface issue.

But at that time i was still choosing which mission, not yet click "PLAY"

Vanilla presentation ??

Now when i try to play SP mission, which i have subscribed recently in the steam workshop, there are 2 boxes jumped out after clicking "PLAY".

1. You cannot play/edit this mission;it dependent on downloadable content that has been deleted.XXXXX(Name of required mods and contents)

2. No entry 'bin\config.bin/xxxxx'

And i'm sure that i have subscribed those mission, which normally it will be automatically downloaded after clicking PLAY.

So...How can i fix it?

THX

You need mods to play this scenario

• RHS Escalation
• CUP_terrains
• fallujah island
• Chernarus Winter Island

Try to run some vanilla presentation.

Hello,
we're sorry for the inconvenience. This issue is caused by the Windows update KB3078601 and there is nothing we can do to prevent the issue at this time. You can either uninstall the update or wait for Microsoft to release a fixed version of the update.
http://windows.microsoft.com/en-us/windows/troubleshoot-problems-removing-updates#1TC=windows-7

Hello,

thank you for your feedback. This is not a bug. Pre-placed units cannot be modified by the Zeus Game Master.

Just tried completely re-installing Arma 3. Made no difference. Still same error code and everything

You mean the bar on the right bottom corner. It is deactivated so it shows 0. The devs are currently working on a new solution to display the armor level. The only wa right now to see the armor is open the inventory and hover the mouse above the vest/helmet.

Just adding "An implementation in ARMA3 is not necessary if you are using a NVIDIA graphics card [with a build-in PhysX Co-Processor]." The main feature of PhysX is the load outsource to dedicated processor on the graphics card (not the GPU!!!). Requirement for this is this special co-processor. PhysX is a Nvidia patent so AMD has no option at all.

An implementation in ARMA3 is not necessary if you are using a NVIDIA graphics card.

1. Open your windows control panel
2. Go to NVIDIA control panel
3. Take a look under 3D-settings
4. There you can define the Physx calculation by the GPU or CPU

Maybe these are the same steps for AMD graphics cards but I don't own any.