@tnavarts Lately ever since this update I have been having a weird issue on macOS.
When I play dusty trip after I reach around 13000m or so there everything just bugs out becomes fully black. You would think that this is a dusty trip problem but my entire client freezes, no longer responds and the app doesn’t even close I just have to force quit it.
This has happened to me around 4 times now and has happened every single time that I reach around 10000m or so. Seems to have an issue when I get far away from spawn or something???
And hell lord how am I even supposed to debug this and provide a client log to really figure out what the issue is this. I already have tried fully deleting and reinstalling the Roblox app.
This isn’t quite the takeaway. I should clarify, that ModuleScripts were always garbage collected. Unfortunately, there’s an edge-case, in that unsolvable cyclic references are formed by modules which return a reference to themselves. While this is dangerous by itself, it generally wouldn’t be too problematic, if not for the major oversight, that any functions the module returns, hold a reference back to the module instance, due to the script variable being present in the global environment.
A more generally efficacious solution, would be to simply undefine this variable. By doing this, and taking care not to reference the module instance somewhere it might (directly or indirectly) be caught in its return, you’d effectively avoid this risk of memory leakage entirely—regardless of whether or not the module is ever destroyed.
The change covered in this release note, is really at-most a patch, which will only address the issue in most cases—those where destroy will reliably be called following the module being required, and where no other references to the result persist at the time of this happening. Even if scripters plan to rely on this behavior, they should still be aware of the potential pitfall.
I’ve been fiddling around with CreateMeshPartAsync from the client on a live game (enabling the fflag), I’ve noticed that a CreateMeshPartAsync call is quite expensive (give or take an order of magnitude more expensive than creating Instances or cloning and parenting existing MeshParts).
Is this something that could be optimized, or is it just the consequence of having to parse the received mesh data? My meshes are using CollisionFidelity.Box and RenderFidelity.Precise (and CanCollide, CanQuery, CanTouch are set to false and Anchored is set to true…)
It is a little bit surprising that it has that much synchronous work to do, I wouldn’t have expected it to be that much of a difference. It is doing the real expensive work on the background thread, otherwise you would see actual frame drops. I’ll see if I can profile when I have time.
