We already have many of the effects described in this ticket (broken windows, smoking engine, damage textures). They just aren't noticeable enough (or nonexistent). The main problem is that vehicles explode. It's fine if there's a fireball, like when the fuel leaks out and starts burning, but vehicles don't explode unless they have something to make them blow up (stored ammunition). Sure in "The A-Team" they do, but that's because they are loaded with Hollywood explosives. What I am saying (mainly), as represented in this ticket, is that the crew really shouldn't die from an explosion when the vehicle is dead. RPGs or AGMs are what is going to kill the crew, not the vehicle itself.

I wholeheartedly agree. I noticed that the karts have a different damage model than other cars, only catching on fire when critically damaged. Maybe that can be adopted for all unarmed vehicles.

I'd like to be able to escape a burning vehicle and not having to worry about a detonation 5 seconds later. A detonation (velocity of expanding gases and thus shrapnel exceeding 1 km/s) requires proper explosives to be present, while fuel usually burns with a much lower speed (so called deflagrations, velocity several m/s). This difference is what makes a deflagration usually survivable, especially given proper clothing (kart overalls).

Yet not voted.
You are right in many parts, but I think, if deprive the vehicles explosions, then this will create many additional problems.
In this case, will need to add a huge number of effects of the damage to each vehicle! This is a broken glasses, the destroyed out doors, damages textures, effects and may be deformations of the vehicle case.
It will be a huge of work and it is unlikely and unfortunately the developers will want to do it!

Related: https://www.youtube.com/watch?v=jGSNbuj4hYE

^Damage model right now^

Thanks for all your effort, you've got some truely amazing ideas there. I hope BI get to see that.
#UPVOTED

That is supposed to state "instances of crashs". Should have been more thoughtful with wording - fixed in above thread.

We are running a maximum of 3 production arma3Servers per physical server. For a grant total of 5 production arma3 servers and 2 testing instances (only active when needed) .

Even if it where "8 instances on 5 servers", that is 1,6 arma instances per machine. But lets not split hairs here.

This is not a "hardware overloaded issue". It is about Arma3Server gobbling Ram like its candy, 6 times faster then it used to do (1.24), and the server then becoming stuck and not even crashing, so you can only see that something is wrong, by you joining the server and getting infinite loading screen.

You're running eight instances on a E3? That is overselling those machines I expect you to have performance issue OR your customers if they fill their servers at the same time as other instances, you're pushing it with four full instances.

pretty sure this has been fixed since 1.30 . At least it has not appeared since then.

@Iceman

running one server without BE now. Will report back with news.

The BattlEye disabled server has now become stuck in the same manner.

disabling BattlEye did, as predicted, have no bearing on the servers crashing.

Still happening. we have got 8 occurances of crashs on 5 different servers (windows 2012 / Ubuntu Wine) where it has happened during last 2 days.

Hi there,

May I ask some questions.
What mission is it that you're running?
How many objects does the mission have?

Other than the server side crashes you're getting those memory figures are normal for Altis. I have several servers that reach that working set quite easily.

Just for verification, could you do a file integrity check, it seems odd that you've started crashing server side after a clientside update.
Since the A3 server does not use the client.dll something else must be at fault here.
Could you also re-download the server.dll http://www.battleye.com/
Place this in the working config DIR/BattlEye.

I managed to create a Manual Dump of a stuck arma3server.exe:

Taskmanager --> Detail --> Arma3server.exe -> Create Dump File.
It is 90Mb packed in RAR (1.7 GB unpacked). It is available on this download link:
https://www.dropbox.com/s/dciovms1qu5vwph/arma3server.manual.Dump.rar?dl=0

When i then tried to analyze the "wait chain", it caused the arma3server.exe to crash and create a crashdump.
It is available here:
https://www.dropbox.com/s/6zuvik7y91dsixk/server_4_Crash_-08_09_2014_infinite.zip?dl=0

Hey,
could you please try to reproduce it with Battleye disabled? We don't think it should depend on in but we'd like to be sure about it.

Thank you very much!

Ok crash does not happened again after removing that launch parameter.
fixed!

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.

thanks I will try it.

Hello,
does it still crash when you use default allocators instead of system? To try it, remove all starting parameters.
If it crashes, please upload new crashdumps. Thank you very much.

swissMAG: Thanks for proving me wrong on the single versus double pilot seat scenario. I guess it's up to BI to explain what they're thinking here.

I didn't realize there was a "full throttle" key. It would probably be preferable for it to be remapped by default, but doing so would possibly create a scenario where players cannot get going forward when their jet is at a full stop. (ie. Sometimes the jet will not move forward with a joystick throttle at full, until the "full throttle" key is actuated.) Probably best to fix this bug first, then remove the mapping of "full throttle" as it definitely conflicts with virtual way point mapping.

Lex: Can you remap the "Collision Lights" action? Can you remap the Shift key for performing the Shift + "Left Mouse Click" keys?

Shift + "Left Mouse Click" - What does the keyboard shortcut? It is not in game management. The game is not working.
On the Shift key you configured Chat?
What is the second function of the Shift key is you?

rogerx: Any action is easily reassigned.
Any repetitive actions highlighted in red. You decide to leave everything as it is, can you do to prevent the management, or assign another key.
https://www.youtube.com/watch?v=pT5AqDBOT54&feature=youtu.be
I changed all the keys in the game, the standard scheme does not suit me.
The keys have two functions are configured so that in certain situations is performed only one function is available.

Any key or combination of keys, you can change the function. You can set the 2X "button" any function.
Assign a "chat" to another key problem?
Remove with a function key, which leads to an accident.

Lex: The "chat" key is CAPS LOCK.

Not every key of the keyboard, nor can every action be remapped within ARMA 3.

"May later suggestion is probably why this bug is being ignored, as real pilots likely truly hand over the controls versus trying to fly while reading a map or their favorite magazine!"
Well, what about A-10 pilot or an F-16 Pilot? Both are flying solo. And they can control their CDU (basicly writing message, receiving 9-Liners, typing in flight plans) or take a look at their TAD (Mapscreen) for the next waypoitns. Another importend point is the control of the radio panels which comes with ACRE2/TFAR.

This argument was always brought up and its just nonsense... and definitly not an excuse why a aircraft should loose its throttle/collective response while in a dialog. Sorry mate.

I do not get whats your issue with the waypoint is? Even if you are pressing full throttle (with your shift) why would you press your LMB while on the mapscreen if you didnt want to create a waypoint? Putting down a marker maybe? While you cannot change the Shift and LMB to make a waypoint, you can change your "full throttle" Key.

In Arma 2 this issue was also occuring when opening the map... At least one of the things were fixed...

Please continue to fix all the dialog & Chat promts also.

Thank you.

Whats even worse, SHIFT+"Left Mouse Click" on the map creating a virtual way point while on the ground or while flying elsewhere.

The SHIFT action is mapped to "full thrust" and the fore mentioned "create virtual way point" action; and can easily lead to critical adverse reactions while piloting.

WORKAROUND: A good workaround for preventing all the related bugs here, maintain a safe operating altitude while viewing the map. (ie. At least greater than 1,000 meters.) And as far as the SHIFT+"Left Mouse Click" altering the thrust or altitude of the rotary wing aircraft, just be aware that this might occur while on the ground and expect this to occur by immediately returning from the map after using SHIFT+"Left Mouse Click". Immediately actuate the throttle controller to readjust the thrust and return to the map as needed. All the workarounds are not flawless and still inhibit risks, such as travelling at higher rates of speed at only 1,000 meters. If I'm not mistaken, the SHIFT key cannot be remapped to a CTRL or ALT key, nor can the SHIFT key's thrust action. Another solution I later thought of and noted below, "the pilot could also hand-over the controls to the co-pilot while he created his own virtual way point or viewed his map, then have the co-pilot hand back over controls."

Another idea, is to turn the engine off prior to looking at the map or creating a virtual way point, but this sounds a little absurd! The use of a co-pilot is ideal, but the co-pilot cannot create a virtual way point on the map for the pilot. A previous bug is or was already opened for the allowing the co-pilot to create a virtual way points for the pilot, but is or was likely disregarded due to time or closed. I guess the pilot could also hand-over the controls to the co-pilot while he created his own virtual way point, then have the co-pilot hand back over controls. But I think players are not going to adhere to a strict regime of flight operations.

May later suggestion is probably why this bug is being ignored, as real pilots likely truly hand over the controls versus trying to fly while reading a map or their favorite magazine!

Still happening in the actual 1.48...

Happens with any menu prompt. (ie. ESC Menu)

The same happens if any scripted dialog is shown. When using the joystick as your control input for collective, you start falling out of the sky at a rapid pace. If you are using your keyboard (default settings), this doesn't happen, the helicopter seems to keep its altitude for the most part.

Joystick pilot that opens a dialog > likely to die.
Keyboard pilot that opens a dialog > likely to live.

Is this going to get looked at? Its still "new".

FYI, I have seen other BIS functions incorporate the same workaround / fix (check return value for nil before returning it).
I think getting this to behave the same in both scheduled and un-scheduled environments would be preferred, ideally so that one can return a nil variable without having to check for it, but I'd take it the other way around if this means we get some consistency here.

Closing on author's request.

Withdrawing this feature request.
This ticket can be closed.

According to the ticket author that issue got resolved.

Lol, knew you guys would be all over it! Thanks for the update!

Should be back to "normal" :)

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.

As well as 'Supply Network' - actually makes the mission unplayable! (Switching to Stable, I'm sure it'll be fixed soon!)

Thank you for the report!

Was introduced by recent AI fixes/optimizations. We're on it!

By the way BIS, this bug totally messes up the convoy behaviour in "Moral Fiber" from the WIN episode.

Yeah, as Armadillo says, I'm sure it'll get a quick fix!

I've noticed that on Dev Branch. AI pathfinding on roads has gone very strange.

I thought this was just happening to me on particular bit of road. I've got some APCs driving up a steep hill, and they keep swerving off course and rolling off the edge. I had to put down concrete barriers to stop them doing it, but then it got worse after the recent change relating to AI walking through editor-placed objects. After that, the APCs started trying to avoid the barriers and ended up going up the hill on the other side of the road.

Yes, it seems AI vehicle movement on roads is er, not right. Any idea if this is just Dev Branch tweaking?

Ah - noticed it effects everything, cars included - guessing this might just be a devBranch, WIP thing!

I've uploaded a picture - you can still see the tank tracks - but I've added a yellow line to show the tank's path.

http://feedback.arma3.com/view.php?id=24256
Closed a subject??? What in it not so? I think Army3 have no prospect of the solution of a question of productivity. Excuse for criticism. But it is the fact, to ignore
"2569 vote" in a subject

arma 3 PIP sucks, end of story