Is there any way to integrate Rojo with this new service? I’ve managed to sync the plugin, but when I Save and Reload Plugin it breaks the sync since it creates a new Plugin instance.
1 Like
I don’t think there is any straightforward way to integrate Rojo with PluginDebugService today. We know this is non-ideal for some users and investigating how to support your workflow.
8 Likes
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 
.
@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