Talk:LlRezObject
can someone write some words about that integer param, the last parameter? maybe the one who wrote the function!
- Yes, I'm adding more to the function description now. Including an example. Xaviar Czervik 18:58, 28 October 2007 (PDT)
Delay?
Is the delay actually mass-based, or is it 0.1 seconds? The article currently says both... Dale Innis 12:10, 1 November 2007 (PDT)
- Both, the function has a default delay of 0.1 seconds (it's part of how the function is plugged into the VM), but there is an additional mass based delay. -- Strife Onizuka 13:42, 1 November 2007 (PDT)
- Only 0.1. The mass based delay has been deprecated for a long time. Acheron Gloom 23:56, 24 November 2010 (UTC)
- LOL, it went away on Havok 4 and nobody noticed! I see now that Andrew closed SVC-1501 with "won't finish" two years ago because the grey goo fence had it covered :o --Cerise Resident 17:52, 25 November 2010 (UTC)
How far away can an object be rezzed?
I could spend some time testing it, but was hoping someone already did that. :) Lana Straulino 20:52, 29 April 2010 (UTC)
- This is just a guess plus a little experience with trying to rez at distance from the rezzer....I think the maximum distance may be variable and tied to the linkability rules. It would make more sense than the maximum distance being (my memory fails me) about 18.5 meters, which was roughly the maximum I have managed in the past. Testing and posting the results would be of value if my guess doesn't help. -- Fred Gandt (talk|contribs) 22:26, 29 April 2010 (UTC)
- Actually: See llRezObject Caveats. Apparently a maximum distance of 10 meters from the rezzer (center of the prim containing the script calling this function) is the limit. I'm sure I broke that though. I may end up testing it myself. -- Fred Gandt (talk|contribs) 22:36, 29 April 2010 (UTC)
As I thought. The caveat is wrong. It also turns out my memory isn't so bad as I thought. Also...A difference in maximum distance is seen depending on the size of the object doing the rezzing.
- A 10 meter cube can rez up to 18.660279 meters away.
- A 0.01 cube can rez up to 10.008666 meters away.
Tested using a cube as the rezzer and rezzee. The rezzee size seemed to make no difference (this was a simple test). <lsl>vector pos;
default {
state_entry()
{
pos = llGetPos();
}
touch_start(integer nd)
{
llRezObject("Object", (pos + <0.0,0.0,10.008666>), <0.0,0.0,0.0>, <0.0,0.0,0.0,1.0>, 0);
}
}</lsl> Any testing beyond this would bore me to tears so, good luck! Hope it helps. -- Fred Gandt (talk|contribs) 23:18, 29 April 2010 (UTC)
- omg! Thanks you Fred! And believe it or not, that sort of work changes entire designs. Lana Straulino 03:22, 30 April 2010 (UTC)
I'm a little concerned by the idea of just casually replacing the original 10m-limit statement with the results of some experiments. My impression has been that what's officially supported is a 10m area, and anything beyond that that any particular version of the server software happens to support should be regarded with suspicion. That's one of the problems with a Wiki :) in that it's hard to distinguish the Official Contract of the function from stuff that people have discovered and posted on the page. Personally I wouldn't write any code (or at least no code that I was planning to support someone else's use of) that depended upon being able to rez an object more than 10m away; I can easily imagine the 10m limit becoming strict in some server update, and any bug reports against that being closed Working As Designed. Of course ymmv... Dale Innis 14:07, 3 May 2010 (UTC)
- Agreed Dale. However, I first discovered the approx 18.5 meter range quite a few servers ago. 1.24? (I really can't say, about 18 months ago ish) The fact that I took the time to study the results on more than one occasion and on far removed server updates does lend my results some validity. You are of course right though. If 10.0 meters is what it should be, we should mention it. :-) -- Fred Gandt (talk|contribs) 14:40, 3 May 2010 (UTC)
- Yeah would probably be good to confirm with a Linden as to what the actual supported use is, and write that down. I updated the text slightly to note 10m as the "official" limit, although I admit I can't point to specific proof of that! :) If you know which server versions your results apply to, that might be good to document as well, in case it ever becomes an issue... Dale Innis 15:33, 3 May 2010 (UTC)
- I agree with Dale on this. It has been my thinking that this sort of information may be hinted at in the caveats but should be located in the Notes section. I would go with a caveat like (don't use this, word for word it's a quick mockup that is by no means properly usable):
- The official limit is 10 meters. Testing has shown that under special conditions distances above 10 meters may work.
- To learn more about this see #Distance Limit
- Code that depends upon the idiosyncrasies of the limit will be brittle; there is no guarantee that LL won't changes their implementation.
- The official limit is 10 meters. Testing has shown that under special conditions distances above 10 meters may work.
- You get the idea.
- Once inside the Notes section it's pretty much free form do what you want.
- And if you want to get really off topic (or into esoteric subtopics of limited interest), there is Deep Notes (how did we/i ever decide on the name "Deep Notes"?).
- I'm off to bed, I've been awake more than 26 hours (16 of which I was at work x_x). -- Strife (talk|contribs) 20:09, 3 May 2010 (UTC)
- P.S. Normally detailed descriptions of functionality that are too long for the summary box and caveats, would go into Spec but seeing as this is experimental, it doesn't belong in Spec. Spec is for when you have to explain something technical.
- Okies doke. When editing notes deeply, wear my specs. Got it. -- Fred Gandt (talk|contribs) 22:13, 3 May 2010 (UTC)
- P.S. Normally detailed descriptions of functionality that are too long for the summary box and caveats, would go into Spec but seeing as this is experimental, it doesn't belong in Spec. Spec is for when you have to explain something technical.
Notes - Center
About the center, is that the geometric center, the center of mass, or did they mean the position? :p -- Strife (talk|contribs) 04:06, 5 May 2010 (UTC)
- There are more details than there were. You once told me that it is better to write something than nothing since gold can possibly be gleaned from something but, nothing can be gleaned from nothing. The center is where all the middles meet ;-) -- Fred Gandt (talk|contribs) 05:12, 5 May 2010 (UTC)
- I only ask because llRezObject places the object's geometric center at the target position. *evil grin* -- Strife (talk|contribs) 09:55, 5 May 2010 (UTC)
- With a single prim that would be its center wouldn't it? Or would even a single prim have a mismatched geo center and pos center if the prim was cut etc? If you know what should be written, would you mind doing the honors? I honestly don't feel like testing it out (right now) and would have to. My ankle hurts *shrugs* -- Fred Gandt (talk|contribs) 10:11, 5 May 2010 (UTC)
- Cut shouldn't effect the geometric center but it would effect the center of mass. I believe the geometric center is the average position of all the prims. But I honestly don't remember as it's been almost 6 years since this last came up (the last time was when they added llRezAtRoot and llGetGeometricCenter... which was SL version 1.5). In all the years of scripting, I don't remember ever using llGetGeometricCenter, I don't know if it even works. The only time I use llRezObject is when dealing with projectiles, the rest of the time it's llRezAtRoot. The one thing I recall about the original implementation of llRezAtRoot was that it was just llRezObject but with the position shifted and the shift counted against the distance limit! Which *might* explain the fudge factor you are seeing. I can imagine it might be easier to tweak the limit then it would be to get llRezAtRoot working properly. Pure speculation on my part and my memory may be faulty.
<lsl>vector llGetGeometricCenter(){
vector buffer;
integer a = 1;
integer b = llGetNumberOfPrims();
list c = [PRIM_POSITION];
while(++a <= b)
buffer += llList2Vector(llGetLinkPrimitiveParams(c), 0);
return (llGetRootPosition() + buffer) / b;
}</lsl>-- Strife (talk|contribs) 07:50, 6 May 2010 (UTC)
Does this work on non-physical objects?
I have tried to rez a non-physical object from parent object inventory and it was not rezzed. I tried to rez a physical object with this script <lsl>on_rez(integer start_param) {
llSetStatus(STATUS_PHYSICS, FALSE);
}</lsl> in it and it was rezzed. As I have had a headche trying to figure out why my non-physical object was not rezzed, perhaps it would be nice to add a line about it. -- Otaner Merlin 14:53, 15 May 2010 (UTC)
- Yes, llRezObject works just fine for rezzing non-physical objects. This is the basic idea of the call we make that works.
<lsl>default {
touch_start(integer total_number)
{
llRezObject("Object", // The name of the object to rez (must be in the inventory of the prim containing this script.
llGetPos() + <0.0,0.0,1.0>, // A position relative to the rezzing prim (see caveats for details).
ZERO_VECTOR, // A vector measure of velocity (fires the rezzed prim (if physical) away from the rezzer).
ZERO_ROTATION, // The rotation the object should be rezzed at.
0 // A start parameter for the rezzed object (can be used by a script inside the rezzed object).
);
}
}</lsl> -- Fred Gandt (talk|contribs) 16:57, 15 May 2010 (UTC)