Innula Zenovka

Try cleaning up your data before processing it, thus, and see if it helps: if(data != EOF){ data = llStringTrim(data,STRING_TRIM);//chop off leading and trailing spaces if(data!="" && llGetSubString(data,0,1)!="//"){//if there's still anything left and it's not a comment //process it }} It can't hurt, and at least it would rule out one cause.

default{ state_entry(){ llSay(0,"Wow, thanks Cerise!"); } } Yay! So easy. Thank you so much.

That's what I thought. When I raised the question in the SLU thread, it was because I was making something that uses llTextBox and was a bit nervous that some people might not be able to use it. Admittedly the device I was making also uses RLV, so that meant I only needed to worry about TPVs, but certainly we've had no complaints from people who can't use llTextBox, as yet.

I don't think there's any way with LSL to control viewer settings, though I'm open to correction. The only way I know in most cases for scripted objects to control your viewer settings -- as opposed to the behaviour of what's effectively an in-world object normally controlled from your viewer, like your camera -- is to use a specially compiled viewer (like RLV, which won't be any help here) with an API you can access with LSL functions such as llOwnerSay().

Depending on who's using the item, you might also consider using not llWhisper but either llOwnerSay(float_text) or llInstantMessage(id, float_text).

The only "God Mode" of which I've ever heard in SL is http://wiki.secondlife.com/wiki/God_Mode. No, your collar can't give you powers reserved for LL employees, if that's what you are asking!

Can anyone think of a TPV that doesn't support llTextBox()? Cool VL, Dolphin, Phoenix and Singularity all do, as far as I know, and I think Imprudence does, too. ETA We had a chat about this a while ago in another place, and no one could think of a viewer in reasonably common use that doesn't support it.

Sorry. I was misled by the reference to RLV -- all you can do with RLV is block IMs completely (though you can set exceptions, so some people can still IM you) and (I think, if you know which bit of xml to tweak) send a custom message. But blocked IMs are discarded, I'm afraid. So if you want somethng like Phoenix's autoresponder, I'm afraid RLV isn't going to offer any solutions. I'm wondering if Singularity or Imprudence have a feature similar to Phoenix's autoresponder and, if they do, if they would run on your machine.

The RLV part of it is easy. You don't need a relay to use RLV commands on yourself -- you just need an object or an attachment that belongs to you that can issue the appropriate llOwnerSay commands. Something like this, worn as a hud, will turn your IMs on and off for you, I think: integer toggle;//turns IMs on automatically when attached/detached or on_rezdefault{ attach(key id){ llOwnerSay("@clear"); toggle = FALSE; } on_rez(integer p){ llOwnerSay("@clear"); toggle = FALSE; } touch_end(integer n){ toggle = !toggle; if(toggle){ llOwnerSay("@recvim=n"); } else{ llOwnerSay("@recvim=y"); } }} However, the autoreply message people receive when they try to send you an IM is a very different kettle of fish, because that's sent by the viewer. I've got an idea you can edit the viewer's xml files to set your own autoreply -- I think I saw something in a blog once about how to do it -- but I could well be mistaken. All I can suggest is getting in touch with Marine or Kitty to ask for their advice about what -- if anything -- you need to alter to set your own default message.

Depends where your friend is based, but if she's in England or Wales she's guilty of fraud by false representation, contrary to the Fraud Act 2006. I would imagine most other places have similar legislation.

There's an invite-only (to ward off spammers) group in-world, For Sale By Owner, which is primarily for people who want to buy and sell full sims. I've always used that group, and have been quite content with the results.

Thanks. I had had a look in the forum but will search through the server release notes. I wish I could remember the details of what I was told; it was back in the old forums late last year, and I mentioned 4.0 as the maximum and someone -- I can't remember who, but it was certainly someone who usually knows what they're talking about when it comes to viewers and server releases -- corrected me, saying it had just recently changed.

Yes, I know a lot of people do. But I'm wondering if, in fact, there is now any difference between 3.0 and 4.0 or if it maxes out at 3.0. Dolphin 2 certainly won't let you set it higher than 3.0.

What's the highest you can effectively set renderVolumeLOD to? I thought I'd read somewhere that a recent-ish change to the server software now maxes it out at 3.0, so the usual advice to set it to 4.0 to make sculpties look better is now outdated, but I can't find a reference anywhere. Can anyone help?

I don't know, but I would imagine it's done by rezzing a small invisible follower that floats above your head and displays a title with llSetText. And, as Peewee says, if you just tp to another sim, it can't follow you and it should, if the scripter is at all competent, delete itself shortly after you leave the sim and it can't find you any more.

Yeah, but isn't it the same issue? If the sim can't tell, if I'm offline, whether or not an object is allowed take advantage of my group abilities to rez things on my behalf, it's not going to know whether it can use my similiar abilities to run scripts either. That's what I meant -- sounds to me like another manfestation of the same thing.

It's quite a long-standing issue, and I rather suspect that some accounts that were initially affected were also so unfortunate as to be missed in the two big updates mentioned in the jira, too, so no one knows to include them in any of the weekly updates unless asked to.

Try clearing your cache manually, rather then simply pressing the "clear cache" button, by following the steps outlined at https://wiki.secondlife.com/wiki/Clear_Cache (or you could simply create a new cache location in "Preferences", which has the identical effect). Then relog somewhere quiet and give your inventory time to reload from the server, rather than your pc, which can take several minutes. If you're using several different viewers, it's a really good idea to set a separate cache location for each one. And certainly having any V2-based viewer trying to share a 1.n viewer cache is a recipe for disaster. I switch between viewers all the time, testing scripted content I'm making, to see that it works right in all viewers, and I used to have half my inventory missing most of the time until I discovered the necessity of having separate caches.

I agree with Rolig. I think this is a permissions issue, https://jira.secondlife.com/browse/SVC-3145, "group ROLE permissions only work for scripted rez when owner online (was rez objects only works if i'm online)". This is real pain in the neck for those of us who make furniture using systems like MLPV2 that need to rez things. ETA It's been reopened as a new feature request, https://jira.secondlife.com/browse/SVC-6686, "parcel build permissions needs whitelist".

Glad we've identified the probable cause of your friend's issue. According to Brooke Linden's comment, they seem to do the manual updates on Tuesdays, or they used to, so it might be worth waiting til Wednesday to see what happens, but as to your question, Lindens have email addresses in the format firstname@lindenlab.com and I've always found that emails to the appropriate Linden seem to get actioned more reliably than do notecards and IMs, particularly if they're short and to the point. ETA -- I just tried clicking on the link in my post, and had difficulties reaching the jira entry, too. Try going to the jira's main start page and typing WEB-3126 into the search box.

Is it a very new account? There's a long-standing bug, https://jira.secondlife.com/browse/WEB-3126 , that's got everyone baffled, but they work round it -- it seems -- by running a manual update every Tuesday, though it seems from some of the comments that people still get missed. Can't hurt to drop a line to Brooke Linden, I guess, if your friend continues to have difficulties. EDITED April 14 to fix broken link to jira.. sorry.

Eep.. you are right, of course, Qie... sorry about that. I had tested it but the way I had linked it, the error was not apparent. I always seem to get that wrong. I will fix it in the example. ETA Are you sure it should be i = max -1 ? The only way I can get it to work decrementing it is if I set i=max: list prims_to_change;string change_me = "change me";list glow_on = [PRIM_GLOW,ALL_SIDES,0.05];// could change colour, texture and whatever here, toolist glow_off = [PRIM_GLOW,ALL_SIDES,0.0];list params;float alpha;integer toggle;integer i;integer max;find_prims() { prims_to_change=[]; //clear the list i=1; max = llGetNumberOfPrims(); do{ string s = llToLower((string) llGetLinkPrimitiveParams(i,[PRIM_DESC]));//get the description of each prim if(s==change_me){ //if the target name matches prims_to_change +=[i]; //add the number to the list // llOwnerSay((string)i); } //else if the description is something else, add it to another list if appropriate } while (++i<max);}default{ state_entry(){ find_prims(); max = llGetListLength(prims_to_change); } changed(integer change){ if(change & CHANGED_LINK){ find_prims(); max = llGetListLength(prims_to_change); } } touch_start(integer num){ toggle =!toggle; // llOwnerSay((string)prims_to_change); i= max; if(toggle){ params = glow_on; alpha = 0.5; } else{ params = glow_off; alpha = 1.0; } while(i--) { // llOwnerSay((string)i); // llOwnerSay((string)llList2Integer(prims_to_change,i)); llSetLinkPrimitiveParamsFast(llList2Integer(prims_to_change,i),params); llSetLinkAlpha(llList2Integer(prims_to_change,i),alpha,ALL_SIDES); } } }

To expand on Darkie's comment, one of the annoyances about llGet and llSetLinkPrimitiveParams is that the alpha value is part of the PRIM_COLOR flag, so while you can set the individual prims' alpha values as part of the llSetLinkPrimitiveParams call, in practice, if you do it that way, you have to check on the colour of each prim (which is possibly different for each face of the prim) and reset that, even though it may not be changing, at the same time you change the alpha value. So, in practice, it's usually far simpler (and not much slower) to set the alpha separately with llSetLinkAlpha, which leaves the colour alone.

I don't think you want to be putting slave scripts in link prims, at least not now we have llSetLinkPrimitiveParamsFast. Something like this will control the glow in all prims in a linkset that have the words "glow prim" (without the quotes, of course) as their description. Just drop it in a button prim (not the root unless you want it to turn on and off whenever the object is touched, rather than just when the prim is touched), and you are good to go. I know we said we don't do full scripts for people, but I find this technique of making a list of your target prims and then looping through it at run time so useful. string glow_prim = "glow prim"; integer i; integer max; integer toggle; //on/off binary toggle list glowing; list glow_on = [PRIM_GLOW,ALL_SIDES,0.05];// could change colour, texture and whatever here, too list glow_off = [PRIM_GLOW,ALL_SIDES,0.0]; list params; find_prims() { glowing=[]; //clear the list i=1; max = llGetNumberOfPrims(); do{ string s = llToLower((string) llGetLinkPrimitiveParams(i,[PRIM_DESC]));//get the description of each prim if(s==glow_prim){ //if the target name matches glowing +=[i]; //add the number to the list } //else if the description is something else, add it to another list if appropriate } while (i++<max); } default { state_entry() { find_prims(); max = llGetListLength(glowing); } changed (integer c){ if (c & CHANGED_LINK){ find_prims(); max = llGetListLength(glowing); } } touch_start(integer total_number) { toggle=!toggle; // i=0; i = max; if(toggle){ params = glow_on; } else{ params = glow_off; } while (i--) { llSetLinkPrimitiveParamsFast(llList2Integer(glowing,i),params); } // while(i++<max); } }

In addition to looking at the sample scripts at Sirena, I'd strongly suggest visiting The Particle Lab at http://maps.secondlife.com/secondlife/Teal/180/74/21 There (in the sandbox area downstairs) you'll find free OS sample templates for a wide variety of effects and triggers.