edmuss

Apart from leap motion where you actually have to reach out and flip the switch? Granted pointCTRL's useability is probably a little more reliable* but that's mainly down to the ED implementation, to me leap is more immersive because there are no additional buttons to press or extra devices on your hands. *as it's little more than a finger controlled mouse pointer with (I believe) zero interaction in the 3D space

I have a week off work now so hopefully I will be able to start getting some components marked out and cut. Going for hacksaw, file and pistol drill for the majority. Will probably have to employ the use of the pressbrake at work for kinking the stays although I might have a play with the blow torch and see if I can't hot work in the vice by hand

Just looking at that video you can see the kink that is applied to the cable, route it inside and below the frame, there is no kinking that way.

Slight update Modelled up the spring, seat and adjustment collar. The collar is threaded so spinning it onto the pull rod will increase centre tension, undoing it will release centre tension. At full compression the spring has rate of about 12kgf but is pretty lightweight, I can always spec up a heavier one if needed. nullAdded some gas strut tabs to the outboard side plates of the brake paddles, the struts will be running up the front edge of the main arms. Basing on the 80N struts then it should be 3.5kg brake force required at the top of the paddle and around 6.5kg if pushing at the kink in the plate. Paddle travel is nominally going to be 20° back from the shown position, this equates to a little over 40mm translation at the top.

Have you ticked the show arms box?

Hi all, thought I'd bung a thread in here to document my rudder pedals that I'm in the process of designing and building Apologies if it's in the wrong place and also in advance for the rather wordy post! My current rudders are a set of TM RCS of mid 90s vintage that I converted to USB by cannibalising an old Logitech FFB wheel for the motherboard and pots. Needless to say they're stiff, clunky, long in the tooth and missing toebrakes. Because I'm very constrained with space I can't use a TPR setup and the floor mounted parallelogram like MFGs (which the RCS are) get in the way for my mounted racing pedals. So I've broken out solidworks, found some stainless and aluminium bar stock in the shed that I can use and come up with the following design. Using a Leo Bodnar BU0836A for the USB interface to control the three axes. All are going to be using hall sensors for positioning. The basis of the chassis is an inside out TPR with a cam driven spring as per MFGs. The main and toe brake pivots will be delrin & stainless steel journals, the main cross beam, cam and cam follower will all be on two deep groove ball races each. A compression coil spring will be mounted onto the stainless rod passing through the box section chassis with a thumbwheel to give adjustable spring tension. I've ordered some 80N gas struts to provide return tension for the toe brake paddles, once they've arrived I'll model them up and then figure out where to fit them. I'll be marking, cutting and drilling all of the aluminium by hand at home, the delrin parts will be turned on a lathe at work (whether I do it or get one of the guys on the CNC to do it). The stainless sheet metal for the brake paddles will be laser cut, folded and bonded together. The whole assembly will bolt to the upright legs of my desk but in theory could be made to fit any sim rig frame.

Once mine lands I'll hopefully be able to offer some insight on the GPU bound front and as to whether the X3D helps in such situations. I'm thinking along the lines of the A10 easy instant access, with the 3600/3070 I'm typically running 10-12ms CPU and 13-15ms GPU. I'll do my best to do a couple of tests with my normal settings and some with higher resolution to further bind the GPU and repeat the process with the new CPU dropped in.

Well the upshot is it's only the cable As a matter of interest, do you run the cable above or below the frame and inside or outside? The HP instructions videos show it routed over the top and outside of the frame, however every time you flex the frame hinge this then puts a dirty great big kink in the cable. Route it under and inside the frame and it doesn't kink half as much. I minimise the amont I flex mine as a matter of course but it's a terrible bit of cable management the way they show it should be routed. Attached a photo of mine (with the leap motion fitted obviously) for reference. edit: attached a screen crop straight from HPs setup guide https://h20195.www2.hp.com/v2/GetDocument.aspx?docname=4AA7-5420ENW

Don't forget that if you're using reprojection you need to account for the associated overhead, it is displayed as postGPU on the OXRDT performance overlay. If the sum of both appGPU and postGPU is above your reprojection rate then it will step down to the next bracket. Typically I see 4-5ms postGPU if I have reprojection enabled, that suddenly means your 17-18ms GPU frametime could well be reprojecting down to 30Hz. DCS will allocate as much vram as you have, how much it actually utilises is another matter, typically if you're out of vram then FPS will be tanked and typically runs 15ms/50ms alternating which averages out to an extremely bad experience! I have read that the apache on high textures is a bit of a hog and medium is equal visual quality but much smoother; try playing with them and see if it helps the cause at all.

Yeah, I found the same problem with renaming it. Something copied the incorrect version back into the bin folder after renaming. Delete it and you should be good

That should be an incompatible d3dcompiler.dll, delete it from the DCS\Bin folder and it should work Did you delete the d3dcompiler after the update?

I suspect that without the toolkit writing the keys in via the ingame menu you will have to manually create them. I don't believe you need all of them for it to function correctly, certainly when we started setting it all up with DCS we were testing out random reg entries to see what they did Have exported my OpenComposite_DCS reg key and attached it, you can then insert/edit/copy to your hearts content OpenComposite_DCS_edmuss24.05.22.reg

Are you describing shimmer rather than jitter? Shimmer is an artifact of aliasing, jitter is a function of head tracking. Also are you using any form of upscaling? Both FSR and NIS introduce low levels of aliasing all over the screen and no amount of antialiasing will rid you of it entirely. To me it looks like micro aliasing (tiny crawling ants) along all edges which I find rather distracting. To minimise shimmer in DCS I'm afraid there's really only two options, increase resolution (supersampling) or use MSAA (antialiasing), both of which are quite a hefty hit on performance in VR. Using the openxr runtime improves the image clarity greatly for wmr headsets, I believe there are advantages for the quest2 as well. Given than your gpu is on the lower end for DCS vr (I'm not much better but I can get reasonable performance out of my 3070) then I would certainly look into openxr if you're not already using it and make sure that you conduct system wide optimisations. DCS vr tuning is not all about brute force but more finesse.

It wasn't my guide, @nikoelis the man for that I also only recently switched from 0.6.3 to the new merged global openxr switcher when DCS updated last. Uninstalled all mods via OVGME, repaired and checked for extra files via the ED batch files (available from the FAQs section of the website) and then ran the DCS update. Once it had done its thing I ran the extra files check again for good measure and nothing found. I've never used skatezillas app and if you follow the logical steps it's not required. Reinstalled the mods I'm using via OVGME (Taz's trees for Caucasus and Syria, along with his low bit depth A10C normal maps) and then ran the new global openxr doodah. I renamed the d3dcompiler to. Initially I had a -2 error, it would appear that a rouge compiler had been copied in by DCS, deleted it and the old renamed one and it's worked perfectly since.

I believe that you can edit the registry entries for OXRTK to adjust settings, it's a much slower method than the ingame menu though but it will allow you to enable upscaling/FFR etc pretty easily. I'll take a screencap of the registry entries later on and post it up with some explanations edit: something like this: - There are a couple of other entries that were off the bottom of the screen but if you want to know a particular settings then I can let you know what the key is and the necessary values. The settings shown are generally as per default except with FFR on quality/wide preset, resolution set to 3100 wide and reprojection disabled.

That's related to running out of VRAM*, this tool only keeps the system ram clear. *Reducing texture sizes, resolution, antialiasing and view distance will all help reduce vram usage, it's better with openxt compared to steamvr but still does happen.

As above, it seems to be a lack of VRAM in combination with a memory hole in DCS. Although it's much less common in openxr it does still happen occasionally, in steamvr for me (with 8gb) it's every subsequent flight start so essentially I would need to restart DCS entirely for every flight. In openxr I can go perhaps 5 or so flights before it manifests and the DCS restart is required. Hopefully the hole will be patched by ED but I'm not sure if it's been acknowledged/investigated despite being raised several times in different places on the forums.

I would give trading standards a ring They have supplied a component as new (to replace the original defective component) but not provided the anticipated 12 month warranty on it. Might not get you anywhere but worth asking the questions, however if you can prove without doubt that it's the cable that's failed then it should give you a much stronger case. Looking at it from their point of view, if the cable turns out to be ok and it's the headset that has failed then they're down a cable for no reason. Might be worth asking the question on the OCUK forums or similar (as in UK wide) and see if you can arrange with someone local with a G2 to do some cable testing. edit: note that I'm not a lawyer and have no legal knowledge so don't take my word on gospel!

Sounds like it to me as well, occasionally if I've started/restarted/switched multiple missions (with openxr) then the framerate will just drag to its knees and stay there till DCS is restarted. For me, in steamvr it happens the instant you have a second restart (even the same mission/module/theatre), with openxr it needs maybe 5-10 restarts.

Yeah they were quite hot on chasing up the return of the failed headset for me. I think you'll be golden, you should have a statutory 12 month warranty on all newly supplied items so phone them up in the morning Just hope it's not the headset itself failed! That said, if you get the new cable and it doesn't fix the problem (and HP are unwilling to help further) then sell the replacement cable for 100 quid off a replacement headset.

They will have the record of the V2 cable being sent out and that should carry it's own 12 month warranty on it. All depends on when you got the V2 really. Even if it's just out of warranty, play your face up and see if they'll send another out, they will ask you to test on another machine to confirm failure though. Did the V1 cable work at all for you? Like I said if you were closer you could have borrowed mine to test. They didn't ask for the V1 cable back in my case as they were pretty sure it was the fault. I did have to send the old headset back though after I'd recieved the replacement.

I would hazard a guess that the cable has gone bad, is the be cable as old as the headset? If it was replaced under the HP warranty then there should be 12 months on that. It might be worth a phone call to the HP tech support and they might be able to help out. Do you have the old cable that you can test it with? If you're in the Midlands you might be able to test against my cables for troubleshooting (I've got both the v1 and v2). My headset actually went bad with a 1-13 error and they sent the v2 cable out which didn't fix it so they sent a new headset entirely.

Yes it is useable for the quest2, I'm not sure sure how much benefit there is over oculus native but there have been positive reports for it. Have a search through the main openxr thread and there should be some implementation for quest 2 informatin in there somewhere. It would be handy if there were an oculus specific methodology written for implementing it

Indeed, seeing as our home fuel bill has just shot up to £3000 a year (from £1600) I perhaps ought to set the undervolt up again

It runs in the background and constantly keeps it low, when I've run it Syria ram usage is around 18-20gb without it it's gobbled up almost all of the 32gb. I don't generally use it at the moment as I've not tested to confirm it actually helps performance at all, like @DeltaMike pointed out above, if you clear the ram then you might just be needing to fill it back up again. I don't know enough about memory allocation/usage to quantify how well this works, more testing needed