Release Notes for 649

[baackup_1st (Backup)]

They were implemented not too long ago, before then it was just ambient and a sun.

[DrAdministration (Lumine)]

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.

[subcritical]

RE the first one:

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.

[Kittylitterking123]

@Dekkonot

Instance isn’t the baseclass anymore

I didn’t know they changed this. I guess the base class is Object now, right? When did this happen?

[Dekkonot]

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

[Kittylitterking123]

@Dekkonot

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)

What exactly do you mean by this?

[Dekkonot]

They get into it a bit more in this topic:

@FGmm_r2

Object Instead Of Instance

When we first introduced the Editable* APIs, the only way for instances like MeshPart to reference Editable* data was by adding the Editable* instance as a child of the MeshPart with code like myEditableMesh.Parent = existingMeshPart.

A tradeoff to that design is that instances can only have one parent at a time. This doesn’t provide a way to have a single EditableImage drive multiple MeshPart instances since an EditableImage Instance could only be a child of one Instance at a time.

With this update, EditableMesh and EditableImage are now an Object instead of an Instance.

Object is a new base class of Instance that is being introduced to the Roblox Engine. The key difference is that Object does not have a Parent property and cannot be a member of the DataModel tree. This allows multiple instances (like MeshPart) to hold shared ownership of the same Editable* object without breaking API contracts for existing systems like streaming, replication and so on.