Kayaker Magic

Here is a very short script that, when put in a root prim, point's the prims local X axis at the nearest avatar and the local Y axis "up". default{ state_entry() { llSensorRepeat("","",AGENT,30.0,PI,1.0); } sensor(integer num) { vector fwd=llVecNorm(llDetectedPos(0)-llGetPos()); //normal pointing at nearest avatar vector lft=llVecNorm(<0,0,1>%fwd); //UP cross fwd is left (right hand rule)// llSetRot(llAxes2Rot(fwd,lft,fwd%lft)); //standard: local Z is up llSetRot(llAxes2Rot(fwd,fwd%lft,-lft)); //local Y is up instead }} I say "up" because the axis is allowed to rotate around the Z axis as necessary to point the X up or down while keeping the Z axis always in the XY plane. I prefer to keep all my objects in the "standard" orientation with the local X axis pointing foreward and the local Z axis pointing up (the commened out line above). llAxes2Rot is my FAFORITE function! You can think of the three arguments as 1) which way you want the local X axis to point, 2) which way you want the Y axis to point, 3) which way you want the Z axis to point. Of course there are rules: 1) All three vectors must be unit vectors, 2) the positive Z axis must point in the direction of the cross product of X and Y (That was why I had to negate lft above) and 3) they must be perpendicular to each other. When you have an object like a gun, or a flying critter, you usually want one axis trapped in the XY plan. A gun turret spins around the Z axis and the barrel rotates up and down.Given just the direction the gun is pointing you can calulate the other axes as I showed above and turn that into a rotation. Gimbal lock isn't a problem in this situation, if a strange combination of Euler angles are necessary to get what you need, llAxes2Rot calculates them for you. Gimbal locks seems to be a problem that is had by people who think in terms of the angles. If you think in terms of the vectors, there is never any problem!

I moved all my items over to Direct Delivery recently, verified that everyting is direct, deleted the Magic Box items from the list of unlisted items. After a week or two I took the plunge and removed the magic boxes (took them into inventory). Then I got an email from Xstreet SL telling me that my items are not available. "Our records indicate that you have items listed at the Xstreet SL Marketplace, but none of them are available for purchase because your server object(s), listed below, have lost connectivity with the Xstreet SL main server." Then a bunch of links to the old www.xstreetsl.com server. I assume this is a message from the dying system that I can ignore.

I have been using the prerocessor since it came out in Phoenix. There was a period of time when Firestorm first came out but it did not have the preprocessor yet so I was unable to upgrade. I'm totally addicted to the preprocessor and can't script without it any more. HOWEVER, it is not perfect. When the compiler detects a syntax error, it gives a line number in the expanded version. Clicking on the error will take you to that line in the expanded version, and the interface will even let you waste your time editing that version. I've been frustrated many times to discover that I have edited the wrong version and have to make my changes over again in the real source. And even if you remember to edit the unexpanded version after looking at the error, there is no easy way to find the same line in the source. Yes, I know that included lines will not be there in the main source, but when a line does appear in both of them, I can click on the error to see the bad line in the expanded version, but then I have to search for the same line in the source before I can fix it.

Every time I log into SL lately, I notice another texture map has turned white. Sometimes it is a texture I uploaded, and I have tried uploading a new copy to fix it. Sometimes it is one of the standard terrain textures and part of my land turns white. Once it was even the default plywood texture that every newly created prim starts with. Over time more and more textures turn white until I finally learned that clearing the cashe brings them all back. Is this happening to anybody else? I have one hypothesis to explain this: It is what I do between the times that I log onto SL: I have been spending more time on Open Simulator based grids. My hypothesis is that there are occasional collisions between the UUID numbers of one of these grids and the UUID numbers of SL. My viewers (Phoenix, Firestorm, Imprudence, I've seen the problem with all 3 of those) cashe the UUID numbers from one grid, then try to use them on another. The result in the case of a texture is a texture that cannot load properly and defaults to blank white.

If a customer buys something from my vending machine in SL, I get their UUID. I add them to my database. I store them by UUID since it is, well, Unique. If I need to send them an update, llGiveInventory works by UUID, so life is good. But if someone buys something from me on the Marketplace, LL only gives me the username in the reports. But LL does not supply a way to convert that username into a UUID (no llName2Key). Why do they NOT provide this? Why do they give me names and not UUIDs in Marketplace reports? Now I have no unique way to identify customers, I have no way to find them to send updates. Life is not good. I get the impression that LL thinks people who want UUIDs are some sort of griefer/hacker/criminal. LL banned everyone who used to maintain the w-hat external database. Can I get banned for using one of those databases? LL put special tests in the llHttpRequest function to prevent it from being able to implement name2key. While reading forum messages, I see people worrying that they will get in trouble for making too many requests that look like name2key requests. The external name2key servers that I use keep dying and then my Marketplace updater code stops working and I have to run around and find a new one. Why do LL's own polices make me feel like I have to become a hacker/criminal in order to do ordinary business operations in SL???

You guys are the greatest! I was able to get my scripts to work again! I submitted a JIRA to LL, but they were unable to reproduce the bug. Even if they could, I would have to wait until the next server roll-out for a fix. Then Nova noticed that the problem went away if the build was large enough. I only have one prim in my build, it was already invisible and phantom while the avatar was sitting on it, so I changed the size to <60,60,60> during that time, and my script started working again! Thanks a bunch! Well, it was not quite that easy, my prim was physical and when I made it that big llMoveToTarget ran out of energy and the whole thing started falling into the ground. I wrote this a long time ago and only made the silly thing physical to get smooth motion. I have been meaning to convert it to non-physical llSetKeyframedMotion. So after I did THAT, then my script started working the way I wanted it to. Thanks for your help!

I wrote the following script to demonstrate the problem. Create a standard plywood box. Put this script in it. Sit on it. Your avatar should rise up into the air turning around. But at about 21 meters, you stop moving or rotating. The get operation reports the correct position but you don't appear to move or rotate. Every 10 meters or so you do suddenly move and rotate. Sometimes there is a long delay when you should return to 1 meter. I tried this in Imprudence 1.3.2 (May 17 2011) and in Firestorm 4.2.2.29837 (yesterday) and saw the same thing. I have a dozen scripts and 1000 products sold that depended on this working! What happened?! vector height=<0,0,1>;rotation avrot=ZERO_ROTATION;rotation thirty;default{ state_entry() { llOwnerSay("Sit on me"); llSitTarget(<0,0,1>,avrot); thirty=llEuler2Rot(<0,0,30>*DEG_TO_RAD); } changed(integer param) { height.z=0.0; if (llAvatarOnSitTarget()==NULL_KEY) llSetTimerEvent(0); else llSetTimerEvent(0.333); } timer() { avrot *= thirty; height.z += 1.0; if (height.z>50.00) height.z = 1.0; llSetLinkPrimitiveParamsFast(2,[PRIM_POSITION,height,PRIM_ROTATION,avrot]); llOwnerSay((string)(height.z)); float dist = llVecDist(llGetPos(),llList2Vector(llGetLinkPrimitiveParams(2,[PRIM_POSITION]),0)); if (llFabs(dist-llVecMag(height))>0.5) llOwnerSay("FAILED!"); }}

I tried moving to a nearly empty sandbox, same effect. I tried converting the prim from physical to non-physical, same effect. I tried it in an old reliable version of Impudence, same problem. Siny new version of Firestorm, same problem. I had a friend watch me and tell me if my avatar was turning when it was supposed to, she saw the same problem. I have some indication that the effect is not there when the avatar is close to the root prim, and starts up when he/she is more than 10? meters away from the root prim. So it may have been a change in the linkability rules that only effects avatars. (I have some off-sim objects that still work fine 50 meters from their root prim).

A whole bunch of scripts that I wrote a long time ago are missbehaving today. Has there been a server change recently (PathFinding?) that has caused problems for anybody else? I have a bunch of scripted objects that find the seated avatar and move/rotate him/her around like a child prim. I do this using the same technique described in the UpdateSitTarget function in the Wiki. Every build I have that uses this techique started working poorly yesterday. (Although I haven't looked lately, it could have started failing earlier). It still sort of works, but it is VERY SLOW. Especially at rotating the avatar, and even just moving the avatar sometimes results in the avatar moved up or down far away from where I intended the move to go.

My understanding of physical bullets is that in a collision, only the physical object gets notification. I don't want my target critters to have to be physical, so only the bullet gets notification. So how does the bullet tell the target that it has been hit? llCastRay sounds like a better way to do this than physical bullets. Again, it is the “gun” that casts the ray and figures out that it has “hit” some other object. How does the gun tell the target that it has been hit? I assume that some sort of message is sent and susceptible targets listen for it and react accordingly. Is there a standard protocol for this? Does everyone use the same channel number and message format? Or am I assuming a level of co-operation between weapons makers that doesn't exist in the wonderful collaborative world of Second Life?

I just spent all day debugging some code of mine that worked fine on OpenSim but broke down in strange ways on SecondLife. Finally I found the problem: Despite it's name, llGroundNormal *DOES NOT RETURN A UNIT NORMAL VECTOR!* It returns a vector pointing in the direction of the ground normal, but the length can be greater than 1. Apparently OpenSim *DOES* return a unit normal vector, so my code worked over there. If your calculations require a unit normal vector (like if you use the result as an argument to llAxes2Rot) you must normalize it (with llVecNorm) yourself. Yeah, if you read down in the Wiki, they tell you what it returns, but they never mention the fact that this normal routine does not return a unit normal! I foolishly read the name and stopped before getting far enough to see that normal isn't normal. I'm going to put a caviat to this effect in the Wiki!

I have a bunch of swimming and flying critters that used to move in a jerky llSetPos way, I upgraded some of them to llMoveToTarget with poor results. So I was happy to see llSetKeyframedMotion and I started converting scripts over to it. It works great at first, the motion is smooth and the velocity is linear. So I left a few critters swimming around, making another llSetKeyframedMotion call once every second. After a few weeks, I discovered all the critters that use llSetKeyframedMotion were frozen in the water! Resetting the script didn't get them going again, I had to delete them and rez fresh ones out of inventory. Has anyone else had llSetKeyframedMotion fail after a long time? Could there be some sort of memory leak problem that slowly accumulates errors until it locks up? Or was there a server upgrade that changed llSetKeyframedMotion and required re-starting all scripts that use it? I'm waiting for another few weeks to see if they freeze up again.

Yes, Google finds that page. That page tells me how to use the viewer in mouselook mode. HOWEVER, it does not tell me how to write a script to take advantage of mouselook mode. I recall reading somewhere that when you call one of the llGetRot routines from a prim attached to an avatar, instead of returning the rotation of the prim, instead of returning the rotation of the root prim, instead of returning the rotation of the attached avatar, instead of ANY OF THESE THINGS it returns the rotation of the avatar's HEAD. This is useful, and I assume that everyone who builds weapons knows this and uses it for aiming, like that Wiki page says. But where is the documentation that tells you what rotation you get? I care because in OpenSim, you always get the rotation of the avatar, never the avatar's head. When I report this as a bug to the OpenSim people, they say "What bug? Where is the documentation for this? Why should we change this?". I could add documentation about this, but then they would say "You just added that! We still don't need to fix anything!" I have discovered that in SL, the same thing is true for a seated avatar in mouselook mode. You can get the rotation of the avatar's head if she is sitting on your build in mouselook mode. This is useful. I'd love to document it in the Wiki, and the correct place to do that is on the page about using mouselook with an attached object. But where is that documentation? This page is interesting: http://wiki.secondlife.com/wiki/Rotation#Single_or_Root_Prims_vs_Linked_Prims_vs_Attachments but it doesn't mention mouselook mode or seated avatars. Yes, I could add those columns, but I need a reference to back those chanes up.

I have used llGetLinkPrimitiveParams to get the rotation of a seated avatar. In moselook mode the rotation returned is the rotation of the direction that the avatar is looking. I don't know where I learned this, and I need a reference to it. Does anyone know where there is documentation about all the side effects of mouselook mode? The closest reference I can find in the Wiki is in the entry for llGetRot, there is a Caveat that says "llGetRot incorrectly reports the avatars rotation when called from the root of an attached object". I thought this was done on purpose so that an attached object like a gun will fire in the direction that you are looking in mouselook mode. (Not a bug but an important feature). What I have used the mouselook direction for is to rotate the "vehicle" (not using physics or the vehicle calls) that the avatar is sitting on to face the direction that they face in mouselook.

When LL released the first version of the Marketplace (after xStreet) it had a button for managing assistant accounts. Anybody besided me remember that? I thought WAHOO! at least I can turn managment of my Marketplace store over to someone else. But if you clidked on the button it said "not implimented yet" and after a while it dissapeared completely. My workaround is to give my password to somone. Yes, it is the same password to my avatar, my main account, yes the money is all there also. Yes, I am sure I have the right person.

The Internet is full of articles gushing about collaboration in SL, but this is always about using SL to work on things outside SL. I'm trying to grow a business inside SL and having trouble collaborating with people over SL issues. For example, I can't hire someone else to manage my in-world store because the permission bits won't let her stuff products in my vending machines. I tried giving the vending machines to her so she could stuff them and arrange them, but then they paid her instead of me. I could give products and vendors to her, have her stuff them and give them back, rez them and finally have her arrange them in the store. But I end up having to give her “full perm” on stuff, then having to take it away when it comes back. This is as much work as just doing it myself! My business cannot grow if I have to spend all my time managing the store and never have time to create products any more. There must be a better way! I've also had trouble collaborating with people on building things in SL. Objects built with prims, sculpts, textures, animations, scripts and sounds from different people create lots of permission hassles. I can end up building things that I cannot sell to others. I have objects that I have full perm on but cannot back up because of the LL rules designed to prevent copyboting. The only solution I have found so far is to email all the parts to each other outside of SL so we can each pay to upload them again and acquire true ownership. Is there some way of using group ownership to solve these problems? I wondered if we should have one alternate avatar that owns everything that belongs to the business. We each log in to this one avatar to do final builds, stuff vending machines, arrange the store, etc. How do other businesses in SL deal with these issues?

I'm not expecting an exact match, I certainly don't expect the texutres to line up at the edges! I did my own approximation of the blending from rock to grass at the bottom of the sculpt. (No sand 'cause I didn't go down that far). My problem is that the colors, or the saturation, don't match. If it was the same saturation of green on both sides of the seam, I would consider the project done. I get the impression that if I painted the terrain a solid bright red, and my sculpt the same color, what I would get is pink terrain and a red sculpt. I have no control over what LL or the viewer does to the terrain, but I can change the texture on the surface of my sculpt. I was hoping someone else has done the research and could tell me what I need to do to my texture. I tried desaturating my texture map, but that leaves the desaturated rock areas the way they already are: too dark. I tried increasing the brightness of my texture map by different amounts. At 40%, the desaturated rock areas are too light while the saturated green areas are still too dark. Some combination of the two??? By the way, the picture I posted is of the un-modified surface map for the sculpt. The colors in that were unmodified from the texture map used on the terrain.

Here is a picture of one of the sculpts sized to fit into a knotch in the terrain. You can see that the terrain on both sides is faded looking compared to the sculpt. I checked and I do not have full bright on. Or shinyness, or transparancy, or glow!

I built some sculpts to enhance my terrain height map (roofs for caves). Then I used exactly the same texture maps on the sculpts that were used on the terrain. But they don't match! It looks like the terrain surface textures are desatureated, or brigtened in some way. I tried brightening my sculpt textures by 40% in GIMP before importing them. This makes the grey areas of my sculpt brighter than the similar areas of the terrain, but the more saturated green grass is still too dark on the sculpt to match the terrain. What can I do to make the textures on my sculpts match the ones on the terrain?

I'm designing my new sim and trying to match sculpts up to the terrain. As usual, any task in SL starts with experiments to find out how things really work. The Wiki never seems to have all the information that I need. I already knew that the values from the raw terrain map that you supply, the values that you get from llGround, and the terrain that the viewer displays do not match. I hypothesized that the viewer did some modification of the terrain values, perhaps to prevent “tortured”quadrangles. I tried a classic signal analysis test: I applied an impulse to the terrain system and examined the result. I set one pixel in the height map to 255 (times 0.180 resulting in a point about 46 meters tall) surrounded by pixels with a value of 120 (times 0.180 resulting in level ground about 1.5 meters above the water). I was kind of expecting that I would get four triangles pulled up around one point. To my horror, the result is a sync function! The surface of the ground rose up and down for a distance of around 6 meters in all directions around the peak! I include a picture of the result with a 10-meter rod for scale at the bottom of ths post. In a display this would be very sophisticated image processing. But I'm not sure if it is appropriate to use this on a height field. The height field is “displayed” at a much higher resolution than the original pixels. This means that the processing is visible as rings of distorted terrain rippling away from any sudden change. If I create a cliff with a sharp drop, there can be random bumps next to the edge that are sometimes 2 meters tall! I would rather that SL do no processing of my terrain map and just give me what I asked for. Perhaps I can perform the inverse filtering operation on my height maps. Put anti-bumps in the places where LL adds ringing bumps to my terrain. Does anyone know what this filtering operation is? The ringing is not symmetrical, but has a bias along the diagonal and dies off in a square pattern around the impulse. Another interesting research topic is the size of the height map. If a sim is 256 meters square then it should take a grid of 257x257 height values to describe all the corners of a 256x256 grid of rectangles. Sculpties have this problem, which is why you have to store a 32x32 quadrangle sculpt in a 64x64 pixel texture map. There is no room for 33x33 vectors to be stored in a 32x32 texture map, so they had to move up to the next size. So how did LL solve this height field problem? One way would be to define the values in the height field to be the center of each quadrangle, and interpolate the triangle corners between them. The impulse test above already answered this question. If the vertexes are cubic interpolated between height values, an impulse would produce a lower peak that was two meters wide, and it would ring positive and negative for 3.5 meters in all directions. But the impulse produces a sharp peak with ringing much farther than that. So where do the extra vertexes come from? A careful examination of my sim revealed that the vertexes along the north and east (top and right) edges of the height map were simply duplicated! This suggests that it is impossible to create terrain maps that cross multiple sims smoothly! (Unless your sims are boring and flat to start with). There should be a seam with a 1 meter wide stripe that has this duplicated value in it. In fact, there should be gaps in the seams, but since there is not, LL must have some special code to stitch the edges of sims together. Perhaps they simply steal the missing height values from the sim to the north and east. But I am trying to make sculpts that mate with the edge of the sim terrain and hang out farther. Not knowing the filtering function, I resigned myself to designing the sculpties to overlap the terrain a little and dive under the terrain. The duplicated height values on the north and east end are sticking out of the sculpties, I have to take that into account next. I went back and re-read the Wiki (http://wiki.secondlife.com/wiki/Tips_for_Creating_Heightfields_and_Details_on_Terrain_RAW_Files) for inspiration. It does have a good explanation for the multiplier scale factor. But it mentions nothing about filtering the values or dealing with outside edges. Is there anyplace else on the WEB that has more information?

When I found my table, it was not as complete as the one Rolig pointed out in the wikil I thought I had filled in more of the boxes. Here is a script I wrote that points an attached 'gun' at the nearest avatar. You can put it in a cylendar, attach the cylendar to your pelvis, and offset it (with the build dialog) so that it is to your side and above you. It will rotate with you as you walk around, of cource since it is attached. The script will make it turn to point the local z axis at the nearest avatar. Looking at the code now, I could have commened it better. Look up llGetRootPosition and llGetLocalPosition in that table Rolig referenced to find out what each of them returns in the root prim of an attached object. The -PI_BY_TWO is to get the local z axis of a cylendar to point foreward. llAxis2Rot is my favorite of all the llLibrary routines! default{ state_entry() { llSensorRepeat("","",AGENT,20.0,PI_BY_TWO,1.0); llSetText("",<0,0,0>,0); } no_sensor() { rotation rot=llEuler2Rot(<0,-PI_BY_TWO,0>); llSetRot(rot); } sensor(integer num) { vector dpos = (llDetectedPos(0)-llGetRootPosition())/llGetRootRotation(); dpos -= llGetLocalPos()-<0,0,0.50>; //convert the vector into a rotation and point that way vector fwd=llVecNorm(dpos); //vector pointing my new direction vector lft=llVecNorm(<0,0,1>%fwd); //left rotation rot=llEuler2Rot(<0,-PI_BY_TWO,0>)*llAxes2Rot(fwd,lft,fwd%lft); //rotate to face that way head up llSetRot(rot); }}

Rotations are notoriously confusing. And THEN you ad SL into the mix! SL has at least 4 different ways that rotations work: Rotating a root prim is relative to region co-ordinates. Rotating a child prim is relative to the root prim's local orientation Rotating a root prim attached to an avatar is relative to the attachment point and the avatars rotation. There is a bug in one of the LL library routines, they multiplied instead of dividing a rotation, so you have to divide twice to get around it. Animations rotate the avatar in the viewer without the server ever being able to know the region location of the prim. Rotating a child prim attached to a root prim attached to an avatar is ... I forget, but I got it working once. I built a big table of all the different effects rotation has in different situations. I'll look that up when I get home and get back to you then. (Very late tonight PDT).

Amazing! We both responded with the same example text "you're sitting on me" in our examples at the same time!

I don't like the syntax of your calls to llMessageLinked. I think you meant to say the following. The way you had it you were declaring LINK_SET to be an integer. (and 0 to be an integer). If this syntax works, it declares a new integer with the name of the LINK_SET defined constant, and new integers always start out with the value 0. (I don't have any idea what declaring 0 to be a new integer variable will do). llMessageLinked(LINK_SET,0, "", "");

Well, I don't see you calling llOwnerSay, which is probably what was sending messges to the owner. All you have to do is switch to the line below, nd the message will go to the sitter (who's key you stored in agentkey) llInstantMessage( agenkey, "you are sitting on me" );