Information on llRezObjects() scrip delay?

Evening all,

I'm sure I saw somewhere a post or wiki entry showing how llRezObject() 's script delay varied according to the mass of the object being rezzed. But I cant find it. Can anyone point me in the right direction?

Thanks in advance
Tip

I'm not sure if that's still the case. However, objects that are more complex from a data standpoint usually take longer to rez than simpler ones.


However, a friend of mine had trouble rezzing objects with a velocity vector of <0,0,-4> earlier. I would start by setting velocity to zero to test, as this may be a bug.

From the wiki...

- This function delays the script for a period of time proportional to the mass of the object and the rezzed objects velocity (and quite possibly someting else as well) - this timer does not reset when script resets.

It is most likely mass * magnitude of velocity * some constant. However, I can't get on SL to check right now.

A way to check would be to set a variable to the time before the rez, and set another variable to the time after the rez, and measure the average delay. Correlate this with velocity and mass... and you should find something!

Happy experimenting!

Jeffery,
Velocity isnt a worry, it was the mass influence I'm after. In this case, I actually want it to take longer for larger objects.

Keknehv,
Thanks, that was the text I was looking for. I thought I'd seen the results on someone's experiments on this, which was what I started looking for. I suspect that the energy in the object may also be a factor. As you say, time for a few experiments.

Thanks for the replies.

Tip

Well, I did some tests. Here is what I found.

Edit: On further tests, Log10 times velocity appears to be inaccurate. Currently still testing.


Other notes:

- This command does not affect the rezzing object's llGetEnergy.

- If the rezzed object is not physical, the delay is ignored.

- The rez delay can be circumvented by first rezzing a child object that then spawns a new item.



Feel free to double-check my work and update the wiki.

I believe this is what you were looking for?

Jeffery,

Much obliged Sir!

That is very interesting. I didn't expect the zero delay with a zero vector, I assumed there would be an in built minimum.

If I duplicate your results, I'll add a comment to the wiki

Many Thanks
Tip

Thats what I was thinking of.

Thanks

Tip

I'm still testing. I just used an outlier to see what values I would get, and Log10 does not appear to be the proper representation after all (though it did work for smaller objects).


I'll post what appears to be more proper once I have it.

What do you mean break? All scripts hang?

I wont be able to get into SL till later, so I appreciate you investigating this.

With a velocity of, say 10 m/s, what delays are you getting for a 1kg object and a 10kg object?

Tip

I was actually about to remove that comment (have now). It doesn't break, just hangs for an extremely long period of time (several minutes) at very large mass values.


The closest I have come so far is Log10-mass times velocity. However, this does not hold true with very large objects, which appear closer to Log10-of-Power-3-of-mass times velocity, which does not seem to work for smaller objects.

Mass of the rezzing object appears to not be a factor, nor does the relative rezzing location. Number of prims does not seem to be a factor either, aside from their added mass.



At that, I am stumped at present. The function appears to be logarithmic or with a falloff not easy to measure due to the script scheduler.

I would say the best thing to do at this point would be to flat-out ask a Linden for clarification.

Regardless, could you post your data? Perhaps more than one mind mulling over it might make more sense of it.

Does Torley have access to the code base yet?

Jeffery,

When you say 'large', what sort of scale you talking? 1kg, 100kg?

Thanks again,
Tip

Working on it. Here's what I have figured so far:

// NOTE: Delay is adjusted at -1 second to factor out relative script running time.

// I will also be presenting the values with the lowest delay after five tests, as this 
// would present the most accurate picture versus the script scheduler.


// CONSTANTS: Rez distance of object, mass of rezzing object

// Absolute Velocity of: 0.0

"Dimensions: 0.5^3"

Delay: <= 0.00000
Mass: 1.250001
Vel. times Mass: 0.000000
Vel. times Log10 Mass: 0.000000


"Dimensions: 1.0^3"

Delay: <= 0.00000
Mass: 10.000005
Vel. times Mass: 0.000000
Vel. times Log10 Mass: 0.000000


"Dimensions: 2.0^3"

Delay: <= 0.00000
Mass: 80.000038
Vel. times Mass: 0.000000
Vel. times Log10 Mass: 0.000000


"Dimensions: 3.0^3"

Delay: <= 0.00000
Mass: 270.000183
Vel. times Mass: 0.000000
Vel. times Log10 Mass: 0.000000


"Dimensions: 4.0^3"

Delay: <= 0.00000
Mass: 640.000305
Vel. times Mass: 0.000000
Vel. times Log10 Mass: 0.000000


"Dimensions: 5.0^3"

Delay: <= 0.00000
Mass: 1250.000732
Vel. times Mass: 0.000000
Vel. times Log10 Mass: 0.000000


"Verdict: Velocity is clearly factored in, as there is no delay here at all."
"I also tested 10.0^3 and found zero delay."

// Absolute Velocity of: 1.0

"Dimensions: 0.5^3"

Delay: 0.073947 (five tests)
Mass: 1.250001
Vel. times Mass: 1.250001
Vel. times Log10 Mass: 0.096910


"Dimensions: 1.0^3"

Delay: 0.185228 (five tests)
Mass: 10.000005
Vel. times Mass: 10.000005
Vel. times Log10 Mass: 1.000000


"Dimensions: 2.0^3"

Delay: 7.185029 (five tests)
Mass: 80.000038
Vel. times Mass: 80.000038
Vel. times Log10 Mass: 1.903090


"Dimensions: 3.0^3"

Delay: 26.193031 (five tests)
Mass: 270.000183
Vel. times Mass: 270.000183
Vel. times Log10 Mass: 2.431364


"Dimensions: 4.0^3"

Delay: 63.230408 (three tests)
Mass: 640.000305
Vel. times Mass: 640.000305
Vel. times Log10 Mass: 2.806180


"Dimensions: 5.0^3"

Delay: 124.182724 (one test)
Mass: 1250.000732
Vel. times Mass: 1250.000732
Vel. times Log10 Mass: 3.096910


"Verdict: When the one second is factored back in, this appears to follow:"
"Mass / 10 times velocity"

From what I can tell with these latest tests though, Log10 was quite off the mark. Using a more formalized test regimen, this appears to be mass times velocity divided by ten, or simply:

llVecMag(velocityVector) * llGetObjectMass(object) / 10.0;

Closing note:

The relative distance of the object from the rezzing object is 10.0. While this appeared to have no impact, keep this in mind when doing further tests.

That makes me happy . Good job, Jeffrey.

Yes,thanks for your effort Jeffery. This has given me things to think about.

Time for my bed, now. Tomorrow I'll seee about updating the Wiki, unless you get there first.

Tip