Innula Zenovka

I don't understand the problem -- when you drag copy something, the script in the new item resets itself. Try this example to prove it. Put it in a prim, set a number as the key, and then drag copy the prim and watch what happens. integer my_key;integer handle;integer dialog_channel;list numbers =["1","2","3","4","5","6","7","8","9","10"];list order_buttons(list buttons){ return llList2List(buttons, -3, -1) + llList2List(buttons, -6, -4) + llList2List(buttons, -9, -7) + llList2List(buttons, -12, -10);}default{ state_entry() { if (my_key == 0){ llSetColor(<1.0,0.0,0.0>,ALL_SIDES); llOwnerSay("please touch me to change my key"); dialog_channel = ((integer)("0x"+llGetSubString((string)llGetKey(),-8,-1)) & 0x3FFFFFFF) ^ 0xBFFFFFFF; } } touch_start(integer total_number) { key av = llDetectedKey(0); if(av ==llGetOwner()){ if(my_key ==0){ llSetTimerEvent(20.0); handle = llListen(dialog_channel,"",av,""); llDialog(av,"Please choose a number",order_buttons(numbers),dialog_channel); } else{ llOwnerSay("the key is set to number "+(string)my_key); } } } timer() { llListenRemove(handle); llSetTimerEvent(0.0); } listen(integer channel, string name, key id, string message) { llListenRemove(handle); llSetTimerEvent(0.0); my_key = (integer)message; llSetColor(<0.0,0.0,1.0>,ALL_SIDES); }}

I think they've moved the "World/Local/Reference/Screen/Attachment" drop down to the Build-Options annex window, if that's any help. Marine Kelley has put it back in the old place in her latest RLV viewer (based on 2.8) , and I assume it'll stay there in her V3 version when it comes out.

The start parameter in the MLPV2 ~ball obect is dynamic. From memory it's an integer based on the rezzer's uuid and then the ~ball script adds something to it, plus the ball number, to generate a unique channel for each ball. I may have the details a bit wrong, but it's certainly something like that.

Hover text survives. TargetOmega doesn't. I'll check on PINs for llRemoteLoadScriptPin() when I get in.

Void Singer wrote: setting and checking prim properties that get wiped out upon shift-drag is a bit more reliable in the case of rerezzing. Do we have an up-to-date list, though, of what those are, at least the readable ones? The main channel server deploy of 11-08-15 lists among its bug fixes a "Fix to make shift copying copy all prim properties." Sit targets certain seem to survive drag copying now, though I don't think texture animation does, at least not in the cases I've tried, so I'm a bit unclear now what survives and what doesn't.

I'm a bit confused. You that each time it's rezzed it asks for a key number -- is this something the owner chooses or what? Since when you drag copy something, that resets the script in the new copy, why not do in the state_entry event for state_default whatever it is you're presently doing in the on_rez event?

It depends on how you were planning to vary the velocity, but I don't see it, myself. SL projectile weapons usually work by rezzing a physics-enabled object with llRezAtRoot() llRezAtRoot( string inventory, vector position, vector velocity, rotation rot, integer param ); I don't see why a well-scripted mechanism for changing the value of the velocity parameter (e.g. a llDialog menu that listens on a rarely-used channel and closes the listener in a timely fashion) would cause any noticable issues.

I don't really understand the question, except that, if you've been looking in the archived forums, it seems that in the process of moving stuff over from the Jive forums to this one, something trashed all the code examples containing lists, thus turning llSetLinkPrimitiveParams(x,[some parameters]) into llSetLinkPrimitiveParams(x, ).

Why do you say SL works better with only one viewer on your computer? I generally have six or seven different ones installed, because I test the scripted items I make on all the viewers my customers are likely to be using, and because I'm aware that various viewers have their own peculiarities when it comes to rendering some sculptmaps, and I want to make sure anything I use is going to look right for everyone. Ever since I learned to make sure each one has its own cache, I've had no problems I can attribute to having so many viewers installed.

You'll need to take that up with LL's billing department -- this is just ordinary residents trying to help by sharing knowledge and experience. I think, though, that you may be told that "The Land Use Fee is a monthly charge for the peak amount of land held during the previous 30 days, including actual parcels held and land tier donated to groups." So if you transferred the land after June 17th, that's why they charged you. I got caught out like that once -- it's an expensive lesson.

One way to do it might be to have your four lists and then, each time someone touches the object, use llListRandomize to re-order each of them. Then add the first item from "unique", the first from "gold," the first three from "silver" and the first ten from "common" to a temporary list, "temp", using llList2List, and then use llGiveInventoryList to give them that.

You can't directly teleport people as a result of a touch event (unless they use RLV), so you'll need to look at llMapDestination or have the item use llRegionSayTo or an IM to ask them to click on a slurl in the chat history. You can fake teleport people on the same sim with a variety of methods, or (under some circumstances) to an adjacent one, by having them touch things, though. Which are you trying to do?

Rolig Loon wrote: It's not quite as easy as that. You need to be aware of your frame of reference whenever you work with rotations. Changing a rotation in the regional reference frame will have a very different effect from changing it in a local reference frame, relative to some other object or relative to an attachment point on your avatar. This is probably the most complicated aspect of scripting in LSL. To start learning, read http://wiki.secondlife.com/wiki/Rotation . Besides the wiki article -- which I've always found very helpful -- there's three tutorials over at SLU I strongly recommend: http://www.sluniverse.com/php/vb/tutorials/62235-basic-introduction-rotations.html http://www.sluniverse.com/php/vb/tutorials/62479-introduction-rotations-translations-rotation-tutorial.html and http://www.sluniverse.com/php/vb/script-library/40698-kept-simple-rotate-object-towards.html

I haven't said anything about Debian.

That's a good point. Is your spinning disk generally static, then (that is, it doesn't normally change its rotation)? Since I don't know what it's in, but since you're so concerned about the rotation changing and having to reset llTargetOmega, I sort of assumed it was going to be in something that moves around a lot.

Let's try to figure this out. Here's the screenshots for one of my alts: So the metric measurements differ by 20cm between V3 and Phoenix, which is 7.87 inches. We need to convert V3's Imperial measurement to feet and inches; 6.28 feet is 75.36 inches, which is 6 feet, 3.36 inches. So the difference between the two viewers' imperial versions is 6.64 inches, not 7.87, which is a bit odd. 2.11 meters is 83.07 inches, which Google calculator thinks is 6' 11.07", not 6'10" so Phoenix's conversion is just over an inch out. V3's 1.91 meters is 75.19 inches, which is 6.266 feet, not 6.28, so they're both a bit out in their own conversions from metres to feet, but not hugely so. Where are you getting "a 5 foot tall avatar is 6.6 foot tall.. and 4 foot tall = 5 foot LoL" from?

I don't quite understand what you mean by SL's Viewer's Height Detector. This is what my appearance editor looks like in V3 -- are you talking about something else? ETA -- where on earth are you getting the conversions from in your table? One metre = 3.28 feet, or so Google Calculator thinks. 

I've always been a worried about when to use no_at_target events because, presumably, they're firing constantly until I reach my target, so it's a bit like using a very fast timer -- not really a good idea over extended periods except when absolutely necessary. Or am I being over-cautious because I've misunderstood?

If the OP is using Windows 7, then Start>All Programs>Accessories>System Tools>System Information will open some windows giving the necessary information, I think. Details of the OS Name and Processor will be on the System Summary tab and details of the graphics card name and type will be in the Components-Display window. These can be copied simply by left-clicking the relevant entry and doing CTRL C (the right mouse click context menu doesn't seem to work there).

Sassy Romano wrote: (It took me a week to find out how to stop wearing boxes) One of the things that keeps me going when I'm trying to understand some seemingly impossible scripting conundrum is the thought that, no matter how difficult it seems, it can't possibly be any worse than once I thought opening boxes was.

It might be worth, if you are able to do it, clicking on Debug-Show Debug Settings before trying to log in, setting NoHardwareProbe to TRUE, and then trying to log in (or you might need to restart the viewer before it takes effect). That was always the fix for messages about unrecognised graphics cards when your graphics card was too new for for the viewer to recognise. ETA -- To change the debug settings, start the viewer but don't try to log in. If you don't have Debug as a menu option at the top left of the screen, hit ALT CTRL D to make it appear. Then choose the first option, Debug Settings, and type in NoHardWareProbe. Set that to TRUE, and then close the viewer and restart it (I'm not certain the restart is necessary but it can't hurt). I'm not sure this will work, because I've never had this problem, but it's certainly how I've dealt with similar issues in the past.

Real world laws most certainly can apply to a videogame. While I can see massive difficulties in actually proving the offence, what makes you say that someone in the UK wouldn't be subject to this: http://www.cps.gov.uk/legal/p_to_r/prohibited_images_of_children/ ?

Yeah, I've just tested it in the Blue Steel sandbox. default{ state_entry() { llSetLinkPrimitiveParamsFast( 1,[PRIM_COLOR,ALL_SIDES,<1.0,0.0,0.0>,1.0, PRIM_LINK_TARGET,2,PRIM_COLOR,ALL_SIDES,<0.0,1.0,0.0>,1.0, PRIM_LINK_TARGET,3,PRIM_COLOR,ALL_SIDES,<0.0,0.0,1.0>,1.0]); }} works as expected if it's in the root prim but gives that error in a child prim.

See https://wiki.secondlife.com/wiki/Linden_Lab_Official:Adult_Content_FAQ It's a "working draft" but it pretty much restates what the position's always been -- yes, child avatars are allowed on Adult sims but they should keep well away from the actual adult content. That having been said, a lot of Adult sims and parcels do ban child avatars anyway.

There are several such devices in the marketplace. I've not used them myself, but I have recommended Dora Gustafson's products to people on the grounds I know she's an excellent scripter who understands rotations, and everyone's told me they've been exactly what they've been looking for.