Prim height limit with llSetPos?

Okay, I know that the Wiki says (yes, the wiki speaks to me) that you can llSetPos a prim up to 10m at a time with a max of 650m or something like that but I have a script moving a prim straight up and it seems that the prim dies at about 200m.

Does this sound right?

I fly up with it and it just seems to vanish at about that height. It is supposed to come back down after doing another task but it always seems to vanish at about 200m.
Is this a known issue that I missed or a bug or something?
Is there is another function I should be using to do this or what?
Besides making my otherwise useful teleporter a paper weight, it's just bugging the heck out of me.

Thanks in advance.

From a different post about vanishing prims (albeit moving horizontally instead of vertically), try changing the material of the prim to light instead of the default wood.

It was something to do with something or another having to do with some other thing, but the original poster said changing the material fixed the problem.

Yeah I saw that post as well. The prim is already a light, I forgot to mention that
Thanks for the suggestion though.

To asnwer you simply: No that does not sound right. I use this method quite a lot and I have never had an object or prim disappear simply by setting the position up to that height. You can go up to 512m in height before the object will get stuck but it doesn't disappear. May be you have something else in your script that does something once it reaches 200m that you aren't remembering.


I would start my search in this other task you spoke of.

Could someone post a link to that thread? There is no reason that the material should affect movement (edit: or make a prim disappear). And light is a very bad material to use unless you actually want to generate light.

I really need to see this.

Nope.

Well, I haven't done this in a while, but the limit for llSetPos is 768m.(**) This is also the maximum height that you can place an object via manual edit.

You can move an object higher than this using physics. A physical object can be moved up to 4096m using llMoveToTarget() or something similar. Above 4096, an unattached object disappears without warning. It doesn't return to your inventory and there's no message.



Off hand, I can only think of three things that can remove a prim from the world: llDie(), autoreturn, and temp on rez.

There are several other things that could make it invisible. One of the more interesting ones of these is if it gets too far away. A small prim can seem to disappear even if it's within your draw distance if it gets far enough away. The SL renderer clips smaller prims at a distance. llSetAlpha() can do it, too. And setting the texture to a clear texture.

If you still have problems, I'd suggest posting the LSL.

------------------------
(**) llSetPos used to only work to 512m. It now appears to work to 768m, although there's some differing observations regarding this. If you observe that it works only to 512m, please bug report it.

Shack, why will the temp_on_rez make it vanish? I think I have that in the script so that may be my problem, but I am just curious as to why.
Thanks to the posters as well.
This just made a lightbulb go on so I wil check the script for temp_on_rez.

Because that's what it does. temp_on_rez will make the object die 80 seconds after being rezzed.

Ahhh, got it.

Thanks Ziggy.

The original poster was possibly refering to this thread, where it was suggested to change an object's material to light for higher visibility during testing, as light objects are likely to be still visible at a distance where a wood object wouldn't be drawn anymore.

Yeap, that's the one , wrong thinking though for this case. Looks like they got it figured out.

Okay, makes sense. thanks!

For testing, yep I can see using light. And for a bullet, light might be the right material for the final product, since a bullet is often viewed from a distance and it's small. The amount of light emitted is propotional to the size of the object. A small object would cast a small amount of light, but would be much more visible and more resistent to clipping.

But light is generally a bad thing for people who don't have local lighting turned on. You can't see what it's really doing. It's tempting to use light because you can see it at night, but colored light objects can look *really* bad.

For example, I saw a river whose prims were made of light and it was casting horrible blue light on the surrounding terrain and builds. The builder had local lighting turned off and therefore had no idea how bad it looked.

1.7 has a new feature related to this that lets you get some benefits of light without using light material.

* Full Bright Objects
o Objects now have the ability to be lit with a full brightness
lighting effect. It makes the faces (textures) appear as if the
sun is shining directly on them, regardless of the time of day.
o This effect can be applied to all faces or individual faces of an object.

Shack, llSetPos is maxed out at 512m. You can manually move builds up to 768m.

Right, thanks for the correction. LOL I never actually used llSetPos to that height. After your message I remember reading that.

One more thing that makes no sense, I guess.

That isn't true anymore. The building tools, llSetPos and llSetPrimitiveParams all go up to 768 now.

I can't get llSetPos() to go over 512m but I can get llSetPrimitiveParams() to go up to 768m. When I try to go higher than 512m with llSetPos(), the prim just stops.

I have a little elevator thing I use that listens to owner for the altitude to move to. And when it tries to go over 512m the script no longer listens to me, so I can't even go back down. I need to reset the script. Which basically means it is stuck inside the while(llGetPos() != targetpos) loop that I use to set the position till it is at the desired height/position.

So unless they changed lLSetPos() in the last week ro so, it's still limited to 512m.

Something else must be going on. I just rode a prim up to 768m using llSetPos().

I put the following code in touch_start, sat on it, and touched the prim. It took me to 768m.

integer i;
vector pos = llGetPos();
for (i = 0; i < 1000; i++)
{
    llSetPos( <pos.x, pos.y, 1000> );
    llSay(0, (string) llGetPos() );
}

Wierd. I have a couple of doors on my building area skybox that uses llSetPos, and it's at 650+ meters.
I remember something said about this in the hotline...
*looks*
Ah Ha! - /invalid_link.html
and - /invalid_link.html

If it's reverted behavior, best to bug report it.

This thread has been quite informative so far, and partly explains some mysteries.

But, I have a flying platform which uses llMoveToTarget(), and it won't take me higher than about 400m. Is there some trick or optimal settings to get things to their maximum height? My object isn't especially large, 10 prims forming a chair and platform.

Any advice on high-flying appreciated!

(I used to think that 768m was the top of Space, from sitting my av on a prim and manually editing its height... but then a skydiver wandered by and took me up to 4000 and I was thus enlightened. )

Use llSetPos if it's non-physical, and remember llMoveToTarget onlymoves you if the target is within 60 meters or so... hmm. I'll have to experiment later to see if llMoveToTarget has a Z axis limitation. Wiki desn't mention anything, though.

Thanks!

Yuppa, I'm using llMoveToTarget() on a timer, never asking for more than 60m.

I thought maybe it had something to do with the physics "Energy" that is alluded to in the WIKI; More testing is needed.

I could switch to non-physical... but if physical motions can go up to 4000m...