Hempstead

It’s not that bad. I even used it for mining in Elite Dangerous, that tedious bit of grind, placed on my desk. You just have hold your stick lightly instead of death grip like a lot of noobs would. Death grip would indeed make you “feel” the wrong angle. But I have to admit that I bought two sets of TM flying clamps for it in a side stick configuration (for both F16 and F18, and no the center is occupied by Boeing yoke).

Nope, not that Gordon. It's Gordon URW. This one, https://www.myfonts.com/fonts/urw/gordon/ I am sure you can try that free Gordon. It's close too. As long as you are consistent on all panels, nobody will be able to tell unless they put a real panel right next to yours. Even my real F16 panel use different fonts, see the picture of my two Oxygen panels. '-' like in the screenshot below? I actually opened MS33558 font file with Fontographer on my old old old machine before its harddrive died, and there weren't any non-alphanumeric chars in there. As you can see below. Helvetica Neue Light is close, but a bit too "big and wide", but it's not unlike the Oxygen panel on top. Reducing the size might fool the unwary. And on some of the panels, I actually had to use Gordon URW Condensed Regular to get that "squeezed" look to fit the text in the space. That.... I can't find equivalent in any other font other than Gordon URW.

Indeed it cannot be MS33558, b/c ICP has a non-alphanumeric character, ‘-‘. See here, https://www.hempstick.org/The_Official_Hempstick_Site/F16_Landing_Gear_Panel.html, for my findings. In short, try Gordon font (commercial product.) Note that, I don’t have a real ICP panel. That 3D model Ranma13 used was modeled by Kumrik. However, from all the real F16 panels I have on my shelf, I can take a good guess that Gordon font will do you good. .

$142, USD? Mind you, Amazon is selling it for USD$299! I pre-ordered and paid something like $225. My only gripe was it’s too expensive for a plastic body stick. I would be happier if it were about USD $150. Guess you got a good deal.

That problem has been there since the Cougar days. It's caused by poor tolerance in manufacturing using the cheap pot metal casting method/material (more difficult to have tight tolerance for such cheap metal casting than proper metal like aluminum alloy) even with post machining. Sometimes, the shaft is just a tad smaller in diameter than the hole in the grip shell. The root cause is really a slight design problem -- you need to consider your material and manufacturing method when making design decisions. That shaft and shell connection mechanism is not a stellar design decision, although a good enough one for mass produced commercial products. I mean, no big deal, the fix is easy enough. I usually fix it with the traditional method... news paper shimming. Just open it up and shim it with some layers of news paper, or some tennis racket grip tape, and screw it back on. I recently fixed my F18 stick this way. Be careful though. Because it's pot metal (or plastic in F18 grip's case), it's very easy to strip the threads (and your threads might have already been stripped) so don't over tighten the screws. If that happened, you have two choices -- 1. thread inserts, and 2. use a stainless steel pipe clamp like somebody else on this forum posted (sorry, I am too lazy to hunt down the referenced posting, but my #include <disclaimer.h> here is valid -- I didn't come up with pipe clamp idea), or use a support bracket like the one MAXCenna mentioned.

https://github.com/JonahTsai/F16/tree/master/BasicPanels That’s a pair of Solidworks files based on MS25212.

I used to do 120Hz, max resolution set in Q2 device, with my RTX3080, and turn PD=1.0. It's workable... but you will never get 120 fps... but I wasn't shooting for 120Hz, I was only hoping for 120 / 2 = 60Hz (notice there is no 60Hz option; so this is my way of doing 60Hz). The trouble with using the default 72Hz is that you often get locked down to 36Hz, with plenty of GPU cycles available. With 90Hz... you get trimmed down to 45Hz, most of the time. With 120Hz, I was able to get beyond 45Hz... a lot of times at 50+ but never beyond 60Hz. However, I question the utility of fluctuating 50+Hz against stable 45Hz. Seriously, I can't tell the difference, particularly with ASW set to auto. So, for now, I am doing 90Hz, with device resolution bumped up to about 1.2X, and DCS PD=1 with MSAA 4x. I get quite stable 45Hz (except when there are a lot of explosions etc. like from GBU-105), and my GPU utilization is somewhere north of 75%.

Not just that... I don't know about you, with AirLink everything look fuzzy to me.

Well, at least OP was able to return to cockpit view. I got another problem with F10 with my Oculus Q2. Since the recent update of Open Beta, F10 seems lagging and even not responding to mouse and touch controller input. It seems to be so laggy in F10 that even zooming the map doesn’t work. But, if it did respond, it took like a second or two to zoom in or out, making it completely unusable. I mean, imagine human induced oscillation remote controlling a buggy on the moon from earth. And it got so bad that F1 did not work in map, but F2, F3, etc. did work. And since I couldn’t get back to cockpit view, I was forced to kill dcs.exe eventually. I have not tried if this happens in 2D yet.

I tried the new OpenXR NIS solution a couple of days ago. No go. Neither DCS nor Elite Dangerous uses OpenXR. It does work for MSFS 2020 though.

In case you are too lazy to go do what I mentioned earlier. I always have a VM up with Solidworks running. It's 6.6428" x 2.

Nope... those are two different things. One is "Asynchronous" Space Warp, the other is "Application" Space Warp. What's in Oculus Debug Tool is Asynchronous Space Warp. Application Space Warp requires the application to explicitly provide the motion vectors for it to compute more accurate additional frames than Asynchronous ones could "guess" from previous frames. So, DCS must code it in for Application Space Warp. I would love DCS to code this feature in.

https://www.hempstick.org/The_Official_Hempstick_Site/F16_Model_A_Center_Console.html Go Download this on GitHub, load it up to a compatible CAD program, Solidworks, Fusion360, or OnShape, and measure centerline of the whole thing to centerline of the store mgmt panel, multiply by 2 and you get centerline to centerline of the MFDs. Sure, this is model A without MFDs, not model C, but I am pretty sure it’s the same. I also have a real model C left console frame too. I put it on top of the model A console, they match exactly. I must warn you if you use OnShape to open it. OnShape no longer allows private projects for free accounts. You must not save the document without attaching a Creative Common Non-Commercial International license these files are published in. Otherwise, you might have re-published the files you don’t have rights to grant additional rights. It’s a mess best avoided. If you must use OnShape free accounts, the easiest way to avoid all these license nonsense is to open it, measure whatever you want, quit, and don’t ever save.

Totally Off… That was the idea - I set the Q2 to max resolution, which will tax the gfx card to render at higher resolution (what the GPU does best), then Q2’s hardware will reproject to its curved surface according to its optics. Oculus mirror even has a command line option to “flatten” out the framebuffer. Then, Q2 has to either downscale and/or crop it to native resolution of its LCDs. That’s the “theory” anyway. There is only one way to find out. Moreover, one of my CPUs is pegged at 100%, CPU bound. And my GPU utilization was at about 60%. By rendering at higher resolution, I bumped up my GPU utilization to about 80%. Even though I set Q2 to 120Hz, I am never expecting I could get that. I am only hoping when ASW kicks in, I get either 30, and perhaps shoot for 60 (dream on), instead half of 72, which comes to about 35. Difference between 30 and 35 fps is barely perceptible as long as they are smooth. So, what I am doing is basically supersampling split in two parts — render at higher resolution by the GPU, and downscaling by Q2. GPU no longer does the downscaling… I hope. Therefore, I can skip the in game SS, as I found the in game SS no longer improved my perceived rendered quality. And, BTW, my cloud quality is set to Ultra. I can probably squeeze out a few fps turning that down.

I have the Q2 maxed out on resolution with the experimental 120 Hz refresh rate, ASW=Auto (set in Oculus Debug Tool). But I have an RTX3080 Ultra (EVGA factory over clocked, basically). So I went with the brute force approach. This lets me turn down AA settings. If DCS supports nVidia’s DLSS, and in VR, I might give it a try instead of the brute force approach with higher resolution. With MSAA off, I get some annoying shimmering, but not too bad. Quite ok actually. And I get about 45fps at 1,500 ft agl overhead landing pattern at Nellis. Turing on MSAA 2x, I lose about 5fps, i,e. 40 fps, even on the runway. So, now I know where to get that extra 5fps, if I need it. At altitude, it's even higher fps, but never over 60fps. And, I have the expensive Quest Link optical cable. I get about 1.7Gb/sec. I don’t use OTT at all.

That should work. I didn’t know that function exist!

You’d have write your own USB firmware, or figure out another way to masquerade as one of TM’s USB controller. It’s a widely known “secret” for over 10 years.

So, you agree in mission editor setting steer point using agl is buggy? Why else would I need to avoid using agl and switch to msl instead?

Well, every time I put in 0 agl in the mission editor, it always jumps back to 98 feet after I step off the input field.

I am designing one. And it’s aimed for making it all in your garage with simple hand tools and some simple shop tools like a drill press and a 3D printer — a very tall order in design. I am mostly concentrating on the guts of controls like HAT and buttons, and slew control, all non-contact without bounce. Like mini-Hall stick, optical 8-way + 1 switch. The 8-way optical HAT switch alone has been ongoing for the last 3 year (10 complete redesign… almost there). But, I wouldn’t hold my breath on it. Even I couldn’t wait for my own RudderCore design to be completed (needs Hempstick Pico, which I have not even started yet) and bought a TM Pendulum Rudder. Moreover, there are a bunch of people already made their own F16 throttles using 3D printing. Anyway, TM Cougar is all 5V.

Yep. That messed me up for a few days. The symptom is that no matter which direction you approach the steer point, on HUD, the target box always seems to be farther than where it “should” be. The “Z” height shows up. Unfortunately, in mission editor you cannot set a steer point to be lower than 98 feet agl. That, I consider a tolerable bug, b/c 98 feet agl is close enough to not mess up your perception from afar, particularly when you are 20,000 feet doing a level bombing run. But if you do a Stuka style dive bombing, you can tell the 98 feet difference.

Mine doesn’t even touch my face. No VR goggle face print like a raccoon either. It’s an el’cheapo AirSoft helmet, not rated for impact. The adapter is a clone Wilcox NVG adapter, all aluminum. You can adjust up down, in, out, tilt up down too. The yellow thing is simply a 3D printed PLA holder. I have since replaced the rubber band with a better bungie coord, as designed. You do have to scroll saw the front lip of the plastic helmet a bit to accommodate the goggle. Everybody follow Luckey’s ski goggle design and improved on it. But everybody forgot that the real problem is that you are hanging some weight cantilever and you need something to counter that torque. Your head with long COVID-19 hair simply is a bad thing to generate that counter-torque. The forehead plate is in the right direction, but not enough. Anybody who have wore a k-pot in the bootcamp knows that thing with just one strap rolls forward and backward on its own will, particularly when you are sweating like a pig. That problem has already been solved! The 2nd chin strap from your chin to the back of your head provides the counter torque. It’s still uncomfortable wearing it for long with the goggle flipped up. But for flipping up to look at your pancake to alt-tab or adjust something quickly, it’s perfectly fine. I am in a mind to hang some horse blind on both side to block out the reflections. And perhaps an audio headphone and mic?

I see no hand at all in the visualizer, even though the status is all green. Sticker on the sensor says to activate at that URL, but no activation whatsoever at that URL, only Gemini download. Do I need to unlock the thing or pay some subscription or what? Or is it simply dead on arrival? I spend two hours searching the web for solutions to no avail and gave up.

I can also confirm that it's the Ant Elevation "bug." Here's what I tried. After I shot down the two bandits, it instructed me to go after the 4 new bandits... and lo 'n 'behold... the Ant Elevation without me doing anything to it other than following the instructions and changed mode etc., went completely berserk. Both low and high alt. next to the cursor went negative red. So, I just moved the Ant Elevation knob slightly, and it returned to blue and reads normal. Then TMS right worked as it should be, repeatedly.

I am still working on it…. But mostly the guts of it for the last 3 years, and mostly on the optical 8-way HAT switch, a real bitch with all my requirements. Today, the prototype of 9th complete redesign of the sensor cap finally proved to work well. What are left are just refinements and jigs to make making them easier than free handing it, and a lot of clean up, packaging, and documents, switching to MSLA instead of FDM. ( come on, Phrozen, where are my 8K mega and 8K mini?) I am considering releasing it, not necessarily OpenSource. Then, on to Hempstick Pico. Damn, I need to finish these for my DCS F16!