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?
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.
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.
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.
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)
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.
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)
After using this beta for a while I can confidently say that it’s hindered my workflow in a lot of areas, while offering a lot of experimental wins that would benefit any creator. I’ll focus on the two main gripes I have with the changes to Roblox Studio’s Draggers in this beta.
I’ll start with the bad because I suppose the feedback is the strongest element.
Skimming over this thread, the one thing that people haven’t talked about much (at least from skimming, cut me some slack here, there’s a lot of posts)
Handle Summoning isn’t working right.
In the above video, I’m trying to summon the handle at my cursor, which is something I’ve done a lot for up-close precision when working on complex builds that couldn’t only work under correct snapping increments (0.25, 0.5, 0.75, 1, etc.).
For people who often build with (0.001) this is such a pain to deal with! I have to angle my camera so awkwardly just to line up a part I’m looking at. This was executed so much better before the rework of this feature. What happened?
For example, this is what it’s like with the beta off.
If we had this type of handle summoning with the soft snapping, it’d literally be perfect.
Speaking of which…
Soft Snapping is a pain sometimes
I understand that getting closer to the edge you wish to soft snap gives you better results, but there are some cases where soft snaps are needed in spots they don’t spawn.
A good example of this behaviour comes from Photoshop, which isn’t present in Roblox Studio’s dragger tools.
The above video shows that when moving objects of different sizes, Photoshop is able to determine the edge of another from a far away distance, and snap to it. What’s even better is that they also count the gap between two objects sandwiching another so that it’s always centred.
With studio’s current beta functionality, for people looking for precision like this, it will only ever function on edges the Part will connect with, which isn’t very intuitive.
Also in the above video, you may have noticed that despite having 1 stud snapping, the ground doesn’t snap to 1 stud like before this beta, as others have reported with baseplates.
I acknowledge the version of these draggers before the beta didn’t have this functionality, but it makes so much sense to have it here with the addition of the rulers and the counting done when moving a part, scaling, or rotating.
I don’t entirely dislike the features here. I enjoy being able to type the number and have it jump the part in that direction, I like the concept of soft snapping, and animations on rotating as before determining the direction it moved in was awkward without selection faces, as you see me using in the videos.
I think with just a little better execution these tools will work for just about everyone. I get you’re adding toggles to disable some of these, but what’s the point of improvements if they just get turned off?