No more warp?

Invisiprims are a bug/hack that was never intended, but LL keeps it working. They 'broke' invisiprims during a beta last year and quickly 'fixed' them so they worked again since so many people used invisiprims. LL has said they don't want to break existing content, which they've done with whatever happened with llSetPrimitiveParams, so it's possible they'll return it to how it was before.

Actually, there were two types of invisi-prims back then. LL broke both types, then restored one type.

I wonder if over-sized prims are next the list.

"Support for multiple PRIM_POSITION rules will be enabled again, but a delay may be added."

Discussion may now resume.

Thank the gods!

Log in to JIRA and here is the bug report for it.

Vote to make sure it gets fixed!

Well, that's good news...sorta.

I posted in Resident answers about this before being told about this topic. If anyone wants the link here it is. /327/33/171479/1.html#post1438388

I use warppos in serenity woods for the teleporting units. I agree this was a bad thing to log in and find out. :/ I also know that LL probably doesn't care, even though i remember them once stating that their goal is not to break existing content. :/ What ever anyone comes up with will be greatly used. Still i would rather get warppos back how it was. So i decided to vote on it here. https://jira.secondlife.com/browse/SVC-47

And here I've already taken my Superporter off-sale and replaced my Superporter networks with my old Long Distance Teleporter networks.

I know how you feel. I had DELETED my semyfunctional newgate pads (sorry newgate, there's a bug in there) and had uploaded a "our teleporter is busted, click for landmark" sign.. before I read that.

No good news, a delay in the call would still kill off both warpPos as well as fast communication.... This is just adding insult to injury.

The crooked house is currently broken as well :-/

(Warppos is also useful for things other than teleporters)

if the old WarpPos hack is being "depricated" as being "an unintended effect that is adding to performance issues, that LL is no longer able to support"... then it is at LEAST reasonable that LL go back and "patch" a "WarpPos" implementation, so that it functions at all. If it reverts to the old "while loop" method's functionality.. sure, it's no better and people will just go back to dealing with "slow taxi prims"... but at least all that old stuff people bought.. will FUNCTION again.

Example: (made up numbers)

50,000 teleporters on the grid use WarpPos
50,000 teleporters use while loops.
Half the teleporters don't work at all today.
Better to have all teleporters working, (half, less well than originally intended) than to have half of them permanently broken.

Personally, I'd prefer the old (yesterday) functionality back in it's original form....but if the best LL can allow is provide "some" support for devices that used the hack... that's at least better than "sorry.. it wasn't official LSL.. you guys cheated and now you're screwed"

This will definitely have me doublethinking next time I do something unsupported in a script.

An even better solution would be to remove that 10-meter limit at all. Saves the scripting hassle with building up the PRIM_POSITION list, thus removing some script impact.

If they do feel the need to add a delay it may be directly calculated out of the total distance travelled.

But if the 10-meter limit was imposed because of some anti-griefing measures (for example to not to have objects scattered around a sim) and remains there to stay, a llTeleportAgent() function as a valid replacement would be strongly encouraged.... Of course a function teleporting the agent would need an extra permission bit denoting wether a user gave the object the permission to change the avatar's position (and maybe heading, rotating av's has been broken long enough)?

Yep iTP is also broke because of this. I IM'd the Lindens about it last night but they did not seem bothered. I have taken iTP off the market like I bet most other teleport creators who used WarpOS have with theirs. Maybe the lindens should also include a list of things they have broken along with the list of things they say they have "fixed".

"Here lays iTP", until we can think of another way to fix this.

This was driving me crazy last night - I was working on a new build and put some of my teleporters around, and none of them were working right. I gave up in frustration and logged out, then came to the forums and found out about the warppos break.

So I too had to log in to my stores and take my teleporters off the market. Fortunately I'm fairly new and haven't sold that many yet. I'm hoping that SL will fix the problem in the next few days so I don't have to revert to the while..getpos...setpos routine. I've implemented that temporarily on my own (so I can get to my skybox) but it's sooo slooooow.

-Atashi

As i stated once already though, The whole reason i used warppos was do to the soul fact that ti DIDN'T have a delay... I can understand if something is server intensive but i didn't see these being that way. In fact, if they are, then perhaps instead of setting delays and limits to everything, maybe LL should beef up their servers for once. >.>

omg, it just came to me.. the linden plan is to replace
intra-sim transport with:

llPinballPort(vector d);

The pinball transport works via:

a) doing llShout() to temporarily rez huge bumpers along the route

b) giving the AV a mighty push via llApplyImpulse()

The bumpers will help keep the AV on track. It should be possible
to make a trip anywhere in a Sim with < 32 deflections.

This should allow for much faster transport than the llSetPos() method.

It should also create a market for designer "transport padding" to keep
AVs from getting killed by merely traversing damage-enabled sims.

I'm betting they do this April 1st ...

DON'T do it this way! If your object tries to go through a mountain or other piece of land, it'll never get to its destination and loop forever. It's really important to add a bail-out, so that your loop tries only a certain number of times before it gives up. I've seen Cadroe shapemaker prims sitting there setposing as fast as they can go for months before someone noticed them.

The 10-meter limit has nothing to do with griefing and everything to do with inter-sim communications. It is there for the same reason prims are limited in size to 10 meters in any dimension (yeah, I know there are exceptions; talking about the actual scale/size numbers, not the weird, contorted prims which get around it): because the sims have a 10m buffer/overlap at the edges adjacent to any other sim where they try to sync everything that exists in the overlapped area with each other. This is in an attempt to make border crossings more stable. Bigger objects and bigger moves would require a larger buffer, and more simulation work on each sim because, basically, any particular sim is simulating everything within its own borders and everything within the buffer area in all adjacent sims.

That's why intersim travel with WarpPos is rather.. nasty.. at times. To do it right, you really need to stop within the 10m buffer area for a moment to give the adjacent sim you are trying to move into time to start simulating you, then move across into the adjacent sim's buffer zone, wait a bit more for the transfer to get a little further along, then you can move to your destination. In general, it is very nasty, and the safest method of intersim travel remains llMapDestination.

On the other hand, if it's not effecting the sim itself, it strikes me as a case of 'let the scripter beware'. There's certainly enough other dumb things one can do through scripting!

From SVC-47



So, hopefully, everything will be fine in the next grid update.

Havent found a woraround sad to say........

HAHA... yah LL quality testing for yah...
(break it then suhhh see if anyone notices it)

I tested it, and WarpPos works in the Beta grid.

Hopefully they'll update the Main grid before next Wednesday, but at least it's coming.

Bunnyporter works again!!!!!