gibonez: I do not think so. I think the Atlis map as well as the Stratis maps are suitably large enough for larger transport aircraft. Granted they're short hops, similar in real life going from one local airport to another. Fixed wing aircraft being still far faster than using a helicopter, and can more easily remain within a holding pattern if need be.

Now that I've reasoned this, I likely see now why Bohemia Interactive has decided to remain only with helicopter transports versus incorporating larger fixed wing aircraft transports, likely to remain profitable alongside their other helicopter simulation software. And it's easy to workaround doing without, by simply scripting in a teleport or instant halo jump script.

This though inevitably leaves the airport taxi ways relatively unused as most servers I've seen only have one or two jets active, if any at all.

Really what we're looking at within the bigger picture is a calamity of finicky issues such as; AI too accurate, not enough trees on Altis for exiting choppers via ropes (versus Stratis have some really good spots), some servers have too many enemy vehicles making helicopters useless below 1500m, flares useless, etc...

FYI: There is a working Boeing C-17 module. I just tested this C-17 module recently within the past month or so, and found the C-17 module most functional having only two issues noted further below.

ie. Armaholic > Downloads / Arma 3 / Addons / Vehicles / Planes / Boeing C-17 or http://www.armaholic.com/page.php?id=25090

Cargo bay has a glitch with cargo falling through and something is wrong with the co-pilot seat. Other then these two issues and once fixed, the C-17 will be on par with the status of the other already included aircraft or helicopters within vanilla ARMA 3. With the added benefit of having a bay door which actually does something useful!

Should add, we had a somewhat good time attempting to parachute into the area of operations yesterday on Anzu's server, which is heavily fortified by infantry. However, if one can get into the inside of the area of operations (by parachute), the experience can be quite bountiful!

Here's a tip, flying above 1,500 meters one can successfully evade AAA and drop paratroops into the area. I would suggest not opening the parachute until just above 100 meters (or to be safer 110 meters), and no later than 90 or 95 meters. If opened too soon, you can push the forward button to attempt to get down faster.

The old helicopter drops one to two clicks outside the area of operations, and then the long jog is getting quiet old! (Thank God for TF1776 servers with flag pole parachute insertions, and reloading of original backpacks!)

Screw the C-130! Go for the C-5 Galaxy!

The V-22 Osprey was suppose to be integrated into ARMA 3, but looks like it was dropped sometime shortly after ARMA 3 Alpha. Now the Osprey looks like a faded memory.

This Bug is really a duplicate of older Bug #0010139, "Large transport aircraft for airdropping vehicles, troops". The older Bug #0010139 should be augmented to include the majority of this Bug's better description, including the attached photos.

With the C-5, the server administrators could program/script the C-5's for allowing air drops of approximately 30 Virtual Ammo crates over the AO, or unload approximately five vehicles at an airfield including troops.

While we're at it, anybody have a status on the ICBM's or incorporating girls? ;-) Another neat idea with the larger air transport vehicles, building supplies can be more easily & quickly transported, simulating building a city?

Ditto. I don't know why Bohemia Interactive initially called this "Feature Request", as it's going to spur quite a bit of response and cause confusion between Bugs and Feature Requests!

If you noticed, "Bug #{number}" and "Issue #{number}" and "Feature #{number}" all tend to be synonymous! (I need to double check these.) I tend to just use Bug #{number} myself.

Interesting. It would appear the embedded URL references for Feature/Issue/Bug issues do not work for bugs that are not present (ie. Bug # 1), or when referencing the same bug number the post is being made to. And furthermore, the embedded URL seems to happen only after the "#" symbol, with no bearing as to what the previous word is prior to the "#" symbol.

That was before they put girls into the cockpits.

Not sure of the specifics, but should likely be other damage such as instrument failures with armored vehicles, etc.

Just added an addition to my previous comment.

Arkhir: Good informative write-up Arkhir! Your second half probably describes what I'm seeing on one remote (albeit patched to h*ll) server. I would presume they "knew about me" or "I shot one of them so they now knew I was enemy", and at this point they're acting extremely computerized (or T2/SkyNet like), performing very unlikely as a human being would perform. Extremely accurate and killing within one to two shots, turning left & right faster than a human being would, etc. Of which when the AI are shooting these few very accurate shots, a normal human being or human ARMA 3 player would still be dealing with fatigue or still trying to get their bearings after just jumping out of a vehicle.

Sometimes, the AI would just walk by without recognizing my presence.

2015.04.24: Also researching back through similar AI bugs, the AI bugs have an apparent history of simply being closed without really being fixed. But when you think about this, Arkhir's description tends to be more exactly described then the previous filed bugs.

I thought this issue was being worked on and fixed within the latest patch?

And yet, now the AI (artificial intelligence) seems far more accurate now then my past experience.

They're movements seem far too quick and accurate now, and is noticeable when they shoot the enemy dead upon immediate exit from a tank. I can see them look left and right, with amazing computerized quickness, and all within a fraction of a second then shoot the enemy dead with one or two shots.

However, maybe this was fixed and it's just the server having it's own patches/hacks or they defaulted the accuracy of the AI to expert due to past problems. I should probably spend some time within the editor, playing around with some scenarios. (Too bad I wasn't an expert scripter within AI personnel/tank placement, else I could load in enemy in real time instead of having to reload the Editor map each time!)

I also recently heard AI could see through white smoke without any problems, unless the colored smoke were used. Obviously, most times colored smoke is used far less.

A crash just occurred within the past week here, using ARMA 3 alongside TeamSpeak and Saitek X52 Pro joystick/rudder drivers and Saitek programming interface.

This bug seems to be a duplicate of this one:
Bug #0017150, "Fault Module Name: atkdx11disp.dll <--- while after joining server"

Seems this "atkdx11disp.dll" is provided by the ASUSTeK D3D10 drivers.

On the latest developer version, there are no SAM rocket effects during daytime.

In other words, no smoke trails can be seen while flying over and having 5-10 SAM (surface to air) missiles/rockets flying towards my aircraft!

About four months ago, I was flying the simulated jet and was automatically ejected out of the jet while the jet either broke apart or exploded. (I can't quite remember, but simulated body fatigue/injury could have also triggered this.)

Funny thing is, I unfortunately didn't pack a chute as I vividly recall frantically trying to pull the rip cord.

Yes, it would be much more realistic if aircraft (and helicopters) either randomly or systematically disintegrate, ejecting players or forcing players to eject due to lack of control.

Yup. I too would really like to see fires on jets/helicopters, while giving pilots and passengers a chance to bail-out as appropriate.

Would be nice to have some minimal damage requiring ejecting from a fixed wing aircraft. From what I recall, quite a few pilots have successfully parachuted to the ground after their aircraft had disintegrated around them from a AA or SAM/AAA hit!

As far as the comments; people need to quit smoking dope, which results in being overly sensitive or paranoia. (Too many girls within Army wanna be forums! ;-)

Ditto concerning L3TUC3's comment concerning the topic not being easily comprehended. A title should be brief and easily descriptive. The title should not contain any abbreviations unless absolutely needed, as it's more appropriate to write the abbreviated word within a paragraph, along side initially defining the abbreviation for any readers whom are not knowledgeable of the abbreviation. (ie. In other words, what looks cool to you might not look cool or very useful to anybody else. ;-)

arziben: I completely agree. Fixed winged aircraft, as with any aircraft, have an ability to catch fire with a large period of time of possibility for ejecting. I think the developers may have this already stubbed in with the black smoke trails, but with no real timer until the vehicle is completely destroyed. Probably because they haven't calculated the margin at which time the vehicle should be destroyed, or smoke indefinitely? I mean, we are getting into guess work as to probabilities. Currently the vehicle either smokes indefinitely or explodes alongside killing the pilot likely just prior to the explosion. In reality, pilots and passengers are still alive while getting fried (depending on clothing) until the likely impact being lethal.

Usually when programmers create routines (ie. main & functions), they're just created to exist or to say this can be performed. And not necessarily to be accurate or completely correct (ie. look really pretty), and with C++ can basically assume it's going to be a hog of system resources. ;-)

Hence, you can likely see by the effect of the ARMA 3 Alpha and Beta programs, the aircraft (and vehicles) would have just templates for destruction or templates for interior details, which some would later be removed and replaced later with more something more refined.

I'm still waiting for the glide scope to be implemented on the remainder of the helicopters! (Glide scope was or is available on the Ocra last I knew, and is almost essential for effectively flying the helicopters or aircraft. Also took me a little while to understand how the glide scope worked.)

I coincide with Goblinbutt! Think it would be better stated as,

"Realism sucks butt. It's just a model that is inherently overly complex, and one that you can use to model your own deranged complex reality from. ... Complexity is fun. Realism is not. The latter simply makes things easier to relate to in some circumstances."

When living like all the other hard workers within society, working 5 days & 40 hours a day, coming home to play a game demanding you to walk another four hours before having any fun would likely equate to hell or strong meditation.

Had you guys been real Army folks (or girls ;-), you'd realize the five free minutes fun minutes (AKA R & R) you get from working your 7 day a week 360 days a year job, were probably better spent elsewhere! ;-) (And very likely, we would have also seen open or active bugs or feature requests asking for BIS/ARMA to display their Bibles, regardless of religion, while walking these four miles!)

I like realism. However I hate the above scenario if you're a more mature person working a day job. The likely best solution, equate the physics proportionally to average time spent by average player whom works within a productive lifestyle! As long as the equation of physics is realistically proportioned, I (& likely many others) are not going to complain!

Although I tend to agree a kilometer (or half mile) range, guessing playability as the reasoning.

A safe pilot would land 9-10 kilometers away with a more realistic AA targeting range, or one to two kilometers outside the range of threat.

Just what I want after coming home from a realistic day's hard work; only to simulate within a game walking 9-10 kilometers, only to be simulated shot dead and having to perform the same redundant 9-10 kilometer (or 5 minute) walk all over again!

And this is only with shoulder or portable fired missiles and not including the five minute simulated flight! ;-)

The "10 clicks" (or 10 Kilometers) we're talking about, is the approximate realistic range of shoulder fired anti-aircraft missiles, as to why we're discussing having to land up to ~10K away.

Currently, AA are not fired unless pilots are flying within 1K of the area of operations, making it possible to fly in at around 1K from the area of operations.

I love realistic simulations, but if it were anymore realistic, the game would then become a second job or second life. And most likely would risk quitting their jobs just to play ARMA.

But I would really love to see, the risky pilots flying and their aircraft to explode and disintegrate in air! And if the aircraft does disintegrate from around the pilots & passengers, usually the pilot & passengers are still alive and can deploy a parachute.

Anzu's War Games server seems to be modified to increase the effectiveness and range of both enemy shoulder anti-aircraft weapons and AAA/Tigris missiles.

Go any closer than 1.5 kilometers, and you're sure be be shredded by 20+ AA missiles. I must admit, it is likely a little more realistic, as previously they were merrily considered mosquito bites. But the side effect of Anzu's increased AA effects, has pretty much disabled any effective use of chaff/flare countermeasures!

The stable vanilla game likely does one thing correctly, static tripod implacements of AA can easily ignore chaff/flare countermeasures and strike the target, while shoulder/portable AA missiles have difficulty targeting around chaff/flare countermeasures. This is likely due to the static tripod implacements allowing more propulsion within a projectile versus something requiring to be more portable and lighter in weight.

The origins of this bug I think are related to Anzus specific game modifications, as it seems he desires more reality, while sometimes forgetting about playability, or the lack of sensation while looking through a 1 foot by 2 foot window or display. When tinkering with code, it's easy to sometime sway to far in one direction, but for the most part I enjoy Anzus's server, until they start ordering civilians around like puppets. ;-)

Tip for the reporter:

1. Fly below radar and go slower when approaching a new landing zone. (Flying low & slow, allows also for effective safe landings incase the aircraft does take damage!)

2. Never fly directly over the area of operations, unless all AAA/Tigris are deactivated. (Pilots have a death wish if they choose to ignore this, but still might be able to fly low-and-slow on the out skirts of the area of operations, prior to Tigris being disabled.)

3. Once Tigris are down, it's likely flying very fast at very low altitude runs over the area of operations is possible and almost safe, as shoulder fired missiles cannot view enough of the sky when you're flying low for effective targeting.

Yup. Currently on ANZU's servers, chaff & flare are pretty much useless or futile!

Count your chickens too, as typically when hit by AA missiles the aircraft has a tendency to explode in air due to the wings and body containing jet fuel, with (I'm guessing) 99% fatality of pilot and/or passengers! The fact that every anti-missile strike doesn't immediately or subsequently cause the aircraft to either explode or immediately break apart within ARMA 3, is completely amazing! Doing so, would further encourage pilots & players to strap-on parachutes while being transported! (But also, one should be able to strap their backpacks below them, if they had to eject.)

Fixed in latest developer version. But cannot turn on/off collision lights, manipulate gear, etc!

It's an excellent idea and realistic too! Now no need to yell at the pilot to turn on/off the lights, or to extend gear!

Chem lights also only last several minutes (ie. at most five minutes), when they should last from 30 minutes up to 12 hours.

http://en.wikipedia.org/wiki/Glow_stick
http://en.wikipedia.org/wiki/Phosphorescence
http://dayz.wikia.com/wiki/Chemlight

Yup. Within the game and the last I checked, chem lights within the game were only lasting 3-5 minutes! They're almost useless to use for marking landing zones at night!

UPDATED: I just timed (yellow) chem lights within the latest developer version, and chem lights last for seemingly 15 minutes or expire after only 15 minutes.

Suggest closing for now?

Looks fixed to me until a future version provokes this bug again.

I test edfathead's scenario and this bug still happens randomly when exiting the boat without a weapon. Sometimes the diver would be immobilized when exiting the driver's position, and sometimes not.

(On a side note, it would be nice to see more map missions on the coast capable of making use of divers.)

Thanks for the reminder, as I was preoccupied by AI cheating within multi-player last night. ;-)

I'll definitely check to see if this was fixed from yesterday's push of 1.12 stable version update, and report back.

I've just tested the same equipment load-out as stated previously and I had no problems swimming after ejecting from the boat within TF1776 servers. Still waiting to test this on the AWG Zulu (AnzusWarGames.info) server which I originally found this on, and seems they haven't upgraded their server to 1.12 stable yet. :-/

I finally was able to log into AWG Zulu after updating to the latest CBA mod, and have found this bug as been fixed as of 1.12 stable.

I currently cannot move after entering the water from a boat with the current stable version of ARMA 3.

I have the diving gear alongside the Zafir, 45 Handgun, Carryall Backpack, etc.

I have verified after unloading everything except diving related equipment, that I can exit the boat and move/swim after entering the water.

However, when I unloaded everything onto the deck, I found I could not pickup anything from the deck (or ground) using the inventory. As such, cannot further troubleshoot this bug as it would be too time consuming within the multi-player servers.

Nope, and I know none of the details of this server's internal (map) modifications.

Probably going to have to log in really quick to their main server and download & examine (or grep) the files. Likely there's some SQF scripting for each of the players incorporated into the map scenario, sending all scripted voices to /dev/null. Probably should be a server side setting, and maybe something already internally incorporated into the stable version for all I know.

Like I said, I still see such scripted text as "Reloading..." or "Regroup" scrolling. Other then this, it is ominously quiet now, even though I initially already had the Voice Scripted chat audio minimized. It's nice, but now I (nor anybody else) can see any of the enemy until it's too late.

Like I stated previously, the Scripted Voice was actually a wonderful crutch for having to squint through a two foot by one foot window. The human eye I obviously cannot immediately see enemy more than the 3D simulated 50 feet away without using magnification as within the 3D world the object is basically a pin-point at this 3D simulated distance. Of course, most admins are seemingly completely blind to this as they're young and the game looks more cool without the voices.

I think simply minimizing the scripted voices to a minimal volume, and reducing the unnecessary scripted voices to an absolute minimum. For example, such voice chat as "Regroup" or "Reloading" is really unnecessary, and I only found "Enemy (or tank) at 3:00 o'clock (or bearing)" useful.

Granted, the above is slightly off-topic from the main bug description, but figured I'd leave no stone unturned as the information is relevant.

FYI: I think the Anzu's War Games server has successfully cut or removed the scripted voices, and only scripted text is currently shown.

Girls usually do this, then one of their girlfriends exclaim, "Why throw out the baby with the bath water?" (Sorry, I couldn't resist this one. ;-)

Anyways, a good work around, but I don't think most would enjoy not having a radio. Good programming is evident when the program is written from the ground-up, accounting for almost all possible situations which could be encountered.

It's why I still enjoy using a command line console versus graphical click and play environments! Should be a global variable within the game scenery file enabling or disabling radio scripted dialogs. (ie. RadioScriptedDialogs="NoMeansNo" )

With the above being said, I'm also split on the decision to completely omit the radio scripted speech as well, because scripted alerts aide situational awareness to the lacking detail of looking through a two foot by one foot window. (I'm referencing a window, for a computer monitor or computer display.)

So at times when walking within the 3D game environment, it tends to be really nice to hear my unit call-out an enemy's location for which is only the size of a pin head or smaller on my computer monitor!

The best solution for me here, is reducing the Radio Scripted voices to where I can still hear them, while having Radio VON volume is significantly louder. (Currently, Radio Scripted voices is at the same volume as Radio VON, and tends to be confusing to the brain, as we ourselves are not initiating the voice, but the game is simulating our person, leading to confusion.)

As far as the Radio Scripted voices causing lag, think they should look at properly optimizing the programming or scripting.

Go into Config > Audio and turn down Radio commands.

Optionally if you also think the helicopter effects are too loud and need to give preference for VON, helicopter effects is under Effects. I'm always also turning down effects to around 5%, but need to routinely increase Effects as you won't hear ricocheted rounds. Hearing radio commands is good for detecting enemy, so I turn Radio commands down only so far as that I can still hear them.

Scott_Ripley: I may have misinterpreted DogBo's previous comment. :-/

About the only thing useful with the voices, is when the voice calls out enemy detected and their direction and approximate distance. Everything else is just seems like useless chatter, including when the person is a group leader.

Also, screen goes black when an HDMI resource is disconnected from the computer. This issue I just stated, seems to be a O/S related bug as I do not see it present within Linux, or an HDMI implementation related bug.

On Windows, I've disabled all drivers related to HDMI, HDMI display, NVIDIA HDMI Audio, etc. It helps, but does not solve the issue.

If I'm not mistaken, I'm no longer purple within version 1.38. :-(

But at least I don't look like the other ugly guys... within the game anyways. ;-)

In my opinion, there are more important features to worry about than people intentionally feeling purple.

Looks fine to me! ;-)

I don't mind this purple effect, as it sort of protests the zealous game servers not allowing the (simple) low resource and small file sizes of the custom "face.jpg" and "Sounds/" folder feature of ARMA 3! ;-)

What harm is there in having a game server to allow such custom files, aside from a few weirdly designed GL people and some making farting noises?

Matter of fact, I think 1 in 100 (or even 1 in 1,000) people/players only know how to provide a custom "./face.jpg"; or 5 in 100 (or 5 in 1,000) for the "./Sounds/" folder!

As such, I say leave the purple effect in! (I changed my vote, and think you will too! ;-)

I think players should be allowed to customize their profiles a little more then just their nicknames alone, no matter how much of an idiot it makes them look. ;-)

OH. Then it's my incorrect assumption! (I love it when I'm proven wrong. ;-)

Maybe this bug needs to also consider changing the default face.jpg and Sounds/ file/folder sizes?

SOME ADDITIONAL LINKS

"Arma 3 Modding Characters"
http://community.bistudio.com/wiki/Arma_3_Modding_Characters

Instructions on 3D modeling, more likely compared to my own chicken scratch notes here at home, likely requiring clarifying instructions for new 3D modelers. Instructions also instruct using only BIS's tools, omitting any tool explanations for The Gimp or The Blender.

"ARMA FAQ: 6.1 Custom Faces"
https://community.bistudio.com/wiki/ArmA:_FAQ#Custom_Faces
Very basic information on the face.jpg/face.paa file.

Armaholic FAQ: How do I use/make custom faces?
http://www.armaholic.com/plug.php?e=faq&q=23
Contains much better instructions.

MY ADDITIONAL CLARIFICATION

Basically, you're creating a face.jpg or face.paa file within:
"My\ Documents/USERNAME/ARMA\ 3/face.jpg". For ARMA 3, the face is located at specific coordinates designated as "XXX" below.

XXXXXXXXXXX
X_________X
X___XXX___X
X___XXX___X
X_________X
X_________X
XXXXXXXXXXX

Basically, the approximate face texture coordinates is 1/2 the size of an original appropriately sized image (ie. 512x512) and resized to about 1/2 the size of the original image and then moved-up to about 1/3 from the top of the image, centered by width size as denoted above. Eyes, legs, arms, etc all have other coordinate texture locations within the 512x512 (or other appropriate sized) image. Seems the Wipman Reference Templates utilized many layers.

THE GIMP INSTRUCTIONS

1. Grab an image and rescale to 512x512 (or other appropriate size) by doing "Image > Scale".
2. "Transform > Tools > Scale" or "Shift T" to scale the specific image 50% smaller within the original image to 256x256. (I know, confusing but this is a different type of rescaling.) You'll still have a 512x512 main image size denoted by the main image checkered background, but your specific image will be in-laid.
3. Move the image using "Transform > Tools > Move" or "M" so that the smaller image is centered horizontally and about 1/3 from the top of the main image, as denoted above.
4. File > Export to JPEG, or TGA (with possibly RLE Compression deactivated for BIS tools ImageToPAA compatibility)
5. Place the face.jpg into the proper folder and use it by going into the Configure > Profile menu.
6. For using the TGA file and converting to BIS PAA image file format, use ARMA 3 Tools ImageToPAA, a command line utility. (ie. Executing via console, "ImageToPAA.exe face.tga" will provide a file named "face.paa")
7. Finally, click File > "Save As" to save all your undo levels using Gimp's specific XCF file format.

READY TO USE TEMPLATES

Wipman's Reference (face.jpg) Templates using Adobe Photoshop files, compatible with The Gimp:
http://www.ofpec.com/editors-depot/index.php?action=details&id=519

MY FINAL NOTES

I personally think in an effort to simplify these face.jpg files, each image file should contain only one body part, within a subfolder, or for example "My\ Documents/USERNAME/ARMA\ 3/Profile/leg.jpg". (ie. face.jpg, arms.jpg, legs.jpg, eye.jpg, ...) Cramming everything into one file, without explaining the coordinates of each body part within a face.jpg, is overly complicated.

As previously mentioned, the previously mentioned instructions are unique and only pertain to BIS tools, and nothing about using The Gimp and Blender, etc.

Another bug; in order for the ARMA 3 Game to recognize a new or changed (face.jpg) image file (ie. "My\ Documents/USERNAME/ARMA\ 3/face.jpg", the user needs to exit and restart the game for the game to recognize the newly changed face.jpg. You also need to manually designate your profile to use this custom file.jpg by going into the "Configure > Profile > Edit > Face > Custom Face". (A new face.jpg file will be recognized without restart, but a modified face.jpg will not be updated until the game is restarted.)

Don't forget Hand Smoke for parachuting! I know within TF1776, the server is modified to deploy a range of chemlights while parachuting or when running onto the player's vest. But during day time, chemlights are useless, and smoke or other item for increasing visibility is required.

I would imagine hand_flare, hand_smoke, would be treated like an ordinary flashlight or hand_flashlight, or grenade item.

However within ARMA 3 when selecting grenades, they're merrily thrown and not grasped like a weapon such as rifle or handgun!

It would also be really great to be able to place something more permanent on the ground, designating a remote landing zone for helicopters instead of always having to deploy a red smoke grenade every few seconds for daytime increased visibility. Thankfully, chemlights last awhile, or did so until the latest stable release?

On second thought, maybe the game is going green and is finding hand flares are a more dangerous form of lighting, and hazardous for breathing? As such, chemlights are now the preferred method of night lighting? ;-)

The color of red for pyrotechnic flares, is a basic color of most flares.

Your hand flares (via Flare Wikpedia), are more specifically called Fusee flares (or highway flares, road flares, or ground flares) and are commonly used to indicate obstacles or road hazards, and commonly found within road hazard kits. The only specific mention of the color red used to disinguish usage within the this Wikipedia article, are when the red flares are used within the terrain of the ocean, mairtime usage of flares. (ie. First topic under Civilian Usage; "Maritime distress signal", with the next topic being the definition of Fusee flares, and Fusee flare being used by everybody.)

I think what you're referencing with police usage, is probably within ARMA 3 Life servers? I tend to agree, if there's a vehicle on the road and many people are driving their OpenGL car/vehicle down these very narrow ARMA 3 highways, people should drop flares forewarning of an approaching parked vehicle convoy or accident. ;-)

Basically, every truck or commercial vehicle would have a road hazard kit containing road flares. Civilian vehicles would be optional, but can be somewhat myself, I also have road flares within my own privately owned vehicle! I currently also reside within a far more rural area of Alaska than most of you folks, having adequate emergency response services. (Or a cop for every city block.)

Not a night goes by within ARMA 3, when somebody parks in the middle of the road/highway causing a accident. But they also have to be adequately intelligent to also get out & deploy flares, versus just running off naked!

As I previously mentioned within my last post, the likely rational for flares is for daytime use, as smoke only lasts for a few seconds. Road flares are designed to last far longer, and at the same time do emit quite a bit of colored smoke, aside from the bright light which is also seen in bright daylight. (ie. From Fuse WIkipedia, "... fusee, which burns for 10–60 minutes with a bright red light." Yes it would be nice to have a daytime signaling device lasting far longer than a smoke grenade!)

Doing a little more reading of Flare Gun Wikipedia, and finding flare guns have been used as weapons, with destructive or lethal power. As the boats or navy arena grows within ARMA 3, boats are also going to require flare guns.

Arkhir: I wouldn't file a duplicate, but take the time to file a bug stating this bug is not assigned to anybody. If I'm not mistaken; if a bug (ie. on Bugzilla) is unassigned to anybody, the bug will be completely ignored. There are likely many unassigned bugs, as Bohemia sounds as if they're probably constantly moving around resources or people. It also maybe desired to mark a bug unassigned, as they may have no plans on resolving the bug at all.

Just make sure you post a comment back here containing the bug number and description to inform others monitoring this bug here.

On the flip, they could be leaving the bug unassigned as they do not want to close due to the internal decision of not having any interest in fixing the bug. Once a bug is closed, the bug typically is difficult to search for by others. So leaving unassigned might be a lesser evil action, and keeps the bug easily found by others instead of filing many more duplicates!

The beeping is needed for immediate notification some (dumb) player has placed an explosive device.

The triangle is usually only seen after a minute or more activity, and doesn't suffice by itself as an immediate indicator.

What I do agree with this Feature/Issue/Bug request:

1. I agree the enemy should not be able hear the beeping (or triangle visual indicators) as it's obviously a game balancing feature.

2. And, there should be options for customizing whether the red triangle or beeping while placing explosives are seen or heard.

(Further, I think they're primarily focused on bugs now, and appear done with implementing game features for the time being.)

The duplicate "pops" referenced is particular to Harzach's recent post speculating this bug is similar to the older bugs, and not to for this particular bug. These appear as misconceptions.

Again from my perception, the bug described within, is for any beeping occurring with explosive devices overall. As the person authoring this bug, explosive devices do not usually beep at all.

This bug probably needs further clarification to ensure it remains distinctive from Bug #8938 "Reloading weapons / placing explosives is audible far away from source".

(Took a little time and think I can help rephrasing the topic and description. I made some grammar modifications/corrections and replaced some words to make the issue more clear and understandable.)

Beeping is Too Loud & Non-existent in Real Life.

Military deployable explosives on the battlefield do not beep so loud as an entire town can hear one being deployed. More so, they rarely beep at all. As a result of the current beeping sound effect; The man standing next to the tank of which you just placed a charge next to, can turn around and either ask you what your doing, or put a bullet between the player's eyes.

gutsnav: LOL. This sounds like politics in general. Good point though. I was not aware the enemy could also hear the beeping. As with the red triangle, assumed the beeping was only heard by friendlies. Likely an option needs to be integrated, so server administrators can disable or enable this, and further fix the beeping to be only heard by friendlies.

Sure sounds like a broken feature. Should also mention, many times people have inadvertently placed an explosive when using the middle mouse button menu. And the beep sound does alert people nearby that the accident prone player may now also inadvertently now press the detonate button, and the beeping gives other players a chance to go for cover. This beeping has saved mine and others' lives within the game many times, but guess it is broken as the enemy should not also be able to hear.

I think the extraordinary loud beeping is used only as a signal for others within multi-player, that some other (person) has possibly planted an explosive or satchel nearby.

Anybody playing within multi-player and whom haven't encountered this, should realize this is likely the only fair solution besides disabling explosives to all beginners, or to all others except for a few select few. Also notice, the red triangle visible to everybody is also unrealistic. But again, it serves to state an explosive device has been planted for those that do not have a microphone, or for alerting of possible trouble makers within the multi-player server.

I think the solution implemented is well thought out and is also very effective for quenching any trouble. So effective, that a trouble maker them self would need to file a bug report in order to try to get around it.

Did a little more customizing with my TrackIR 5 and found the One:One, Deadzone, Slow and Fast option seemingly a template only, and does nothing with the settings. Basically, the template gives you an idea where to place the dots within the graph, to simulate one:one or fast head motions.

So far optimal settings, seem to be in between one:one and fast templates.

My settings: Set the center Y axis to 2.
The next 5 pairs of dots are as follows:
-3,3.5
-7,4.5
-12,5.0
-18,5.0
-27,5.0

This seems to give me a more true one to one head turn rate speed on my 27" monitor. One to one seemed too slow for me, and I had a hard time looking over my shoulder, while fast was too fast. So far, my previously mentioned settings seem optimal. It's not rocket science, as the x/y coordinates I set are just guesses against the Fast template. (BTW, the Mirror option is checked as should be yours by default, so you only have to adjust one coordinate to affect the matched paired coordinate.)

Click create a new profile and save if you want.

For those having problems with TrackIR slowing down (or slo-mo) graphics while running on foot, this is because of the "Video Processing Mode = Precision" by default, and you need to switch this setting to "Standard". Now setting this to Standard helps significantly, but this does not completely solve the slowing-down of graphics while on foot completely!

As far as allowing "standard" to be set by default within the TrackIR configuration files, the corporation stated they were looking into this awhile ago.

Seems to be a few bugs here, and it's not like TrackIR not to fix bugs.

I don't think you have TrackIR centered properly.

Try tapping F12 (center) with your head in a normal position. Sometimes I move my head about an inch forward and then center (F12) the IR camera, as this ensures I viewing the full screen while piloting. (Not so important when on foot.)

About the only issue I have with TrackIR 5, is the slowing of the person while walking/running, and most times only pressing F12 will quickly resolve. Lately though, the F12 hasn't been working to fix this little bug or misconfiguration.

FYI: TrackIR is great when flying, and not very useful while on foot. But I still use it while on foot, as you can look around while running forward or advancing easily. I have more issues though with trying to use the keyboard keys to switch firing positions. Likely should just always use my big clunky Unicomp keyboard, as my fingers won't fall off the keys.

UPDATED 2013-12-25 21:14: OK. Sorry, I'm out of ideas then. I know you can get into the camera configuration view and change the boundaries, but I'm having a tough time figuring it out with my above stated issue of slow-motion. I know I've got the flip/reverse view when going to far figured out with limiting or unlimiting the boundaries, but I'm limited when trying to explain how to save the profiles and using properly TrackIR terminology. Configuring the boundaries is something that usually doesn't need to be done unless you're leaning too far. As to why you only lean a little bit and get this effect, I do not know!

FYI: I've got notice of this, and believe I have tried using invert yaw axis with no effect. But will retest when I have more time.

I think the partial solution was simply to extend the X axis points. Sometimes the X axis terminated at about -40/+40, which would cause a significant slow down when extending the view past the -40/+40 X axis points. However there was still an intermittent (random) slow down at times. And it's possible inverting the Y axis also might solve this completely.

2014.05.17 - Think I've gotten my bug mixed up with this one. This has to deal with reversed zoom as described within the description. I was seeing a bug when moving your head left to right extensively, the entire image on the display would flip into another perspective. Extending the X axis seems to have resolved or reduced this perspective flipping. Invert the Y axis, only reverses the left and right head motions, making looking around seem backwards.

All the servers are running really horrid today with very poor frame rates and network lag. Hop back into single player mode and everything is fine. I'm thinking with all the players, the server backbones are likely stretched beyond their rated network bandwidth. (Kids need to be back in school and doing something productive with their lives, besides wasting it playing games.)

2014.01.07: Ah! Good thing I subscribed to this as I realized shortly after posting this I found I had reverted Power Saving within the Windows O/S to use power saving instead of a performance related profile. The Power Saving feature enforces the network card to use power saving measures, which created frame rate issues only within Multiplayer games. (Odd, but true!) Once I set the Power Saving to use a Maximum Performance option, the frame rate lag issues within Multiplayer games amazingly ceased to exist.

The brightness of the flashlights are getting really close to the real thing. Flashlights are currently about as powerful the incadescent models.

LED flashlights are far more brighter than the current setting. I'm guessing about 30% brighter. For example, I should be able to a clearly distinguish an object such as a helicopter about greater than 100-200 feet away if I'm not mistaken.

Look at the ground, it's pitch black on a moonless night, which is pretty realistic.

The topic of this bug needs to be written to include all man made light sources during night time as being weak.

A LED flash light is an extremely bright light source and I can adequately see people or objects as far as 200 to 500 feet down the road from the light provided by a very small LED flashlight! Within the 3D game, we're only able to see a very limited 25-50 feet with those 3D flashlights!

The vehicle lights only seem to be simulating low beams, but even then I would say they are just as weak as flashlights.

This maybe related to Bug #8082, "Night time (darkness) visual problem with [DEV] build..." and this problem with skies not being dark enough was seemingly recently resolved. My guess is, this man-made lighting is going to be the next item on the agenda.

Should be a TOW vehicle. Since they won't integrate a solution or maybe not exposing something script level, just use a tank or other similar vehicle to push the jet. ;-)

I should also add without reverse taxing ability for aircraft, it will be a deficiency for any C-130, C-5 and other larger aircraft.

As they say, a classic catch 22. Vote up or vote down? I voted down as I think the feature was focusing on smaller aircraft, for which are currently implemented.

Ditto. (I paid for the game, and I want to play with all it's toys and not have to re-earn all the toys again -- wasting good time for other more fruitful real-life projects! ;-)

After rereading the topic, I also tend to agree having Direct Chat statically linked within the Effects Volume is probably a very bad idea. But does within another perspective, make sense.

I'm always constantly manually turning-up and turning down the Effects Volume due to vehicle and aircraft noise, or the fact there's no ear plugs or radio headset simulated within the game. And without Effects Volume turned to maximum volume, Direct Chat is completely silenced.

Please note, this is related to Bug #10272, "Ability to instantly disable VON whit specialties to Side and Global chat to not be bother by people screaming over the mics."

However, the two bugs could be combined, if Bug #10272 were to include this bug's possible solution as well. This bug seems to currently have fewer votes and was opened later. But this bug or feature request could also be a solution to Bug #10272! Reducing the volume is something I always used to do, and still do when multiple radios are turned on. However, this would also easily provide an off switch as well. But again, as I just noted within Bug #10272, this volume feature can also be abused by server administrators wanting to deny usage of certain groups just because it looks cool or looks realistic. And in essence, turn away many older players as the server administrator's perception is not realistic. (If I'm not mistaken, certain channel volumes already have their volumes artificially increased within the game, and I think one channel with increased volume is Side Chat, which is extremely irritating when communicating on direct, group or vehicle chat channels.)

Usually we've reserved Side chat to minimal Air or Mortar (or other external support) operations. (As it should be!) Most users should be able to reduce this Side chat channel volume and focus only on their group, vehicle or direct chat channels. Instead, they're forced to hear a much louder Side channel over their primary used channel.

I'm poking fun at the fact some programmers do not take into account for future features or modifications, and just hack something together because it works.

Now for this feature request, the programmers would have had to account for a modifiable or exportable "WaterLevel" variable. I suspect they did, and should be an easy to further implement. (ie. There probably already is a global variable for water level, as well as wave heights, ...) But having to request this simple feature here, more or less has me puzzled. Because with insight into programming, one would think it's so simple, why isn't this already exported (or exploited) via scripting?

ProGamer: LOL. But not really as I elect to read some code and see the problems some easily forget to fore think of.

Well, this might destroy some vehicles just sitting around. (ie. Vehicles in the water, either self destruct and sometimes are not designed to respawn.)

If they did their programming correctly, then weather and other factors should be easily modifiable within the future. (Hey, it is coded in C++ after all, so we shouldn't expect it was coded with an open mind. ;-)

Ditto, fixed.

Also fixed is the slope or hits being below the cross hairs of the HUD, and was fixed in 1.50.

Shrugs. I was trying to make the scenario work using the green simulated HUD. It's not like there's a big warning sign stating, "This HUD does not work for Laser GBU's". ;-)

And further more, even after asking around, nobody could clearly explain, as I previously just did. Not only this, the large white lock-on icon appears to briefly, even I was completely over-looking the lock-on icon even after flying many hours.

Just to verify, the green inlaid HUD does not work for Laser GBU's correct?

I have noticed lately, it is no longer required to line up the white circle and white lock-on diamonds. (Basically it looks like this program line check for line-up looks to be commented out, or the calculations for bomb glide scope is augmented for game play.) This seems to be a really good solution. Before, pilots had only a five second window for making a good laser guided bomb drop. But they rarely could do so because they first had to seek and find the laser target, for which would rarely be immediately present due to quality of laser target and players multitude of view distance.

For best laser lock seeking, most pilots should boost their view distance to 2,000km.

Until all pilots are able to use an adequate view distance of greater than 1,999km, as well as having a bomb drop window greater than five seconds, this bug probably won't progress much further than this solution?

ADDITIONAL: Using this solution on one server during night, I was finally able to lock and drop more than 4+ GBU bombs (or full payload) with ease, as it probably should be.

Excellent feedback. I too have heard about view distance affecting locking from aircraft.

As far as the difficulty settings, they should drop those difficulty specifications when laser locking for now in order to allow players to benefit from the laser targeting systems.

For the past months after the few times I tried laser targeting, the pilots either had no idea they were given a lazed target, or they never seen the lazed target. I've flown a few times and never seen a lazed target even with view settings set at around 3,000-3,800 for view distance!

I'm not sure of the maximum altitude a lazed target can be seen, but I'm pretty sure it's much higher than 1500km. Again, thanks for the excellent feedback!

OK. Here's how to successfully drop Laser Guided GBU's from within the game.

Only pay attention to the large white or game flight circle and square target icons. (Likely a different color if using other than default colors, and even default colors tend to change for the game.) Ignore the green flight simulated HUD for GBU weapons, along with the green diamond lock-on icon and squares for which always seems to indicate locked-on and further note the simulated green HUD for GBU weapons currently is only good for dumb bomb drops to a certain extent.

Seems for the ideal drop hieght, or the heighest I have been able to drop with an active lock-on has only been about 700m, give or take a 100m. (Speed so far variable, or have had hits from 200-500 km/hr.) Pay attention only to the large white game circle and square target icons for the game as the large white diamond lock-on icon stays lit for only a few seconds. Drop when the large white diamond shows over the large white square target icon, along with having the large white flight circle over these other icons. The drops for 700m high drops seems quite far away when you think about the glide path. In theory, should be able to go to higher than 1,500m for drops correct?

Another tip for being able to view your hit with Laser GBU's; after the Laser GBU is dropped on a lasered target, drop full flaps (prior or after dropping) and go immediately to a higher height, switching to third person view during this time. This will significantly decrease your speed and provide more viewing area from higher up, enabling a view of the perspective hit.

One more tip; could likely declare a static IR grenade near each target on the map, similar to a static glow stick. (Static glow sticks are already available within my public ARMA 3 "Air Target Training" or "AirTargetTraining" single player mission, or you can search for the script declaration elsewhere.)

I performed more testing, adding setfuel=0 so the vehicles would not move.

I still had a hit ratio of 10% or less, with bombs falling approximately 50 feet or further away. I notice the diamond lock-on is almost always persistent for the aircraft HUD, and the diamond lock-on for the game graphics is only persistent for a short period of time after flying the jet towards the target. Using the game graphic diamond lock-on, think I had only one direct hit. All other drops landed far wide, indicating some sort of guidance failure.

TIP: Now recalling playing Janes software jet simulation on bomb practice runs using their laser pod, drop the bomb and then throttle back fully (and/or apply full flaps after dropping the bomb along with brakes) and level-off and/or point the noise upward to further decrease speed. Switch to 3rd person view, hopefully using TrackIR and I can now watch the bomb fall towards it's intended target. (Or, it's possible a game update occurred while I was testing and the graphics were imported while I was testing within the editor. See below. :-/)

Seems a game software update just occurred short while ago, and now all my enemy vehicles are showing as green icons on my jet's radar! I am presuming this is another game bug? I also tested the latest developer version. I can no longer test this bug until this gets fixed.

Edit 20131123: After much troubleshooting, I later found out the developers modified the Next/Cycle Targets and Reveal Target keys. It would have been really nice for somebody to give us heads-up about this, as also spending time programming the irritating Saitek joystick software makes things hellish here. Wasted about four to six hours trying to figure-out the mess created with the last update. Also contributing to the mess, seems the enemy vehicles were still being treated as friendly, no matter what I removed and changed within the GUI. So I reverted to an earlier version which had no problems. Maybe getting into the enemy vehicles to check their (no ammo and no fuel) capabilities was what triggered treating the enemy vehicles as enemy? A bad save? A bad save during an upgrade while the game editor was in use? Haven't diff'ed the scripting file, and probably won't waste more time then needed. Anyways, after more testing, lasered targets using GBU are still incredibly inaccurate.

20131125: Updated mission to vehicles just north of the runway without fuel, each with a laser designated AI within a few feet of the enemy vehicles. As you'll notice as fly to the targets, the computer GUI lock-on diamond is only active for less than a meer second! (While the HUD green diamond lock-on is pretty much always lit as locked-on.) I don't believe this is how laser designating is intended to work.

I've retested and noticed the lock-on diamond is pretty much automatic with GBU Bombs, and the green diamond shows only within the green HUD and not onscreen.

There is one hitch with my testing yesterday, on my Saitek X-52 Pro which has a three-way profile switch, I could have initially tested with a profile I use for helicopters. This joystick has two switches within the trigger switch. And on the helicopter profile I use the first switch to "show target" or "identify target", for which can inadvertently unlock a target. Hence, I could have initially been testing with the helicopter profile, but follow-up testing using the aircraft profile (which only maps the second trigger switch, leaving the first trigger switch unmapped) shows my hit rate with GBU bombs still to be about 50:50!

Dropping down and flying over, I noticed one GBU had hit the ground about 50 feet from the intersection where an Ifrit was located. On another target, the Ifrit appears to have moved, but may have hit the laser designated target nearby.

Although I have TrackIR 3, it's extremely difficult while viewing 3rd person, to view the bombs hit. So seeing them hit is usually by chance, or luck.

With a 50:50 hit rate, something seems amiss. I'll do some more testing, dropping the bombs from >4 km out to see if they glide to the target. If they are getting near the target, should confirm they are being guided. But last night they were by far not guided at all to the laser.

Which type of munition did you use? (I'll double check to make sure the lock-on is active when selecting a target here.)

Attached AirTargetTraining.Altis.7z - Altis map with jet on runway with unlimited munitions, including laser designated targets just north east of airbase.

Additional: I initially added one AI laser designator from afar, but he didn't appear to lase targets at all, likely due to sway. Added a second one nearer, in front of previous AI laser designator, about five feet from a target and found he lased the target without issue until the target moved. I've added three or more laser designators directly in front of the other targets and haven't tested this change yet but should produce the desired affect of having more lased targets. ;-)

And what really bugs me, you can likely dress as a civilian and still automatically (within less than one second) be assumed as enemy and be shot by the enemy AI!.

But on the flip, I do sort of enjoy the prospect of ARMA Life substituting for "the Sims" virtual world game.

Imagine one day having almost real civilians within your ARMA 3 battlefield.

OK. I give-up.

I want a female model in the game to have similar big breasts as the girl in the Movie Airplane. I want them to jiggle like they did in the Movie.

Just wait for when female AI are implemented.

As usual, we'll have server administrators bumping the female AI skill level above all reasonable human intelligence. Then the server administrators will then again start complaining the game is no longer using maximum CPU/GPU resources along with complaining of frame rate stuttering, and will not give much thought for the remote possibility that the female AI have been given too much power.

As I stated in my past comments, I'm a guy and definitely would play as a girl.

It's better than watching some other guy's butt in third person view all the time.

And with all the other supposed whining Army guys around, my character would likely socialize better.

Unfortunately, Czechs' Sexist Tradition May Nearly Be Ova
http://articles.chicagotribune.com/2000-03-09/features/0003090053_1_czech-women-suffix-ova-post-communist-countries

-POET-: You need to watch the video from the international Game Developers Conference in San Francisco containing Project Lead Joris-Jan van't Land's lecture at a panel titled, Gaming the Laws of War.

There are good reasons why babies are not simulated within the game.

Finally somebody posts some sound evidence for the issue!

Up until vertebrate's posts, all I heard was whining for girls with no rational basis.

"... but the underwear in arma 3 its anything but sexual in design ..."

I disagree.

Pesoen: Most sane and rational post I've heard yet!

Well I just realized, If there were more female programmers, maybe this problem would be solved already. I mean, what would people say if all the programmers were female with a male executive in charge, and the models were still based on men? But then again, we'd probably still end-up with all male models within the game.

Another way, the females can lynch the leading manager and install their own wonderful female manager or female executive for guiding all the male programmers into a more proper direction?

Personally, I'm not much for lynching after studying the results from past history. ;-)

Sounds good to me! I need that arm rest fer me gun!

Ditto. Wish everybody whining about this bug would just hold their pants on!

Why only show a girl your pen, when I can show off to them my nice big clicky Unicomp/IBM Model M keyboard!

RickOShay: If you look back in the history, you'll see I tend to agree, as I'm having to look at my own butt all the time. Sure would be nice to see a female every now and then.

I'm not an expert at International law, but I guess in some countries they could file lawsuits or whatever, but within the US it would be more of a State issue with allowing the box stores to sell the game if it had an X rating.

But from my perception, having female medics (within the game) perform in-the-field prostate exams (with insert your favorite big gun) sounds interesting.

I couldn't agree more and cannot add anymore than vlad_8011 has stated above!

I'm sure vlad_8011 has stated enough, that we can now conclude & close this bug. Later, we can all get together and share a beer! Peace, love, happiness, hugs & kisses all! :-)

TakeHomeTheCup: From my legal point of view concerning laws of national regions, I don't think so. A ban on import would be more likely, if at all. People are usually allowed to dream without the local police knocking on their doors.

Personally, I see no issues. However stepping back and looking at this from a more humorous point of view, maybe you're inciting their Country has more girls per men? ;-)

Dr_Death: Rooting for the soldiers to break-out into a dance if the sway or fatigue is increased much more than it is already! Maybe we should add some hallucinogenic red & blue disco lights too during increased fatigue levels?

Anyways, off-topic but Dr_Death does have a serious point concerning the sway & fatigue levels being completely unrealistic. So much so, I'd rather live real life instead of trying to play a game as some zealous realism server admins try to promote such game settings. (Comment has no bearing concerning the "Phoenix Realism" game server, as the title is somewhat a misnomer.)

I say again, I too would love to look at a female butt while in third person!

RickOShay: Whining because the military medics in the field do not know how to properly perform an emergency prostate examination! (Winning! ;-)

Would be nice if we could also play as a "whiner"! ;-)

I always thought provoking or intimidating another person as an illegal act, or as bad as the actual committing of the intended crime.

Probably should generalize the word "Your" (or more correctly "You're") within your last statement just prior to "right to ..." and rewrite as, "People's right to ...".

I believe you're basically stating people are exploiting freedoms for their own wants and needs, again still illegal in my view. Exploitation has always been the next thing in line following the Ten Commandments, according to history as well as within today's world. (ie. I have ten wives, but at least I don't have 20 wives like the guy next door.)

Dr_Death: Shrugs. I don't know where you're getting the perception I'm preaching hatred, and considering it freedom of speech.

celticalliance: Here within the US we believe in freedom of speech. Shrugs. Would you like a hug?

I was somewhat serious. (ie. See past comments concerning implementing more civilians within and around the houses.)

On a side note, thought feedback was suppose to exclude comments about others' personality traits? ;-) ... Yes I'm very smart.