Currently, we have to have the plugin activated to use any sort of mouse events, so it’s virtually impossible to create custom keybinds (i.e. “p” to create a new part at the mouse hit). I’ve run into numerous occasions where I wanted to be able to use the keyboard even when the plugin wasn’t selected. Here is a list of things that I cannot possibly do with the way plugins are atm, well, I could do them, but it’s REALLY annoying to have to switch plugins to do things that constantly require switching between plugins:
Pressing “G” to send the selected model/part to the ground without having to switch to the plugin
Pressing the spacebar to bring up a part search box while building with CmdUtl – would have to switch over to the search, find the part, then switch BACK over to CmdUtl T_T
Toggling GlobalShadows with any given key do help while building in dark places without having to switch back to a plugin (requires constant switching back to make sure it’s looking good in the dark as well)
etc
Sure, it would work great for someone such as yourself, who is a coder, and developing their own plugins, but for everyone else letting random plugins bind random keys with hard-coded shortcuts even when they aren’t activated would be a huge mess, because there’s honestly no way 90% of plugins are going to offer any sort of configuration. And even those few that would offer configuration would be using their own ad-hoc systems, and you’d have no way to easily manage it.
Do you really want to have to fix up your key bindings every single time you install a new plugin? Because that’s what could easily happen if this were allowed.
If you take advantage of the new Quick Access bar customization you can add a plugin to it and then set a shortcut to select the plugin from the Shortcut Customization menu. On plugin activation preform the desired action.
@Stravant: Special studio option to allow multiple plugins to be activated at once, and only unactivated if unactivated by the plugin itself or clicking on the plugin button? Should be 100% compatible with all plugins since it isn’t changing how they work.
I have a single plugin that I’m using to tweak Studio to my liking (i.e. anchoring inserted parts and changing them to Symmetric, removing “build tools” from build mode, etc), and really want to add some functionality for “G”(grounding objects), “L”(toggle lighting), etc, but without this feature (since I use your plugins + others frequently), I won’t be able to accomplish that. I suppose I could make one big mac-daddy plugin, but really? Is that what I’ll have to resort to?
SystemMenu bby :([/quote]
Meh, I no longer care for system menu. Feels unorganized and cluttered when I go back to it. Though Ribbon doesn’t work offline for some reason. :c
SystemMenu bby :([/quote]
Meh, I no longer care for system menu. Feels unorganized and cluttered when I go back to it. Though Ribbon doesn’t work offline for some reason. :c[/quote]
lol – ROBLOX in general doesn’t work offline (hope they fix :()
Personally, I still prefer SystemMenu over RibbonBar because I’m usually using the buttons to switch between tools. I’ve been working with SystemMenu since I first joined ROBLOX, so I’m used to it, and I know where everything is. When I tried RibbonBar, I had to switch tabs way too much when building – it is most certainly not tailored towards building, and because I build quite frequently, that was an immediate turn-off for me. It has the feature where you can start servers and players at the same time, which is really neat, but there’s not much to it other than that. I make it so I can test all of my games in Play Solo, (proper error-handling on Datastore requests etc), so I never really need to use the test servers unless there’s an issue with Filtering Enabled, which doesn’t happen too often since that’s like second nature to me now.
“Special studio option to allow multiple plugins to be activated at once, and only unactivated if unactivated by the plugin itself or clicking on the plugin button? Should be 100% compatible with all plugins since it isn’t changing how they work.”
Uhh… what? That doesn’t solve the problem at all… in fact it makes it even worse. Almost zero plugins would work correctly with that option enabled, so it would pretty much only work for people who are developing all of the plugins they use, which is only 0.01% of people. Plugin expect that when they are activated, they should be using the mouse, you can’t have two plugins activated at the same time because they’ll both be trying to do their mouse stuff. And on top of that, it it still doesn’t address the shortcut conflict problem I brought up at all.
I don’t know if you even put any thought in before you made that response to my post. If you want to discuss features you should at least put a little though in to think about whether the thing you’re suggesting is remotely reasonable for anyone other than yourself right now.
Could this be solved with a plugin hotkey service? The user could go into studio settings and change the bindings and the plugin would only listen for the action to be called, as opposed to a specific key press. Something like
PluginBindingService:RegisterAction("Terrain Plugin", "Selects a block of Terrain", Enum.KeyCode.E)
PluginBindingService:ActionStateChanged("Terrain Plugin", "Selects a block of Terrain"):connect(function(keycode, userinputstate) end)
This would solve overlapping bindings by allowing the user to change them if they happen to install a “passive” plugin that uses the same key as another.
No keybindings by default, but allowing plugins to register namespaced “verbs” (That’s the term you’re looking for), is the only reasonable solution that I can see. (That way you would be able to assign shotcuts to those verbs in the normal shortcut settings page)
Keybindings by default from plugins will never be an acceptable solution, because anyone with a non-trivial amount of plugins will have so many conflicts that there might as well not be default keybindings at all.
This is the necrobump to end all necrobumps, but I feel that this feature is incredibly useful and beneficial. Keyboard shortcuts are an essential part of any program, and without full control of them, plugins will always be limited.
I’m designing a plugin similar to FX Console but for items/code, but a key component of its design is that the mouse is unnecessary–everything is controlled with the keyboard for maximum efficiency. If it’s not crazy fast, the purpose is defeated.
I understand that there are some issues that arise with allowing this (multiple plugins using the same command, etc.) but I am certain that with proper implementation on the part of the engineers and plugin developers, these issues can be avoided.
