Introduction of Lua Widgets

It seems that along with this new update, all of my once-consolidated plugins have now… deconsolidated…

except for a few that have for some reason
image

6 Likes

The lack of support for UserInputService is… interesting. So there’s no way to tell if, for example, the shift key is pressed since it does not create a character within a TextBox. I was getting so hyped to make my own script editor :frowning:

11 Likes
Already began one making one before PluginGui update


btw I’m gonna convert the text to courier new sprite when i get the chance, I was just having issues before.

But it would be nice for some friendly competition :stuck_out_tongue:

I’ll give you a little hint on a hacky way around your problem till UserInputService is added:

1.Force focus on a textbox
2.Every time someone types, fire an event of some sort and put the text as the parameter
3.Clear the textbox
4.Focus the textbox
5.If player unfocuses textbox, refocus

4 Likes


Is this normal?
First time experiencing this problem, generates the error 100 times every 3 seconds.
Restarted studio and it stopped but if this comes up with any future problems, it’s here for reference.

1 Like

Update on some text input shenanigans. I tried a couple hacks and while the “read text from a textbox” hack sounds good for maybe a few key presses, it isn’t nearly complete and is only good for typable characters. I tried to use a proxy TextBox within a ScreenGui in CoreGui, and it did not capture input. So, it seems that PluginGuis have independent focused TextBox along with no UserInputService, and by extension no ContextActionService either.

I’d say this update gets a “C” grade. Not failing, but nothing to write home about - the cost of keyboard input while using PluginGuis is pretty significant, but paying that price to more fully utilize screen space seems reasonable at the moment given studio’s “point and click” nature. Plugin developers should definitely expect UserInputService/ContextActionService at some point. I would revise the OP to specifically mention that support for keyboard input in general is weak. I assume this extends to gamepad input as well since both these game services are required for that.

Let’s not forget almost every major plugin used by developers have some sort of keyboard shortcut. Look at xSIXx’s Moon Animation Suite, for example. It would massively benefit from reclaiming the game window screen space, but alas the ever-valuable key commands would only work with the main game window selected.

tl;dr:

  • You can only use typable characters for keyboard input using a TextBox hack
  • ContextActionService is also out of the question, so PluginGuis don’t support gamepad input either
  • Dockable windows reclaim enough screen space to look past these feature deficiencies at the moment
  • Many valuable plugins that would benefit from moving to PluginGuis depend on keyboard input in some way, so they’ll probably not do it (bad)
  • Dark theme when?

Hello, from the future! It seems that PluginActions help this out: Introducing Plugin Actions

8 Likes

My take is that Roblox should let you bind actions without binding buttons. This would include default shortcut keys. This would let us rebind hotkeys and add actions to the hot bar easily. Makes it easier to discover actions.

3 Likes

canvas element for things like this maybe?

Hey so uh ever since this update, terrain tools have kind of become garbage no offence

This is using the “Add” tool set to the material “Sand”, for some reason half of it is “Limestone”.
https://gyazo.com/26d020fb77c1503853a15accc5ae6406

Also Plane Lock keep’s enabling itself constant which is pretty awful for tools like Grow or Erode. Not only this but sometimes the Material buttons won’t appear until I’ve resized the Terrain Editor window around. The default terrain tools have historically been a little frustrating to use but it’s even worse since this update.

And I don’t know if this is just because I’m not used to it yet but honestly the different tools being in a little window in a different part of the screen from literally every other tool in studio feels extremely user unfriendly.

5 Likes

For the Add tool, do you have Auto enabled? This will make the tool apply whatever is below it, rather than the selected option.

The plane lock re-enabling is certainly a problem.

Can you explain more about the materials not appearing? They all show up for me.

As for the materials, It’s just upon opening it for the first time in studio, it seems to happen when the tool is created with a bunch of other things already taking up space in the side column

and I guess auto could have been turned on? It seems like a strange option to have for the add tool, it was never an option before. It makes sense for the add tool to just use the selected material

If I had to guess what the most major issue is that’s making this confusing is that the tool options seem to carry over tool to tool, and only some tools have defaults. Like if I use the “Add” tool, it enables and locks Plane Lock to true, but if I go back to grow or erode, it doesn’t bother switching it back off. I think that must have been the same issue I had with the add tool suddenly using “Auto” for material settings. either case is odd because Add and Subtract never used auto materials before, and grow and erode never used plane lock before, and I think both instances of these options being used for these tools is inappropriate for those tools to begin with.

Still though, from a usability standpoint I’m not fond of this widget format. Like, every tool I use in studio I click on the ribbon bar to get to, except now these terrain tools are somewhere else on the screen, and I keep getting visually confused because all of the different settings tabs feel muddied up with the other things I keep open in studio and it makes it very difficult to quickly change settings that I need to be changed

7 Likes