Innula Zenovka

What I'm saying is that the issues you describe could very well be caused by your once having accidentally rezzed a copy of the item from your inventory, or that you accidentally dropped it rather than detaching it. If there's a rezzed copy of the object, that belongs to you, sitting in world, and the script doesn't allow for the object containing it being rezzed but not attached to anyone (and if it's one of the popular free "drinking animation" scripts it almost certainly doesn't) then you will get keep on getting these error messages. That's why it's important to try to track down the location of the particular rezzed object -- so you can either take it back into your inventory or delete it.

Is it travelling round with you, or is it confined to one particular sim (probably where your home is)? What you describe is frequently caused by an attachment that's been rezzed on the ground (or dropped) and which hasn't been scripted to make sure it's attached to its owner before asking for permission to animate you. But it's only going to do that while you're on the same sim. If it is confined to the one sim, you're going to have to search for the offending item, I fear -- I think the script error window should give you the coordinates of the object containing the script that's throwing errors, but I'm not in world to check that.

Any indication when the fix for http://jira.secondlife.com/browse/SCR-66 ("llRegionSayTo() Fails to send messages to attachments on sitting avatars") is likely to be deployed? I'm trying to decide whether to hold off releasing some new products that use it, or put them out using llRegionSay() and send out an update later. I'd like to send them out, but if I'm going to have to update them in in the next week or so, I'll wait.

Maybe an example will help. vector sim_pos;vector local_pos;vector target_pos;string to_say;default{ state_entry() { sim_pos = llGetRegionCorner(); // grid co-ordinates of the SW corner of the sim I'm on llOwnerSay((string)sim_pos); local_pos = <148.0,42.0,22.0>; // target position on the sim -- change this, unless you're i) on the Freedonia sim and ii) want to visit my shop target_pos = sim_pos+local_pos; to_say = (string)((integer)target_pos.x)+"/"+(string)((integer)target_pos.y)+"/"+(string)((integer)target_pos.z); llOwnerSay(to_say); } touch_start(integer total_number) { //whoosh! llOwnerSay("@tpto:"+to_say+"=force"); //only works if the owner uses rlv, obviously }} Note, though, that I could use this to get the global coordinates of my shop and then use them anywhere on the grid.

Void Singer wrote: I seem to be confused.... what's wrong with llGetRegionCorner? Nothing, so long as you're in the region in whose coordinates you're interested when you call it. But the OP wants, I think, to calculate the target coordinates at run-time and can't rely on being in the same region as the target when it's necessary to do the calculation.

It's not ideal, but if you need to grab some information about the user before he or she pays you, you can ask customers to touch the object to activate the vendor and then, in the touch_end event (touch_start and state changes don't play nicely), grab the information you need and switch to state payable, which sets the default touch action to pay in state entry. Then go back to state default after you've been paid (or after a timer goes off).

money Crannock wrote: Thanks for the explination, the problem is that I was using <40,40,2000> as an example, the position changes everytime its used though, so it will lag. I guess if there's no way to get around it, I'l try another way of doing it. I'm afraid that if you need to find the sim's grid location, the only way to do it -- at least the only way I know -- is to call llRequestSimulatorData. You could trying storing the coordinates -- or, rather, the string @tpto is to use -- for specific locations when you look them up, I guess, and then, when you tell it you want to go somewhere, first have the script look in the list to see if it's a location it already knows. If it is, then use the appropriate string, and if not, ask the dataserver where to go. My Dari's Haus collar stores locations I use frequently, and I never seem to need more than 10 or so. That might be an idea to explore.

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.