Not really. You can do it IF and only if you have the object handle of the chopper, i.e. you need it to have a name assigned. Besides, enabling the debug console will allow it for all players, which is hardly what you want, especially not on a public server.

Having the debug console in the Edit window of the unit is the only thing that makes sense.

Might or might not be related to this issue http://feedback.arma3.com/view.php?id=16103

May I suggest that instead of "forcefully" changing the player's inventory the mission description should give hints as to the required setup? For example, in the Survive mission "Death Valley", the game wants me to take a grenade launcher and removed my ABR. Instead of this, the briefing could have told me "It is advisable to take a weapon with underbarrel grenade launcher on this mission, since the terrain might give tactical advantages for a grenade launcher". Something of that nature.

The pictures show really good screen space ambient occlusion,
it doesn't look bad.

Quite obviously, "looking good" and "looking bad" is a matter of taste. I think these halos look horrible. I don't want to disable AO because in most cases it looks fine, but these...

You can clearly see that the tank casts a shadow on the ground.
That is made by SSAO/HDAO.

I know how SSAO/HDAO works. The shadow under the tank is fine. The halo around characters, not so much. The halo follows the camera view, which a shadow would not.

Seems to be back in patch 1.50. Was playing the "Infantry" showcase and seeing my team leader shoot at CSAT with P07 instead of rifle.

You might want to try http://steamcommunity.com/sharedfiles/filedetails/?id=182984547, I made that myself so I know it sets the doneKey...

The "completed" mark will not show automatically on a mission. The author has to set a DoneKey for it, and activate that key in the mission, i.e. the mission has to make sure it flags itself as completed.

Might be related to this issue http://feedback.arma3.com/view.php?id=17205

I just tried it with the up to date dev build. Playing a Blackfood on the map and setting "Player as Gunner" exhibits the problem, pressing right mouse button or keypad 0 will zoom the view but will not switch to camera. Once you disembark and get in as gunner again, the controls work as expected.

Still valid as of the latest Dev build. Cannot switch to Blackfoot's gunner view, making the gunner position useless for a player controlled helo.

Seriously, this needs fixing.

EDIT: Getting in and out seems to fix it. Doesn't work obviously when you start in-flight. Really needs fixing.

It seems this issue occurs when the player starts in the chopper.

Great! Thanks a lot!

Completely different stock
Sides of the MX are almost right angles, ACR are 45 degrees
Charging lever is completely different (ACR is non-reciprocating too)
ACR has exposed gas blcok
Don't look at the side view only

Yes, it WOULD be enough reason to fix it but BIS thinks just because this is
futuristic they can do whateverthey want.

Still don'T get why people downvote it.

And check again the ACR. it may have a different foregrip but its almost
the same weapon.

I modelled the ACR, it's an entirely different weapon. The MX looks much more like the XCR than anything else.

dont think this is a balancing issue, just a realism issue.

Isn't that enough reason to fix it? IMO it is

Oh and you wrote earlier:

the MX its not a fictionalrifle, its a placeholder name, the actual rifle
its the ACR

It's not an ACR, and it doesn't look like an ACR any more like a CZ805 looks like an ACR.

Why is this a bug that needs to be fixed? Because it makes stealth based missions pretty much moot. It is no longer a question of situation whether you can risk taking out a guy or not, you will have to ask yourself, is he grouped or not? Because if he is grouped, it doesn't matter where his buddies are, they will know. If they spread out way outside hearing range, if they are guarding a point and sent out a guy to check something, you cannot take out that guy because they will immediately know that the guy was shot.

The argument that you use scripting to alter the group's behavior is irrelevant. If you want naturally behaving AI, you will have to resort to scripting. Take BIS_fnc_taskDefend. According to its description, AI will man static defenses as well as send out patrols. Patrols will be untouchable since you cannot dispatch them - they are grouped and therefore the rest of the group will immediately know.

Another case, setting a group's formation speed to full says the individual members will not wait for the rest of the group. A DISMISS waypoint can have group members wonder off into the distance. Still, all of the group will know about any dead member, because they magically share the information.

@mepwaygame

If you don't have anything productive to add other than calling people named, please go away. Thank you.

If you set a formation's speed to "full" they won't wait for each other, and they might be way out of hearing range. Or there might be background noises, or the guy might fall on soft ground, it doesn't matter.

@mepwaygame
"Here's a point for you: Groups stick together and share information by design. If somebody scripts them to behave differently, then they should have a good reason for asking Devs to change the way it works. "

Picture this, you spot AI that is moving through the forest in a line formation, and you silently pick off the rear guy. Should all the others know that their rear guy is gone? Nope, they shouldn't, but they do. That is because independent of distance or means of communication, AI instantaneously knows that a group member is down.

Added another, even better example. Setup is: One member of the group is on he runway, the other is on Kamino Firing range on the other side of the island. Using Live Feed to get a PIP of the guy. Even though they don't have radios (for real this time) they know instantaneously that their partner got shot, on the other side of the world.

One thing I'm confused about is how everyone is getting these AI groups to
stay spread out.

First you need to remove their "In Formation" state (set to "None"). That means they will be apart, but they will try to get into formation after the mission starts. Simply add a "doStop this" to their init field to keep them where they are.

Attached the sample mission. Issue still persists in latest dev build.

I'm not saying the AI doesn't need an overhaul, but I think the idea is
that groups are in communication with each other via radio.

Nothing wrong with the AI noticing it EVENTUALLY, but not instantaneously. And as I said, the guy didn't have any chance to use a radio, he just dropped dead and didn't even hear the shot.

EDIT: Just tested it, it doesn't matter if AI has a radio or not, they will know about it instantaneously even if they're butt naked.

Made obsolete by latest dev branch. Apparently, modelOptics can be an array now with a separate model for each zoom level.

Actually, it's an old bug that I already reported here: http://feedback.arma3.com/view.php?id=2558

As I wrote in my now closed original , I can observe this behavior on models of my own that have a Stencil shadow lod ('1.000e+4') but no shadow lod ('1.100e+4').

Short barreled weapons must have an advantage over long-barreled weapons, otherwise their presence is kind of pointless.

Good way to reproduce this reliably:

• Go to Multiplayer -> New Server -> Pick an existing editable mission and click Edit
• Grab a single unit somewhere on the map and move it a few pixels
• Press "Preview".

Will instantly complain about "Failed to save mission"

Duplicate of 1679 (http://feedback.arma3.com/view.php?id=1679)

And its 2035....soldiers will all have GPS units to be able to get around.:)

Not as a cranial implant. This should be coupled at the very least to having a GPS in your inventory, but still, it should be able to be switched off as an option. Missions like the famous "navigate by the stars" in OFP or anything like DayZ is going to be pretty ridiculous if you have a large red circle pointing out your location, even if it is only a few hundred meters.

I was thinking about this, and IF the proxies are animatable (as they are in DayZ), this would work - add the following anim sources

• an "opticsMode" source would allow to animate the G33 magnifier to be swiveled up or down according to your mode.
• a "downSights" source would allow to selectively hide parts of the model when the player looks down the optics/sight
• an "opticsZoomLevel" source would allow to selectively hide/animate parts of the reticle that need to be exchanged based on zoom level

Finally throw in a radial blur around the reticle like Project Reality for Bf2 to blur out the outside of the scope

Update: Apparently, animating a proxy isn't possible. So maybe we can extend the way optics are defined like this:
class optic_XXX: ItemCore
{

scope = 2;
model = "state1.p3d";
// ....
class ItemInfo: InventoryOpticsItem_Base_F
{

opticType = 1;
mass = 4;
RMBhint = "Advanced Rifle Combat Optics";
optics = 1;
modelOptics = "";
class OpticsModes
{

	    class Scope
	    {
		model = "state1.p3d";
		opticsID = 1;
		useModelOptics = 0;
		opticsPPEffects[] = {""}; //{"OpticsCHAbera1","OpticsBlur1"};
		opticsZoomMin = 0.0623;
		opticsZoomMax = 0.0623;
		opticsZoomInit = 0.0623;
		memoryPointCamera = "opticView";
		visionMode[] = {"Normal"};
		opticsFlare = 0; //1;
		opticsDisablePeripherialVision = 0; //;
		distanceZoomMin = 100;
		distanceZoomMax = 100;
		cameraDir = "";
	    };
	    class Kolimator: Scope
	    {
		opticsID = 2;
		model = "state2.p3d";
		useModelOptics = 0;
		opticsPPEffects[] = {""};
		opticsFlare = 0;
		opticsDisablePeripherialVision = 0;
		opticsZoomMin = 0.375;
		opticsZoomMax = 1.1;
		opticsZoomInit = 0.75;
		memoryPointCamera = "eye";
		visionMode[] = {};
		distanceZoomMin = 100;
		distanceZoomMax = 100;
	    };

};

};

};

I.e. specify an extra model per optic mode that replaces the standard model when this mode is selected. This way, a G33 scope could be implemented as a second model instead of an animation, and 3D scopes with a magnifier would be possible.

It's a general problem with CfgWeapon items retextured via hiddenSelection.

See http://cloud-2.steampowered.com/ugc/846951660449148539/9E273D818152D4322E475A55AEAA5D632D2C64DE/ for an example of this effect. Note how the sights are flipped up in spite of the mounted scope.

Duplicate of 1679 (http://feedback.arma3.com/view.php?id=1679)

Also reproducible in conjunction with grenade launchers:

• switch to grenade launcher.
• Reload. While reloading, press 'F' to cycle fire mode
• wait until reload is finished.
• Switching with 'F' will "blink" the magazine.

Additional information:
Lens flares can be seen through some objects only. In the screenshot I attached it shines through the HAMR scope but not the weapon itself. I noticed that it shines through my own M4A1 from the FHQ_M4 pack.

My M4A1 does't have a normal shadow volume, only stencil shadow LOD's. Could that be the reason for this?

Duplicate of 1679 (http://feedback.arma3.com/view.php?id=1679)

Duplicate of 1679 (http://feedback.arma3.com/view.php?id=1679)

Duplicate of 1679 (http://feedback.arma3.com/view.php?id=1679)

Actually, the other way around, but the duplicate is assigned.

Duplicate of 1679 (http://feedback.arma3.com/view.php?id=1679)

Here's another link to a post I made on the subject with a proposal on how the system could be modified:

http://forums.bistudio.com/showthread.php?166346-The-Attachments-rant&p=2527582&viewfull=1#post2527582

To clarify, does that mean that, currently, vanilla weapons
cannot accept community attachments?

They can, but you have to override the config entries for the weapons. With different addons adding attachments, this might cause a problem.

Duplicate of 1679 (http://feedback.arma3.com/view.php?id=1679)

This really needs to be fixed. With the sharpening filter, the effect gets even worse.
http://cloud-4.steampowered.com/ugc/540756983672114246/5507AD20656740295914E861AE1EAACE337548FD/