Awesome!!

This screenshot shows the difference between a proper configured GL rifle (example MX) and the Mk20 GL that is missing a hidden selection texture to be able to retexture the GL (EGLM).

Interesting, I use for instance ["end1", true, 0.001] call BIS_fnc_endMission, which works, but it doesn't show the achieved objectives in the final overview. I wonder if it's related to this issue.

Well, my guess is that you didn't try the correct one.

1. Go to the editor
2. Place yourself as an engineer
3. Place one of the *HELICOPTER DLC CARGO NETS*: classname: "B_CargoNet_01_ammo_F"
4. Try to blow it up with explosives, or set damage to full in editor
5. Observe nothing happening, crate and inventory is undamaged and accessible

No mods

My guess is that it is a performance choice to disable all lights during the day. Especially dynamic lights eat a lot of processing power.

Adding:

• attachment functionality to personal weapons
• new weapon configs/ballistics
• new sounds for compatibility with new sound system
• sling loading
• advanced helo flight model
• firing-from-vehicles
• PhysX compatibility
• compatibility with Arma3 characters
• compatibility of textures with Arma3 engine upgrades

There's probably more..

Porting the stuff is a very big project, like the CUP project itsatrap mentions.

'There are minor changes to be made to each object'. I don't agree.

Another reason is a game-technical one: sometimes your character puts the rifle on its back, for instance when using binoculars or pistol. The rifle goes on the right side which would interfere if the launcher was there.

So in the game you have 3 visible weapon slots, rifle on the right, launcher on the left and pistol on the leg.

Even though Arma3 looks very realistic sometimes, these weapon slots are the result that the Arma soldier is still a computer guy which needs some simple places to put stuff without these things clipping (visually overlapping) or using complicated weapon sling simulations.

It nice to find out though that launcher-left is realistic as well for r-handed people.

The same bug is also present for a running soldier without weapons.

I'm guessing! :-) Maybe in MP, flying in fast helicopter, all the soldiers + weapons have to move at same high speed. Like I said, I'm guessing, I can't understand otherwise why the weapons are hidden, it looks so much better with the weapons. :-) And with the right position like you are saying, clipping would not be a big problem.

In some parts of Arma3, the animation is still preserved. For instance in the passenger position next to the driver in the Offroad vehicle. Here it looks very cool, even with longer guns.

I hope all or most cargo positions, in helicopters, trucks, etc. would look like this.

I'm also wondering if hiding the weapons is because of visual issues (clipping) or performance issues, where showing the weapons possibly decreases FPS.

Just to clarify, my mod remark was a suggestion to see how it looks. I really hope this gets an official solution for vanilla Arma; the crew in cargo looked very good in OFP with weapons. The weapons add a big amount to the identity of the soldiers. Besides, you have something to look at all the while, while sitting in cargo.

I'm curious about this case, since I agree that hiding weapons is not a good solution. I looks cool and realistic if soldiers carry their weapons in cargo (like in OFP).

If your ticket is about mods then the developers probably won't solve it. Their solution is hiding the weapons. Then it's better to change this ticket to 'request make weapons visible in cargo OFP style'.

I asked a question about this in the forums once:

https://forums.bistudio.com/topic/183002-mod-for-infantry-weapons-showing-in-cargo/

Every vehicle has a config with this:
hideWeaponsCargo = true;

I suspect a mod with this would make weapons show OFP style without sticking into the vehicle.

I don't understand this ticket, in most vehicles cargo spaces the weapons don't show at all except the ffv positions. Are you using mods?

For simple travel I suggest behaviour 'CARELESS'.

The F18 is a mod, so BIS won't look at that. Please provide an example with a Vanilla aircraft.

You can use the script command flyInHeight to force certain altitude if it isn't fixed.

I agree, the killed-by-blast theory only works for very heavy explosives, like special bombs or heavy artillery. Not exploding trucks. I don't play MP but I can imagine what you describe is an annoying cheat to kill a tank crew.

In real life it is possible to get injured or die from explosion shock waves. For instance in WW I/II there were bunkers that survived artillery/bombs but the people inside got injured or died.

I don't know how much this relates to your described situation although I can imagine the tank violently rocking from the explosion injuring its crew by throwing them around inside the tank.

Or it could be a bug..

Good example, it feels weird being killed in this way.

Hmm, theoretically that makes sense. A red hull is seriously weakened and probably has holes in it or parts missing.

The problem is that violent shaking of the tanks and/or holes in it is not visually represented, leading to unexpected injuries. It definitely feels weird dying from an explosion in a visually undamaged vehicle, this is a problem.

Would maybe a good compromise be for the ai to only shoot with small arms at close range, say closer than 100m? to reflect the desperate attempt?

Else it would be dumb ai reveiling their positions firing at a vehicle they know has armor protection. And ineffective firing with the Lynx at the whole vehicle, not specifically the weak parts would be annoying as well if the Lynx guy is on your side.

I get your point Gilatar, but be careful what you wish for. In an earlier version infantry did fire at MRAPS. However, if they just fire at the vehicle, it is very ineffective.

I was very irritated in missions where I liked to ambush MRAPS with launchers, but my squad opened fire with small arms, before the launchers could fire. This usually led to the squad being detected early and wiped out.

This is a delicate issue. It used to be the other way around where ai where firing pointlessly on armored vehicles and getting wiped out before the AT guy could launch. I don't want that situation back!

It would be nice if AI fired and have a good opportunity to destroy MRAPS with high-calibre weapons.

This is intended behaviour and not a bug. It is implemented to prevent you getting addicted to the editor and spending too much time with it. ;-)

Hmmm, I get your point better now. If you use fog and want to measure exactly when a enemy is hidden or not you would want to 'toggle' the visibility. My bad weather missions don't depend on such specific placement but I can imagine others will.

I'll be a good sport and change my downvote ;-)

Why don't you use a text editor to edit your missions? I think, it is not that hard :)

This is not true of course, but I see the smiley :-)

implementing a functionality that takes less lines of code than the "creative proposals"

This is also not true of course, it's a hyperbolic statement not grounded in reality

I for example like to give some thoughts to the weather settings and daytime I use for my missions, so I spent quite some time tuning it.

I get this, I do as well. But whats stopping you from making some notes of the settings or taking a screenshot, it's really easy compared to many other things that need to be done to create a good mission.

I'm not convinced yet that your suggestion would be a useful addition. Maybe it boils down to different opinions.

I don't understand why this needs a special command. You edit the mission in clear weather and when you're finished (and a couple of times in between to check) your configure the bad weather.

If its super-important for a very special case you can script the thing you want, but I do not prefer devs to spend time on this.

The armor engine behaviour is far from optimal. Often they go to fast and flip. But it requires a good solution not a simple one.

The engines have incorrect gear functioning giving them actually weak acceleration and traction. Just drive around in an armoured vehicle off-road and you'll see how slow you will go and you will hear high-pitched engine noises and weird gear shifting.

Increasing their mass would make this problem even worse. The game-engine has actually trouble with armored vehicles because of tracks/high mass. It was designed more for normal cars.

The tanks need powerful engines but reasonable speed.

Armored vehicles bump into each other and flip over as well because of this. Especially when going downhill.

'Ok squad, our Hellcat will transport you to the LZ, it's a new prototype and it should be able to get us there in 3 seconds.'

duplicate of #5927, please use search before making a ticket.

I looks cool and is realistic, however I suspect problems with launching the missile into the ground by mistake by AI and players. The game is too 'rough' to allow for this fine tuned position. The resulting problems would create a lot of extra work for the devs. This is my feeling why it was never implemented.

An Oshkosh M-ATV (Hunter) weighs 32,500 lb (14,700 kg). A Chinook (Huron) sling load capacity is 26,000 lb (11.600 kg).

This is my examination of 5 minutes of Googling. ;-) Remember that a Hunter is not a WW2 jeep, it's a big, armored all-terrain vehicle.

And if you were thinking about a helicopter carrying a tank. No.

I didn't even have to look at your videos to know what you're talking about, I already know what it looks like. Blown up ammo crates go crazy!!

Very unfortunately for missions where you have to destroy enemy ammo supplies.

It's great help when people take the time to make a video of the problems.

Maybe in other words, I don't want to watch the videos, because I know about it and seeing it hurts my eyes.. :-) BIS please fix! :-)

Using the search function is as easy as 123! :-)

Glad you are aware of this and I hope it will be fixed!

Demo mission uploaded: a Cheeta and a hovering Huron set to 'CARELESS';

Let your gunner engage the enemy. Move your commanders view (1st person) around and zoom like you're keeping an eye on your surroundings.

After a while the bug appears. 100% reproducable for me

In the second movie look at 2:47. Your gun sight is still obscured. So it helps, but not much.

I don't understand your demo in the arsenal, trying to shoot people in the head from a large distance. This is totally unrealistic for actual combat.

It's fine if you want to shoot like that, but that's target-shooting, like a sport. For sport-shooting you don't need a suppressor.

This is just a joke from Cheese or one of his friends. If this is an Arma bug I will eat my X55 HOTAS.

Aha! now I see. Cargonets and Launchers containers have wrong content.

The ticket is a little unclear to me. It's clear that the cargonets do not have right cargo. This could be a ticket: fix content cargonets. But is there something independently wrong with launchers? I don't get it.

UPVOTED

Most of the armored vehicles have this problem, especially going (slightly) downhill and cornering. Learning the crews how to break more gradually in the corner and/or drive slower would help.

As a work-around I set vehicle speed limiter to for instance 30 km/h with scripting: LIMITSPEED

It would be a whole new kind of gameplay, requiring a whole new game (Arma4) ;-)It would be a cool feature though.

Just to be clear, I mean no offense and nothing personal. I understand that my point of view seems egoistic to you, but that's how the voting system works in my opinion.

I voted down because it is of no use to me. If a hundred people also vote down, then it means that nobody wants this.

If I'm the only down-vote and you get a hundred upvotes and BIS would start working on it, then I would accept it and would be happy for the community even though it is of no use to me personally.

In my current setup:

• I scroll my mousewheel to activate the menu and scroll through the actions
• I press the mousewheel button to select the action and the menu automatically disappears

This feature request kind of suggest the same thing, but is talking as well about blocking player movement and different keys while the menu is open or something like that. I don't see a clear benefit at this time.

I gave a downvote to discourage BIS to spend time on this and instead work on other things that are of more use to me.

I hope this explanation helps.

I don't see what is really and absolutely great about this at all.

Yeah soldiers fly up. To me it seems this behaviour was also seen a couple of versions ago then fixed and now it's back.

Yeah, this is getting pretty annoying. Reminds me wearing soft contact lenses which can become blurry when they become dirty or fold a bit. Therefore in Arma3 I have the tendency to start blinking to get a clear picture back :-)

My guess is that most sound related bug reports will be closed, because they're not considered bugs but work in progress. Maybe another type of closed would be more appropriate than 'resolved'.

The current soundsystem is very experimental. Even though, in my opinion, it's unfortunate that its added to the non-dev game (stable branch), it's because it's longterm development that is added throughout the year. BIS has a small sound team, but it's aware of all the problems and working on it.

For details:
http://forums.bistudio.com/showthread.php?154605-Audio-Tweaking-%28dev-branch%29

I agree with Mickeymen. AT ammunition is not effective against infantry means that it is not worthwhile to use these in comparison to other munitions. It doesn't mean it is literally ineffective, they are still explosives.

With the grenades I can accept that 'future protection' is better, but if the grenade is really next to the enemy and he doesn't die? Still a bit unbelievable.

I can confirm it usually takes two RGO's (the larger grenades) to take out an OPFOR dude.

When I have to clear buildings I always make sure I have the larger grenades on me and often have to leach more grenades from my AI team mates to clear multiple buildings.

I throw them accurately: I go inside building until I have visual contact with enemy -> throw grenade -> look again, see that he's alive -> throw another -> now he's dead.

The grenades seem underpowered, with enemies surviving the blast indoors from a grenade a few feet away.

I agree, they sped it up one time to get it closer to the faster speeds of the other walk/run modes, but it looks a bit unnatural and I prefer the slower speed.

I think that 'acknowledged' means that they have read your ticket and understand it, nothing more.

Thanks Koala, confirmed.

Koala, while doing these tests I noticed another issue: double engine shut-down sounds for the UAV, at least with 3rd person perspective. Did you notice this as well? If this is consistent I'll open another ticket for it.

Did some more testing:

1. Koala's test was replicable
2. My test was replicable as well. The difference is that I have the last waypoint on 'CYCLE' to create a custom loitering pattern

Using the CYCLE waypoint results in the situation that there are always waypoints for the UAV. This causes the UAV to take off on its own after landing in two possible ways:

1. With 'AUTONOMOUS' ON the UAV returns to its cycling waypoints
2. With 'AUTONOMOUS' OFF, the UAV takes off and starts a default loitering pattern around the airfield

In fact, 'AUTONOMOUS' ON always activates attempt to fly along waypoints, or straight on if there are none. 'AUTONOMOUS' OFF activates default loitering pattern.

I did manage to ground the UAV permanently WITH active (cycling) waypoints by deleting the waypoints with a script during the flight, proving that the active waypoints lead to the UAV taking off without permission.

My conclusion:
Taking off with 'AUTONOMOUS' OFF makes little sense to me. Especially in combination with the fact that this is caused by remaining waypoints which the UAV will ignore anyway and will start default loitering instead.

Possible solutions:

• Setting 'AUTONOMOUS' OFF deletes active waypoints
• UAV is not allowed to start engine on its own

What do you guys think?

Re-reading your post Koala I noticed 'You have to make sure, that all waypoints are canceled before landing.'

I didn't realise you can cancel the waypoints yourself with the UAV terminal, even with cycling waypoints. So fortunately you can make sure yourself that all wp's are gone before landing, to permanently ground the UAV. UAV's are stubborn indeed.. :-)

It doesn't move to (old) waypoints. It ignores the waypoints and start circling directly after take-off.

Even if there are waypoints in its wp list, I think its wrong if it takes off and moves to waypoints on its own if I unchecked its 'autonomous' function.

I will try the 'never fire' option. Notice however that this situation can be replicated without enemies on the map.

Thanks for replying. You start with the UAV flying a holding pattern (created in the editor). As the player you decide you're finished using the UAV and want to send it to the airport. You uncheck 'autonomous' and select auto-land. The plane lands. You shut down the engine. You release the controls to go do something else, but the plane starts up its engines and takes off again without your permission.

This situation is reproducible with a UAV starting in the air. If you put a UAV on the ground at the airfield (without waypoints) it won't take off on its own.

So yes, unchecking 'autonomous' at one time or another won't prevent the UAV to take off on its own under certain circumstances.

Can happen in single player as well, for instance in the editor. I think there is a related ticket on this subject that explains it better, you might want to try and find it.

I've been fidgeting with the sounds and I've got two tips for people who were underwhelmed like I was:

• play the sounds loud on a good sound system and/or with good headphones and maybe play around with your sound settings (equalizer)
• I had some good results with for instance LAxemann's Enhanced Soundscape (L_ES) to improve some of the sounds. The different sound mods have their own issues though, so these are not the final answer as far as I'm concerned

Just to clarify, I'm not happy with some of the current sounds and especially that some of them seem to be missing their effects. Of course I am happy with BIS taking on the complicated task of creating a more dynamic and realistic soundscape.

Thanks for your reply pops, I've read that report when it came out. It says among other things:

'Of course, this development is work-in-progress'

It surprises me that incomplete sounds are added to the public game, I feel that this type of work-in-progress belongs in a testing area. I am the kind of player that doesn't participate in pre-alpha's in general or the dev-branch here. I'm willing to wait for features to be as complete as possible.

I play Arma3 a lot, it is my favorite game by far, and thus I am aware that, in a sense, the whole game is a work in progress. But this is a step to far in my opinion.

So, then, when can I expect the next update that has new improvements on the sound?

It's the same for the (double) 20mm AA guns, they have a very unimpressive sound.

I uploaded a picture demonstrating this behaviour combined with another flaw: the grenadier fires in different directions because he fires before reloading/moving animations are finished.

It can be very frustrating seeing the ai firing useless smoke grenades at the enemy (or all over the place).

Or maybe just force 'AWARE' mode. You can order this, but they refuse because of simulated 'human feelings' which doesn't work in the game.

If we could just force them in 'AWARE' mode, even erase their 'knowsabout' information, you could get your squad running again. It's even realistic, it's like the commander saying 'Forget about the enemy, just keep moving!'

In one of my missions, my ai squad and I approach a hill from 1.5km with enemies behind it. If one of the ai enemies is on top of the hill by chance and can be seen by us, we're screwed. Nobody is firing, not us, not the enemy, because the distance is too great, but the squad goes very slow because of the detected enemy and it takes a very long time to cross the distance.

It's not fun at all like this, especially because it seems so unnecessary. I really hope this gets fixed someday.

Lots of interesting mission scenario's suffer from this:

• Fast extraction (like mickeymen describes)

• Suppress and flank: the flanking forces refuse to move fast, even when only encountering very light resistance (like one or two enemy soldiers). Result: everyone dies because the manoeuvre depends on speed.

• Advance after key target is destroyed: waiting for an enemy tank to be destroyed before moving on. Your squad sits around as you wait for the AI anti-tank team to very, very slowly move to the position where they'll take out the tank (because they came briefly under fire).

There is potential for amazing dynamics in (infantry) combat in Arma 3 like suppressive fire, taking cover, flanking, detecting enemies etc. The possibility to move at speed (under fire) is very important in these dynamics and is currently lacking.

Upvote, very much needed. I like behaviour name 'BREAKTHROUGH'. Other suggestions: 'COMBATMOVE', 'MANOEUVRE', 'HASTE' or just 'MOVE' perhaps.

I gave you an upvote, but don't agree with everything you said.

con:
With the helicopter for example: with an invisible LZ object you can pinpoint exactly where a helicopter should land, have you used this?. And you can get very far with some basic scripting. I feel that if you like to make any kind of interesting convoy / patrol / insertion behaviour, you should be able to make some scripts. It's often easier than creating a clutter of waypoints and triggers in my opinion.

pro:
I agree with you that some things could be improved with regard to convoys/transports:

• helicopters still land awkwardly since OFP, soaring high in the sky before landing.
• AI driving is often a mess with braking, taking corners, avoiding obstacles. One relatively simple fix I would like to see is that vehicles maintain speed better and don't bump into each other in convoys when for instance going down hill.

I'm not really sure about this one. You would like the infantry to recognize buildings and move into them for fire positions?

I use a script to place infantry in building positions where they will fire out of the windows. These positions are snap positions that each building already has. I'm happy with this, although it is a limitation that they have to placed there by the mission planner.

The doFollow and commandFollow commands are 'return-to-formation' commands and they are meant to be used within a group.

I use scripts to position soldiers from a group at different guard points and stay there. When it is time to move out, I use commandFollow to restore the original formation.

I see your point at wishing for groups to follow other groups. As long as there is no specific command to do so you might want to use scripted waypoints with game logics. They allow for much more flexibility and you can use this to give different groups the same waypoints.

I just played a mission where this problem plays again, ai team members getting far behind because they were just in a fight and now stuck in danger mode.

Suddenly nr 2 yells 'clear!' and I'm thinking: I am the leader and I yelled 'clear!' 10 minutes ago by setting behaviour to 'aware', why can't they just follow my orders!

Please post personal frustrations towards BIS elsewhere, BIS is working with lots of restrictions. Inflammatory comments will not persuade its staff to work on issues we find important. Even though I'm sometimes frustrated too, Arma3 is still a great game.

@Vlad: strange circles is ai moving to 'get in' point for vehicle. It's a bit wide, but that prevents them getting stuck on obstacles (such as the vehicle itself). I think this is intended behaviour and I personally don't mind it, even though it looks a little weird.

@maciek: AI not moving is something I witnessed myself. I think the cause is not the same thing as the slow-moving behaviour. My guess is that AI sometimes has difficulty selecting a path and gets stuck, even though different paths are clearly visible to the human eye. You noticed it with ungrouped AI as an example. I notice it in squads as well when I'm the leader. Sometimes I have to switch to the stuck soldier to get him going. Your example sounds replicable, so that's possible valuable.

I made a similar ticket about this previously: related to #0021222

• I recognize these problems looking at your vid: It's hard to pinpoint the exact problem, but I believe that AI normally likes to move in formation, and when this is not possible they go in a slower movement mode which is recognized by the 'raised rifle' jogging.

I've seen similar behaviour on open terrain where you run ahead of your squad. They feel like their loosing formation and revert to the 'raised rifle mode' which is very slow and fatiguing while they should be running with rifles lowered to catch up with you.

Another problem that's hard to replicate is that some soldiers seem to get stuck in the 'raised rifle' mode, making it impossible for them to move fast. Even if you player-switch to the unit and lower its rifle the unit will raise its rifle when you switch to your original character. This can happen no matter the behaviour mode.

@Vlad
I think this is intended behaviour and I personally like it. The squad has an internal hierarchy. If I'm not the squad leader but the second in command, I can deviate from the squad route and take some guys with me.

Yeah, same thing with me: 1.38 single player; editor; no mods

I don't find the protection argument very strong as the helo provides very little protection inside or outside.

Your second argument on the other hand is a very good one, in reality it would be hard to get inside with soldiers on the benches. I didn't think of that.

Yes this please. It is very hard to make the AI approach and move away from a beach with the biggest threat is beaching. If that happens you lost the boat.

To be fair, the Ifrit probably had its windscreen wipers on, witch brushed away the explosion ;-)

Thanks for taking the time to make this clear video, upvoted.

The static launchers need their own tickets, it's something different.

This is not my experience, AI definitely seek more cover in Combat mode en they scan better for enemies, for instance behind them. They will also move with me (as their leader), even if it's a bit on the slow side.

But this ticket is not about that, it is about longer range covering of ground, say 500m for instance. The ai will get a bit stuck in aiming down the sights while moving which is not appropriate in that situation.