Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hide the Nintendo Drivers from Other Programs #11

Open
JoshuaEagles opened this issue Jun 18, 2017 · 10 comments
Open

Hide the Nintendo Drivers from Other Programs #11

JoshuaEagles opened this issue Jun 18, 2017 · 10 comments

Comments

@JoshuaEagles
Copy link
Contributor

This is something that causes issues in some games, basically since the (bad) Nintendo supplied drivers are still there, some games that don't use controller-selectors and just pick up the first thing they see (Dark Souls looking at you) will pick up one of the Joy-Cons and get inputs from them. This is a small issue, and not likely easy to solve, however squashing it would be very nice.

On a similar note, built in direct SCP support would be nice, to eliminate the vJoy -> XInput layer, optionally of course. Again, for games like Dark Souls, where having extra controllers results in problems.

@fossephate
Copy link
Owner

I noticed this in a game the other day, this isn't what I'm working on now but I'll look into it further / how to resolve it when I have time. You might be able to fix it by setting the default gamepad in windows (to the vJoy controller) although that probably won't work for all games and a more permanent fix would be nice.

@fossephate
Copy link
Owner

Eliminating the vJoy->XInput layer would require a lot of work, and I would have to add a button mapping feature, so for now I prefer to leave that to programs like x360ce, but maybe in the future ;P

@JoshuaEagles
Copy link
Contributor Author

Yeah neither of these things are all that short term. As for button mapping, since I'm looking at remapping vJoy anyway, I may look into that part myself as well. I'll at least get something going through the command line arguments.

@My1
Copy link

My1 commented Jun 21, 2017

well one thing that although would be nice would be to hide the actual joycons and only have the vjoy there, because programs which can work with multiple controllers see both the real joycons and the vjoy, which isnt too funny.

@JoshuaEagles
Copy link
Contributor Author

Yeah, My1 that's exactly what I said, the Nintendo Drivers are the other things that are seen in joy.cpl.

Also, I believe WiinUSoft has found a solution to this for the Wii U Pro, which would likely transfer over, however that solution doesn't work on recent versions of Windows 10, and the code isn't open source (yet, he is going to open source it when it's done apparently). At the very least, this means it's possible.

@fossephate
Copy link
Owner

fossephate commented Jun 23, 2017

in joy.cpl you can set a preferred controller, which may help for some games in the mean time.

@jabujabu
Copy link

jabujabu commented Aug 6, 2017

First, sorry for my english.
I digged arround with ghosting issue for these few days, and found that it is not just ghosting but 'dual' ghosting ((wireless controller + vjoy) + xinput). For example, in resident evil 4 pc version's controll setting, you will see three gamepad device(wireless controller/vjoy/xinput) with joycon driver + xoutput on background. And it ghosting( you cannot choose one!). and 'mame' emulators input setting also detect 3 input for one push button for binding.

Almost emulator(dolphin and etc but exclude mame and etc) was OK with ghosting problem because there is option to choose specific control device and other control layer will not interrupt, But almost steam game has not such option. it is so sad that this driver is working fantastic but restricted a lot in steam games by ghosting problem.

PS. Some Steam game works very rarely with dinput blocker(you can google it) for this problem, but seems like there is no stable solution we can choose right now.

PS2. Found some better workaround that steam has it's own controller mapping for each game&global, It is placed in deeper section, but at least you can manually mute all dinput layer and solve ghosting. But it's far-away from user frendly and requires too many heavy understand for each setting and actual result in game. Thanks for developer add this issue to feature request.

@fossephate
Copy link
Owner

looking into this further, it looks like this problem is a bit beyond the scope of what I'm capable of in any reasonable amount of time, fortunately, it looks like this project was built for this exact problem: https://github.com/nefarius/ViGEm/tree/master/Sys/HidGuardian

It looks like it's still a work in progress though, but you can test it here:
https://vigem.org/hidguardian-v2-secret-alpha-test-area/

There are also other solutions out there as @jabujabu mentioned, this one might not be the best solution, it also looks a bit technical for the average user, so post what works for you / for which games

@jabujabu
Copy link

jabujabu commented Apr 3, 2018 via email

@stoikerty
Copy link

I'm also having this issue. It can only be the duplicate controllers interfering with each other. Trying to get the Switch Pro Controller working with Minecraft Bedrock and I'm having no luck. When I start the game the controls go crazy and it selects menu options back and forth and I'm unable to even get into the game :(

Without JoyCon-Driver the controls in Minecraft work mostly... everything apart from sprinting for some reason... which is why I'm here, looking for an alternative in using JoyCon-Driver.

Having said that, the rest of the utility works quite well! I love the little touch of playing the mario tune using the vibration of the controller :D pretty neat

If HidGuardian was a one-click utility I would look into it, unfortunately there's too many steps to make it worthwhile for me just to play Minecraft. I'd rather just use my SF30Pro in the meantime.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants