Meatshield

Well, if anyone else finds it as insane of a design decision as I do (for background I'm an embedded device/firmware engineer with 12 years of commercial and industrial new product development experience specializing in human-machine interfaces, not saying I'm never wrong, but I pride myself on creating an intuitive and a pleasant user experience), or just wants to see what I'm talking about, I learned some python just now and made a joystick gremlin script to fix the hat dropping buttons in the corners. Feel free to use/modify/ignore: https://pastebin.com/F1FiPPsh To use: install vJoy, install Joystick Gremlin, and download the py script linked above Set the hat to 8W mode in VPC In Joystick Gremlin, add this file on the plugins tab, hit the gear to config, bind the hat to the various inputs, set the outputs to buttons on the virtual stick Click the gamepad looking thing in the toolbar and it turns green Enjoy! You can run as many instances of the plugin as desired (hit plus sign next to plugin to spawn more instances), so you could do all the hats if you wanted. It only has callbacks, so shouldn't hurt performance. Bonus, if you have multiple throttles, or a collective that you swap between, you could map a hat on each to the same virtual buttons so you don't have to change your VA/SRS bindings when switching devices

The issue isn't finding it, it's holding a hat on the side of the throttle a perfect direction for a number of seconds while making large throttle and/or body movements, as one would do with a 4-way mic switch while in combat. (which is also when you have the least brainpower you're willing to devote to something like that)

4 way is meaningless, because you may as well have it set to 8 way, if the way you have to use it is to carefully and perfectly only press it exactly U/D/L/R, no? Like U 0 R 0 D 0 L 0 is still 8 ways, just putting 0's in instead of UR RD DL LU, instead of a 4 way which would just go U R D L

The fact that I think "pushing on the hat firmly should result in a button press unless you are set to 4 way and manage to exactly hit the corner without activating one of the sides first" is the problem? If this is intended behavior, it's because they messed up and are letting inputs inhibit each other, like: U'=U&!(L|R) R'=R&!(U|D) When they should be using the outputs to inhibit each other: U'=U&!(L'|R') R'=R&!(U'|D') If this is the issue, I feel like it's where the vast majority of their hat complaints come from. People say they "feel" bad, but I'm guessing the main issue is they "feel" like they don't have great control over which buttons are pressed and using it in 4 way with proper logic would fix that. I'd bet a large amount of money they make that change and make 4-way the default for things other than POV hats like the trim hat on joysticks, it would virtually eliminate hat complaints, and hat complaints are like the only thing I see people bash Virpil for. The problem is between the keyboard and the chair, but it seems to be between a keyboard and chair at Virpil somewhere.

Those settings only show you using 4-way for the 2-way switch on the front of the throttle, the rest of yours are set to 8-way and would trigger multiple buttons in the corner, unlike 4-way, which is what my questions are all about, which should only send 1 at a time. Happily, little help?

That's exactly what I'm saying. I was pressing up, it's set to 4 way, it presses the up button. I move towards the corner and it drops the button, even though you can clearly see physical input 20 is still asserted. In 4 way, there are no corner buttons, the corners should just keep sending the cardinal direction it was sending. If your sending up, you should be able to move to either "up" corner and still send up, it should send up until you release the switch or rotate to be pressing straight right or left, right? People on discord and here have said that they do not have spots in the corner where it sends 0 buttons while pressed in 4 way mode, but no one has provided any screenshot to prove it.

The images on the right half were the buttons in JoyTester, the left half is VPC Config's raw inputs, and I'm not having any issues with center, so that isn't the issue. Anyone? Anyone else able to see this behavior on theirs? Do I need to warranty my throttle?

Thank god, I was hoping it was a bug on my end. What software version are you using? I'm on the latest, and here are my settings:

You guys are saying it doesn't drop the button in the corner for you? Could you share a screenshot of your button/ALPs decoder settings?

If the issue is that they consider it a requirement of 4-way mode to not be able to go directly from one direction to another (using my logic, up to up-right to right would simultaneously drop up and start asserting right once you got out of the up-right corner, no dead zone), I'd rather see it where you need to go back to not pressing anything for it to register another press. So you could press up, and then do a full 360 if you wanted and it would still be asserting up until the hat doesn't see any of its physical inputs asserted. Assert the first direction until there are no directions pressed. Boom, fixed. Make one of these schemes an option, at least. The current behavior does a very bad job of translating user intent into button outputs. I'm never pressing on a 4-way hat and intending to send zero button presses.

The hats are garbage, unless I'm missing something. If you want to use it as a 4-way and you press and hold a direction, then say move the throttle while holding it, or just twitch a little too close to one of the corners, it will either add a second button press if in 8-way mode, or drop the original button press in 4-way mode. They cannot be reliably used as mic switches, the a-10 coolie hat, a speed brake switch, or anything where you want to be able to reliably press a direction and hold it for a duration. There is no way to use them as 4-way hats other than playing a stupid game of "don't touch the corners". It would be a simple logic change for them to just not change any button outputs when a 4-way is pushed into a corner, as it's not a valid combo to interpret. You can assume if the user was pushing a direction, and is still pushing that direction, they still want the original button held down, even if they accidentally touched a corner. In 8 way if a user pushes some direction, and then towards a corner, the software correctly interprets user intent as wanting to add in a second direction. In 4 way if a user pushes some direction, and then towards a corner, the software assumes the user doesn't want to be pushing the hat at all. WHAT? WHY?

The ungated hats are insane, driving me crazy after one day as well. Why the heck is the software logic for 4 way action to drop the first pressed direction when the second pressed direction is detected? I would assume if I move it up, and it registers as up, and it's in a 4-way config, that as long as that up input is held, the output should hold, but if it sees fore or aft in conjunction with up, it freaks out and doesn't output anything, when you clearly are pressing on the switch. Virpil, if you are listening, the proper 4 way logic would be to output whatever direction when it is pressed individually, and continue the last output when two directions are seen at once. (not drop it)

Sorry, I figured it out. Giving the "engage with" command does it, but then it doesn't use the datalink, it uses DCS AI magic. Limitations of AI wingmen and such, I assume. Anyways, great work, thanks for all the fun, learning, and practice!

Hi, love the campaigns. I'm on the first mission management one, (after getting lucky on SADL engagement), my issue is I can't figure out how to issue an accurate attack command to wingmen. They just sorta do whatever they want. Last attempt at one point they were each 40 miles away in opposite directions (I believe after issuing an attack command). I have SPI on a target, and I've tried either broadcasting it, or with SPI set, hooking a wingman and hitting the "SEND xxxx" OSB on the TAD, but neither result in any attack runs by the wingmen. They seem to just pick their own targets of whatever type if I issue an engage command afterwards. No idea how datalink and issuing commands to AI work together, and google isn't helping, either. Everything I can find is about human wingmen and multiplayer. Little help? For what it's worth, the A-10C manual says the following, but after hooking the aircraft, the network ID appears below send without pressing it first, and after pressing send the first time, the send OSB goes away, so there's no send OSB to press a second time.

Love the program, 2 small bugs, first, the donate link just opens a blank page and I've tried googling and can't for the life of me find any donate links for your work, and second, my scripts to startup DCS and cleanup after DCS fail with SimShaker, because when I send a terminate signal with the taskkill command (not /f forced, just a regular taskkill), SimShaker mostly closes (like the notification tray icon is gone, and it doesn't operate when DCS is running), but remains a listed process. Then my startup script thinks it's already running and skips it. I dunno how hard it is to handle the taskkill event the same way you handle choosing exit from the notification tray, because that works fine. Or if you don't leave files open or anything, maybe it's safe to just force terminate simshaker with the /f option? Or is there any other preferred means of closing it from the command line? Edit to add, I'm on what I believe is the current beta

I'm not sure if its effect on the aimpoint is implemented, but if you have the TGP and the laser armed and fire the laser as you aim/release, it's supposed to switch to the laser as the range source for the most accurate CCIP calculation.

That did the trick. Awesome, thanks a bunch! I was googling for a long ass time trying to figure it out without any luck.

Hi, I've got a weird one. I'm getting horrible double vision with my brand-new Vive Pro 2. It works fine in SteamVR home environments and Pavlov VR, but in DCS it has vertically stacked vision. It's like one of my eyes is looking slightly up or the other is looking slightly down, but they don't line up, and I see a vertical double image of everything, worse the farther away from the POV it is. I tried a full repair, deleting (well, moving to a backup) the saved games folder, doing a full "reset" of the headset through vive console, tried the vive console beta version as well as stable, updated my graphics drivers, but nothing has helped. Any suggestions would be greatly appreciated.

None i found, haven't tried in a bit. I actually stopped using Viacom for now because of this bug, and can't recommend it to any Viper pilots in it's current state.

See attached for screenshots from current build. Mission 8 of UN Pilot Campaign played on Open Beta today.

I'm also having very, very severe impacts in multiplayer (like dropping from 45 to <5 fps, resolved by toggling VRK off). Made sure the hook script is not installed and that auto-load mission is disabled. 5800X, 3080, 64GB, NVMe, HUION H640P. Any suggestions or ways I can provide further information? I'd love to be able to use this app.

This is still an issue. We were trying to do low level IR Mavs in Nevada at night, 3/4 moon, was fine until about 30 minutes pre-dawn and it went pitch black, couldn't see the ground even with NVGs. Moon was still overhead. It's like when it switched from night to day lighting or something.

Hey Devastator, I'm having the same issue, you ever get it sorted?

Bump. For example, I can't bind VR Zoom to either the keyboard, the mouse, or my throttle. Please can we get an update on this issue? it's been over 2 years. See attached

See attached. I can't bind VR zoom controls to my speedbrake switch like I do in every other aircraft, but I can bind them to any of my other USB controllers. My next thought was to use Target software to make the throttle send keyboard keys, but a) I hate target software and b) keyboard is greyed out as well! What gives? How do I fix this? Thanks for your attention in this matter.