thx. closing...

hi, I'm not able to reproduce the issue. Since it's a long time ago is it still happenning to you or it was solved meanwhile?

Just tried it, it's not happening anymore. This bug was for the old version of AddonBuilder with the traditional windows interface, I suppose things changed with the new one :)

This issue is not fixed!

Steps to reproduce:

1-Go in editor mode
2-Place an UAV on the start of a runway
3-Place an enemy vehicle on the end of the runway (so it can be detected before takeoff)
4-Takeoff MANUALLY
5-Release UAV control

Done! You're bugged for life.

At this point the uav will keep doing strafe runs at the enemy vehicle and ignoring ANY waypoint.

The "autonomous" option doesn't change ANYTHING.
Selecting a waypoint with the option "NEVER FIRE" doesn't change ANYTHING.
Your UAV is doomed until it dies and respawns.

FIX THIS BUG FOR THE LOVE OF GOD.

Hello,

this behaviour should be solved in 1.18. Could you please confirm?
If it persists, would it be possible to create a simple repro mission and provide exact repro-steps? It would help us a lot.

Thank you very much.

in today's dev branch changelog:

Added: arma3diag.exe (includes diagnostic tools, excludes MP)

https://community.bistudio.com/wiki/Arma_3_Diagnostics_Exe

Workaround for version 1.16:
Try to change the UAV behaviour (right click on the waypoint) to "Never Fire" and the UAV will follow every given waypoint. With that workaround, UAVs won't start after you landed them manually.

After the latest update to version 1.18, you can find an "Autonomous" button in the UAV terminal, where you can switch off the artificial intelligence of the UAV.

just noticed that there is a similar request
http://feedback.arma3.com/view.php?id=18434

Should be fixed in current dev branch and even in current stable branch (hotfix released).

Mass closing tickets marked as resolved more than 1 month ago.

If the issue is in fact not resolved, please create a new ticket referencing this one and ask for it to be re-opened.

Priority acknowledged, fix is in progress.

Confirmed, fixed in hotfix.

Another problem is that shooting minigun like that spawns way too much splash projectiles - over 150 at the time just for a single gunner, I think that splash projectiles should die off much quicker so less projectiles will be simulated for better performance.

It is not just the cannon that shoots inaccurately, the missiles also suffer from the same inaccuracy.

Can this be upped to urgent and a hotfix release done early next week?

to partly elevate the issue servers needs to use startup commandline
-nologs

and in BattlEye filters either fully disabled createVehicle.txt filter or
these 2 entries needs to be added to CreateVehicle filters
to stop logging in BattlEye logs (to w/e line you have to log all)

!="B_762x51_Minigun_Tracer_splash" !="B_65x39_Minigun_Caseless_splash"

The bug is still there after 1.24 update.
Any ETA on data lock?

Should be already fixed in dev branch and it should be a part of the next update (1.26) for stable branch.

Data lock :/

Sorry, cannot confirm as fixed, the issue still exists in 1.20 update

Submit

Data lock is not yet over

The bug is still present

https://www.youtube.com/watch?v=aeSCOfJ2TFg

The problem lies not on the gun or the sights.
That's a problem with the Moddel.
With the sights and gun from the NATO Heli the bug is present.

Still not fixed, renders entire helicopter useless

Still bugged in dev branch.

Resolved locally, will be out after data lock.

That's correct. Especially when you turn your optics left or right.

The problem is the router, not Arma. If you disable the firewall it will still block some outgoing traffic. I have the EasyBox 904 xDSL and the same problem. I worked out a workaround and documented it here: http://www.stdlib.de/904.html

Addendum: I also tried the Steam-Button which at that time didn't work (I did no extensive tests.)
I also have to add that somewhere along the road the router automatically updated its firmware so it could as well be a problem not caused by Arma.
As a workaround I installed an old firmware and switched off DoS protection.
Works for me now.
When I have some spare time I will recheck the steam button deeper but that's probably not gonna happen within the next 4-5 days.

Hello, thank you for detailed info. The information from the Steam server has to be downloaded by multiple queries and it looks like the router is detecting that and is triggering an alarm.
Could you please try to use GameSpy (click on Steam button at top right corner)? I'm guessing that will works fine.

Also, if you have any other MP games on Steam, could you please test if their browsers are working? It's important that they are using Steam API for matchmaking (basically anything from the Valve like TF2 or CS).

Follow up: Today we tried playing together via playing host and my teammates were unable to see me in the steamlist while they were able to see/join through the gamespy list. Joining via steam buddylist also failed where joining via gamespy worked.

Hello,

are you still experiencing the issue?

Thank you.

I can add some info on that:
Since the recent update I'm unable to play multiplayer. What I found out so far:
Symptom:
I randomly get a serverlist once. After that mostly a nogo (no servers listed at all).
When trying to connect I get a connection failed message. Nothing more.
After such an attempt my browser lost internet connection. My voice-software (Skype or Teamspeak) still works.

Checking the router protocoll it gives me a log entry for "UDP Syn flooding" for randomly changing IP's. The message is
[UDP SYN FLOOD] : src ip=192.168.xxx.xxx dst ip=xxx.xxx.xxx.xxx
where src is my own computers local IP, while dst is an arma server
The router is an "Easybox 904 LTE".
Firewall is switched off in the router. No way to prevent that.

I chose a different internet connection (not enough bandwidth to play, but enough to test) with a different router - no problem at all.

It seems that pulling the list of available servers out there triggers such an UPD Syn flood alarm and I assume the router blocks that specific connection (somehow also affecting the browser, chrome in this case) without affecting voice connections.

This problem was not existant 14 days ago.

I hope for a fast fix 'cause until then I can't play anymore.

Edit: I assume quite a bunch of issues reported might be related to this problem like this one:
http://feedback.arma3.com/view.php?id=18681

Maybe all the servers are still running on an older version?

Is the issue still present now?

Mass closing tickets marked as resolved more than 1 month ago.

If the issue is in fact not resolved, please create a new ticket referencing this one and ask for it to be re-opened.

Hello,

thank you for submitting the ticket, it has been assigned to responsible departments.

Have a nice day.

Resolved according CL.

When will the fix be in the stable release?

Mass closing tickets marked as resolved more than 1 month ago.

If the issue is in fact not resolved, please create a new ticket referencing this one and ask for it to be re-opened.

Fixed in 1.20 stable

Great! Thank you.

Which version will this be available in?

I'm away from home at the moment, but I will see what I can do.

It will be in dev build, the version of the game has to be greater than 1.19.124227

I've adjusted a Steam server initialization, the -ip= param is passed to the Steam to force it to use this interface.

r. 124227

Can someone please test it and confirm that the fix is working?

Resolved according CL.

One LAN card with multiple IPs associated with it. This is how most clans dedicated server boxes will be set up.

we have a xxx.xxx.xxx.112/28 IP assignment, so the addresses available on the box for use are 114 (the primary or base IP) through 126.

The Arma 3 server is on 116, but the out of game steam browser shows it as being on 114. I assume that the in-game one also has it on 114, but it doesn't seem to show the IP anywhere.

we have -ip=xxx.xxx.xxx.116 on the command line.

Hello, could you post a little bit more details about the problem? You mean the Steam server pick up local IP instead of public WAN address? Or you have multiple LAN cards and it picks up the wrong one?

Thank you for the report!

Without knowing the circumstances it's hard to tell why the AI reacts that way. Once a player in the command of an AI dies, the AI becomes fully autonomous and will start engaging targets - if it knows about any - and completing assigned objectives on its own.

Basic behavior can also be heavily altered by the mission design. (way the AI gets created, what WP it initially gets, assigned to the player, what's done in extension if player in the command dies, how they are re-assigned to the player after respawn)

Would you be able, please, to provide more detail, ideally a simple repro mission with an incorrect AI behavior?

Thank you!

FYI: https://gist.github.com/Fank/11127158

For everyone who need a dll/so that calculate the BattlEye GUID out of the Player UID https://github.com/Fankserver/ArmA-Extensions/tree/master/calcBattlEyeGUID or if you need customized version of it open a issue here https://github.com/Fankserver/ArmA-Extensions/issues

Know i think this issue can be closed.

Mass closing tickets marked as resolved more than 1 month ago.

If the issue is in fact not resolved, please create a new ticket referencing this one and ask for it to be re-opened.

Hello again,

Can you please confirm that these crashes are not happening anymore on Steam Dev 1.19.124162 and higher?

To switch to Steam Dev, please follow steps right here:
http://forums.bistudio.com/showthread.php?149411-How-to-change-Arma-3-branches-between-STABLE-amp-DEVELOPMENT-versions-STEAM-client

Thank you very much.

It seems that those crashes are happening when a player connect or disconnect since the last line in the server console log is usually one of client connection /disconnection and usually not complete since the server crash before the buffer is written in the server consile log file eg:"19:13:54 Player XXXXXX connected (id=00000000" (this line missing ")."

Hello,
we analysed the crashdumps and applied fixes to prevent future crashes. The fixes should appear on Steam Dev in couple of days and on Steam Stable on next update.

Thank you very much, your ticket helped us in a great way.

Categorised as random, so no reproducibility

Hello,

thank you for submitting the ticket. Our program department will analyse the crashdumps.

Thank you

Could you please tell us who we can reproduce it?

Hello,

thanks for submitting this issue. We thank you for your feedback and will put it under consideration.

Have a nice day.

I'm pretty sure Valve is responsible for hosting updates (and game content), so you might want to ask them instead.

Did more testing. I created a Multiplayer game while Steam is selected as the server lists and even when I was in game I was still unable to connect to the internet. I switched it to Gamespy and hosted a game and everything seemed to work ok.

Sorry, 1.18 not 1.8.
For myself switching from Steam to Gamespy actually seems to fix the issue. My friend is having the exact same issue since the update though and switching makes no difference.

Yea well that doesn't work to great AFTER you have already installed the update... and i'm not oblivious to how steam mechanics work i know i can turn off the auto update. what i didn't know is that i wouldn't be able to downgrade after updating which is kind of a bummer considering a lot of the servers haven't updated yet. please think about it more before posting such a single minded reply.