Under Studio Settings>Studio>General the option to “Always Save Script Changes” no longer has the correct behaviour when edits are made during play-testing. While I’m not exactly sure when this issue started occurring (assuming it would be fixed), it has become enough of a disturbance to my workflow over the past few months that it felt necessary to report. An identical report was made this past February and marked as “Fixed” despite the issue still being present.
While in play-testing with the “Always Save Script Changes” option toggled on, any debugs or changes made to scripts by clicking on errors/warnings in the output should reflected when the game is stopped. While Server Scripts handle such changes fine, local scripts/replicated scripts/modules do not retain any edits. This is particularly bothersome when trying to debug quickly. First, having to identify the line of the error, stop play-testing, and only then make the necessary changes. The past behaviour would allow changes made during play-testing to remain after stop is pressed.
I don’t believe that this behaviour is intended, or at least, not as it was before. If the answer is that this is simply one of the quirks of how the script editor handles source changes to replicated scripts, it almost certainly contradicts the past behaviour. The option to enable “Always Save Script Changes” when changes are made to Local Scripts suggests that these changes are supposed to be saved when making changes to Local Scripts and yet they are not.
Testing a Local Script that prints or errors will let us to make changes by accessing it though the output. After making the desired changes the following dialogue will be prompted (if never shown before). Selecting either “Yes” or “Always Save” does nothing to keep the changes you made.
When editing a Local Script outside of the runtime the top bar should look something like this. Changes made here will be saved.
When accessing the Local Script through an error or warning during runtime the tab is MODIFIED to indicate that is the script as replicated by the client. It DOES NOT POPULATE A NEW TAB.
This would lead us the believe that changes we make to the source during runtime are carried over, as is the case with server scripts that have the corresponding “Server” icon when accessed through the output.
Unfortunately, this is not the case with Local Scripts. Addressing the issue by restoring the expected behaviour would be appreciated as debugging is incredibly bothersome without changes being saved.
Hi. Issue was initially fixed for me, but then later, it reappeared on client scripts. I messaged guy who answered me in that bug report, and he said this:
Interesting, I also recall getting this error. The reason given makes perfect sense as well, still I have to wonder why because I’m certain changes saved before.
In short - this error occurs when script gets cloned and parented to somewhere. You edit copy of script and not script itself and due to this you receive this error. Previously, this was somehow handled, but now not.
This brings up an interesting question: let’s say we figure out where cloned scripts are coming from, after stopping Play Solo. What if you edited multiple scripts by mistake (by clicking on the Output widget you get different parts of multiple cloned scripts) – resulting in conflicting versions of the same script.
How would you reconcile the conflicting changes? It’s possible that there are a few dozen changes in a few dozen scripts which makes merging potentially challenging.
You raise a really great point. When making this post I only really considered the scripts first replicated such as those carried over from StarterPlayer and StarterGUI to the LocalPlayer. These are easy enough to trace back from where they originated to apply the changes. In any case however, you’re right, there are complications introduced when scripts start to get cloned. I’m not sure what the behaviour looks like for “Always Save Script Changes” on the server side when dealing with cloned scripts, keeping in mind that server scripts do not have the same issue. I’d propose that clicking on the output for a cloned local script links back to the instance it was cloned from, that way you’re adding all your edits to the same source. For both cloned and un-cloned scripts Its worth considering that as soon as you make any edits, new errors in the output linking to the same script may have the line numbers off, though I think this is already one of the quirks when making changes to a server script from the output which is a fine behaviour so this may be redundant.
Sounds reasonable, so practically we would always apply the latest edit to the original script (given that at Test time there is no Edit datamodel).
As a first pass we’ll communicate better about when a change would not be applied. A second pass will do the applying of the latest changes only with proper messaging stating that only the latest changes will be saved for each LocalScript. It is possible that we’ll have to show the same message Server and ModuleScripts as well.
I certainly like the idea of having transparent messaging to help let users know which changes are going to be applied if there is a conflict. If I’m understanding what you’re getting at, edits to a cloned script will only be applied to the original script if it was the last instance to be edited. And, if you were to switch between two scripts cloned from the same source, then made edits to both, a message would interject to say that only edits made to the clone you last edited will be applied. I believe this is slightly different from what I was trying to explain where essentially the sources of both the original script and cloned scripts would be linked, and changes to one would be reflected in the rest. However, the behaviour you’ve described seems more desirable as it be simpler to implement. Having all the sources change synchronously might only cause confusion. I know what you’ve described will certainly be more than adequate for my own use as a tend to avoid cloning scripts anyways.
I think that what you’ve outlined would be a great way to approach script edits. I’d only add that messages should only be displayed IF the user is doing something that might cause edits to be lost/cause a conflict. Otherwise it would be annoying to make edits to a single instance and having to say “yes I want to make these changes” each time.
Thank you, I added this info into our internal ticket and this is now in the backlog. We don’t have an exact schedule for this yet but will prioritize it higher given the impact.
