This will effect a skybox put at max height to reduce texture lag of sourounding objects. It breaks my Stargate style teleporter. And it breaks a shield.

None of these things are using hacks or exploits. This is a Bug. It was not a FIX.

I have filed an abuse report for your harassment in the JIRA and will encorage other people to do the same if you continue to use the jira to harass people.

Darling

I know that one can sit offset on a prim such that the prim is inside the 256x256 region, but the avatar is horizontally offset so as to be outside of the sim. Does this behavior now cause the object to be returned as well? Again, if this does, then the behavior is at least consistent, but if it does not, then clearly this seems to be an aberration.

That being said, it is also possible that there was a good reason for this changed behavior.

This has been happening since i first started playing sl. If an object goes up near 4000m it gets returned. (I have loads of experience in this.)

Since the lindens raised the build hight on the release client they more than likely raised the sim ceiling with it.
The reports seem to take place around 4096 therefore this object should be set to teleport a bit below that to prevent it from leaving the sim ceiling. End of story.

Edit: I used a test rocket to launch me up into the sky. It went past 4096 (4361) before it returned.

When an AV sits on a linkset, it becomes the root prim. According to the logic of SL, if the root of any set is above the build height, return it.
Makes sense to me.

On a side note, Darling, upgrade your warpPos function. Your using a very old version that was improved eon's ago. You'll notice a evident performance gain.

An efficient, and less laggy version is posted below.

warpPos( vector destpos)
{
integer jumps = (integer)(llVecDist(destpos, llGetPos()) / 10.0) + 1;
list rules = [ PRIM_POSITION, destpos ]; //The start for the rules list
integer count = 1;
while ( ( count = count << 1 ) < jumps)
rules = (rules=[]) + rules + rules;
llSetPrimitiveParams( rules + llList2List( rules, (count - jumps) << 1, count) );
if ( llVecDist( llGetPos(), destpos ) > .001 )
while ( --jumps )
llSetPos( destpos );
}

We truly need a Linden comment on this one, to see if there was a reason for 'fixing' it.

The return of objects has always been based on the root prims, not the linked set centure. This behaviour can not be reproduced when the avatar goes offworld on the x or y axis. The x and y axis are still behaving normally.
An example of this can be seen in parcel encrochment where trees hang over your land, you can't return them because the root prim is not on your land. In fact the behaviour is consistant right through SL, except for the recent change to avatars sitting above 4096, which is now inconsistant behaviour.

@ Jahar Aabye

Objects are not returned if a child prim is offworld in any direction.
To test this, make two small boxes. Link them. Move it until the child prim is off world but the root prim is not.

An Avatar sitting offworld in the X or Y direction does not result in the object being returned. Try this test script in a region without another region to the west. (remember to have your draw distance set for at least 300)

default
{
state_entry()

}

@ Knife Carver

You have the right to express your opinion in the JIRA. However you do not have the right to abuse the JIRA system by closing issues to silence the options you do not like.

The behaviour is inconsistant and it has changed without being announced as a BUG-FIX and is NOT listed in the JIRA as something that needs to be fixed. It is most likly an unintended side effect of some other change.

@ Jana Kamachi

An Avatar has always been added to the link set as the last prim in the set.
Place this script into a single prim and sit on it to see what I mean.

default
{
state_entry()
{
}

changed(integer what)
{
if (what & CHANGED_LINK)

}
}

@ All

I am not aware of any undesirable side effects with the original behaviour under havok1 or havok4. It does not evade sensors, crash regions, or make your hair stick to your bum!

My Stargate teleporters made use of this and the product is non-upgradable so there is no way to FIX it for people effected without having to teleport all over SL and give people new ones after they report them broken. (The teleporter uses a +z sit target to make the avatar immediatly vanish while the prim makes a particle poof directed at them. The result looks like an azgard stargate beam-up effect.)

Going by when I started to get reports of problems it would appear the bug was introduced in the last rolling restart. I know it was still working in havok4 on the 18th of April on the main grid based on my code revision notes. It appears to have been working up until a very recent server update.

This was not a hack or an exploit, so it is resonable to think it was broken by mistake. (thus my jira issue)

Darling.

It's the fix that makes phased chairs not work

I don' t think that is correct, as phased chairs have been broken(fixed) a lot longer than havok4 has been on the main grid, and months longer than the recent rolling restart that caused this issue.

Also under havok4 sensors can see the avatar's true location even if they only scan the prim your sitting on. So you can be setting 300m away from the prim and be detected if someone's sensor covers the location of the prim. <-- that is the side effect of the change they made to "fix" phased chairs.

This issue is clearly not related to phased chairs. It is an unrelated issue.

Darling.

on your off-topic unrelated note:

Did you notice my script used a destination of <128,128,4095> ?

I noticed your script will not move an inch if your attempting a jump like that!

Darling.

Actually, that was alreayd the case in Havok 1. It was the way to detect phased chairs, and the reason why simscans still showed people correctly.

But the fix for that was to detect the avatar if they are within sensor range even if the prim was not.

your right that when phased chairs worked the only way to find the true location was to scan the prim. When the lindens patched that under havok1 the avatar was not visible at the prim location anymore, only at their true location. When havok4 came out the behaviour changed yet again and the avatar is now visible at both locations. So technically havok4 has a bug as a sensor is returning a result for something outside of the radius specified in it's params. <--- none of this has anything to do with this JIRA issue, its just an interesting topic.

@Knife Carver

This JIRA is about objects being returned to the lost and found folder with the message that they went offworld when in fact the object did not move at all, and was at a perfectly valid location.

The talk about phased chairs is not related to this JIRA issue. The fact the fault is caused by a z sittarget is also NOT related to phased chairs. In fact no phased chair I have ever seen has used a +z sit target because that will prevent it from going within 100m of the ground. Every phased chair I have seen uses a -z sit target, and they are not effected by this bug.

Darling.

I didnt win anything, and I was not trying to win anything.

All I have done is notice a bug that turned up a couple of weeks ago and reported it. Just in case you are confused, that is the purpose of the JIRA.

If you would like to argue with me for the purpose of winning points, you can find me on plenty of forums. This is not the place for trying to win points.

Darling

I have also noticed that objects are being returned if their binding box goes offworld on the Z axis even though the centure of the root prim is still below 4096. This was not previously the case and would appear to be related to the bug.

I have a nice hollow 256x256x4096 sized prim I use on my private island for creating a horizon which is also instantly returned the moment I rez it.

Darling

What is of interest to everyone is any object that was built using a prim large enough to go offwork on the Z access will go offword when you try to rez it again later. This includes megaprims, and normal prims if any part of them is above 4096.

Objects did NOT go offworld when a non-root prim went over the max Z limit previously and should not do so now. It is a new behaviour that messes with existing content.

Darling

http://www.quantumproducts.org/forum/viewtopic.php?t=649

This entire jira entry is to "fix" one of darling brody's weapon hacks.

She has an entire forum pointing to the jira "fixes" she wants her fans to vote for.

I vote that we ban darling brody from the jira as the votes only concern her weapon, and thus represent a tiny minority of second life, i.e. the griefers.

There was one behaviour before a server roll-out, and another after. Both behaviours are okay, and one is not better than the other. But, as the rule to not break existing content, there is a reason to change it back to old behaviour, therefore scripters need some reliability in the SL environment that the behaviour they trust on doesn't change randomly from one day to the next.

Whispering and Knife, please refrain from misusing Jira for your personal antipathy against Darling. There is already a Linden assigned to this topic, so we should respect that we should feed this Jira with facts, not policies. Thank you.

Please stop now posting in this thread off-topics about Darling Brody, this isn't actually the right place. Make another Jira thread (I would be curious about how Linden would handle this) or abuse report her.

Thank you very much. Back to topic.

I will continue to monitor the jira activities of anyone I see fit thank you very much. Specially those who seek to use the jira to further their own ends at the expense of the other 98% of SL.

There are some loverly artificial horizons being used on private island regions. With this NEW bug it is no longer possible to rez the megaprim. Despite the lindens openly blogging that they are going to retain the megaprims because they like the horizon idea.

The rezzing of a megaprim on a private island will also result in the prim being returned if the binding box goes over 4096. I reported that to another forum, and to this jira too. Yet the product griefers are hell bent on breaking all effected content for private island owners just to spite me. (how lame)

SkySit is old technology, however this bug gives me trouble almost every week when i try to build on my private islands which I payed LL for. Those of us who are paying money into secondlife have a right to a stable development enviroment. The jira should be restricted to people who are land owners. That will keep the stupid alts and their vendetters out of the jira.

The bottom line is that a non-physical object that is not moving should never be returned for being offworld. Nore should an object rezzed at ground level be returned as offworld just because it goes too high in the region.

---------

EDIT :-

Ezian Ecksol,

the behaviour didnt change when havok4 came out. the behaviour started 1-2 weeks before I posted this JIRA. The SkySit was tested along with every other function after havok4 was rolled out to the main grid. My test sheet shows that it worked correctly and was changed to use nonphysical movment instead of physical movment above 768. My notes say that havok4 improved it's stability. Then a couple months later it was being returned to lost and found after a rolling restart. I suspect as a result of something else the lindens were fixing that caused an unintended side effect.

Since posting the skysit issue I noticed the effect on other prims with a long Z access. (avatar sitting or not)
For example it is now impossible to rez a Quantum Core on the gound. It is immediatly returned to lost and found. Yet I can wear it and edit it as per normal. However adding/removing prims is not possible without first rezing it on the ground.

Darling.

The fix you seek is to:

a> stop sitting on objects which place you above 4096 meters.
b> stop rezzing 4096 meter high objects.

The bottom line as you call it is to stop treating us like we do not know what you are trying to do. I.E. Use undocumented LSL behaviours to further your weapon sales, and then claim to your noob clients that you are some sort of scripter goddess.

When changes are made to actually defeat grief uses of the technology, Darling Brody asks her griefer friends the following questions.

"And can anyone find a non-weapon use for the click-2-sit we can use an an example why they shouldnt implement it? "

And "Is anyone able to find the reason they made the change. the JIRA number?"

Darling should be allowed to do these things, as we should be able to respond in kind.

I'm sure no-one here expects us to smile and let her continue to use the jira for her own personal profit at the expense of other paying customers.

Sounds you are jelous of Darling? Let's try to keep things rational.

Whispering is right. The ceiling is set for a reason and if you target it, the correct action is for it to be returned.

System acts correctly therefore this jira should be locked.

Do the right thing. Close this jira for good.

Did anyone else do tests to confirm this instead of blindly defending her?

integer jumps = (integer)(llVecDist(destpos, llGetPos()) / 10.0) + 1;
// Try and avoid stack/heap collisions
if (jumps > 100 )
jumps = 100; // 1km should be plenty
list rules = [ PRIM_POSITION, destpos ]; //The start for the rules list
integer count = 1;
while ( ( count = count << 1 ) < jumps)
rules = (rules=[]) + rules + rules; //should tighten memory use.
llSetPrimitiveParams( rules + llList2List( rules, (count - jumps) << 1, count) );

• I remind people that the JIRA is a place that ONE person has the right to suggests a change / fix for SL.
• Other people can vote in agreement, or they can leave a message to help refine the suggestion.
• Comments apposing the suggestion should be limited to technical or logical reasons why the suggestion can not or should not be implemented.

• • Personal vendettas have no place in the JIRA and will result in an AR being filed each and every time.

Normal
"Minor loss or impairment of function, other problems which have workarounds, or issues that are extremely simple to fix."

Workaround provided.

A nonphysical, unscripted object should never be returned just because someone sat on it. This is a loss of content issue, and as such is major.

No object that has it's centure below 4096m should be returned to lost and found the moment it is rezzed. (ie. the horizon megaprim)

–

It should be noted that Whispering Hush searched the JIRA for my name and downgraded all of the issue I listed as a form of harassment.
Here is a list of examples. One of them includes an unprovoked threat against me too.

http://jira.secondlife.com/browse/SVC-1462
http://jira.secondlife.com/browse/VWR-4185
http://jira.secondlife.com/browse/SVC-2114
http://jira.secondlife.com/browse/SVC-2336
http://jira.secondlife.com/browse/SVC-2336
http://jira.secondlife.com/browse/SVC-1533

"A nonphysical, unscripted object should never be returned just because someone sat on it. This is a loss of content issue, and as such is major. "

Wrong, the object is returned to lost and found. It is not a Major bug in any way shape or form. Try again.

Please learn to prioritize your issues according to jira policy, then it will not be necessary others to show you how to do things correctly.

I am not harassing you Darling, I am correcting your mistakes, of course you may call that harassment, that in itself does not make it so. Just as your sales of weapons does not make you a griefer, only those who use your weapons to grief are griefers.

That's why Darling, it is important to the residents of Second Life that the Jira be prioritized so that valuable Linden expertise be expended in the areas which need attention, and not in trivial little pissant issues like this.

In summary, learn to set the correct priority so that others do not have to do it for you.

Thank you.

Clearly you feel this is not a bug and it does not effect you. As you are not suffereing any loss as a result of this bug, why are you attempting to prolong the suffering of those people who are?

Go away, so I can represent the people who are effected by this issue.

Darling Brody.

---------------

Do not alter JIRA issues with a linden assigned to them.

upon further testing i see why your code is making it go offworld. you purposely putting the prim at the ceiling but if you reduce the z of the warp by 1 meter it will prevent this and completely fix this jira, im going to upload a pic and close this because it is RESOLVED!

also in terms of positioning SL uses the GEOMETRIC CENTER to determine the objects place in the world.

the code is used:

WarpPos( vector d ) //R&D by Keknehv Psaltery, ~05/25/2006
{
vector lastpos;
if ( d.z > 4095 )
d.z = 4095;
do
{ lastpos = llGetPos(); integer s = (integer)(llVecMag(d-llGetPos())/10)+1; if ( s > 100 ) s = 100; integer e = (integer)( llLog( s ) / llLog( 2 ) ); list rules = [ PRIM_POSITION, d ]; integer i; for ( i = 0 ; i < e ; ++i ) rules += rules; integer r = s - (integer)llPow( 2, e ); if ( r > 0 ) rules += llList2List( rules, 0, r * 2 + 1 ); llSetPrimitiveParams( rules ); } while ((lastpos != llGetPos()) && (llGetPos() != d));
}

default
{
state_entry()

touch_start(integer total_number)

}

The photo attached shows that the offworld issue does not effect going offworld sidways. However the same can not be said of going off the top of the world.

@Knife Carver

If you mean you cant teleport above 4096 using a prim based teleporter, you shoudl consider the sit target as a way of teleporting to a higher location than the prim your sitting on. (which this bug also breaks) In fact his bug reducing the build height by 512 meters for my teleporters. Making them useless above 3584.

I would not be complaining if this was always the case and I didnt have products out there that are broken now. Products that are not covered by any kind of a registration/upgrade system. Thus rendering them useless to the people who own them, with no upgrade path.

To answer your question Knife Carver. No it will not offset the object over the build ceiling because an object does not need to be over the build ceiling for this bug to show it's ugly head. While there is a side effect that objects can have child prims over the build ceiling, this was the original behaviour anyway and does not effect a cleaver teleporter from reaching the location anyway.

Darling.

The prim will not go offworld until you sit on it. it will sit at the location with no problem. it is the sit target that make sit go offworld. This JIRA has been assigned to a linden as as such may not be closed by anyone but a linden. Do not violate the community standards.

[quote]
http://jira.secondlife.com/browse/SVC-1462
Alexa Linden - 02/Jul/08 08:16 AM
A quick reminder for everyone - https://wiki.secondlife.com/wiki/PJIRA#Caveats

"The Second Life Community Standards apply to all areas of Second Life, including the Second Life Public Issue Tracker. Any Resident who disregards these guidelines may be banned from future use of the issue tracker.

Examples of specific behavior or actions which may result in removal from the Issue Tracker:

• Using the Issue Tracker to promote your business, cause, blog, website or anything not directly related to the issue at hand.

• Flaming - The act of posting a message that is intended to incite anger or directly attack a person or persons is called "Flaming" and it not appropriate for the Issue Tracker. Please keep to the facts of the issue at hand. Posts that disregard this may be deleted.

• Private Discussions - Blogging your personal opinions or off-topic rants. Pjira is about finding solutions to issues. We love productive feedback. Please stick to the technical details of the matter at hand.

• Editing Wars - Repeated changes to a resolution, priority or classification of an issue within Pjira.

Personal attacks or inappropriate posting with result in a written warning and can lead to banning. You are each responsible for you own posts - regardless of how or what someone else posts. Keep all posts to the issue at hand.
[/quote]

I have filed an Abuse Report and will file one each and every time you violate the community standards by using the JIRA to grief creaters.

Darling

1) I am standing on a white platform at 4089 meters high. Well under the 4096 limit.

2) I have a cylinder rezed with a sit target set for <0,0,30>.

3) When I sit on the cylinder the object is returned to lost and found.

Clearly this has NOTHING to do with the warppos destination in the previous example script.

The worse part about this is that ANYONE can return your builds by sitting on them !!

Darling.

I tried that on my parcel and it was reproducable that another avatar could return my objects set up the way Darling described by sitting on them. It should not possible for other avatars without the appropriate permissions to return my objects on my parcel. This seems to be a bug.

The statement "The worse part about this is that ANYONE can return your builds by sitting on them !! " is false, the build has to be either extremely close to the ceiling (4096) or have a sit target that puts some portion of the bounding box of the object above the ceiling. The above statement is misleading because the instances where it is accurate are so few and largely self inflicted (building close and using unchecked sit targets).

Objects are returned based on root prim location, not binding box. This is has always been true for object/agents going undergound and off the side of a region. It WAS true of going over 4096 until a couple weeks before I posted this JIRA. It WAS true of HAVOK4 on the main grid for more than a month too.

It was not listed an a BUG to fix in the jira.
It was not announced as a fix in the release notes.
A linden has been assigned to the issue, instead of a "exected behaviour" responce that is given for secret security fixes.

• • • Make special note that this JIRA is about an unexpected CHANGE to what was established behaviour for havok1 and for havok4. In other words "things never used to get returned, not even under havok4".

When all these facts are taken into account it is resonable to say it is an unintended bug introduced by some other code change.

Darling.

I have sent you an object that demonstrates this bug. it has SVC-2336 is its name.

Darling Brody

Good JOB!