RLV/a Help

[Raven Huntsman]

Having an issue with the RLVa API (Firestorm viewer) whereby I have a script that runs the following command via llOwnerSay; "@attachallover:/~MyCustomBody/1.0.0=force". This is a pretty standard attach command and it does work, but for this attachment specifically, it very often attaches and then the object detaches itself almost immediately.

Once I reattach it following this bug, the script state inside the object (MyCustomBody) is totally borked. It uses a number of states and some complex HTTP calls but I'm unsure what could result in this behaviour. Have any RLV/a scripters encountered this before?

 

TL:DR RLV Attach command doesn't work correctly for a very specific attachment, detaching itself immediately when attached which results in broken script states within the target object.

 

Some Notes:

• This issue doesn't happen all the time, I'd say 70-80% of the time when I call the attach command. 
• The script/s inside the target object do not have any logic to self detach.

I can only assume that some x logic in lsl does not play well with the RLV attachallover process and is intermittently resulting in a detach.

Edited October 19, 2022 by Raven Huntsman

[Quistess Alpha]

A) Keep an eye on your restrictions list and make sure there are no folder attach restrictions (Ex. "@attachthis:...=n")

B) In my anecdotal observations/guesses, the 'bigger' something is in terms of sim resources, the more likely SL is to bork on attaching it. Is the thing in question a large linkset/ have lots of scripts and/or object inventory?

C) Is the object in question a literal copy or an inventory link? RLV(a) often dislikes inventory links in many scenarios.

D) One possible fix/bandaid would be to lock the folder for a while :

llOwnerSay("@detachallthis:/~MyCustomBody/1.0.0=n,attachallover:/~MyCustomBody/1.0.0=force");
llSleep(5.0); // adjust as needed. sleeping this long is somewhat bad form, but useful for testing before reimplementing with a timer.
llOwnerSay("@detachallthis:/~MyCustomBody/1.0.0=y");

 

[Raven Huntsman]

23 hours ago, Quistess Alpha said:

A) Keep an eye on your restrictions list and make sure there are no folder attach restrictions (Ex. "@attachthis:...=n") Definitely none present

B) In my anecdotal observations/guesses, the 'bigger' something is in terms of sim resources, the more likely SL is to bork on attaching it. Is the thing in question a large linkset/ have lots of scripts and/or object inventory? That sounds like a potential cause, it's without question a large linkset, a handful of scripts and things all bundled together. Might explain the inconsistency of the issue as well. In which case.. hm I don't know that I can simplify it, as it's by nature complex (custom body with many integrated bells and whistles to save on attachment count).

C) Is the object in question a literal copy or an inventory link? RLV(a) often dislikes inventory links in many scenarios. Always a copy, I use an in world versioning system when editing my body which then gives me a copy and creates a versioned folder in my RLV folder structure via the GiveInventory command.

D) One possible fix/bandaid would be to lock the folder for a while : I hadn't considered this! Will give this a go and see how it goes.

llOwnerSay("@detachallthis:/~MyCustomBody/1.0.0=n,attachallover:/~MyCustomBody/1.0.0=force");
llSleep(5.0); // adjust as needed. sleeping this long is somewhat bad form, but useful for testing before reimplementing with a timer.
llOwnerSay("@detachallthis:/~MyCustomBody/1.0.0=y");

Thank you for the suggestions and information Quistess

 

[Raven Huntsman]

@Quistess Alpha I finally got around to trying out that possible solution and to my surprise it didn't work. I actually observed the attachment detach itself while the detach=n restriction was still active. My test case was to enable the restriction (separate call), attach the object. Then try reattaching a few times, still able to repro the issue, while the detach restriction was enabled. Very odd, I'll likely have to find a way to debug the attachment itself (going to take me ages ha) and figure out what's causing the issue.