Please refer to Bug #14924, "Opening joystick config in game results in joystick disappearing as input option"

This bug you reported as well as the supposedly duplicate bugs reported by T-Bone within his Comment #92012 (ie. Bug #14924, Bug #20950, Bug #21856) may also be duplicates of Bug #14924, "Opening joystick config in game results in joystick disappearing as input option"

Within Windows 8/8.1, it's mostly futile trying to reconfigure power options as this bug with the USB controller is unavoidable. The only fix is to upgrade to Windows 10 or downgrade to Windows 7. Due to the amount of time this bug has been open and the fact this bug is supposedly an upstream bug, I do not ever expect this bug to be fixed for Windows 8.

I'm using Windows 7 for production, even though I also do have Window 8.1 installed. However most, if not all of my work is performed using Linux, including Wine if needed.

Which version of Windows are you using?

I wouldn't mark this as resolved, as this bug is still open and supposedly actively being worked on.

Should be marked as a duplicate only, and closed as a duplicate.

However granted, strange unexpected things do happen when people write the word "puck" within their statements. (ie. pucker factor)

I was shocked to not see any tracer packed ammunition cases for the newer weapons within the arsenal!

However, maybe they're still making adjustments and do not want the added overhead of maintaining duplicate ammunition types as of yet. However, this MarksMan is paid content. Personally, I would have waited to release, and released on a Monday allowing five days for any needed hot fixes. (But that's just what I would do if I were planning.)

Yup. AI problems are such a common occurrence, it's no longer considered a bug or issue.

I'm going to close this bug because this looks like the expected behavior, but I have no ability or permissions to close.

This bug occurs because of my following key mappings:

VIEW
Toggle View = NUM+ENTER, NUM+'.' key
Tactical View = NUM+'.' key

I've had to work around a dysfunctional NUM+ENTER key on my keyboard, and guessing the NUM+ENTER key might have broke due to over use. As such, the best workaround aside from buying a new $100 keyboard (for which is still always going to type worse than a 1980's era electric typewriter), was to remap and make use of the NUM+'.' key.

Funny, I see no other conflicts or usage of this NUM+'.', so I don't know why I'm getting this bug. But unmapping/deleting the default mapping of the NUM+'.' key from the Tactical View function solves or works around this bug.

VIEW
Toggle View = NUM+ENTER, NUM+'.' key
Tactical View =

This bug is still not fixed on Phoenix servers. There are still a few statements constantly resetting camera shake! (ie. The statements start with double quotes within the scripts, and contain camshake commands.)

After some testing using the Editor and entering similar scripting commands posted above, it would appear this bug is localized to the Phoenix server and it's usage of resetCamShake, more specifically and like the addCamShake. Likely this specific scripting is proving dysfunctional and acting erratically when using TrackIR hardware and/or using free-look extensively. Although CamShake appears to work well within my Editor, on Phoenix servers, the camshake feature is acting extremely odd, or not fluid with movements or experiencing significant Internet lag or a bottleneck whenever a CamShake movement is experienced.

If you notice, the shaking we experience now is the same rhythm as the prior persistent shaking. Just much less, and almost apparently completely omitted while using scopes and binoculars.

Also mentionable is the fact this same shake bug (in it's current state as documented within Comment #0088612)) I'm now experiencing, has been in ARMA 3 since likely alpha or beta, but isn't usually seen unless users make constant use of free look, or use TrackIR which makes explicit use of free look.

Hence, the root of the bug is still likely there, it's just back to being not noticeable or not detectable by the normal everyday user, or users not knowledgeable.

I'm pretty sure they only fixed half of this bug. If you also notice, there's almost absolutely no shaking when looking through scopes & binoculars, while the shake I experience now documented above within Comment #0088612, is only seen or provoked usually within third person usage. That's the other thing, camera shake is more noticeable within third person usage.

If they did hack around and now are negating camera shake while using scopes and binoculars, might be a good idea to omit or apply the same fix for this massive camera shake bug within the third person as well. But from a player's face value point of view, or from an unknowing point of view, this bug might only "look" fixed.

I have also just fgrep'ed the Phoenix Realism mission game files, and definitely see the only reimplementation or reactivation of CamShak is also apparently commented-out via double quotes.

$ fgrep Phoenix_Domination_V4G.Altis/ -r -e "CamShak"
Phoenix_Domination_V4G.Altis/fnc/injury/fn_injuredBloodloss.fsm: " resetCamShake;" \n
Phoenix_Domination_V4G.Altis/fnc/injury/fn_injuredBloodloss.fsm: " resetCamShake;" \n
Phoenix_Domination_V4G.Altis/scripts/ais_injury/fsm/bloodloss.fsm: " addCamShake [15, 999, 0.7];" \n
Phoenix_Domination_V4G.Altis/scripts/ais_injury/fsm/bloodloss.fsm: "resetCamShake;"/*%FSM</STATEINIT""">*/;
Phoenix_Domination_V4G.Altis/scripts/ais_injury/fsm/bloodloss.fsm: "resetCamShake;" \n

However, CamShake is definitely somehow being reactivated by some other means than just the Mission Files on the Phoenix Realism servers. As I try to read this scripting, it looks as if the double quotes, are just quoting a further embedded listing of commands? Hence, "resetCamShake" should also be further deleted/removed? (Actually, the recommended method is likely just commenting the sections out within C style /* */ comments.)

I think I've successfully proven this bug still exists within 1.40129533 version.

If you have TrackIR, you can reproduce by flying and sometimes either zooming in (with your head) or moving your head to the border region of the extent of head movement. You'll immediately notice the shaking is extremely reminiscent of the CamShake bug. Briefly looking elsewhere or doing something, the problem quickly dissipates, however very annoying while aiming at something.

If you don't have TrackIR, you can likely reproduce by using Free Look.

I'm using the Phoenix Realism server.

Playing on some of the demo servers using the RC (developer) build, I think there is still the reminiscent camera shake bug still present. (Come to think of it, I still think I have camera shake turned-off on my client here.) It's almost like the server is spamming the client, creating a sporadic screen jitter.

What's making it really difficult to further test, there are very few demo multi-player servers for testing in or very few other players. As well as some set to night without night vision and with non-working flares. The AI difficulty are also set to experts. So basically bump the expertise of the AI to dumb & dumber so they don't take over the compounds within two shakes (or two seconds), and provide night vision or please fix the flare lighting bug.

(Within the next day or so, I'll bump back down to stable version, log into Phoenix and download the map and grep the script to verify you commented the two script lines re-enabling the camshake upon death. But since it's only two lines, I don't see how anyone could have missed them. So I'm swayed to believe you likely did disable camshake.)

W. Carruthers: Make sure there are no routines calling fn_injuredBloodloss.fsm or bloodloss.fsm, as I can obviously see something calling reset resetCamShak and addCamShak. Matter of fact, I do not remember seeing these calls previously, unless I was just searching for "CamShake" without prefixed spacing. But with Bash history here, I'm using a previously used fgrep incantation! Did you just add these in?

roger@localhost4 /cygdrive/c/Documents and Settings/roger/My Documents/Arma 3/missions/Phoenix_Domination_V4G.Altis

$ fgrep ./ -r -e CamShake

I just updated to 1.40129533 and it does seem like the CamShake bug is solved using the Phoenix_Domination_V4G.Altis map. I just ran the chopper into the antenna tower, respawned and all is well still.

./fnc/injury/fn_injuredBloodloss.fsm: " resetCamShake;" \n
./fnc/injury/fn_injuredBloodloss.fsm: " resetCamShake;" \n
./scripts/ais_injury/fsm/bloodloss.fsm: " addCamShake [15, 999, 0.7];" \n
./scripts/ais_injury/fsm/bloodloss.fsm: "resetCamShake;"/*%FSM</STATEINIT" "">*/;
./scripts/ais_injury/fsm/bloodloss.fsm: "resetCamShake;" \n

Somebody has stated that there is no server side option for enabling or disabling camera shake.

I've found "enableCamShake false;", but somebody else has also stated this is a global variable on the server side, that can be modified by user modifications. I would imagine the fix to this is defining the variable as static or local to the server?

Looks like this issue is still occurring on Phoenix Realism servers regardless of this setting.

2015.02.26: I just did some grepping of the Phoenix server mission files (ie. Phoenix_Domination_V4* -r -e CamShake) and found several files resetting Camshake values, likely re-enabling CamShake server side and regardless of whether the server explicitly disabled CamShake. These mission files should not have access to the CamShak server side variable, hence should be a local/static value and not globally accessible. Hence, the likely fix.

Per FeralCircus's post above, Comment #0087903, I heard someone state they may have disabled camera shake on the Phoenix Realism server within the past day or so.

I cannot confirm the work around for this bug, aside from the fact I haven't seen this bug within the past day or so. (Not enough time to set up a server within Windows', dealing with DRM, etc..., easier & quicker debugging on Linux... etc.)

Another possible past related issue, I remember the camera shake in ARMA 3 Alpha/Beta or early release versions of ARMA 3 while within the AH-64 gunner seat. If auto-hover was enabled, camera shake would occur while looking through the gun camera. Disabling auto-hover would cease the camera shake. I somewhat assumed this was an issue with the joystick axis, and think I created a dead zone to either relieve this or a fix was published.

As already noted above, very likely related to Bug #0022394, "UAV camera shake at specified altitude"

This bug is extremely active within Phoenix Realism server. It's using the Domination maps customized by Xeno. This bug makes the game almost unplayable, unless the weapons are locked guided to their target. Even guided rockets are missing because of this bug.

From my perspective, this could be network lag causing camera shake? Like I"ve stated, the bug is reproducible on Phoenix Realism server using the Domination map customized by Xeno.

This bug also seems to be being caused by the server. I've restarted the client, and the bug still exists. Upon first joining the server, and apparently after a fresh restart, the bug was not present until once I died. And then after death the bug became persistent. I think I smell a hot fix!

I also tried disabling camera shake within the Difficulty settings which had no effect. Possible the camera shake is mandated by a server side setting?

After reading all the comments, the overload on logs can cause this with overloading the network, but I'm speculating.

Likely related to Bug #0022400: Camera shake after 1.38 update

I think it's most noticeable while flying, but it's also somewhat noticeable while running around and viewing in third person.

Adjusting the TrackIR software settings has no effect, to include the Precision setting.

I was encountering significant problems while flying the 3D aircraft last night, along with also noticing the selected aircraft ammunition type being reverted to guns after each time viewing through a UAV aircraft using the UAV terminal. All these small bugs are seemingly increasing over the past months, with no apparent substantial fixes except what looks like hacks. :-/ (Shrugs. Significantly detracts from the fun of playing games.)

Thanks St. Jimmy for further confirmation and further clarification of this continuing bug/issue!

Fast roping would be more required if the terrain were more cluttered with trees. The terrain cannot be more populated with trees due to likely frame rates? And as such, this feature/bug is probably depending on the frame rate issue.

Wish they'd publish bug dependencies or what is holding up the integration of feature!

Count your blessings. At least the feature is scriptable!!!

Maxyzzz940: I didn't understand the question, but yes all those actions are possible within the current menu.

With all these scripts, there should be an official repository, using something like GIT, and a script utility to enable/disable script/feature for server administrators to pull and enable/disable scripts without manual fuss. (ie. Something like Gentoo's Layman which pulls official and personal repositories, using CVS/SVN/GIT.) And, scripts should be published with standard version numbers, unlike within the Windows world. Whether by date or version. (ie. script-20141221 or script-1.12)

I think you still need to use a custom module/script to enable this feature?

Fast roping within the *1776* servers is already possible. However, PhsyX and rope graphics are currently missing.

So fast roping is currently possible, just missing graphics & PhsyX. Also, people cannot be extracted by deployed rope rigging, which is previously mentioned within this Bug/Feature. (You see the rope extractions being commonly performed by US Coastguard; As well as within other Army related Movies. ;-)

LOL. Now that's the tallest stripper pole I've ever seen!!!

I forgot about the Coast Guard using roping for extractions, too.

I still say Atlis needs more forested terrain for fast roping, or for rope extractions to be utilized more frequently. Stratis was a good example, providing heavily forested areas along Kamino Bay, and surrounded by ocean making rope insertions desirable.

I think Atlis has less foresting due to forests causing frame rate issues?

Atlis also has more accessible land, requiring less ocean insertions. Albeit these issues are probably best discussed under a separate thread, titled more appropriately. Also to note, map makers always situating their operating areas within largely accessible cities and other largely accessible areas is probably another factor, providing many hours of boring repeated scenarios! ;-)

From what I've experienced, there people can only deploy and not board helicopters via ropes.

On Stratis, there were many heavily forested areas where tactical drops were necessary. Humorously on Altis, Altis is not heavily forested allowing easy landings. Ropes are still useful though for roof top deployments, etc. And Altis doesn't have many, if any, coastal areas for operations for ocean insertions.

Using the EPD server which currently has ropes implemented, people can deploy via ropes, but not board the helicopter via ropes. Ropes are also currently invisible from third person view. Sometimes on auto-hover or standstill, the middle mouse button menu does not have a "Deploy Ropes" option, or the option disappears. (ie. Triggers may glitch.) Also; the Lift (Lift Chopper), Release (Lift Chopper), Deploy Ropes middle mouse button menu options tend to be jumbled amongst other lesser priority menu options, confusing the pilot and causing unnecessary scrolling to acquire clicking the menu item. All of the fore mentioned may or may not be related to this specific feature request and solely intended as feedback on current implementation within Beta!

I find it extremely useful when piloting and lifting an ammo crate or vehicle, to deploy ropes while dropping a lifted item; allowing passengers to deploy more quickly in case a SAM locks on or other incident occurs. However there's always somebody remaining on board not knowing about deploying by rope, and the person requires landing to exit.

Maybe Altis needs more heavily forested areas and areas for ocean insertions, for utilizing ropes & underwater assets?

Albeit, the scenery does look quite awesome while flying helicopters!

One vote here to make the onscreen rope emblem resemble a stripper pole. ;-)

Awesome feedback and corrections DennisModem. ;-)

A note. Network lag seems to be a factor with the availability of menu items such as the simple "Get Out" menu item only displayed at less than approx. 5m above water. This prompt item is sometimes there and sometimes not there even though all conditions are met due to network lag on other remote client computers.

So having prompts depending on other pilots' menu actions might be overwhelming for most players due to network lag, but within a perfect world where everybody is on a local server, would likely be the best method to implement.

I do see the reason for having pilot or crew chief authorization in order for passengers to deploy ropes, as players would tend to deploy them whenever. However, implementing it, passenger players would then likely need to wait for up to five seconds sometimes to be able to use the fast rope option, causing the pilot to hover longer than needed.

Shrugs. Personally, not too particular as to how it gets implemented, just as long as those passengers insisting on getting dropped at forested or non-landable XYZ point have an option to deploy. ;-)

I should also note, jumping out of a helicopter within anything but calm seas at < 5m is extremely difficult, as hovering above rough seas a this height is extremely difficult. Hence, fast roping into the ocean is almost required with wind and weather effects are enabled.

Within the latest ARMA 3 Beta release as of today, the parachutes do take up a backpack slot.

If I'm not mistaken though, when a parachute is required, the equipment backpack is slung underneath the person parachuting or additional equipment is attached on other carry-on packs.

Also, we can carry or drop ammo crates for deployments.

Roping is really essential when extracting from forested areas.

Good Call Phoenix.

I would like to think that is exactly where they're going with this feature, as with most other features not already implemented. Providing the hooks for such features after debugging in completed. Likely one of the main goals for this feedback server, ensure they have all the required hooks in for every thinkable script, mod, or feature.

We'll probably start seeing activity on these feature requests sometime around Autumn.

I should also add the main reason why I want to see fast roping, is for the (wonderful new) players (who spent their money on the game) whom request drop-offs or pickups within the middle of forested areas (due to their unawareness). (Feel free to replace language within parenthesis with your preferred vulgar language. ;-)

Another reason, when there are rough or high seas, it is almost impossible to maintain 1-2m hover height. Although I enjoy the challenge, network lag hinders or severely delays the "Get Out" prompt for passengers. As such, fast roping would be better for these situations but a delay should be experienced unless they detach from the rope while fast roping. Also, the ropes need to be undeployed else they become a hazard.

Ropes will deploy when,

1. The players activate the "fast rope" option.
2. The pilot deploys ropes.

Ropes will remain when,

1. The player is on the rope.
2. When the player is on the ground and not attached to the rope.

Ropes will destroy or disappear when,

1. The chopper rises more than a number of feet(?), and/or
2. A "Rope Undeploy" option replacing the "Rope Deploy" menu option. But to reduce menu clutter, the option may only be present when within rope usable altitude?

I should also make mention, some use the ropes to ride in or ride out. Would be neat for hot extractions, but can guarantee a few pilots will also be towing a few trees afterwards.

Maybe this feature request could possibly fix Bug #0007485 "Should be able to fall into water from greater heights and not get hurt."?

Stiffwood: You reading comprehension concerning my post is incorrect and you're not reading my post correctly.

They stated physx is not yet enabled.

Google "physx and '-nosplash'", never mind, here's the data:

http://steamcommunity.com/app/107410/discussions/0/864961722097793772/?l=turkish
See phnord's post at 12 Mar 2013 @ 10:25am

Somebody mentioned with a post about -nosplash and other commandline options, physx is yet to be enabled.

Cr*p. I just want to be able to eject from an aircraft about to crash being piloted by stupid pilots!

However, as little use roping will be used within games, roping down from a chopper hovering above tree or heavily forested terrains might be essential for the more realistic maps!

+1 vote from me.

This could likely be implemented by a simple hack or scripting, when ejecting when hovering < 100 feet and < 5 miles per hour, soldier will drop by rope.

(I really kind of like this as it's always a hassle trying to find a good landing spot sometimes. Prospekt, guess you didn't see him kissing butt for this feature. ;-)

I don't know about anybody else, but sometimes when using the scroll wheel via my joystick, the joystick registers the scroll wheel actions as double clicks and double scroll increment events.

Quite possibly though, the Saitek X52 Pro driver/software could be glitching. But I've only seen this bug occur with ARMA 3 so far.

Anybody else love when you're trying to evade fire by getting inside a building quickly by using the door, inadvertently simply pressing the action key to open the door but only to be stuck healing yourself (for another five plus seconds I might add...) while still taking fire still outside the door?

It took quite a while to learn when injured as indicated by having a medic icon on screen, to fully open the context menu and select the "open door" option to avoid the default heal option when injured. I don't know about the rest of you playing the game, but I prefer to heal myself inside the house versus at the door steps under heavy fire!

Clunky 'climb option' with modifications implementing their action items in any order. (ie. Such as moving the 'Release' option around when 'Deploy Ropes' option becomes randomly available. ;-)

Thank God? This is now apparently fixed within:

18-05-2015
EXE rev. 130770 (game)
EXE rev. 130770 (launcher)
Size: ~166 MB

DATA
Tweaked: Substantially increased overall performance of Wipeout and Neophron cannons so they are now able to properly damage even heavily armored vehicles (Bug #19993, Bug #22146)

If you study astronomy, there is really no such thing as these star field lens flare graphics within reality.

If you do see lens flare from strong light sources with star like effect shapes, almost always a star effect filters and other color filter has been added! On the flip, I've briefly heard star effect filters can be used to exaggerate light to detect colors better, such as a prism. (I personally do not like to use star effect filters or any color filter while studying astronomy related topics.)

I think what the reporter more or less wants, is likely a realistic light flare along with Bug #9319 ""Flashlight is too dim..." fixed.

I'm also noticing within the current release, aircraft collision lights, other aircraft lights and runway lights cannot be seen at all during dusk or cloudy skies! (It might be we're getting close to some of these remaining lighting bugs to be tackled.)

I'm using Kimis HUD Mod to put radar ground targets back on radar.

Iceman: I believe disabling radars on helicopters to be an unwise decision. From my preliminary research, military aircraft have some sort of warning system for anti-aircraft missiles, including (if I'm not mistaken) ground/air radar.

This decision likely ruined game play, and should have been an option created within the server configuration file. Also note, the radar is useless when flying above 1,500k, including searching for air targets flying above 1,500k?

I suggest opening a new bug, as this is likely on their ignore list. :-/

(I'm reading several cockpit helicopter manuals clearly citing the usage of radar.)

Many thanks for the script, providing further insight into the addAction and it's usage!

I'm no pilot, but the flight boards appear duplicated between pilot and co-pilot. And from hindsight, the co-pilot should be able to perform such tasks alongside the pilot. So I personally do not think there's a problem having both pilots having access, except for the fact you might get a psychotic co-pilot whom might like to play with the lights. So it might need some final fixing detecting the "unlock controls" function, but I would be happy with this if it were published as is, along with likely many other people.

But from what I'm guessing, you might also be trying to explain the co-pilot cannot be given this feature/function unless he's detected as a the "driver" or the pilot with the controls. (ie. No function to check for the co-pilot seat occupant, unless he is driving/flying.)

Still no function mapping for Collision lights, for mapping to a joystick button. Collision lights could include flashing lights for vehicles, such as police or caution lights and placed within the same category as the common lights/headlights key.

Should also be a spot light key, which could also include head light high beams. (Shrugs.)

This needs to be closed. This bug was fixed a while ago, and I now can vividly see when my own team is firing on my butt. @#$@#$ :-/

I use no modifications, just vanilla ARMA 3.

The equipment I additionally utilize and this bug then becomes extremely evident is Track IR hardware, and then viewing as third person during flying over AA vehicles. When flying in third person using Track IR, you'll notice there are almost no smoke trails from ground fired rockets! However, when viewing from another person's point of view from the ground and watching AA/AAA rockets go into the air, you can see smoke trails without issues. So this seems to only occur from the pilot's point of view, and easily seen in third person pilot seat, and might be more easily seen when using Track IR as it's difficult to move your head easily as third person via keyboard, etc, as the keyboard or joystick head movements are static, or limited to one limited angle and a limited span. Even when viewing externally and watching another aircraft fly over, you're still omitting from viewing from the pilot's seat.

I'm also wondering if at night (including hours of dawn and dusk), we should also be seeing flashes of light from the ground further indicating AA/AAA rockets firing, as well as light trails from the rocket motors? Others on the ground can easily see this activity.

Another but unlikely scenario, the smoke trails could be appearing as invisible from the angle of view with the colors used to indicate smoke trails and blending into the ground colors. It is very rare that I see any smoke trails and more like a fluke when I do see a rocket smoke trail, and I have yet to see any flashes of light from the ground AA/AAA firing at night. I doubt this has to do with the colors of the smoke trails, and I further mention below the only AA rocket fire smoke trails that I do see, might be coming from infantry AA rocket fire.

Maybe if I get more time, I'll put like 20 to 40 AA vehicles (Tigris) on the ground and fly over at a very high altitude, and at night. I'm wondering if decreasing the expertise will make them poor aimers, might aid further detecting this issue. But I think the magic here used for detecting this issue is using TrackIR hardware. Also, it maybe the rockets trails I do see are those only coming from infantry AA rockets and not the AA vehicles, or Tigris vehicles.

2015.04.28 01:00 UTC: I placed approximately 40 Tigris with low expertise on the map and used the Typhoon to fly-over using a view distance of about 3700km at an altitude between 3000-4000m. I now see some very brief white flashes of light, but no smoke plumes from the rocket motors. The flashes of light, or simulated rocket motor light, are so fast and so brief, I'm not sure it's even realistic as I wonder if the rockets can even travel at the speed of light. Usually when two objects are going in the same direction, the second object has more of a chance of being fully seen versus when two objects are moving at each other. Shrugs. Seems really odd to me. Maybe getting some experienced witness testimony as to what a pilot should be seeing from AA/AAA ground fire? ;-) (Also, there's still no tail number/art light when using collision lights at night. Aircraft use tail lights on their tail numbers to distinguish themselves from other aircraft at night. Main lights on aircraft still provide light while only on the ground, and main lights are never able to be seen once in the air.)

You're welcome.

After the latest patch, out of the 50+ SAM/AA/AAA (surface-to-air/anti-aircraft) missile fired (by two Tigris) during a fly-over at an altitude of >2,000 meters (for which the AI are now programmed and able to see unrestricted over 1,500 meters after the latest patch), I still think I only saw maybe one or two AA/AAA missile trails while viewing as pilot from external 3D view. If any missile trails, as the trails I saw from 3D pilot could have been only artifacts of the trails.

If you're on the ground as a foot soldier, I believe you can see missile trails without any problems.

If I'm not mistaken, this becomes a problem with passengers of helicopters, also not being able to see or detect ground AA/AAA fire. During the day, should probably be able to see small smoke plums (and possibly flashes at night) from the ground firing and then smoke particle trails through the air and possibly light some light flashing from the rear of the missile rocket motors.

This bug is currently unassigned.

Finally using the 69th Enjin* server, I saw one AA missile trail from some infantry ground AA being fired at another pilot. (It was a very short, low, & quick flight for the AA missile toward the pilot head-on who was flying too low.)

So far ARMA 3 Version 1.40.129* still doesn't show any AAA missile trails from the pilot's perspective. (Can only see missile trails usually if you're on the ground or the one firing the missiles. If I'm not mistaken, can either sometimes or most times see infantry AA being fired at other pilots.)

When parachuting, you can look around. I believe those keys are mapped to the number pad on the right of 105 key keyboard. Some keyboards omit the keypad to the right of the keyboard, as they're not typically used except for accounting purposes or repeated number entry tasks such as databasing tasks.

I also have Track IR, and can easily look around without using the number pad to the right of the keyboard. Also, the Enter key on the number pad toggles the point of view from first person point of view to third person point of view. I personally believe in using third person point of view routinely as you have to realize we're really just looking through a one foot by one to two foot window, and sometimes much less. Really difficult to squeeze an entire simulated virtual reality within such a small window, and using third person point of view tends to provide much more information as well as lacking the sensation of gravity. Third person can feel like cheating, until your realize the fore mentioned.

If you have one of the smaller keyboards, I'd suggest investing in Track IR as neither I use the number pad much except for routine usage of the number pad enter key. And remap the number pad key (if it isn't by default already) to another key such as the Enter key?

Anybody else also notice the new weapons arsenal does not include any of the Vermin magazines? (Shrugs, maybe it's just a bug with 69th servers.)

Duplicate of Bug #21394

Duplicate of Bug #18733, "Global chat is laggy in almost every server"?

Duplicate of Bug #21395

Duplicate of Bug #18733, "Global chat is laggy in almost every server"?

I was on as pilot, with a co-pilot. Gave him the controls and then later took back the controls. The server had CBA mod loaded, and I also had CBA loaded. I don't think I noticed any problems with frame rate, but he hopped out just after I retook controls.

Jets too also ALWAYS explode! I've very rarely ever had any chance to eject, hence parachutes are basically useless when flying a jet. I figure my chances have been one in 500.

I've updated my Bug #26690, including possible solutions.

But just realizing too that jets suffer always exploding, seems to definitely insinuate this is bug is definitely a bug having a broader spectrum. I think I have opened a bug for the parachutes being useless when flying jets, or at least made mention within another bug at the very least in the past.

Aircraft have a tendency to disintegrate in mid air. "... And if the aircraft does disintegrate from around the pilots & passengers, usually the pilot & passengers are still alive and can deploy a parachute."

FYI: I tried the above within the recent version of ARMA 3, and have yet to be able to control a static GMG/HMG. However, I have little problem controlling a UAV aircraft or UAV vehicle. I haven't seen anybody using autonomous static emplacements recently.

I've long ago figured-out static (AA, AT, GMG, HMG, Mortar) emplacements. Along with facing direction, as well as assembling them up in the military towers.

However, I've never figured-out autonomous (GMGa, HMGa, ...) emplacements. I have set-up some (GMGa, HMGa) autonomous emplacements, but I never were able to use them or instruct them.

There's also an "Auto Machine Gun" emplacement class which seems to have no tripod, and the only use for it seems to be for setting and looking nice on the ground.

I have had few problems using the autonomous aircraft, etc. So just the autonomous static emplacement GMGa and HMGa are troublesome or seemingly non-user intuitive!

Many including I, do not know how to setup an autonomous static (HMG/GMG) emplacement.

Matter of fact, pairing the backpacks themselves can be extremely difficult due to the lack of descriptions.

Care to elaborate a little on how to setup and use an autonomous emplacement?

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

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

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

Lex: The "chat" key is CAPS LOCK.

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

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

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

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

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

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

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

We've more appropriately suggested implementing ear plugs, simulating radio headsets, and using noise canceling headsets for pilots, etc.

(If you also noticed, there's also no emulated sun visors when wearing the pilots helmets either!)

Shrugs. I think they need to implement all the three suggestions I posted.

I did not vote on your vote, although I am 100% for this bug. You bug entry will likely be marked as a duplicate sometime within the future.

Cheers.

Kind of biting my lip concerning the topic change as well.

If the object distance is limiting the object from being seen, this would appear to be the intended result? If so, the next question would be, "What or where is the bug or issue requiring further attention?" Should this bug be closed?

I cannot seem to modify any of the characteristics of flares, using the above fore mentioned script commands or other commands.

However I should make mention, setLightFlareMaxDistance sounds like it will likely obey the player's maximum view distance.

I haven't gotten positive confirmation, but assume it too was fixed.

I do know when I cuss at the enemy in Direct Chat, the enemy do not respond. (ie. Yell "Hey Numb Nuts" from approximately 25 feet away just prior to shooting an enemy in the rear buttocks.)

Odd. Fixing without testing? Is this legal? ;-)

Apparently now fixed within the Change Log:
http://forums.bistudio.com/showthread.php?149636-Development-Branch-Changelog/page54

22-05-2015
EXE rev. 130872 (game)
EXE rev. 130876 (launcher)
Size: ~180 MB

Engine
Changed: VON is played in 3D for more channels

But as usual, always test to verify first that the bug is really absolutely fixed before closing this bug!

I don't like it either when I'm laying low and I automatically stand up during a fire fight.

I also do not like performing an action (whether by accident or intentionally) and not being able to halt, stop or cancel the action.

I believe this has to do with the automatic jump function when running over obstacles, and one of the side effects is this bug. When crawling or moving while prone up to an obstacle, the player will automatically stand up.

I would vote for this bug, but won't because I tend to like running over obstacles. Removing the feature bugging the bug author, would then require players to always pressing CTRL-V again to just get over obstacles all the time.

Steam always prevents me from a graceful shutdown on Windows 7 and Windows 8.

I can almost guarantee this issue is related to Steam and Microsoft, hence upstream.

I was going to say, problems just do not mysteriously solve themselves overnight on computers!

It maybe the servers are having memory runs, and may have been preventing my client from connecting during 1.54RC. This sounds plausible as I was getting no minidumps on my client.

The is a classic "memory leak" bug.

Amazing though that this type of bug bypassed in-house memory debuggers!

But there has not been any hot fix since this opening of this bug correct?

How about the latest developer version? I think this parallax issue is fixed when flying the Ocra?

In other words, the target cross hairs remain fixed on the target ahead, while still being able to look around without the target cross hairs moving with the head motions.

The likely reason you're exploding upon impact, as I do sometimes as I also have CBA enabled, is you're touching the ground too fast while parachuting. (So basically you're character would be dead anyways, as you were not slow enough before touching ground.)

You need to pull back or slow your ground approach while parachuting by pressing the 's' (or 'x') key as needed.

The likely rational for what is happening when the explosion occurs, the collision or impact with ground is being confused (by the CBA mod) for a vehicle impact with the ground. Could have yourself a little fun with this glitch, by landing on some enemy vehicles, etc. ;-)

Bug #0006391, "[Feature request] Draw your own waypoints on the map! (for Pilot Class). Side use: Coordinated ground attack!"

No people do not migrate to TeamFart. They migrate to Task Force ARMA 3 Radio. (AKA TFAR)

TeamFart is nothing more than glitter and eye candy. A real man's application needs no front end, except the current open sourced essentials and a good open source codec of choice! TeamFart is still something required by the open sourced Task (ARMA) Force Radio module.

What's even more humorous, some of those TeamFart servers, have 100+ channels/rooms where beginners cannot find their default respective channel.

I formally contest your rationalization, as I never really did get involved with TeamFart or the users of TeamFart, until Task Force Radio was implemented. ;-)

I do agree the ARMA 3 internal voice communications needs to be stabilized, as it is the default communications for most, if not all beginners, and even seasoned individuals. (ie. I tended to use internal communications over TeamFart due to beginners not being able to hear my communications on TeamFart.)

I agree whole heartedly TFAR should be integrated, with the option of upgrading externally. The ARMA 3 internal communications should be additionally configured for either better sound codec, or give the users the options to increase the quality of internal communications sound quality.

I can easily this bug being more popular than weapons emplacement, as this bug tends to affect everybody, whether flying, driving or just on foot!

I think I mentioned previously, that this bug's likely source of breaking was during the initial attempts for optimizing the ARMA 3 binary for increasing performance. I think others mentioned UDP or other network protocols as a likely source. Either or, it was during the initial attempts of optimizing.

If this does not motivate developers, than I would further infer fixing this would allow me to better yell at the last gamer who shot me in the butt!

Cheers!

Again as I just remembered when reading the recent comments just now, this bug occurred just after the developers publicly pushed it's initial attempts at coding optimizations, to try to satisfy the number one voted bug concerning the game not making full use of system resources.

I recall the rise of this bug specifically due to extensively monitoring the developer's log during Alpha, Beta then early Stable releases. And then the initial push/commits of optimizations within the developer branch. And then just after the push to stable branch, this bug arose. I now recall I also likely made mention of this scenario as a possible cause of this bug likely early within this bug's comments as well.

This bug is also tagged along with Bug #15987 "Multiplayer Issues Central Hub", and also lists de-sync map and 3D reality issues. Hopefully with a little noise, this gets fixed for Christmas's stable patch.

Isn't this fixed yet?

Every update so far has failed to fix this trivial bug!

Bug #25342 "Possible fix for laggy and choppy VON/VoIP channels" looks like a duplicate, but at least provides a possible solution.

Terox: I've witnessed this bug with players 10 or less, and only occurring a select few players!

Can we all slander the guy whom invented the script to hurt/injure players whenever they activate chat when tuned to Side/Global chat? (ie. Two accidental chat key presses while tuned to Side chat and the player dies.)

I encountered this script on Engin/Ingin 69 server.

This is exactly likely why BI will not provide hooks for disabling the channel for (child) server owners, as doing so deters socialization and makes game play worse. (Give's BI's game a bad impression for players.)

Although as irritating as Global/Side chat channels being broken, it's even far worse to implement a hack that is not well tested or engineered correctly! And using or abusing the injure functions is a bad response for when more experienced typers whom always have their finger hovering above this key on the keyboard!

And to think, some servers are not effected by this bug nowadays, while some are or some individuals are. So likely something within the firewall settings of players and servers is the cause, and something with optimizing the runtime executable provoked this bug even further.

I was messing around a few nights ago monitoring up and down bit rates of my network interface.

If I'm not mistaken, I saw similar up/down bit rates when talking within ARMA 3 voice chat as compared to TeamSpeak. So one should expect voice chat to be as clear as when using TeamSpeak with those bit rates.

On the flip and I keep forgetting to mention, I doubt if many have utilized digital two-way radios within a wide area network (ie. 5-10 square miles), but the audio quality within the game is still far better than that of real life digital radios! (Aside from this bug concerning packet loss.) Fact is, most do not know how to talk on a radio, which further creates over use (or stress) on the voice chat engine within the game.

I previously already mentioned here or elsewhere, this seems to have started occurring about the same time they rewrote code for optimizing execution due to the popular slow framerate bug. Therefore, you can likely see the optimizing occurring within the globally defined variables, while there is no problem within locally defined variables. Likely this further has to deal with optimizing automatic intelligence (ie. AI), as those would be globally defined variables. If you also notice when you see similar network lag or "desync", the sound on global/side chat is also similar on playback, or stutters.

I do not think TeamSpeak is a viable solution for communications per the following:

1. There's no indication of who is speaking. Nobody knows how to talk on a real radio system by first indicating who they are, and who they're talking to. (ie. Amateur Radio)

2. TeamSpeak creates odd or strange activity while using alongside Saitek's Profiling software. I forget the bug as I've stopped using the Saitek Profiling software, but I think it has to do with direct access somewhere and will cause a blue screen or operating system crash and reset when encountered. Many bugs seem to persist and go unfixed.

As such, TeamSpeak is great for listening to the girls chat away.

Personally, I'm biased toward vanilla solutions and at most scripting. Requiring a player to get many other XYZ plugins and/or applications, significantly deters player involvement.

There's already an open bug concerning integrating something similar to ACRE within ARMA 3. I gander, this might be a possible next feature to be implemented as it is quite popular.

Dunno. Maybe they sliced network optimizations right through globally defined chat somehow? All other chat channels (I think) are defined locally. Hence, maybe the global/side playback function is somehow checking intermittently for a return 0 from all players on the network during playback?

I don't have the code in front of me, so it's not like I can tell you, or even guess for that fact unless I could read hex or binary. ;-)

Ah, the Seven Wonders of closed source code! You never know what you're going to get! (Except you're always assured to always receive the never ending phone calls from phone solicitors, wanting to gut your heart out. And I've yet to hear a phone solicitor stutter.)

But it seems more realistic with Global/Side chat channels restricting global communications. (Just like it is in the real world!)

Ditto what Terox stated.

Compared to my very conservative clothing, even my clothing has more flare than this game!

Thanks. Looking it over.

Let me guess, an "addon" is somewhat a misnomer.

What needs to be done for implementing the above, is to define the above class within a *.hpp file (similar to a header file, but only redefining a type), and then it is later "#included" (within a script) and essentially is used for redefining a type of ammunition or replacing a type of ammunition.

I like how there's a lot of information on scripting, but dislike the fact that writing scripts (etc) still requires an internal developer to pull all the pieces together as the documentation either lacks clear examples at times, or doesn't clearly define the technique or clearly provide instructions. Anyways, enough of my ranting and I'm thankful for what documentation there is, and far better than other software projects.

So, any URLS pointing to quick examples (or any quick example) for implementing the above classes within my Editor? (I'd like to verify the intensity.)

pops: I'm aware of that, but I just could not resist pouncing on the idea of having the community create their own balloon sounds!

zealot: I was recently playing with flare settings, but failed at scripting something similar. I'll give that a try within my own map scenarios!

I tried the above, but I saw no difference when using GL flares.

Funny. The following notes within the Change Log seem to dictate that the following issue is more important than this bug here as well as Bug #9319: Flashlight is too dim.

2015.04.01 Development Log entry:
"Tweaked: Further adjustment of the sounds for Balloons"

As I follow the log, seems this is either the second or possibly the third time the balloon sounds has been adjusted. I'm sure a lot of people can more easily and quickly submit their own balloon sounds!

Look at the bright side, the mortar flares sure make pretty colors in the night sky! Fireworks for effect anybody? ;-)

Hello. We're still here wanting to make use of our flare guns!

Night time ambient lighting was fixed long ago, and now just waiting for this one little issue which completely prevents making any use of flares.

I completely agree with Kilian and again cite Bug #8082, "Night time (darkness) visual problem with [DEV] build...". For a long time, there were no dark skies at night, while flares and chem lights were wonderfully lighting up the area.

Now, ambient night time brightness is just starting to look really realistic. But there are still a few remaining minor bugs with light levels during night such as this one with dim flares, dim flashlights and dim headlights on vehicles.

My guess is, flare brightness levels are statically linked into night time darkness level which is a big no no in computer programming! ;-) (And likely flash light brightness and vehicle head light brightness as well!) But I could be completely wrong.