Creator Marketplace: Improving Model Safety

first they destroy audios, and now they remove requires. god this platform gets worse with each and every update.

just make a game setting to disable these instead of making them unusable

3 Likes

A warning won’t stop a noob from using it and getting an account termination causing tears and parent outrage.

Maybe better moderation and not banning users for inserting models into their game will work.

Maybe just a different type of account warning or message telling you to delete the asset from your game.

That still wouldn’t prevent the offensive item from appearing in some game for some amount of time.

Prevention is better than cleanup.

Then that’s on them.
Noob or not, if you don’t bother to read a warning, you’re the only one to blame.

1 Like

It’s on roblox if that asset got past their moderation anyways.

Well now its on Roblox to prevent you from require(id) thanks exploit creators, thanks a lot!

I’m interested to know what prompted this, or more-so how much planning went into this change. Like all major changes, this should’ve been announced weeks ahead of time to allow room for feedback, and more importantly, adaptations from the developer’s side.

3 Likes

I too use getfenv and setfenv quite frequently in my code. Disabling this is not just obnoxious, it’s incredibly upsetting.

So for example a car model currently in the library that has it’s operational script as a require(id), will the entire car model vanish from the library? Or will it just become non-functional(the script will vanish).

(didn’t mean to reply to you Scoot) :slight_smile:

1 Like

No, just stop, this is going to break stuff like A-Chassis 6 Clutch and a bunch of other things, like, bruh

Once again, an issue that would of been resolved long ago.

Just give users to uniquely allow certain require id’s.

Stop harming the community that makes tools.

All this will do is make people upload their scripts off the Roblox site and try to use a lua pharser to execute their scripts.

Are you going to block HttpService requests next?

3 Likes

This update has to be even dumber than the audio update, both updates could have been taken care off differently and better lol, litteraly, just put a warning when they insert a model notifying them it has a require() or a getfenv(), if they still insert it and there happens to be a virus in it, thats THEIR fault, you can’t just destroy the platform for developers because of a few foolish people on studio inserting virusses bruh

You can’t seriously expect a popup warning to prevent something from happening. Who’s fault it is isn’t going to matter, its spreading malicious code.

You can’t expect a 9 year old kid or even their non-coding parent to have any idea what getfenv(), require(), etc. even mean. Oh, so some library items are fine to click through that warning and some are not, which ones are fine?

A warning is not a solution.

Thank you so much for the feedback on today’s update. After reading your comments we realize that our initial announcement wasn’t as thorough as it could be. We want to take a moment to address some of the concerns we’re seeing.

These changes are focused completely on the Creator Marketplace. Assets that include the use of these features will not be included in Marketplace Search. We are not disabling any functionality nor are any assets currently using these features being removed or moderated.

These changes are part of an effort leading us to a future where Marketplace Search contains assets that we feel confident are safe for use and you can feel confident in as well.

We appreciate your feedback and will continue to monitor this thread.

29 Likes

Speaking for many others who share similar interests as I do, this update is terrible. Many of us upload modules to be required which depend on other modules that are required and many of us have custom sandboxed elements to allow for a much more customised lua experience. I can provide a simple example:
I wanted to rewrite the math.sqrt function to work for all numbers and not just real numbers (as well as add an nthroot function to the math library), keeping all the functions within the math library for ease of use. To accomplish this, I must utilise setfenv in my script to set a metatable on the current script’s environment, allowing me to replace math.sqrt with my own custom square root function. This works, but with this new update I cannot publish this to the creator marketplace without getting banned (if I wished to do so).

This update simply is much more punishing for all developers as setfenv/getfenv and require are the two most lenient functions, allowing for the coolest stuff to be made in roblox lua.
The best way for this to be handled it to warn users about a potentially harmful module using a trained algorithm. Removing after detecting with the algorithm would be a mistake as false positives may be a thing. This fosters creativity through encouraging the use of setfenv/getfenv and require, whilst also protecting those who are genuinely about to insert a virus into their game.

2 Likes

If Roblox really wants to make their creator marketplace better, they need to work more on providing logs for what the scripts in a users game is doing, instead of outright blocking developers ability to use these features.

A simple page of ‘audit log’ style script events, such as
‘Workspace.FreeModel Car.Script’ has used ‘Kick’ on ‘BlarBlix’-------------- [ disable ]
‘Workspace.FreeModel Car.Script’ has used ‘require’ -------------------------- [ disable ]
‘Workspace.FreeModel Car.Script’ has used datastore scope ‘k1234Ga’ - [ disable ]
‘Workspace.FreeModel Car.Script’ has used httpservice for domain ‘hehebloxbuilder()com’ - [ disable ]

and clicking disable simply removes/disables that script in your game for you.

I mean, Roblox did say they would work on sandbox style for scripts ever since they removed closed source modules… probably for exactly the same reason they’re now restricting new developers from making tools that can self auto-update and letting other tools like Adonis slide by anyway.

December 2018.
Providing sandboxing for scripts so that developers have full control over what code they import can do in their game. This may eventually allow us to reintroduce closed source modules once we have put certain safeguards in place.
Allowing creators to share code and other assets with specific users instead of the entire platform.

Good-bye to auto updating modules incase Roblox does an update. It’ll be up to the game developer to re-insert a module, maybe twice, four times even, anytime Roblox breaks anything.

And if Roblox really doesn’t sidetrack for at least ONE BIT. I really don’t see Roblox listening to the community at all. They’re just doing quick fixes to fix the issues of backdoors at hand, instead of focusing on the people who got affected and helping them with better and easier tools.

Instead of blocking users from being able to do something. Maybe make it easier to know what that something it’s trying to do.

7 Likes

I personally use require(id) for version control in my matchmaking service. I feel retroactively doing this to pre-existing models is very harmful. Why not just allow creators to block an id-based require at a lower level in their game… We have the option to disable marketplace for things we don’t own why not just add another option “Allow require(id) syntax”

1 Like

Your response is appreciated, but it doesn’t really give us anything really positive enough to change our opinions all that much.

I haven’t heard of any lawsuits lately, so I can’t imagine this update is being forced upon us for that. I think it’s a bit absurd to only give us a day, if that, to do anything about it. From looking through this thread, I’ve noticed that a lot of people rely on require() and even getfenv for tools and such.

From what I can tell, this has been your only response on a thread that already has 120+ reactions to it. We should be getting more transparency than just this one message from a staff member, but I suppose it’s better than nothing probably.

Your statement still doesn’t say that “we’ll consider looking into more options”, because I’m sure that’s not even being considered at the moment. We can’t really get comfortable with an update like this when it blocks people from uploading models that use require() or getfenv entirely. Just because some idiots decided it would be “funny” to abuse those two things to make and put malicious scripts in models doesn’t mean we should all suffer.

The title doesn’t help either as it makes it sound like this update is helping us, when in reality it’s restricting us more than anything. The mostly negative response should be a red flag, too.

In the end, the only ones who are winning are the people who are doing what you’re trying to prevent. We’re certainly not winning, even if we’re supposed to be.

8 Likes

Warning or not, just removing another feature because malicious people are using it is not the answer.

They already did that to private modules, said they would bring it back. But uh, that been since 2018 and no solution brought yet.

3 Likes