Bump. This could lead to so many possibilities for plugins.
1 Like
I’m gonna have to bump this thread.
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.
1 Like
bumping this thread… yet again
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.
2 Likes
Not sure if you still need it, but currently this can be accomplished using GetRelativeMousePosition.
1 Like
bumb, tell me when this gets out.
also i feel like PluginActionService name is better than PluginInputService.
1 Like
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.
And let’s hope you don’t have a lot of them…
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!
2 Likes
I just can’t belive that this thing isn’t dealt with yet
2 Likes
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
1 Like
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.
2 Likes
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.
Does anyone have at least an idea of why?
2 Likes
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)
1 Like
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.
1 Like
Bumping, I can’t believe how none of the staff have responded yet. For now @vvv331 's way of doing this is fine, but it’s not what I, nor the rest here really wants. I also have a suggestion for pluginactions, I think it would be good if they had a default keybind you can set as the plugin creator.
1 Like
most of my UI uses UserInputService for stuff like dragging, and since plugins dont support that I cant test my UI in flipbook 
bumping this once again. roblox we need this.
boomshakalaka another bump. roblox needs this. the ammount of hotkeys and shortcuts could make plugins even better. especially those paid ones 
bumping this AGAIN, like I want my ui to atleast have a drag system bro 
i’ve found more and more keys that dont work with the keydown hack i’ve used
please roblox, being forced to capture through DockWidgets isn’t a fix all solution.
1 Like
Bump,
It is also very annoying that now (still happening as of late November 2024) the numpad (or keypad) inputs have hard-coded actions to bump-move selected objects.
This takes away the premium keyboard real-estate that I use most-frequently for custom plugin actions.
PluginAction
PluginAction | Documentation - Roblox Creator Hub looks like a way to set up plugin actions, but I don’t see a way to specify a default key/input binding.