Jump to content

Merge two scripts together - help please


Sarah Glenelg
 Share

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

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

Recommended Posts

Hi there - I can happily fiddle with scripts to adjust them to do what I need but I need some help on how to merge two scripts together.  I have a dialog script that can display a button and execute a command when the button is pressed.  What i would like it to do is to teleport the user to a location on the sim.  I also have a simple teleport script that I would like to use here but I'm not sure how to merge the two scripts to get the desired result.  Here are the two separate scripts - any suggestions welcome and thanks in advance for answering:


Dialog script
-------------------
 
integer gListener;     // Identity of the listener associated with the dialog, so we can clean up when not needed
 
default
{
    touch_start(integer total_number)
    {
        // Kill off any outstanding listener, to avoid any chance of multiple listeners being active
        llListenRemove(gListener);
        // get the UUID of the person touching this prim
        key user = llDetectedKey(0);
        // Listen to any reply from that user only, and only on the same channel to be used by llDialog
        // It's best to set up the listener before issuing the dialog
        gListener = llListen(-99, "", user, "");
        // Send a dialog to that person. We'll use a fixed negative channel number for simplicity
        llDialog(user, "\nFREE GIFT VENDOR IS ON TOP FLOOR", ["OK", "Cancel" ] , -99);
        // Start a one-minute timer, after which we will stop listening for responses
        llSetTimerEvent(60.0);
    }
    listen(integer chan, string name, key id, string msg)
    {
       
       if (msg == "OK")
    //        [run the teleporter script]
       
        // Make the timer fire immediately, to do clean-up actions
        llSetTimerEvent(0.1);        
    }
    timer()
    {
        // Stop listening. It's wise to do this to reduce lag
        llListenRemove(gListener);
        // Stop the timer now that its job is done
        llSetTimerEvent(0.0);// you can use 0 as well to save memory
    }
}


Teleporter script
---------------------------

// Set your target position below (must be in same Sim):

vector targetPos = <27,200,29>; //The target location in vector format <x,y,z>

string floatText = "";   // change to "" if you want NO float text


reset()
{
    vector target;
    target = (targetPos- llGetPos()) * (ZERO_ROTATION / llGetRot());
    llSitTarget(target, <0.0,0.0,-1.0,1.0>);
    llSetText(floatText,<1,1,1>,1.0);
   // llSetSitText("TO VENDOR");
   // llSetClickAction(CLICK_ACTION_SIT);
}
default
{
    state_entry()
    {
        reset();
    }
    
        
    changed(integer change)

    {
        llSleep(0.2); //helps when SL is being laggy
        llUnSit(llAvatarOnSitTarget());
        reset();
    }    
}

 

 

Edited by Sarah Glenelg
adjusted title
  • Like 1
Link to comment
Share on other sites

Teleporting is weirdly tricky. The specific teleporter script you've picked transports the avatar using a big sit target offset, so it only works when the avatar sits on the object.

There are some other classes of teleporter script, but to curtail griefing, they all rely on the teleported avatar doing a little something more than merely touching an object and answering a dialog.

For example, the easiest way to mash together these two particular scripts to end up with a teleporter would be to require the sitter to agree to Experience permissions and then when the respond to the dialog the script could call llSitOnLink(), triggering the sit target teleporter of the second script. That's almost never practical, though, because Experiences come with a bunch more work to set up (they only work on land that has explicitly enabled the Experience, among other things) and, if the script has all that Experience stuff built-in it can just call llTeleportAgent() without needing any of the sit target stuff of the second script.

If, however, there's already a custom Experience as part of the scene and every visitor will have granted Experience permissions, this can be a very tidy approach -- although it, too, is subject to some caveats, notably it is like Map-based teleportation in that it respects any landing points set on the parcel, unlike sit-based teleporters.

That hints at some of the other kinds of teleporting: sit-based "ride the prim" transport which can go greater distances than the sit target approach, Map destination transport, non-temp attachment transport, etc. And choosing among them isn't always simple, depending on such factors as distance as well as whether there are multiple destinations to choose from, whether multiple people could be trying to teleport at the same time, etc.

So, that gets to the real question: what are you really trying to do? If you're simply wanting to see how to combine two scripts as an academic exercise (and you're either Premium or know somebody who's Premium and will lend you their Experience) we can get these two scripts together into one that will teleport avatars. If you're trying to make a non-Experience-based teleporter, though, we need to understand why it should be touch-activated and more of those details about the application.

Link to comment
Share on other sites

Hi Qie - thank you for your detailed reply.  As requested, I'll explain my application.  I have just started a store in SL selling mainly ladies fashions.  The store is on 3 levels and I probably have about 200 vendors.  In the shop window I have some mannequins displaying some of the outfits.  To save people time in walking around the store looking for the vendor for a particular featured outfit, I want to give them the option of teleporting to the vendor they are interested in.  I have tried putting the teleporter script into the mannequin object itself which works fine but it is a bit abrupt in teleporting people when they clicked on the mannequin.  So, I had the idea that when they clicked on the mannequin, a dialog box opens up, describing the outfit and its price and offering a button that will teleport them to the vendor if they clicked it - that way, the person has control over whether they want to be taken to the sales vendor or not. 

So I have the dialog script and the teleported script and thet is why I want to merge them together.

Thanks

Link to comment
Share on other sites

Thanks, that's very clear. Now... what would I do in your situation? Hmm...

First, I'd rule out the Experience-based solutions. They could be very cool, but they'll spook your customers: "What? You want ALL THOSE PERMISSIONS? What kind of scam are you running here?" 

I can see that the immediate sit-to-teleport thing would be very abrupt: "I just wanted to learn about the outfit, not get lost somewhere in the middle of the store."

What I'm coming up with is an old, two-step approach, with two separate scripted objects. So the first script runs and offers information and etc and its dialog offering to teleport to the vendor location. When that option is chosen, the script temp-rezzes a separate object, perhaps somewhere near the dialog-responding avatar, and advises them to sit on that object to get to the vendor. That temp-rezzed object might be set "left click to sit" to make it a little easier. If nobody sits on it in a minute, it just vanishes by virtue of being temp-rezzed, no clean-up required. If they do sit on it, I think a sit target script like your second one might be best because the store destinations should all be within range. (One would instead use the "sit to ride the prim" approach if the destination might be, say, a bargain basement skybox or something.)

So again, instead of combining the scripts, you'd be using two separate objects with two separate, relatively simple scripts. The trickiest part now is deciding how to most conveniently tell that temp-rezzed object where it should go for this particular mannequin's in-store vendor. That's not rocket science or anything, it's just the thing you'll be configuring on a regular basis so it would be good if it's not too cumbersome. One way could be for the mannequin to use a description field you can edit to describe the teleport destination, which the temp-rezzed object can learn using llGetObjectDetails(..., [OBJECT_DESC]) of its own llGetObjectDetails(..., [OBJECT_REZZER_KEY]), but there are innumerable other ways to do it. One other worth mentioning is to compress the destination coordinates into the single integer that's passed with llRezAtRoot.)

Maybe somebody else will suggest a better overall approach. Or maybe I'm overlooking something about the application that makes this a bad idea. But if/when you want to follow this approach, let us know how we can best help.

Link to comment
Share on other sites

... although to be practical about it... I think if it were my store, I'd simply add separate "Teleport to Vendor" mannequin pedestals or some other permanently rezzed object with click-to-sit, scripted with something like the second script, and not bother trying to integrate the functions at all. At this point I think most shoppers are accustomed enough to teleporter objects like that. Makes it all less exciting for the LSL Scripting forum, though.

  • Like 1
Link to comment
Share on other sites

from a inworld shoppers pov I do wonder why I couldn't just buy the garment from a little vendor set next to the mannequin. As a shopper I just want to give you my money in the easiest and most convenient way to me. At this moment I am more on a shopping expedition to buy stuff, rather than a sight-seeing tour

the next most inconvenient thing for me as the shopper is that I don't want to wait round for stuff to rez and then have to work out that I have to sit on it, or give permissions. I just want to buy the thing

if I do have to go somewhere else to buy the thing then as a shopper I prefer to see where I have to go. So that if there is a teleport bork, then I at least have had some previous knowledge/indication of where the vendor is

this all said.  In this scenario the simplest thing is for me (the shopper) to get a llMapDestination

Touch the mannequin. Get dialog with info. Click the button on the dialog. Get a Map destination. Click the World Map teleport button to go to the vendor

 

 

 

Link to comment
Share on other sites

Thanks Molly for your input.  In my situation, the vendors are franchised so I cant put any purchase options in my mannequins, the best I can do is to direct people to the vendor of interest.  Qie, I do have a small sign at the base of the mannequin that has a teleporter in it but I noticed people click on the mannequin anyway so wanted to provide that option too.  Thanks.

Link to comment
Share on other sites

On 7/21/2019 at 2:44 PM, Sarah Glenelg said:

Thanks Molly for your input.  In my situation, the vendors are franchised so I cant put any purchase options in my mannequins, the best I can do is to direct people to the vendor of interest.  Qie, I do have a small sign at the base of the mannequin that has a teleporter in it but I noticed people click on the mannequin anyway so wanted to provide that option too.  Thanks.

As the situation in your shop is not the typical user case in SL, I can imagine that people don't understand that they need to click the signs. However, you should keep it as simple as possible for everyone involved. In my eyes the most practical solution would be to add a "teleport" option to the dialog menu. If people click on it, then the public chat tells them to click on the sign at the base in order to teleport to the vendor and buy the object. Then they do what they would usually do in a shoping situation and get as a result the information what they need to exceptionally do in order to get there...   😉

Link to comment
Share on other sites

Thanks Estelle, thats a good suggestion.  I gave up on trying to merge the two scripts since I couldn't find a way for the script to 'sit' the avatar on the object for the teleport since clicking the dialog button wasn't the same as clicking on the object and the user had already clicked the object to bring up the dialog window.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1735 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...