Technically, you could make explorer and properties panel replacements and make everything but the ribbonbar dark themed. We’re getting close.
I created an rbxmx
file, to view the default structure with the current setup of modules, and emptied the source and object name parameters. Now I’m using a string function to replace the keywords with the name and source of each file under the repo/src
that ends with a .lua
extension.
This does not mean I gave up on the idea of Nagaton600, the auto DM bot.
Cool but where is our normal CycloneUprising style meme update?
I’m saddened
Nice new API addition. I’m thinking of creating a plugin that will take advantage of the new Lua Widgets API and this is what I made so far with the new API.
So… how does one debug script-based plugins without HotSwap?
If you use the “Save as Local Plugin…” feature, it should reload all plugins with your new plugin code. This is not as fast (two or three clicks instead of one) but should work for this purpose.
Ah, thanks. I’m so behind the times for plugin development.
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
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
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
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
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.
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
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.
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.
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