An equivilant of game:GetObjects() for scripts

As a Roblox developer, it is currently hard to implement a way to transfer something a different user made in studio to your game.

For example, currently I am having a problem with transfering a user-made level from studio to my game, for more detail and more info, check out the post linked below.

Long story short, instead of using InsertService in this case, I am forced to serialize the said level and save it on a 3rd-party hosting service, then I would give an ID to the user, and back in the game, the user would pass the server that ID and load up the level.

Thus, to avoid all the trouble 3rd-party services might impose and to allow developers to do such things way more easily, reliably and faster, I suggest that InsertService receives a new method or that InsertService:LoadAsset() receives an update.

Since InsertService already had this functionality available before, it shouldn’t be much work (I guess) to reintroduce the previous functionality of it, in some different form.

Whether InsertService:LoadAsset() receives an update, or a new method is added, the new functionality of that method should be fairly similar to game:GetObjects(), originally, InsertService:LoadAsset() was able to load free models which are not owned by the game’s creator directly, most likely the restrictions we have nowadays are made to prevent “Virus” models and them Inserting other malicious scripts,…

In order to keep that security, I suggest…

InsertService:LoadAsset(assetId: number, assetLoadFilter: Enum.AssetLoadFilter)


InsertService:LoadAsset(assetId: number, classWhitelist: {} or classBlacklist: {})

Enum.AssetLoadFilter consisting of the following enums…

Enum.AssetLoadFilter.Default (DisallowScripts)

Or classWhitelist/classBlacklist table consisting of ClassNames which are to be loaded or not.

If the developer allows scripts in any of these two methods, the method should function as it functions today (only allows models made or directly owned by the owner), but if the user disallows scripts, only the model should be loaded regardless if the model is made or directly owned by the owner. (Note that the asset at that point should be free)


I think a simpler solution would just be to re-implement AllowInsertFreeModels, it was a property that previously (when enabled) would allow FreeModels to be inserted regardless of whether the owner of the experience owned them or not, it has since fallen into dis-repair and is no longer functional. :frowning:

However, with the addition of RunContext since, I would certainly feel more safe with some way to disable scripts that come from InsertService:LoadAsset() by default, just for peace of mind! :sweat_smile:


Didn’t also ApproveAssetId() work for some time or am I mistaken?

Either way, they should consider allowing developers to insert free models yet again, whatever their solution for scripts might be. Your suggestion of disabling all scripts from free models also sounds like a great idea, but in the end whatever they choose if a win win for everybody.

Currently because of this limitation, in my case, I am forced to serialize the level and send it over with ModuleScripts, if there was any way to get free models it would be easier for me and the player’s creating those levels, other developers too would far more easily be able to enable their players to create additional content for their games too…



It’s up to the developer to be able to be responsible with the objects they insert without having to restrict what we are able to insert into our games. Being able to insert anything without creating a custom rbxm parser (which has a bunch of downsides of not being able to use MeshParts or Unions) is a dream come true.

If some engineer is still not convinced. AllowInsertFreeModels would be a good compromise for people who know what they’re doing. If ServerScriptService.LoadStringEnabled can exist then so should something that can open up so much potential to expand the game’s community engagement.

1 Like

Bumping this topic because I really dislike the security limitation Roblox has done.

If Roblox has done things such as loadstring, third party teleports, and http requests as an option, why can’t InsertService just be one?

The security attempt you’ve done seems like a great attempt and I have full support for it if it comes out. Having the option to allow and disallow scripts is a better type of security (and including the fact you can whitelist and blacklist instances).

Options for player creativity have never felt and been so limited and I think if they release the gates for this, player creativity might be way more huge than ever.

Now, I’m forced to use some API webhook, or bot to buy the models to even get this to work.

I’ve seen games like Typical Colors 2 find out a way to insert models with IDs with flaws such as unions messing up since it isn’t really grabbing from the real model.

InsertService has always been so useless, the only real use for it are catalog games, but that’s really it. InsertService inserting things made by me is completely useless since I could just import them myself and parent them to ServerStorage or ReplicatedStorage.

1 Like