First of all, run from an ADMINISTRATOR command prompt, because if DS4Tool.exe runs with administrator permission and you did not launch CMD.EXE with administrator permission, it is not going to be able to save the output to a file. The "> filename" is a standard output redirect. It's the only way to get the console output when DS4Tool.exe puts itself in the background as a GUI application and disconnects from the CMD.EXE that launched it.
I have no idea how you would get a crash running it from the command line. No one has ever reported such a thing. And like I said, if you want to verify that idle timeout isn't somehow occurring, hold a trigger or thumbpad or anything else and that will prevent any otherwise-configured idle disconnection timeout. I can't make your problems occur on Windows 8.1, so you absolutely have to reproduce them and show me the errors if I am to be able to help.
I'm posting a very minor update here instead of making a Beta 6 because I really want to figure out why some people are having controllers immediately disconnect before I make another minor improvement release. The changes are just to the UI: when minimized to the notification area (system tray), the tooltip will show you controller charge status; you cannot accidentally have extra Options/Custom Mapping screens, and they will be automatically closed if the controller you are editing the options for disappears.
Okay, so I did the command prompt thing. I ran both cmd and DS4Tool as administrator, and put "> log.txt" at the end to get the output. This is the text of log.txt:
A4:15:66:65:99:BF 2014-04-14T23:16:32.4103021Z> start
A4:15:66:65:99:BF 2014-04-14T23:16:32.4493043Z> power subsystem octet: 0x09
Cancelling IO
Cancelled IO
Close fs
Close sh
Device is closed.
The program immediately gave me a "stopped working" message, and I had to close it. And yeah, I've only experienced these problems with any version after the original 1.3 RC3, which is really weird. It's not a HUGE deal, since I can just start the program manually and then everything works fine, but I do think it's really odd that the wireless connection doesn't work if the program is already going when the controller is started.
This is all in Windows 7 x64, by the way.
(04-14-2014, 01:50 AM)shinra358 Wrote: [ -> ]To be honest, I don't see the point in this. It being used as a mouse is just fine as is. If the ps4 can't do it, this shouldn't do it either. The touchpad modes I don't see the point of either. Standard mode should be enough. How on earth can anybody remember what mode they are on when they are in-game anyway? Just seems like way too much. I'd rather focus on full functionality for the rest of the functions on the controller so it can become a complete simple driver.
I'd like to map the touchpad to controller to get closer to the PS4 experience, mapping the touchpad single touch to xbox's back and the share button to F5 (it's what I set to take steam screenshots). As I said before, the only 2 modes I can see useful is standard and button mode, as well as just mouse movement of the touchpad disabled but the actions still possible on press. Button mode isn't really useful in games with xinput, but when the controller is fully mapped to the keyboard and mouse, it's useful for certain games like Civilization.
(04-15-2014, 01:22 AM)pedrovay2003 Wrote: [ -> ]Okay, so I did the command prompt thing. I ran both cmd and DS4Tool as administrator, and put "> log.txt" at the end to get the output. This is the text of log.txt:
A4:15:66:65:99:BF 2014-04-14T23:16:32.4103021Z> start
A4:15:66:65:99:BF 2014-04-14T23:16:32.4493043Z> power subsystem octet: 0x09
Cancelling IO
Cancelled IO
Close fs
Close sh
Device is closed.
The program immediately gave me a "stopped working" message, and I had to close it. And yeah, I've only experienced these problems with any version after the original 1.3 RC3, which is really weird. It's not a HUGE deal, since I can just start the program manually and then everything works fine, but I do think it's really odd that the wireless connection doesn't work if the program is already going when the controller is started.
This is all in Windows 7 x64, by the way.
Thank you for your help trying to track this down. I think I've just fixed the problem, so try out Beta 6!
(04-15-2014, 02:16 AM)Jays2Kings Wrote: [ -> ]I'd like to map the touchpad to controller to get closer to the PS4 experience, mapping the touchpad single touch to xbox's back and the share button to F5 (it's what I set to take steam screenshots). As I said before, the only 2 modes I can see useful is standard and button mode, as well as just mouse movement of the touchpad disabled but the actions still possible on press. Button mode isn't really useful in games with xinput, but when the controller is fully mapped to the keyboard and mouse, it's useful for certain games like Civilization.
Button Mode may be more useful for you now that you can control which buttons are bound to mouse keys. You can also bind them to controller keys or choose "Unbound" to remove them entirely. I did see some people unhappy with the default choices for button mode, so now it's fully-configurable.
(04-13-2014, 07:05 AM)knewknow Wrote: [ -> ]Is there any way to map controller buttons to the touch pad button?
The newest version, 1.0 Beta 6, gives you this ability in Button Mode. I have yet to go back and adapt Standard Mode and Drag Mode to support it, because all of this work has taken considerable code rewriting, but you now have full control over all the mappings in Button Mode's Button Lock.
I've just stumbled upon this thread while setting up a DS4 on my PC. Signed up to ask a small request, if you don't mind, Electrobrains:
Is it at all possible to add configuration to toggle hiding the DS4/DirectInput portion of the controller, or at least a pre-defined shortcut on the gamepad (similar to the touchpad toggle)? I haven't played around with much yet but two of the three titles I've tried - Saints Row IV and SSFIV - both don't play friendly with having the DS4 portion visible. SR4 almost works save for the vertical axis on both sticks being reversed, while SSFIV allowed me to press start on the same controller a second time to add a second player.
As I play a lot of legacy titles I'd rather leave the DS4 visible since it's more useful so having a quick toggle for more modern software would be handy, even if it cannot be manually reconfigured. Better still would be having the lighting able to change colours to reflect which mode it's currently in but I can understand if that just sounds greedy.
Cheers.
(04-15-2014, 08:50 AM)Thalyn Wrote: [ -> ]I've just stumbled upon this thread while setting up a DS4 on my PC. Signed up to ask a small request, if you don't mind, Electrobrains:
Is it at all possible to add configuration to toggle hiding the DS4/DirectInput portion of the controller, or at least a pre-defined shortcut on the gamepad (similar to the touchpad toggle)? I haven't played around with much yet but two of the three titles I've tried - Saints Row IV and SSFIV - both don't play friendly with having the DS4 portion visible. SR4 almost works save for the vertical axis on both sticks being reversed, while SSFIV allowed me to press start on the same controller a second time to add a second player.
As I play a lot of legacy titles I'd rather leave the DS4 visible since it's more useful so having a quick toggle for more modern software would be handy, even if it cannot be manually reconfigured. Better still would be having the lighting able to change colours to reflect which mode it's currently in but I can understand if that just sounds greedy.
Cheers.
It sounds an awful lot like you're describing the "Hide DS4 Controller" feature that's there as a checkbox on the main window. If you check it, DS4Windows will attempt to acquire exclusive access of the DirectInput/HID device and thus lock out any other programs from also accessing it, so they can only access the Xinput.
Beta 6 unfortunately didn't fix the "Connecting..." bug or the other bug I get, which is after the first time I disconnect my controller and try to reconnect it later on during the same boot cycle, it refuses to hook in and create an XInput device.
I have all required software installed. DS4 Tool v1.2.2 works flawlessly in this regard. I can disconnect my controller, stop the tool server. Reconnect my controller to Bluetooth and start the server again and it always hooks to the controller. Never a flaw.
I would love to use the latest and greatest, but after that old version, it just isn't reliable anymore.
I decided to record the events from a fresh boot to show exactly what is broken for me.
(04-15-2014, 09:25 PM)DaRkL3AD3R Wrote: [ -> ]Beta 6 unfortunately didn't fix the "Connecting..." bug or the other bug I get, which is after the first time I disconnect my controller and try to reconnect it later on during the same boot cycle, it refuses to hook in and create an XInput device.
I have all required software installed. DS4 Tool v1.2.2 works flawlessly in this regard. I can disconnect my controller, stop the tool server. Reconnect my controller to Bluetooth and start the server again and it always hooks to the controller. Never a flaw.
I would love to use the latest and greatest, but after that old version, it just isn't reliable anymore.
I decided to record the events from a fresh boot to show exactly what is broken for me.
Can you figure out the EXACT first version of DS4Windows that incurs the problems? The console output that pedrovay2003 posted seems to indicate that Beta 6 should fix his disconnection. I could really use the console output from your failed connections. The rapid disconnection and reconnection seems like a race condition, and it would really help to see the exact timestamps down to the sub-second values. If I could reproduce the problem then I could do it myself :/
I expect that the reason it stops working completely is the ScpVbus driver getting messed up, and if you restarted that device in Device Manager that the Xinput would work again. I think I need to see the debug output on the console to determine why you would be getting an immediate disconnect. If there isn't an error, like with pedrovay2003's log, there should at least be an indication what else did happen.