blood spurts happen in anime and hollywood, not in real life. In real life blood seeps, except in the case of limbs being lost, or bullets going through heads. Especially for typical military small arms calibers, bleeding won't even start instantaneously, as a bullet will temporarily seal off capillaries and other blood vessels from the pressure of its passing. The most that could be done to make the system more realistic would be to have blood drip off of wounded arms and legs.

Reproducible in the attached mission with extended armor either on or off (does not seem to make a difference). Shoot a civilian in the small of the back (right where his belt would be). Takes two hits to kill. Shoot opfor at same location, or even further down toward the legs, and they die in one hit. At these short ranges, a shot to the upper torso will kill the civilians in one hit, but at further distances it often takes two hits.

I'll see if I can create a repro map or video. Will check the extended armor settings.

Supersonic Scream! Worthy of Guile!

the grenades are generally underpowered. HOWEVER: exploding vehicles is not necessarily realistic anyway, as an explosion of an aircraft will generally only happen if the fuel tank ruptures (massively) and spills tons of fuel all over the place at once. In general, a grenade, or series of grenades, would most likely puncture, rather than fully rupture, a fuel tank, causing fuel to spill out and maybe catch fire and commence burning. The fuel used in US aircraft is called JP-8, and is more akin to diesel, than to gasoline, and is very difficult (might be impossible, not sure) to cause to explode. It's definitely NOT high explosive. Just a note.

how much more to the right? 5 degrees shouldn't make much difference, but 25 will.

I've uploaded a mission with targets at 100 through 1000 meters on the runway. Please give this a shot and see what your results are. You may need a friend to spot for you, especially for the fart argets. In my own testing on this mission, I've found that the bullet may strike low, typically by one, maybe two meters, at long distances. This may be dependent on the shooter though. I've had results varying between spot on and low strikes.

Tested with hamr on the mxm also, and the results were remarkably similar to the regular mx, despite different ammo. Have not tested with Arco yet. Can you guys tell us specifically which weapon and scope combination you're getting this problem with? Also, are you using suppressor s, or not?

also be mindful that if you have altered the default field of view for your player, it will throw off the scopes.

Tested with Hamr and 6.5mm ammo, no problems. My guess is that you might have been using the ebr or mxm. In those cases, the 7.62x45 ammo they use has a different characteristics than the 6.5x39, and so, the scopes being configured for the 6.5 round, will not produce accurate results for the 7.62. For comparison, the velocities are both 795m/s, but the airFriction coefficient for the 6.5mm is -0.00096, whereas for the 7.62 it is -0.0009324. Not sure how the ballistics algorithm works, but I'm going to guess that the 7.62 has less drag, and therefore retains more velocity at a given distance compared to the 6.5. This would result in 7.62 rounds striking high, compared to 6.5.

fuck no.

ai hacks, didn't you know?

but at any rate, I kinda doubt that STANAG says anything about tracer packing order. Could be wrong, but it mostly applies to manufacturing specifications and interoperability between NATO countries, and how you pack your tracers isn't really that critical of a detail.

Regular 30 round 6.5 caseless mags for the MX series are labeled as STANAG in game. Those for the Katiba are not, nor are the mags for the TRG rifles. 30 round 6.5 caseless tracer mags for the MX series are not labeled as STANAG, but we can presume that they also are, since their picture is identical, and they go in the same rifles.

Ok, so I was in an infantry company while deployed to Iraq, but I was a communications soldier. My experience was that for going out to the range for qualifications, etc, we just used regular ball ammo. When deployed, if I remember correctly, we were issued both ball and tracer ammo, and were instructed to load every fifth round as a tracer. This was in 30 rnd stanag magazines for an M16A2. I don't know what the infantry guys were carrying (many of them were rangers, so that obfuscates things even more). If I recall from my M249 qualifications, those belts also had a tracer every 5 rounds, I THINK. It would be nice to get some input on this from current service members, both infantry and non-infantry.

At any rate, for use in suppressed weapons, where stealth is important, there shouldn't be any tracers. That said, we don't have subsonic ammo yet, so I expect that when subsonic ammo is added, it will not have tracers in it.

I just saw this happen myself. I'm not sure of the conditions, but it looked like it was a non-tracer 100 rnd stanag, and it appeared that the tracers appeared every other round, or so.

Here's the latest class for the 100 rnd stanag:

class 100Rnd_65x39_caseless_mag: CA_Magazine
{

		scope = 2;
		displayName = "$STR_A3_CfgMagazines_100Rnd_65x39_Belt0";
		picture = "\A3\Weapons_F\Data\UI\M_100Rnd_65x39_CA.paa";
		count = 100;
		type = "2*		256";
		ammo = "B_65x39_Caseless";
		initSpeed = 850;
		tracersEvery = 4;
		lastRoundsTracer = 4;
		nameSound = "mgun";
		descriptionShort = "$STR_A3_CfgMagazines_100Rnd_65x39_Belt1";
		mass = 20;

};

As you can see, it's set to tracersEvery = 4; That would account for the behavior I observed, but not sure about what the OP saw.

The last five rounds in a stanag 6.5 magazine are intended to be tracers. Is this what you're seeing, or are you seeing the whole magazine being tracers?

But I love my guided missile rocket propelled grenades!

also be mindful that if you've altered the default field of view, it will throw off the scopes.

Please use the attached file to run tests. It provides targets at a known range from the player, and on level terrain. Give it a shot and see what your results are.

This ticket is a duplicate of http://feedback.arma3.com/view.php?id=6678

Heh, hadn't thought of that. :)

No way to stop drop and roll, so it would be really annoying if you accidentally got too close to a fire and start burning with no way to stop it. Maybe if an "Extinguish Self" menu item were added, similar to the treat self item.

Ah, that looks awesome.

If English is not your first language, Google Translate is your friend. Your sentence is meaningless as it is.

Also, if someone can test in-game to verify the state of the problem, that would be great too.

I'm not sure it's time to close this. I just checked the files, and the entries now all look about like this:

			class MagazineCoef
			{
				initSpeed = 1;
			};
			class AmmoCoef
			{
				hit = 1;
				visibleFire = 0.8;
				audibleFire = 0.6;
				visibleFireTime = 1.0;
				audibleFireTime = 1.0;
				cost = 1;
				typicalSpeed = 1.2;
				airFriction = 1.2;
			};

So the Hit and initSpeed coefficients are set to 1, but the typical speed has been increased by 20% above base, as has the airFriction.

I don't know the details of how these values interact, but if typicalSpeed = 1.2 means that a silenced round gets a 20% boost to velocity, then I think that's pretty unrealistic. 1.02 seems like a better value for this, if I'm understanding it's use correctly. And as far as the airFriction.... I don't know how that one is used. If it were a frictional coefficient as in a normal physical simulation though, it would be dependent only on bullet geometry, maybe rotation speed. I don't think any ballistics simulation appropriate to real time use would need to change the coefficient of friction with speed. BUT I'm not sure.

Could we perhaps get an informative note of explanation from the devs about these variables, please?

The following code is extracted from weapons_f.pbo, with the further path weapons_f>a3>weapons_f>acc>config.bin

class muzzle_snds_H_MG: muzzle_snds_H
{

		displayName = "$STR_A3_cfgWeapons_muzzle_snds_H_MG0";
		picture = "\A3\weapons_F\Data\UI\gear_acca_snds_H_MG.paa";
		model = "\A3\Weapons_F\Machineguns\M200\lmg_suppressor";
		class ItemInfo: ItemInfo
		{
			mass = 5;
			class MagazineCoef
			{
				initSpeed = 0.6;
			};
			class AmmoCoef
			{
				hit = 0.8;
				visibleFire = 0.8;
				audibleFire = 0.6;
				visibleFireTime = 1.0;
				audibleFireTime = 1.0;
				cost = 1.0;
				typicalSpeed = 0.6;
				airFriction = 1.0;
			};
			muzzleEnd = "zaslehPoint";
			alternativeFire = "Zasleh2";
			modes[] = {"manual","close","short","medium","far_optic1","far_optic2"};
			class manual: Mode_FullAuto
			{
				reloadTime = 0.075;
				dispersion = 0.00093;
				recoil = "recoil_auto_mk200";
				recoilProne = "recoil_auto_prone_mk200";
				begin1[] = {"A3\sounds_f\weapons\silenced\silent-25",0.8912509,1,200};
				begin2[] = {"A3\sounds_f\weapons\silenced\silent-26",0.8912509,1,200};
				soundBegin[] = {"begin1",0.5,"begin2",0.5};
				closure1[] = {"A3\sounds_f\weapons\closure\closure_rifle_2",0.70794576,1,50};
				closure2[] = {"A3\sounds_f\weapons\closure\closure_rifle_3",0.70794576,1,50};
				soundClosure[] = {"closure1",0.5,"closure2",0.5};
				weaponSoundEffect = "DefaultRifle";
				soundContinuous = 0;
				soundBurst = 0;
				minRange = 0;
				minRangeProbab = 0.3;
				midRange = 5;
				midRangeProbab = 0.7;
				maxRange = 10;
				maxRangeProbab = 0.04;
				showToPlayer = 1;
			};
			class close: manual
			{
				burst = 10;
				aiRateOfFire = 0.5;
				aiRateOfFireDistance = 50;
				minRange = 10;
				minRangeProbab = 0.05;
				midRange = 20;
				midRangeProbab = 0.7;
				maxRange = 50;
				maxRangeProbab = 0.04;
				showToPlayer = 0;
			};
			class short: close
			{
				burst = 8;
				aiRateOfFire = 2;
				aiRateOfFireDistance = 300;
				minRange = 50;
				minRangeProbab = 0.05;
				midRange = 150;
				midRangeProbab = 0.7;
				maxRange = 300;
				maxRangeProbab = 0.04;
			};
			class medium: close
			{
				burst = 7;
				aiRateOfFire = 4;
				aiRateOfFireDistance = 600;
				minRange = 200;
				minRangeProbab = 0.05;
				midRange = 300;
				midRangeProbab = 0.7;
				maxRange = 500;
				maxRangeProbab = 0.1;
			};
			class far_optic1: medium
			{
				requiredOpticType = 1;
				showToPlayer = 0;
				burst = 3;
				aiRateOfFire = 10;
				aiRateOfFireDistance = 1000;
				minRange = 300;
				minRangeProbab = 0.05;
				midRange = 500;
				midRangeProbab = 0.4;
				maxRange = 650;
				maxRangeProbab = 0.01;
			};
			class far_optic2: far_optic1
			{
				burst = 3;
				requiredOpticType = 2;
				minRange = 400;
				minRangeProbab = 0.05;
				midRange = 750;
				midRangeProbab = 0.7;
				maxRange = 900;
				maxRangeProbab = 0.01;
				aiRateOfFire = 10;
				aiRateOfFireDistance = 900;
			};
		};

};

From this extract, it appears, based on the class AmmoCoef, that the damage for this particular suppressor is 0.8 of the non-suppressed bullet's damage, the flash is reduced to .8 normal, bang to .6 normal, and the velocity (typicalSpeed variable) is reduced to 0.6 of the normal value. This code is for the machine gun suppressor, but the other suppressors show similar values, all with hit reduced to .7, and speed to .6 of their normal values.

In my interpretation, this issue is still not fixed, either on the damage or velocity front.

As a side note, it appears that fire rate is also affected by the suppressors. I don't know what effect, if any, a suppressor has on a weapon's fire rate in real life. Anyone following this thread know and care to share?

So it looks like severity and priority have both been set to none. Does this mean that this issue will be ignored by BIS?

Baffle strikes ARE very bad for accuracy, but they won't occur under normal conditions with well made suppressors in good condition. One that's seeing heavy use and abuse in a combat zone.... yeah, might get bent out of alignment. Interestingly, there are (at least) two viable designs in use by the US Army. The one that I'm familiar with uses wipers instead of baffles, such that it's actually a series of solid membranes in the path of the bullet. When the first round is fired, it punctures the membranes. Those are good for about 10 shots or so before the membranes have to be replaced. They were used on M9s by some long range surveillance folks in case they were discovered while hiding in their hide sites. I don't think that kind of suppressor would be used for many other applications though.

Thats one of the two main reasons not to use a suppressor all the time. The other being that they are relatively fragile compared to the weapon itself.

Turns out that the debriefing system has been changed. The old briefing.html is no longer supported, and debriefing information now goes into the description.ext as class declarations. http://community.bistudio.com/wiki/Debriefing

Hm, the br tags didn't show up in the report. Oh well, you get the point.

This ticket ought to be closed when someone gets a chance.

Speed of sound at STP is about 340 m/s. Grendel linked above is at 190 m/s at 1000 m.

As far as I know, the only major ballistics element that has not yet been incorporated is the effect of wind on the bullet. Other than that, it's quite a good model. This ticket probably ought to be closed.

You guys seem to be under the mistaken impression that the ballistics model is not accurate, but it is in fact quite good. Bullets DO lose velocity as they travel, and each projectile has its own wind resistance coefficient (somewhat of a fudge factor I think, since they don't seem to have individual masses). Bullets ARE less effective at long range than at close range, and it does take time for a bullet to travel. Currently, the 6.5mm and 7.62x45 rounds are set with initial speeds of 795 m/s. By the time the 6.5 reaches a target 1km away, its speed has dropped to about 300 m/s. You can see this change in speed over distance for yourself with the script I'm including below. Simply create a mission with a rifleman or marksman (your preference) and paste it into the unit's init box:

GunHandler = player addeventhandler ["Fired",
{
_this spawn
{

		_bullet = _this select 6;
		_initSpeed = -1;
		_speed = 0;
		while {alive _bullet} do 
		{
			_velocity = velocity _bullet;
			if (_initSpeed == -1) then {_initSpeed = sqrt ((_velocity select 0)^2 + (_velocity select 1)^2 +(_velocity select 2)^2);};
			_speed = sqrt ((_velocity select 0)^2 + (_velocity select 1)^2 +(_velocity select 2)^2);
			player sideChat format["Initial Speed: %1 Current Speed: %2",_initSpeed,_speed];
		};

};
}];

Similar issue: http://feedback.arma3.com/view.php?id=3935

Ok, i just spent a whole ten seconds googling an verified that auto hover is a real thing in some helicopters.

So for the sake of argument, lets assume that bi includes additional helis which have a turret mounted gun such as the apache has. In that case there ought to be a way for players without TrackIR to look around and aim. I'm somewhat surprised if this isn't possible already though. Can't you free look with the mouse by hitting * on the numerical keypad? If not, yes it ought to be enabled.

As to the existing helicopters, none of them have turreted guns, so shooting in a direction other than where the Guns point is a no go. If that's what you're advocating, then I still disagree.

If you're advocating the former though, then you're right.

Interesting idea, except that real helicopters don't have auto hover, and if you take your hands off the controls to shoot out the window, you're gonna crash. If op meant the mounted guns, well as Grezvany13 said, these choppers ain't got that ability. Down vote.

In reality, I have kicked inflatables to get them back in the water. Heh. :)

I am experiencing this also, in regards to the wonky NVGs. It is a randomly reproducible bug, and seems to happen when I do this addItem "NVGoggles"; this assignItem "NVGoggles" as init script for a civilian unit. this bug is also commonly accompanied by the error message "a3\weapons_f\data\ui\gear_x_ca.paa not found". Not sure if it's directly related though.

confirmed on stable build.

In reality, people being ambushed shoot high, so the am ushers want to be as low as possible. Another problem with taking tactics from airsoft is that the 6mm bb has neither the accuracy nor the range of a bullet, nor its ability to penetrate through branches and foliage. If you're in a tree, you're DEAD.

Now the place climbing trees MIGHT be useful, and I stress might because I've never been trained in SEER, is in evasion in the case of a downed pilot. Or in a dayz type mod where hiding is important. For long term hiding, you'd want to build a hide site such as are used by LRSD units, but if you gotta get out of sight fast, and there's a SUITABLE tree, meaning lots of concealment from branches and leaves, and tall enough to get 30 feet or so off the ground, then having the ability to climb it might be useful. But ONLY if you are willing to risk being unable to escape if spotted, and you intend to remain hidden.

Ambush might work against a single pursuer, but not against more.

In airsoft you stop shooting as soon as you are hit. In actual combat you stop shooting when you are unable to return fire. For infantry wearing body armor, that turns out to be a very long time.

You don't die in airsoft.

Not tactically useful. A man in a tree is a stationary target with no cover. No sane infantryman would climb a tree to stage an ambush in real life.

Verified at kamino and the air base. Rocks have hitboxes the size of an elephant.

big upvote on this.

Yeah, the vest seemed like a cool idea at the time. >.>

I agree, the only way to to judge it properly is probably to try it oneself. That said though, the torquing effect was considerable, and if the weight is half, that's still the same order of magnitude, so I would expect it to be comparable if all other conditions were similar.

This: http://www.youtube.com/watch?v=0NSHASDuD_A

I doubt that a community mod could add support for the thing in any event. But patching the game after launch to add support shouldn't be too difficult as long as nothing dramatic needs to be changed, and honestly, if some dramatic change to the engine IS required... well it may already be too late for that. >.> But I doubt that's the case.

On torque: The AN/PVS-7 (680g) that I used in the army had this problem too. Too much weight too far forward, caused them to constantly tilt downward, whether mounted on a head harness or on a helmet.

Using tightening of straps to keep vr goggles in place was always a losing proposition. Once the device gets to weigh more than a few ounces, I think you really have to redistribute the weight, some in front of the head and some behind, for it to be comfortable for long term use. The problem was never neck strain so much as the annoyance of having to look down your nose at the screens, so to speak, because they would fall down from the torque. That and having the straps so tight that they caused pinching. If they can make it as easy and comfortable as putting on a cap, or a pair of ski goggles, I think that would make it a winner. Otherwise, I'm skeptical. It needs to be more than just usable. Console and PC gaming history is filled with devices that were usable. It needs to be comfortable enough that the benefits it provides aren't outweighed by the annoying aspects of getting it out, putting it on, and using it. TrackIR fits that criteria pretty nicely. My Saitek joystick barely makes it (it's a chore to pull it out and mount it to my desk. Very bulky.) My logitech steering wheel does not make the cut, and as a result lives in the basement. That 14" speaker mounted in a backpack (I forget what it was called.. Activator Vest maybe?) definitely didn't make the cut.

could have sworn the Virtual Boy had a head mount option, but looks like that's not the case.

Well that takes care of the resolution problem. Movement is a trivial issue and can be fixed with some accelerometers. That weight is still rather enormous though, considering that a typical pair of glasses weighs less than 30g. How badly do the goggles torque?

for reference, Virtual Boy looks like it was 750g according to wikipedia. Not sure how much of that is the controller though.

Nah, sarlaac was supporting the idea, not opposing it. Rather aggressively supporting it too. :)

Ok, maybe the Gameboy 3D wasn't fair a comparison. XD My point in that comparison though was the bulk of the device rather than the visual quality.

I saw the mention of the device being a prototype only. Based on that, I think it would be safe to assume that the final product would not be any heavier than the prototype? I'm curious what the upper bound on the weight would be, if someone would be kind enough to weigh the device.

The question of resolution remains though. How much is the technology likely to improve by in the next year or two?

wow. This thread is nuts. It's like a debate is raging, but there's only one side present. Not sure where you guys came up with the perception that someone had argued against OC on the basis of an 'unfair advantage'. In fact, I don't see any outright arguments against it anywhere.

So let me add one >:D

OC appears to be the same type of thing as the old virtual reality systems of the '90s, or the Nintendo Gameboy 3D. Those systems all suffered from poor resolution, disorientation, and, most importantly, the goggles sagging down in front of you, which forced you to constantly point your nose upward just to keep a level view. I would bet that this is not something that will catch on this time around.

That said, if it's a trivial change to add support, it can't hurt. However, if it would take resources from elsewhere, my vote would be to leave it for a post launch patch, and concentrate on features that won't require players to plunk down several hundred dollars on new equipment and keep their noses in the air while playing (and which will affect more players).

I down voted for that reason.

Seriously, for those of you who have never experienced Virtual World or other such VR attractions, it really was just a novelty, and certainly not compelling enough for it to survive in the free market. I think the primary thing that needs to happen is the goggles need to get down to a manageable size, and be no heavier than a pair of ski goggles. Google Glass is evidence that that technology is on its way, but is it here yet? For those with the dev kit, how much do the goggles weigh? The second most important thing is for the displays in the device to have sufficiently high resolution to compete with a standard display (currently 1920x1080). Apple's retina displays are evidence that that technology too, is close (main thing being the dot pitch there) but I don't think it's here yet.

I'd be happier to see support built in for existing 3D tech such as what nVidia makes.

No, we should take this no pants thing one step further: Go Commando! (Real soldiers do!)

occurs in stable branch too.

Yep that's it. Normally there's a timeout period so that someone can't just stay not ready and hold up the game, but in this case that timeout is 9000 seconds, which is 2.5 hours. So not very effective, obviously. It's probably set to 9000 just as a temporary thing, as standalone server functionality isn't one of the things they're showing off yet, but we want to get the issue documented to make sure it doesn't accidentally get overlooked. Also so that it maybe gets fixed a little sooner... >.>

Fire mode can be confusing in real combat. I was in a convoy when we came under fire. Our gunner, who was carrying an m249 pulled the trigger three times before he realized he was on safe. By that time we were out of the kill zone, and the attackers were out of range (night time convoy). So even for trained soldiers in a combat zone, this is a consideration.

That said, I vote this down, as there is no good reason to have the functionality. Almost no one will use safe mode, and there are no real consequences for not doing so. Additionally, having to cycle safe-semi-auto-safe-semi-auto is not how real weapons work, and it is silly to have to go to safe on your way from auto to semi.

This is like adding cryptographic keys to DCS A10-C: yes, it makes it more accurate, but it would not add anything good to the game, and simply gets in the way of real gameplay (in the case I'd A10-C, starting up the jet). Minimal return for a lot of hassle. I vote to leave it out.

We might equally well petition to have boots have shoelaces that would trip you up if not tied. Yes, more realistic, but when would anyone ever really untie their boots?

Another vote for something similar to the shacktac bunny hop linked by NordKindchin, with the provision that height and stamina used be linked to carry weight. Carrying a full ruck, you'll probably fall on your face if you try something like that. Ooh, hey, how about adding a tripping mechanic while we're at it? (J/k)

Ive had this happen, but not as a diver, and I was far inland when it happened. not sure what the cause was.

That sounds pretty likely. Hadn't noticed the placement radius option, but I went back to double check it just to be sure, and all the offending waypoints are set to zero radius. I've been seeing this happen to more than just waypoints too. Seen opfor end up swimming nearly 50m offshore from time to time when placed near the waters edge.

I had just assumed that this was due to the game having to keep track of more objects than my computer could handle... I think I'll be giving that shadows thing a try too. GTX 570 here as well.

Did this get fixed already? I haven't been playing much recently, so I haven't been able to keep tabs on our AI Grunts' radio procedures.

@MulleDK19:

Easy, the information on wikipedia is wrong. Wikipedia is an excellent source of general information, and it generally gets things generally correct. It even has some truely excellent articles on various Mathematics topics. But it also is rampant with errors, inconsistencies, and misleading explanations. That's the nature of being open and editable by anyone.

So it really comes down to this: Either I, and everyone who has sounded off in agreement with me, most of them claiming to have been radio operators in the military (either by training or by job function), are a bunch of liars, and we forged those Army field manuals linked above, or else the sources such as movies, wikipedia, and Urban Dictionary, are wrong.

Believe what you like.

@DemonMustang

"NURSE! Quick, hand me the neural defibrotomulizer, STAT! I need to reduce suction on the cranial bicameral thoracic mitochondria, or the patient my go into bifarptric destabilization!"

@MulleDK19 I find it rather funny that you just quoted UrbanDictionary.com as a means, apparently (correct me if I'm wrong), to try to argue that a veteran radio operator's explanation of what ROGER Wilco means, and when it is appropriate to use it, supported, mind you, by links to genuine US Army field manuals, is somehow not correct.

It made me giggle. :)

Who said anything about you? The issue isn't whether you should be allowed to say Roger WILCO, it's whether BI should fix it in their game. THEY do get paid. Frankly, I'm totally cool with you saying Roger WILCO in vent, or TS, or VON. But the game needs to consistently be held to the high level of fidelity that BI has always achieve.

As for the goofballs who go tacticool in paintball or airsoft, that stuff is just silly. Airsoft is as close to real combat as kendo is to real sword combat. People who take tactics too seriously in that context deserve derision.

The difference is that in ArmA 3, BI is presenting an image of the military which they claim to be, and which everyone assumes to be very close to reality. Missing something like Roger WILCO is like having leprechauns, or elves and orcs for that matter, suddenly go running across the screen shooting at you. (Actually, that would probably be a pretty awesome mod xD)

It breaks immersion because it is grossly inaccurate. Maybe a better example might be having a man carriable minigun in the game, a la the TF 2 Heavy. Those of us who know something about the military and combat, and I definitely include you in there, we KNOW that it doesn't belong. Same thing with Roger WILCO, it's just less well known outside of the military. It's no less wrong though.

The pin and spoon not coming off the grenade when you throw it is a small detail. Roger WILCO is not, for all the reasons already explained above.