A mime type representing that the current DataModel’s Selection is the thing being dragged, which various pieces of Studio like the new Explorer will follow as a convention.
You can’t send Instance references through a system-level Drag-n-Drop so an alternative mechanism is needed to communicate dragging of the selection.
While this isn’t an official answer, it’s important to recognize that in coding, there are often numerous ways to reach a solution, and many can be optimized significantly using techniques like caching, divide-and-conquer, dynamic programming, memoization, and even parallel processing in some cases.
For instance, various search algorithms—like linear search, binary search, and hash-based search—perform differently based on the structure and size of the input. Each algorithm has strengths suited to particular types of data, and choosing the right one can make a major difference in efficiency.
In short, runtime optimization is essential for effective code, and understanding concepts like Big O notation, amortized analysis, and space-time trade-offs can help you make well-informed decisions about the best approach for any given problem.
My guess is InvalidatedFastClusters, basically, from my understanding, there is some precalculation/cached stuff to models containing a humanoid, to make their rendering faster. However, updating things inside the humanoid causes it to recalculate stuff, leading to lag spikes (or general lag) when doing frequent visual updates to characters
Would be nice if an engineer could confirm, or tell what RenderingCacheOptimizations is for
What you’re thinking of is our internal IsA being O(1), but that’s because we already know the classes and such in advance at compile time. The Luau method wasn’t quite so brilliant. The optimization was a pretty straight forward one: we’re caching the class that a string of its name correlates to directly. This allows us to actually use that clever O(1) optimization that we weren’t before.
Sky has been implemented for viewports since the beginning I think, but it’s not used for skyboxes, it’s used as a cubemap to give reflections to reflective objects in the viewport frame.
After I updated studio and my in-game servers updated I noticed that after the most recent update, it can completely break movement with characters that rely on forces like LinearVelocities when the HumanoidRootPart Massless property is set to true.
(Even without those forces, when the rootpart is massless it causes some very weird physics when animations are played on the humanoid.)
I fixed it by simply disabling the massless property, but if you don’t revert it at least list these changes in the release notes!! Anytime a game breaking physics bug happens from a Roblox update it’s NEVER listed as a real change. And I always have to go digging and testing to try and fix it. I’m lucky this one took me only around 10 minutes of stress, last time this happened I was searching for hours.
This is a more comprehensive optimization for IsA, FindFirstChildWhichIsA, FindFirstChildOfClass, FindFirstAncestorOfClass, and FindFirstAncestorWhichIsA, and a few other internal systems (e.g. we get a little better startup times in networking code).
We added a few fast class lookup structures, which allowed other engine systems to integrate more tightly with Instance reflection in perf-sensitive areas. This allowed faster IsA checks as @Dogekidd2012 mentioned (optimizes IsA, FindFirstChildWhichIsA, FindFirstAncestorWhichIsA), and also unlocked direct comparison between class types (optimizes FindFirstChildOfClass, FindFirstAncestorOfClass).
Speedups were in this general ballpark for big Instance trees:
IsA: ~1.3x
FindFirstAncestorWhichIsA: ~1.6x
FindFirstAncestorOfClass: ~1.1x
FindFirstChildWhichIsA: ~20x
FindFirstChildOfClass: ~3x
FindFirstChildWhichIsA was an outlier because it had a few other missing optimizations.
This happened in release 647, so not very long ago. My understanding is that this is because it doesn’t really make sense for some things (like EditableMesh) to be Instances because of the restrictions that being an Instance implies (e.g. only one parent) and the overhead it brings with (look at the sheer quantity of APIs that Instance has).