Secondly, any limitations will simply penalise a lot of people. Your generalisation of "griefers" is very narrow minded. Many people use weapons for fighting against griefers.

And don't forget the golden rule. DON'T BREAK EXISTING CONTENT

Try asking Luc Aubret, or Lil Carducci about these things. Indeed, I make most of my money from my own highly advanced weapons. There are people whose entire income, and therefor lives, depend on weaponry.

IF you don't want these things to happen to you, quit whining about it and do something. Like buy a non phys shield. And quit trying to cripple one of the biggest markets in SL.

You only want to continue selling your weapons, don't you?

I want this fixed, too.

• Limit movement to between 0 and 700m altitude. Period. No one needs anything above/below. If he currently does, he misuses 'altitude' my eyes, anyway. There should be a grace period then to move all prims to 0-700 range, then set the limit
• Switch for user: disable push

Tillie, your idea of moving all prims below 700m scares the heck out of me. I would hate to see someone's build that spanned the 700m barrier completely and unilaterally broken by LL attempting to "solve" griefing. Disabling push on a user-by-user basis was debated to exhaustion in the forums, and the existing Push Restriction system was chosen as an acceptable compromise. If you don't want to get pushed, buy some land and set it no-push.

I don't support WarKirby's argument that "Many people use weapons for fighting against griefers", because I don't think that's an effective means of dealing with griefers. However, I don't think that weakens WarKirby's main point at all: orbiting is not, in itself, an evil act. People have orbit-fights for fun! There's nothing wrong with that, and breaking that isn't cool. It's not evil to sell weapons, it's evil to use them for evil purposes.

1) The client not recovering from pushes to insane altitudes (negative or sky high), which is what squirrel pointed out

2) Physics objects being used to impart disruptive amounts of force on restrict-push parcels, which is a separate issue

Discussion of #2, or any proposal for addressing it, should be a new JIRA.

Second, if you're entire Real Life is supported by money made from Second Life, then perhaps it's time you get a job or get some kind of government aid. Second Life is a game, not a profession. I myself do not work and am currently trying to get disability, but I do not make any money off Second Life. So to accuse anyone of trying to "CRIPPLE YOUR SL INDUSTRY" when suggesting a fix to an EXPLOIT is just ludicrous.

Third, why would anyone want to orbit another person's avatar to the height that the avatar parameters fail except to grief them. If you're using weapons to fight griefers other than the tools the game allows (i.e. Estate Ban Tools) than you are a griefer of griefers and no better than they are. You have stooped to their level. So again, these suggestions to fix such an exploit is better than all the nagging I've heard in the past of accusations that Linden Lab doesn't know what they are doing.

Fourth, don't nag. If you can't make suggestions that will help resolve issues or build or amend previous suggestions so that Linden Lab can make Second Life better for the players, than all you are doing is griefing Linden Lab. Please help give solutions and not make Linden Lab's jobs harder.

Your second argument is pointless trolling. Many people make a living here. It IS a job. to make a worthwhile income from SL takes a lot of time and effort. But at the end of the day, A person can become fully self sufficient and self employed. That's something a lot of people dream of. How can you possibly justify getting goveernment aid. Living off benefits. Leeching public money, as any sort of alternative to being an independant entrepreneur.

Third. Visit the linden sandboxes sometime. They're completely unregulated, and full to the brim with all sorts of people. Good and bad. If you're building in a sandbox, and you get attacked. There's one reason to use a weapon. To defend yourself. I have also used weapons to defend a sim. By orbiting someone who was in the process of mass rezzing physical objects.

Your last point is again, trolling. This is a community project. Not your property. It is not your place to tell people where or how to post comments. I have posted a a reasonable argument against a proposal, which is a necessary thing. It's called community moderation. The principle this whole Jira is based around. No solutions are needed. A non phys shield and a good dose of common sense will make you invincible to everything. There is no need for things like this.

Well then. How about "fixing" the warppos hack too? Or how about the neat little bug in llTakeControls that allows you to grab all user input? Or how about reverting every megaprim to normal ?

Those are all bugs, and would break a hell of a lot of things if they were "fixed"
-----------------------------------------------
"make weapons that don't need to abuse bugs"

Oh, why didn't I think of that. I'll just press my magic button and conjure up a new technique.
------------------------------------------------------------

"if you close the loophole everyone has to buy new weapons...."

Why yes, you're quite right.

"Sorry folks. Those fancy weapons you spent all that money on. They're broken now."

I imagine that will go down real well with my customers.

I am strongly against the idea of limiting user's abilities. Airplanes (or space shuttles) should be able to fly however high the creator wants them go (especially making them able to fly above the maximum height of skyboxes so they don't run into them all the time). Skydivers that want to instantly "orbit" themselves to a few thousand meters and then freefall back down should be allowed to, as well. Heck, if two friends want to play and "orbit" each other to millions of miles in the air in a game of tag, why can't they? Your world, your imagination, right?

I love the bug report, I hate the proposed solution.

>> Well then. How about "fixing" the warppos hack too? Or how about the neat little bug in llTakeControls that allows you to grab all user input? Or how about reverting every megaprim to normal ?

>> Those are all bugs, and would break a hell of a lot of things if they were "fixed"

That may be the case, but if that's the way it is, so be it. It's just not reasonable to keep bugginess hanging around and expect nothing bad to come of it. Of course you could make the bug go away by incorporating it into the design of the system, but I really don't see that happening for a bug that requires relogging afterwards. In any case, the buggy state is a bad state - it's inherently unpredictable and in this case really not nice.

>> "make weapons that don't need to abuse bugs"

>> Oh, why didn't I think of that. I'll just press my magic button and conjure up a new technique.

Not sure what you mean by this. Are you saying that you don't want to innovate? Or are you saying that it's impossible to make weapons that don't involve bug abuse?

>> "if you close the loophole everyone has to buy new weapons...."

>> Why yes, you're quite right.

>> "Sorry folks. Those fancy weapons you spent all that money on. They're broken now."

>> I imagine that will go down real well with my customers.

I'm sure this isn't a problem. After all, you explained to your customers that the badness this stuff causes was really an abuse of a bug and not really intended system behavior right?

First, the two separate techniques being discussed here (Pushes and physical objects imparting forces to other physical objects, including avatars) have been used for a considerable time by many developers. Breaking existing content isn't acceptable, especially not when it's to further someone's own agenda. Bringing out the "griefers" argument ought to be the Godwin's Law of SL.

If there are more than a microscopic minority of people out there using anything other than the freebie collection of weapons any newbie knows where to find to "grief" others, I'll eat my hat. The people I see using these things against each other tend to be people who know one another and do so with consent (or as a well-intentioned practical joke) or frequently, against people who really are attempting to cause misery.

Getting knocked to some insane Z-axis coordinate isn't griefing. If you want a worthy cause for fixing, go after the physics exploit that allows someone to drop off an untraceable physical object in a sim and keep it in a crash loop for hours.

I do agree that the broken attachments and invisible avatar requiring relog should be addressed.

after all it makes no difference if someone gets pushed up to 4096m or to MAX_INT. he's still in space.
MAX_INT just looks more impressive. so why change that? it's just cosmetic.

i hope that you find a middle way between fixing the bug and keeping the physics engine features how they are.
and i think my customers would agree

The concern about this issue is comprehensible. However, I'm against fixing it, not just because "I make money off this bug", but rather because of the fact that the amount of people that use these weapons for self-defense or event security purposes is much, much higher than the amount of people that use it to harm others out of the blue.

I'm sure a lot of you will accuse me of being against fixing this just because I make money off Ownage Reloaded, but it's not that. It's the fact that these weapons have been used for nearly a year, for reasonable purposes. It's the concept of a greater right for a tiny wrong. I guess it works out like guns in real life: most gun users are security agents or civilians who use them for security purposes, BUT there are a few who use it to commit crimes. The fact that you own a weapon doesn't mean you'll go off shooting people around the place.

The technical factors to take into account for fixing this are way over my head, but I believe the only part that needs fixing is the one where scripts get math errors when somebody gets "owned". Maybe that has to do with the maximum value of an integer in LSL being exceeded by the Z-coordinate of an avatar's altitude. Because it's not really MAX_INT. MAX_INT is just where the SL client stops counting altitude. The other day we did some tests with some friends, using a little script in an attachment that would report llGetPos() every five seconds. Our SL client kept saying MAX_INT in the Z-coordinate field, but our script said a MUCH, MUCH higher number. If I remember correctly, it was over 20 digits. It was ridiculous.

The bottom line is that it's a fact, based on my experience that at least most of MY customers use it for security purposes, rather than kidding around as grievers. So, this should stay "unfixed", unless LL comes up with a better way for residents to defend themselves against those idiots running around with annoying Jedi crap or other annoying stuff, messing with residents' privacy, work, events, houses, etc.

my personal thoughts on the matter are these:
1. The SL code should be changed internally to stop the breakage of scripts during high orbits. Definitely. Products, and hence real money can be turned into trash if the object is no-mod for the owner, and that just shouldn't be.

2. I'm indifferent about the avatar 'disappearance' issue. A relogin fixes it. You're just invisible to yourself, not to others. Aou can still interact normally, so really, this is a minor thing.

As a tiny sidenote, for those who don't know ( I doubt anybody here doesn't), to prevent being orbitted just sit on a plywood cube and stick your tongue out at the griefers.
That is also the point at which they will show you there are MUCH more annoying things than an orbit. Really. Much more. And you will wish for the orbits to be back.

So, fix the breakage definitely, perhaps fix the visibility problem...but my main points I want to make is:

1. Remove the griefers ability to fill a whole sim with screaming, following trash and have it stay. simple solution: Ket parcel owners set it so if the object owner is gone x minutes, remove the stuff. no, this is not the same as autoreturn, as with this solution rezzed things would stay while the owner is there, even if they disappear exactly at the point the owner leaves the sim. This allows people to rez objects for fun, and for instant cleanup if they leave. Griefers usually don't stay at ground zero, and if they do, snapshot, report.

2. Fix the sim's sensitivity to physics. Currently it is so easy to make sims crash, the Lindens even put up an additional note at the 'crash me' sim (check the map for that one), that it's not supposed to be physics crashed. Once you've seen your favourize sim killed for a whole day over and over again because of a griefer, or flooded with hundreds of screaming, sight-blocking, roaming followers, you'll see that orbits..really..aren't the problem griefers cause.

All the cents I had.

Griefers these days do not use "Blitz", no you would think they do but they don't. The fact is griefers use griefer toys, such as sound spammers, followers, physical spam, non physical spam, script spam and sometimes combinations of those.
The residents will always find a way to annoy other people. to the point that if you'd want to solve it you'd have to limit the game to a point where it is no longer playable. Disallowing "Blitz" will not solve a thing, in fact it will break more than it fixes.
These days there are simple solutions to prevent being blitzed. As for every weapon in SL, counter weapons will be developed.
SL is much like real life, people try to get some weapons banned, only to realise that the criminals will find nastier and smarter ways to gain their way of killing.
If the lindens decide to ban "Blitz" I DEMAND, we get better support(that actually comes to a solution, instead of a temporary fix) to stop the griefers currently harassing the places without admin support. the public sandboxes for example.

Should blitz make you invisible, no it should not fix that.
Should blitz have a chance to break your attachments, this was probably the reason for it to get a request of banning in the first place, no it should not it should just be fixed

Think of what will happen when blitz is banned, just like orbit. A new alternative will be created which will probably even worse than blitz or orbit, as it involves tapping into more dangerous ways of getting rid of people. like crashing them, or screwing them in another way.

The right solution is to give the public sandboxes, and the areas that need it an admin.

'Not sure what you mean by this. Are you saying that you don't want to innovate? Or are you saying that it's impossible to make weapons that don't involve bug abuse? '

The last line here is indeed a fact, effective weapons involve bug abuse half the time and many may say they are 'illegal' to SL. BECAUSE LSL IS A CANNED SCRIPTING LANGUAGE, you are severely limited to 'innovation' as you know it in terms of creating weapons. I doubt you even know how to make a weapon if you have a firm belief that we simply can invent some new way of battling griefers. Look at every weapon on the market, and every weapon that isnt, they all use the same or drastically similar methods of attack, sure they may differ in the eye candy they use, but they are ALL THE SAME. That kind of tells you something doesn't it? Think i'm talking bullcrap? I have scripted weapons since I joined in 2004. Think i'm a griefer for being against the fixing of this bug? Hahahah...you make me laugh. I completely agree with azure said, fix the attachment problem, leave the physics engine alone. Havok 1 is already crappy enough without you people indirectly forcing the lindens to make it even MORE limited than it already is. If this JIRA does indeed get passed regardless of breaking a lot of content, then I hope you enjoy your second life full of griefers who cant easily be stopped by push lines and weak physics. That's my two cents, anyone who disagrees with anything I say, research research research, before you come at me with your points of disagreement. Anyone who does not abide by common sense is a fool. That is all.

Many many ligitamate products utilize this effect, its not just a weapon. DON'T BREAK CONTENT.

All this about not being able to teleport and such when hit with a weapon that uses this effect is rare, and an unfortunat side effect when it occours. Please don't go changing something that will have as big a negative affect as this. Billions of $L and Peoples work are at stake.

Gaheris Merlin --Anti-Griefer

If you're using weapons to fight griefers other than the tools the game allows (i.e. Estate Ban Tools) than you are a griefer of griefers and no better than they are. You have stooped to their level.

(Thats a load of crap)

What concerns me most is the breaking of attachment attacks, i dabble with weapons at times and didnt look twice at that bug because its kind of scary and intimidating. Taking llPushObject out of SL isnt a good move in my view, seeing that nearly every person uses the function in atleast 1 of there inventory objects is just crazy to say the least.
I'd also like to point out what Blabla2 Eponym said about "Griefers" using Blitz. He is right, some people see SL as a game and others see it in a more serious perspective and commit to the crazy world that is Secondlife, i.e grab a gun and shoot someone. Killing weapons in SL will encourage people to use other functions to be evil i believe, alot of new weapons have evolved in SL since i joined a year ago and some without llPushobject, i quote Weapons in SL are everyday you cant take them out, because LSL hasnt got that choice. Weapons like the world evolve and always will in my view, its a pointless debate.

Lindens!! If you want to LEVEL the playing field then introduce new physics library or MONO..... PLEASE do not tweak the current version of Havok to address a very narrow band of weapons that make YOU a lot of money....

The privately held sims CAN, and DO ban troublemakers, and do so at the drop of a hat, I might add....

I spend a lot of time outside of the public sandboxes... and I can tell you the blitz issue is almost not existent... Why? Because a few complaints of weapon abuse outside the sandboxes results in prompt bans...

Blitz as it is now is a very useful tool to get rid of attackers that will not listen to NO.... especially in the Public Sandboxes that the Linden crews have all but abandon...

Just like the disaster of "patching" WarpPos() LL stands to harm a lot more users than they "protect"

Griefers don't use random orbits and blitzers anymore.... they are ineffective and tend to bring the anti-griefer crowd down on their necks HARD.....

Griefers prefer to crash sims.... or fill them with noisy trash. A disrespectful newbie who likes to test their new toys in places that they should not, IMO deserves to discover the reality: there are and will always be bigger and badder weapons in SL that will put them off the map long enough to get their attention... If you Lindens are keeping your word about the new Abuse Reporting system then you already know who the greifers using blitz are..... Please take them out of the pool....

Lindens... it is a bad move to start poking at Havok to fix a few uncomfortable realities.... Replace the whole engine if you want to make a change..... level the playing field.... Weapons engineers will find the holes the new one, in time, and a new round of innovation will begin....

It's too late to play The Little Dutch Boy on the physics engine without alienating many users who have nothing to do with griefing or anti-griefing.....

_HS

-Crim

I'd like to state firstly that this 'bug' isn't a concern on SecondLife, it is a concern of Havok inc. - Thus meaning that Linden Labs isn't a primary target for the physic's 'bug' or 'misbehavior'.

With that said, i'd also like to coment on a few other things being suggested or stated in these coments on this bug or issue. First being that giving the agents an option to toggle push on or off, is like giving people invunerability in Combat enabled parcels. There is an alternitive to this, being push disabled parcels. If you own land you can simply toggle push on, or off. HOWEVER this is not a topic about llPushObject, this is a topic about the Havok physics exploit.

Alot of exploits in SecondLife are made for a reason, LindenLabs gives every person the tools to create their own world, and its on their own from there. Take 'warpPos' for example - Linden Labs didn't give everyone the ability to make objects jump long distances with a single function, someone went out of their way to do so, and its being used by lots of people today.

But we arent talking about warpPos either. The matter of this issue is in the hands of 'Greifing'.
Where there is opportunity for inovative ideas, and creations, there will ALWAYS be exploits, no matter if they fix the bug or not. If they fix it, there could be an opening for ANOTHER, maybe WORSE bug to come about. Say they patch the 'blitzing' bug, but then there is a physics exploit to unsit an avatar, that would be even more dangerous than Physic Orbits.

No greifings can simply be patched, however not all agents are shooting MaxINT throwing prims at people, there are people who use them in appropriate areas (such as combat simulators) - so the simple, most effective, most fair, way to deal with a greifer, is the simple Help > Report Abuse.

-Jokeiroo

But if nobody can attack in the first place, it's all good. I don't care about wasted money, we all knew they were unreliable products as we bought them nontheless.

I'm resolving this as fixed.

Just stop crying, and start looking for new physics bugs in Havok4... I'm sure there will be plenty.

Havok4 prevented it from working as a direct attack, but the new version takes advantage of the ability to set a prim so that left-clicking on it causes the av to sit on it. Thus these new orbiters use an invisible prim with the left-click sit option, and once the avatar sits, it does something (which I still have not determined) that causes them to be orbited in a manner nearly identical to the old method.

Well, at least now it's not automatic orbitting. We should have made this bug "critical" back then, I'm making this "major".

Jahar, feel free to update the description if you find more.

The problem is maybe that you can set an object to sit the avatar on the object instead of touch the object.

There are also griefing objects that uses a normal touch, to apply "trash" animations to the touching avatar, that deform the avatar to very ugly shapes. Though there are "antideforming" animations and scripts, lot of unexperienced SL players don't know of them and are forced to relog to repair their shape. Force somebody to relog is in the result the same as to crash his client.

So I think we have here a complicated issue. You can not forbid moving avatars by llSetLinkPrimiitveParams, cause there are several useful applications. You cannot forbid to apply animations to avatars by touching an object, cause there are several useful applications. You cannot forbid to configure an object to apply "sit" instead of "touch" by touching it, it would break to much content.

Since this methods are no active, automatically working weapons, but one have to "click" them, maybe it's better to leave things like they are. The unexperienced people clicking 2-3 times on griefing objects like this and learn to be more careful.

So I just learned to be more careful. In a Linden sandbox, i would NEVER click on anything just for fun, I normally only right click objects to check their inventory.

Maybe these "passive weapons" are misfiled here. You should make a jira against "changing touch to sit for an object", or "moving an avatar part of a linkset" or similar ...

For starters, these objects do not appear to be using warppos/llSetPrimitiveParams. These objects move the avatar to these heights almost instantly, whereas warppos and similar methods are known for being rather jerky...even when using multiple scripts for "smooth" flight, they still would take a certain amount of time to reach those altitudes.

Secondly, the avatar is not intentionally clicking on ANYTHING. These weapons work by rezzing a large invisible prim that moves behind the avatar and follows them, such that in the normal camera position, it fills most of your screen. Thus clicking on anything, such as yourself of a nearby teleporter (some of which must be clicked to bring up a menu) will result in unintentionally clicking on this invisible object, resulting in the orbit. It's not really an issue of needing to "be more careful."

Also, I did make a JIRA asking Linden Labs to alter the behavior of the left-click sit ability, but it was decided that doing so could break a lot of legitimate content. LL did add a new feature to the 1.20 client where the left-click sit will not work if you are already sitting on an object, but that doesn't help if you are walking around. That is a separate issue to this one, however. That involves the methods used to get someone to sit on an object for a number of reasons, this ticket is discussing specifically one of the things that occurs, being orbited to insane altitudes.

I think that your analysis is more complicated than it needs to be. The issue is actually quite simple: Despite Linden Labs explicit actions taken in the deployment of Havok4 to prevent these sorts of attacks, it is still possible to "orbit" an avatar to maximum altitudes, causing all of the same problems that it did before. It creates a serious liability in that scripted attachments can be broken, it can cause problems if it forces the client to crash while someone is working on unsaved notes or scripts (which is one difference between a forced relog and a crash), and even when it doesn't crash the client, it DOES pretty much force a relog because the camera is broken, offset so far from the av that not only does the av seem invisible, but moving around causes wierd camera behavior that makes it very difficult to figure out how to move correctly and interact with the environment.

There are now specific avatar speed limits in place, as well as vehicle speed limits that should in theory prevent this from being possible. My guess is that since nothing can actually move to those altitudes in that time at any possible velocity, it is likely that these devices are using something like llSetLinkPrimitiveParams to actually place the avatar at that position as if it were simply moving a prim in a linked set. The problem, of course, is that the distances here are far greater than those allowed by llSetLinkPrimitiveParams as well. No matter what method is being used, it's clearly outside of the normally expected behavior of LSL functions, and thus there is a bug somewhere. If it is based on a bug, and not just an exploit of normal expected behavior (since there doesn't seem to be any normal expected behavior capable of doing this), then hopefully it will be possible to fix this without impacting legitimate content.

It turns out that it is possible to simply use llSetLinkPrimitiveParams() to place the avatar sitting on the object up above 2 billion meters. I had assumed that this was not possible, since llSetLinkPrimitiveParams(PRIM_POSITION,vector pos) should have been limited by the maximum link distance between the objects. It appears, however, that this limit only applies when the linked object is an object, not an avatar.

However, this should be rather simple to fix. Since it is already impossible to move an object in a linked set to 2 billion meters up in one call (there is no possible linked set with that link distance, and it is not possible to move the entire object more than 10m in a single call of the llSetPrimitiveParams() function), it should not cause any problems to simply clamp the maximum distance allowed by llSetLinkPrimitiveParams() to a reasonable distance. The maximum height that you could place an object is 4096m, so even presuming that you needed to use this function to teleport a person from the very bottom of one side of a sim to the top of a high-altittude build at the other side of a sim, the maximum distance there would be 4104. We could call it an even 5,000, maybe even round it up to 10,000 just to add some extra room, and it should still accomodate any and all legitimate projects.

I almost placed the script here for reproducibility, but thought better of it. That being said, it should be pretty easy to work it out from what I've said here, but if there are any questions, please IM me in-world and I can provide a copy of the script I used to test this.

No, I understood you completly.

As assumed by me the method could be llSetLinkPrimitiveParams, you tested that is true. I use this function as 4k teleporter, too, and agree to your proposal to cut the distance at 10k meters, maybe somebody likes to visit that height for sky-diving ...

For any longer distances I cannot imagine any normal usage besides griefing/orbitting.

when a bug is used often enough by the users,
it becomes a feature.

Leaving aside the fact that this bug isn't used all that often (which is a shame considering its use for long-distance teleporters), there really is no use for allowing llSetLinkPrimitiveParams(LINK_NUMBER,[PRIM_POSITION,vector pos]); to extend up to 2 billion meters in the z axis. There is no need for a 2 billion meter teleporter. There isn't even any point to moving an av up to that altitude, since it causes the av to turn invisible to the user and according to some reports may break some scripted attachments. The only way to make one's avatar visible again is to relog. I don't know any programmers, anywhere, who consider any function that requires an otherwise unnecessary relog to be a "feature.".....ok, aside from the guys who made Windows ME and Vista (another bad joke).

But in all seriousness, there is no actual need to move an avatar to 2 billion meters. Given that this method does not involve physics, but simply involves inputting a vector into llSetLinkPrimitiveParams(), it should not be too difficult to either limit the function call to a total vector magnitude of 4,113m (the maximum distance that one would need to move within a 256x256x4096 sim (my earlier math was a bit off)), or else clamp the Z-axis to a maximum of 4096m. Hell, we could even decide to double the Z-axis clamp and round it to a nice even 10km just to allow people to make some cool skydiving sets, and it would still be perfectly fine.

The only thing that this "feature" accomplishes is forcing a relog. The only people who consider that a "feature" are griefers.

QED.

Oh, there is a JIRA ticket up specifically requesting that there be a clamp on llSetLinkPrimitiveParams(LINK_NUMBER,[PRIM_POSITION,vector pos]); it is SVC-2543

I'll go test it in-world in a few minutes.

• EDIT:

Ah crap, I see that the blog is announcing that 1.23.2 is borked as well. Maybe they should just call the next attempt 1.24 for good luck.

Second Life Server 1.23.4.93100.

kool =)

The client still reads one's previous position, but you cannot move and there is no "Stand Up" button. My alt had me mapped and I could see that I was moving around the outside of the sim, despite the fact that my client was not registering this. I could still teleport back to my previous location using the map, fortunately. I scripted an object to attach to my HUD to tell me my position when pressed and had my alt target me again. These were the positions that the device reported:

[20:37] Object: <229.96507, 36.94101, 40.20931>
[20:37] Object: <-177.30472, -191.26422, 937.18011>
[20:38] Object: <-167.10719, 485.43021, 937.17969>
[20:38] Object: <-165.79642, 199.97865, 937.17981>
[20:38] Object: <-165.44095, 35.57613, 937.17969>
[20:38] Object: <-165.21877, -70.64777, 937.17975>
[20:38] Object: <-164.99663, -141.80170, 937.17969>
[20:38] Object: <-164.50784, -225.97870, 937.17957>
[20:38] Object: <-163.90797, -229.55023, 937.17950>
[20:38] Object: <-156.26541, 97.40144, 937.17920>
[20:38] Object: <-153.59938, 355.46594, 937.17932>
[20:38] Object: <-151.26660, -229.11295, 937.17896>
[20:39] Object: <-136.53687, 434.48965, 937.17865>
[20:39] Object: <-136.20367, 481.51181, 937.17871>
[20:39] Object: <-135.53716, 485.49588, 937.17889>

Note that the values kept changing. The only method for moving an alt sitting on an object is llSetLinkPrimitiveParams, so I would assume that it is still possible to use this function to create this behavior. This is clearly a bug as it is not expected that an av should be capable of existing at negative coordinates, and as the client still reports one's former coordinates. As one cannot move or interact with the world when this happens, it causes severe disruption to one's SecondLife experience, and only the fact that one can teleport back to the original location prevents it from being a potential Denial of Service attack. Were it not for that, this would have been reported to Security@LIndenLab.com (which would not be the first time that a device made by this creator had been reported for security violations).

The goto and return +/- offsets to the same starting coordinates are different but you soon get the hang if it after a bit of practice.

The other problem was that in the instance I mentioned in the above post, my avatar appeared, in my client, to be standing where he was, and the coordinates at the top of the client were normal. However, all objects and avatars around me vanished, and I was no longer visible to the other avatars in the sim. My alt, who was mapping me, showed that I was off-sim and moving around.

Clearly buggy behavior, and given that this is the only method of moving an avatar sitting on an object in that manner, it probably still involves llSetLinkPrimitiveParams() somehow.

I do declare, obessions with "griefing" create the most amazing tunnel vision about use cases...

My point is that the behavior is not what would be expected.

Besides, this is about more than just griefing, this is about fixing the bugs in the program that these griefing devices are exploiting. Sending an avatar to an altitude that causes the viewer to become corrupt and act in unexpected manners such as making the av invisible, or move an avatar into the intersim void and potentially disconnecting them from SL would clearly be buggy behavior that any programmer would want to remove from their system.

If you were a programmer designing the next Grand Theft Auto game, for example, and beta-testers reported that there were methods that would result in the character being shot into the sky and then turned invisible until the user restarted, or which moved the character offworld, you would probably respond by trying to reproduce the bug and then you would try to fix it.

I did not say that SL is like GTA. I said that if you were a programmer who was coding/debugging a game...and I used a popular game as an example....and either you or your beta-testers found behavior that was buggy, unexpected, and caused problems for users, especially if it included requiring an unwanted reboot, you would try to FIX THE BEHAVIOR SOMEHOW.

And I don't think that I have been arbitrary here, I have been quite clear in listing behavior that I believe may be buggy, and listing reasons why it seems to be unexpected. And I don't think it's only MY view, since several other users have been saying the same thing AND Linden Labs seems to agree.

As for explicit specs supporting my views...you seem unfamiliar with my JIRA comments, I almost always include citations to relevent information.

For instance, the move to Havok4 included specific changes made by Linden Labs that were explicitly stated as being for the purpose of clamping push behavior to prevent avatars from being pushed to high altitudes. So clearly the game shouldn't allow it to happen, and yet this llSetLinkPrimitiveParams() allows this. For reference on this, see:

http://wiki.secondlife.com/wiki/LlPushObject/Havok4Implementation

Additionally, there are limits on llSitTarget() in terms of distance, and there are already limits on llSetLinkPrimitiveParams() for non-agent-prims. It was only for avatars that there was no limit on llSetLinkPrimitiveParams(). In general, not placing a limit on a script function is going to lead to problems down the road. In this situation, it led to a problem in which avatars could be moved to an insanely high altitude almost instantaneously, causing the viewer to stop being able to render the user's avatar until the user relogs.

I really don't understand how you can not consider that to be buggy behavior. Are you really saying that this is "how it should work" to use your phrase?

As for the corner/edge case, I think that we can all agree that any situation in which the client is not displaying the same coordinates as the simulator and other users are seeing for that avatar would be a bug. I think that we would all further consider that an situation in which everything in the simulator disappears for the avatar while the avatar appears to stand still (and yet other users see the avatar moving around) to be buggy behavior as well.

Is there some disagreement here? Are there people who believe that this behavior is "how it should work" in SecondLife? And if so, could those individuals please present reasons for this instead of simply telling me to stay off the grid.

Look, with the unbelievably huge use case set of SL, almost any behavior may cause problems for *some*body.

The ultimate "surprise" is when code that had one effect yesterday has a different effect today because somebody decided to logroll and call behavior he didn't like "a bug". The "old programmer's joke" isn't a joke. Absent a firm spec on behavior, what constitutes a bug is opinion, and a judgement call. "Jahar didn't like how this works so we broke your product, too bad". By the way, it's also not true that "it is not possible to move an entire object more than 10m in a single call of the llSetPrimitiveParams()"; I have a product that does this. Or are you going to logroll for breaking that too?

If the viewer can't recover from edge cases like high altitudes without relogging, the viewer is broken. Just like it's broken when you TP with "too many" attached prims and can't recover without relogging. "I had to restart my viewer" is a bug. But it's not a server bug. If you want to make the viewer more resistant to DoS attacks that force a relog, you should be filing VWR bugs.

Why does this have to be about me? Please point to a single change in the SecondLife libraries or source code that I made. I wasn't even the one who submitted this ticket, nor was I the one who submitted the related ticket asking for a limit on llSetLinkPrimitiveParams().

The changes were made by Linden Labs. The same Linden Labs whose Terms of Service you signed. It has nothing to do with me and I can guarantee you that I have absolutely no connections to Linden Labs and I have absolutely no control over their actions or decisions.

I am not really sure what you are asking. Is there some reason why an avatar should be moved more than 4096m? Nothing else can exist up there. I suppose I could see a skydiving device wanting to push an av higher, but then sure, the limit could be adjusted upwards to a higher but still reasonable limit. I would see no problem with 10,000m, for example. The point is that there should be a limit, and there really isn't any point to being able to move an avatar beyond a certain point.

It sucks that the changes wound up breaking a few teleporters. I have yet to hear of other content that has been broken, although I won't deny that possibility. That was a problem with the code, and likely got overlooked with all the other crap surrounding the 1.23 release. It'll get fixed at some point in the future.

And just so you know, physics changes in 1.22 caused problems for my products that will not see a fix until server version 1.25 rolls out, that would be the version that rolls out AFTER this upcoming Mono rollout. So yes, I understand that it sucks when code gets messed up and it damages items.

As for the issue of viewer vs. server, the behavior itself resulted from actions that occurred serverside. The fact that the issue showed up on multiple client versions on all systems implies that a clientside fix might have been difficult. On the other hand, it was much more obvious that fixing the exploit that resulted in the problem would be the simpler and thus more feasible solution. Do you have any suggestions for a viewer-side fix?

I really do not understand the outrage over having a few teleporters break. It's not a huge issue and it will probably be fixed soon. The best way to accomplish this would be to file a JIRA ticket detailing the problems that the teleporters are encountering, along with a description of how they used to work correctly, and an explanation of how they are working now, a reproduction, and maybe suggestions for how to fix it (such as making all xyz coordinates limited to 4096m).

Why should we allow llSetLinkPrimitiveParams() to move an avatar to an unlimited distance, especially since doing so can cause the av to become invisible until a relog?

All methods of moving someone high enough to cause this effect have been removed from the server code. This bug should be re-filed as a viewer bug, but good luck building a repro for it now.