flightace37

@ErichVon: I'm running a full +20 in-game curvature on all of the relevant CH axes, except throttle of course. Zero deadzone. (Only use deadzone to work around bad centering behavior). You could use that figure as a starting point if you want, and then adjust it to your liking.

That's the one. I guess it's public domain now. Cool.

I'd go with more than 25% fuel or you'll have to relearn how to fight with a heavier load. Try 50%, which will leave the aux tank empty as it should be in combat, and drain a little bit out of the main fuel tanks. Give the AI max fuel, and that should give you a good performance difference to work with. The real trick is simply not pulling on the pole so hard. The P-51 likes to stay above 200 mph wherever and whenever possible. When you get it slow (below about 180), you start losing a LOT of turn performance. Fly geometry rather than muscle, and look around for the pdf book "In Pursuit" on Google. It's freely available, and a great resource for the budding combat pilot. Further reading would be "Fighter Combat: Tactics and Maneuvering" by Robert L. Shaw, which you can buy on Amazon, or in a bookstore. Be warned though; it's very technical. When I mentioned that 200 mph figure, don't let it restrict you from going slower over the top of a loop. That's normal behavior. Also pay attention to trim and smoothness of control, as well as maintaining coordinated flight. All are critical in minimizing energy losses in combat.

Oh cool. That'll save me some stress and effort.

@Griffin: You're right. The DCS manual only has maximum limit charts. The P-51 operator's handbook has what you're looking for, but I'm not yet sure if I can redistribute it or recreate the content.

The DCS manual has information about arming and firing the various weapons. For rockets, you need to set the RX mode selector to either single or auto.

@MemphisBelle: It seems I've been tapped to write my squad's DCS Mustang checklist, so I'll get that done along the line, then see about making it available to the general population. I could include a quick-start checklist that folks could use if they don't want to look at the long version, but my squad is focused on realism, so our full checklist will be as detailed as the real thing.

Nono. The charts are in the manual. The combat tips are not. The charts are also posted on a plaque on the right cockpit wall. Other limitation charts are posted elsewhere around the cockpit.

Hmm. My quick and dirty startup checklist: === Pre-Start === Flight Controls: CHECK Parking Brake: SET Stick Lock: NEUTRAL Fuselage Fuel Gauge (Shoulder): CHECK Left Fuel Gauge (Floor): CHECK Right Fuel gauge (Floor): CHECK Flaps: UP Carburetor Ram Air Control: FORWARD unless filter required Carburetor Hot Air Control: FORWARD unless hot air required Rudder Trim: 6* RIGHT/As Desired Elevator Trim: 2* NOSE HEAVY (4* with tanks) Aileron Trim: 0*/As Desired Landing Gear Handle: DOWN **Do not raise gear on ground** Mixture: IDLE CUT-OFF Propeller Control: FORWARD Throttle: 1 Inch OPEN Gunsight Gyro Power: ON Gunsight Mode: As Desired Gunsight Brightness: As Desired Weapon Selector Switch: SAFE Bomb Arm Switches: OFF Gun/Camera Switch: OFF Altimeter: SET Directional Gyro: UNCAGE Flight Indicator: UNCAGE Supercharger: AUTOMATIC Fuel Booster: ON Ignition: BOTH Fuel Shutoff Valve: ON Fuel Tank Selector: LEFT WING Battery: ON Generator: ON Position Lights: ON/CHECK Cockpit Lights: CHECK/As Desired Signal Lights: As Desired Landing Gear Lamp: TEST Supercharger Lamp: TEST Oxygen Gauge: 400 PSI Radiator Cooler: TEST/AUTOMATIC Oil Cooler: TEST/AUTOMATIC == Start-Up == Prime Engine: 3-4s if cold, 1s if hot Starter Switch: START (Hold) Mixture: RUN (When engine catches) Oil Pressure: 50 PSI within 30 seconds Warm-Up Idle: 1200-1300 RPM to 40*C oil temp, steady pressure Suction Gauge: CHECK 3.75"-4.25" Engine Instruments: CHECK Idle: ~1000 RPM If engine cuts out, set mixture to IDLE CUT-OFF. Re-prime 1s for restart. Starter is good for 4 attempts before 5 minute cool-down. (Check me on this!) == Engine Stop == Prop Control: FULL FORWARD Idle: 1500 RPM Fuel Booster: OFF Mixture: IDLE CUT-OFF Throttle: Open below 700 RPM Ignition: OFF Electrical Switches: OFF Stick Lock: NEUTRAL Carburetor Ram Air: AFT That's the detailed list after comparing my own experiences with the user manual and startup tutorial. If you want a pdf version, go ahead and make one. I probably won't get around to it for a while.

Mmmph. That's a really good way to do that. It gets rid of the color and edge problems associated with dots and stick figures. I second! Just make sure that sizing is realistic once the object would normally be a 5x5 or so pixel square. Although to be honest... Averaging the target color and then representing it as a dot would probably provide much better performance, which is a big concern. You could use this method at longer ranges, then do a size exaggeration up to the point of a 5 pixel square, then go normal render. The pitfall to avoid is having it go from dot to render, where the render is more difficult to see than the dot at the switching distance. You'd have to take the variable-zoom feature into account when designing this thing...

No problem. Some of this stuff isn't in the manual. You pick it up from experience and good instruction over time.

You'll probably get a more definitive answer from ED, but it should be how far out terrain information is preloaded from disk and cached in RAM. Lower values should result in smaller, more frequent loads. Higher values result in larger, less frequent loads. The optimum value for your system will depend mostly on disk read performance and RAM speed/quantity. I'm unsure as to whether or not preloading is conducted in a background thread. I have the radius maxed out on my system and it seems to do fine. (16GB RAM, i7-3930K). Of course, I don't work with or at ED, so I don't know for certain, but that is what makes the most sense to me, from a software engineering perspective.

Congratulations on a great patch, ED! Ground handling is much improved over the initial beta and I'd say that piece is actually ready for prime time. I had no issues in keeping runway centerline with the full rocket + heavy fuel load I had complaints about earlier on, save a little yawing because I need to practice. It's absolutely controllable, with just enough bite to give complete newcomers a little difficulty. Free caster behavior seems to have improved quite a bit, and the doughnuts seem to have been thrown back in the deep fryer where they belong. I'm now able to engage and disengage the free caster quite easily, with only the first bit of wheel misalignment to overcome when returning to locked mode. You do have to apply opposite brake to stop the rotation, but that is expected. Behavior in the air seems to have improved as well, with the little bit of instability that the aircraft should experience as per RL reports. We still can't get the trim quite where we want it though. It's either too little or too much, but I'm sure you'll iron that out as time goes on. As per the patch info, the tire LOD problem is fixed. Lighting also seems to be fixed. Both position lights and signal lamps all work when zoomed in now. I would ask that you inspect the rocket FMs. They seem to still have quite a bit of drop. I don't have any proof as to whether or not that's correct though. I guess it's time to break out some HVAR youtube videos. Thanks!

Not necessarily. You use different RPMs for different flight conditions. Running 3000 RPM above 300 mph actually produces worse performance than say 2700. Test it out; you'll achieve higher speeds in straight and level flight if you reduce the rpms, up to a point. If you're in a dogfight, generally run max RPM as you start a hard climb, and reduce it again as you pick up speed in a dive. You'll eek a little more performance out of the engine that way. Keep in mind that the max continuous power setting is 2700 rpm with 46" of mercury. They'll eventually add engine degradation as a result of running high power for too long, so get used to using 3000 RPM + max throttle only in limited situations, and only for a limited time. The specific limits should be in the manual.

Use the neutral position lock at all times on the ground, unless you absolutely need the tail wheel to free caster. The exception of course is takeoff and landing when you need full stick control. The neutral lock holds the stick "back" for you, thus locking the tail wheel. The forward one locks the stick forward for you, allowing it to free caster and generally make a mess of things. Left clicking the lock lug moves it to the forward position. Right clicking it moves it to the backward position. Doing the same click again from either position appropriately releases the lock. Understanding how stick position affects the tail wheel is the most important aspect of the ground handling of this aircraft.

I think the trim problem is more an issue of trim accuracy and speed of trim. Perhaps an auto-trim button that we can hold down to cause the "virtual pilot" to trim to maintain existing flight conditions over a period of several seconds would do the trick. I don't think that could really be considered a cheat, but ED could put it under the "cheats" control section if necessary. It would be far more accurate than dialing in everything by hand using the digital controls, and faster to boot. As far as implementation goes, use a "spring" system, where the rate of change is proportional to the offset from the correct trim setting, with an upper bound. When the trim is within epsilon of correct, then just set it to the correct position to make sure it is as precise as possible. Bahger, do you think that some of the torque behaviors are above and beyond what you would expect, given the fact that we're dealing with a much higher performance engine than is typically installed in civilian birds? Would some of the pitch stability problems you're feeling be explained away by a full auxiliary tank? I do know that the behavior improves dramatically as that tank empties and the CG moves forward to the correct position. Have you tried taking off with a full load of 10xHVAR, along with as much fuel as permitted by the gross max T/O figures? While takeoff even with a 100% fuel load is quite doable (I can do it in a straight line with no cross wind), making a successful roll with that weapon load on board has proven to be almost impossible. I wish we could get the opinion of a real P-51D pilot on the feel of the model. I do have yet to try the .2 patch, so there may be improvements there.

In mph for a 3 degree glide slope, it works out to around ground speed x 4.6 to get your feet per minute sink rate. Just take GS x 5 and take a little off, but remember that the trig is where you get those easy-peasy multipliers from. ;) Mouse's infamous by-the-seat-of-your-eyeballs method is classified. Sorry! Actually, I just fly the numbers like you're supposed to. Once you're close to on-speed and in the right kitchen sink (sink rate), you look around the nose and adjust your aiming point as necessary, using the far end of the runway as a guide once you can't see the actual threshold anymore. If you hit all the numbers exactly at the end of your base turn (speed, sink, altitude, distance), you can literally just ride them all the way to touch down, chopping power and flaring right before you reach the ground. I don't have the official numbers on hand for the P-51, other than the IAS, but we can compute the final approach altitude at 1 mile using the glide slope equation. tan(3 deg) = altitude / distance This works out to 276 ft AGL, 1 statute mile (5280 ft) from touch down. Use 300 ft for a little safety. I suspect that is the standard figure, given that the A-10C approach pattern uses 300 ft at 1 mile as well. Ivan definitely has it right that the attitude indicator (whatever it's called in WW2 terms) can be used if you define "bar width" units, but I question its utility. I've frequently had it go out of whack, after which I re-center it. Given that level is defined by the aircraft's pitch and roll at the time of centering, you won't have a true representation of your pitch after flying around for a little while. Instead of locking yourself to a specific nose angle when landing, you should be flying IAS and sink rate, which are the two components that geometrically define your glide slope. The nose will be pitched at whatever angle it needs to be to set those two figures, in combination with your throttle. Affect airspeed by adjusting pitch as necessary, and affect sink rate by adjusting power.

Use your vertical velocity indicator to obtain sink rate, and IAS to approximate ground speed. From there it's trig, but I would just do it using the seat-of-your-eyeballs method. If you really want to do it by the numbers, at 125 mph GS you're looking at 576 ft/min sink rate to maintain a 3 degree glide-slope. Equation: tan(3 deg) = sink rate / speed Make sure to convert from mph to ft/min. As for knowing proper nose angle for landing, remember what it looks like prior to take off. You want to touch down (after flare) at the same nose angle.

Throttle controls manifold pressure. The RPM control sets the RPM that the governor tries to maintain using the variable-pitch inputs to the propeller. This forms what is generally known as a constant speed propeller system. See Wiki: http://en.wikipedia.org/wiki/Constant_speed_propeller

For the record, in the track file I posted in the "show me your dogfighting skills" thread, I was able to outmaneuver the AI after starting from a lower energy state (only 200 mph at the merge) due to engine cut out at mission start, by forcing a dive to low altitude and horizontal turns to equalize energy. After some messing around in the horizontal for a while, the AI eventually took it back into the vertical, and he had a slight advantage, but I was able to neutralize it by carefully controlling my G loading at the bottom and at the top of the loop. Namely, relax G as you come around the initial 45 degree pull-up from the dive, allowing speed to build by wing unloading, which the AI does not seem to know how to do. Do the same over the top, rather than trying to yank the nose down on him. The effect is basically flying lag pursuit on the bandit while carrying a little more speed. You eventually win enough energy for your guns to cover him from time to time. This is from Wags' 1v1 mission, with the AI set on High. I haven't checked the fuel states. The point is, it is possible to beat them, although I do agree they have an incredible ability to hold energy. If their ammo weight isn't modeled correctly, that definitely explains it, but you don't need equal conditions to win. Fly to conserve energy, and gain it whenever and however you can. If you are losing or have already lost position, don't be afraid to make a drastic change to re-equalize the situation. Also, locking your prop lever at 3000 rpm isn't always the best thing to do. If your IAS is high, you'll get better acceleration and efficiency in a fast dive by reducing prop speed. Go to 3000 as you start to climb, reduce to 2700 (or whatever is appropriate) as you come well into a dive. There are other techniques to help you in the vertical as well, especially going out of plane. You can't tip back towards the horizontal because then you're just giving the AI free energy, but you CAN go out of plane in a different way. Imagine the AI's turn circle from a top-down view, and then imagine yours overlapping his. Out of plane in this case, is just rotating your turn circle around the vertical axis (clockwise or counter-clockwise from the top-down view). Once you're out of plane, you can vary your pull-ups and pull-downs to change the timing of your arrival at the top of the loop relative to the AI's, and you can eventually make him fly through your guns. There's lots of fun things you can do with careful examination of the geometry of the fight. Cheers!

Okay, I'm going to do my best to help clarify this. The critical text is the very last line in the quote. The K-14A is not a predictor sight, because it only relies on own-ship motion (plus range) to judge bullet trajectory. Therefor, it is a "real-time" sight, in that it shows where the bullets would be right now, if you had fired one time of flight in the past. It is "historical" in the sense that it shows the current position of bullets fired in the past. Both terms mean the same thing; you just have to think about it a little differently. The "historical"/"real-time" nature of the sight is not due to any mechanical devices inside it. It is solely because the sight is not predicting the position of the target in the future. That is the realm of "director" sights, and it requires some kind of understanding of true target motion, rather than just own-ship motion. This is achieved by a radar lock, or some other kind of tracking and ranging system, and even with that, it is not perfect. (The target can still squirm in 1 TOF). Shaw goes on to say: The advantage of the "real-time" sight (I like that term better), is that you can open fire 1 TOF before the pipper is on the target. When the pipper then touches the target, the bullets will hit the poor bugger. "Predictor" sights cannot do this, because they show you where to aim to hit the target 1 TOF in the future. (Yes, the pipper is still typically placed on the target, but it could just as easily give you an arcade-style "lead" dot to place your bore-sight on). Lastly, remember the "settling time" that Ivan mentioned. The sight has a small interval that it requires to actually move the pipper to the correct position. Ivan said this interval was 1.2xTOF. I believe that it is actually 0.2xTOF. So, for the bullets to hit the target, you actually need to have fired 1.2xTOF in the past, rather than just 1xTOF. To look at it another way: If you are waiting to open fire with a steady-state tracking solution, you have to wait 1.2xTOF for the pipper to move to match the steady-state situation before you can pull the trigger. The situation then has to be exactly the same for another 1.2xTOF until the bullets pass through the target's range at the pipper position. One last way to look at it: If you had an unlimited supply of bullets and were constantly holding down the trigger, any time the sight touched the target (less the 0.2x settling time), bullets would hit it. All assuming perfect ranging, etc. And a final anecdote: The K-14A does not have any kind of computer memory, so it cannot show you the actual position of bullets fired one TOF in the past. Instead, it takes its best guess based upon current maneuvering conditions. This is why you have to set up a steady track and wait for the sight.

The file in question is DCS World/Config/View/Labels.lua. Comment out the lines you are going to change, then re-create them without the %-escapes you don't want. You can also adjust the sides colors to be pure black. The file appears to be self-documented.

It's a limitation of resolution. Detection is easier with anti-aliasing turned off, ensuring that single-pixel-sized objects aren't blurred into the backdrop. Many WW2-era games implement a dot and stick-figure system for longer range detection of objects, but that is not present in the DCS engine as far as I know. The only way to mimic it is to configure some Lua files to show friendly/enemy aircraft with label "dots" out to a certain distance, but this is not server enforceable, so it doesn't make for fair competition. You should try to develop a scan pattern of the sky around your aircraft, using zoom functionality to help you find objects. With a 1080p monitor, you can see a P-51 from the forward quarter from 5-7 seconds away (head-on) without any zoom. That's not a lot of time. Make sure your ears are open for an engine blowing by. Higher resolutions definitely yield longer detection ranges. Also, remember the adage: "an enemy at your six o'clock is better than no enemy at all". If you heard something go by you but you can't see it, do your best to disengage, and keep an eye toward your six. You'll eventually pick him up, and can then make efforts to gain the advantage. Lastly, turn on that rear-warning radar (AN/APS-13). It will give you a bell notification and a light if something sneaks up behind you, assuming that it's modeled correctly.

@LcSummers: Sounds like you found it already, but if not: What you're looking for may actually be titled Engine RPM Increase/Decrease under the Flight Controls section of "P-51D Real". At least that's what it says on my config screen. This is definitely something you want to map to stick buttons or an axis.

I don't have any real problems landing with trim, but I also land at pretty low engine power and contact the runway on three points. It doesn't give too much kick over, and I'm able to correct it pretty easily using pedals. Landing has actually gotten to be easier than takeoff for the time being. As far as trim implementation goes, I want to suggest something that ED may or may not have considered yet. What about using a force/counter-force implementation, where the physical controller's displacement from zero is the amount of force the pilot applies against the controls, instead of actual deflection of the stick. That way, the trim tabs can have their real-life physical effect. You would obviously need a default base "spring" so that returning the physical stick to center actually returns the aircraft's flight stick to center for ground operations. With this implementation, deflection would be zero when no aerodynamic force is being applied to the flight controls with the user's physical control centered. As speed increases, the flight controls would respond by moving toward their trimmed position, all without the user having to move the physical stick. The simulated stick in the cockpit would move to the new aerodynamic center. Tail wheels like on the P-51 have a tendency to center themselves, so those forces could be added to the effects of the rudder aerodynamic return. I imagine having the tail wheel in contact with the ground would tend to override the effect of the rudder, and so the aircraft would track relatively straight, which is what we expect. It would probably be necessary to fade out the default spring as aerodynamic forces increase so that it doesn't affect flight characteristics. The user shouldn't have to trim out a non-existent spring while in flight. This can be done with an appropriate mathematical function. This all of course only applies to aircraft modeled with physical or hydraulic controls. Fly-by-wire systems would still simply send stick position to the computer. The computer however, might have to deal with trim tab effects, if that's how trim is implemented on that particular aircraft. Just trying to be helpful. I have not thought the entire thing through, so it may or may not actually work as intended.