Can we get a feature to be able to disable Roblox’s autosmoothing when applying layered clothing? I have custom vertex normals on my ugc bundle and it gets replaced when something with wraplayer is worn. I would’ve posted this in feature requests but apparently I can’t create a topic there.
1 Like
It’s for memory leaks specifically with requiring modules when they shouldn’t be. If the module is destroyed and should be forgotten, this require will error and tell me about the leak. It’s very specific so it won’t help much people in that way!
2 Likes
The main intent is the Instance field letting you mix cloud and experience local accessories without having to go off the beaten path and write your own system.
7 Likes
sorry to say this but apparently 50k bad programmers already can use requires and delete them and know how to use a stop function in a module.
your running requires are memory leaking…? optimize your scripts please.
dont get how you’re a programmer when you cant make a stopfunction
2 Likes
Clearly you haven’t spent enough time with modules. They will bless you with a few bad behaviors eventually. I’ll let you discover them on your own!
2 Likes
bad behaviors? i see requires still being able to run while destroyed as intended behavior. i use modules regularly and using destroyed modules is a thing i do quite often. i have never had memory leaking issues because i keep track of all my variables and am able to discard all of them if needed. those memory leaks are you talk about are your problem. please consider keeping track of everything that goes on in a modulescript if you have such problems
1 Like
…which is stupid in my opinion. Those are the memory leaks I’m talking about. When I destroy scripts, I expect them to stop persisting. If they don’t stop, it can break my game.
1 Like
thats because modulescripts load into memory and it has been this way for years and developers make their games with this in the back of their mind. its good practice to take care of all the memory aspects as best as you can by yourself so the bad practice is really on your part. if you call a function from a modulescript it runs in the script that called it, so that script has to be destroyed too.
1 Like
There’s a reason the release note starts out “Potential impact will be measured first”.
Sometimes we give bolder changes with big benefits but also big breakage potential a try. When we do that we make sure to get analytics on what the impact will be like, and often those analytics tell us that there would be too much breakage for the change to be viable.
My favorite example:
Ever done this? Vector3.new(myVarible1, 0, myVariable2) …note the misspelling? Yeah, well, it won’t error, the X component will just silently always be zero. We tried really hard to change that but no matter what approach we cooked up the analytics said it would just break too much stuff so we’re stuck with that behavior of nil meaning 0 rather than being an error in the Vector3 constructor.
12 Likes
Can this be reconsidered or made an option? My script builder game heavily relies on running destroyed modules to prevent them from being altered or accessed. Having them run under DataModel would be subject to attacks from other scripts.
1 Like
If you require a ModuleScript before destroying it, you will still be able to use it.
5 Likes
Will it work if I try to require() it again?
1 Like
Why even disallow this from being done in the first place? It doesn’t have any significant negative impacts on the game and will do more harm than good to developers.
And, you can require the module before destroying it as mentioned in a previous post, so what’s the point in even doing this then?
3 Likes
No, it will throw an error.
It’s fixes one of the memory leaks on the whole platform.
Unlikely. Just don’t destroy a module if you plan to require it again.
5 Likes
How would this cause a memory leak? I’m pretty sure it should be GC’d if there are no references to the module left. If a script holds a reference to it, then the module should work normally.
3 Likes
What? Is there no other way to prevent this from memory leaking? Do you really have to completely prevent it from being done altogether?
You say this whilst having a vague grasp of how often it is used, as only a few developers have commented on this page.
why should using require() on a module that has been previously required and subsequently destroyed cause require to error? if the module has been required and is running and continues to run after it is destroyed, why should require() error on it as if there is an issue with it when there is actually no issue?
1 Like
mate, if it was already destroyed you can’t even import it anyways
also who relies on this behavior, literally no one (unless you do not care about memory leaks like a pro!!! 
)
um actually require() works perfectly fine if you have a variable for the module and works as usual as long as you dont have any descendants in it that it depends on
1 Like
If it wasn’t intentional then it wouldn’t work. Also, the basis of common knowledge is subjective.
*Scripting
Three years is not enough to know every minute aspect of LuaU, especially due to it still being constantly developed.