08-25-2014, 12:19 AM (This post was last modified: 08-25-2014, 12:21 AM by Xaero.)
(08-24-2014, 01:06 PM)jhebbel Wrote: Ive yet to hear anybody getting the Toshiba stack to work for the simple fact that the Toshiba stack does not use MAC addresses for connected HID devices, something that is a MUST for us, and it is this exact lack of MAC that throws the Index out of bounds error, in our case we plain englished the error to read Unsupported BT stack or driver, but they mean the same exact thing. The only other thing I can think of is that you are getting high levels of interference causing the latency (BT operates on the same band as WiFi and many other wireless protocols). The other reason I tended to lean to it being the device being incompatible is that in the log you sent, one thing it includes is the PID of the BT dongle, upon referencing it this is what I found: http://www.modem-help.co.uk/Broadcom/chi...2-USB.html Could be a typo though
Interesting - then why is it the original DS4tool successfully detects and maps the controller, and lists it's MAC Address with the Toshiba stack installed? I've already reverted to the Windows stack, for the time being - but I've verified against my motherboard manufacturer this is indeed a 2.1+EDR device. It's an Asus Rampage III Extreme. Either way I'm moving to a different bluetooth dongle. Shame we can't add support for the Toshiba stack as apparently its pretty robust (from what I've read its lower latency etc...)
Edit:
Would it be possible to detach the color settings from the mapping profiles?
(08-25-2014, 12:19 AM)Xaero Wrote: Interesting - then why is it the original DS4tool successfully detects and maps the controller, and lists it's MAC Address with the Toshiba stack installed? I've already reverted to the Windows stack, for the time being - but I've verified against my motherboard manufacturer this is indeed a 2.1+EDR device. It's an Asus Rampage III Extreme. Either way I'm moving to a different bluetooth dongle. Shame we can't add support for the Toshiba stack as apparently its pretty robust (from what I've read its lower latency etc...)
Edit:
Would it be possible to detach the color settings from the mapping profiles?
(08-25-2014, 12:40 AM)jhebbel Wrote: What do you mean detach?
Make them a separate entity entirely, as well as a profile feature.
For example, I could set the default colors to one setting, and then have a profile either A) use the default settings or B) override them.
Example scenario:
By default, controllers that are charging would be RED when low on power and gradually turn green. A fully charged controller's light would be off, and a discharging controller would be off (to save power). A dying controller would flash red.
Then, for a profile I could select to leave all colors default, and then override just the discharge/fully charged color - Blue for P1, Pink for P2, Orange for P3, White for P4. (with one profile per player) or any combination of options. This way we don't have to create a profile to change colors, and color changes can be made more dynamic.
(08-25-2014, 10:39 PM)Xaero Wrote: Make them a separate entity entirely, as well as a profile feature.
For example, I could set the default colors to one setting, and then have a profile either A) use the default settings or B) override them.
Example scenario:
By default, controllers that are charging would be RED when low on power and gradually turn green. A fully charged controller's light would be off, and a discharging controller would be off (to save power). A dying controller would flash red.
Then, for a profile I could select to leave all colors default, and then override just the discharge/fully charged color - Blue for P1, Pink for P2, Orange for P3, White for P4. (with one profile per player) or any combination of options. This way we don't have to create a profile to change colors, and color changes can be made more dynamic.
Im not seeing the benefit, how would that be better than just having 2 profiles if you want to have 2 different color schemes?
08-25-2014, 11:41 PM (This post was last modified: 08-25-2014, 11:42 PM by Sleix.)
(08-25-2014, 11:14 PM)jhebbel Wrote: Im not seeing the benefit, how would that be better than just having 2 profiles if you want to have 2 different color schemes?
I think what he means is he wants to change the default color scheme that every new profile is based off of.
I kind of agree, I have my own scheme that I always have to change to from default every time I make a new profile. Having this would cut out on the annoyance factor.
(08-25-2014, 11:41 PM)Sleix Wrote: I think what he means is he wants to change the default color scheme that every new profile is based off of.
I kind of agree, I have my own scheme that I always have to change to from default every time I make a new profile. Having this would cut out on the annoyance factor for some people.
You can duplicate profiles once you have one set up
(08-25-2014, 11:44 PM)Sleix Wrote: Yes, but that's more of a workaround. Not really a solution.
It isn't urgent by any means, but it'd be nice to have.
I guess I still dont get the issue then, the built in application default profile is meant to be a failsafe and is what other profiles are based off of when first created, if its editable it kinda defeats the purpose, as it stands the only difference between having a user editable default profile and duplicating a profile is which button you click on the profile screen, there is no extra steps beyond that, but as I understand the OP he wants lightbar settings to be a completely separate and assignable predetermined configuration, I don't think this would go over very well as the macros are set up this way and I have had several requests to try to get them more tightly integrated into the actual profile rather than as a separate entity.
