Put a warning banner when editing scripts inside PluginDebugService

For the past 12 days I’ve been creating a plugin, while PluginDebugService is useful, sometimes when a script inside a plugin would print something or error out, I would instinctively click on the output text to edit/check out the script, clicking on that output text would then open the same script under PluginDebugService.

Since I keep my actual plugin code, and everything else related to it in ServerStorage, sometimes I would unknowingly edit a huge portion of the PluginDebugSerivce’s script and once I reload the plugin no changes would be saved. (Since I didn’t actually save the edited version…)

I suggest there to be a banner when a script inside PluginDebugSerivce is open, warning the developer that they are editing a different script.

This would save some people (like me) a lot of time and it will prevent these mistakes from happening.

The banner should say something along the lines of “This script is a part of PluginDebugService” or “You’re editing a script inside PluginDebugService”. Also a button/setting should exist to ignore these banners.

(The banners I am talking about)

12 Likes

What actually is your workflow here?

The workflow I’m most familiar with is editing the scripts under PluginDebugService and using Ctrl+Shift+L to save the changes and reload to see the effect of the changes I’ve just made.

Isn’t the point here to use PluginDebugService

@tnavarts It would be nice if I could create a new plugin directly inside PluginDebugService without having to create a folder outside it and saving the plugin locally. Just a few less steps at the end of the day

Oh my god… I’ve been making plugins for maybe over a year at this point and I haven’t been aware of this, well, it seems that I wasn’t using PluginDebugService as intended… My bad…


I’ve always used PluginDebugService in order to tweak some settings and change certain stuff in my plugin live, however I keep the main plugin content always in workspace or Server Storage, and I would only use the plugin content from PluginDebugService when I wanted to tweak something without risking breaking something in the main plugin.

I treat PluginDebugService like the studio’s playtest feature, I could edit the content while playtesting in order to test stuff out, but 70% of the time I wouldn’t save those changes.

I do all that because I keep stuff like the plugin’s UI, maybe certain objects, and other values in the Plugin itself, once I initialize the plugin, I take the UI, objects and other values and send them to their parts of the plugin. Since the plugin inside PluginDebugService is “running” and in my case some objects were changed, if I were to reload the plugin from PluginDebugService, those changes would most likely break the plugin.

I guess my way of making plugins is really really inefficient, however, for some reason that is the easiest way for me to work with plugins, I’ll probably transition onto using PluginDebugService as it was intended in the near future.

1 Like

I just permanently lost a bunch of work because I was accidentally editing the PluginDebugService copy of a plugin script instead of the master copy in the place file.

Please make it very clear when you are editing scripts in PluginDebugService because they are transient and easily overwritten.

EDIT: This happened to me 4 times in the past day. Please fix this, it’s insane. I tend to focus very intensely on things and simply do not have the capability to be constantly second-guessing “am I editing the right script?”. I am just going to disable disable plugin debugging entirely now because this issue is worse for my productivity than the occasional inconvenience of not being able to use breakpoints.

1 Like

Code inside non persistent services should have a very clear indicator in the IDE that they are not going to be saved. Studio almost never does anything for this sort of UX and that’s a serious problem - e.g. toasts for important messages such as publish failure, errors, etc. It never feels like the product is concerned with the user.

1 Like