0.9, linked objects, and llSetStatus

Did llSetStatus' behavior change with the 0.9 patch? It seems that it did, as I had a few linked objects with scripts (the script is in the parent) which do llSetStatus to turn physics on and off as needed, which no longer work. They exhibit some very odd behavior in general, which would lead me to believe that physics is turning on for atleast 1 of the objects in the link, but definitely not the way they're supposed to. Is there some way I can "emulate" the way it worked previously? I don't much care for the idea of having to put a script in every single child object of a link to make things work right?

Ok, it appears this was not a problem with llSetStatus, but possibly a physics change in general? There are several objects which existed previous to the 0.9 patch which functioned well, they are designed as an "axle" style system. That is to say, there is a hollow tube surrounding a solid cylinder, allowing for spinning.

Ever since 0.8.1 -> 0.9, they are no longer capable of spinning. They appear to constantly be "stuck", even though not in contact. I have tried to correct this through several methods, including increasing the diameter of the "containing" tube.

Increasing it to almost twice it's size allowed it to once again move freely, but still not properly. It's completely incapable of spinning as it did previously, based on it's llApplyRotationalImpulse. It still seems to "stick" on it's container object, and I have to apply impulses in the magnitude of 1000+ to make it move at all. Previously, a impulse vector of <0, 0, -350> was enough to launch an object across a sim (it's a catapult). Now <0, 0, -1250> will send the same object approximately 50m at best, as there seems to be a huge amount of friction between the two non-touching objects, which used to be able to spin freely about each other.

Without modifying diameters of container objects and axles, the object can no longer move at all, if I apply enough impulse to where it can, it simply breaks free and leaves the world with wonderous rapidity.

I would be more than happy to demonstrate this to a Linden, it's easily reproducable (as it's constant). If someone could possibly inform me of what needs to be done to change these objects to work as they did previous to the patch I would be greatly appreciative.

Bump? Nothing? Still broken since many patches ago.

I second this....Plz any ideas of what caused this change in the updates? LL help plz?

We need catapults and other things like gears and such that need this.

I *really* wish LL would document *every* change made in updates, since they have no idea what a little tweak might do to someone's scripted masterpiece.

I heartily agree... please return this back to ~ pre .9 patch state or fix so it will function again.

(8

I dunno its kinda nice not having farm animals fly overhead all the time......

just kidding, it is broken and needs to be fixed. If you need to see a case in point or example I think the catapults are still in darkwood that don't work but used to.

Farm animals? She hit me in the head with a shark!

A shark!

At 0.9 we added some code that could detect when collisions between a single pair of objects was killing the physics engine (causing it to go unresponsive, sometimes until it's network circuits timed out). When this happened we would "pin" the object (turn off "physics" and disable scripts, since a script could re-awaken the object and cause the problem all over again.

Turns out this was too aggressive, so we increased the threshold that determines whether an object get's pinned.

Also, we now only disable an object's scripts if ALL of the following criteria are met:

(1) the scripted object was directly responsible for the sim requiring a restart (that is, the physics engine was comtemplating the object's collisions for at least 20 seconds)

(2) the script has a timer or repetitive operation (such as llSensorRepeat())

(3) the object was "physical"


The result of this is (i) it is possible for an object to get "physics" disabled if it's collisions are too expensive and (ii) it's possible for a script to be disabled if its object killed a simulator.


As to increased friction between objects...

We did change the geometry of objects with very small (< 0.2 meters) dimension on at least two sides. The reason is that the smaller triangles on tiny objects (especially concave objects) could kill the physics engine. So, if a catipult is relying on a cylinder that is less than 0.2 meters in diameter I suggest either making the post and hole bigger than 0.2 m, or else making the post smaller until it works (bigger is probably better... when you go smaller you are moving further into the "quantum realm" of the physics engine where collisions can do strange things).


Sorry I'm late with this post. I read this thread before but was drawing a blank on the friction problems.

Well, you heard the man Alek, make a copy of it, stretch it, and see what happens

(I take no responsibility for the death of an entire sim based upon this request.)

Thank ya much Andrew. It gives us a slightly better idea what to do. Maybe we can still get this workin again .

And I pronounce the catapult fixed.

Of course, about an hour after fixing it, a slight physics mishap caused it to leave the simulator at a rapid rate of speed.

If only objects could not break free of each other like that, ohwell

Catapults are fixed, game on!

Thank you very much for your reply, Andrew! I'm really glad our catapult wasn't broken indefinitely. All I have to do now is set out a new one after Si breaks it. (:

I hope the top pieces aren't still in the world! (;