Alternatively:

obj allowDisposal bool

Latest dev branch changelog includes:

"Added: UnitRemoveManager for SP and MP"

This sounds interesting.

As KK suggested, this would be a most welcome addition!

Please add global command

addToDisposeManager obj

To take care of vehicles and units

I have tested with all mods deactivated; the damage issue is fixed but this one remains to show up randomly.

I have added a Video with this exact Issue, tested deliberately.

I am using todays Dev-branch, the problem persists with and without mods still. Note that also no audio distortion is present. This problem exists for all guns, but is most apparent on rapid firing weapons.

https://www.youtube.com/watch?v=tvOW4-g0dZE&feature=youtu.be

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,
please deactivate all mods used. Is the problem still present?
Thank you.

it seems this issue was caused by a mod. close please.

I am using very minimal mods, but I'll give it a shot; another mod of mine was broken by the update so that may be the case.

Hello,
please deactivate all mods used. Is the problem still present?
Thank you.

And these entities can't even be easily destroyed through a script

Hmmm, i think there are multiple restrictions put on the Arma 3 Dev team from VBS features, and in that case, it makes it look like the VBS guys wear the pants, and BIS is simply doing what they can to get by...

I'm hoping in the upcoming expansion to fix this...
Funny thing is, among many other things VBS supports this as well and apparently it's not even that complicated.
Maybe there's some VBS-exclusive legal bound that prohibits BIS to use that in Arma.

Thanks for the response! Will patiently wait and see what the outcome is. That combat behavior thing is useful to know, will keep that in mind.

Edit:
"Also note that the distance a WP completion is checked by the AI differs according to the type of vehicle used."

Would be interested to know if this applies to cargo units also. The reason I noticed this behavior was because I'm trying to get a waypoint to trigger for a group in a helicopter's cargo space in order to trigger a paradrop.

Hey! Thanks for the report.

The completion radius works against AI checks. If the AI has nothing else to check it won't find out that the WP is completed until it securely reaches the very waypoint.

In COMBAT behavior the checks are performed almost constantly making the AI realize a WP has been completed soon after crossing the completion radius.

I agree it probably isn't much intuitive, but I can't tell you now whether changing this behavior would even be feasible.

For now I'll play a dead fish and wait for more feedback/votes ;)

---

Also note that the distance a WP completion is checked by the AI differs according to the type of vehicle used.

A better wreck model would be great, too.
Like one where the wings are missing, kind of what the buzzard has.

Just doesn't look good at the moment.

Is this ever going to be looked into or do we really have to listen to our characters heavybrathing like porn actors till Arma 4 comes out????

The thing behind This is, that there should be an Option to deactivate TrackIR while looking through a scope.

For that (deactivation) please use http://feedback.arma3.com/view.php?id=9816

The thing behind This is, that there should be an Option to deactivate TrackIR while looking through a scope.

Like you were using 2D scopes.

I personally would not to have the possibility to look left and right while zooming.

This would be the ultimate solution: An option whether you want to use TrckIR or not while looking through a scope.

May be so, but this sensitivity goes as global setting. I have adjusted the sens, and it works, but if you enter the view of a zoomed scope the sensitivity is extremely high compared to the normal view.

Oh and I use FacetrackNoIR with a 3 point clip and the free track protocol and fake TrackIR.exe.

I'm sorry to disappoint you. We can't do. (the sensitivity of TIR relates to its center (unlike mouse), it wouldn't work nicely if you zoomed in while looking to the side)

Anyway, thanks for the feedback & idea!

You can do this within the Track IR software. If you prefer, you can create a profile just for ARMA 3, and you can adjust the sensitivity of each axis separately. You can custom tweak each Track IR axis a billion different ways. It's very easy to adjust.

I second this. Please deactivate TrackIR when aimed down with a zoom scope!

It makes the TrackIR/Freetrack highly sensitive and nearly uncontrolable

what we really need is a preset "dashboard quick look" button that would switch the camera to be zoomed in on the dashboard/control panel as long as it is held. It's nice to have the wide field of view that's there now, but it's too hard to read the instruments in that view.

They could allow you to set a default view, and also another one you could get by holding a key. That way your key could be looking over the shoulder, to the side, dashboard, etc, and you could also set your default view (sometimes it points down too much as well).

it would be better to have this as an manual option, so if people want that wide field of view thes can do it with the zoom-key, otherwise people can look at the dashbord, or mfd without zooming in.

also for the trackir users its mor natural when you dont have such a high FOV.

Iceman,

98% of the time I only get the rpt files and no other dump files. Yesterday when I was trying some fixes I got a bidmp file but there was no text in it. I will try to generate another one. The bidmp file I uploaded was from 1/15 crashes I had.

Mass-closing all resolved issues not updated in the last month.

Please PM me in BI Forums (http://forums.bistudio.com/member.php?55374-Fireball) if you feel your bug was closed in error.

Another person has reported this issue.

Iceman,

I discovered today that if I launch the game in windowed mode it will not do a hard crash and reset of the computer and displays the "DX11 DXGI_ERROR_DEVICE_REMOVED" error message. Doing this will also generate the error logs. I attached more error logs and a screenshot of what the error message looks like.

Thanks,

Hello,

thank you for your report and files. It seems that your problem is that DirectX crashes. This may be from various reasons, such as outdated DirectX, outdated drivers, overclocked CPU or GPU [by manufacturer or user] and many more.

Sadly, there is nothing that can be done from our site. I linked this problem to bug number #0000579, where you can read useful tips in comments.

Sorry for the inconvenience, have a nice day.

Iceman,

Thanks for looking into this. It looks like 99% of the time there are no dump files generated when this happens and I only have the rpt files. Luckily, a few days ago it looks like there was a bidmp file saved with the rpt. So hopefully that will tell you something. I attached the files to this above.

Also, you should know that I had first posted about this problem on the main Arma 3 forums and somebody reported the exact same issue as me.

Let me know if you need anything else.

Thanks.

Hello,
we sent your files to analysis, would it be possible to create another (as many as you can)?

Bump

This needs to be fixed.

Hello,
Thank you for reporting the issue.
We need crash dump files from this folder for solve your problem.
C:\Users\<Name>\AppData\Local\Arma 3\
Can you upload somewhere in winrar package please?
When package will be smaller than 5000k, you can attach it here. When package is bigger, please use some free sharing service and post link here.

How to find correct crashdump file:
Try to make the crash happen
Look into crashdump folder
Upload crashdump with latest date in name (crashdump is rpt + bidmp + mdmp file with same name). Please try to provide as many crashdumps as possible, it helps us investigating the problem in a big way.

Thank you.

http://feedback.arma3.com/how-to-user.html

@rogerx...
lol yeah maybe I was just wishful thinking :-)
This is still a big problem with the RAM just rising with no dump at all.

I have designed my missions so that they never exceed 1.5GB of RAM and normally run persistently as long as the server is up (sometimes weeks)
But at the moment they just eat RAM until they burst within a couple of hours.

@rogerx...
There have been many changes since the opening of this bug as the ticket is one and a half years old.

The problem got fixed in January but returned with the 1.54 update.
My servers started dumping RAM normally again last night and appeared to be working fine.

But unfortunately I woke this morning to find it had crashed lol :-s

I was going to say, problems just do not mysteriously solve themselves overnight on computers!

It maybe the servers are having memory runs, and may have been preventing my client from connecting during 1.54RC. This sounds plausible as I was getting no minidumps on my client.

The is a classic "memory leak" bug.

Amazing though that this type of bug bypassed in-house memory debuggers!

Seems to be working again...

My persistent servers have been running over 5 hours and they are managing the RAM nicely.
As the mission cleanup script deletes unwanted things from the map the RAM responds by dropping in value.

All nice and stable again :-)

We also experience this issue! Our Server crashed 2x in 1 hour (appcrash). I tried disabling the rpt-logs since those were full of spam with some object information, but this didn't help.

Please find a fix soon.

Regards from germany,
G00golplexian

Unfortunately this problem has returned with update 1.54

But there has not been any hot fix since this opening of this bug correct?

@rogerx...

Yeah it's like ARMA 3 is constipated and can't release it's waste.
My dedicated servers have become useless due to this bug (again)

My servers seem to be running nice and stable now...
Missions restart and the RAM manages itself nicely without having to restart servers.

I'll keep monitoring just in case but everything seems good for now :-)

Still doing the same even with the performance binary...

Imagine the server RAM has risen to 1,234,567 KB (example) and the mission ENDS back to the lobby to choose your slot for the next game.
The next mission will start @1,234,567 KB and start rising again.

Sorry I get the feeling I'm repeating myself here :-s
Hope I'm making sense, I just can't explain it any other way :-)

Recently noticed exactly the same problem going in and out of the mission editor...
Preview a mission in the editor, then go back to main menu and observe the RAM sticks at the highest point that it reached in the editor preview.
Go back into the editor and it starts to rise again, repeat until crash.

It seems ANYTHING that you do in ARMA 3 (SP/MP/editor) accumulates the RAM until it either crashes or you shut the game down.
This is a VERY BIG problem.

Hello,
Thank you for reporting the issue.
We need crash dump files from this folder for solve your problem.
C:\Users\<Name>\AppData\Local\Arma 3\
Can you upload somewhere in winrar package please?
When package will be smaller than 5000k, you can attach it here. When package is bigger, please use some free sharing service and post link here.

How to find correct crashdump file:
Try to make the crash happen
Look into crashdump folder
Upload crashdump with latest date in name (crashdump is rpt + bidmp + mdmp file with same name). Please try to provide as many crashdumps as possible, it helps us investigating the problem in a big way.

Thank you.

http://feedback.arma3.com/how-to-user.html

I will do a few mission restarts and force the server to crash then try and get the crash dump files as soon as I can, although my knowledge on this sort of stuff is limited :-s

Basically what is happening when the mission ends the RAM stays the same (as if still playing) then the next session loads adding more RAM on top of the already built up RAM from the last session, instead of starting a fresh in the lobby.
The only way to clear the RAM and start a fresh mission is to restart the server which defeats the object of a persistent server.

You can test this process by repeatedly using the server command #restart

WOW this looks interesting I'll check it out CHEERS :-)

please try the performance binary
http://forums.bistudio.com/showthread.php?169944-Arma-3-STABLE-server-1-24-quot-performance-binary-quot-feedback&highlight=performance

the download is hidden under spoiler button ...

all you need is replace the server binary with the one 1.24PERF4

No crash dump files needed for this as it is so blatant, you can test it yourself and see the problem by monitoring the RAM...

It even occurs on non persistent servers where the mission resets to the lobby when the last player disconnects. The new mission holds the RAM from the previous instead of dumping it.
So whether the server is persistent or not it will still run out of RAM in the end.

duplicate of #7926

Yep, here too.

Since last update the supply drop module wont drop any crates at all on a dedicated server, flys over but no drop or drop message. Missions that did work on dedicated in the past now only work in editor & single player. Is it a fix too far by Bis, instead of "multiple crates" you now get none!