|
|
|
[
Permlink
| « Hide
]
McCabe Maxsted added a comment - 14/Sep/07 01:51 AM
Sounds like you're using llTargetOmega to do your rotating. This is client-side, and will appear differently on different people's screens.
I'm experiencing this issue too. Several objects I've set to just rotate forever, are stoppping. They restart when right clicked, but that's hardly optimall.
yes, it was 4 months ago for me too, even touching the object will start it again...
This bug is verified, and can easily be verified by creating a simple touch-activated rotation script that changes direction each time it is touched.
When rezzed to ground, the script works properly. When worn on an avatar, it does not. This is an easily verifyable bug in llTargetOmega, and a problem one. And like the above users, I have only started noticing this on a relatively recent basis. This needs fixed, as many avatar attachments rely on this script function to work properly. I'm trying to make an object rotate. I couldn't get it to work but now I know why; The object was rotating only I could not see it. My friends could see it turn.
I don't know if this is related to this issue, because I'm not a scripter. If so, does anybody have a solution for this problem? Is there a way to make something rotate without using llTargetOmega? This sounds like the same thing as
default
{ state_entry() { llTargetOmega(<0,0,1>,1,1); } } *FIXED* Second Life 1.19.1 (4) Apr 2 2008 12:03:24 (Second Life Release) You are at 260130.0, 248374.4, 30.7 in Hazzard County South located at sim4301.agni.lindenlab.com (63.210.157.205:13005) CPU: Dual i386 (Unknown) (2000 MHz) I don't think that this issue is fixed. I've still some objects on my land that should rotate using llTargetOmega, but they don't!
One object I created yesterday works fine, but some older ones don't - even if I reset the scripts. Second Life 1.19.1 (4) Apr 2 2008 12:03:24 (Second Life Release) You are at 259780.0, 271778.0, 23.5 in Neum located at sim5048.agni.lindenlab.com (8.2.32.49:13006) CPU: Dual i386 (Unknown) (1833 MHz) my objects rotate if my camera is within 10meters of them, but not if it is further away, even after recompiling and reseting the script.
Second Life 1.19.1 (4) Apr 2 2008 11:59:37 (Second Life Release) You are at 255521.0, 243865.4, 25.7 in Aero located at sim3747.agni.lindenlab.com (216.82.22.228:13004) CPU: AMD (Unknown model) (2812 MHz) I too am having this issue with products I produce - but only after I installed the Viewer 1-19-1-4 (My previous viewer 1-19-0-5 worked perfectly)
This also appears for me to be distance related - as indicated above by Sylumm - if I and others are withing 15 - 20 meters - everything works fine - beyond that distance they stop rotating - but will re-start rotation if you approach the object and stand there for a few seconds. I hope you can help - thanks !! this issue does NOT duplicate
 )
so I'll repeat here what I said in as of 29-Apr-08, llTargetOmega() continues to malfunction. for the purposes of this posting, "objects" refers to any/all objects that utilize llTargetOmega() FEW objects behave the "old way" – single-prim: start/stop OK; multi-prim: start but can't stop i will say this: i see this new nastiness most often where the prim using llTargetOmega is a child. all the objects i've been working with were created before Havok4 deployment oh – i should add this: the bad behavior of llTargetOmega seems unaffected by the 'physics' status of the object i'll post my tech details but DO NOT let that fool you. i continue to see the outlined issues on every Mac and PC system i have. Second Life 1.19.1 (4) Apr 2 2008 12:03:24 (Second Life Release) You are at 283171.7, 267426.4, 701.5 in Mephilo Tor located at sim2978.agni.lindenlab.com (216.82.19.221:13000) CPU: Dual i386 (Unknown) (2400 MHz) Thanks Nava! A live, repeatable example helped tremendously.
The bug as I see it is "Slowly rotating llTargetOmega child prims stop rotating when you move ~40m away." 40m??? mine don't work at all even when I'm less than 5m away. when i edit it, the object will jump to a new roation position and that's it
go here http://slurl.com/secondlife/Delilah/21/74/68 This week it's okay again at the SIM I'm located at (see above).
Last week the objects didn' rotate when I loged in. I noticed the following:
There was a workaround to restart them by shift-draging the prims, but that's no solution for an art gallery displaying ROTATING objects The llTargetOmega bug has not been squashed yet!
I have a vendor with 16 linked rotating sculptie prims, and 1 larger unlinked sculptie prim that also rotates. Here is the location: http://slurl.com/secondlife/Wallaby/232/226/54 Most of the time, when I log on, the linked prims are not rotating but the unlinked one is. Sometimes the linked prims are rotating, but they stop after a few moments, especially when I update the sculptie maps via LSL. The unlinked prim is always rotating. If I go into edit mode, and click on the non-rotating linked prims, sometimes they will start rotating. But not for long. If I shift-drag the linked & unlinked prims, they copy left behind will start rotating. Sometimes. But they stop rotating soon after that. However, the unlinked prim always rotates, never a problem. If I go into edit mode & click on the non-rotating linked prims, they will shift their axis, as if they had rotated a step. If I click on the ground to deselect the prims, they rotate a step again. Select, deselect, they rotate one step each time. Sometimes they don't however. This bug is driving me crazy!!!! dan – glad you found the hands-on example helpful. If there's ANYTHING I can do to help facilitate the troubleshooting process, please let me know.
However, i have to agree with Marie – I'm experiencing stops & stutters regardless of [physical or camera] distance from object. I just want to say this issue continues for me and has never been resolved since my reporting it. I still cannot see objects rotating with the SL viewer. Oddly enough if I use the On-Rez veiwer I can. The object created do not rotate, distance is not a factor. It simply does not work, no amount of clicking the item helps me. My ability to build waterfalls with rotating paddles directed by the water ended when this began and has been dead since. It is extremely annoying not to be able to "suddenly" without any obvious cause have this problem. Seemingly one of the new client releases did "something" and this just stopped working. I wish to god this would be addressed.
on this page http://wiki.secondlife.com/wiki/LlTargetOmega
i found this "Set the gain to zero to disable and remove the rotation behavior, eg llTargetOmega(ZERO_VECTOR, 0, 0); So I went inworld and found my script had this llTargetOmega(<0.0, 0.0, 0.04>, 0.1, 1.0); so i incrementally changed the spinrate and gain and it began to work when i had 0.7, 7.0.. then i managed to incrementally drop it down to 0.3, 3.0 but could go no lower. to get it to start again i had to up the numbers to around 10 to get it to start and then drop it again. after around 20 minutes it stopped working all together and went back to the jerkiness when you click edit. Of course it could have something to do with the spin/gain - certainly changing those triggered the rotation. whereas changing the vectors didn't. the object is here: http://slurl.com/secondlife/Delilah/21/74/68 Hopefully there's something to go on in this that means you may be able to pinpoint and fix the problem. *edit* last night (8/5) i got all excited as it started to work again. my sim was being griefed and the lag was terrible, yet my rotation began to work. it was spinning quite maniacally though- certainly faster than it is supposed to. of course the griefer attack has gone and it's stopped rotating for me again.. i can see the rotation with a no longer supported laptop running 1.19.1 (4) with an ATi 9700 card with OpenGL Version: 2.0.6388, I can see it on a pc running 1.19.0 using a GeForce4 MX 440/AGP/SSE/3DNOW! but can't see it on 1.19.1 (4) with Graphics Card: GeForce 7300 LE/PCI/SSE2/3DNOW! with OpenGL Version: 2.1.2 I see this problem in 1.19.1.4
Model Name: iMac the scripts in the object are very straightforward: state_entry() under 1.19.0.5 this works fine. under 1.19.1.4 they stop turning and snap back to 0 rotation occasionally... TPing into the area they wont move at all. Same here. Works in 1.19.0, no go in 1.19.1. Some items rotate, some do not. Distance is not affecting start or stop.
CPU: 4 x PowerPC 970 (2500 MHz) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Critical
llTargetOmega periodically stoppping rotation
.