Rolig Loon

Viewers using the V2 codebase use a different method for keeping track on items in inventory, in order to handle the new system of creating outfits and allowing multiple attachments on a point. If you use the same cache location for a V2 viewer and any of the others, therefore, there will usually be some confusion about which clothing items the veiwers think you were wearing last. For that reason, it's always wise to use a different cache location for each viewer. For right now, if you clear cache as you log out, the V2 viewer you are using right now should remember the outfit you are wearing next time you log in.

I don't know about 2.6.3. Phoenix makes it easy. Preferences >> Input & Camera >> Camera View Angle and Camera Follow Distance. There should be debug settings in V2 that do the same thing. Check your debug settings menu.

Well, you can compress the script a good deal by putting your switchit function into the body of the touch_start event. You don't really need it in state_entry, after all. Even though I left it there, you don't even need to set the prim's color in state_entry, really, because it never changes. Just set the prim to white manually. Here's a shorter version.... // Touch the object to light it up.// Lighting is configurable.integer light_s = TRUE;vector lightcolor = <1.0, 1.0, 1.0>;float intensity = 1.0; // 0-1float radius = 10.0; // 0-10float falloff = 0.0; // 0-1float glow = .01;default{ state_entry() { llSetColor(lightcolor, ALL_SIDES); } touch_start(integer total_number) { float thisglow = glow * (light_s = !light_s); llSetLinkPrimitiveParamsFast(LINK_SET, [ PRIM_POINT_LIGHT, light_s, lightcolor, intensity, radius, falloff, PRIM_FULLBRIGHT, ALL_SIDES, light_s, PRIM_GLOW, ALL_SIDES, thisglow ]); }} Edit: Made it even shorter. :smileywink:

That really depends on the product and on the resale agreement that you have with the creator. In SL, we don't have warehousing issues, so you don't stock 100 copies of the same item, wating for a sale. You usually buy one item with copy/transfer permission and you sell it over and over again. The creator may expect a flat payment for the right to resell those copies, or may only let you sell them through a split-payment vendor that divides the proceeds from a sale between you. The only way to find out is to talk with creators whose work you would like to carry, and work out an agreement. You will discover, of course, that many (most?) creators would rather sell their own work and keep 100% of the profit, but it never hurts to ask.

Welcome to Second Life! Changing your avatar's appearance involves two sorts of skills. One is altering your avatar's body shape, including everything from your height and body fullness to the way the tip of your nose slants. The other set of skills involves adding textures to your avatar (like skin and some kinds of clothing) or attaching things to your avatar (like prim hair, shoes, jewelry, ...). There's quite a lot to learn, but it's mostly fun. The basics are all right here in this KnowledgeBase article >> http://community.secondlife.com/t5/English-Knowledge-Base/Editing-your-appearance/ta-p/700709. You can learn more about dealing with attachments here >> http://community.secondlife.com/t5/English-Knowledge-Base/Avatar-attachments/ta-p/700031 and you can learn how to create certain types of clothing here >> http://community.secondlife.com/t5/English-Knowledge-Base/Creating-clothing-and-tattoos/ta-p/700055. As soon as you start making friends, you'll find that everyone has favorite shopping areas to recommend and will be glad to help as you put your appearance lessons into practice. :smileyhappy:

I've been using that one for a couple of years, and it's pretty reliable. They only update a couple of times a week, randomly it seems, so your displayed map can be out of date briefly if you are doing a lot of building beween updates. Our sim map displays showed snow on the ground for the better part of a week after we changed terrain textures earlier this spring. With only that one minor drawback, I've never had any complaints about it. If you'd like to see how we're using this API in a "Click any spot for an LM" application, visit the reference desk right spang in the middle of the Info Island sim. We have three maps on the wall behind the desk. ETA: See http://wiki.secondlife.com/wiki/Map_API_Introduction for full documentation of the Map API.

In Phoenix, you can turn off group notices selectively, and you can turn off ALL group chats (with Preferences >> Phoenix >> Chat >> Disable ALL group chats), but you can't turn off just a selected group's chats. It's all or nothing.

As far as I know, those are the only two controls that you have unless you move to Phoenix, which doesn't have the annoying little yellow bubbles. :smileywink:

Ah, good point. Kinda kills the fun, doesn't it?

Why can't I ever find a tip jar when I need one? :smileytongue: Unless the tip jar is broken (or rigged), this shouldn't be possible. I can't even think of a way to rig a tip jar to take more than you agree to give it. Are you sure that your account is being debited twice, or are you just getting two "Thank you for the tip" notices?

So, something like this. In the master (sending) prim... integer gChan;integer gLisn;list gUUIDs;integer KILL = TRUE;default{ state_entry() { gChan = (integer)("0xF" + llGetSubString(llGetOwner(),0,6)); gLisn = llListen(gChan,"","",""); gUUIDs = []; } changed (integer change) { if(change & CHANGED_INVENTORY) { llResetScript(); } } touch_start(integer total_number) { llRegionSay(gChan, "Identify"); } listen(integer channel, string name, key id, string msg) { gUUIDs += [msg]; //Store the UUIDs llSetTimerEvent(15.0); } timer() { if (KILL) //The first time the timer triggers, signal panels to remove inventory { llRegionSay(gChan,"Update"); KILL = FALSE; } else //The second time, send new inventory { integer len = llGetListLength(gUUIDs); while(--len) { llGiveInventory((key)llList2String(gUUIDs,len), llGetInventoryName(INVENTORY_OBJECT,0)); } llSetTimerEvent(0.0); llListenRemove(gLisn); } }} And in each of the remote panels A (in the same sim, in this case).... integer gChan;default{ state_entry() { gChan = (integer)("0xF" + llGetSubString(llGetOwner(), 0,6)); llListen(gChan,"","",""); } listen(integer channel, string name, key id, string msg) { if (msg == "Identify") { llSleep(llFrand(5.0)); //delay a random amount so that all panels aren't yelling at once llRegionSay(gChan,(string)llGetKey()); // report your own UUID } else if (msg == "Update") { llRemoveInventory(llGetInventoryName(INVENTORY_OBJECT,0)); } } touch_start(integer num) { llRezAtRoot(llGetInventoryName(INVENTORY_OBJECT,0),llGetPos() + <2.0,0.0,0.0>*llGetRot(),ZERO_VECTOR,ZERO_ROTATION,1); }} You put a new object in the master prim and touch it. It calls out to the remote panels A and gets their UUIDs. The UUIDs stagger in over a 5 second period and load into a list. A short while after the last panel reports in, a timer tells all panels to remove the object in their inventory. After another decent delay, the master prim sends each panel A a copy of the new object. Or something like that.

Sorry, I'm still being dense. So... Panel A contains Object B. Touch it and B rezzes. Got that part. There are 100 panels like A, right? And you want to replace B with object C in each of them? If that's the task, I can't think of an easy way to do it unless the script in each of the 100 panels was written with updating in mind. If you were planning ahead, you could prepare for that task, for example, by telling each script to listen for a key command on a private channel and then if (msg == "Kill_B") { llRemoveInventory(INVENTORY_OBJECT,0); } then delay a decent period and send each panel A a new Object C. That's just a matter of knowing the UUID of each panel and using llGiveInventory. If you don't have a script like that in panel A to start, though, it's not going to be possible.

Thanks for posting over in the Scripting forum. I responded there. :smileyhappy:

I'm not sure just what you mean by "script overloading" but I can guess. You mean "How many scripts can I have on my avatar (in clothes, hair, HUDs ....) before I get in trouble with someone?" There's really no good answer. A good guideline, perhaps, is that you will do best with fewer than 50 scripts, for a total of something like 2 MB of memory. If you stay under those limits, you probably won't have much trouble with teleporting and most sim owners won't give you any grief. When there are too many people carrying a lot of scripts into a sim, especially Mono-compiled scripts, a sim's servers will start to slow down under the load. Several people bringing Mono-compiled scripts into the sim at once can make the sim stall for a few seconds, too, which is why we experience that "rubber band" effect sometimes. That's why people are getting concerned. There's absolutely nothing magic about those numbers, though. There are no SL-wide rules of any kind, and there's no way you're going to violate TOS by having even 100 times that many scripts. All that's going to happen is that you'll start having really bad lag and people are going to start saying nasty things to you.

Hehehe.. If you like 1.23, you'll love Phoenix. It's the same familiar UI but with a much better engine behind it. I never touch V2 myself.

Maybe you're right that a different viewer is the answer for you. Here's the full list of approved viewers, including the old 1.23 >> http://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers . If you use a different viewer, I'd suggest setting a different location for the cache files that you create with that viewer.

Right. Your inventory is stored on SL's servers. When you access items, you are referring to something that you can think of as a lookup table. That's what gets rebuilt when you clean cache and relog.

With a brand new installed viewer, it's an even bet that it's checked ON by default. (Besides, I'm out of ideas beyond that. :smileysad: )

Oh, crumb. Missed it by that much. Well, if that almost worked, then you probably did get very close to the solution. Perhaps you didn't actually remove all the SL files on your computer when you uninstalled it, and one of the remaining files was corrupted? Delete your cache files manually. When you log in, log in to Smith or Pooley and rebuild your inventory quietly. (Just open inventory, type an "A" in the box at the top and wait for it to rebuild completely.) And keep your fingers crossed.

Problems like that are almost always local, on your own computer. It looks as if you've tried many of the standard solutions already, but there's still hope. It just may take a while and some good luck. Take a look at http://wiki.phoenixviewer.com/doku.php?id=bake_fail to see a few more things to try. You didn't mention rebooting your modem and router, for instance. That can often clear the cobwebs out of a wonky connection. Also, if you are using any of the Norton Utilities, try disabling them at least long enough for a test. Norton software has been known to have conflicts with SL on some systems.

OK, so it's unlikely to be that single image. Try this..... Go to Preferences (CTRL + P), open the Graphics tab, and click the Hardware Options button. In the window that opens, UNcheck the box that says Enable OpenGL Vertex Buffer Objects. That setting has been known to cause some people problems with uploading images.

Ah.. If this just happened after having no problems for that long, then yes, it's unlikely to be your local network. A network can block applications that use excessive bandwidth, though. Colleges do it all the time. Under the circumstances, it sounds like it's more likely a problem with the new viewer.

Yes, SL should automatiucally downsize a huge image, but you never knoiw. It was worth a shot. 712 pixels is a strange dimension, so SL will redimension your work, but it's certainly not too big. So that's not your problem. On to Plan B. (Whatever that is.) Out of curiosity ..... Is this just a problem with one particular image, or all images? If it's just one, maybe that file is corrupted.

It could be that your local provider is blocking access. SL uses a lot of bandwidth. Some local networks (like campus IT networks or your local coffee shop) block applications that they predict will use a disproportionate share of local bandwidth and cause problems for other users. Try visiting a friend with a private network connection and see if the problem goes away.

Is it too big, perhaps? SL's servers are supposed to downsize any file that is oversized, but maybe they don't know that. If any dimension of your image is larger than 1024 pixels, try resizing it and try again.