No more warp?

Did the latest server-side update break llSetPrimitiveParams using PRIM_POSITION more than once, or is it just me? I've got malfunctioning teleporters and communications equipment (that passed messages using fast-moving objects) all over my sim.

Yeah, broke it good.

All warpPos teleporters are broken, as are any other teleporters that used chains of llSetPrimitiveParams calls.

I take it back... The teleporters in Argent Stonecutter's SkyHook Station appear to work... Sorta. At least, one of the destinations works, although the others don't appear to.

Hehe, although I did just have one of his dropped me off in midair! Nice fall down to the lagoon, haha.

Stupid, LL, just stoopid. Broke a lot of stuff today, it seems.

I noticed the same. Using the excellent warpPos in a TP system I built into my home, and as of this update it drops me off after the first 'hop' of 10 meter.

Don't have time to test it myself today, but some thoughts:
1. Can it still handle multiple parameters, just not more then one of a certain type? I.o.w. can we still do a move/rotate in one step, or a texture/color change?
2. Maybe the problem is not that it can't handle the multiple list anymore, but it just can't handle the out of bounds values. Maybe the target vector has to be 10 meter or less in length and multiple lists would still work? Worth checking out.

Update, found another popular place with warpPos type teleporters, they are broken too.

Way to go!!! Woohoo!!!

Argent's use a variety of methods depending on the destination. Nice work there, BTW.

I'm less concerned about the teleporters (I can always go back to the 50m/s method) than I am about how this has borked all my interobject communications, which were sort of relying on being able to get the message to the destination in a reasonable amount of time by having the "carrier pigeon" warp to the destination.

UGH, my "test flight" panels are broken, too. Again, an easy fix, but I'm effectively out of business until I get all these scripts updated. Still don't know how I'll replace what has so far been the only effective high-speed non-throttled inter-object communications method I know of.

I'd sure love to see llTargetSay(id, channel, msg) one of these days. All the backend code is there -- listen events, the ability to restrict who hears it (witness range restrictions in llWhisper), all we need is a call that makes sure only targetted UUID hears it, and give it the same range as llOwnerSay.

Good thought. (/me runs off to test.)

No joy.

default
{
    touch_start(integer total_number)
    {
        vector pos = llGetPos();
        llSetPrimitiveParams([
            PRIM_POSITION, pos + <8.0, 0.0, 0.0>,
            PRIM_POSITION, pos + <16.0, 0.0, 0.0>,
            PRIM_POSITION, pos + <24.0, 0.0, 0.0>,
            PRIM_POSITION, pos + <32.0, 0.0, 0.0>,
            PRIM_POSITION, pos + <40.0, 0.0, 0.0>]);
    }
}

Result: Object moves only 10m total, despite each position being within bounds of the last. So much for that idea. It does verify, however, that it either takes more than just the first parameter, or it only takes the last and clips it to 10m. My guess would be it only takes the last, since if you're setting the same thing more than once, the second change will overwrite the first, so it's now optimized to simply discard all but the last one and only attempt to do that, clipping if necessary.

Bummer, so basically the bounds check is now for the whole list in total instead of for every single parameter

That seems a bit of a tough change to do without notifying beforehand? I can't imagine this was an intended change. Maybe a side effect of some other changes?

Yep, seems like. This sinks:

default
{
    touch_start(integer total_number)
    {
        vector pos = llGetPos();
        llSetPrimitiveParams([
            PRIM_POSITION, pos + <0.0, 0.0, 2.0>,
            PRIM_POSITION, pos + <0.0, 0.0, -2.0>]);
    }
}

Yea, this is lovely...they've single-handedly broken 90% of my merchandise as well as the turbolifts I built for my group's sim.

I sincerely hope this is a bug and not intended because there's just way too much content that this has screwed over.

If bounds checking is done in a new way, does this also break prim torture scripts using chained llSetPrimitiveParams calls? It seems logical to me, although I dont use any that I need to go test now...

LOL When I first read that, I misread it as, "This stinks". I'm inclined to agree.

Isnt this wonderfull, half of the spots in my 45K traffic sky palace are now spunked up by those code monkeys. Someone feed em a bannana and demand for it to be put back the way it was please. :/

Gaius, does this mean that your ships' auto-park feature is busted?

Sadly, I doubt LL will fix warppos(), as it is "unintended."

Well, I guess it's back to

while(llGetPos() != d) llSetPos(d);

at least till something new is found.

Yes, autopark now only works if you're with 10m of the parking spot to begin with.

***

There is a workaround to this. I call the script "pseudowarp".

default
{
    link_message(integer src, integer num, string msg, key id)
    {
        if ( num == -13013 )
        {
            if ( llGetSubString(msg, 0, 4) == "warp:" )
            {
                vector dest = (vector)llGetSubString(msg, 5, -1);
                while ( llVecDist(llGetPos(), dest) > 0.01 ) llSetPos(dest);
            }
        }
    }
}

By itself, it don't help. But drop a dozen copies of this into an object and you can use a link message to simulate WarpPos. Example usage (from the replacement for the DreamTech Teleport System):

    llMessageLinked(LINK_THIS, -13013, "warp:" + (string)dest, NULL_KEY);
    while ( llVecDist(llGetPos(), dest) > 0.01 ) llSetPos(dest);

The numeric parameter is used to avoid making a string comparison when not necessary, and the string prefix is used to distinguish "warp:" requests from other link messages that might be passing data in the integer param that happens to come out to -13013 for whatever reason.

Damn close to the same speed, if you use enough "pseudowarp" scripts. Of course, this probably generates massive lag, but that's par for the course. If LL didn't want scripts using massive resources, they'd remove all those silly delays and limitations since the inevitable workarounds always end up costing more than it would have cost to just let the original function work without delay or limitation to begin with. If LL really wants to keep the grid running smoothly, they'll just revert this particular change back to the way it was. They could make it work even more smoothly by removing or shortening a lot of other script delays, but that's another battle.

Argh!!!!! I can't believe they'd break this. One would think the Lindens
actually use the very environment they write, and would give a heads up on this.

Yes, WarpPos() was a hack. But it was a good one, brought about by the sheer
LL shortsightedness of not making a llTeleportAgent() call.

Would be competitors: take note of the forums and the blogs. There
is much to learn. Many mistakes made that should not be repeated.
This one will have a lot of eyes rolling today...

disappointed

That's pretty similar to what I was thinking of using to fix it if they decide to leave it this way...I'm not touching anything atm in hopes that they will put it back. I am going to get the 'fixes' ready just in case tho...

I would be a lot less disappointed if I ever saw an acknowledgement that things were broken... It was suggested earlier in this thread that this might be caused by a "fix" to llSetPrimitiveParams() that resulted in this "unintended feature" being broken... If that were the case, I would certainly expect that LL might give us the "this is why we did that" reason, like they did with joints.

Or maybe too many joints is still the problem? (heheehee, I just couldn't resist after re-reading my post and seeing that last sentence again)

Or a quick and non-delayed method of sim-wide inter-object communications, ala llTargetSay(id, channel, msg). The warping "carrier pigeon" was my favorite work-around for that particular problem, but alas, no warping now without even more massive, ugly, and resource-consuming hacks. I don't see how LL is going to help the grid grow and gain better performance by constantly forcing script writers to consume more and more resources to work around the limits.

I say Second Skies holds a race to see who can move a Prometheus around the grid in 80 seconds or less.

MUHAHAHAHAHAHA!!!!

lol you should of seen some of my early test flights. I lobbed large sections of the ship clear across the grid. Was crossing from Abbotts to Rosedale and got messages from pieces being returned for going off-world in Crimson and that other C-color word next to it (even if I could spell it, I wouldn't know the color if I saw it). Heh heh heh.

Of course, this is completely off-topic.

Hey! many many thanks I was able to fix my teleporter with this fix. Teleporting is a lot slower, but at least it works.

Meni.

Well, damn. No wonder my ears are burning.

(and no wonder I'm getting all these messages about things getting returned to me because they were in the wrong place)

First things first, my diagonal-offset long distance sit-teleporters still work up to 511 meters. I'm going to redo my teleport networks to use this short term, and they're still available at Skyhook Station, and they're still open source.

Second, the physical-motion code in my Superporters will work below 768 meters just as well as above 768 meters. It's going to take some hacking but I should be able to get some semblence of Superporter action up again this weekend. But I'm not going to work on this until this weekend... I don't have time, and Linden Labs might have an attack of generosity and either fix WarpPos or implement llTeleportAgent().

And third, now we REALLY need llTeleportAgent().