|
|
|
[
Permlink
| « Hide
]
MartinRJ Fayray added a comment - 04/Mar/08 06:17 PM
[18:15] XXXXX XXXXX: some of those rotation bugs can be tricked by putting a simple 'llSetText("test",<0,0,0>,0); '> under the omega one or even two times. but that doesn't work here either.
i have the same problem here. the rotating object does NOT get attached to an avatar (i know about that bug).
some other objects i made are also link-sets and do keep rotating with the same script. Is this happening for straight llTargetOmega, that is started once and never changed? Or are the llTargetOmega parameters being changed?
A sample failing script would be even better. A straight llTargetOmega, for example:
default { state_entry() { llTargetOmega(<0,0,1>, PI, 1); } } . And no, it's never changed. This is a general issue, happens everywhere and has happened very many times with a wide variety of llTargetOmega function calls. Regards. This is an old old bug. Leave something rotating long enough and you'll see it.
I've never seen it. I have several things that are always rotating this way that I have never seen stop.
UPDATE:
since the crashes on April 5th llTargetOmega doesnt work at all. All objects that should rotate and always did just dont do nothing. regards I'm now seeing all targetomega objects not rotating anymore. Worse still, they don't start rotating again when updated. Taking and re-rezzing said objects seems to make them work again though.
Relogging makes broken objects stay broken, but those which are taken and re-rezzed to fix, don't break. That leads me to believe this is serverside somehow. 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) (quote from another thread on the same matter) Hmm . . . I can remember having this problem once, but only once, much earlier in the H4 beta process. An object I had set with llTargetOmega was not rotating inexplicably. I forget how I fixed it (it may actually have been shift-dragging), but since then I've never seen the problem again. I have several objects in my home that use llTargetOmega that have been around for a long time, and none of them have been adversely affected. In fact, some of them were broken until the H4 update that fixed llTargetOmega explicitely.
Considering that, and considering that non-phys llTargetOmega is client-side, I'd be tempted to say that it's a client-system interaction problem. That would also (as some have stated) explain why some of us are seeing this, and others are not. It would also explain why resetting/recompiling/new scripting the object would not work. Targetomega is STILL broken.
Anything using targetomega will not work. Hardware Overview: Machine Name: iMac GeForce FX 5200: Chipset Model: GeForce FX 5200 Tested using a G5 iMac:
Second Life 1.22.6 (107949) Jan 14 2009 20:15:27 (Second Life Release Candidate) You are at 255251.1, 255095.3, 21.5 in Sandbox Wanderton located at sim3004.aditi.lindenlab.com (8.2.33.230:12035) CPU: PowerPC 970 (1599 MHz) libcurl Version: libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 Using this script, I'm unable to repro: integer count=0; default { state_entry() {llTargetOmega(<0,0,1>,PI,PI); } touch_start(integer total_number) { if(++count%2) llTargetOmega(<0,0,1>,0,0); else llTargetOmega(<0,0,1>,PI,PI); } } The cube will stop and start when touched, as expected. Editing the cube will make it appear to stop spinning the user who is editing, but spinning is resumed after the box is deselected. A fresh login also shows the cube spinning. I waited some time to see if llTargetOmega() would fail, but nothing happened. I repeated the tests with llTargetOmega() in the root prim of a multiprim object, and the results were the same. This is unacceptable.
Of course you can not reproduce our bugs on the corporate net work. Maestro Linden noted that LL cannot repro this condition on their own network because they do not have the resources to test under end user conditions. The way they test under end user conditions is inputs from users. By that standard this issue has been repeatedly confirmed on this and other threads. Prepares for a Second Life with out IITargetOmega0. Don't know if this is relevant or is something different, but I found a problem this morning with a multi-prim dance machine of mine that would not spin on command as usual. First noticed this problem after the rollout of the new 1.25.5 server code. Another single-prim device of mine in the same location was unaffected. Resetting the scripts in my multi-prim device did not clear the problem. However, when I took it into inventory and re-rezzed it, it worked fine. My client info:
Second Life 1.21.6 (99587) Oct 15 2008 09:48:17 (Second Life Release) You are at 218781.7, 288969.5, 28.3 in Boundless located at sim5270.agni.lindenlab.com (8.2.33.17:13001) CPU: Dual PowerPC 970 (2000 MHz) libcurl Version: libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Reopened
Critical
llTargetOmega DOESNT WORK at all! Mac PPC OS X
