Solid hotfixes!
This will be good for fixing some bugs in my game:
It will point out memory leaks, which is nice.
This will help new scripters a bit!
Not sure if this is the right place to ask this but how exactly do you benefit for this? How can you find memory leaks with this?
It’s a new property under Workspace! Set it to Enabled
to enable it. The feature is super cool - it’s like Google Docs but in Roblox Studio scripts. Cannot wait to make use of it.
Nice to see more types being updated to reflect what they return
I replied to a previous release notes post asking about PerAxis being added for AlignOrientation, could we get an update on whether this is being considered or not?
Question was answered in a Q&A, and it is planned:
Solid set of fixes, thanks so much!
This looks pretty helpful. I’m not sure what the intent of it is, but what would be really nice is if we can query the information of accessories worn on avatar and ideally have a property that determines the accessory’s creator by UserId. I’d like to delete all non-Roblox-created UGC in my experiences due to concerns with UGC creators and the accessories they’re uploading being gamebreaking while it being difficult to actually handle these cases automatically without significant external services strain.
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.
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!
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.
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
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!
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
…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.
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.
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.
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.
If you require a ModuleScript before destroying it, you will still be able to use it.