Not for now.
The space is little, so I will need to change the colorpicker to a custom solution first.
The space is little, so I will need to change the colorpicker to a custom solution first.
Noticed a possible bug with writing colors to the Pro Controller:
I had set it to Neon Blue and that worked just fine. I paired it to the Switch and I was able to see the changes properly. However, then I decided I wanted to change the color again, but to a non-predefined color. That did not appear to work. It kept reverting back to Neon Blue.
I then set it to Neon Red and that worked, which I found odd. At first I thought: "Huh, maybe the data isn't getting sent correctly for custom colors? Perhaps some kind of data transformation isn't being applied correctly?"
After setting it to Neon Red, I tried my own color again and it worked.
So, not really sure what was up with that, but if anyone else is having problems try setting an "official" color first then try again. That may cause it to work properly for you.
I had set it to Neon Blue and that worked just fine. I paired it to the Switch and I was able to see the changes properly. However, then I decided I wanted to change the color again, but to a non-predefined color. That did not appear to work. It kept reverting back to Neon Blue.
I then set it to Neon Red and that worked, which I found odd. At first I thought: "Huh, maybe the data isn't getting sent correctly for custom colors? Perhaps some kind of data transformation isn't being applied correctly?"
After setting it to Neon Red, I tried my own color again and it worked.
So, not really sure what was up with that, but if anyone else is having problems try setting an "official" color first then try again. That may cause it to work properly for you.
Last edited by d4mation,
Hmm that's strange. The write algorithm is the same for joy-cons except some extra checks.
i checked it again and there's no problem with data conversions. Also tried many different ways to write my colors to my joy-con and it worked.
I assume it's a bad signal.
This can happen:
It checks that the device is still connected.
If OK, proceeds to send the write command
If the signal is bad, the device can receive a partial packet and reject it.
And after it sends read commands which are not received partially, so that's why it successfully changes the preview to your old color.
This can be fixed by implementing a write/read check to make sure that the color was written and the result will be always a success.
I didn't want to do this because it involves a write command and I think it's better for user to try again manually..
Will see. Maybe I will implement this.
That may be. I was doing this from within a VM since I don't have access to a Windows computer at the moment, so possibly things got wonky for the Bluetooth hardware passing from Host->Guest. I got it to work in the end like I said though
- Joined
- Jul 30, 2017
- Messages
- 374
- Trophies
- 0
- Age
- 30
- Location
- In a dark cave
- Website
- thomas.dusbite.se
- XP
- 456
- Country
Never use a vm for usb / bluetooth purposes. It will ALWAYS end BADLY. i've killed a usb drive that way..That may be. I was doing this from within a VM since I don't have access to a Windows computer at the moment, so possibly things got wonky for the Bluetooth hardware passing from Host->Guest. I got it to work in the end like I said though
If the vm would've got a hiccup you could've jinxed your controller.
Also, if you only have a mac, consider using bootcamp to dualboot windows.
Last edited by PotatisKnug,
I've never had trouble using a VM personally. With hardware virtualization, the hiccup risk isn't much worse than running native.
Yeah, I've never had an issue either. VMs have gotten pretty solid anymore and if you pass through the MacBook's built-in Bluetooth (Which shows as a USB device) and then install the same drivers Bootcamp uses it appears to work 100% the same. I was just being impatient and used my MacBook as I didn't want to wait until I had gotten home to use my Windows Desktop.
So, it could have been caused by the VM. I'm not going to rule it out. Appears to have worked overall in the end though as I was able to change the color of my Pro Controller a few times with no issue.
The good thing is that it's not something that you will use all the time, so it will not be so frustrating if the device doesn't get the write packet.
I made it that way, so the chosen color is not lost and you just open/ok the color dialog and write again.
In the next version I will not add an automatic retry. I still prefer it manually for bad signal/adapter cases. So if it fails, user will be confused and move his device closer to the BT adapter and not another broken packet will reach the device. I will add a hint text also.
Finally, I'm working on a SPI backup validation and restore feature for next version. It will also provide only color, factory/user calibration and other sector restore options.
It will also check if the backup is from your device and then let you choose if you wan to restore it.
I made it that way, so the chosen color is not lost and you just open/ok the color dialog and write again.
In the next version I will not add an automatic retry. I still prefer it manually for bad signal/adapter cases. So if it fails, user will be confused and move his device closer to the BT adapter and not another broken packet will reach the device. I will add a hint text also.
Finally, I'm working on a SPI backup validation and restore feature for next version. It will also provide only color, factory/user calibration and other sector restore options.
It will also check if the backup is from your device and then let you choose if you wan to restore it.
Last edited by CTCaer,
Not yet but keep an eye in this thread because I plan to. The only problem is that most logic is inside the form class and it's a mega mess. I'll try to add as many comments as possible in the source though.
Yes.
You can even put a funny max 16 characters string like @shinyquagsire23 did:
But it's debatable if it should be easily accessible...
Note: Still the MAC address cannot be changed. So it's still identifiable.
Unlikely, and for a good reason: Third-party controllers.
Nintendo would have a massive PR disaster if they banned people for using third-party controllers that had different color settings built in, so there's basically no chance of them doing anything about hacking the color settings on official controllers, either.
Yes.
You can even put a funny max 16 characters string like @shinyquagsire23 did:
But it's debatable if it should be easily accessible...
Note: Still the MAC address cannot be changed. So it's still identifiable.
How did you change it tough? did you mean its debatable if you gonna add this feature ?
It's as easy to change as the colors and other things.
Yes, it's debatable if I will add it in the near future. Don't know yet.
Other than that, it should also be a universally wanted feature in GBATemp.
EDIT: Let's say, what a user is going to do if he didn't do a backup first?
Maybe I can make it difficult to accomplish, but still...
Yes, it's debatable if I will add it in the near future. Don't know yet.
Other than that, it should also be a universally wanted feature in GBATemp.
EDIT: Let's say, what a user is going to do if he didn't do a backup first?
Maybe I can make it difficult to accomplish, but still...
Last edited by CTCaer,
Similar threads
