LSL Request

The ability to teleport WILLING participants from point A to point B.

I understand that if you make it possible to do this in the code then people would rather do this than pay the fee to use the Landmark system...keep the fee =P. All its really for is show.

I've seen some people attempt "teleporters" with push scripts, but that always seems to end bad.


Maybe there is a way to do this already and I'm just missing it. Either way...somebody let me know =)

if there is a call that does this, it should have a flag that allows the owner to cover the charge

Ooh I like that one Nada, would require its own permision though. Don't wanna buy a chair from someone that they can end up using to teleport them selves from my home at my expense anywhere they say.....

Alternatively, add scripting capability for teleportation, put another checkbox in the build box along with lighting and physics. Tax these objects heavily, like physics and lighting taxes.

Possibly also implement a per-call fee on the teleportation functions, as well. And only allow teleportation from one teleporter to another. (You provide a Sim coordinate, but you get transported to the nearest empty transporter, not to the exact coordinates.) Provide a function that will return the keys of teleporters near the target, another that returns the distance of a teleporter (by key) from the target, and a third that actually teleports to a teleporter (by key), with an integer return value that indicates success (0), or reason for failure (constants).

The owner can then charge different rates, absorb the entire operational cost themselves, or offer teleportation as a "value-added service" at their establishment. If the owner's bank account is too dry to pay the per-call fees, then that teleporter simply ceases to function.

The teleporter-to-teleporter requirement should help reduce the system resource cost somewhat, while providing a business opportunity for those willing to pay the taxes (and the scripters.)

P.S. I forgot. Need a function to determine the cost before actually calling the final teleport function.

it would definately need debit permissions, which can only be recieved from the owner, so no problem there.

oh and grim, for that to work, we would need some sort of inter-object communication(like object to object im) or the communications array that i am putting up, but the message does take time to propagate through the system, and for the teleportes to be worthwhile, they would need to be near instantaneous(with the im, we would still be looking at a 20 second delay...) interesting problem

I'm hoping OtoO IMs and creating/writing to notecards are two of the things that will be added to 1.1, since soooooo many scripters are begging for them.

why a 20-second delay?? OtoO IM's with a 20-second delay would be pretty useless for most applications.

Of course, a good scripter could write a script that would maintain a "database" of active teleporters all over the world, their location, and transfer cost, and not have to query for teleporter data every time they're ready to teleport someone.

heh thats what lists and strings are for! heh i think misinterpreted your post. i thought that you were limiting the number of people at a teleport site at one time, so if you tried to go to said teleporter, it would need to communicate with its fellow 'porters to find out where it could send someone... but now that i re-examine it, you meant that people could only go to certain designated areas, and it would be up to the script to send them to the the nearest one yeah?

and although i want all those functions you mentioned, and have on numerous occasions brought it up, or added my vote to someone else bringing it up, what i really really really want is script controls (heh LL knows all about it , since we keep bringing it up <ducks>

I think the three things I'm most interested in, in order, are:

Owner-configurable "constants" set via GUI. (You know, the GUI that the docs mention, but no one can find.)

Write to note cards in inventory.

script "libraries" that can be sold and used by customers while protecting the source code.

The OtoO IM's will be nice for performance, if properly implemented, but for my normal usage it would just be an efficient replacement for llShout().

Yes, although you wouldn't want one av teleporting into another one, so there would have to be some sort of failure message indicating that the teleporter is "occupied" or something to that effect. You could just retry a certain number of times before giving up or moving to the next-closest target. C'mon, the scripters have to provide SOME of the logic, otherwise nobody'll need us any more.

Teleporting into people isn't that big a deal, it already happens or is handled for just for people teleporting to a landmark spot.

Actually, IMs from objects to avatars have only a ten-second delay. In my experience, this doesn't mean that it takes the IM ten seconds to reach the avatar. It means that the script pauses for around ten seconds after sending the IM. If inter-object IMs had the same behavior, a response might be received in eleven seconds.

As for why there's a delay, my theory is that the Lindens wanted to prevent objects from overloading a system intended for communication between players.

"Silly object! IMs are for people!"

In addition, the potential for mischief with objects that could spam endless chained IMs to a key is pretty clear.

I don't think the scripts pause, as in sleep, though. Some other kind of cue or something is piled up.