On Friday, October 4th, 2019 Linden Lab blogged about the recent script related issues that caused widespread disruption (notably with rezzing systems) across Second Life following the SLS (Main) channel deployment made on Tuesday, September 24th, 2019, and which ultimately resulted in a complete rollback from the grid on the 27th/28th September.
As noted in my Simulator User Group Updates, the release that caused the problems – simulator release 2019-09-06T22:03:53.530715, included a number of updates intended to improve overall script performance, including how scripts are scheduled and events are delivered. However, these changes resulted in an unintended impact which, due to the region sampling, was not revealed by the update initially being deployed to a release candidate (RC) channel on Wednesday, September 11th.
The October 4th blog post from Linden Lab indicates that improvements have been made to the code, and once deployed, these should help prevent a recurrence of the problem. As an aside, it has been hoped that these updates might have been deployed to an RC channel on Wednesday, October 2nd, but a last minute bug prevented this (see: Deploy Plan for the week of 2019-09-30), so the updates will likely be deployed during week #41 (commencing Monday, October 7th).
However, even with the fixes, there blog post goes on to note there are come best practices when using parent / child script communications between a parent object and a child it rezzes:
One common cause of problems is communication between objects immediately after one creates the other. When an object rezzes another object in-world using llRezObject or llRezAtRoot, the two objects frequently want to communicate, such as through calls to llRegionSayTo or llGiveInventory. The parent object receives an object_rez() event when the new object has been created, but it is never safe to assume that scripts in the new object have had a chance to run when the object_rez event is delivered. This means that the new object may not have initialised its listen() event or called llAllowInventoryDrop, so any attempt to send it messages or inventory could fail. The parent object should not begin sending messages or giving inventory from the object_rez() event, or even rely on waiting some time after that event. Instead, the parent(rezzer) and the child(rezzee) should perform a handshake to confirm that both sides are ready for any transfer.
The blog post goes on to define the sequence of events between a parent and rezzed child object as they should occur, and provides sample code for such parent / child operations.
An important point to note with this is that when the fix from the Lab is re-deployed, any scripts that still exhibit these kinds of communication issues will likely need to be altered by their creator to match the recommendations provided by the blog post.
Those wishing to know more are invited to read the original blog post in full, and address and questions and / or feedback through the associated forum thread.
