MagnumHB

Doing a quick bit of research shows that the current 1.5.4 implementation is simply incorrect in terms of human factors as far as I can tell. Every worthwhile diagram I could find of normal field of view/line of sight (see 1, 2, 3, 4) indicates that the normal seated line of sight is 15 degrees below horizontal. This agrees with the way the eye works as seen in this diagram depicting the line of sight angled below horizontal. Furthermore, the field of view is wider below (70-80 degrees) horizontal than it is above (50-55 degrees). The previous implementation of centering the view 27 degrees below horizontal seems to be a more valid approximation of the natural line of sight plus some fudging to account for the wider natural field of view below horizontal. Centering the line of sight at horizontal as in 1.5.4 does not seem to reflect the way line of sight actually works. It certainly does not match my experiences in light aircraft being able to both easily see outside and scan the instruments, and I doubt that it matches the A-10 either. Note that in this diagram, the 20 degree field of view below horizontal is specifically emphasized to show the view over the nose. Assuming the 15 degree natural line of sight, it is obvious that the high seating position in the A-10 is optimized to maximize view of the ground, not to have the pilot stare straight out at the top edge of the HUD.

If you had to fiddle around with the TrackIR for several minutes to get a view you were satisfied with, one that includes both the HUD and MFCDs, I don't see how you actually like the change. What you did was unfortunately waste your actual playing time with control tweaking to presumably try to get the view as close as possible to the old one. That doesn't sound like a positive experience to me.

I was just about to say something like this. I can't speak directly to the ergonomics of the A-10, but I think it's instructive that when doing instrument training in a Cessna 172 (or any other light GA aircraft) while wearing foggles, your head position doesn't change from what it normally is. Your normal field of view includes both the outside world and the instruments. The foggles simply obstruct the outside world and force you to only pay attention to the instruments without any major ergonomic changes. Another issue I have with this change is that it does, in fact, look wrong. There is noticeable perspective convergence visible in areas like the edges of the UFC that make it look like the viewpoint is at a distinct non-90 degree angle, as opposed to being reasonably perpendicular to the surface as it was before. If this is intended behavior for VR users, great. For the (I would think) overwhelming majority of us who are not, this is a bug classifiable as an unintended side effect of implementing a new feature, and should be reimplemented as a user selectable option.

Put me down for a round 6 bluefor lonewolf slot. Callsign: [DBS]Magnum Aircraft: A-10C

That's the general idea, but this of course opens up a big can of worms discussion on jets vs. props, Air Force vs. Navy, personal preference, etc. Stick and Rudder pounds that into you so you understand it deep down, but it's also important to remember that pitch, power, speed, and descent rate are all interconnected. Adjusting one may require you to adjust the other, or adjusting one may fix more than one problem at once.

Good post, you covered nearly everything that bothered me in the first 3 missions, and much more. The timing inconsistencies are even worse in mission 3 than you mentioned, with the briefing PDF saying the push/end vul times are 1607/1637 (times which are basically impossible and I assume remnants of an earlier draft) vs. the lineup card saying 1615/1651. In any case, I took off on 03R to avoid the backup at 03L, and I was still late after taxiing the required distance. I think the issue here is that the player has a few expectations while playing a campaign marketed as a highly realistic Red Flag experience. The first, as mentioned in the OP, is that the player will be held to a higher standard. This means that when the briefing says to push at a given time, the player assumes that doing otherwise will result in either some sort of outright mission failure, or getting pummeled by SAMs or fighters for not being properly in sync with the rest of the strike package. The second is that the player most likely expects a uniform level of detail throughout the mission planning. When the mission is excruciatingly detailed with ingress routes and timing (albeit currently in an inconsistent manner), it's a bit disappointing to arrive at the target area (whether that be Apex for landing in mission 1 or the actual targets in mission 3) and have things suddenly become a free-for-all. If the mission designer expects the player to do any significant improvisation from the mission as briefed, there must be some hint to the player that this is correct and not a bug or poor mission design. The most obvious ways I can think of to do this are subtle hints in the briefing, or some sort of in-game comms audio. I understand the desire to maintain some sense of chaos/fog of war, but this must be balanced with the expectations of the player to feel that they are accomplishing the mission within acceptable parameters. As it is now, I think the targets in mission 3 don't make a lot of sense since either low-level tactics (and corresponding loadout) are required to maintain terrain masking from SAMs (and be briefed accordingly), or the effectiveness of the SEAD flights should be taken into account to allow for higher altitude tactics. In any case, I felt the pacing of the mission went right out the window when I went from a participant in a tightly coordinated strike package to loitering in the target area for an extended period of time mopping up targets with a non-ideal loadout and a lack of specified detail for the egress. I will certainly be looking forward to future updates before continuing the campaign.

Just got a game crash while not doing anything particularly significant (like loading a mission, etc.) I was flying a multiplayer mission in the A-10C while looking (zoomed in) at the TGP and hit the China Hat, then the game locked up. Log/dump attached. System Specs: Win 7 i5 2500k @ 4.2 Radeon R9 390 8 GB 16 GB RAM DCS.openbeta-Crash-20160109-195202.zip

I noticed some very odd behavior from the A-10C landing light in Nevada. I spawned on the runway at Nellis, and everything appeared to be normal. However, after switching to the external view and moving the camera around, the landing light beam either becomes offset from the bulb location, appears in a completely different spot with a weird shape, or disappears altogether, depending on the camera placement. I observed this behavior at McCarran as well, although I haven't tested this in Georgia in 1.5. Track and screenshots attached. Specs: Windows 7 i5 2500k @ 4.2 Radeon R9 390 8GB 16 GB RAM nevada_a10c_landinglightglitch.trk

Seconding this. The nice thing about a map set realistically in the US is that you have free and easy access to all the charts and plates you need from places like Skyvector, Airnav, and even directly from the FAA, not to mention services like Foreflight if you have a subscription.

I'm also getting this issue, and I have an AMD Radeon 6950.

Speaking of which... It is true that wheel landings can be more challenging in some respects, but they do have some advantages that you may or may not be aware of. Primarily, the slightly higher approach speed is desirable in gusty wind conditions, and in general allows you to retain more control authority. There is a definite mushiness in the Citabria at a 3-point approach speed that is not there when coming in slightly faster for a wheel landing. Another good reason for doing wheel landings is improved visibility over the nose/down the runway. Something else to consider is that the tailwheel is relatively fragile compared to the mains, and it is generally a good idea to minimize extra stress on it, although this is less important in a sim. Of course, the key to a good wheel landing is to have an appropriate descent rate and to pop the stick forward as soon as the mains make contact with the ground to avoid a bounce. This certainly takes some practice (in the about 60 landings it took to get my endorsement, maybe only 10 or so were 3-pointers because they are generally easier), but the results are well worth it, as a properly executed wheel landing just feels much more solid and satisfying than even the best 3-pointer. All of that being said, it's worth mentioning that the best type of landing for any given situation depends heavily on factors such as wind conditions, runway surface, and aircraft type.

I'm very happy with my Saitek Combat pedals after upgrading from the CH pedals a while back.

I sure would like to hear more about this myself as well.

Nice to see the autoupdater being used for a quick incremental patch. The ARM fix is very welcome.

Wags has said that new effects for the CBU-87/103 are currently being worked on but weren't completed in time for 1.2.4. Hopefully we'll see them in 1.2.5.

You were playing Rampant Bear on Eno's, yes? Not sure if you were still around, but I eventually took out one of the Tunguskas with a low-level pop-up attack from behind a hill with a Maverick shot at ~3 miles. It's certainly a more exciting attack profile than I'm used to, but I'm curious to see what tactics Eddie has in mind.

Mavericks have never been 100% accurate, nor are they intended to be. However, my first shot in 1.2.4 with a D model Maverick did miss. If not a bug, an interesting coincidence.

ETA? Just trying to plan my morning schedule here. :thumbup:

Assuming you are facing the general direction of your target and within range, you can use the HUD TDC to mark the area quickly, then use the TGP to refine the SPI to the target accurately.

Good news. Any chance that there has been an improvement to the massive slowdown encountered with the CBU-87 to go along with this?

Sure would be nice to see the autoupdater used to deploy a nice little incremental patch to fix this issue instead of having to wait for a whole new large version.

1.1.1.1 had its own share of multiplayer instability issues as I recall. More random and less frequent than 1.2.2 perhaps.

It's an error with the LAU-68 using the wrong model. Previously reported, but I don't know if it's been publicly acknowledged by any testers/devs.

So, you are saying that not only are a large group of users hallucinating instability problems, but the developers are as well? Wags' updates clearly indicate identification and resolution of real, actual bugs.

Hopefully the non-slideshow MLRS strike shown in the video means that a release version will include properly optimized effects for the CBU-87 and MLRS soon.