Release Notes for 596

[TheTrollock]

Will it work if I try to require() it again?

[homersimpson_num1fan]

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?

[WheretIB]

@TheTrollock

Will it work if I try to require() it again?

No, it will throw an error.

@homersimpson_num1fan

Why even disallow this from being done in the first place? It doesn’t have any significant negative impacts on the game

It’s fixes one of the memory leaks on the whole platform.

@homersimpson_num1fan

and will do more harm than good to developers.

Unlikely. Just don’t destroy a module if you plan to require it again.

[TheTrollock]

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.

[homersimpson_num1fan]

@WheretIB

It’s fixes one of the memory leaks on the whole platform.

What? Is there no other way to prevent this from memory leaking? Do you really have to completely prevent it from being done altogether?

@WheretIB

Unlikely. Just don’t destroy a module if you plan to require it again.

You say this whilst having a vague grasp of how often it is used, as only a few developers have commented on this page.

[ceat_ceat]

@WheretIB

Unlikely. Just don’t destroy a module if you plan to require it again.

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?

[2jammers]

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!!! )

[ceat_ceat]

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

[homersimpson_num1fan]

@2jammers

you shouldn’t be relying on not intentionally supported behavior, it’s common knowledge.

If it wasn’t intentional then it wouldn’t work. Also, the basis of common knowledge is subjective.

@2jammers

programming

*Scripting

@2jammers

and I have already educated myself

Three years is not enough to know every minute aspect of LuaU, especially due to it still being constantly developed.

[2jammers]

@homersimpson_num1fan

If it wasn’t intentional then it wouldn’t work. Also, the basis of common knowledge is subjective.

It was obviously an obscure bug?

@homersimpson_num1fan

*Scripting

I do know other langs, ands they aren’t just scripting languages.

@homersimpson_num1fan

Three years is not enough to know every minute aspect of LuaU, especially due to it still being constantly developed.

You can never know, how can you expect that?

[ceat_ceat]

it seemed more like an intentional thing to me idk it just always kinda clicked to me that yeah it behaves like that so it looks more like intended behavior to me

[homersimpson_num1fan]

@2jammers

It was obviously an obscure bug?

It’s not a bug…

@2jammers

You can never know, how can you expect that?

The limitations of memory.

[2jammers]

Destroy means to get rid of and no longer use. If you wanted to require it again just don’t remove it.

Using it as a way to protect your game will literally do nothing, exploiters can access anything local.

[ceat_ceat]

i use this behavior to protect server scripts on script executor games so it does protect the game

[Judgy_Oreo (DisplayName)]

@homersimpson_num1fan

If it wasn’t intentional then it wouldn’t work

That’s literally what a bug is though? It’s unintentional, but it will occur. Only Roblox has the analytics to say that this issue is causing a memory leak.

@homersimpson_num1fan

It’s not a bug…

Clearly it is, they are fixing (or “Improving” as the Release Notes say) the behaviour because it was not their intention for modules to be requirable after it has been “destroyed” (which logically would mean gotten-rid-of).

@ceat_ceat

it seemed more like an intentional thing

It just doesn’t make sense to me, why would you get rid of something you are actively using?

@homersimpson_num1fan

*Scripting

??? At the end of the day, the sentence “scripting behaviour” and “programming behaviour” are practically identical and convey the exact same message, no matter the small semantic difference between them.

@ceat_ceat

i use this behavior to protect server scripts on script executor games so it does protect the game

Why not prevent them from requireing modules outside a certain scope? If they don’t need to, then why not prevent them from calling require at all? What if a script runs after a module it needs to require is deleted?

[nonamehd24]

Being able require something after it has been destroyed is like the dumbest thing ever. When I say Destroy(), I really mean destroy this object and remove it from memory.

[shadowflame63 (MiniiMann)]

@tnavarts

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.

Could there not be a Enabled property on module scripts, the same way normal scripts have?

Or a similar property that when toggled determines whether the module is ‘frozen’ or not. The module is paused (not restarted unlike scripts), and any requires are rejected. If there are no references to the module, as in its been deleted and all previously accepted require references have been gc’d, and this property is enabled then the whole module is gc’d rather than left to run in the background.

[2jammers]

I think a better property would be a RunContext property

[TheTrollock]

Sorry for the bump, will this behaviour also be true for modules loaded through require(assetId)?
It wouldn’t make sense to make this error because you could simply destroy that script (get the ModuleScript through getfenv or ScriptContext.Error) and make the module completely unusable.

[WheretIB]

But why would you destroy your module and make it unusable for yourself?
If you have malicious/virus code in your experience destroying modules, that’s already a bigger problem.

I’m probably misunderstanding the use case here.