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.

Would you care to elaborate a bit on this? A quick search has people agreeing with the lift part, but I am having trouble finding sources either way about agility, except some short statements in RC heli sales descriptions. Most of the things I read seem to lean toward co-axial being more agile at the same weight range, whereas more agile single rotor aircraft are simply lighter. What exactly are we discussing when we say agility? It seems co-axial craft have greater stability and rudder authority at speed, but single have speed ceiling advantage with rotor clashing happening earlier than retreating blade stall. Is this mainly a weight thing, or am I not considering some properties?

This I agree with. Even though the angular change is the same, the effect is drastically increased when zoomed, so a possible solution to both problems would be to simply divide the angular change for these kinds of scopes. I can see why you would rather avoid the PiP method, as that could make proper optics dependant on PC performance, if I understand the PiP settings right. I really like those 3D scopes and it's a shame some people evidently aren't happy with them yet.

I don't see why the only solution people give for handling heavy weapons is limiting turn rate. Add sway from moving, and make lighter weapons recover stability faster! This way pistols are an excellent choice in tight buildings, since you have that ability to whip around and fire accurately. Carbines and SMGs possibly even better, more fire, better penetration, heavier weapon with centre of mass closer to your chest and supported against your body, so less drastic recoil on firing while still reasonably easy to stabilize. Bullpup? Centre of mass further back, even better stability, but a bit more recoil on firing! Long rifles and machineguns? Probably don't want to whip that thing around unless putting fire in the general direction of something sorta over there is good enough. As for the developers staying quiet, I can sympathize. As soon as they say anything someone seems to pop out of the bushes and look at it really hard until they find a way of making it sound like they are admitting to communally kicking puppies in the break room.

If I remember the developer commentary mode the whole initial scene in Portal 2 used Source's pre-baked physics capability and the bits that affected the player just used cleverly timed camera jostling, though. While I would like to see the feature I am more interested on seeing it applied to boat decks. The only real part I could see it be very useful in aircraft could be filled by a new "ramp position" slot or something in preparation for parachuting.

I don't really like the idea of limiting turn speed, because you simply have much freer control of the weapon than you do in a turret. If someone is holding a relatively heavy weapon and they need to fire behind themselves, they wouldn't hold the weapon out from their body as when aiming and slowly swing it in an arc around themselves, they would more likely point it up and bring the centre of gravity as close to their body as they could, turn around and lower it. Now this would be hard to really do in the game, so the facing of the camera is generally best left as the intended direction rather than true direction, and other things let handle the fact that you are jostling a big weapon around. I would give all weapons a base accuracy (how easy it is to keep it stable in one direction), a penalty for movement (how much its weight and inertia make it want to keep going after fast movement, and the strain of countering forces on it), and a recovery time (how fast you can regain a stable and accurate aim). The last two probably overlap enough that you could just merge them. A pistol is smaller and lighter than a rifle, and has good "pointability", so while it lacks the base accuracy to be very useful at range, you can turn around and fire accurately within a very short time. It lacks in weight though, so the recoil would affect the aim drastically, but the fast recovery means it is only a big issue when firing very fast. An assault rifle has an advantage when it comes to base accuracy, as you lever it around your shoulder giving you smaller changes in direction for the same amount of hand movement and removing some of the inaccuracy from the triple lever points of your shoulder, elbow and wrist. It is also heavier, and should therefore be just a little bit more stable in its direction. This is also the part that gives it a detrimental effect when moving quickly, since it's going to take more force to return it to a proper position and direction. Recoil would affect aim less drastically at the very least because it is braced against your shoulder (unless some of the stances do otherwise, I can't recall them all right now), but since it lacks some of the freedom a pistol has it will take longer to recover and be prone to a buildup effect. Long rifles would mostly be the same changes as for an assault rifle, but greater yet again, and possibly some changes due to the center of gravity being further out from the body. It probably needs a lot of refinement, but I thought I would at least check if anyone agreed before thinking further. Another issue I noticed the other day related to animations and aiming: If I sprint and right click to bring up the sights, nothing happens. But when I stop sprinting it brings up the sights. Starting a sprint from sights also brings up the sights afterwards. The first part I do not like. It is an input having an at the time completely invisible effect that only appears afterwards. If sprinting, right clicking should do nothing and you should have to right click again when moving normally, I think. The second I am less sure about. Personally, I would like to see sprinting taking you out of sights mode entirely so you have to bring them back up after, but others might disagree with that, since things like crouching and standing feel entirely logical to look through the sights afterwards as well. This could probably be one of those things related to the "feel" of sprinting and the disagreements about what it should be. I think it is an abandonment of all other concerns for speed so it fits that you end up out of sights.

I'd like to see a hybrid approach instead. The HUD can follow the view, this can be pretty useful for staying level while you have to look to the side, but weapon crosshairs should be shown vehicle-relative at all times. Another option is also to snap the HUD to aircraft-relative position only in the forward arc, say, 20-45 degrees from the front. That would work well for missiles and rockets, but I'd still prefer that cannon and possibly lock tracking stay aircraft-relative to avoid confusion about where exactly things are.

For the TAB locking mechanism, I probably wouldn't remove it entirely, since having a simple and similar command method across vehicle types can be important. I'd rather see it turned into a narrow line of sight selection, say a circle that pops up in the center of your current view direction when held down, and the targeting box appears over valid, known targets inside the circle and stick when you release the key. Now, this might lead to some issues with "scanning", so the threshold for valid targets to lock might need to be higher than for the target menu. Hopefully this would work as decent compromise for both people with and without head tracking accessories, though some upgrades to the target menu might be in order as well to better show which direction a particular target number is relative to you, or your vehicle. The "radar" I am less certain about, since as far as I know it's not really a sensor, but a visualization of the "known" targets around you. If I am right about that the problem might be more related to aerial vehicles' excellent vision, and possible solutions could include inducing a bit more "tunnel vision" at range, and clearing out old targets faster when they are no longer in vision or replacing them with some "assumed position" type deal. Harsher friend and foe recognition might be in place. If the system works like I think friendlies would appear friendly immediately due to your side constantly transmitting things like that silently.