Theoretical. I’m just thinking of anyone who tries to use plugin.Unloading for the first time isn’t sure if/when the function is being run. Printing is the way to quickly figure this out & confirm code is running. E.g.
plugin.Unloading:Connect(function()
print("Did this work?")
end)
The cleanup work might be non-visible stuff too, e.g. disconnecting events.
Clearing the output before unloading might just cause confusion if a plugin does dump a lot of info to the console on unload.
AKA: average dev’s worst nightmare that no can seem to fix and you spend hours and hours trying to find the line that caused the error only to see it was inside another script and then you fix that one and it breaks something else and you just eventually wonder what the meaning of life is and considering quitting development and then you reload into playtest one more time and then it fixes itself at the last possible moment only to leave playtest and discover it’s broken again and really WHYY are we here?
FYI this one should be rolling out now. The difference is night and day.
Probably…but I’m not sure. Please check, and if it doesn’t, let me know (ideally in a bug report, but if you can’t then a private message) and it is usually pretty easy to fix up.
It is a big deal if you are testing production code and has to constantly retry over and over again. It can accumulate to hours saved over a whole year lol
Can you file a bug report for this as well, or PM me if you can’t? Ideally with a video of what you are trying to do that is lagging and the model itself.
I do know of a bug where if you have any dragger selected (especially Move tool–make sure you have everything including Select deactivated) then there’s a spike, so this could be that. We were looking into that one but don’t have much yet.
This should be a setting at the very least, or just approached differently.
I don’t personally have a practical concern to highlight but I’m not sure why the output would have to be cleared. The release notes say “make any fresh output from the new run of the plugin(s) stand out clearly”, but isn’t the timestamp on each entry there for that?
You can relatively easily make a difference of when things happened.
There’s also separators that can totally do the job. For example, a warning saying “Plugins reloaded” is even more easily discernable from most clutter.
I also don’t like the approach of the question, “Is this a practical concern you ran into” because it implies we would remember a use case months ago of when we used previous output logs after reloading plugins. It’s extremely unlikely anyone can come up with a specific use case on the spot, when the behavior of not clearing is expected. In other words, having the output not cleared has never been the highlight of my day.
Anyway, I feel like there’s no precedent on clearing the console from reloading plugins without a setting. If VS Code started doing this every time it installed or updated an extension, a lot of people would not be happy about it.
The output is not cleared in either of these cases.
This is change specifically only clears the output while reloading a plugin as part of the plugin development workflow, not any regular developer flow. A regular developer will never see the output cleared by this.
The logic is, why are you reloading the plugin as part of plugin development:
You’re reloading it because you fixed something which broke: Clearing the output is very helpful here because it makes it much more obvious whether the error is gone (and if it isn’t, what the new problem is).
You’re reloading it after changing something, which may create a new error: In that case clearing makes it easy to scroll up and see the first error that happened, which is the one you want to look at.
It is a somewhat opinionated choice, but I talked with several devs before doing it, and we weren’t able to come up with any realistic cases where it creates an issue.
Settings are expensive, we avoid adding them “just in case” and generally only do to satisfy an actual need. I’m open to the setting but I need concrete use cases to go ahead with that, not just abstract concerns.
You’re not wrong but this is ignoring the fact that there is a single output. Which means when you reload your plugin, you don’t only clear the previous plugin error, you also clear everything that came before.
You’re also right, for most developers, this will probably never affect them. But in the past 2-3 years, I’ve written 30+ plugins for our game fund game, and I’m confident that comparing between the latest and previous error, or output data, has happened more than once.
For example; how the new version of a plugin has analyzed and optimized a KeyframeSequence, versus the previous version. I’d have to copy-paste or screenshot the output, just to compare their results right after, or I make another plugin with an interface to compare KeyframeSequence data. It makes for much more work, iterations are slower, and for no reason.
Even worst situation when I think about it, my plugins hot-reload with Rojo as I make them. I don’t manually control the reloading, it just reloads when I save any file in VS Code. It’s a lot more convenient to be able to see the history of data, errors, or testez results, than betting on my memory or even worst, having no idea something happened.
It also highly reduces the chance to catch a “in this very specific scenario, it fails”, because you missed it and don’t have the output history. Too bad!
Like at the end of the day, isn’t its history one of the core purpose of an output? With this mentality, shouldn’t we clear it every time there’s an error; to make it stand out!! /s
What I want to know is who are these developers @tnavarts is in contact with, and why they matter more then us? What is with this obsession with clearing the output, and not even giving us an option to disable it?
I don’t know if this update caused this problem, but now whenever I try to Emit a particle that’s not enabled it doesn’t emit. How would I fix this? Is this a bug?
