Version 3.2.8

[Ryochan7]

Initial DualSense Edge support, fixes

.NET Runtime x64
https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/runtime-desktop-6.0.10-windows-x64-installer
.NET Runtime x86
https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/runtime-desktop-6.0.10-windows-x86-installer

• Corrected list display of Press Key special action regarding Toggle status
• No longer enforce en-US values for Custom Bezier curve string. Might be a mistake
• Fixed saving of options for Macro special action. Model problem
• Check tray icon has been created before trying to show notification
• Fixed DS4KeyType check for shift modifier when multiple flags are used
• Ignore None KeyType flag for shift modifier
• Simplify shift modifier key type saving
• Fixed loading of Gyro Mouse Joystick trigger eval condition
• Added extra precautions when disconnecting from FakerInput
• Adding initial DualSense Edge support. Contribution by dezerving
• Updated zh-cn translatation. Contribution by jyc001
• Grab firmware info for DualSense controller

---

This discussion was created from the release Version 3.2.8.

[IHunterFang]

I'm getting an error message that says: The supplied instance wasn't found.(Parameter'instanceld').

[P-G19]

Tried building myself with this release still no success with Gyro.
When free, if possible, can someone check Adding Qixiong/ShanWan wire ps4 controller... I opened the issue a few months ago.

#2702.

I know I might get muted or something but it was worth a try.. Sorry for bothering.

[mika-n]

@Ryochan7 Hi. Nice to see you are back in working with DS4Windows. I saw the following comment in the latest "What's new" list and one comment about it: "No longer enforce en-US values for Custom Bezier curve string. Might be a mistake"

The logic behind this using "en-US" localization when writing and reading bezierCurve decimal values as a string was a fix to localization bug. For example here in Finland the default decimal separator char is "," comma and not "." dot like in US. Now, if decimal values are written out as string using the current default localization then in theory something like this could happen:

• A profile file is saved in PC using US localization and decimal sep "." char
• The profile file is sent to someone using Finnish/Swedish localization.
• When DS4Windows app there tries to read the profile file in a PC using Finnish/Swedish lcoalization then string-to-float conversion would expect the string to use "," as a decimal sep char if the conversion uses the default PC specific localization setting.
• String-to-float conversion would fail and DS4Windows throws an exception because the profile file had "." as decimal sep and not "," char (or value is wrong if "." dot char is interpreted as thousand separator and not as decimal separator in Finnish/Swedish locale).

The logic to enfoce en-US both at profile writing and reading time was a solution to this problem case (which was the case when I received profile files for testing from users who had a localization setting using "." as decimal separator char). When the app enforced the decimal format in a profile file then everything worked regardless of PC specific localization settings.

[methbkts]

Same in France

[Dinir]

Is special action handling fixed in this version?