..:: PCSX2 Forums ::..

(11-20-2015, 11:01 PM)Nefarius Wrote: [ -> ]Since I'm not available this weekend I'd like to present to you a new release which will hopefully detect all your genuine DS3s flawlessly.

changing buttons still doesn't work. :/

(11-20-2015, 11:01 PM)Nefarius Wrote: [ -> ]Since I'm not available this weekend I'd like to present to you a new release which will hopefully detect all your genuine DS3s flawlessly.

Glad to hear you are finding a way to detect genuine DS3 as genuine
Gotta test this new release soon, for now i'm using v1.5.5794.0 because it is the most stable one i've found so far

BTW, is there any way to detect my DS3 as the xbox controller nº 2?
There are some games that both keyboard and xbox controller nº 1 act as player 1 at the same time (like rocket league) and i want to make my controller to work as player 2
For now i'm using KinoConsole to generate another fake xbox controller so there can be 2 of them, but it's kind of annoying

(11-20-2015, 11:01 PM)Nefarius Wrote: [ -> ]Since I'm not available this weekend I'd like to present to you a new release which will hopefully detect all your genuine DS3s flawlessly.

Working fine now via bluetooth and original DS3. Does not long get recognized as fake one and rumble and led via Bluetooth works flawlessly.
Thanks for your efforts

Problem carried over to the legacy server

But I saw in the logs that it is indeed receiving disconnect signal during gameplay

Also saw it getting an unknown key command as well.

During this log, I was in DCUO tanking a boss.

Controller disconnected from bluetooth during the fight.

Controller should be forced to stay connected unless I enter a passcode to disconnect it if necessary.   Ignore all disconnect requests unless a passkey is entered and authorization is granted.

Maybe a little extreme but if I wanted to disconnect my controller, I'll just pull the bluetooth or enter my passkey or just let the thing timeout and go to sleep.

No need for it to randomly accept disconnect request

(11-21-2015, 08:38 PM)bchiemara Wrote: [ -> ]Problem carried over to the legacy server

But I saw in the logs that it is indeed receiving disconnect signal during gameplay

Also saw it getting an unknown key command as well.

During this log, I was in DCUO tanking a boss.

Controller disconnected from bluetooth during the fight.

Controller should be forced to stay connected unless I enter a passcode to disconnect it if necessary.   Ignore all disconnect requests unless a passkey is entered and authorization is granted.

Maybe a little extreme but if I wanted to disconnect my controller, I'll just pull the bluetooth or enter my passkey or just let the thing timeout and go to sleep.

No need for it to randomly accept disconnect request

There is no such thing as a "disconnect request", no game has the abilities/rights to request a controller to disconnect, only the user has if you press L1 + R1 + PS for a few seconds. Your screenshot shows an exception which is not good, submit your log pack please, that's a different problem.

(11-21-2015, 08:45 PM)Nefarius Wrote: [ -> ]There is no such thing as a "disconnect request", no game has the abilities/rights to request a controller to disconnect, only the user has if you press L1 + R1 + PS for a few seconds. Your screenshot shows an exception which is not good, submit your log pack please, that's a different problem.

I know that, what I am suggesting is it may be initiating the PS3 (hold PS button ->shut off controller) command based on a combination of requests from the game.

In my experience, variables (if they don't throw a null exception or object reference) can sometimes do odd things if something is overlooked or a particular user or game input/command is combined in a way that was unforseen at the time the program was written.

From the console via PS button there is a disconnect request command.

I found this

<log4j:event logger="ScpService.Ds3Service" timestamp="1447902165062" level="FATAL" thread="1"><log4j:message>An unhandled exception occured: System.NullReferenceException: Object reference not set to an instance of an object.
   at HidSharp.ReportDescriptors.Parser.ReportDescriptorParser.ParseMain(MainItemTag tag, UInt32 value)
   at HidSharp.ReportDescriptors.Parser.ReportDescriptorParser.Parse(EncodedItem item)
   at HidSharp.ReportDescriptors.Parser.ReportDescriptorParser.Parse(IEnumerable`1 items)
   at HidSharp.ReportDescriptors.Parser.ReportDescriptorParser.Parse(Byte[] buffer)
   at ScpControl.Usb.UsbDevice.Start()
   at ScpControl.Usb.Ds3.UsbDs3.Start()
   at ScpControl.Usb.UsbHub.Notify(Notified notification, String Class, String path)
   at ScpControl.RootHub.Notify(Notified notification, String Class, String path)
   at ScpService.Ds3Service.ServiceControlHandler(Int32 control, Int32 type, IntPtr data, IntPtr context)
   at System.ServiceProcess.NativeMethods.StartServiceCtrlDispatcher(IntPtr entry)
   at System.ServiceProcess.ServiceBase.Run(ServiceBase[] services)
   at ScpService.Program.Main(String[] args)</log4j:message><log4jroperties><log4j:data name="log4jmachinename" value="LCARS" />

---

Been programming since 1996... I was just guessing in my immediate previous post, but looks like I was on the right track.

(11-21-2015, 11:38 PM)bchiemara Wrote: [ -> ]I know that, what I am suggesting is it may be initiating the PS3 (hold PS button ->shut off controller) command based on a combination of requests from the game.

In my experience, variables (if they don't throw a null exception or object reference) can sometimes do odd things if something is overlooked or a particular user or game input/command is combined in a way that was unforseen at the time the program was written.

From the console via PS button there is a disconnect request command.

Again; there is no way any game could request the controller to disconnect since I do not interpret anything else but rumble requests via XInput API. If the PS can turn the controller off that's fine; the software doesn't. I should know by now

And no; in a managed language like C# there is no unexpected behavior on null Null-references; the CLR throws an exception you can handle or ignore. If you ignore it, the program crashes.

(11-21-2015, 11:53 PM)Nefarius Wrote: [ -> ]Again; there is no way any game could request the controller to disconnect since I do not interpret anything else but rumble requests via XInput API. If the PS can turn the controller off that's fine; the software doesn't. I should know by now

A closed mind is not a wise one.  You have gone through all your functions and their returns and any error traps that interact with those returns to ensure that they are not returning the wrong values?

I troubleshot a program this morning that had over 100 try catch statements and found one out of those that returned a 1 instead of a 0 which was causing an intermittent error to disable one of the modules that runs on a timer.

User input is one of the most difficult things to control the outcome of in software designed to interpolate those inputs into instructions the computer hardware can do something with.

Human error (especially when working with thousands of lines of code that you have to visualize each path and interaction for the desired outcome) has caused many a patch to be written.

(11-21-2015, 11:59 PM)bchiemara Wrote: [ -> ]A closed mind is not a wise one.  You have gone through all your functions and their returns and any error traps that interact with those returns to ensure that they are not returning the wrong values?

I troubleshot a program this morning that had over 100 try catch statements and found one out of those that returned a 1 instead of a 0 which was causing an intermittent error to disable one of the modules that runs on a timer.

User input is one of the most difficult things to control the outcome of in software designed to interpolate those inputs into instructions the computer hardware can do something with.

Human error (especially when working with thousands of lines of code that you have to visualize each path and interaction for the desired outcome) has caused many a patch to be written.

No I haven't because I don't need to; the XInput API has no request for a controller shut-off and since the communication between the game, the Xbox emulator driver and the wrapper service is done via official Microsoft XInput API calls the error must be something else since there simply is no way the game or whatever application is "requesting" the controller to shut off.