llSetLinkPrimitiveParams & local teleport?
|
|
Jesse Barnett
500,000 scoville units
Join date: 21 May 2006
Posts: 4,160
|
10-27-2008 18:17
I was raised in South Texas where everyone had at least one tepin bush in the garden. A little tiny pepper that is about 250,000 scoville. Since then I am a confirmed chilihead and now so is my daughter. Habanero's? HA! We laugh at them  I think I am definitely addicted to the endorphin rush. Never had a chance at the Jolokia which are rated at a million scoville but have done 2,000,000 with a Blaine's special edition sauce. Now that is definitely hot!!!!! I miniscule drop in a bowl of soup and I am rushing around all evening.
_____________________
I (who is a she not a he) reserve the right to exercise selective comprehension of the OP's question at anytime. From: someone I am still around, just no longer here. See you across the aisle. Hope LL burns in hell for archiving this forum
|
|
Innula Zenovka
Registered User
Join date: 20 Jun 2007
Posts: 1,825
|
10-27-2008 19:25
Thanks all. This posJump certainly looks worth investigating, but my lack of knowledge of rotations is rather letting me down. When I use it to send a prim (with me sitting on it) 15 meters up in the air, it works as expected, but when i try to adapt it just to send me up in the air, using llSetLinkPrimitiveParams(2, [PRIM_POSITION, <1.304382E+19, 1.304382E+19, 0.0>, PRIM_POSITION, target_pos]); i go from <164, 172, 21> to <201, 210, 28>. Why i end up there and nowhere else is a mystery.
Playing with my local rotation doesn' t seem to have much effect.. no matter how i try to compensate by zeroing my rotation, i seem to end up in the wrong place. It's fun, though.
|
|
Hewee Zetkin
Registered User
Join date: 20 Jul 2006
Posts: 2,702
|
10-27-2008 20:21
Your rotation shouldn't affect it at all. No idea about the rest of this whole inf hack though.
|
|
Klug Kuhn
Registered User
Join date: 7 Sep 2007
Posts: 126
|
10-27-2008 23:33
From: Innula Zenovka Thanks all. This posJump certainly looks worth investigating, but my lack of knowledge of rotations is rather letting me down. When I use it to send a prim (with me sitting on it) 15 meters up in the air, it works as expected, but when i try to adapt it just to send me up in the air, using llSetLinkPrimitiveParams(2, [PRIM_POSITION, <1.304382E+19, 1.304382E+19, 0.0>, PRIM_POSITION, target_pos]); i go from <164, 172, 21> to <201, 210, 28>. Why i end up there and nowhere else is a mystery.
Playing with my local rotation doesn' t seem to have much effect.. no matter how i try to compensate by zeroing my rotation, i seem to end up in the wrong place. It's fun, though. i'm not sure of the rotation in the hack, but if you just want to send you up in the air, you could TP you and the prim to the destination, then unsit and the object goes back. So you'll end up just in the air etc..
|
|
Innula Zenovka
Registered User
Join date: 20 Jun 2007
Posts: 1,825
|
10-28-2008 00:16
From: Klug Kuhn i'm not sure of the rotation in the hack, but if you just want to send you up in the air, you could TP you and the prim to the destination, then unsit and the object goes back. So you'll end up just in the air etc.. That's the problem, though -- I don't want anything other than the avatar to move if I can avoid it. The effect I'm trying to achieve is that the avatar touches my rather large device, is held in place by a stand animation while the device does various things, and then vanishes to reappear somewhere else. llSetLinkPrimitiveParams lets me do exactly what I want, but doesn't move the avatar far enough. I think what I'll have to do is split things up by having a thin transparent prim in front of my machine that animates the avatar, whispers to the machine to start it, and then sleeps for a while before tp-ing itself and the avatar and then returns home.
|
|
Jesse Barnett
500,000 scoville units
Join date: 21 May 2006
Posts: 4,160
|
10-28-2008 03:37
Avatar actually touches the invisi-prim and it animates (stand animation) and physically moves the av to target location?
Using physical movement would allow you to control all the variables including waiting before moving.
_____________________
I (who is a she not a he) reserve the right to exercise selective comprehension of the OP's question at anytime. From: someone I am still around, just no longer here. See you across the aisle. Hope LL burns in hell for archiving this forum
|
|
Innula Zenovka
Registered User
Join date: 20 Jun 2007
Posts: 1,825
|
10-28-2008 11:17
Sorry, I don't quite understand. I'm now touching the invisiprim, thus triggering the stand animation (and, by whispering to the unlinked main device) the special effects, sleeping for 10 seconds, using posJump to move both the invisiprim and the avatar, unsitting the avatar at the destination and then moving the invisprim back to base. Would physical movement be better for this? I just want the avatar to vanish and reappear at the destination, so I'm not worried about smooth -- as opposed to rapid -- movement. Ideally I'd like to use one linkset, but if that's not possible, it's not. I just don't want the main, visible, device to move at all.
Assuming I do have to use a separate, invisible, teleporter, is it better practice to have it return to base or to rez a new one each time the gadget is used and have the old one die after unsitting the avatar? Or doesn't it matter?
|
|
Jesse Barnett
500,000 scoville units
Join date: 21 May 2006
Posts: 4,160
|
10-28-2008 15:20
From: Innula Zenovka I don't, though, want the device briefly to vanish along with the avatar and then reappear, and I do need the delay between the animation starting and the avatar being moved. I guess I misunderstood this sentence. OK you want to just disappear and then appear in the new location AFTER your animation and special affects. No problem then and either warpPos or posJump will work fine. You just have to insert either into the code at the correct time after everything else has cycled. Is the movement part the only thing you are asking about or do you need help with the whole project? If you can post even a rough script of how you think it would work then we can help put stuff in the correct place and order. From: Innula Zenovka Assuming I do have to use a separate, invisible, teleporter, is it better practice to have it return to base or to rez a new one each time the gadget is used and have the old one die after unsitting the avatar? Or doesn't it matter? To be able to move the av and still have your equipment in place then you are going to have to go the invisiprim route. Just remember that size does not matter and you could even place the prim on top of a button for example. Personally I would just have it move the av and then go back to it's starting location. But it depends on whether your equipment is going to be moved at any point. The invisiprim needs to store it's home location and would have to be reset if moved, in that instance then it would be better to go the rezzer route which will rez it referencing the equipment/button/whatever location.
_____________________
I (who is a she not a he) reserve the right to exercise selective comprehension of the OP's question at anytime. From: someone I am still around, just no longer here. See you across the aisle. Hope LL burns in hell for archiving this forum
|
|
Klug Kuhn
Registered User
Join date: 7 Sep 2007
Posts: 126
|
10-28-2008 16:44
From what i know of so far, these are the ways to TP an avatar: 1) llSitTarget() - doesn't need to move any object or rez any TP beam. But TP only within 10m from the object. 2) warpPos() or posJump() hack - to move the TPer > unsit > the TPer goes back to the start. Require moving the TPer, no distance limit, and could be done in 1 click if left-click is sit. 3) warpPos() or posJump() hack - to rez a TP beam > the beam move to the destination > TP beam dies when arrived. No moving of the TPer, no distance limit, and require 1 click rez & 1 click sit. The TP beam could go back to the starting position but this would be very inflexible since the beam is not in the same linkset and the TPer might be moved/re-rez etc... In your situation i think it's best to use 3), the TP beam will be invisible but then it requires 2 clicks so i'm not sure it's that what you want to animate etc.. Or, you could do a trick something like to make a invisible prim as for the root of your object 5m higher than the original center of the object. Then use 1) to set the TP to 10m above this root. So you'd end up a simply move avatar-only 15m TP visually 
|
|
Talarus Luan
Ancient Archaean Dragon
Join date: 18 Mar 2006
Posts: 4,831
|
10-28-2008 17:01
From: Klug Kuhn From what i know of so far, these are the ways to TP an avatar:
1) llSitTarget() - doesn't need to move any object or rez any TP beam. But TP only within 10m from the object. Actually the maximum range of the SitTarget TPs is ~520m from the teleporter. Don't forget good ol' llMapDestination().  It's the only way to safely go intersim, especially over long distances and between islands and mainland regions. There's also another trick, but it doesn't always work in everyone's setup. Craft links like these: secondlife://Region/x/y/z secondlife:///app/teleport/Region/x/y/z Clicking on the first link opens up what amounts to a landmark dialog box with Teleport and Map buttons. Clicking on the second like (if it works) will teleport you instantly without confirmation.
|
|
Innula Zenovka
Registered User
Join date: 20 Jun 2007
Posts: 1,825
|
10-29-2008 02:49
From: Jesse Barnett Is the movement part the only thing you are asking about or do you need help with the whole project? Sorry I didn't make myself clearer. Thanks, but I've got everything working as I want it to now; I just needed advice on the best way to handle the movement -- I was hoping I could use llSetLinkPrimitiveParams, since that would have been a more straightforward and economical solution, but posJump works fine for me as an alternative. Thanks so much for all the help, everyone, and all the information about tps, from which I've learned a great deal.
|
|
Strife Onizuka
Moonchild
Join date: 3 Mar 2004
Posts: 5,887
|
10-29-2008 12:03
From: Hewee Zetkin Yes, with llSitTarget() it can be up to 300m away (or thereabouts, since I think each AXIS is constrained rather than the overall distance). History tidbit: 300m per axis, resulting in a total of just over 519m, for a while there was a bug that would crash the sim if the distance was 512m or more. ----- Don't get me wrong, I'm all for reasonable, consistent, limits. I would welcome a TP function, but at the same time I don't want them to limit the Sit Target distance to link distance rules (something they would like to do). It's a physics problem to have large link distances, the math starts to break down.
_____________________
Truth is a river that is always splitting up into arms that reunite. Islanded between the arms, the inhabitants argue for a lifetime as to which is the main river. - Cyril Connolly
Without the political will to find common ground, the continual friction of tactic and counter tactic, only creates suspicion and hatred and vengeance, and perpetuates the cycle of violence. - James Nachtwey
|