(04-17-2014, 02:52 AM)Banyuyaga Wrote: [ -> ]When the gamepad is not connected the tool tries to create the xinput controller, because it is paired? Is that happening?, because I see the tool reporting the gamepad that is not connected, but paired and the text connecting... Can that be related to the problem? This problem (not showing fake xinput controller, and also not receiving input in the directinput controller) has happened to me for a long time, but was being triggered randomly. Now it happens always both on my pc and laptop...
What version is the problem starting with? You must be getting some kind of error printed to the console output if it is attempting to connect while being paired and never gets anywhere. Are you also using Windows 7?
(04-17-2014, 02:52 AM)Banyuyaga Wrote: [ -> ]When the gamepad is not connected the tool tries to create the xinput controller, because it is paired? Is that happening?, because I see the tool reporting the gamepad that is not connected, but paired and the text connecting... Can that be related to the problem? This problem (not showing fake xinput controller, and also not receiving input in the directinput controller) has happened to me for a long time, but was being triggered randomly. Now it happens always both on my pc and laptop...
I definitely think there is something there, to that thought process of the paired Bluetooth controller being viewed as "alive" to DS4 Windows and it tries to pair to it even though the controller may not be on.
Are you on Windows 7 on both your desktop and laptop by chance?
(04-17-2014, 02:58 AM)DaRkL3AD3R Wrote: [ -> ]I definitely think there is something there, to that thought process of the paired Bluetooth controller being viewed as "alive" to DS4 Windows and it tries to pair to it even though the controller may not be on.
Are you on Windows 7 on both your desktop and laptop by chance?
I still want to know if disconnecting the traditional firmware-only way by holding the PS button invokes the problem, too. Maybe the Bluetooth disconnection procedure has to be done differently, but on Windows 8 it is sufficient to request disconnection and then immediately try to write an output report to the device, which causes it to notice the disconnection. Does the Wireless Controller actually disappear when the disconnect is performed? Does it disappear then come back?
(04-17-2014, 02:57 AM)electrobrains Wrote: [ -> ]What version is the problem starting with? You must be getting some kind of error printed to the console output if it is attempting to connect while being paired and never gets anywhere. Are you also using Windows 7?
No error. I'm on windows 7 x64. This is a capture of what happens when I insert my bluetooth dongle:
http://bayimg.com/CANMdAafj
A xbox controller appears (I mean on control panel => created by this tool) and my gamepad is not connected because I haven't pressed ps button and the directinput device is not present. But the gamepad appears on the bluetooth device list, because it is paired.
I will now try versions until I see what is the last version that worked for me (may take I while, I think I have to reboot when the tool gets into a bad state).
(04-17-2014, 03:28 AM)Banyuyaga Wrote: [ -> ]No error. I'm on windows 7 x64. This is a capture of what happens when I insert my bluetooth dongle:
http://bayimg.com/CANMdAafj
A xbox controller appears (I mean on control panel => created by this tool) and my gamepad is not connected because I haven't pressed ps button and the directinput device is not present. But the gamepad appears on the bluetooth device list, because it is paired.
I will now try versions until I see what is the last version that worked for me (may take I while, I think I have to reboot when the tool gets into a bad state).
You should be able to recover by stopping and starting the ScpVBus instance in Device Manager.
The error wouldn't be in the Debug Log, what's in the main window. It would be at the console-level log which I described a page or two ago.
(04-17-2014, 03:39 AM)electrobrains Wrote: [ -> ]You should be able to recover by stopping and starting the ScpVBus instance in Device Manager.
The error wouldn't be in the Debug Log, what's in the main window. It would be at the console-level log which I described a page or two ago.
For the other people that is having this problem. Now that I've tried older versions, I've realized that the controller (at least mine) is getting to a state where it never works again -that is until you reset it-. It was connecting but wasn't showing any device on control panel. I realised this when I tried an older version that worked for me before.
I've tried beta 1: It connects and works correctly. If I press stop, the gamepad light continues blue and on control panel the wireless controller is present but doesn't get any input.
After that tried again beta 7: Also connects and works correctly. Same problem when pressing stop.
What I am getting from this is: sometimes the tool makes the gamepad go bananas (I don't know if just beta6+). Also at least on my pc pressing stop doesn't leave the device working correctly (not sure if related to the above), at least from beta1+. If you want more testing please tell me version(s) and what to test.
(04-17-2014, 04:11 AM)Banyuyaga Wrote: [ -> ]For the other people that is having this problem. Now that I've tried older versions, I've realized that the controller (at least mine) is getting to a state where it never works again -that is until you reset it-. It was connecting but wasn't showing any device on control panel. I realised this when I tried an older version that worked for me before.
I've tried beta 1: It connects and works correctly. If I press stop, the gamepad light continues blue and on control panel the wireless controller is present but doesn't get any input.
After that tried again beta 7: Also connects and works correctly. Same problem when pressing stop.
What I am getting from this is: sometimes the tool makes the gamepad go bananas (I don't know if just beta6+). Also at least on my pc pressing stop doesn't leave the device working correctly (not sure if related to the above), at least from beta1+. If you want more testing please tell me version(s) and what to test.
Okay, stopping and starting while the controller is still connected isn't something I've tried. That does fail for me and give me just "Connecting..." so now I have something to work with for that one particular connection issue.
Edit: Spoke too soon. Not recurring anymore... maybe it's when FFXIV is already running? Trying more....
(04-17-2014, 03:09 AM)electrobrains Wrote: [ -> ]I still want to know if disconnecting the traditional firmware-only way by holding the PS button invokes the problem, too. Maybe the Bluetooth disconnection procedure has to be done differently, but on Windows 8 it is sufficient to request disconnection and then immediately try to write an output report to the device, which causes it to notice the disconnection. Does the Wireless Controller actually disappear when the disconnect is performed? Does it disappear then come back?
I did try this and reported it on page 22.
Basically DS4 Windows doesn't know the controller shut off and holds the state of the Wireless Controller and Xbox 360 Controller indefinitely in a non functional state (obviously). Turning the DS4 back on while the server was still running from before shows nothing happening at all. It never drops the old connection and it never reconnects. The LED stays solid white until I stop and start the server again.
(04-17-2014, 01:29 AM)electrobrains Wrote: [ -> ]Any change with the patch I tried making for you guys in this post?
http://forums.pcsx2.net/Thread-DS4Window...#pid367564
It moves the 1/4 second sleep to before part of the device detachment, in an attempt to deal with the phantom reconnect. I wish I could make this problem happen locally, but I don't have Windows 7 installed.
The only change I noticed was that while that patch was active, the lightbar would turn on and stay white. Everything else acted the same, as far as I could tell.
(04-16-2014, 06:25 AM)Tox Wrote: [ -> ]Unfortunately this wouldn't work as you think it would; this is because the circumstances for being able to hide the DS4 are specific, as many programs will snag all active controllers (Steam, for one). But more to the point, why ever NOT hide it? Until we get a version of DS4Windows that supports Gyro/Accel data there's nothing at all being sent by the DS4 that isn't just XInput data, all the buttons are the same (4 face, 2 shoulder, 2 shoulder triggers, 2 sticks, 2 stick clicks, a d-pad, back, start) so there's honestly no reason to NOT simply use "hide DS4" at all times.
For legacy purposes, mostly. Anything that doesn't support XInput will only be able to use L2
or R2 at any given time - pressing both will respond as nothing as far as they're concerned due to the daft way MS implemented them in the first place. The control is still usable like this, of course, but it reminds me of even older days when 6-or-more-button joysticks used the X and Y axis of what should have been joystick 2 in order to "fake" having extra buttons, despite USB not actually having a 4-axis, 4-button limitation.
Most emulators and anything which pre-dates XInput are far more friendly to the DS4 design, which means you're better off not hiding it for these. Older simulators also benefit from the separate axes of the DS4's triggers instead of a single combined one. Hence my desire for a quick toggle.