New Limitation

I am severely concerned with this as well. One of the pulsing questions in my head is why would LL place more limitations on something that already worked perfectly?

There has to be *some* reasoning for both changes, and I want to know it.

==Chris

The current 1.3 preview sets the llSitTarget limit to 300m, up from 10m, but not as high as 1.2 (128m into adjoining sims, or near unlimited vertical)

As for why, I've been witness to many times when using sit-target teleportation, avs get stuck on one end of it, or disappear, or generally do all the things Bones warned us about on Star Trek.

So? That just means the coder needs to target things better. Unless it's causing problems with the SERVERS, there's no reason to limit it. Or instead a backend fix needs to be made for ALL forms of long distance travel.

Lemme give you an example:

Myself and five people all sat on various faces of a cube and started travelling. We started in Seacliff. We travelled all the way over to DaBoom, then to Dore, then way up to the northern-most sims.

Not by script, not by physics, but by me editing the position settings in the cube. Generally 230m at a time, and dragging the cube across sim borders.

Know how many problems we had? Two. One was the VERY rare occasion where an avatar with a slower than recommended connection interpenetrated with an off-world area (since I tended to skim the cube along the edges of sims) and would get tossed off the cube, and the other was when people wouldn't figure out what I was doing, and the camera would stay whilst their AV would move with the cube.

The first would be considered 'normal' for people with lower than average connections interacting with the edge of sims.

The second can be fixed by a change to the client.

No one had problems with sims dropping their connections, no one had problems with sims not updating prims around them.

I was essentially llSetPos-ing 23x the allowed amount in a single jump. And I did it more than twenty times. With the same cube. With what became, eventually, over fifteen+ people on a single cube.

If the sims can handle the repositioning of a single cube and over FIFTEEN avatars AT ONCE, including having those avatars all cross sim borders all at the same time, without major issues, why in the WORLD must things be limited to 10m?

If llSitTarget() can be 300m (almost entirely because David Linden came across the Clover transport system in game last night), then what is preventing llSetPos() from being 300m as well?

I think they do it to make it harder for people to screw up and lose control of some object they are scripting.

I don't agree with the philosophy of "protect the designer from herself/himself".

We should be given the tools and the burden of using them responsibily. If someone uses a tool for mischief, they should be punished, not have everyone's tools dumbed down.

Give us tough tools that we can use to create powerful and amazing things that may sometimes be problematic, but don't try to protect us from ourselves by turning all our tools into foam-padded tinkertoys.

Some of the reasons I can think NOT to give us a certian tool is if it:
- takes too much developer resources to implement
- takes away someone else's capabilities on public land without their consent (llFreezeAvatar without a permissions dialog)
- could violate standards for privacy (no llGetRLName or llGetRLEmailAddress)
- directly interferes with the economy (no llCreateMoney)
- directly interferes with the general environment (no llMoveWorldSun or llSetWaterLevel)

Some things which I think would be nice additions, but come with some degree of responsibility include:
- make your avatar invisible
- make your avatar phantom
- teleport to precisely anywhere on the map
- change your title without a group
- temporary decals on any object
- removal of the "no build" and "no script" land flags
- "home" should be able to be set to anywhere, not just on land I or my group owns
- teleport-on-death location should be a separate location distinct from "home"
- any object that has been in the sandbox for more than 1 hour while the owner has not been in the sim should be movable / returnable by anyone
- llSetMass

But that stifles creativity, at the expense of coders who actually know what they're doing. And exactly -how much- harm can someone who DOESN'T know what they're doing DO with SitTarget? Or even SetPos?

I've lost stuff before by carelessly using llSetPos(). Had to do it in a loop of course.

That certainly doesn't excuse the limit.

Please don't nerf llSitTarget to any less than 500m. It's incredibly fun, it's the first useful instant elevator, and frankly even if you cross sim borders it's more reliable than the telehubs.

Ah, if this were the case, I say, "give us what we really need!" We really need a /usr/bin/top style task/process list for owned tasks on the sim. Ideally, such a feature would help us understand how resource-friendly our tasks are, allow us to kill them from afar (presumably from within a given sim), and provide the location of each owned running task.

How cool would that be? Well, a lot cooler than child-safe lib calls!

I'm posting against my better judgment, but after poor response to my attempts at private communications in this matter I feel more background should be provided.

First of all, I should mention that I use llSitTarget extensively. The complex Drift and I have created in Clyde virtually depends on it as it stands.

When I first discovered the properties of this command my first thought was "I can't believe LL lets it work this way". I knew at some point this would be examined and removed, that day just came a lot sooner then I thought it would.

The day of the preview sneak peak I took my scripts into the test grid to see what would be broken. Low and behold llsittarget is set to 10 meters. So I took the only reasonable option available, I spoke with the Lindens. I demonstrated how I was using llSitTarget, showed where I felt there was a need for something of this nature. After discussion they let me know they had decided to TRY it at 300 meters rather then 10. This does not mean that is what is going to go live with 1.3.

There are many ways this code can be exploited, trust me; I have seen tons of them. I'm not going to say here or anywhere what those exploits are. Hopefully those loopholes can be found and plugged. In the grander scheme of things the current function of llSitTarget can be used to circumvent Linden Lab vision for social gathering. Also there are some bugs that occasionally pop up, as mentioned elsewhere in the thread. All in all though I believe there is a place for instant transport functionality, and while I would like to see a 512 meter limit as well I’ll take 300 if that is what Linden Lab is willing to compromise with. Its certainly much better then 10 meters. It was also mentioned that a specific teleport command could be created in the future, and sittarget restored to its proper role. Until that day I'll gladly take 300 meters over nothing.

The whining I see here in the forums is astounding. There is NO program ANYWHERE I have seen that provides such direct communication with support staff and developers. If you have an issue at least use that capability to get the full picture before exploding.

In my opinion LL should kill these forums like SOE did with the EverQuest forums. Nothing but bad feelings come from anything here.

I spoke with the parties in question before posting this, as these were private communications. Though they agreed to allow me to discuss this, this post in no way is a statement of LL policy, and is not a promise of future features.

If you want more clarification please contact me in world.

My creativity, your creativity, and anyone elses creativity should not be stifled because LL doesn't like it. I don't like rap music. Does that mean all rap music should be banned from my presence? I don't like how adding rotation to any prim in the game instantly makes it 'art' by some people's standards, but does that mean it's any less worthy than my simple particle script fireflies?

Besides, the only 'circumventing' the function does is let us go through solid objects, which you can do just as easily with at least three different non-script related UI interface tools. So if LL honestly wanted to prevent teleportation, they'd nerf those other things as well.



Uhm... last I checked, SitTarget's proper role is the repositioning of an avatar. How is that NOT a teleport function?



'scuse me? Whining? We're attempting to get direct communication with LL in a fashion that won't get us banned, or the thread deleted. Realize, LL has a nasty habit of deleting threads the moment any private conversation gets posted to them. You even say as much in your post, when you actually had to go out of your way to get PERMISSION to post information to the forum. So the only way to disseminate information is to get it posted by a Linden in public fashion to the forums. We're USING the tools provided by the Lindens for communication with the Lindens. It's now up to the Lindens to step up to the plate and respond in kind.

That doesn't sound like a very good argument to me. Almost anything can be used to circumvent LL "vision" for social gathering: push scripts, particles, llPlaySound, even llSay. Anything at all can be used against the desired functioning of a social event.

If they change how llSitTarget works, they'll break a lot of scripts for little to no gain. Not a good decision IMHO.