• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: SVC-1952
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Critical Critical
Assignee: kelly linden
Reporter: Cecilia Zheng
Votes: 32
Watchers: 15
Operations

If you were logged in you would be able to see more operations.
2. Second Life Service - SVC

llSetLinkPrimitiveParams PRIM_POSITION on Avatar is not work on some sim after Havok4 Upgrade

Created: 31/Mar/08 02:58 AM   Updated: 01/Aug/08 12:30 PM
Return to search
Component/s: Physics
Affects Version/s: Havok4 Beta, 1.20.0 Server
Fix Version/s: None

Environment: Second Life Simulator 1.20.0.83892
Issue Links:
Duplicate
 

Linden Lab Issue ID: DEV-13218
Linden Lab Internal Branch: havok4-5


 Description  « Hide
Reference: http://jira.secondlife.com/browse/SVC-1505

I'm really worry about each update/upgrade of Havok4 and the case is not apply to all Havok4 region, but in random.
Each time there is update/upgrade on Havok4, I may receive a complaint about llSetLinkPrimitiveParams for PRIM_POSITION.

Previously, the strange is that, in 1 or 2 days, the issue is gone and the sim handle llSetLinkPrimitiveParams correctly.

I'm just test on sim Emaga, and it just failed to make the command to work properly.
I really have no idea what happen, cause it happen in random and often happen repeatedly after Havok 4 update on random sim.

My test is the same as previous Jira SVC-1505:

I make a simple test to do, that create 3 box in a line, with center become the root prim and have this script:

default
{
state_entry()

{ llSitTarget(<0,0,.1>,ZERO_ROTATION); }

touch_start(integer total_number)

{ vector test=(vector)llGetLinkName(llDetectedLinkNumber(0)); llSetLinkPrimitiveParams(4,[PRIM_POSITION,(vector)test,PRIM_ROTATION,llEuler2Rot((vector)test)]); }

}

The left and right box have name:
<.0,1.0,.0>
and
<.0,-1.0,.0>

So with the script when I was sit on the center box, and touch the left or right box should moved and rotated.

And I will try to check the sim each day, and update here.

Sincerely,
Cecilia Zheng



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Cecilia Zheng added a comment - 02/Apr/08 10:01 PM
I'm just received more complaint about the SL Simulator 1.20.0.83683.
Seem, The llSetLinkPrimitiveParams for PRIM_POSITION to move avatar position,
is not work correctly in some sim, but not all sim.

So this is very random problem that happen when just have upgrade/update to new version of havok4


torben asp added a comment - 04/Apr/08 12:36 AM
Hello there,

Hallgerda is one of the sims that has the problem mentioned above.
Hope it will be fixed soon;o)

Cheers
Torben Asp


Cecilia Zheng added a comment - 04/Apr/08 05:24 AM
Just Check sim Emaga, It seem already fine.

Skye Cardiff added a comment - 04/Apr/08 05:32 AM
Looks like the problem is happening in Coral dAlliez as well.

Lauralai Toland added a comment - 04/Apr/08 10:07 AM
The problem is happening on Blackburne sim. In testing the scripts ourselves last night, we found that on some items my avatar was perfectly in position while a friends was vastly out of place. On other items my avatar was out of position and my friends was even more out of place. (Same pose tried by both avatars resulted in different outcomes) It's effecting different poses, in different furniture pieces and seems to be a completely random occurance. I can say that it seemed as though resetting the scripts allowed my avatar to be positioned correctly, but only the first time the item was sat on, all subsequent sits were out of place. If it helps at all, all items we tested are owned and made by me. We did not have other creators content to test. I sure hope you can figure it out! Thanks!

philby sands added a comment - 04/Apr/08 11:20 AM
problem also occouring on samselarm too

Genjcchristian homewood added a comment - 04/Apr/08 03:06 PM
It is a problem in Quilassito.

Chenda Allen added a comment - 04/Apr/08 08:49 PM
Region: Unknown Central
Intan Couples Dance Ball

serpy palen added a comment - 05/Apr/08 04:03 AM
Also is problem in Bilogorac located at sim4034.agni.lindenlab.com (63.210.156.192:13004)
Second Life Server 1.20.0.83892

Nack Barnes added a comment - 06/Apr/08 11:57 PM
This issue is manifesting in a variety of ways at the blackburne sim as well. It is behaving inconsistently between avatars, where some avs are set correctly and some are not. Consistently.

I notice this ticket has been open a week, and has yet to have any technician assigned to it. This issue has broken significant assets in my area, from furnishings to dance devices. Can we please get this at least assigned to someone for it to be looked at??


Fortytwo Botha added a comment - 07/Apr/08 06:23 AM
Also a problem in Gia Islands with the Intan Couples Dance Ball

Mosley Sperber added a comment - 07/Apr/08 01:02 PM
Same problem currently in in Varano located at sim5409.agni.lindenlab.com (8.2.33.156:12035)
Second Life Server 1.20.0.83892

Felix Oxide added a comment - 07/Apr/08 10:08 PM - edited
my sit scripts have stopped functioning properly in the mainland region of Kolbeinsey since the update to Havok 4. The creator of the scripts says that setlinkprimitiveparams movement is no longer working in this sim but setlinkprimitiveparams rotation is. We tried it in another sim and they seem to function normally. but in Kolbeinsey they do not. Here is another odd bit, they function normally for me, but no one else now. They do the animation or pose but are not moved to the set offset.

Lindens I know you are overwhelmed with issues, but this is a priority. All of my seating in my club is affected and of course the initial reaction from folks is to blame the owner of the objects. Please fix this ASAP.


Cuka Carter added a comment - 08/Apr/08 03:59 PM
Hello there,

Sumatra is one of the sims that has the problem mentioned above.

Thank you
Cuka Carter


Efran Loon added a comment - 10/Apr/08 01:41 AM
As has been mentioned in https://jira.secondlife.com/browse/SVC-2096 me and a friend encountered the same problem but we have more information.

Everything worked OK for me but not for her.

Basically the problem seems to be that the code checks for that avatar's permissions in the 0,0 location of the sim and not the current location. So if that corner does not allow them access ( or possibly a more specific permision ) they cript does not work.

We made a small plot of 4m x 4m in that corner, made it public access and now it works for everyone.

Hope this helps


Mosley Sperber added a comment - 10/Apr/08 02:43 AM
Confirmed for Varano; here also the parcel in the 0,0 location has banlines up. (As it is not my parcel, I cannot fix things here.) Thanks Kyle, Ilse, and Efran for figuring that out – now hopefully it can be fixed really soon!

kelly linden added a comment - 10/Apr/08 02:01 PM
Yup, this was a bug where we were not appropriately transforming the agent's seated position to region coordinates, and thus checking entry permissions around 0,0 instead of where they actually were.

This will be fixed in an upcoming release. Due to timing this will NOT be the next (1.21) release, but should be the one after.


biggd dastardly added a comment - 13/Apr/08 06:56 PM
I have this problem in SW Crystal Springs. Could this region be checked? It is interesting because it happens with some avs and not others.

Cecilia Zheng added a comment - 29/Apr/08 12:37 AM
Fixed on Sim Server 1.21

darling brody added a comment - 01/Aug/08 12:07 PM - edited
@ kelly linden

I'm getting flooded with people complaining about broken teleporters in their regions, even though it is working in my region "Quantum". For every person who is complaining to me there must be dozzens who are dropped half way to their destination without knowing why.

My region is running "Second Life Server 1.23.4.93100". Are you sure about the fix being in 1.21?

Can you roll back this broken fix in the next update(whatever version that is) while we wait for a proper fix for it? At least that way everything will continue to work.

This JIRA went from normal to critical after the broken fix was rolled out. Clearly people care more about having their vehicles and teleporter work than the occational orbit. Especialy in the short term.

Darling Brody.


kelly linden added a comment - 01/Aug/08 12:19 PM
I dunno what you are doing with the status of this jira Darling.

What I fixed and changed went into 1.21 and has since been deployed to Second Life a long time ago.

  • Is the broken behavior new to 1.23? If the repro is not exactly the same as in the description of this jira please create a new jira.
  • Has this just never been fixed for you? Cecilia commented that she found this to be fixed in 1.21.
  • Why do you think it is 'fix pending'? That marker means that code to fix it has already been written and is in testing or in the pipeline to be released. Considering you just re-opened this it seems unlikely it is in that state if the bug is really there.

If I were to hazard a mostly random guess (I don't have much to go on from what you have said so far) then I would say there is some combination of object owner or permissions and parcel or region properties that cause the teleporters to stop working.

Do you know if those complaining are trying to cross region boundaries with the teleporters? That could be it, I think we limit how for outside the region a teleporter will work.

Please do get what information you can, and only mark things fix pending if you have written a fix and know it is in the QA or release pipeline. As I said before, if you find the repro is not exactly the same as the original description please file a new jira.

Thanks!


darling brody added a comment - 01/Aug/08 12:30 PM
Kelly. I was just about to edit my original post when I saw yours.

I intended to post under https://jira.secondlife.com/browse/SVC-2543 where the recent change has broken teleporting. However I clicked the wrong issue.

More details can be found in the recent comments of SVC-2543. I will close this issue again.

In short there seems to be a problem with the way range checking has been implemented that prevents teleporting around the same region. I define a region as 256x256x4096 which was meant to be the new range limited valid range for moving the avatar.

Darling.