Innula Zenovka

Be warned, though, that face numbering changes if you cut the prim. There's a (rather complicated) explanation of how it all works at http://wiki.secondlife.com/wiki/Face plus a handy keyboard shortcut. In V2, enable the Develop menu (if you haven't already done so) with CTRL-ALT-Q. In V1, enable the Advanced menu with CTRL-ALT-D. Then select the face in which you're interested with the select texture tool and press CTRL-ALT-SHIFT-T, and it tells you, in local chat, what the face number is. Another caveat, which I learned the hard way -- the side numbering script resets the prim's texture repeats and offsets rather drastically. Not a big deal, but you get a shock when you put another texture on, particularly if you've spent ages adjusting them and didn't make a note.

I don't understand what you mean by the question. Can you be a bit more specific about what you're trying to do?

Ansariel Hiller wrote: Innula Zenovka wrote: Ansariel Hiller wrote: The problem is caused by avatar physics and it's not only Phoenix affected but all version 1.x based viewers that are unfixed - even the official LL viewer 1.23.5. It appears that only Phoenix is affected because the majority of people use that viewer (> 40%). BTW: A fixed version of Phoenix is planned to be available today. Beside the fix it will also contain the avatar physics feature of Viewer 2. I know there's an issue with avatar physics and older viewers generally, but are you saying that Phoenix users see people as Ruth if they've not loaded properly because of avatar physics and as a particle cloud if there's another reason for their not having properly loaded? If RenderUnloadedAvatars is disabled, you will see avatars having general problems loading avatar data as cloud, avatars with physics as ruth. As for physics all avatar data is correctly downloaded to your viewer, but processing the shape data just stops because the physics parameters are unknown. The most easy fix is to just skip unknown parameters, but LL originally errored out, so even known parameters that might follow physics parameter are omitted. That results in ending up as Ruth. If you have RenderUnloadedAvatars set to enabled, you can't say directly what the problem is. But another weird side effect of avatar physics is that avatars might first load with a female looking shape and suddenly transform into the correct shape. So, am I correct in thinking that someone using today's update of Phoenix who has RenderUnloadedAvatars set to TRUE will continue to see avatars whose data hasn't properly loaded as Ruth, in circumstances when someone using the same viewer who's got it set to FALSE will see them as a particle cloud?

Ansariel Hiller wrote: The problem is caused by avatar physics and it's not only Phoenix affected but all version 1.x based viewers that are unfixed - even the official LL viewer 1.23.5. It appears that only Phoenix is affected because the majority of people use that viewer (> 40%). BTW: A fixed version of Phoenix is planned to be available today. Beside the fix it will also contain the avatar physics feature of Viewer 2. I know there's an issue with avatar physics and older viewers generally, but are you saying that Phoenix users see people as Ruth if they've not loaded properly because of avatar physics and as a particle cloud if there's another reason for their not having properly loaded?

As I understand it, you see Ruth rather than a particle cloud if you have RenderUnloadedAvatar set to true in debug settings. I've often seen changing this setting, which, as I recall, is easily accessible in the Phoenix preferences panel, offered as a suggestion in the Phoenix support group in world when people complain the world is taking too long to load. So that might give us an indication where the problem is.

Marine's example shows you the method, though. You get the global (i.e.. position on the grid) coordinates of the sim with llRequestSimulatorData("sim name",[DATA_SIM_POS]). When the dataserver replies, it gives you the position on the grid of the Sim's SW corner. You break down the reply in exactly the way she does it there, into the x, y and z coordinates, and then add to those, the coordinates on the sim you need -- in your example, <40.0,40.0,2000.0>, as she does in that example, and turn them into a string for the teleporter to say. Any lag is almost certainly caused by the delay in the dataserver responding and the script processing all this. But you can avoid that, since you know your destination(s) beforehand, by using the method Marine demonstrates there to build a list of the coordinates in which you're interested when the script first starts running. The sims aren't going to move, after all, so there's absolutely no need to recalculate the target position every time you use the device. Then when I come along and set off your teleporter, the thing knows what it's supposed to say, and the only delay in teleporting me is going to be if my relay is set to ask me before accepting commands from strange objects and I take a few seconds to agree.

Builders Brewery do some very good classes -- about an hour, in text -- on how to use Snap To Grid. I went to one the other day, to remind myself how to do it, and was very impressed. I find it a lot easier to use than the TPV align tool Void mentions.

default{ state_entry() { llSay(0, "Thanks, Void and Cerise"); }}

Sorry, I'm confused. I've updated Blue Goo in both Chrome and Firefox 4. Sample scripts produced in both LSLEditor and Notepad++ look OK when I copy paste them and press the +LSL button but when I click Preview it seems (both visually and from the HTML) to take out all the tabs and carriage returns/line feeds. And when I copy paste the results back to either editor, I just have one long line of code. Have I missed out a crucial step somewhere?

I've not tested it, but something on these lines might do it. The idea is that llGetObjectPrimCount(llGetKey()) will return the number of prims in the linkset -- assuming it's in the root prim, otherwise I guess you need llGetObjectPrimCount(llGetLinkKey(1)) -- while llGetNumberOfPrims() is prims plus seated avatars. Worth a try, anyway. key av; default { state_entry() { llSitTarget(<0.0,0.0,0.5>,ZERO_ROTATION); } changed(integer change) { if(change & CHANGED_LINK){ av = llAvatarOnSitTarget(); if(av!=NULL_KEY){ if(llGetNumberOfPrims()>(llGetObjectPrimCount(llGetKey()) + 1)){ llUnSit(av); } } } } } ETA -- dunno what's happening with the editor

Thanks. that may explain it.. I've just changed the permissions in Windows 7 to make sure the viewer can write stuff to disk, but it's making no difference. I will try doing a clean re-install and see if that helps.

Oh. I wonder if it's to do with using a StarLight skin... are you using the default viewer?

That's what I have been doing, Peewee... it should work and it used to in SnowGlobe but the setting just doesn't seem to want to persist across log-ins in V2, which rather breaks it. I will take a look in the jira and see if that brings any enlightenment.

You can't copyright ideas, either in RL or SL. You might be able to patent a process, but I think you would need a patent lawyer's advice on the subject, and I'd be rather surprised if any scripted process you could make work in SL was, in fact, patentable.

As far as I can remember from SnowGlobe, you used to be able to change the default texture for prims by putting in the appropriate UUID in Debug Settings -- DefaultObjectTexture and relogging. Then after you'd done that, while prims still rezzed as plywood, you could change them to your preferred default texture by going to the texture picker, clicking blank, and then clicking default again. I can't, though, get this to work in 2.6.8 -- the value for DefaultObjectTexture just reverts back to the default plywood,"89556747-24cb-43ed-920b-47caed15465f", each time I relog. Am I doing it wrong or is it broken? I've not tried doing it before in V2.

Yes, I understand. But I am asking if you get this message everywhere, or just on one sim. There are several different reasons you might be getting this message, and if you can tell me if you get it everywhere you go, or if you only get it on one sim, then that will help me to know what the most likely reason is.

According to the KB article you can use pretty much any unicode alpha-numerical character you want (whether other people's viewers can display them depends, of course, on what they happen to have loaded in their computer) plus a limited range of punctuation characters, which the article lists.

Your post has no content. If you are using IE 9, you need to enable compatibility mode to post in this forum (click on the icon that looks like a torn piece of paper). Or use Chrome or Firefox or something other than IE 9.

The line is as I posted it -- llGetParcelDetails(llGetPos(),[PARCEL_DETAILS_NAME]); Note the [ square brackets ] round [PARCEL_DETAILS_NAME]. They are there because lsl uses them to enclose lists, and, as you will see if you look more closely at the wiki article, llGetParcelDetails requests a list of details about the parcel -- you're using it to request a list with only one item, but you could just as easily be asking for details of the description, owner, size, and stuff at the same time, so the request has to be presented as a list, and lsl knows something's a list if it's enclosed in square brackets. Since you've asked for a list of details about the parcel, you get a list in reply, albeit one with just one item, so you will need to decode the list, using the format llList2String(my_list,0); That means "find the first item in the list (lsl starts counting at 0, not 1) and turn it into a string so you can say it, or display in hovertext or whatever. Tl;dr -- you need the [ ] round PARCEL_DETAILS_NAME or it won't compile, and you need to turn the results of the call into a string so the script can do something with the parcel name when it knows what it is.

The syntax is llGetParcelDetails(vector pos, list params); So something like this should do the trick. default{ state_entry() { //llSay(0, "Hello, Avatar!"); } touch_start(integer total_number) { llOwnerSay(llList2String(llGetParcelDetails(llGetPos(),[PARCEL_DETAILS_NAME]),0)); }} ETA -- what this means is that llGetParcelDetails takes two arguments -- the vector location of the parcel whose details you want and a list of the various possible details you want it to tell you. It returns a list of what those details are -- it has to be a list, because you might be asking for the parcel description, or its owner or area or whatever as part of the same call. In this example, you're only asking for the description, which is a string and is the first (and only) item in the list that's returned, so you change it into a usable string with llList2String(list, 0) -- "find the first item in the list and return it as a string".

Another way to do it would be to turn the listener on and off each time you wear it. This way, though, it's only going to listen to you when it's worn: integer g_intListenHandle;default{ state_entry() { updateParticles(); } attach(key attached) { if (attached!=NULL_KEY){ g_intListenHandle=llListen(5,"",attached,""); } else{ llListenRemove(g_intListenHandle); } } listen(integer channel,string name,key id,string message) { if(message=="fall on") updateParticles(); else if(message=="fall off") llParticleSystem([]); else llOwnerSay("usage:\n/5 fall off\nor:\n/5 fall on"); }}

Are you getting this annoying message everywhere, or only on one particular sim? Try TP-ing somewhere else and see if that stops it. Then TP back to where you were before and see if it starts again. You see, one reason you'd get this message is if you rezzed the item rather than wore it as a hud or attachment (and when you say it's not appearing in your inventory, that makes me wonder if you rezzed a no-copy item). The only fix, if that is the case, is to try to find the item, take it back into your inventory and wear it. If you are on a private island, the owner or someone with estate rights should be able to locate it for you, and return it, using the estate management tools. I don't know how it works on the Mainland, though.

As Blackdog suggests, it sounds like you need to update the listener to listen to the new owner (I'm assuming, since it's a dress, only the wearer can talk to it). Try dropping this changed event into your script -- there are more elegant ways of doing it, but without seeing the script, this is all I can suggest that I know will do it. changed(integer change){ if(change & CHANGED_OWNER){ llResetScript(); } }

When I had two adjacent islands, I sometimes used Ezian Ecksol's Camjumper script to get between the two of them. That goes in an attachment, finds your destination by where your camera is, and then calls llMoveToTarget repeatedly to move you there very fast -- so fast that you normally blast through apparently solid objects with ease. I don't know, but I'm wondering if the same method wouldn't get you from sim to sim if you sat on something that used it. I know warppos looks as if it should, but doesn't do it at all reliably, so I'm not sure how well the physical equivalent would do. Though, as I say, when called from an attachment it always worked well for me.

I've just copy-pasted your code into a touch_start event and it works fine. As the others say, it must be some other cause.