SC Controller is a pretty essential standalone user-mode driver and configuration UI for working with the Steam Controller, and it just got the first stable update in some time. It enables you to use your Steam Controller fully outside of Steam, and it works really damn well.
While the developer has been working on an experimental c port, others have submitted a few essential fixes so a new release went up. One major issue is with most modern Linux distributions moving to a major Python update, which broke SC Controller. Thankfully, as of the v0.4.8 release that's not so much a problem with the AppImage now working on Ubuntu 20.04 and comparable distributions.
Testing on an up to date Arch Linux install (using EndeavourOS), the AppImage worked perfectly!
Additionally, this update all pulls in these changes and fixes:
- Hip fire style action for trigger
- Added DualShock 4v2 over Bluetooth udev rule
- Button labels on Gyro Tilt mixed up
- Cemu hook not working with Dolphin Emulator
- Radial menu drawing broken on HDPI displays
- Gesture recognition not working with DS4
- "Confirm menu selection by releasing" not working at all
- Moving STICK and LPAD at once can make buttons stuck
- Issues with non-ascii (and especially Chinese) characters in profile name
You can find it on GitHub.
Problem: conflicting requests
- nothing provides gnome-python2-rsvg needed by sc-controller-0.4.8-10.1.x86_64
- nothing provides pylibacl needed by sc-controller-0.4.8-10.1.x86_64
Quoting: AkienFor the reference, there's a WIP Python 3 port
Will that possibly be upstreamed? Or is it more likely upstream will abandon Python altogether?
Does anyone know if it works with Stadia or GeForce NOW?
Quoting: NoStDoes anyone know if it works with Stadia or GeForce NOW?
Yes, it works with both.
Quoting: PhlebiacNice to see it getting updates and a new release. The Fedora builds only go up to 30, and it doesn't have the required dependencies in 33 - looks like it still needs obsolete Python stuff?
Problem: conflicting requests
- nothing provides gnome-python2-rsvg needed by sc-controller-0.4.8-10.1.x86_64
- nothing provides pylibacl needed by sc-controller-0.4.8-10.1.x86_64
Quoting: AkienFor the reference, there's a WIP Python 3 port
Will that possibly be upstreamed? Or is it more likely upstream will abandon Python altogether?
Easiest solution would be to use the Snap that /u/mcphail seems to have built or the AppImage. Both are cross-distro solutions either already working for you or easy to set up.
Quoting: grigiI've had really good experience with AppImage, its a great generic solution for stand-alone desktop apps.
It would be nice to manage them as apps that get updates, etc... but it's currently the lowest friction way to get a complex desktop app available for any Linux distro.
Lowest friction for developer - yes.
The extra effort of maintenance has been shifted from dev to user instead.
Quoting: mcphailThanks for the confirmation!Quoting: NoStDoes anyone know if it works with Stadia or GeForce NOW?
Yes, it works with both.
Quoting: CatKillerQuoteOne major issue is with most modern Linux distributions moving to a major Python update, which broke SC Controller. Thankfully, as of the v0.4.8 release that's not so much a problem with the AppImage now working on Ubuntu 20.04 and comparable distributions.Python 3 has been out for 12 years, and Python 2 has been EOL for a year already. Containerisation is useful in its own right, but using it to limp along with a dead Python version doesn't seem like a great plan for something that's under active development.
The problems created in the move from Python 2 to Python 3 seem to be one of the reasons Kozec is porting SCC over to C, and that's why he's not focused on creating a Python 3 port too. However, as Akien stated above, there is a functional Python 3 port of SCCavailable now thanks to the Community!
Quoting: NoSTDoes anyone know if it works with Stadia or GeForce NOW?
Liam would be able to say for sure regarding Stadia, but I'm going to say that it very probably does. SC-Controller (SCC) operates independently of game clients and games and can tell those games that whatever the Steam Controller input is, it's an input the game is expecting. Since SCC is available as an Appimage, it's nothing to download and tryout with Stadia, etc. Give it a try!
P.S. Full disclosure, I'm an SCC Patreon supporter from way back. If you like (or more likely love) Kozec's SC-Controller project and (like me) can't code or figure out Github, please consider financially contributing whatever you can.
You can support him at Liberapay, thru Patreon (like me), or directly via a donation at Paypal.
Last edited by Nanobang on 11 December 2020 at 4:23 pm UTC
Quoting: SpirimintOh wow, with the new Version finally its working. But it has way less options as the steamoverlay. Will be hard to setup a game with not all of these options I got so used to use one button for different actions and also using the action layers etc.
tl;dr I'm an SC-Controller fanboy.
SCC may have fewer options than Steam's client, or it may not. I don't honestly know, but I think SCC may have more. A lot of what you see in Steam's UI is available in SCC, but you might have to do it differently. In many ways, Steam's UI is to Kozec's SC-Controller as Windows is to Linux: the first (Steam's) is simpler but is less customizable, fewer granular choices, and the second (Kozec's) is way more choices, but isn't as dumbed-down.
For example, the Activators in Steam's UI (Regular, hold, start press, etc.) are easily done in SCC, but are set-up in either mode-shift or macros. Action sets are done just by making another profile, otherwise it's the same, it's just that SCC doesn't keep track of that in the UI.
But SCC lets me do so many things Steam's client can't. In Steam an input can only have one mode shift. In SCC I can add as many mode-shifts to a button as I want: Press 'A' and pull the trigger, one thing happens; press 'B' and pull the same trigger, something else happens. Mode-shift combinations on the SCC are exponentially greater than Steam's UI. That alone would be enough for me to count SCC the better of the two.
Rings on pads are more configurable, so that more than just buttons can be placed in the rings. I'll give you an example based on my own basic Payday 2 SCC profile. Normally the Rpad is a trackball mouse to control a camera. On top of this I add a mode-shift so that when I click the RPad it becomes a DPad where LEFT is reload, UP is change weapon, DOWN is drop weapon, RIGHT is flashlight, and center is grenade. All that is doable in Steam's client, but with SCC I've added more. To more easily interact with Payday's menus, I added a mode shift so when I press the back button the very edge of the Rpad becomes a circular trackpad mouse-wheel and the center becomes an Arrow Dpad.
Once again, an open source solution outshines a proprietary one.
Last edited by Nanobang on 11 December 2020 at 5:13 pm UTC
Quoting: Liam DaweQuoting: CatKillerPython 3 has been out for 12 years, and Python 2 has been EOL for a year already. Containerisation is useful in its own right, but using it to limp along with a dead Python version doesn't seem like a great plan for something that's under active development.Well if it works, and it keeps useful applications alive, there's nothing wrong with it and there's people who have issues with the newer Python version of SC Controller. No need to have one solution forced on everyone, options are good for those who need it :)
In the current world though that's not a good idea. With vulnerabilities and malicious actors moving faster than most communities can keep up running out of date software is dangerous. It gets even worse if you live in a home where you and/or others are working from home, as a particularly bad vulnerability could give an attacker the ability to take over a PC and silently monitor the local network, potentially gaining access to a corporate network by getting VPN credentials with a MITM attack.
This is also why Windows Kernel-level Anti-Cheat is so dangerous as well.
See more from me