It’s not really a good idea to invite people to shoot themselves in the foot in order to support such a niche case, so I can’t really agree with this proposal.
4 Likes
Everyone is overexaggerating the dangers of require, there is no way for an exploiter to use require() as it can only be used serverside. Enabling it for unowned modules would not be shooting yourself in the foot.
2 Likes
A random exploiter coming into your game and requiring a module isn’t really the concern here. There have been cases in the past where a private module was used in many games and was maliciously edited by its owner. Running code you can’t see in your game has never been a good idea.
I think the concern isn’t that exploiters will take advantage of them, but as @TheGamer101 mentioned even a trustworthy person could have their account compromised and your game could be next on the list since that person has server script privileges to your game through the module.
That being said, I rarely see private modules being used for features the creator could just as easily create. If it’s an option between having a game that’s vulnerable and not having a feature that’s likely critical to the success of the game, I’m sure most sensible people would choose the former. It sucks that they don’t have access to the source code, but they’re taking what they can get.
I don’t agree with how bad this is considering I’m typing this on a closed-source auto-updating Windows 10 machine which could receive bad updates due to a compromise in Microsoft’s security. It all comes down to whether or not there is enough demand for the feature, but so far there doesn’t seem to be much.
2 Likes
I use it alot in script builders, and I know there’s other people who do.
The admin scripts being used across thousands of games have their source loaded by require().
But do any of them actually need to auto-update while the game is running?
You’re right, there are other people who use it in script builders. There are also immeasurably more people that this wouldn’t benefit at all, so even if you can make a strong enough case for the feature, it’ll never be high enough of a priority that ROBLOX would implement something just for script builders. Loadstring was disabled, even though it was used in script builders, for instance.
No, the latest version is loaded upon the server starting, and some admin scripts are closed-source.
Disabled, it’s still usable if toggled in ServerScriptService and after closing a pop-up warning. I’m hoping the same can be done in this case.
That setting is for clientside loadstring – serverside loadstring is completely gone.
So then they have no use for busting the cache on require
I think they want to have it auto-updating, but can’t because of the cache.
And that setting is for serverside loadstring, not clientside.
For the whole “private modules aren’t secure” discussion:
Admin scripts would go back to the old days of using LoadAsset to auto-update. It’ll affect less people, as the model has to be taken, but still. If you care about your game being 100% secure, just don’t use private modules. Otherwise, do what you want.
On-topic:
I’m more worried about what require() will do/return when it loads a module for the second time. Will the first “runtime” be terminated? Or is it like “Reload script” in studio that just clears the cache value and re-requires it (but the new version this time)? I’m not entirely sure if I’ll use this (but auto-updating certain modules sounds fun), but might be handy.
ROBLOX actually has a built-in update mechanism for modulescripts that return tables. If you have a modulescript that returns a table and you reload it in studio, the old table is cleared and filled with the key/value-pairs of the new table. In that case, having local idk = require(...) and using idk.whatever() would automatically use the new method. again: this is already happening in studio, not an addition to this feature I’m inventing
It wouldn’t affect previously required objects, it’d just be a way to require the latest version.
Exactly. The whole “two versions running at once” might be a problem if your module starts threads and connects events etc.
Well, the same would happen if you just insert the latest version and require it that way. Seems like a non-issue, if they’re using this without cache they should handle cleaning up the old module.