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.

galzohar: How do you get an idea that it is an easy fix, if you read my past explanations of citing Bug 0008082, "Night time (darkness) visual problem with [DEV] build..."?

Peter: Your question as to why there was a change, was likely answered within one of my most recent past posts within this bug/issue/feature. I also speculated why this bug might be difficult to fix, but since we do not have access to the source code, we cannot be sure or even really begin to speculate.

If I'm not mistaken, even with night vision, flares can provide additional illumination instead of just relying on moon light.

Why not a flashlight? ;-) By the way, nice video at the beginning - showing how wonderful flares used to work.

I'm wondering at this point if the developers did not create an individual brightness setting for flares (and flashlights), and the flare brightness is merrily a global variable statically linked into ambient night brightness. If so, I would strongly favor keeping the night brightness at it's current setting and coding the additional necessary separate variable for controlling flare brightness. Maybe this is why it is taking so long to fix such a trivial bug!

If I'm not mistaken, flares launched by mortar are exponentially brighter than those by rifle. As already mentioned elsewhere, we should also have handgun flares and flares sticks. Again, they should all have individual brightness level settings as well as colors.

See my second post made on this bug for the history of bugs related to this bug.

Bug #8082, "Night time (darkness) visual problem with [DEV] build..."

I personally think everything looks really close to reality now, except for this one bug as well as flashlight being too dim. (ie. Bug #9319 "Flashlight is too dim")

I completely agree flares are still not working!

I usually do not keep prodding an issue, but this issue or bug is obviously negating game play when the scenario is set to night time!

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

That would sincerely upset me if this is what truly "reviewed" means.

Flares were first initially wonderfully bright within ARMA 3 ALPHA. Now they're only a glimmer of what they should be.

Chem lights are also now significantly less bright then they once were, and all types of lights tend to pop-in and pop-out at seemingly random intervals with viewing distance set at adequate levels.

Yup. Seems like an internal struggle alongside with night sky brightness issues. (Some people think the sky should be baby blue, some think the night sky should be pink, etc...)

There were just some night flare usage televised by the news, demonstrating the Israeli forces in the past day using flares which vividly showed their high lumen value.

Additional: I just uploaded a demonstration of a flare. Unknown type of flare used within the E52951F2-5795-4995-92BE-D81E96CCD48E_cx0_cy7_cw0_mw1024_s_n.jpg image file. (Looks like a good one to two miles, or two to three kilometers until the brightness or lumes declines.) Also, it shouldn't be too hard for the programmers to link in the flinching reaction when AI (or players) are hit with a flare. And since it is a bright light (similar to flash bangs), should temporarily blind the player along with the night vision?

As of the latest update which included some supposed fixes for flares and flashlights, flares are still useless for ground illumination. Albeit, flares appear a little prettier then when I last recalled using them. (ie. Enhanced smoke trails?)

As of now, the dark landscape or ambient lighting has a very faint hint of increased lighting. This very faint additional lighting appears to get very faintly brighter as the flare approaches the ground. Increased lighting is almost not noticeable, and apparently still pretty much useless unless the flare is fired into the ground.

Yup. Shooting flares into groupings sometimes helps signal to others where the enemy are. But most times the gamers think it's just friendlies lighting up a cigarette! :-/

Yup.

Instead of voting for new categories (sitrep-00061 http://forums.bistudio.com/showthread.php?179116-What-would-you-like-to-see-worked-on-next-in-ArmA-3), which creates or instigates new bugs, how about mentioning a category concerning "Fixing Old Bugs?" (Hey! Bug fixing is really fun!)

The forums poll is somewhat a biased opinion of what has already been voted on via this Feedback site. Albeit, the user created poll may just confirm the voting results within this feedback site.

Here's a workaround for this flare issue, set time to daytime hours only. ;-)

Just shoot the flares just above ground level, or at the ground nearby the targets. Figured this trick out during Alpha/Beta when ambient lighting was being screwed with. Shooting the flares into the ground works especially well within forested areas. (Albeit, the flares don't last too long either. And probably best to use chem lights if at all possible. It would be nice to see some mortar launched chem lights. ;-)

Although, I still end-up shooting the darn flares into the sky out of habit and takes awhile to cognitively realize I should just shoot the flares into the ground!

Currently on Anzus's server, they're a bunch of bozos with post traumatic stress syndrome, restricting mortar HE/Smoke/Flares only until they're only requested. (The majority using mortar HE/Flare/Smoke usually have zero friendly kills, too.) As such, a person sitting on a mortar tube will end-up sitting there forever as they're never requested. (Hey. This is the civilian world, and not military. And they're not getting paid to play!) So in brief, a lot of servers are not routinely exercising these HE/Smoke/Flare features, or restricting the server to only daylight.

I remember when they had the flares significantly less bright during alpha/beta, so you only had a few seconds to make you sniping shot! (We had to use some team work to get one or two enemy down at night without night vision. ;-) Then there were builds with wonderful lighting effects, as well as colored effects, with some of the ARMA 3 alpha/beta builds!

Still, ditto. They need to make flares more bright, to show-off ARMA 3's colors at night. Not just for realism, but also for game play, else everybody is just going to use night vision all the time. I wonder if these people using night vision all the time, are complaining night time sucks? (And hopefully they won't reintroduce Bug #8082, "Night time (darkness) visual problem with [DEV] build"!

If there's internal controversy, just export the internal static variables into externally definable variables for map makers (or us) to adjust! (But then again, we might end-up with blue skies and flares lasting only one second if they do export the variables.)

What's basically being stated within the Bug description here; The flares are not providing enough, if any, ambient lighting upon the ground or upon objects within the area.

I agree ARMA 3 Alpha, flares were amazing against the night sky and ground. Albeit, unknown if it was realistic, but do know fireworks sure light-up the sky & ground at night. I definitely know the blue skies within ARMA 3 Alpha/Beta/Final during one point was highly unrealistic.

Personally I'd rather error a little bit on the side of eye candy versus realism, but more so enjoy realism. Chem lights early on were also amazing, and we enjoyed making a forested hill on Stratis looking like Christmas!

We might have a night time color/brightness contrast issue here between this bug and Bug #8082, "Night time (darkness) visual problem with [DEV] build..." which is now marked resolved. Another bug seemingly being worked on to suffice any missed aspects of Bug #8082 is Bug #0012717 "Night Sky is too boring."

Seems to be a little bit of a political battle with colors and brightness levels within ARMA 3. Seems we now are getting adequately dark skies or at least light polluted skies, but flares and chem lights seems to now be impacted.

I like the photos attached! They dramatically show the contrast levels, including the increased contrast levels of the night sky looking black with the bright flares against the night sky.

I'd like to suggest this bug be mark related or depending on Bug #0012717 "Night Sky is too boring.", but this bug is not a duplicate.

See ulukay's 2015-04-06 17:43 comment above? If relevant, sounds like a BattlEye bug.

No idea.

I'm only on DSL now for the past year, and can nolonger bear the unreasonable download times, as well has having to re-download everything again upon revert to the stable version. Would be nice to see something like rsync utilized, as well as separate install folders for Stable, Release Candidate, Developer versions. Security assuring DRM is nice, but this is paranoia.

I've figured-out the source of the problem for the ASUS Xonar cards; and further more, likely other sound cards as well as this appears to be an upstream Windows' OS and/or Manufacturer driver problem.

BUG REPRODUCTION:

1. Open Sound Playback Devices properties menu
2. Select the S/PDIF output as the default device, instead of the common (analog) Speakers output.
3. Using the sound card manufacturer's front end, view the Dolby Digital Live switch and your stereo receiver's display for the stream type input. (ie. Yamaha RX-V375: Option > Signal Info > Format, ... should show Dolby Digital/Dolby Digital Live.)
4. Once you've selected the S/PDIF output as the default playback device within step two above, use your sound card's frontend to switch from Dolby Digital Live output to PCM and then back to Dolby Digital Live, and you'll then notice your stereo receiver's display revert to only recognizing PCM output no matter how much you tick the Dolby Digital Live tick box.

BUG WORK AROUND:
So basically to avoid this upstream bug, keep the stereo speakers output set as the Default playback device without the sound playback device settings?

Realtek users, please follow-up if you see the similar effects with the Realtek drivers and/or software front end applications.

Looks to me, like the operating system is getting stuck in share audio mode, reverting to simple two channel PCM when the default output is set to S/PDIF?

Sorry for speculating on ARMA 3's wonderful C++ programming. Crow sure tastes better after it's gone through an aircraft engine. But still, the Windows' Dolby/DTS playback tests still function around this bug.

oukej: What is your stereo receiver reporting for the stream type. (ie. Yamaha RX-V375: Option > Signal Info > Format, ...)

I, as well as the previous reporter, already perform all the above. The problem seems to occur at the point during ARMA 3 is formating/initializing the multi-channel stream, or at the frontend when the driver/frontend gets the stream, it's either not formated correctly or a driver/frontend setting is stuck.

But as I see it, this seems to be more of a ARMA 3 problem, as the Windows' test Dolby/DTS test streams within playback work fine! I'm guessing ARMA 3 is sending a bad initializing sequence or a badly formated stream, or other similar issue. If I were a betting man, I would bet the stream isn't being formated properly, as the device initialization is likely performed by Windows' or the device driver's frontend. And past experience dictates, if the output format isn't correct or recognized, the frontend or receiver will likely not play or not play in the correct format.

Example: If ARMA 3 is randomly sending only 3 channels instead of 4 or 5 channels, with one channel being bugged, then likely the conversion will quickly revert back to PCM. Another possibility, what if one or more of the channels has a different sample rate than the other channels. Likely Windows' or the device driver's front end will also revert back to two channel PCM. Another scenario, what if ARMA 3 has more than one audio thread or process working at times, than Windows' will likely work in shared mode which is 16 bits @ 44100Hz, or whatever the user has set for shared mode. Lots of possibilities, as I know Linux ALSA somewhat well. I personally avoid a lot of problems within Linux by disabling shared mode (ie. PuleAudio, ALSA's shared mode, ...), and using only one application outputting sound at a time! ;-)

Yup. The reason why your 4/5 channel surround works, you're using the analog method and mixing/scaling and conversion from digital to analog has already been completed.

This bug is about the software driver enabling converting 4/5 channels to Dolby Digital Live or into two digital channels for transport over S/PDIF.

The only program I can think of, is the after market Uni-Xonar drivers, but they're basically just repackaged snapshot of the old official Xonar drivers with some tweaks. When it gets to drivers within Windows, compiling after market or custom drivers tends to be a large hurdle, as most users cannot perform driver signing. If this were Linux, I can guarantee you by a large margin, this issue would have already been solved!

Even the official Xonar drivers have this problem.

Clicking between PCM and Dolby Digital Live within the Xonar control panel while watching stereo receiver's panel signal information, I'm pretty sure I can see the panel flashing over to Dolby Digital Live but quickly reverts to PCM. It's as if the 4/5 channel audio is corrupted, and the Xonar frontend/driver doesn't know how to convert the audio stream (or 4/5 channels) to Dolby Digital Live so it quickly reverts to a PCM stream over S/PDIF. When going into the Windows' 7 sound playback properties and using the test playback for Dolby Digital or DTS for testing, I have no problems and the receiver gladly plays back the test media with either DDL or DTS.

So by process of elimination, something funky is happening with ARMA 3's multi channel sound output format or initialization, or something is occurring right at the frontend of the Realtek/Xonar 4/5 channel PCM to Dolby Digital Live conversion process. On the Xonar, reinstalling the driver (or simply cleaning the old driver) seems to quickly unclog the conversion to Dolby Digital Live, and my stereo receiver quickly shows "Dolby Digital" even before reinstalling the Xonar drivers. Could be ARMA 3 is doing something it's not suppose to with the audio stream? (I'll keep an eye on this issue for the next week as long as I have time.)

I'm seeing this issue also with an ASUS Xonar STX PCI-E card using the latest Uni-Xonar drivers, for which are just repackaged drivers with a few tweaks. I've also seen this same issue using the ASUS manufactured default drivers, for which are quite old.

This issue of ARMA 3 only outputting two channel PCM is sporadic, occurring every now and then, and usually more often only outputting two channel PCM instead of the two channel encoded Dolby signal.

Sometimes when playing with the S/PDIF and Number of Channel settings within the C-Media control panel, I can get the sound flipped into Dolby for some odd reason.

A possibility as to why sometimes two channel Dolby encoding would appear to occur, the Uni-Xonar drivers have an option for re-enabling Stereo Up-Mixing (ie. 2 ch to 4,6,7 channel) audio. Which is basically just mirroring the channels to the other extra channels.

The feature this post talks about, taking the 4-5 audio channel output of ARMA 3 and sending the four plus streams to the system audio driver for mixing into a transportable Dolby stream over S/PDIF, for which does support multiple audio channels.

I have not tested the above possible solution, nor do I want to muddle within Windows' affairs. ;-)

UPDATED: That's interesting. Just as I performed the following tasks, and logged-out of the multiplayer game, I noticed the signal now is Dolby Digital! Either Seamonkey was holding the audio mode open within the shared audio mode, or reinstalling the drivers enabled something. Or even an NVidia HDMI audio driver conflict. Shrugs. Could also be I need to re-install the Xonar drivers after each Windows Update or NVidia driver update.

1. Reinstalled the Uni-Xonar drivers
2. Disabled NVidia HDMI audio and the additional TV attached via HDMI within the Device Manager (I usually do this after each NVidia driver update, forgetting to do so on the latest NVidia driver update)
3. Quit Seamonkey/Mozilla browser

UPDATED AGAIN: Yup, reinstalling the Uni-Xonar drivers, or just the audio drivers here does the trick of re-enabling Dolby Digital Live audio streaming over S/PDIF. Matter of fact, the re-enabling of the DDL stream occurs once the driver uninstaller completes it's task of cleaning the drivers, prior to installing the drivers. So every time I want to play ARMA 3, I have to re-install the audio drivers.

Ditto, but there are also some other map or 3D bugs also holding-up large ships and submarines.

Helicopters can only transport a small amount of troops. Helicopters are significantly slower and less stable than fixed wing. Fixed wing transports also do not need to land, as they can air drop several cargo crates at once.

Many items can be air dropped, although there is a second air field on the east side of Altis. Several other smaller runways might support dropping cargo during touch and go landings.

(ie. We want more!)

mickeymen: Might want to open a separate bug, and post the bug URL here for reference as I think many will want to subscribe/vote whom are already subscribed here!

ie. Title, "We need a military sea transports."

When you look at Altis's size, it takes quite a while to get a vehicle or a small amount of infantry to the far coastal regions of the map. Either by land or by sea would likely decrease the time for transporting.

Without the transports, area of operations are usually quickly completed by using scripted Halo jumps. Scripted Halo jumps would likely be removed if larger fixed-wing or sea transports were utilized.