Right now there are two ways to listen for input as a plugin:
UserInputService: Doesn’t integrate with studio shortcuts, only works when the viewport is focused
PluginAction: Only works when one of the plugin’s PluginGuis are focused
Neither of these work at all when other windows are focused, such as the output or explorer. I want to make a plugin that has a shortcut and right now, if the user tries to active the shortcut with a hotkey, nothing will happen 90% of the time because of window focus and plugin ownership. This makes no sense to an end user and it will look like their plugins are broken.
Another bump, we still need this. Plugins are a big part of a developer’s workflow, and key-binds/shortcuts definitely speed the process of creating up. A service such as PluginInputService will help out a ton.
Creating plugins is currently an incredibly tedious (and atrocious) process in regards of using input altogether. We’re required to rely too much on hacky methods such as underlying button elements in order to make use of simple events such as mouse down, mouse up, etc. to create a smooth experience as without them there’s a high possibility for bugs as an event might not fire of an element
a great example of this are dragable objects and despite my previous experience with creating plugins and having worked with user interface for years as a frontend programmer, plugins just lack a lot of APIs that are as common as it gets to use vs games, such as an input service.
additively :GetMouse() doesn’t function within the docker widget neither does UserInputService and PluginActions don’t support mouse movement, mouse key up and mouse key down (as far as i remember from utilizing it in my custom keybind plugin)
We’ve had a good start with the additive changes of the Script Editor API for plugins but there’s still a long road ahead that would benefit everyone that creates plugins.
Edit:
After having, very stupidly, looked over certain event types some UI elements may contain; InputBegan, InputEnded and InputChanged. these could be utilize for said input, however certain global input might still be useful if we’re talking about specific widget wide interaction rather than needing to create events on each component individually.
I am currently working on a plugin that has drag n drop feature for elements in a docker. The thing is that, UserInputService is only for viewport and to prevent input being lost when dragging an element too fast, i have to somehow obtain the raw input responsible for mouse movement. How? THIS MESS.
--lets say this is inside the InputBegan connection,
do
local inputChanged, inputChanged2
inputChanged = UIElement.InputChanged:Connect(function(input: InputObject)
if input.UserInputType == Enum.UserInputType.MouseMovement then
inputChanged:Disconnect()
inputChanged2 = input.Changed:Connect(function()
print(input.Position) --only THEN i can obtain input position regardless if mouse is within UI element bounds or not
end)
end)
--ClickInput comes from UIElement.InputBegan signal.
ClickInput.Ended:Connect(function()
inputChanged2:Disconnect()
end)
end
Really messed up eh? I would love to have a dock widget to have a function to get a dedicated input listener that provides same functions as userinputservice, but just for dock widget.
I really hope this gets added at some point! PluginActions are great, but there are currently limitations to it. The OP worded the problems I have with the current solutions perfectly:
Another limitation is that if my plugin has a front-end and I want to add basic input support for interacting with said front-end, I can’t do anything besides detecting mouse inputs, and ironically enough, my specific use case is that my plugin tries to reduce mouse usage for specific tasks. It displays a list of instances - you can select an individual instance because left clicking works, but implementing advanced functionality such as shift-clicking to select multiple instances, or adding any custom behavior that enables my plugin to react to specific input for that matter, is currently impossible. The biggest hurdle is that UserInputService:GetKeysPressed() returns an empty table unless the viewport is focused.
I could create PluginActions for very, very specific functionality in my plugin and manually assign the shortcuts—and I already do for some things which works great—but so would every user of my plugin. They would also need to figure out which shortcuts to pick, unless I publish “recommended shortcuts” with my plugin’s documentation which is less than ideal.
I have a lot of ideas for plugins that would substantially enhance my workflow as a developer - and I’m confident that other developers could benefit from my creations too! However, this has been the largest blocker for bringing my ideas to life for a surprisingly long time and it would be great if this issue could be given some attention. Thank you for your consideration!
I spent 2 months working on a plugin using PlayerGui’s (because I didn’t want to constantly publish as a plugin) only to find out UserInputService is a no-go in the Widget
Not sure if this helps but I found that creating a frame in your widget and using the InputChanged event (from the frame) works to gather input from the widget as long as the widget is focused.
Even though this doesn’t cover the rest of studio and doesn’t address the point OP made in their post, it should be sufficient if you’re only looking to get inputs from a widget.
I didn’t want to bump this topic again as it is almost 4 years old but why isn’t there at least an explanation by the staff team of why this wasn’t implemented yet?
I mean, 16 people bumped this feature request over the course of 3 years, and it got linked/mentioned at 3 other different topics, it can’t be the classic answer everybody gives “Roblox doesn’t listen” because a feature request got bumped for 3 years, there must be a reason behind it.
I’m in a situation with a plugin where having this feature would make my life so much easier, and I think everybody making a plugin wants this to be implemented.
bump, this to this day really needs an implementation. Currently @vvv331 's method works as long as your mouse is within your plugin window. When your mouse leaves your plugin window you get an InputEnded and thats it. UserInputService and ContextActionService both only work when your mouse is in the viewport (which is useless)
I would also like this to be implemented, but my main issue is with an almost 4 years old topic being bumped since 2020 with no answer/explanation by the Roblox staff, it’s not like this is a useless feature, it’s a great feature to be added, but it looks like Roblox is ignoring it.
