machineabuse

What 7th_Serf is trying to say is that compared to real life shooting the sway feels nothing like it, which is an opinion I concur with. Fun fact; in reality you don't see the rise and fall of your sights with breathing unless you are prone or have your weapon steadied on something. What you do see is the sights jittering on target because of involuntary muscle movement and that looks very much like how ArmA 2 did fatigue related aiming interference.

What I really find annoying is how 3D scopes move independently from the PoV. In reality my face would be pressed down on the stock in a tight cheekweld to use a magnified optic. In A3 the scope is moving about like it has a life of it's own. This results in my mouse inputs moving the PoV in order to try and line up a drifting reticule on a static environment. With TrackIR, the natural tendency is to try and stabilize one's head movement to the environment. So in the end the player ends up juggling alignment of anywhere between 3 and 4 planes of movement which is infuriating. I can see why some TrackIR users would call it nauseating even if I don't personally suffer any ill effects other than annoyance. Our group has been staging a proliferation of head tracking devices and our two newest Freetrack users both report the hardest part of learning headtracking is the small arms sway behavior. In my opinion the sway behavior should move in lockstep with the PoV when looking through 3D scopes. Also head tracking should be locked while looking through 3D scopes (that has been on the issue Tracker since the inception of 3D scopes and it's still an annoying issue.).

Awesome mod! :) Our group is looking forward to things getting more stable but we are all looking forward to being able to use this as status quo!

Please do rapid target to target transitions from standing and prone with iron sights with expert supervision with a variety of weapons. Also if possible moving target drills. And for the love of ArmA take notes on how to improve the sway behavior :)

A schizm between deadzone and non-deadzone users can only be a bad one.

BlackPixxel pretty much summed up the solution I would suggest as well (albiet more clearly than I could have managed :)). In fairness I still think the "camera trick" method is pretty ingenious in it's efficiency and shouldn't be thrown out the window, it does however need to have the math moved around to provide a more reasonable facsimile of how target acquisition is supposed to work. Animations are expensive in money, time and hardware overhead. @Chortles: I actually despise turn rate caps myself. that can stay dead. The part of the BI OPREP I didn't agree with was the dismissal of weapon lagging. That seemed a little like trying to sidestep the discussion of what is arguable just as good if not better a system of representing weapon inertia than sight misalignment. I concede however think that execution is more difficult as it can easily give the end user an impression of latency. Which is a thing we most certainly don't need more of :cool: Right now as it stands the way iron sights squirm around even when slowly and smoothly turning bears no resemblance to reality. The very least that should be done is to make this system work on a curve with a dead zone for the lower mouse velocities so that you can at least track a running man with zero misalignment. There should also be differentiation for weapon inertia between moving and staying still. Also also wik; pistols exhibiting LESS sight misalignment than RIFLES? What planet is this? :D

The real issue here is the artificial implementation of the system grossly misrepresents some aspects of how real weapons are employed. Look at open class 3 gun rifles built for speed and rapid target transition and you will notice that they are mostly long rifle length AR-15s. Again, some of the most agile guns you can shoot are heavy skeet shotguns. "Difficult" and "real" are not directly related mathematically in simulation. If something is authentic in difficulty it should be "difficult" in analogy to how accomplishing the real task is difficult and the way the difficulty is overcome should likewise be analogous to how (in this case) one trains, practices and improves in reality. In reality; if you've trained to track moving targets the front and rear sights stay in alignment. The Weapon Inertia system offers no affordance in this regard. When proned out and properly settled on a rifle with maximal ground contact, a rifle's sway on the target is largely vertical with no horizontal movement. The sway system movement makes no consideration in that regard. A3 also still has the weird behavior where as long as you keep the mouse moving, sway doesn't kick in. It only kicks in AFTER the mouse stops moving. Which is a behavior both bizarre and also makes the easiest exploit to hit something is to keep spamming in semi while sweeping your sights over the target in small motions. As I mentioned previously, I'm not saying that the way these systems are implemented can't work. I am however saying that the way they function at current leaves a lot to be desired in terms of authenticity. ;)

@Chairborne: Solid man :) for reference can you round up the TS Codec you mentioned you are using and your TS versions of the TS server and client?

:cool:

Is this necessary? On average I can tell you that most of our members normally use +12db on master in addition to per-user volume management on TS3. As I mentioned before, if ACRE2 is discarding user's volume settings from Teamspeak that makes it hard for everyone...

I for one have been waiting for manual engine controls for a very long time. In addition to being a useful training aid it is also handy for resolving tail rotor loss via autorotation.

I ought to clarify that in our case when using direct voice the volume of speech is low but the distance at which this low volume speech is audible is pretty far. We can hear people somewhere between 50-100 meters away which is quite odd. We're using the Opus Codec but not sure of the version.

Set to automatic. Will attempt directsound tonight :) Will ask the TS admin about our codec later.

The TS server we use is also Version 3.0.10.3 but on Windows. Our members are running 3.0.16 clientside.

Sjaba: to get you up to speed, the cause of the issue is yet unknown. Mod author NouberNou is unable to replicate the issue on his end and those of us who are effected are hypothesizing the cause. Nouber, I gotta ask; the volume of ACRE2's direct and radio speech in game should be inheriting volumes from Teamspeak right? Because on my end changing the volume on Teamspeak up or down has no effect on the volume of ACRE2.

My group too has universally low direct voice volume. Most of us are running hardware analog volume controls with windows volume maxed out. We all have observed that altering the Teamspeak volume has no effect on the volume of direct speech either up or down. Radio transmission volume works fine though. Clearly with the number of reports coming in it doesn't seem to be an isolated cases. It would also seem to be a problem afflicting whole communities in a binary fashion, either everyone has it or not. Which leads me to ask if it could possibly be a problem with the Teamspeak server itself? A version mismatch perhaps?

The mud, dust and other goggle effects are really nice but what the goggles module lacks is clear ballistic glasses. Mechanically, none of the environments in ArmA 3 are presented in a way bright enough that you would ever require shades to see better. Objectively, aside from the protection they offer against muzzle blast and airborne dirt the goggles module only makes seeing the world harder; arguably not what most people wear glasses/shades/eyepro for in reality :) Again; clear ballistic glasses.

If it is a feature it would be nice to know if it is definitively. Proper comms protocol would be nice but currently impossible due to the current issues with direct voice being too low volume. Our group has also found that ACRE2 seems to override TS3's volume settings wholesale. Is this the intended behavior? Our group has quite a wide variation of microphone equipment that require per-user volume scale adjustments to ensure that everyone is audible. If ACRE2 is discarding our settings that complicates matters further.

Our group has encountered what appears to be a bug where the radio will occasionally beep multiple times in rapid succession (seemingly 4) if 2 or more individuals try to transmit at the same time. The sender will not hear it and but some receivers will hear it (as in not every listener will experience it for a given occurrence). Teamspeak issue?

Thanks for the latest release! :) Stability issues seem to be fixed. The volume of radio and direct are very soft in comparison to the overall game volume. We have the ingame volumes turned down to about 5% and direct voice is still barely audible. Direct Voice is also way too quiet at point blank. If the volume is turned up to make direct voice a natural speech volume, then radio becomes eardrum-bustingly loud. I would suggest using the volumes of A2 ACRE as the benchmark. That had it perfect!

Don't mistake me, neither I nor anyone else in the thread at any point asked for any changes to the FDM to suit keyboard players. What I asked for specifically were tweaks to the interface handling so that key presses do not result in instantaneous 100% antitorque and collective inputs. Because these changes happen on the interface end and not the FDM end, this has no effect howsoever on the analog experience while being considerate of players for whatever reason do not use analog input. Simply put; there is no reason to be opposed to this inclusivity aside from BI's internal time constraints and that is for them to worry about :) Not that it matters, I have a HOTAS albiet an ancient one. I just see no reason that a keyboard and mouse can't be used within the scope of this flight model given a minimum of attention. A *little* more than :)

The latest update has made the FDM keyboard flyable again. No spontaneous rotor ejection observed anymore! :cool:

I like the intent. I think you may have a misconception that one can't see far with an NVG which isn't really the case. It isn't that you can't see objects that are far away, it's more that you would have trouble discriminating what they are. Think of it like seeing a low resolution picture of a distant mountain; You'd still see the mountain in the distance but the trees on it become a mess. With this solution you lose the whole mountain :) There are a few ballpark figures at the bottom of this page that should give you an idea.

To cut a long, unnecessary discussion short; this. Considerations for keyboard input and "dumbing down" are two different things. If doing nothing more than pressing two keys for a second causes the main rotor to break I'm inclined to say there's something wrong flight yoke or no.

No offence, but I'm inclined to disagree that the sole intention of the Advanced FDM is to create an elitist society of players who own HOTAS. I am giving feedback based on that assumption.