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

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

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

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

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

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

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

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

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

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

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

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

Same thing here, after I finish Crossing Paths and Im at Camp Maxwell the game freezes, there is just a black screen and all I can hear is rainfall and some background noise. My character is able to use the radio but that's about it. This happens every single time, Ive tried restarting, verified game cache with steam but no dice. Its very repeatable on my computer.

Here you can find the fix (I've found it too)
http://feedback.arma3.com/view.php?id=16602&nbn=4

I'm running into a similar issue with the same mission. I get the walk into Maxwell with the cinematic bars, and after the walk in, the cinematic bars don't go away, and I can't access my inventory, or map. James' speech seems to end early, after mentioning that the AAF hit us hard last night. I think he's supposed to say more than that, but I can't be sure. So far I've had this or a very similar issue every time I've started this mission, so quite repeatable on my computer at least.

We need dxdiag and files from this folder for solve your problem. C:\Users\<Name>\AppData\Local\Arma 3\
Can you upload somewhere in winrar package please?
When package will be smaller than 2,097k, so you can attach here. When package will be bigger, please use some free sharing service and post link here. Thank you.

http://feedback.arma3.com/how-to-user.html.html

I noticed that in the recent patch (not sure if it's related to this one, could have been done already earlier), they stop shooting and run to cover, if they're under fire/being hit.

I've noted this in the campaign as well, I take 3-4 shots at the A.I and it just won't die until a 5th shot.

In the campaign I've decided to set it at the lowest difficulty, then set the enemy A.I skill value to = 0.00 and they STILL just stand there, look at me for at least 1 second *this happens while I am prone as well.* then somehow just one shots me. This issue really just infuriates me greatly and it's just pushing me farther away from trying to enjoy the campaign entirely, this must be resolved soon!

Duplicate of #15830.

duplicate of #7257

same here

maybe it had to do with the date + 64bit combo

I also started getting this issue today.

Win7 64 bit
Vanilla Arma - no mods.

Could running the latest BETA video drivers from Nvidia cause the issue?

331.93 - BETA

Very strange. The issue disappeared for me too, one day later.

for me the issue disappeared today without being able to reproduce anymore ... strange somehow

Having the same problem peoples, tried turning down graphics and all above, verified game catch thingy, and nothing bitches....damn this sucks!!

Yeah, I'm having same problem, So I up voted, They Need to give people the option to play part 2 without needing part 1 completed.

Okay for those who missed this see my Post here http://feedback.arma3.com/view.php?id=17050

in mission 13 maxwell in game,Just hit left shift nunpad - type endgame. And that shall let you move on to the new campaign. Lose the last mission but w.e. hope that helps

yea right this was reported about a month ago. They cant even fix a campaign before releasing a new one, i want to throw this game out my window right about now. Such a disappointment from flashpoint!

same as 16722

a lot of people with this problem...
there is someone working on this?

Or i mean end mission sorry haha

Hey just an update. Today Adapt came out, and I cant even play it because WHEN THEY RELEASED THE NEW CAMPAIGN THEY WERE TO STUPID TO FIX THIS PROBLEM! NOW I CANT PLAY. At least they fixed multiplayer.

same as issue 0016602

      0016682
      0016691
      0016678
maybe 0016658
      0016621

Exact same issue as reported above. Please fix this.

I have this same problem. I can hear rain falling and sometimes it will fade away then come back. Like the guy above I began to rapidly tap the space bar, and I began to hear footsteps, and then they stopped, but still a black screen. Please fix this it make the campaign suck.

It is possible to get in the game from the black screen if I hit space multiple times in the loading screen but it causes the AI to freeze when I get in the game.

I'm going to have to bump this one, as I don't want to put a duplicate ticket on the subject.

Why wasn't it fixed with the lovely sound update we got with Marksmen? Explosive charge sounds is kinda ridiculous and spoils many stealthy demolition ops in pvp.

Upvoted. I have the same issue. It KILLS the campaign. It's not *just* a bug.

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

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

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

Related to issue #8938

Edited, since rogerx very eloquently pointed out that this ticket addresses a different issue. ;)

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

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

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

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

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

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

I think the real issue is the terrible localization of this and other sounds. Hearing someone place an explosive or reload their rifle from 500 meters (or more) away is just terrible. As this issue has carried over from Arma 2, I don't expect it to be fixed, but ... it really needs to be fixed.

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

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

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

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

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

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

The Red Triangle, is good enough, for "Balancing", but the beeping has to go. If a friendly is dumb enough to step on a marked mine than, well, they kinda deserve to die for it.

Except there's not red triangle on higher difficulties.

That doesn't justify the beeping.

The beeping has probably been put there for game balancing, at the expense of realism. Why would anyone make a bomb that emits loud beeping sounds? That belongs in Battlefield 4 and not ArmA 3.

I don't like it and it should be removed.

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

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

"i do believe BIS already disabled friendly fire one mines"

When?

So your saying in real life, they have beeping sounds in new SEAL teams groups so they all know when someone is planting a bomb... Ok look, i get where your coming from, but that is why there are kick and ban options in "Multiplayer", just for hacking or any other annoyance you'd find unacceptable. But this is in General, and not every server has 12 years olds that don't know how to use a satchiel, or hell, any other explosive. But the Beeping must go. As Gutsnav stated, clear example. Another was when i was watching two enemies in wasteland, and to mess with them, i placed down a satchiel. Guess what happened. They both INSTANTLY looked my way, and started running, in an attempt to kill me before i got safe enough distance away to set it off. Its game breaking. But since theres no beeping sound in real life, there should not be in game. As for the red triangles, i'm pretty sure in real life, radio protocol, someones gonna mark a placed mine on map, and someone will make sure no one walks over it. Besides, i do believe BIS already disabled friendly fire one mines.(Which i think is dumb, because in real life, if you step on a mine whether a friendly placed it or not... your dead.)

Rogerx, actually it is quite annoying when you are trying to do a little combat engineering in a PVP mission. Say for example there's a crap load of enemy infantry in a bunker tower. Alpha One and Two keeps them suppressed and throws smoke and the like. Alpha Three flanks left through the trees and sneaks up on the tower. They plant a few satchels at the base, but because of the insanely loud beeping noise the enemy knows that they are going to get blown to kibbles if those satchels go off. So they just run out of their bunker, shoot the engineer and his fire team, and disable the explosives. This isn't the only scenario where this is annoying, but it's just an example.

I don't think the beeping should exist at all.

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

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

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

Beeping needs to go, period. Yes, special forces do risky things like placing charges really close to enemy presence. It's not going to beep, because well, that should be obvious.

Only if they have no AT (guerilla fighters), but this is extremely rare. You usually won't be able to pull this off without blowing yourself up (unless you want to, which is really dumb). But still, the beeping should not be louder than a cell phone or watch alarm.

Do people actually run up to tanks and place charges next to them in real life?

What do you mean? :) Explain please? Does it already work??

We need dxdiag and files from this folder for solve your problem. C:\Users\<Name>\AppData\Local\Arma 3\
Can you upload somewhere in winrar package please?
When package will be smaller than 2,097k, so you can attach here. When package will be bigger, please use some free sharing service and post link here. Thank you.

http://feedback.arma3.com/how-to-user.html.html

Write time in the mark description :)

I thought it was in all multiplayer missions, but now I have played a couple where the ambient sounds *do* work, so no, can't reproduce in all of them.

Can you reproduce this in any multiplayer mission or just in SaMatra's Wasteland?

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

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

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

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

Click create a new profile and save if you want.

You need to Invert the Yaw axis here a example how to change:
http://teamspeak.fankservercdn.com/Arma%203/invert.PNG

does this solve this issue?

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

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

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

I don't think you have TrackIR centered properly.

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

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

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

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

I center my TrackIR every time I start up a new session.

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

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

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

No matter how this is fixed, the current delay when landing needs to be addressed. It is possible for paratroops to land on their feet so it should be in Arma. Voted up

I agree that there should be a new animation for landing a parachute but, like Humay said, not in the way your suggesting.

All military parachutists are taught to PLF (Parachute Landing Fall) when they hit the ground, because they will be carrying 30Kg+ of kit and your going to be falling at a faster rate than a normal civvy parachutist, so to attempt a running landing to stay on your feet would more than likely end in a broken ankle/leg.

All your kit including your weapon (which will likly not be made ready and may not even be loaded when you jump) is strapped tight to your body to prevent it flapping about and chinning you mid jump.

So basically when you do hit the ground not only will you be on your arse, but youl still be attached to the chute and your weapon wont be immediately ready to fire.

The current system, however naff looking atm, is in my opinion far preferable and more realistic than landing on your feet and instantly being able to fight.

All im asking is give control back to the player apon landing, not have to sit there and wait for a 5-6sec animation to finish.
Also note that parachuting, is not accurately portrayed based on what you guys with experience have explained.

there are 3 ways to land with a parachute:

The soft way:

You can land running away and take the parachute off on the run without having to be prone

The hard way:

Like most of the paratroopers, they have somewhat heavy parachutes, so when they land they usually fall. I have seen people break legs and knees because of this

The fast way:

you are going so fast that it might be dangerous, and its better to cut the chute off and fall in a very painful way, usually a frontroll helps.

Then again, in real life paratroopers land so far that they cant be spotted from the sky (think about at least 3-4 km in average conditions)

and not in the middle of the battle.

Im not saying fight with a parachute on your back, you dont have one anymore after you land, all im interested in is the part where when you do land that you do a belly flop and then all this extra stuff before you gain control of your character again.

At least lets cut out animations after you land so that we can be ready to fight and have control of the character right away, I'm mostly saying the belly flop is unrealistic, no one does that, not the way portrayed ingame, its a waste of time and unnecessary "extra" stuff you have to watch your character do before actually fighting.

The whole objective with halo and parachuting is to get to an inaccessible area of the battle that you normally wouldn't be able to do other wise, but if you are engaged as soon as you land you cant do anything til your character is done laying on his stomach and then standing there like everything is ok, again its unneeded and wastes time and not realistic.

As for alternative functions and or features as you suggested if you want real realism then someone can make that, personally i dont care, i just want after I land to not have to sit there an watch my character do all this useless stuff, as said i have no control over my character once I land til the animation ends, if we can cut that part out then we can begin to look at other things.