Require( assetId, ignoreCache ) or something similar

Feature Requests Engine Features
#7

If I made a new model for every update I’d end up with an inventory full of models that I’d have to scroll past when I upload models

#8

You can delete models from your inventory.

#9

You can’t delete them entirely though, like, they still appear in the models list when you upload a model. Or has this changed?

EDIT:
Yeah, you still can’t actually delete them, just ‘untake’ them ( I don’t ‘own’ the red ones yet they still appear in my develop window, etc )

688×802 48.9 KB

#10

Do this when you want to look at your own models:

#11

I understand that but when you upload a model from studio it displays any that you created, even if you ‘deleted’ them e.g. ( Red ones are models I deleted )

1039×696 156 KB

So if I did make a new model for every update it would fill up that screen and make it a pain in the ass to upload models

1 Like
#12

I wasn’t disagreeing with the OP, I was just trying to give a temporary workaround.

Add requirelatest(ID) to re-require() the latest version of a MainModule
#13

Sorry, I know, I didn’t mean to sound like I was arguing with you, I was just letting you know why the workaround isn’t ideal / why I wouldn’t use it

#14

Bump, really need this

#15

What’s your use case? It’s unlikely that this will be implemented if you don’t explain when this would be useful. You can already do this for your own modules using LoadAssetVersion. Using modules required by AssetId made by someone else is an attack vector against your game and you shouldn’t do it, my personal opinion is that we shouldn’t add any more features to support this.

#16

Things like auto updating admin commands, etc

The current way with insertservice requires the asset be owned and requires it be inserted, moved out of the model that its inserted in and then required

#17

This does not seem like a good use case to me, you should not allow any code run in your game unless you have wrote the code yourself or audited the code to make sure it’s ok. Using auto updating admin commands is insane, even if the creator of the commands is not malicious their account can be compromised or they can make an update that conflicts with the existing code in your game and cause bugs.

With the new chat we increased the maximum amount of characters a player could chat from 140 to 200 characters. In a popular admin command script there was a check if a message from a player contained more than 160 characters, if it did it kicked the player from the game. This command script was being used in at least one front page game. You shouldn’t put thousands of lines of code you haven’t read into your game, it’s even worse if it is auto updating.

I think we should probably break require for assetIds the creator doesn’t own, it’s too much of an attack vector against games that use it.

2 Likes
#18

I agree that the person should have to own it, however if that’s implemented I see no reason not to allow us to require the latest version directly as we can already do it with insertservice?

#19

This would ruin require() in script builders, as the owner of the script builder would have to own the module and I prefer my script builder modules closed-source.

If you’re going to implement this change, please add a game configuration option to allow unowned modules.

3 Likes
#20

I have to admit that I like the fact you can use require( ) in any game however it opens up MASSIVE security risks for even FE games which is not good. It basically entirely circumvents the restrictions put on the InsertService…

#21

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
#22

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
#23

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.

#24

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
#25

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().

#26

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.