GregP

No, it's a little bit different, a little further back, higher, and less panned down: Default: Snap[11][13]["y_trans"] = -0.041336805555555564 Snap[11][13]["x_trans"] = 0.36 Snap[11][13]["hAngle"] = 0 Snap[11][13]["viewAngle"] = 75.0 Snap[11][13]["vAngle"] = -23 Snap[11][13]["rollAngle"] = 0 Snap[11][13]["z_trans"] = 0 Mine: Snap[11][13]["y_trans"] = -0.046597290039063 Snap[11][13]["x_trans"] = 0.370751953125 Snap[11][13]["hAngle"] = 0 Snap[11][13]["viewAngle"] = 131.448216 Snap[11][13]["vAngle"] = -19 Snap[11][13]["rollAngle"] = -0 Snap[11][13]["z_trans"] = -0.001983642578125

Well guys, I've fooled around with this for a few hours and still haven't gotten it to my satisfaction, however, this is the best I've come up with so far. The viewangle parameter is probably way too high for single-monitor users, but looks good on my 3-monitor setup. It's not much of an improvement in terms of side panel visibility, but does significantly cut down on the 'skewed' look of things in the default view, with the HUD frame and MFCDs appearing more vertical instead of angled. My settings: Snap[11][13]["y_trans"] = -0.046597290039063 Snap[11][13]["x_trans"] = 0.370751953125 Snap[11][13]["hAngle"] = 0 Snap[11][13]["viewAngle"] = 131.448216 Snap[11][13]["vAngle"] = -19 Snap[11][13]["rollAngle"] = -0 Snap[11][13]["z_trans"] = -0.001983642578125 Default: Mod:

Right -- there's no doubt that this is a tough design problem, and we can be fairly certain that ED knew what they were doing when they designed it as is, and had good reasons for doing so. Nonetheless, it does indeed seem that having the eye viewpoint further back not only feels more natural, but leads to less fisheye effect. Seems worthwhile, therefore, to see if we can get all the HUD info to compress inside the new visible HUD area.

OK, I just tried the LWin+KPx method last night, and found that those key combos need to be held down, unlike the {RCTL KP0} DELAY(50) KPx method, which toggles them. It seems to me that toggling is better than holding down, because with the latter you can press other keys/buttons in the sim and have them be recognized, whereas in the former (I'm pretty sure, from past experiment) you cannot.

I tried Cayenne's settings and I too agree, they feel much more realistic than the defaults. I would, however, shift the view upward enough so that the top of the CDU is visible -- this reveals a lot more of the bottom of the HUD and doesn't seem to adversely affect anything else. I completely agree that the eye viewpoint would more intuitively be placed nearer the seat back, rather than the front edge, and doing so makes a tremendous difference as you pan around the cockpit -- the 'fisheye lens' effect is significantly reduced, and the visibility of the side panels seems much more realistic; I've always been frustrated at my inability to read the side panels right-side up -- they always appears almost upside down since with the default viewpoint, you're really looking REARWARD to see the bottom 60% of the side panels. But, as everyone has noted, the HUD gets messed up and is only minimally visible when you move the viewpoint rearward. There are a bunch of LUA files that control HUD format here: C:\[game]\Scripts\Aircrafts\A-10C\Input\HUD\ And I tried playing with a bunch of different parameters in (I think) HUD_definitions.lua, but couldn't get it working correctly. I was able to drop the font size, but have yet to find a way to compress the HUD symbology to fit into the smaller area of the new viewpoint's HUD. But I would guess that our answer lies somewhere in that folder.

By the way, I think I also read recently that the release version has added LWin+KPx as being equivalent to RCTL+KP0 and then KPx, which would be a simpler way to solve your problem above.

If I understand you correctly, I've got the functionality you're looking for in my Cougar profile simply by combining the 'snap view toggle' command with a delayed 'specific snap view' command. Try this in your button assignment in the TMM file, using Left MFCD as an example: Zoom_left_MFCD = {RCTL KP0} DELAY(50) KP4 Cockpit_panel_view_toggle = {RCTL KP0} And this in your TMJ file: BTN H3U /O /T Zoom_left_MFCD /T Cockpit_panel_view_toggle It's not a perfect solution, as sometimes pressing H3U will only do the 'snap view toggle' command instead of both that and the KP4 command ... you have to sort of 'nudge' H3U again after pressing and holding it up in order to get the KP4 part to work. Might be easier to use method below, actually, now that I think more about it.

My bad, I misunderstood your #1 -- you meant press and release the snap view button; I thought you meant just press it without releasing it.

Ah -- well if that works, then yeah, that's definitely simpler, aside from the fact that you have to hold the snap view button down the whole time. Doesn't that interfere with moving your view to the new desired position, though?

Let me preface this by saying that I use a 3-screen SoftTH configuration in DCS: A-10C, so you might see different results if using a different setup -- but I think it should basically be the same. In DCS, choosing the 'HUD' snap view (RCTL KP0, then KP5) gives me a zoomed in view of the HUD frame but the actual HUD symbology is way too zoomed in, with most of it lying outside the frame and thus not visible. With the betas and their inconsistent snap view saving behavior, I never quite figured out how to create a more useful zoomed in HUD view. Boredtechie posted a very useful set of changed snap views here for things like the MFCDs and CDU, which I incorporated into my SnapViews.lua file, but he didn't list a 'zoom HUD' configuration, and trial-and-error at guessing numbers for viewangle, rollange, hangle, etc. just got too frustrating for me, so I decided to find a way to make DCS's 'save cockpit angles' functionality finally work for me, as I'd yet to work it out. With the release version of A-10C I've now got it working, and thought it might be useful for others. Here's how: Assuming I want to overwrite the inadequate KP5 snap view: 1. If you haven't already done so, set UseDefaultSnapViews=false in your View.lua file. 2. Toggle snap views: RCTL KP0 3. Press the snap view you want to change: KP5 4. Untoggle snap views: RCTL KP0 5. Move/pan/zoom your view to where you want it; for me, simply using zoom in (*) and slightly panning the view up a bit got me a nice zoomed in HUD view. 6. Save cockpit angles: RALT KP0 7. Press the snap view you want to set: KP5 And that's it, you're done! Pressing RCTL KP0 and then KP5 ought to take you to the new zoomed-in HUD view. And you can go to your SnapViews.lua file to see what values for [11][6] creates this view, for easier setup next time.

I just last night worked out the proper sequence for 'saving cockpit angles': 1. Toggle snap views: RCTL KP0 2. Choose the snap view you want to change and press that key: e.g. KP5 3. Untoggle snap views: RCTL KP0 4. Move your view to desired position 5. Save cockpit angles: RALT KP0 6. Press the key of the snap view you chose before: KP5 Voila! RCTL KP0 and then KP5 should now give you the changed view you wanted. You can also, as you say above, now look in your SnapViews.lua file and see the values in [11][6] and save them for future reference.

TigersharkBAS, I just wanted to thank you again for these excellent videos. I was able to order all the parts, assemble everything, and get it up and running in DCS with minimal trouble. The hardest part, really, was just getting the very thin wires that come with the GP-Wiz40 (which seem to actually be for solder connections, requiring users like myself with screw terminal switches to cut off their ends, carefully cut off some sheathing, and then delicately twist the individual wires around each other) to not constantly snap when moving things around. After a few tries, though, I've got it all working. I did an AHCP, minus a few of the switches, as my first project just to test it out. It's brilliant -- thanks again!

Yup, clean install after uninstalling Beta4. And I have no graphics options set outside the game, so if I'm doing same in-game then I'm stumped as to what's different.

Indeed you are! Porsche Turbo S Wheel with Clubsport Pedals. I gave up trying to switch out the Clubsports for my CH Pro Pedals whenever flying, and finally found a way to get the Clubsports to work in DCS properly (found this on the ED forum somewhere, but can't quite remember where): Left Rudder: set it to the pedals' Joy_Slider2 axis, check the 'slider' box, then set the responses to 0, 100, 50, 0. Right Rudder: set to pedals' Joy_Y, check both 'slider' and 'invert' boxes, set responses to 0, 100, 50, 0. Wheelbrakes: set to pedals' Joy_RZ. The only downside, and it's a minor one, is that since I run the pedals thru the wheel, I have to turn on the wheel first, meaning the fans inside it are running the whole time I'm flying. If I separately connected the pedals via USB to the computer, instead of running through the wheel, this could be avoided -- but then in racing games, I'd lose the brake pedal vibration effect, which only works when run through the wheel (it's a 'canned' effect, always occurring at a designated pedal travel percentage, but I like it anyway).

So I dialed my overclock back down to 4.6 last night, to match what I was running with Beta4, and I get the exact same framerates I got at 5.0 with the release version: 44 and 47. Apparently, something has changed in the release version that has negatively impacted framerates on my system. I'm stumped!

I don't know -- unless you're specifically trying to run with 3 sticks of RAM (for example if that's what you already owned and didn't want to buy new sticks), does going from triple-channel to dual-channel really affect anything? With this platform, it doesn't seem like RAM is much of a bottleneck. With Sandy Bridge there is no de-linking of the FSB from anything else, so I don't think there's any way to play with things like QPI. All you have control over is FSB -- which pretty much has no headroom -- and multiplier. Right, I'm waiting on Microcenter to begin stocking the fixed boards, at which point I'll do my exchange there. Either way it doesn't affect me because I just switched my SATA devices over to the 4 ports that are not affected by this defect.

I use a Sunbeamtech Core Contact Freezer w/120mm fan -- not top of the line, was using it for 2 years on my old QX6800 -- but DCS under load, in my testing so far, doesn't push the temps above 70, and idle in mid-30's. Yeah, my next test was going to be dropping back down to 4.6 to see if I could replicate, or even just get closer to, the FPS numbers I was seeing in Beta 4. And why 5.0? Simply because the headroom is there, and it's fun to say your machine is running at 5 gigahertz :) With these Sandy Bridge chips o/c'ing is effortless, and I got at least a 10% FPS gain when going from the stock 3.3 up to 4.6, so I assumed going up to 5.0 would at least not hurt things. But perhaps I've pushed it too far. I guess I won't know til I try 4.6 again.

I don't know -- I'm a bit hesitant to present this, because I feel like there must be some obvious thing I've overlooked and screwed up -- but I did a comparison last night between Beta 4 and the release version and I got a big DROP in framerate, DESPITE the fact that I have overclocked my processor even more now than I had when I did the Beta 4 test. My setup was/is: WAS: Beta 4 64-bit version, i5-2500K @ 4.6 GHz, 8 GB DDR3, GTX 470 at 680/1360 IS NOW: Release 64-bit version, i5-2500K @ 5.0 GHz, 8 GB DDR3, GTX 470 at 680/1360 I ran two different tests (one a simple sitting-on-the-runway takeoff mission, the other during the LITENING Pod training mission) using a 3-screen SoftTH setup at 4630x1080 and got these results: WAS: 52 and 57 IS NOW: 44 and 47 That's a disturbing 15-18% drop in framerate since Beta 4. As I was entirely expecting a framerate jump with the release version, I'm really confused here.

These threads are always fun. Some nice setups here, guys! I'm surprised that more of you don't run SoftTH or Eyefinity or Nvidia Surround. I'm loving SofTH with DCS: A-10C, even though it is solely responsible for my not being able to easily add other monitors for MFDs, Helios, etc.

Aw man, wish I'd known about polycase -- thanks for the link. I could've used that before buying my now too-small 7.5x5x2 case from Mouser Electronics to build an AHCP.

Wow, TigersharkBAS, I just watched your videos and whereas beforehand I had little to no interest in building such a panel, now I am definitely going to give it a try. As I'm not so big on the startup process, I'm thinking of trying the Armament HUD Control Panel as my first project. Thank you so much for taking the time to put these together -- I love stumbling across cool new home cockpit additions.

Wow, Sandman, that profile looks incredible, nice work! I myself use SoftTH with 3 monitors, so I don't think Helios is currently an option for me, but man it's tempting after seeing the coolness that it's capable of. Thanks for sharing.

Krebs20, unless you need Hyper-Threading for something (DCS won't use it), save yourself a hundred bucks and go with the 2500K. I've got mine running at 4.8 GHz on air cooling and could easily push it to 5.0. The few hundred extra MHz you might get with a 2600K won't make any difference in DCS -- see my post here to see how much O/C affects framerate.

Kuky, I ran a single CPU test case in Cinebench 10 and got a score of 6700. copen, my case is an AZZA Hurrican 2000 and my CPU cooler is the Sunbeam Core Contact Freezer 120mm.

Kuky, no problem at all, will do tonight when I get home.