Doombell

All I see your proposed change doing is moving the problem to another place, where it is harder to deal with. Instead of an altitude hold system that is too slow, you would get an upward acceleration system that is too slow. You could use a controller emulator like Glovepie to test out exactly the control you suggest if you want to try it, though. All you need is an axis bound to increase or decrease from your collective up/down keys bound to collective.

While we're on the topic of targeting issues, acquiring targets for the guided munitions is awful. The direct target command is WAY too accurate in aircraft, and would be more useful if it worked by the centre of your view rather than the centre of the HUD or however it works now (I honestly have enough trouble lining up targets well enough that I am still not sure if it does this). Preferably it would work in a narrow cone and lock the target closest to the centre. Just filter out things that aren't known to your group to avoid "scanning". Wouldn't hurt if it would work with the reveal target command, though. As it is now any situation with multiple targets ends up with a mad pressing of the next target button, hoping that it will get the one you want before you are so close you won't have time to lock.

I think you are vastly overestimating how desirable full control is. If any particular heli would have autopilot for collective or not is harder to say (UH-60 seems to only have the systems connected to attitude control, while the CH-47 does seem to have it.), but having this vary between aircraft would probably be very unfriendly to beginners. A bit of searching seems to suggest any newer aircraft either already have these systems, are being upgraded to them, or are even planned for upgrades to full fly-by-wire (Apparently the Comanche was supposed to be the start of these upgrades, but the cancellation delayed it. Articles were a few years old, not sure what the current state is), which would potentially have even greater degrees of assistance. The problem isn't in there being flight assistance, the problem is in either our capabilities for input (the altitude target changes too slowly), how rigid the system is (it's possible it simply doesn't let an aircraft descend beyond a certain speed) and/or the properties of the aircraft (I am not sure if the lift at zero collective is low enough, but I haven't seen any extensive tests on these things.). It is also possible that most of the values are reasonable, but clash with the lower scale of terrains in the game.

Actually, it sort of will, in an assisted system, which I think is a fair assumption of any of these modern helis. Your collective setting will simply have a range around the 60% setting that the autopilot would override to set you to for example 68% when under target altitude or 54% when over. The problem is that for keyboard control, there is ONLY the equivalent of a target altitude setting, with an actual manual input being abstracted completely. In the sort of system I describe you could (even though it would generally be considered bad flying) just set the manual collective input far enough away from the autopilot's desired range that you get something like un-assisted flight, but offset a bit by the autopilot countering with its maximum input. For this game it is just as if the autopilot has an unlimited range. For a fly-by-wire aircraft this would probably be closer to how it works, but I don't know if any helicopters use a system like that, or if you would want them to. The assisted flight method is generally a good thing for anything but harsher manoeuvres (not sure if it's worth implementing for manual inputs like joysticks in Arma scale terrains, or if that is even possible), but it could use some behaviour for severe changes, like holding ctrl+collective up/down (I think ctrl is free while in vehicles?) to simply max it out in either direction and set target altitude to where you end up when you let go. As for the comanche's snap turn ability it has been mentioned quite a lot in the tail rotor discussions, and I believe the ducted fan design is what gives it more torque authority, even at speed (I think the funny little tilt could even be to direct forward airflow or downward airflow from the main rotor through the fan, or at least part of it). A lot of people seem to think this means it can keep flying at high speed sideways though, which sounds quite unreasonable to me, and as far as I can tell has never been stated by the sources people use. I was hoping this was what those coefficient values would give better control of, since I believe all helis have a very sharp cutoff to torque right now at a certain speed.

While I agree that keyboard controls could probably use some more precision for aircraft (trying to take off in the fixed wing showcase before giving up and pluggin my joystick back in involved a lot of precision throttle tapping during taxi), it DOES approximate how a modern autopilot aided system would work. I am saying this from the limited experience of DCS Black Shark, but at least in that you set a target altitude and the autopilot simply gets a partial override of your current input to try to achieve this. A pure rotor angle input would lead to even more control input as this would likely lead to your altitude gain/loss being even more dependent on height and speed, and end up with you having to micromanage your upward acceleration. I don't suppose anyone knows what all these offset/coefficient or whatever values added to the newer revisions mean? Do they allow further configuration of the effectiveness of anti-torque or other controls between airframes or are they about how speed effects them?

Things I would like to see are: 1. Waypoint right click actions when stationary! I should not have to give it a new waypoint to give it new firing permissions or taskings! 2. More controls with dedicated buttons in the terminal: a. Separate control and turret control buttons, just put them by their respective camera. b. A toggle for the headlights of the UGV, that thing is trying to get us all killed, and last I checked Skynet was in another series. c. RoE mode switches, preferrably with different workings than regular AI. It is acceptable for an unmanned vehicle to not fire back when engaged. 3. Ability to communicate over radio while controlling one. A FLIR UAV turret is an excellent command position and right now I don't even know if I can use it to lase artillery targets since I have to release control to call in support.

Now that they are working on getting actual penetration of vehicles they might be able to make a more proper system by putting any parts that register damage inside the first physics hull that needs to be penetrated. I wouldn't mind seeing more separate damageable components (especially for aircraft), but that sounds like it might have its own complications.

That's what I meant. It is a concern that needs to be accounted for when moving so you maintain cohesion, not a problem that needs to be removed.

Speaking of which, I don't necessarily think making fatigue a bigger concern would do harm to modes like CTF. Having varying mobility, firepower and survivability seemed to make the old Tribes games (Not sure about the newer one, the maps seemed too cramped for my tastes) some of the most interesting takes on the gameplay modes around. Maybe adapting the mechanics to the mode is not the best choice?

One thing I have been thinking about concerning running and sprinting is that the basic run is more controlled, while the sprint is your absolute maximum output because some unlikeable character is trying to rob you of your basic functions. Now, I am unsure as to how much of this is already done, since I only have the subjective experience during missions rather than numbers and mechanics behind it, but the run probably should max out its fatigue below the actual maximum fatigue, with speed slowing down in a more "predictive" way (this could be complicated or it could just be a case of making the slowdown for fatigue hit sooner). If you then let sprinting cause maximum fatigue, relatively fast (Even professional athletes with nothing weighing them down can tire themselves enough to barely be able to stand in just a hundred meters or so if they do not pace themselves, after all), you could then have running at that point be considerably slower than where usual running would slow down, but it would let you get a little bit of breath back until you hit that max, though considerably slower than actually taking a rest. This to me sounds like a reasonable depiction of how one would try to move in a dangerous situation; keep the pace up (run), but save some energy for when it is definitely needed (sprint). Heavily loaded people lagging behind would be a concern, but hopefully they wouldn't be completely useless in combat unless they pushed themselves to keep up with guys running around in t-shirts with SMGs. I can see the logic behind this, but I am unsure if it's prudent to have too many stats tied to skill. It is reasonable to assume your special ops troops are going to be highly fit, but you are still going to have plenty of basic grunts carrying around the heavy stuff.

That actually looks a bit familiar... I think something like that happened if I tried to override the game's anti-aliasing through driver settings. Try making sure you have don't have the driver control panel set to anything but application controlled AA, not even any "Enhance application settings" (I only know what it says for ATI cards, so Nvidia might be called or even work differently), since that one only seems to check what AA level the game demands, then overriding it with an equivalent one with more sample points (At least that's what I've read the "#xEQ" are).

The three most important improvements to grenades compared to Arma 2 I want to see are: 1. Better control of throw power. In A2 the "charge up" seems to start immediately as the animation does, and progress very quickly with little indication of how hard a throw is. I'd rather it only start when you wind the arm back, and maybe show how hard the throw is by how far back it is. That should be quite easy to fake with just a slight zoom out, since you ordinarily wouldn't see that arm either way. 2. No strange arcing. In A2 grenades went much too high compared to your aim point, so it was often anyone's guess where they would go. Most people are probably more familiar with the practice of aiming over a target you want to throw a grenade at, so I imagine it is more intuitive. The grenade can come from over your shoulder somewhere for a regular throw, the important thing is the direction. 3. An aiming reference that does not rely on crosshairs being turned on. The simplest is the popular left hand method. You could even make it a toggle like weapon sights if the grenades are switched over to an equip type system.

One thought I had the other day when watching one of Dslyecxi's videos was for position transfers. He ran up get back in a BMP, I think it was, but found himself on the wrong side due to the turret being faced backwards. I was reminded about some things I had been reading earlier about having infantry ride along on the hull of a vehicle, and figured it could actually make sense to have that as a pre-position for any access to a top hatch, perhaps using the stance adjustment keys to go from "hull - beside turret" to "turret - commander seat", for example. It could work for vehicles like the Chinook too, with a "cargo - seated" and "cargo - ramp" type deal. Not expecting much, but it can't hurt to throw ideas out there. Maybe a mod, someday.

Yes, there is even a manoeuvre where you come in at speed to the side of the target, then point the nose toward the target, initiating sideways flight, with the downward angle of the nose making the aircraft turn in a circle around the target, keeping the nose pointed towards it through the whole thing. I think it was called a funnel turn or something. My understanding is that this would simply not be possible with a single rotor craft, though how much a role the Ka-50's "turn to target" autopilot assistance plays I can't say. As for whether a tail rotor allows faster turning at a hover than a coaxial design I can't say, I can see both tail rotor having an advantage from leverage and being dedicated entirely to the function, and co-axial simply having more surface area to work with as reasonable, so I'd have to find some comparison for that.

FaceTracknoIR has a feature like this in the works for much the same reasons as stated earlier in this thread, so a toggleable sensitivity adjustment on zoom would be very nice, leaving it as an option and keeping the possibility of avoiding a double adjustment in case someone were to use an external version of it. The zoom out on turn is not quite optimal, but a good compromise (Maybe PiP when head is turned and view zoomed out, and normal render when centered? That might be even harder to do right, though.), as long as the above is also included since you would risk some serious woodpecker jitter without it.