Im sorry? What? Banning REQUIRE() from freemodels? Because “the majority of uses are malicious”? Have you guys completely lost your mind and understanding of YOUR OWN platform? Like, what the hell made you come up with that?
“hmm yes a single malicious require() was reposted a lot of times so lets ban all requiring from freemodels instead of making efficient ways of warning people of the said requires, previewing the contents of the required assets and such”. Yeah, lets COMPLETELY disregard all the auto updates and easy set up because a bunch of people who launched studio 2 days ago weren’t aware of requires (which is also on Roblox). Thanks! What a useful update! Lets continue demolishing everything on Roblox while putting new features over it until it turns into an average complicated game engine for a bunch of developers that joined in 2020! Completely ignoring everyone else on this platform, besides those guys that are gonna be happy about every game killing update because they have zero connection to Roblox outside of their own questionable simulator projects. This is absolutely stupid.
Reusable Packages have the potential to be incredibly useful, they’re just lacking in Access Permissions right now:
Currently you (the package creator) have to grant manual access to others, or the user has to join your group (but even then there’s no view-only option). These aren’t scalable. They could be if there was a third option where anyone can use your package.
We’d quite like to take a hybrid approach with Nanoblox where we use a plugin to install the application, then the bulk of the application itself functions under a package where users can toggle AutoUpdate on.
Maybe we’ll see some future changes to this current set of permissions @nsgriff?
These functions still have people using it in a valid use-case however, you shouldn’t lock down a feature just because it’s ‘mostly used for malicious behaviour’, you should instead look for options that don’t further limit your platform!
This is a major step-back in my opinion, sure we should be given more control over what assets do in our experience, but just blocking requires from toolbox models is not the way to do it, make it an option. Like how loadstring must be enabled manually by the developer, if I wish to allow the use of a require I should be allowed to do so.
Okay, this is actually a good update but I’ve noticed that you guys seem to be using an automated system for this, which could come up with a few false-positives…
Also, just to ask does the ‘require’ security also apply to in-game scripts, since you only seem to mention that the obfuscated code only applies to public toolbox assets?
Yet again, ROBLOX seems to dislike the existence of paid subscription service based assets, Sandboxing is a high demand feature that was promised over 2 years ago when removing closed source third party modules. It was stated that these could be reintroduced once a sandbox system was in place however, this has still not come to fruition. I highly agree with @ForeverHD’s proposition of a fully sandboxed permission based system to control what scripts are able to access what APIs. Having game-wide loadstring, http, and teleportservice toggles causes a security risk when only one script needs such functionality.
Outside of Sandboxing, increasing model safety by disallowing obfuscation and require() functions even if they are open source, again kills paid-subscription based assets and stunts the ability to update models easily. Admin systems will be unable to update to fix possible security vulnerabilities or update features on what users want on demand.
Still, I am waiting to this day for a step forward on sandboxing and allowing at least some way for paid-subscription based models to continue their services without needing obfuscation to do it. Now, this change seems like a step backward and in the wrong direction of actual model security and safety.
If you wish to type in the require command yourself in your game, you are allowed to do so.
I thought obfuscation was already against TOS, no? Just because people are doing it doesn’t mean it is allowed. I don’t’ know, I’m asking.
Maybe it isn’t against TOS, but this popup warning implies that it is:
Yeah, but I should also be authorised to allow other modules do it.
I wonder if they will permit commented out require statements. Where you could go into a setup script of some sort and uncomment the line to enable the functionality.
Not ideal, but maybe an option.
what are we supposed to do about version checkers? often you would require a module that would return something like Version = “2.0b”, and now that would be impossible without using Marketplaceservice and having different assets to do different stuff, which was otherwise possible in a module
Another
stupid
update.
Just give us a warning if the model has getfenv, setfenv, or requires something it’s really that easy
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
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.
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.
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) 
No, just stop, this is going to break stuff like A-Chassis 6 Clutch and a bunch of other things, like, bruh