Important Script Source Update and New ScriptEditorService APIs

Updates Announcements
#22

Does this allow me to store anything I want of any size inside ModuleScripts now? Because that would be awesome.

All I need is something like .Source = but with no text limit

and Lua table with Roblox types stringifier

3 Likes
#23

There should honestly be a way to make a function a scripts source, seeing as it’s done perfectly find with task threads.

3 Likes
#24

I still don’t know if UpdateSourceAsync let’s you have more string characters than .Source.

I tried a very long for loop that adds a letter to add characters but that just crashed Studio… cuz… yeah

anything that UpdateSourceAsync returns gets replaced, so that’s good. In the callback it passes the “old content” as well as an argument.

If UpdateSourceAsync has no character limitation. Then it’s finally possible to be closer on creating an interactive Plugin to edit OBJECTS in Studio an save them in like JSON style.

Things like Color3.new() would have to be converted or something because it doesn’t exist in JSON. Unless I can dump it in a different way.

But I don’t know if it has a character limit. @bezzie_boi

3 Likes
#25

Hi @HealthyKarl,

The UpdateSourceAsync method is indeed more flexible than the Source property. Currently, we don’t impose strict limits on the new content size when set through the API. However, scripts are not designed to hold very large data since this can impact performance during network replication and typechecking in the script editor. We’re aware of this limitation and are exploring better solutions for such use cases.

5 Likes
#26

There’s ObjectValue | Documentation - Roblox Creator Hub

But if one would CTRL + X (cut) an Instance that is being pointed to by ObjectValue and re-paste it in, ObjectValue would still be pointing to an Instance in nil.

ObjectValue is also nil at the beginning. So ObjectValue for “linking” to Instances, needs to “loop wait” until not nil.

Instances can’t be stored in a plain text. Roblox does resolve them though into table keys though. Storing a BUNCH of “key values” for a single Instance that gets initialized into a customized Class, can only be done with those BaseValue instances.

But then you’d have to create one for each or make a Plugin automate it…

Using ModuleScripts to store data isn’t ideal either. If I store too much and want to use the Script Finder, it freaks out.

1 Like
#27

I dont mind the change, but there seems to be an issue where UpdateSourceAsync edits the wrong script source.

My plugin does this:

  • Get ModuleScript from replicated storage
  • Clone the module
  • Edit the cloned module’s source
  • Require the cloned module

However, if you have the original module opened in the script editor, the source of that one gets edited instead.

Is there a way around this?

2 Likes
#28

I can confirm this is a bug. It’s caused by the fact that the internal unique ID of a script only recomputes when the script is parented (causing the function to mistakenly believe the editor has the cloned script open, when the editor is actually looking at the original).

We will investigate and work on a fix. In the mean time you can work around this by parenting the script before passing it to this function.

7 Likes
#29

This should now be fixed after a Studio restart.

6 Likes
#33

Sorry for the late reply, but it still seems to be broken for me.

#34

I’ve double checked but it seems to be working for me. Could you post a video of what you’re doing? Perhaps I’m not understanding the repro steps quite right.

#35

I was able to find a simple repro. It seems like there was a small oversight where the bug is fixed only if you clone the module directly. If you clone the parent instance, the bug is still present.

Repro plugin:
testPlugin.rbxmx (1.8 KB)

Test module folder:
bug repro folder.rbxm (995 Bytes)

Throw the folder into workspace, and then click the plugin button. Everything works fine if you dont have the module from the folder open, but if you DO have it open, the original source gets edited.

#36

I see. We’ll take another look, thanks.

1 Like