Recent Instance.Changed and DataModel.ItemChanged update made certain commonly used methods and tricks no longer functional

Bug Reports Engine Bugs
,
#1

Recently I noticed that some of my scripts which utilize Instance.Changed have either stopped working properly or completely broke.
After doing some research it turns out that the reason behind this case is one of the most recent releases:

image
image932×102 12.8 KB

Even though as of now it is still marked as “Pending”, the above change has already came to effect.

Upon noticing this “improvement”, I immediately voiced my objection and explained in detail why it should not be rolled out here: Release Notes for 653 - #7 by vfx_1

At that time the change was not in effect yet.

Most of my scripts responsible of handling physically controlled objects relied on the following trick:

local unanchoredPart = script.Parent

unanchoredPart.Changed:Connect(function(value)
	if value == 'NetworkIsSleeping' then
		-- Handle the rest
	end
end)

This used to be the most efficient way to take an action whether an object has fallen asleep or woke up.
As “NetworkIsSleeping” is a non-scriptable property, after the update it is no longer possible and there are no other alternatives available.
I had a few uses for it such as forcefully waking up the object with

unanchoredPart:ApplyImpulse(Vector3.one)

once NetworkIsSleeping was signaled and for example the object has not reached the target angle yet or ended up in an unwanted position. If the target angle/position has been reached, I’d anchor the object and do whatever else I needed.

I know there are other people who used this or similar tricks with the .Changed signal, therefore I am afraid that this update could cause even more issues.

System Information

Windows 11 Pro 21H2
Intel(R) Core™ i7-4800MQ CPU @ 2.70GHz

I am fully aware that non-scriptable properties are called “non-scriptable” for a reason and were not meant to be relied upon, however often using them is literally the most efficient and reliable way possible. Many scripts like mine intentionally expected non-scriptable properties to be called with Instance.Changed, while I understand that some people never expected it to happen.

This behavior always seemed to be intentional and existed for too long just to be just removed without any good alternative provided to the developers.

Expected behavior

Instance…Changed and DataModel.ItemChanged signals should still be called when non-scriptable or inaccessible properties change.

As of now, the best options to address this issue are:

  • Reverting the update,
  • Allowing the use of non-scriptable properties with :GetPropertyChangedSignal(‘’),
  • For my specific case making BasePart.NetworkIsSleeping read-only rather than non-scriptable as well as all other useful properties
8 Likes
#2

This is a massive functionality change of something decades old, this shouldn’t have been quietly squeezed through and should have came with a warning and grace period for developers to react. I am unsure if my game has broken features yet because I am in the middle of a house move. Unpleasant time to find out.

Afaik I don’t have high stake in this, but I use many third party libraries and I may have done this for a strange edge case. I don’t remember.

Is it not possible to instead let us simply read certain internal props by string e.g. an “UnsafeRead” function? I am aware this API is volatile and changes often sometimes, hence unsafe, but some have been around for a very long time. Remove them from Changed, I’m sure there’s good reasons to. We could poll on the values instead to the same end result.

3 Likes
#3

Thank you for the report.

We understand the frustration, but inaccessible properties should not be relied upon. They don’t make a public API with backwards compatibility promise and have changed and will continue to change for a multitude of reasons.
There was plenty of time to modify the code since December 6th release notes that you were aware of.

This was one of the leaks of the implementation details of the engine we have fixed along others in the last year and is important for the security of the Roblox platform.
It is also important for the ability of the platform to improve as internal details do not go through extensive forward/backwards compatibility review as they are not intended to be relied upon and allow engineers to be more flexible with the implementation of new features.

Instead of ‘figuring out a hidden hack to find out something’, consider making a feature request.

2 Likes
#4

To be fair, feat group requests arent being reviewed so that argument is pretty much inaccessible to normal members of the forum,

1 Like
#5

Hello,
Thank you for your reply.

I understand your point, however mostly cannot agree with it.

Not everyone regularly follow the release notes. I believe that’s also not the right place to inform creators that a functionality they could’ve done ages ago and worked for such a long time will now break. As the person above said, it is a very major change so it should be at least possible to temporarily opt-out with a workspace flag.

The fact I am able to post a bug report doesn’t mean that I can post a feature request. I unfortunately cannot. Last time I used the recommended way of posting it somewhere else and had a staff member move it to the #feature-requests category I got warned. So in my case it is unfortunately better to “figure out a hidden hack to find out something” rather than trying to push such a minor thing through the whole process of even getting it into feature requests and then have it reviewed. (Based on my past experience).

2 Likes