only appears to happen with this 1 union…
LITERALLY FOUND OUT THAT YOU COULD TYPE HERE THE ENTIRE TIME 
I suppose this is what i mean by,
https://gyazo.com/90d7f6b48ffc5f507bac451b322443fc.mp4
im not sure if this is a bug or not
This update seems pretty good but how do you remove the circles in the middle of parts?
1 Like
Why in gods name did this post not include the fact that you can right-click + scroll to change your camera speed
Hello there.
While you did a great job. Do you know how do I disable Grid snapping? It’s not anywhere in the settings
It’s currently disrupting my workflow as I need the orientation to be the same in certain cases. It would be good if there’s a setting to do so
this announcement already mentions it
I just realized that this update breaks my plugins keybinds which uses the numbers 1-5.
Because of the way that plugins are restricted to inputs we have to use frames to read them which means that this update no longer sends out the InputBegan signals for numbers 1-5, looking for a workaround. Any help will be appreciated.
@tnavarts is there some way around this. Plugin:Activate() just gets overriden, this really makes my plugin more difficult to use.
1 Like
We’re taking the shortcuts 1-5 for the draggers. Unfortunately, this is just bad news for your plugin no matter how you put it and you’ll have to change something.
You have three options:
-
Use different shortcuts. Other keys entirely or a modifier key on top of 1-5. The draggers used to use Ctrl + 1-5 for example, and those are now free and should work via your old method (though they’re obviously less desirable, which is the whole reason we switched the shortcuts).
-
If this is a power tool for some internal workflow where you interact directly with the users you could expose the functionality via PluginActions and have those users reassign the shortcuts 1-5 to those plugin actions instead of the draggers via shortcut customization.
-
Co-opt dragger selection when your plugin is active if it’s a contextual plugin. You can use GetSelectedRibbonTool to hook selection of a dragger and re-process it. This is what the built in Animation Editor does to work with the Move / Rotate tool buttons. This is a little bit janky and tenuous but is a way you may be able to maintain something as close as possible to the old behavior.
2 Likes
These are all compromises, this plugin takes the full screen and usually people replace the viewport with it, I really dislike that Roblox keeps going in this direction where you remove stuff from developers and then ask us to work around it. For the longest time the keybinds were CTRL + 1-5, not only did we have to adjust to this change but in the process you also break other peoples creations.
I would really appreciate it if Roblox added some way for plugins to take back over these keybinds when the plugin is in use, I understand the whole malicious intent thing so you may not want to, but people can easily uninstall plugins with malicious intent.
I personally would rather not have to force my users adapt to a new change (which they already did since this feature has been broken for a couple months now)
Example of what the plugin looks like, keybinds 1-5 were used to change colors at the top of the screen faster.
Adding onto what Parker said above, if they’re in a viewport that doesn’t have draggers (ie a plugin), I don’t see why the engine has to keep using those inputs and not do anything with it?
Alas, Roblox Studio does not have contextual shortcuts right now, all shortcuts are global.
Also, even with contextual shortcuts, the API isn’t there. For that setup to work, the plugin would need a way to tell Studio that it is handling the shortcut and doing so in the context of that panel, neither of which are things the plugin API supports right now.
I can give it a bit more thought but there’s no obvious change that would be able to restore the functionality. It’s very likely that you will have to change things.
Just make it possible that when a plugin uses plugin:Activate() the default keybinds are disabled, again plugins with malicious intent can easily be uninstalled by users.
That would not work with building plugins because you want to be able to quickly switch between building plugins and the main building tools.
1 Like
Just a question, how is the edge and corner calculation being done for meshes? Is it using some sort of raycasting or does this feature come only with the engine (as in it wouldnt be possible in a game)
It could actually run in game just fine as user code, there’s no special magic being used. It’s built using a very clever combination of Raycasts to analytically find the mesh edges.
It’s written into a nice self-contained module if you’re interested blackboxFindClosestMeshEdge.lua (9.4 KB)
5 Likes
I don’t see why a bool argument couldn’t be utilised to determine if keybinds are disabled or not, use plugin:Activate(true) to disable, leave blank or false to leave them as-is.
1 Like
YO WHAT?? bless ur soul, 
Also, 1 more question, do you think its better to replace this with an edge detection utilizing Editable Meshes in the future?
I’m having a similar issue to this - my studio will freeze if I try to move a high part count model and will not recover within any reasonable amount of time. (I gave it around 30 seconds before giving up and killing the process)