Jump to content

Positioning script needed


Dictatorshop
 Share

You are about to reply to a thread that has been inactive for 2973 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Hi all,

This probably exists but I cannot seem to find it.  I would like to have a way to have one item check for another when rezzed and position itself in exactly the right position relative to the first item.  Is there an easy way to do this?  I dont want to use a buliding rezzer, too complicated.  I would just like to be able to have a one time move and position.  Anybody know any solutions for me?

Dee

Link to comment
Share on other sites

The positioning part of this seems pretty straightforward; the tricky bit may be how the newly-rezzed object knows about the existence of the other target object, whither it is to move:

Is it just by name? If so, a one-shot sensor scan may be the only choice -- and hope the nearest matching name is the right instance.

Or, by any chance, is the object rezzed by the very target object that it's supposed to move toward? (If so, this is suddenly trivially easy, thanks to the brand-spanking new OBJECT_REZZER_KEY flag to llGetObjectDetails.)

Or, failing that, are they both rezzed by the same script? If so, that script could facilitate identifying that target object.

(This all assumes the two objects will be in the same region, or at least very nearly so. If not, this gets way more complicated.)

[ETA: It's rarely safe to just llRezAtRoot to a particular location, unless you can be absolutely sure that location is within 10m of the rezzer. Rather, the rezzed object will need to learn the location to which it should llSetRegionPos(), and it may learn that using llGetObjectDetails() of the target object. I'd also mention that the rotation of the target is likely significant, to know where the moved object should be relative to that target, and to what orientation it should rotate.]

Link to comment
Share on other sites

Well, if that's a requirement of the application, that would be another reason for the rezzed object to know the identity of the target, so it could track it.

But what I meant was that if the target location is more than ten meters from the rezzer, the newly rezzed object cannot simply be rezzed into position (and the rezzing function will just silently fail).

Link to comment
Share on other sites

Hi, 

Let me give you an example.  Let's say I sell a canopy style bed and it is already done and for sale.  Then I decide I would like to offer canopy curtains as an extra add-on. I would like to be able to have the user be able to rez the curtains on the bed and just have them move into place automatically.  They wouldnt be part of the bed, just an extra bit.  I dont want the user to have to fiddle with getting them lined up themselves.

Link to comment
Share on other sites

Okay, but if the owners have mod perm on their bed, the curtains could be added to the *contents* of the bed and its script get updated to rez them from the menus (using as Steph suggested llRezObject or llRezAtRoot) -- or they could just get rezzed from the owner's inventory and find their way to the right position on the bed.

That second, manually-rezzed approach could be done with curtains owned by somebody other than the bed (although I doubt that's important here), and without any update to the bed itself.  I think I'd do it with a one-time llSensor() scan in on_rez() to find the bed. (That's potentially tricky because the owner may have renamed a mod-perm object. Maybe, if scanning by name didn't find the object, the script could just scan for the sixteen nearest scripted objects and wade into that list for the closest one with the same OBJECT_CREATOR as the to-be-curtained bed; that should usually work.)

Anyway, once the bed is found, it's trivial to llGetObjectDetails() to find its OBJECT_POS and OBJECT_ROT relative to which the curtain-rezzing script would llSetRegionPos() itself.

Note that this all assumes the owner hasn't re-linked a mod-perm bed such that a different element is now root. If that's happened, it would be almost impossible for a script to be sure where to put the curtains (even for a script running inside the bed). For that matter, the owner may have rescaled a mod-perm bed in the editor (possibly adjusting poses accordingly) such that the curtains wouldn't be the right size for it; they could maybe try to resize themselves to match the bed's apparent scale, but trying to identify and address all these "what if"s is getting pretty complicated.

Link to comment
Share on other sites

OK well i suggest you use a dedicated rezzer rreference  prim that is part of the main build, ie the door frame. Then that prim will be the relative position and rotation point and rezz from a HUD that you can add  extras too. But as was pointed out by Q, does assume certain variables, Could include an editable offset notecard, These things are some what heavy going script wise even tho the scripts look simple when done. I wrote and designed my own system and was a headache. Never thought of using a scanner, but that adds another layer of complexaty.

Only my point of veiw  but, seems a lot of work when the owner can just manualy rezz. Actually that could be the answer,  Use a one time pos etc and pass that info to the rezzer then take it and drop into the HUD, still seems a lot of messing around tho as many can not even open the contents of the HUD in which case you will end up with loads of IMs asking you to sort it out. Any how that upto you, best of luck/.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2973 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...