jaylw314

Most controls are made of either aluminum or magnesium alloys. Aluminum is light and pretty strong, but magnesium is even lighter and stronger. Not sure about the A-10 IRL, but magnesium does seem to be preferred in aircraft controls for whatever reason--maybe tradition, maybe to reduce the inertia of the controls, maybe because magnesium is a little more corrosion resistant to sweaty hands?

The "on board computer" (I assume you're referring to the EGI) and even a student pilot would have the ability to figure out the wind strength and direction by comparing the aircraft's ground speed (using, say a GPS or landmarks) against the measured direction and speed (using the airspeed indicator and compass). That's precisely how you figure out what the wind is doing. To imply that information is not available to the aircraft is incorrect. Whether the RL aircraft or DCS aircraft do that, I can't confirm, but my 90's era aviation GPS does.

IIRC, one advantage of the WCMD is the ability to drop from high altitude (10,000' and up). Without INS, CCRP would be too inaccurate and CCIP would be impossible or impractical. Also consider the ability to drop it through clouds. Probably not politically correct, but still an option...

The behavior in-game is that of TV image tracking problems, not a gimbal limit. POINT and AREA modes supposedly track the target, not by the targets known position, but by moving the camera to track an area on the TV image by contrast and shape. Video tracking modes only seem to work at certain angles--you can see in other areas when they turn into P-INR and A-INR, the video tracking is presumably off temporarily and turned back on when the camera is in a better angle. The area in question is about 10 degrees wide about 20 degrees down from the boresight cross. If the camera passes through there, the video tracking algorithms fail for whatever reason. Unlike to the side and rear, the TGP does not revert to INR mode, again, for whatever reason. Whether this happens in real life, I have never heard any substantial information to confirm it does or does not. If it DOES, I would suspect it's a failure in the video tracking algorithm near the camera's longitudinal axis. The algorithm probably tracks the image with simple up/down/left/right commands, but as you get closer to that axis, the left/right commands become less and less accurate, since they tend to spin the camera more than translate left and right. At some point, the algorithm commands full scale left/right commands and can't keep up, and it gives up in petulance. This could be avoided by reverting to automatically reverting to INR mode like in other areas, of course. Of course, that's all speculation on my part, but I'm still hoping we'll someday hear someone with RL experience corroborate any of this

The CBU 97 has the advantage of being able to pair/ripple drop them for maximum CPU-melting chaos

Scorpion also has pretty colors

I suspect the problem is inherent to the 2.7 clouds, so without killing the clouds there's not an easy workaround

Wait, how do you take control from a track file???

Or really any extra two buttons on your HOTAS

That actually sounds normal. About 30 seconds after landing, the A-10C EGI does some housekeeping--I think it downloads flight and engine management data to the DTC among other things. During this time, the EGI alignment is reset, and you get the NO SPI warning. I don't recall what sets off the reset, IIRC it might have been weight on wheels. After a few seconds, the EGI does a warm start and is back up and running.

Make sure the appropriate sensor is SPI. If the SPI is still STPT, they will target the steerpoint instead of TGP The LASTE shouldn't affect JDAMs, they have their own GPS and will aim for the point on the ground. proper LASTE setup might give you a more accurate max range display by a little bit, though, since throwing the bombs with some wind correction saves them a small amount of energy during guidance.

Kind of OT, but one suggestion is to turn OFF PAC-1 when attacking moving on-road convoys with guns. That way, if you line up on the road, you can pull the pipper up through the whole convoy while firing and nail several vehicles before they scatter

When did you create markpoint A? I've found that creating waypoints (or markpoints) prior to full EGI alignment produces waypoints with the error "NO SPI". It should not, however, affect waypoints (or markpoints) created after the EGI is fully aligned.

Dangit, you're right, that's not what you were looking for, sorry

IIRC, under the IFFCC TEST menu, there's an option to allow the gun reticle to occlude (default) or not the other HUD symbology. I've never changed it, though

I just stand on the brakes during a cold start. You don't want the plane rolling during EGI startup

It looks like you're zoomed too far in on the TGP: Image 1 - zoomed out all the way, the dotted box shows TGP FOV Image 2 & 3 - zoomed in all the way, the dotted box has collapsed on the diamond so it's no longer visible. The TGP FOV is about a runway width, which would be appropriate. Image 4 - Can't explain. TGP is still looking at green diamond (with green square collapsed on it because it's zoomed in). It is NOT looking at the markpoint--the SPI is on the markpoint, suggesting either your SPI is STPT, or HMCS is SOI + SPI and you just made a markpoint Image 5 - Can't explain. If HMCS is SOI, TMS right short should make a markpoint at the HDC, not the TGP diamond. Suspect TGP is actually SOI Didn't this thing about not seeing the TGP FOV because it's zoomed in too far come up before? Also realize, if you're zoomed in all the way, if TGP is SOI and you try to slew, the diamond moves VERY slowly in the HMCS and HUD. Zoom out and you'll see it slew faster One other gotcha--DMS right long ALWAYS slaves the TGP to the HMCS EXCEPT when MAV is SOI. It attempts to slave the MAV seeker to HMCS if possible, but does not slave the TGP.

I'd also add that while you're figuring out presets and other functions, it's a good idea to be in a multiplayer server and have SRS running with an overlay. That way you can get immediate feedback as to what you're doing, such as what frequency you're on, whether you're listening to guard, etc.

Nope, no keybind is available yet for the HMCS switch on the right console, although DMS Left Long does turn off the HMCS display and practically has the same function (except on a cold start, of course). No word that I've heard so far as to whether there is any plan to add such a keybind

AFAIK the RL implementation is left eye only. I suspect the main reason was simplicity and cost, although it also keeps the HMCS display from obstructing both eyes.

Syria has some ramps with a pretty noticeable slope (Ramat David for one has a whole runway that's tilted. Add a little idle thrust and you can get rolling accidentally.

Dropped GBU-54's last night, and they worked--okay. Looks like they're going long at first, then they drop vertically over the target. One with laser on, one with laser off. FWIW, I designated the target with the TGP by making it SPI. You don't have to enter location on the CDU, just make it SPI.

My impression is that the GIMBAL ROLL warning has more to do with how fast and how far you've changed heading and bank, presumably, when the longitudinal gimbal is reaching its limit. It does seem when it hits this limit and loses track, it sometimes comes back to the original target. The deadzone problem is due to the lateral gimbal not quite being able to elevate to 90 degrees, so when it hits that limit, the longitudinal gimbal goes crazy trying to track it. AFAIK, there's no warning for this, you just lose your track and it never comes back.

I think OP is talking about the TGP dead zone on the nose. ED claims this is realistic, but I've yet to hear anyone in the know in RL pipe up and confirm this. A simple workaround is to use INR (ground stablized mode) for the TGP, and only use POINT or AREA tracking when needed. POINT/AREA tracking try to stabilize the TGP based on what it sees in the video image, so when the camera hits the deadzone, the tracking goes haywire. Why it wouldn't revert to P-INR or A-INR like it does when the spot is to the rear is beyond me. Having the TGP in INR seems to prevent this from happening, since it's locked to a point on the ground.

I couldn't find this mentioned after doing a quick search. All the entries for China Hat switch FWD short are shifted over to the right one column: "Toggle FOV" should be under "TAD", and each entry moved to the left one space