Plugin Debugging: New Beta Feature!

My plugins like Yucon and Shared System are about to get juicier.

1 Like

This significantly helped ease my workflow, but sometimes deleting things within the plugin through the explorer from the PluginDebugService and adding/modifying things there causes weird Studio crashes without any dialogue unexpectedly - too unpredictable for a bug report I think.

But other than that it’s a very useful feature.

1 Like

uhh just started scripting but yeh thats good

1 Like

Can we get a option like “Reload Plugin” in addition to the “Save and Reload Plugin”? This would allow us to reload a plugin when it changes directly from the files, which will allow us to more easily use external editors with Rojo. Without this, the “Save and Reload Plugin” option overwrites the version of the plugin in files with the outdated version in studio.

2 Likes

Well, I really don’t know if break points really work. It only worked for me once, but now I try to use them again, but it doesn’t work anymore. Does that happen to others? Otherwise, not being able to change the source code of the script is really great, thanks a lot!

EDIT:
Ok, the breakpoints works, but only once. If i want to reuse them, i need to close my game and exit my game, then re-open my game and the breakpoint works.

How do I use this, exactly…? I make and work on private plugin extensions very often and after enabling this, I don’t know what its use is good for.

Is using this a faster way to reload your plugins after applying both small and large edits to them?

I also noticed it doesn’t show the plugin’s widget GUIs in any way so I can’t really watch the widgets work in real-time, or maybe that’s not what it’s for?

Is this just a replacement for using e.g. StarterGui to develop your plugins so you don’t need to load the source plugin place to work on it but really anywhere you want?

I’m not quite getting this, could someone explain?

This beta has proven hard to use because of the way it reloads the plugin; I’m writing a plugin that moves a child to CoreGui, and am having to choose between generating it with a script, cloning it, or just not using this beta.

Is it at all possible to make it reload the ‘pristine’ version with the script swapped out? That would make this a lot more usable for me.

1 Like

I’m curious, why do you want to do this? Why does Cloning not work identically to moving it?

There’s no reason in particular; I’m just used to moving GUIs instead of remaking them. It’s how I’ve always done it.

Is it officially advised that we copy them over instead of moving them?

Either way, I’d still prefer it to swap out to the pristine version. If for whatever reason a plugin has a state that changes in its hierarchy, it’s annoying to ‘reset’ that state compared to just using something like Hot Swap.

I wouldn’t call it “officially advised”, but it’s almost certainly better practice:

  • That component that you thought you only needed one of and moved over? Now you need another of it and you have to rewrite some of your code to support it.

  • If you’re moving over stuff rather than cloning it that’s a suggestion that your code is very far from being testable. (most people don’t do any testing of their code in the community right now, but we would like to promote more of that)

  • Your lifecycle changed (for example… thanks to using the plugin debugger!), and now you need to create the Gui twice is a session instead of once. Moving it back might kinda work, but things would probably have been simpler if you just cloned it in and destroyed the tree after you were done with it, moving it back out instead of destroying it is a very easy way to leak instances or other memory.

  • Also, don’t worry about perf. Actually creating the graphics objects and general rendering state to render the Gui is generally way more expensive than having one extra copy of the static parts of the Gui sitting around inactive in memory.

TL;DR: Just clone it, it’ll cost you nothing and you’ll probably save yourself trouble at some point.

3 Likes

I’ve not actually had to worry about that third point during plugin development thus far. Up until this beta, there’s only 4 situations where a plugin can suddenly ‘stop’, and all of them are easy to deal with using Plugin.Unloading (I recommend Maids to deal with disconnecting/destroying things).

The debugger presents a unique situation because side effects have consequences, for better or for worse.

Also with regards to testing, I gave it some thought and I’m not sure what the best workflow for testing a plugin would actually be. Lots of stuff that relies on user input, which isn’t easy to replicate with tests.

It is certainly not easy… we’re going to try to make things easier, though that won’t be happening for a while yet.

If you want an example of something that seems like it would absolutely refuse to be testable yet has tests anyways, look no further than the Lua Draggers code. If you look under SelectDragger.rbxm in the builtin plugins there’s a module called FreeformDrag.spec which has integration tests for the core dragging functionality. That was done by me writing a “context” class through which the main dragger logic queries Studio state, and a “Fixture” implementation of that context which lets me feed the dragger logic whatever studio state (Joints, Constraints, Selection, etc) I want it to see in tests.

The “TestEZ” module which you can see in the SelectDragger and some other builtin plugins can be automatically used to run all of the “.spec” test Modules in a project.

I’ve lost a good amount of my plugin data due to me closing studio without manually clicking “save and reload plugin”

The first few times I wasn’t aware that it didn’t save on exit, and the “would you like to save these changes” message made me assume it would save my debug plugin data too

The past two times this has happened was because I wasn’t thinking about it and went idle in studio and I was going to resume working later, but I ended up just closing studio without noticing that I didn’t manually click save on the plugin before I closed

a option to auto save debug plugin data, or even just a warning box would help resolve this problem

3 Likes

Hey y’all - we’ve disabled this Beta feature for a bit due to an unfortunate interaction with LinkedSource scripts. We will turn it back on once we’ve resolved the issue!

6 Likes

Is there a way for me to access these plugins any other way at the moment?

I want to edit one of my plugins, but I had been editing it inside the Plugin Debugger and now that it’s not available I can’t access the latest version of my plugin.

4 Likes

Like @AlgyLacey said, is there any way to access our plugins at this moment? If not, how long do you think that the reparations will take? ±, it dosent need to be an exact date. Because I love this feature so much that I can‘t more create an plugin without it :joy:.

@AlgyLacey Unless I’m mistaken, the plugin should be under %localappdata%/Roblox/Plugins in the Windows explorer; that’s where local plugins are saved, and the debugger used local plugins.

3 Likes

Hey y’all - we’ve resolved this issue and re-enabled Plugin Debugging in Beta!

7 Likes

Wow, thanks really much.

But now there‘s a problem: In the meantime I used CloneTrooper‘s ModManager to continue to work on my plugin, and now? I don‘t know why but everytime that I try to enter in my game where I worked on my plugins I just can‘t. I get kicked out. This only happens to this specific game where I used CloneTroopers ModManager. I first thought it just was a normal bug, so I waited for an update. And nothing changed: My problem still persisted. So, I deceided to change device to see if the mod manager changed something locally, and still not: Even on another PC I just couldn‘t access my game. So, my last hope was to uninstall Roblox Studio and to install it, wich is what I tried right now at this moment and my problem is the same. So, I wanted to post this bug on the #platform-feedback:studio-bugs category, but we can‘t at this moment. So, I just hope that there‘s a way to solve it. I have my plugins in the PluginDebugService, yes, but I had in my corrupted game other important stuff like modules etc. I really wish that I could send the logs, but I can‘t access it. The only time were I could access my game while this bug was there was when I switched device. I thought the problem was solved and stored a copy of the game for security, so, if it would be possible to help me/us (other users with the same problem, but who can‘t write in the forum) it would really help us a lot. For example me I don‘t really need to recover my game (but it would be better if it would be possible), what I really need is to get all my guis, backups etc.

Still, thanks for re-enable the Debugging! (This was a really long reply…)

EDIT: Just skip to the next giant text, I found the problem

Ok, I really don‘t know what happened, but I just lost all my LocalPlugins. My Plugin Folder is empty. With this I just lost my pluign in them I was working on. It‘s not a huge thing, I was planing to do my work from scratch again (it was a huge mess), but still, I lost my GUI‘s (I had a backup, but I can‘t access the place with th backup inside). Maybe it‘s me or maybe not, this is why I am asking here:

Do someone else lost his plugins, or is this something related to my problem?

  • Me, too
  • No, I still have my plugins (my self-made plugins, not downloaded ones)

0 voters

#SOLVED
I just found out that it was because I am using another device, sorry for anyone that I annoyied! (Still, maybe it would be a great feature request: make that the not published plugins are shared between all the desktops on them you are connected…)