Rolig Loon

The first thing to do is file an abuse report. That thing is definitely annoying, but it's not hurting you, so you have time to do it. Select the red ball with your Build/Edit tool and find out who owns it. While that window is open on your screen, go to Help >> Report Abuse and fill out the report in as much detail as you can. The system should take a screen shot that will show the red ball, the particles, and your open Edit window with the owner's name in it. THEN, suppress the particles so you can see what's going on. Type CTRL+Alt+Shift+ = . That will toggle particles off in your viewer. (Particles won't accumulate, BTW. They disappear after a while.) It will also potentially make it easier to see the red ball clearly enough to select it and delete or return it. If you are wearing the object, you won't be able to delete it without detaching or dropping it first, so go to your Inventory's WORN tab and see if that's what's going on. If it's not worn, then it's a scripted follower, which means that it can't follow you through a teleport. If you TP across a sim border, you should be able to look back and see the thing, stopped dead and waiting for you to come back. If you don't have manager powers on the sim, ask the sim's owner to find the object in Top Scripts and reurn it for you.

Nope. The only way to find out is to ask the landowner, and s/he doesn't have to tell you. The landowner doesn't even have to have a reason. It's private property. A SL landowner gets to ban anyone at any time. Just like RL.

Start with the basic SL eyeball mesh OBJ >>> http://www.ccccybernetics.com/avatar_databank/eye.php and add texture. Google is definittely your friend if you want to find tutorials ( like http://www.vintfalken.com/eye-texture-orientation/ ), but if you have any Photoshop skills, you can probably texture something as simple as an eyeball without too much guidance.

That's odd, Tam. It's right there >>> https://my.secondlife.com/HoneyPie43. BTW, unless you really love getting spam e-mail, it would be smart to remove your e-mail address from this thread. This is a public site, after all. :smileysurprised: :smileywink:

I assume that you have copy perms on the table, so simply delete it and rez a new one where you want it. My guess is that the script in the table remembers where it was rezzed and uses that spot as a reference for where to rez tiles as needed. So long as the table's script is active and you haven't been able to reset that initial position, it will keep rezzing a new "starter" tile there every time it senses that the spot is empty. As an alternative to deleting and re-rezzing, you might try moving the table to its new home location and then resetting the script (Build >>> Scripts >>> Reset scripts in selection), if that option is available.

Indio Quinnell wrote: Well, yes and no... You could do sound by uploading the sound file, then have the script start playing the sound at the same time it triggers the animation... but again, I don't think the technique will work for a 2-minute video, as there's a maximum limit of 10 seconds on sound files (there are ways to work around this, by having the script actively queue up and play multiple files in sequence, but it gets complicated), and lip-synch won't be even remotely guaranteed. You could, in theory, do the same thing by having multiple image sequence-mosaic files, and having the script switch the texture face from one to the next when it reaches the last frame/tile in the sequence... but this, too, would get complicated. Plus, pre-loading two minutes' worth of sound and image files would be a significant burden on the player's viewer, and you can't necessarily guarantee that everything will pre-load before your script starts trying to play them. In the end, I'm afraid that what you're trying to do simply isn't possible, or practical, within the limits of the SL system. You're quite right. In order to get 10-second sound clips to flow smoothly from one to the next, you need to be sure that they are exactly the same length (or at least all have known exact lengths), and you have to preload each clip individually before it is played. You can't just save a stack of preloaded sound clips. You have to preload one, play it while you preload the next, and so on. In the best of all possible cases, you can piece together very long selections seamlessly if you are very careful. Unfortunately, I have never seen the best case. Lag invariably messes up timing, so that you get skips and dead spots. Trying to sync a perfect sound file with a video would be hard enough. When you add in the complications of a normal day in SL, it's hopeless. If you weren't concerned with having a transparent packground, the best solution would be to host your video with sound on a streaming server somewhere and then simply show it on a prim in SL, using MOAP. All the problems of gluing sound clips togetther and syncing them with the video would vanish, and your video could be as long as you want. Unfortunately, your alpha requirement makes this option impossible, though, because there's no way to preserve the transparency that you might have in your original images (even if you could figure out how to do that part) once they are streamed to SL.

Bonne nuit!

I don't do twitface either, but it looks like Val's right. Just go to https://my.secondlife.com/settings/profile and click the selection marked Social Identities to add the appropriate address. That should do it.

Follow Val's excellent advice See the full list of possibilities here >>> http://wiki.phoenixviewer.com/doku.php?id=fs_bake_fail . Start with the simple things at the top of the list and work down until you find what works for you today. You may find that the bake fail problem comes back repeatedly, even after you fix it with one of the suggestions on that wiki page. If so, you have a chronically weak Internet connection. It may be good enough for doing simple things like e-mail and web browsing, or even playing a game like WoW, but it's not stable enough or strong enough for Second Life. There are many steps to take for repairing it. Perhaps the simplest ones -- ones that work best for most people -- are: (1) Don't Use WIRELESS. Wireless connections are inherently less stable than direct cable connections and are more vulnerable to interference. Then, (2) Reboot your router. Unplug it from the power for a few minutes to let it clear its RAM. The plug it back in and let it get a fresh hold on an IP address. --||-

See whether you can upload photos if you go to another sim. The servers on the sim where you are standing right now may be malfunctioning.

Yes, if your four screens are linked as a single object it especially easy. All you'd need to write would be a quick routine to accept a texture that is dropped into the object, delete whatever texture was already in inventory, and display the new one on whatever faces you designate. You could certainly make it fancier than that, but it your goal is simply to be able to drop a texture on one prim and have it show up on thre others, that's it.

Have you tried logging in to a different location? Try a nice low-lag spot like Smith or Pooley. If you can log in there, then try to TP to someplace else.

Thank you for posting the additional information about your system. I'm sorry that I didn't see it until just now. Your mention of "side-by-side configuration" is the key here. We've seen this same error a few times before, as you'll see if you dig through the forum archives, and it always seems to point to a damaged dll file on the OP's computer. I think you'll find the soluion in Karen's insightful response to a very similar thread earlier this summer >>> http://community.secondlife.com/t5/Technical/the-application-has-failed-to-start-because-its-side-by-side/qaq-p/1567179 . Give it a try and then please post back here to let us know how it worked.

Gee, I thought I was the only one, Innula. I had my external editor cued up in Firestorm and finally shut the thing off because it was so annoying. I tend to create a script either entirely in world or (less often) entirely in an external editor. Hopping between the two makes a hash out of my work and is just frustrating. I do see value in a preprocessor, although I don't use one myself. I find it quite easy to simply cut and paste from my file of handy code snippets. My enthusiasm for the Firestorm upgrade was fired mostly by going down the long list of other features and bug repairs that it includes, all of which are going to take a while to explore.

IMs expire after 31 days, but notecards do not, AFAIK. That means that theoretically your "in box" could slowly load up with notecards until it reaches the 25 cap, and they would never clear (unlike the IMs, which would gradually clear).

The TP script, as Tabriz says earlier in this thread, is nothing fancier than WarpPos. Now that we have llSetRegionPos, I'd use that instead. And the format of the notecard is pretty simple. It's a comma delimited single line, read in the dataserver event. You can see the format in this bit of code in the listen event .... if (llList2String(tmp,0) == "whereto") { list addytmp = llCSV2List(addydata); //addydata is the line on the notecard dest = llList2String(addytmp,0); addy = llList2Key(addytmp,1); llRegionSayTo(addy,-666,"change"); llWhisper(startparam,"goto,"+dest); } addy is the UUID of the target prim and dest is the destination vector.

Lovely, phaedra! Thanks for the heads up. There is a raft of cool stuff in that upgrade. /me runs off to install and start playing.......

Here's Void's version, posted in the LSL wiki at http://wiki.secondlife.com/wiki/LlGetGMTclock //--// GMT function with local offsets in 12hr format //--// integer gIntMinute = 60; //-- 1 minute in secondsinteger gIntHour = 3600; //-- 1 hour in secondsinteger gInt12Hr = 43200; //-- 12hrs in secondsinteger gIntDay = 86400; //-- 1 day in seconds string fStrGMTwOffset( integer vIntLocalOffset ){ //-- get the correct time in seconds for the given offset integer vIntBaseTime = ((integer)llGetGMTclock() + gIntDay + vIntLocalOffset * gIntHour) % gIntDay; string vStrReturn; //-- store morning or night and reduce to 12hour format if needed if (vIntBaseTime < gInt12Hr){ vStrReturn = " AM"; }else{ vStrReturn = " PM"; vIntBaseTime = vIntBaseTime % gInt12Hr; } //-- get and format minutes integer vIntMinutes = (vIntBaseTime % gIntHour) / gIntMinute; vStrReturn = (string)vIntMinutes + vStrReturn; if (10 > vIntMinutes){ vStrReturn = "0" + vStrReturn; } //-- add in the correct hour, force 0 to 12 if (vIntBaseTime < gIntHour){ vStrReturn = "12:" + vStrReturn; }else{ vStrReturn = (string)(vIntBaseTime / gIntHour) + ":" + vStrReturn; } return vStrReturn;} default{ touch_start( integer vIntTouched ){ //-- '-5' is EST, no adjustment for DST llSay( 0, "The time is now " + fStrGMTwOffset( -5 ) ); }} All I did was put in the GMT -5 offset for EST.

A possible way out is to use a function like this one StopAnims(){ list anims = llGetAnimationList(llAvatarOnSitTarget()); integer i = (anims !=[]); while (i) { llStopAnimation(llList2Key(anims, --i); }} It won't touch an animation that keeps being re-triggered by your AO, but it cleans out most background anims that you may have been unaware of.

I have never thought of a good reason for using that option, but I know it was there for a long time. I guess it's not any more. When you think about it, a landmark is handy but it's hardly necessary. Unless a sim or parcel has been locked down to prohibit access, anyone can TP there by typing target information into their Map view or typing a SLURL into chat. A LM is just an electronic sticky note that saves you the trouble of typing that information in each time.

Bummer, Charolotte. Guess it's time to ditch Marketplace and hit the in-world shops.

Wolfen Greggan wrote: [ ... ] Could it have something to do with the upgrades the Lindens are doing? Your guess is as good as mine, but I wouldn't be too surprised. I have been having trouble with a couple of trusty movement scripts for the past few days and have just put it down to bad karma in the servers.

How are your doors scripted? If you are using a script that handles rotation with llTargetOmega (like the Smooth Rotating Door script in the LSL wiki) or if you are using llSetKeyframedMotion to do it, the door only appears to move until the rotation is complete. All apparent rotation is in the client. The servers don't get the door out of the way while that's going on, so you'll bump into it if you try to walk through. If the sim is laggy, the servers may take longer than usual to do their part.

Check to be sure that you don't have a second program handling music. If you already have a streaming audio player queued up on your computer, you may be triggering it with the same pulse that turns on the stream in your viewer.

Ooop. Found out.