Rolig Loon

There's no obvious keyboard shortcut like CTRL+Alt+Shift + 0 or CTRL+Alt+Shift+O that should do that. (See http://wiki.phoenixviewer.com/keyboard_shortcuts for a list of all possible shortcuts.) Instead of doing a total re-install -- which might be necessary but is more work --- try first just wiping your settings. If that doesn't work, then go ahead and do a clean re-install as Val suggested.

If this occurs, chance are good that the inventory cache is corrupt. Deleting it should solve the problem. Locate your cache folder. You will probably need to do this manually, if you are unable to log in. Use a file manager (like Windows Explorer for Windows system, Dolphin, or some such) to locate the cache folder. In its default location, the cache folder is hidden on most OSs. To find it, you will need to show hidden folders. Default cache locations are: Windows XP: C:\Documents and Settings\[uSERNAME]\Local Settings\Application Data\Firestorm Windows Vista: C:\Users\[uSERNAME]\AppData\Local\Firestorm Windows 7: C:\Users\[uSERNAME]\AppData\Local\Firestorm Mac: ~/Library/Caches/Firestorm linux: ~/.firestorm/cache NOTE: If you are using a viewer other than Firestorm, these pathnames will be slightly different, including the name of your viewer rather than "Firestorm". In this folder, locate the files named data.db2.x.* and index.db2.x.* (where * is a digit: 0, 1, 2, etc; you may have more than one of each type of file) Delete all files that match these two names. Log back into SL, to a quiet region (try Hippo Hollow, Aich or Hatton). Allow your inventory to repopulate fully. Do not do anything else in SL until the refershing is complete. If the above fails, then try doing a full wipe of all settings.

If you have a specific question about a part of the script that you are writing, post at least the part that's giving you trouble and ask about it. Someone will always offer suggestions. If you want to hire a scripter to modify your script, though, it's better to ask in the Inworld Employment forum.

Everything you want to know is right here >>> http://wiki.secondlife.com/wiki/LLS_How_to_submit_a_Support_Ticket. Well, almost everything. Basic accounts like yours and mine don't have access to all of the support categories that Premium accounts do. Take a look at what you can ask about >>> http://wiki.secondlife.com/wiki/Types_of_Support_Case If you don't find what you want, come back here and ask us. We might not always know the answer, but we try hard and we're friendly. :smileyhappy:

That TOS box has had occasional problems for a couple of years at least. It sometimes takes a very long time to connect properly so that the Accept button isn't grayed out --- two or three minutes. Our normal advice is to download and install a different viewer and acccept the TOS with it. Once you've done that, you can go back to the veiwer you were using before. Since you don't have to log in to get the TOS screen, I think that method should still work for you, even if your computer won't let you go in world with the other viewer. Give it a try.

Sorry. I just got home. The answer to your immediate question is that the neither script needs to know the name of the other one. All you really need to do is communicate between them on a channel that only those two scripts use. So, the basics ..... Your HUD script is like a light switch. If it's ON when you click it, it turns OFF. If it's OFF, turn it ON. Whichever one it does, it has to tell the particle script. That's it. The whole thing. integer gON; // This is the state of your switch, =TRUE if ON, =FALSE if OFF.default{ touch_start(integer num) { gON = !gON; // This is the switch itself. Reverse the sense of gON. llSay(-1234567, (string)gON); // And here you are telling anyone listening on channel -1234567 the value of gON }} On the other end, you already have the particle script. All you need to do is tell it to listen on channel -1234567. The bare bones have to look like this.... default{ state_entry() { llListen(-1234567,"","",""); // Listen to anybody saying anything on channel -1234567 } listen (integer channel, string name, key id, string msg) { if(msg == "1") // That is, if the message from the HUD was TRUE ( = "1").... { //Turn on the particles. This is where the stuff you already have goes. } else if (msg == "0") // That is, if the message from the HUD was FALSE ( = "0") .... { llParticleSystem([]); // Turn the particles OFF } }} You can make it harder by adding safeguards and filters or making it change colors and ring bells. You can also do sim-friendly things like turning off the listener when it's not being used. All of those are good ideas, but the basic logic is just what I laid out. Don't get fixated on the syntax. You can always figure that out by looking in the LSL wiki. The logic is what counts, and the logic here is no harder than wiring a light switch for a table lamp. Good luck with it.

You will have to put the particle script into the cone and then speak to it with a script in your HUD. Neither script i very difficult. I assume that you already have the particle script, so all you need to do is add a listen event that turns it on or off, depending on the magic word from the HUD, and then open a channel (preferably a high negative channel) . See llListen. The HUD script only needs a touch_start event in which you place a llSay statement with an if test that sends the magic word to trigger the particle script.on or off. If the HUD script uses the same channel as the particle script, you're all set.

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.