Kayaker Magic

Well, I'm competing against the guy who has something like this in his code somewhere: for (EVER){ vector pos=//some calculation llSetLinkPrimitiveParamsFast(1,[PRIM_POSITION,pos]); //there are 2 or more prims in the build sleep(0.02);} and MY customers are asking me "Why do YOUR critters move in such a jerky way? Cant you make them move smoother?" I'm trying to be a good netizen about it and find some way to increase my step rate while still using good event driven programming. I've gotten smother motion with physics, but it has its own problems. The physics engine is not lag free either. It runs away from me all the time. llMoveToTarget can't really do constant velocities and won't move larger builds. I've had to resort to using vehicle physics. Meanwhile, the guy with the ugly loop above is getting beautiful results. What is a scripter supposed to do?

I used to think that you could not set the timer interval less than 0.2 seconds in llSetTimerEvent. But it turns out I was calling llSetPos or something in the timer() event that had a 0.2 second delay. I get the impression that the theoretical minimum delay should be around 1/45 but the Wiki has hints that you will actually get intervals that are twice as long as that. Which is still 4 or 5 times better than I used to expect. HOWEVER, when I try setting timer intervals this small, I don't seem to get things to move more often than I get with a 0.2 second interval. (Even using llSetLinkPrimParamFast to avoid the 0.2 second delay). What are the practical limits on timer() event rates? I haven't done the experiment yet to MEASURE the maximum rate (minimum interval). Has anyone else already done this experiment?

Ringstadjr, you said llSleep has a min of 0.2, but actually it is llSetPos that inserts a fixed delay of 0.2 seconds. Try your loop experiment again using llSetLinkPrimitiveParamsFast instead of llSetPos and see if your motion becomes smoother.

I have rotated and positioned avatars linked to physical objects using PRIM_ROTATION etc. My application is building kayaks and other vehicles that can paddle off-sim into the Void Sea. I have discovered that the Physics Engine gets very confused when the avatar is over about 40 meters away from the root prim and off-sim. At 40 meters or more the whole build starts taking off and flying great distances (greater than 256 meters) before snapping back to where it belongs.

I have a prim that changes size, but I want the texture to stay constant and not scale with the prim. No problem, I can calculate new repeat values every time I change the prim size and call llSetPrimitiveParams(PRIM_TEXTURE to make the texture map the way I want. Problem is, I also want the texture to slowly slide across the prim. (It is supposed to look like flowing water). After I call llSetTextureAnim(ANIM_ON|LOOP|SMOOTH, it resets the texture repeat to 1,1 every frame! For a minute I thought changing the sizex and sizey parameters in this function would do the same thing as the repeat values, but these parameters are integers and I need fractional values. Am I SOL? Is there away to animate a texture (sliding, not frame based) and set the texture repeat at the same time? 

Dang! Bounding box won't work for me 'cause it returns an axis-alligned box that encloses all the prims in a build, not just the one prim I want. What I'm trying to find out is a if a point is inside or outside a projection of the top of a prim onto the XY plane. If I know the center, rotation, (from llGetObjectDetails) and size, I can rotate the 4 top corners and use isPointInPolygon2D. The bounding box is region alligned and includes other prims in the size... Tuns out when I found the prim's UUID it also sent me a string with the size burried in it, but now I have to parse that string and save the size for use later... 

How can I get the size of a prim when all I know is the UUID? llGetObjectDetails will give me the location, the position, but not the size. The prim I am interested in is not part of the build that the script is in. (can't use llGetLinkPrimitiveParams)  

I tried many different things to fix this, putting in delays in different places, forcing the avatar's rotation to be parallel to the XY plane. Nothing in the script fixed it. That last attempt had me thinking that the hip angle in the animation was sometimes corrupted. Finally I noticed that the pelvis angle I was getting was identical to the pelvis angle from the last animation that my AO was running when I sat down! This is that usual problem that a zero animation angle means “leave the old value in this joint”. I edited my sitting animation to have 0.2 degrees around the X axis in the pelvis, and now the problem is fixed! The reason it only happened a small percentage of the time was because most of my fidget animations had zero pelvis rotation already! 

Normally when I sit on my vehicle, everything works fine. But every once in a while (5% chance) my avatar is rotated/tilted to a strange angle. In the script, I have even tried calling llSetLinkPrimitiveParams to force the avatar upright again, but this does not work! Only standing up and sitting on the vehicle again gets me oriented correctly when this happens. It is as if the angle is corrupted in the pose animation. I've been told “Oh, this is a common problem with vehicles” but I find no mention of it in the jira for llSitTarget. 

I'm working on a project where I had to split a single script into several separate scripts. I'm learning some interesting things. Like: When an avatar sits on the prim, ALL the scripts get a changed event. If one of the scripts requests PERMISSION_TRIGGER_ANIMATION (for example) none of the other scripts in the same prim can take advantage of it (unless they request their own). So apparently permissions are a property of the script, not of the prim. There is absolutely NO HINT of this in the Wiki pages for changed, llRequestPermission, run_time_permissions, etc. that I can find. Is there a Wiki page somewhere that talks about the behavior of multiple scripts in one prim? (So I can find out WHAT ELSE I might need to know before I have to figure it out the hard way for myself). 

Well, first off you're code has several tests for (avatar == llGetOwner()) So only the owner of the object will be allowed to control it! You could try giving a copy of the build to your friend, then they will become the owner and can use it. Or take out those tests if you want anyone to be able to use it.

Unfortunately, I was already storing all lists in globals and the functions are called with no or only a few arguments (like a new position or a dialog message string). I'm starting to warm to the idea of splitting my script into several scripts and using llMessageLinked to communicate. But talk about "send by value" issues, llMessageLinked can only "send by string"! So I'll have to parse the string, find out what value is changing and convert vectors and floats back from strings on every message. If I design the protocol to only send messages when things change, then the "main" script will still work the way that it used to. A "data" script will keep the new lists I'm adding and send infrequent updates to the main script. And I can add a third script to handle the dialog box and other user interface issues to save space for more data in the data script. Is it true that a llListen in one script does not cause the listen events in other scripts to get copies of all the resulting messages? The Wiki implies that the effect is local to the calling script, but doesn't specifically say what happens with multiple scripts in a single prim. Of cource I was trying to keep my script count down for future script limitations that LL is considering. I have to give up on that one now.

Besides re-usability, I also use functions for code documentation. I'm horrified to find myself considering taking code that is nicely compartmented into functions with meaningful names (setup, start_dialog, move_fwd, etc) and moving this code into the events that used to call them (on_rez, touch_start, timer, etc.). This is not a good thing IMHO. 

I started adding new features to one of my favorite scripts (around 1000 lines of code). I converted some of the code to functions for re-use, I added new lists and managed them. Before I finished adding all the new features, I got “Stack-Heap Collision”. The script runs for a few seconds, collects some data in the lists and then runs out of memory. So what am I going to be able to do? Does this mean I was pushing the edge of the memory limits before and now I have to give up on adding the new features? 

This is one of the goals of my recent post http://community.secondlife.com/t5/LSL-Scripting/Is-event-driven-programming-in-LSL-dead/td-p/949771. There used to be a trick, called Multi Move to put multiple scripts in an object, syncronize them, and get them all to each call llSetPos/Rot with a different time offset. The result of all this was to get around the limit of only 5 calls per second. llSetPrimitiveParamsFast makes this ugly, difficult and system resource hogging technique obsolete. I'm still struggling with the question what is the best way to use this new call? Like all SL projects, this one starts with doing research to figure out what the llLibrary routines actually do, finding out what the undocumented limits are, what the unexpected side effects are, how to call them without bogging down the sim. I haven't done this research yet, but I'm leaning in the direction of doing the following steps: llSetTimerEvent(1/45) to get timer events as often as possible. llLinkSetPrimitiveParamsFast(1,[..]) in the timer event to move and rotate my critter There may an additional calculation in timer() to calculate how long it has actually been since the last event and adjust the position appropriately to compensate for lag introduced from outside...

If I understand you correctly Darrius, you want to add something like: llSetLinkPrimitiveParamsFast(1,[PRIM_POSITION,pos,PRIM_SLEEP,0.01]); But if we add that, my “friend” will just use this to save him having to call llSleep(0.01);. He will still have a while(TRUE) in his code. Either that, or he will do something even more horrid like: list parms=[]; for(i=0;i<1000;i++) { vector pos=calcnew(); parms = parms + [PRIM_POS,pos,PRIM_SLEEP,0.01]; } llSetLinkPrimitiveParamsFast(1,parms); I shudder to think how that will behave if he calls it more than once every 10 seconds! Either way, I don't see how this encourages good programming style. Good style in this case means “doesn't bog down the sim”. Not that I know what good style is, I'm hoping for enlightenment about this... 

I am always debating whether to make a scripted object non-physical and put up with jerky motion, or physical with smooth motion but put up with the physics engine running away from me from time to time. I bumped into a guy who had some smoothly moving scripted critters (birds in this case). I assumed they were physical objects but he said no. So how did he do it? Well he was cagey about his “valuable proprietary script” but from some of his comments I believe this is what he is doing: Somewhere in his script he has code that looks like this: while(TRUE) { vector pos = calcnew(); //calculate a new x,y,z position llSetLinkPrimitiveParamsFast(1,[PRIM_POSITION,pos]); llSleep(0.01); } No other events can be processed during the sleep. Since he never returns from this event, I suspect that no other events can ever run again in this script. So you can't have timers, listens, or dialog boxes, etc any more. Perhaps you can put in a second script for those things and implement some form of communication that you check for in that big while loop. This guy CLAIMED that his scripts were LOW LAG. I think he was thinking something like this: “The physics engine is laggy, I'm not using the physics engine so therefore I am not laggy. Scripts are the lowest priority thing done by the sim so it doesn't matter if I loop forever”. So if this is a good way to get smooth motion in LSL, then should good event driven programming methods now be tossed out the window? In lots of non-physical scripts that I have written, before llSetLinkPrimitiveParamsFast, I had a timer event that called llSetPos or llSetPrimitiveParams. Because both of these had a 0.2 second delay, I could not move my objects more often than 5 times a second. Is it now reasonable to set timers for very short periods of time, like 0.02 seconds, and call llSetLinkPrimitiveParamsFast in the timer event? What is the shortest reasonable time step I can use? I'm assuming 45 server frames per second limits me to 0.02 seconds or so. But is that REASONABLE? Will several objects doing this bog down the server? Will they interfere with each other? Will my timer events actually be called reasonably often? Can good event driven programming style still compete against the guy with a while(TRUE)? 

I think you wanted llRotBetween(llVecNorm(AvPos-MyPos),<0,0,1>) AvPos is in region co-ordinates, and you want the little vector from the center. HOWEVER, doesn't llPushObject have a wierd-strange fall-off with distance from the center of the prim and the mass of the pushee, or the pusher, or which ever one doesn't make sence? I recall trying to compensate for this once and just running out of "energy" instead.

Some time ago I built teleporters to get from one place to another on my sim. I can set up prims that say “Click here to go to the cove” on then. I used the following technique: I set the teleport transmitter to “Sit on Left-Click”. I set a Sit Target standing in front of the transmitter. When someone sits, I send a message to the receiver, (via llRegionSay) it replies with its location. The transmitter then uses posJump to move to the receiver, llUnSits the avatar there and posJumps back. This used to work 99% of the time. Occasionally it would stop in transit deep under water or up in the air off-sim. If I hit one of the movement controls the system would realize its mistake and snap me to the correct location. But over time it has become more and more unreliable, until EVERY TIME I use one of these teleporters, I first go someplace strange and have to hit the rotate button to finish the teleport. So how do I make my teleporters reliable again? Is there a way to get to the destination directly without pausing in odd places along the way? I could use the llSitTarget trick, but that only works <=300 meters so it won't work for “click here to TP to the skybox”. I could query the receiver every so often and switch to the llSetTarget trick when the distance is <300 meters, but then I still need a reliable way to teleport longer distances. Any suggestions? Below is my transmitter code: //Teleport button integer telchan=-101507; //channel for teleport communication string name="Test Two"; //name of receiver I talk to vector spos; rotation srot; string notecard; //for reading parameters integer line; //next line to read from notecard float delay=0.1; //tenth of a second delay posJump(vector target_pos) { // An alternative to the warpPos trick without all the overhead. // Trickery discovered by Uchi Desmoulins and Gonta Maltz. More exact value provided by Fake Fitzgerald. llSetPrimitiveParams([PRIM_POSITION, <1.304382E+19, 1.304382E+19, 0.0>, PRIM_POSITION, target_pos]); } default { state_entry() { llSetText("",<0,0,0>,0); llSetSitText("teleport"); llListen(telchan,"","",""); //listen for location commands llSitTarget(<0,-1,-1>,llEuler2Rot(<0,0,90>*DEG_TO_RAD)); //set a sit target to hang at notecard=llGetInventoryName(INVENTORY_NOTECARD,0); line=0; if (notecard!="") llGetNotecardLine(notecard,0); } on_rez(integer param) { llSetText("",<0,0,0>,0); llSetPos(llGetPos()+<0,0,1.25>); //bounce 1.25 meters off the ground notecard=llGetInventoryName(INVENTORY_NOTECARD,0); line=0; if (notecard!="") llGetNotecardLine(notecard,0); } dataserver (key id,string str) { if (str!=EOF) { list parse=llParseString2List(str,["\"","=",";"],[]); string cmd=llToLower(llStringTrim(llList2String(parse,0),STRING_TRIM)); string param=llStringTrim(llList2String(parse,1),STRING_TRIM); if (cmd=="" || llGetSubString(cmd,0,0)=="/") cmd+="comment"; else if (cmd=="name") name=param; else if (cmd=="delay") delay=(float)param; else if (cmd=="text") llSetText(param,<1,1,1>,1); else llOwnerSay("Bad parameter file line: "+str); line += 1; llGetNotecardLine(notecard,line); } } changed(integer change) { if (change&CHANGED_LINK) { key av=llAvatarOnSitTarget(); if (av != NULL_KEY) { llRegionSay(telchan,"ask|"+name); //ask the receiver for the location llRequestPermissions(av,PERMISSION_TRIGGER_ANIMATION); spos=llGetPos(); srot=llGetRot(); llSetTimerEvent(5); //give it time to respond } else { posJump(spos); //return the prim where it came from llSleep(delay); //sometimes a delay helps llSetRot(srot); //put it back in the orientation it was in before } } if (change&&CHANGED_INVENTORY) { notecard=llGetInventoryName(INVENTORY_NOTECARD,0); line=0; if (notecard!="") llGetNotecardLine(notecard,0); } } run_time_permissions(integer perm) { if (perm & PERMISSION_TRIGGER_ANIMATION) { llStopAnimation("sit"); llSleep(0.1); llStartAnimation("stand_3"); } } listen( integer channel, string lname, key id, string message ) { list parse=llParseString2List(message,["|"],[]); string cmd=llList2String(parse,0); string receiver=llList2String(parse,1); key av=llAvatarOnSitTarget(); if (cmd=="loc" && receiver==name && av!=NULL_KEY) { llPlaySound("transporter",1); llSetTimerEvent(0); //turn off the watchdog timer spos=llGetPos(); srot=llGetRot(); vector tpos=(vector)llList2String(parse,2); rotation trot=(rotation)llList2String(parse,3); llSetRot(trot); posJump(tpos+(<0,1,0>-<0,.5,0>)*trot); //+<0,.6,0>*srot); llUnSit(av); } } timer() { llSetTimerEvent(0); key av=llAvatarOnSitTarget(); if (av!=NULL_KEY) { llSetTimerEvent(0); //give up on a responce llUnSit(av); llWhisper(0,"Teleport failed, try again later"); } } }

If you want to create joints between prims, you might try OpenSim and their "NINJA Physics". Take a look at the "ragdoll" in this video: Since there is no data structire in an SL compatible object to store joint information, the connections and parameters for this are stored in the prim descriptions!

I have an object that I want to briefly dip below the ground. If it is a physical object I can do this by setting llVolumeDetect(TRUE) and calling llMoveToTarget. But I want to avoid the overhead of a physical object. I made my object non-physical and used llSetPos to move it. But llSetPos refuses to move my root prim below the ground! I used to have an invisible root prim a few meters above the rest of the build so I could push the visible parts of a non-physical object below ground. I thought that llVolumeDetect(TRUE) would make this extra prim unnecessary. I could switch to using physics and bogging down the sim just so I can save that one prim, but I seem to recall that a physical object with a seated avatar cannot go below the ground even with llVolumeDetect(TRUE). Anyone know another way around these limitations?

Ah! But Radegast is not V2 and this is a V2 forum! But since you brought up alternate viewers, I have tried several of them. Phoenix works well and gets about the same FPS as V2 with the same settings. Singularity Viewer is supposed to be faster so I tried it. With low graphics settings it is faster than the others getting an astonishing 30 FPS. But if I turn on transparent water and reflections and a few other nice features, then Singularity slows down to about the same speed as the others. This is a very nice comprimise I can live with, turning these features off for development and back on for taking snapshots! I am very happy with how well ALL the viewers run on Linux! They all look great and seem to be as reliable if not more so than the Mac and PC versions. I'm assuming my FPS issues are caused by my poor choice of graphics chipsets. I'm also running Firefox and Blender (with Primstar) on the Linux system so everything I need to develop on SL fits in this inexpensive shoebox-sized computer I have.

Update! I found something else that effects FPS! I had a big monitor (1920x1080) plugged into the Linux system. I decreased the window size to 640x480 and the FPS went up over 12. (Doh! Slap forehead!) Not great, but probably good enough for my plans for this system.

That sounds like a building question that belongs in another forum! ;-) Try making the shade transparent, or change the script to make the light glow when on. There are two different prim effects that go into a light: PRIM_POINT_LIGHT which shines light on surrounding obects, and PRIM_GLOW that makes the light itself look like somethig that is glowing. I turn both of them on for a light bulb. Glow has the strange effect that it is visible through other prims, so it might fix the problem of shining through the shade. Now if you put a copy of your light script in a post here and asked for advice on how to add glow to it, that is definately an appropriate question for the scripting forum! [later: HA! Everyone else was posting similar advice at the same time!]

This isn't what you want either, but I have written attachments that move around the avatar. I have bats and little dragons that fly around the avatar and react (more or less) correctly to surrounding avatars. I can imagine a critter that always positions itself between you and the nearest avatar, and excelent guard/thing! Problem is, motion that is appropriate for a flying critter would not be appropriate for a guard/avatar/person/cutout. When an attached bat is swung around by the rotation of the avatar, it just looks like erattic flying behavior. Then when the avatar stands still the bat returns to predictible flying patterns. Perhaps this trick could be used to just put the feet of the attached guard/cuttout on the ground. The fixed position of an attachment would keep it behind you always.