Scratch has a lot of extensions for things like lego, makey makey, generally some strange input types that aren't usable for a lot of projects.
adding support for controllers would help lots of projects, especially ones that work well with analog input, like driving games,

when button [a v] pressed :: extension hat // buttons include ABXY, dpad, L, R, L1, R1, L2, R2, L stick, R stick (analog sticks can be clicked down on some controllers)
// this could also have blocks dropped in as an input, just like you can for key pressed blocks.
// when dropping in blocks, it could take the button number ids, meaning that even unsupported controllers could work (to an extent)

when [L2 v] distance [= v] (100) % :: extension hat // input options are triggers and all stick movement (shown on next blocks)
// this block could also have blocks dropped in and take axis ids, just like the button blocks.

[normal v] rumble for (1) secs until done :: extension stack // different rumble strengths

[normal v] rumble for (1) secs :: extension stack // doesn't pause script to rumble

[normal v] rumble :: extension stack // just keeps rumbling until stopped

stop rumble :: extension stack

<button [a v] pressed? :: extension> // (can drop in blocks, like above)

([left v] stick x :: extension)

([left v] stick y :: extension)

([left v] stick direction :: extension)

([left v] stick distance :: extension) // how far the stick is from the center

([L2 v] distance :: extension) // how far the trigger is pushed down (can drop in blocks, like above)

triggers are LT, RT, L2, R2, or ZL, ZR. note that switch controllers (if they get support) just have triggers (ZL and ZR) be at either 0% or 100% since they aren't analog.
if possible, it would change these depending on the controller currently connected, but if it can't, it could just use positions for ABXY (like the switch does for single joycons), and just use L1/L2 (there's only 2 of them, anyone can figure out which is which easily just by trying it)

another thing that could be done is adding support for multiple controllers, for thigns like multiple players. with would modify the blocks to add player numbers from 1-4 (this would be the same as the player indicator on the controller) and add these blocks.

when player [1 v] connected :: extension hat

when player [1 v] disconnected :: extension hat

<player [1 v] connected? :: extension>

multiple controllers should probably be a togglable option (if added) because it does make things much more complicated.

FAQ:
Q: why not use joytokey or other controller remapping programs?
A: these programs don't run on all devices, you often have to pay for them, and it doesn't support proper analog movement.

Q: what about wii remotes?
A: Most operating systems don't support wii remotes without extra software, and this could get a lot of people confused. pointing the wii remote also wouldn't work because you would need the wii sensor bar, which many people won't realize and create MANY help threads to try and get it to work. motion control and point sensing would be VERY hard for the scratch team to implement, and would only work for wii remotes. there will also likely be lots of suggestions about nunchuk support, classic controller, motion+, and every single other thing that can be connected to a wii remote, which each part being used extremely little. these controls also don't translate to mouse/keyboard well, which will likely result in tons of projects that only work with a woo remote, and leave people unable to play them. it also doesn't make sense what the blocks would be for this, they would either not be useful or be far too complicated for most people to use.
TLDR: too much work, doesn't make sense, too confusing for users, suggestions spam, and unplayable projects.

Q: what about bluetooth/wireless controllers?
A: yes, this is handled by the operating system AND the browser already, it will never matter how you connect your controller, and it likely can't even be detected.

Q: what about blocks to check what kind of controllers people are using?
A: no, this will generally only cause problems. it shouldn't matter what controller people are using. you can already represent most inputs by their positions like the switch does. if this were added, people would likely run into issues using rare controllers. it also isn't clear how scratch would detect the type of controller, the only information it can use is a name which varies wildly even for similar controllers.

Q: what about this controller?
A: if it looks like a regular controller (xbox, playstation, switch, gamecube), and you can easily connect it to your computer (so not the wii classic controller), then yes. if not, then it probably wouldn't be supported. keep in mind that “not supported” here doesn't neccicarily mean the controller won't connect, it may just behave oddly. you could still use these controllers with the button and distance blocks, you would just have to figure out how to get it to work manually.
for example, layouts like the n64 controller just are different buttons, and no second joystick. you would likely have issues using the dropdowns for buttons, but you could just input numbers yourself, including to get all the C buttons.
you can test out your controller on HTML5 gamepad tester, it shows you how all the inputs on your controller work.

when I see [thing v] :: hat :: events
if <(thing :: sensing) is upgradable?> then
set [old thing v] to (thing :: sensing)
upgrade (thing :: sensing) :: control
if <(awesomeness of (thing :: sensing) :: operators) < (awesomeness of (old thing) :: operators)> then
go back :: control
if <not<(thing :: sensing) = (old thing)>> then
GO BACK :: control
end
end
else
look for [things v] :: motion
end

Support
It would be really cool

Support, I don't know if what you say about more Scratchers having USB controllers is true, but I think this would be a cool idea for those who do have USB controllers. My one question, and pardon me if it is a dumb one is: are USB controllers compatible with Scratch? I mean, Picoboards and LegoWeDo were designed to be compatible with Scratch, right?

-Osiris- wrote:

are USB controllers compatible with Scratch?

I wonder what this thread is about.

LiberlandAnimations wrote:

-Osiris- wrote:

are USB controllers compatible with Scratch?

I wonder what this thread is about.

I mean, are the controllers capable of being compatible with Scratch?

-Osiris- wrote:

LiberlandAnimations wrote:

-Osiris- wrote:

are USB controllers compatible with Scratch?

I wonder what this thread is about.

I mean, are the controllers capable of being compatible with Scratch?

Oh! In that case, seeing how many other people did it before (as in, with other games and such that were indie) I think it's totally possible.

-Osiris- wrote:

are USB controllers compatible with Scratch?

For the online version: search up “HTML5 Gamepad Tester” on google. if one website can detect it, any website could. the only problem here would be that scratch uses flash, and i'm not sure if flash can detect controllers, but there could possibly be a workaround if flash can interact with the rest of the webpage, where then i believe HTML could pick up the controller signals, then flash would use the data from that.

For the offline version: Absolutely could work, no doubt.

when I see [thing v] :: hat :: events
if <(thing :: sensing) is upgradable?> then
set [old thing v] to (thing :: sensing)
upgrade (thing :: sensing) :: control
if <(awesomeness of (thing :: sensing) :: operators) < (awesomeness of (old thing) :: operators)> then
go back :: control
if <not<(thing :: sensing) = (old thing)>> then
GO BACK :: control
end
end
else
look for [things v] :: motion
end

Why do you need a controller?

Cub56 wrote:

Why do you need a controller?

Because it's cool

SArpnt wrote:

the only problem here would be that scratch uses flash, and i'm not sure if flash can detect controllers, but there could possibly be a workaround if flash can interact with the rest of the webpage, where then i believe HTML could pick up the controller signals, then flash would use the data from that.

also remember that scratch 3 will not be flash-based, it will be html based.

support

ｂｕｍｐ

when I see [thing v] :: hat :: events
if <(thing :: sensing) is upgradable?> then
set [old thing v] to (thing :: sensing)
upgrade (thing :: sensing) :: control
if <(awesomeness of (thing :: sensing) :: operators) < (awesomeness of (old thing) :: operators)> then
go back :: control
if <not<(thing :: sensing) = (old thing)>> then
GO BACK :: control
end
end
else
look for [things v] :: motion
end

Support. This would get the “Extensions” blocks used more frequently because not a lot of people on Scratch use Lego WeDO or other stuff.

Exactly. The whole idea behind those other extensions was a promo by LEGO. The only other use for it is if you want to use fan-made extensions in ScratchX. Making controller support (with custom mapping probably) would be really amazing, since with multiplayer games, it is hard to map all of the controls to just the keyboard (you can see with my project Dragon Lord - it's only ever easy to play it multiplayer if you have small hands). I'd love to see this in Scratch 3.0 since you can definitely do it with HTML5, and that's what Scratch 3.0 is being made in.

I guess this could be nice, but the need of a controller is partially caused by Scratch not supporting all keybinds (like I have to use space to aim down sights in my FPS game instead of right click).

What about people without a controller?

Support. USB controllers would be a great inclusion for Scratch, and having them as an extension will definitely not confuse new users viewing the site for the first time (as it will be hidden). However, I don't agree with some of the wording here, specifically the use of “trigger”. Remember that only Xbox controllers refer to the top buttons as triggers, whereas on PlayStation it is L2 / R2 and with Nintendo it's ZL / ZR. Instead, have it simply replaced with L, R, L2, R2. This is possibly the most simple to understand with most people when looking at a controller. When a controller is plugged in, perhaps the name could change based on what controller it is.

WolfCat67 wrote:

Support. USB controllers would be a great inclusion for Scratch, and having them as an extension will definitely not confuse new users viewing the site for the first time (as it will be hidden). However, I don't agree with some of the wording here, specifically the use of “trigger”. Remember that only Xbox controllers refer to the top buttons as triggers, whereas on PlayStation it is L2 / R2 and with Nintendo it's ZL / ZR. Instead, have it simply replaced with L, R, L2, R2. This is possibly the most simple to understand with most people when looking at a controller. When a controller is plugged in, perhaps the name could change based on what controller it is.

This seems like the best choice.
(Ironic, how the system with the most confusing face buttons to outsiders also has the simplest name for the shoulder buttons.)

Cub56 wrote:

What about people without a controller?

Controller is definetly not a replacement for keyboard, and never will be. any game that supports it will still have an option for keyboard. If a game leaves out the keyboard option, it's not the fault of the extension, it's the fault of the creator.

when I see [thing v] :: hat :: events
if <(thing :: sensing) is upgradable?> then
set [old thing v] to (thing :: sensing)
upgrade (thing :: sensing) :: control
if <(awesomeness of (thing :: sensing) :: operators) < (awesomeness of (old thing) :: operators)> then
go back :: control
if <not<(thing :: sensing) = (old thing)>> then
GO BACK :: control
end
end
else
look for [things v] :: motion
end

WolfCat67 wrote:

Support. USB controllers would be a great inclusion for Scratch, and having them as an extension will definitely not confuse new users viewing the site for the first time (as it will be hidden). However, I don't agree with some of the wording here, specifically the use of “trigger”. Remember that only Xbox controllers refer to the top buttons as triggers, whereas on PlayStation it is L2 / R2 and with Nintendo it's ZL / ZR. Instead, have it simply replaced with L, R, L2, R2. This is possibly the most simple to understand with most people when looking at a controller. When a controller is plugged in, perhaps the name could change based on what controller it is.

Noted that different controllers will have different extensions, and changed blocks to be less confusing.

when I see [thing v] :: hat :: events
if <(thing :: sensing) is upgradable?> then
set [old thing v] to (thing :: sensing)
upgrade (thing :: sensing) :: control
if <(awesomeness of (thing :: sensing) :: operators) < (awesomeness of (old thing) :: operators)> then
go back :: control
if <not<(thing :: sensing) = (old thing)>> then
GO BACK :: control
end
end
else
look for [things v] :: motion
end

(insert bump here)

when I see [thing v] :: hat :: events
if <(thing :: sensing) is upgradable?> then
set [old thing v] to (thing :: sensing)
upgrade (thing :: sensing) :: control
if <(awesomeness of (thing :: sensing) :: operators) < (awesomeness of (old thing) :: operators)> then
go back :: control
if <not<(thing :: sensing) = (old thing)>> then
GO BACK :: control
end
end
else
look for [things v] :: motion
end

I totally support this. I personally don't have a controller, but this sounds like a good idea. FULL SUPPORT!