Madelaine McMasters

Hi Sweepea, You may have a corrupted avatar specific application support file. You can get rid of those support files by... In Finder, Hold down the Option key, go to the "Go" menu and select "Library". Select the "Application Support" folder and open it. Find a folder named for the viewer you are using and open it Find a folder named for the problematic avatar and toss it in the trash Relaunch the viewer Doing this will delete all your IM chat histories, so if you want to save those, drag the avatar's folder to the desktop rather than to the trash. If you are able to log in after moving the avatar folder, you can manually move back all the chat history files (which are named after the people you were chatting with) to the newly created avatar folder in the viewer's application support folder. If that doesn't work, a clean install may be in order. Here are instructions for Firestorm, which are generally applicable to other viewers with an appropriate change in the various path names... http://wiki.phoenixviewer.com/fs_clean_reinstall Good luck!

Hi Quietta, You probably have a corrupted "saved state" file. You can get rid of it by... In Finder, Hold down the Option key, go to the "Go" menu and select "Library". Select the "Saved Application State" folder. Find a folder named for the viewer you are using (ex: com.secondlife.indra.viewer.savedState or com.phoenixviewer.firestorm.viewer-hvk.savedState/) Toss that folder in the trash. Relaunch the viewer. I hope that works, good luck!

Hi Goddess, Rolig and KarenMichelle are correct. Your inventory is safe, but in need of a rebuild. You are, like the rest of us, discovering that nobody, not even Goddesses, can escape Murphy's Law and the GoofballsOfMystery that are Linden Lab. Good luck!

Vic Taurog wrote: As for Rolig's problem, I can't help but think that it's related to the recent problem of objects a first appearing invisible until you right click on them. Somehow the viewer is not getting the message to redraw the screen until you right click it. Perhaps when LL solves the invisible prim problem, Rolig's problem will be solved too. Yeah, I wondered if this was another "interest list" issue, but I figured that if the viewer knew it should be drawn, it would know it should be rotated. I love the windmill, Vic! ;-)

Rolig Loon wrote: Madelaine McMasters wrote: [ .... ] So, we may have an explanation for snap back of llTargetOmega prims, but we're still without an explanation for Rolig's observation that some llTargetOmega calls simply don't seen to stick. That has to be a bug in the viewer code. I can get errant prims to rotate properly if I right click on them or if I either TP away from the sim or relog. Or if I stop llTargetOmega totally (llTargetOmega(ZERO_ROTATION,0.0,0.0) ) and wait for a second or more before restarting the rotation. For my immediate purposes, that's enough of a fix, but it would be nice to not have the bug to deal with. Rolig, is it that you must stop the rotation, or simply not call llTargetOmega rapidly? I modified that example I sent you to NOT stop rotation and it still works every time.

This makes sense, Vic. I could imagine that, during creation of the viewer, the designers found it easier to start from zero whenever the prim containing llTargetOmega actually moved, than to do the coordinate conversions on the current rotation. Rolig also noticed that script resets and touch events on the prim reset the position. Resets make sense, and it could be that the touch event rezeros the prim so that functions like llDetectedTouchFace can work. If the servers don't know the current viewer rotation of a spinning prim, they can't determine which face has been touched, so they cause the viewer to rezero the prim to obtain agreement with the server model of the scene. So, we may have an explanation for snap back of llTargetOmega prims, but we're still without an explanation for Rolig's observation that some llTargetOmega calls simply don't seen to stick.

Ansiri wrote: Hi, here's a few pictures. Eh, still wondering how should post the pictures, as large or full size or what... did the full size now, hoping they're not too big. :smileysur You've done a remarkable job rehabbing the old neighborhood laundromat, Ansiri! Though I do miss being able to dry my circus tent there...

Erik Verity wrote: I have noticed two things that causes a snap back to zero (most likely other things can cause it as well): Using more than one state - upon re-entering the default state, the snap back would happen. I don't remember if I also reset to ZERO_ROTATION inside the state entry or not, but I might have - I believe it was happening either way; Upon reset of a script in the prim - doesn't have to be the same script that is setting the rotation. I was resetting a script to release animation permission when an avatar stood which then caused the snap back even though it was a different script. I've never done either of those things in my creations (except resetting when editing), so that would explain my not seeing snap-back if you're right. My scripts are generally quite simple. I got the impression Rolig's was rather complex, so there may be opportunity for something else to happen which triggers a rezero of the object's local rotation.

steph Arnott wrote: "there's no change to grey texture while waiting for the alternate script to load." ? When you texture a face via script, if the texture isn't already in the viewer cache, the progressive texture load process begins. While the texture is downloading, the prim face shows the progress, starting with the default grey, then proceeding through progressively higher resolutions until the full texture has loaded. If you use Sassy's scheme of putting both ON and OFF depictions of the switch in the same texture, then the moment the switch rezzes in the scen, both switch states are present, though only one of them is visible. Upon changing the texture offset to reveal the other state, it appears instantaneously. If you flip textures on the switch's state change rather than change offset for a single composite texture, the first time this is done after initial scene rezzing, you'll see the download progress for the new state's texture. This will only happen the first time, thereafter both textures are displayed instantly as they're both in the cache. I have a picture frame that cycles through images in the Contents folder. To avoid this gray/progressive load issue, I apply each new picture to a hidden prim face before bringing it to the front. This forces the texture download, but you don't see it happen. When the fading transition is made from the previous to the new picture, both images are fully rezzed.

Rolig Loon wrote: Your particular problem is slightly different from the one I was wrestling with last night and have now hacked my way around. Your anemometer isn't stalling; it's resetting to its zero location when you change speeds. That's unfortunately what it is supposed to do. The rotation is entirely client side unless your object is physical. When you stop the rotation, therefore, the servers are blissfully unaware that you ever did anything. Your object appears exactly where is was before you applied llTargetOmega. Take a look at the smooth rotating door script that's in the LSL wiki to see one solution. It will take a bit of work to wrap your head around what's happening, but basically the server is performing stepwise rotations with llSetLocalRot while your client is using llTargetOmega to make the movement look smooth. It works nicely in a door. With luck you'd be able to adapt the idea to an anemometer too. Rolig, I haven't observed the behavior you mention. Long go, I scripted a globe that could be set to rotate once per day/SL day/hour/minute. The globe never reset to zero on a speed change, but just took on the new speed from whatever orientation it currently had. The little demo I created this morning also works that way for me. I have seen objects swing around to zero before starting to spin, but I've no idea what makes that happen and have not observed it in the few spinny things I've made. There's something going on here we may not yet have our finger on.

Happy Friday, Kids!!! Jeepers Val, you live in exotic France, you can't just sleep and eat all weekend. Drag out your oooh la la and find some trouble.

I never used Pages much, but I like the context aware tools on the right. Flash is even more of a red headed stepchild under Mavericks. It's now sandboxed in Safari because it's just too dangerous to let run wild. It still won't work in SL and I doubt Adobe is going to fix that. I'm quite pleased with Mavericks overall. It's nice to plot a trip in Maps on my Mac, then send it to my phone. I also like being able to read my books on the Mac now. Activity Monitor has always been there, I don't recall seeing any changes to it in Mavericks. Battery life on my MacBook Air has increased significantly with Mavericks, that's very nice. And all my Macs feel faster.

Hi Vic, Rolig Loon was having trouble with llTargetOmega, which prompted me to code up a quick experiment. I sent you a copy of it, which produces the sort of rotation changes you desire. Why your code doesn't do what you want I can't say, but perhaps my demo will give you some insight. As I mentioned in my IM to you, be careful about high rotation rates. llTargetOmega is sampled by the scene's frame rate, and if that falls sufficiently, you will see erratic rotation. Imagine your anemometer has three cups and spins three times per second. If you happen to have a frame rate of 9fps, it will appear to stand still, as each cup will have moved to exactly the position of the previous one at each new frame.

KarenMichelle Lane wrote: WOW - Madelaine - you get the Compassion Award for helping that way. Applauds!!!! Do I still get the award if I admit that I was setting fire to pin filled Linden voodoo dolls while helping other people learn SL? Oh, and call me Maddy, I don't like being reminded that I don't know how to pronounce Madelaine.

Blue Voix wrote: Which is why almost every third party viewer has a in world support group..... Which is inefficient and does not address the issue of trying to help, or get help from, people using different viewers. In the past, when trying to teach people about SL, I often found it necessary to inquire which viewer they were using, then download and run the same myself. This was the only way I could avoid the confusion of that Tower of Babble.

The issue isn't that scenes look different, it's that the user inteface is different. So when you're trying to teach someone how to navigate the SLV UI, you can't say "Go to the "Me" menu" and expect the other party to understand, as they may have no such menu. They may also have a drop down right-click, where you have a pie, and with different options in each, or the same options, but with different names. Across the TPV's the UI is a Tower of Babble.

valerie Inshan wrote: Good morning Hippie. Hugs you. Cheer up, or I'll drag you outside to play... Hi, Kids!!!

Hiya Pussycat, I'm not having viewer problems beyond the norm. The latest Firestorm beta isn't terribly stable, but the release version runs without too much hassle. The LL viewer seems to work as well under Mavericks as Mountain Lion. I won't say that any viewer runs nicely under Mavericks, but in my 5.5 years here, no viewer has run well on any OS. Mavericks doesn't seem to have broken anything and, beyond SL, Mavericks is a pleasant experience. If you have Western Digital external drives running Smartware, be careful... http://www.zdnet.com/western-digital-warns-customers-os-x-mavericks-may-destroy-drive-data-7000022800/

The syntax is probably wrong (been a while since I've coded) but you should be able to work it out. You'll also have to supply the starting of the timer and other stuff... float alpha = 1;integer color = 0;integer prim; Set stuff up here... timer{ color=color++%5; // color cycles 0->4 for(prim=1; prim<=10; prim++){ llSetLinkPrimitiveParamsFast(prim,PRIM_COLOR(ALL_SIDES, llList2Vector(list,(color+prim-1)%5), alpha); }} The magic here is in the modulo operator. You don't actually need it in the first instance, as using it inside the llList2Vector call constrains it to the valid range of 0-4. Also, your example color names are not quite the way the computer would see them. The first item in a list has an index of zero. So your colors go from c0 to c4. Your prim numbers are correct however, as the root prim in a linkset is 1 and the children go up from there. The "-1" in llList2Vector may not be needed. it simply ensures that the script starts with the sequence you listed. If you don't care that the first iteration is p1=c2 (by your naming, c1 by the computer's), then remove it. Oh, and I've no idea if this will complie, much less work. Good luck, Life!

Hit Ctrl-Alt-T to highlight transparent textures (and again to return to normal). The prim will appear as a translucent red thing and you should be able to locate it. Then right click and delete/return it. If it's a very large prim, it may be encroaching from a neighboring sim. If so, you'll have to contact your sim neighbor and have them remove it, or AR it for "encroachment". Good luck, Grizzly!

Dresden Ceriano wrote: But seriously, have you ever even considered that I may have already been dressed as a Christmas tree? If you'd already been dressed like a Christmas tree, I'd not have decorated you, right? You were dressed as a garden variety Colorado Blue Spruce, and the only dates you'd have attracted in that outfit would be squirrels and cardinals. One of those would go for your nuts, the other for... well from what I've seen of the Catholic Church, you'd have done alright with a cardinal. So, I'll take a little credit for your meeting this gingerbread fella. Don't get crumbs on the sheets!

Hi Mosspelt, Failure to rez is often the result of a poor connection between your computer and the SL servers. Here are a couple links that address the issue... http://wiki.phoenixviewer.com/phoenix:bake_fail and... http://blog.nalates.net/2011/10/26/troubleshoot-your-sl-connection/ Good luck! ETA: There's a lot of stuff to go through in those pages, Mosspelt. If you're on wi-fi, did you try a cable connection? Did you try using Google's DNS servers at 8.8.8.8 and 8.8.4.4? Hopefully someone else will be along shortly to shine some light on this. It is curious that everything BUT your avi appears to load correctly.

What doesn't kill you makes you stronger - Nietzsche

Good morning, you two!

valerie Inshan wrote: Good morning Hippie! Back at work today but I would have loved to stay in bed this morning... *sighs* Hugs you all guys! Back at work? That means you didn't drink the chicken juice. I'm heartbroken.