Jump to content

Kayaker Magic

  • Content Count

  • Joined

  • Last visited

Community Reputation

8 Neutral

About Kayaker Magic

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. There is an old bug that treats NaN as a legitimate number for moving prims. This was used to impliment the old PosJump function before llSetRegionPos() was available. It looks like your prim is trying to move to NaN an being prevented from doing so by the 10 meter maximum distance that llSetPos is allowed to go. Several comments on your script: (Intended to be constructive!!!) There are better ways to move a non-physical prim, I recommend llSetKeyframedMotion(); Moving prims in a for loop is very bad form, you should find an event-driven way to do this, such as moving in a timer event. llSetPos() has a built-in delay, you can use llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_POSITION,[traveled]); with no delay. You are calculating your positions using Cartesian math, which has sigularities as you discovered with the NaN values. There are ways of calculating points around a circle that do not have this problem. One way would be to use the rotation data type to rotate a vector around in a circle.
  2. In OpenSimulator there is a problem that people call "particle starvation" and I thought that this problem did not exist in SL. The probem is caused by the PSYS_SRC_BURST_RATE parameter of llParticleSystem. The Wiki says that if you set PSYS_SRC_BURST_RATE to 0.0, it will generate particles as fast as possible. But in OpenSimulator if you do this, it will starve particles from all the other particle emmiters in the same SIM. The recomendation, in OpenSimulator, is to never set this paremeter 0, instead use 0.001 for example. A number that small produces lots of particles, usually indistinguishable from using 0.0, but it does not starve particles from other emiters. Unfortinately, the fix for this is to track down all the other particle scripts in the SIM, look at the PSYS_SRC_BURST_RATE parameters, and if it is zero, then replace it with 0.001. This is unfortunate because you may not have access to all the particle scripts in your SIM. And like I said, I thought this was a bug in OpenSumulator an not in SL, so the whole exersize may be wasted. -------- So here is a completely different suggestion, a way of getting your "flame spine" without using particles at all: How about wearing a couple of flat prims that have a flame texture animation running on them? That could look pretty cool!
  3. I've been doing things like "pathfinding" with things like fish for YEARS, since long before LL added code to do pathfinding in the server. The scrit below impliments the bare bones of swimming motion in a single prim. It moves around in the water, curves smoothly away from different boundaries. You can add a back and forth motion, add llSensor to avoid or attack avatars, put in more tests, change the distance that it looks for certain borders, change the acceleration for different obsticals, etc. Even changing the order of the tests results in different behavior. // Swimmer // A script that gets pretty smooth motion and // moves a critter around sort of like "pathfinding" in in water. // This version is an example of how to do that using the // llSetKeyframedMotion function. // // Put this script in a prim that is long in the X direction, it will swim in the // direction of it's local X axis. Paint it with a texture that allows you to // tell which way is the top (the local Y axis). // // This simple critter behaves in the following ways: // It moves in a straight line until: // moves out of the water but falls back down // avoids getting close to the bottom // turns away from the SIM edges // turns away from parcel boundary edges. // turns away from the waters edge (llGround>llWater) // // I give this code away, use it in your products for sale. float DEFLECT=0.20; //how hard things deflect me away (m/s/s) float LOOKAHEAD=2.0; //how far to look ahead to avoid stuf integer run=1; //flag indicating if I'm running or not list params=[ //make the smoke PSYS_PART_FLAGS,0 , PSYS_SRC_PATTERN,PSYS_SRC_PATTERN_DROP , PSYS_SRC_BURST_RATE,0.125, PSYS_SRC_BURST_PART_COUNT ,1, PSYS_PART_MAX_AGE,30.0, PSYS_PART_START_SCALE, <.75,.75,0>, //magenta smoke PSYS_PART_START_COLOR, <1,0,1> ]; // This function, OKfly, checks for all the places that you don't want your prim to move. // Across sim boundaries, into the ground, onto dry land. // I use parcels to create boundaries where the critter has to stay, so I test // for parcel boundaries here also. // You could test for other things, like a fish can't leave the water or a bird // can't enter water, but fish jump and birds dive so I do that elsewhere. // Nothing prevents this critter from passing through solid objects, even if it is not // phantom. But if it is not phantom it will stop when colliding with an avatar. integer OKfly(vector pos) //return true if OK to move to pos { //don't go outside the edges of the region if (pos.x<=0.0 || pos.x>=256.0 || pos.y<=0.0 || pos.y>=256.0) return FALSE; vector vel=pos-llGetPos(); float gnd = llGround(vel); if (pos.z<gnd) //don't go below ground return FALSE; if (gnd>llWater(vel)) //don't go where the ground is above the water return FALSE; //don't leave the current parcel key curpar = llList2Key(llGetParcelDetails(llGetPos(),[PARCEL_DETAILS_ID]),0); key nxtpar = llList2Key(llGetParcelDetails(pos, [PARCEL_DETAILS_ID]),0); if (curpar!=nxtpar) return FALSE; //insert other rules here, like fish not allowed out of the water return TRUE; //otherwise, it is OK to fly here! } //Single Frame motion routines // These 3 functions impliment smooth motion using llSetKeyFramedMotion // The way it works is this: // You call SFrame with a new position, rotation and time // I usually call SFrame once a second from the timer event with an updated //position and rotation. //But it works over longer times and distances. //UNLIKE llSetKeyframedMotion, here you specify the region co-ordinates and rotation! //I did it in these tree functions to make it modular, I can replace all 3 of them //with routines that work on grids that don't have llSetKeyframedMotion SFsetup() //any necessary setup { //This setup is necessary in SL, and may cause errors on Open Sim, if so delete it llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_CONVEX]); } //move the calling root prim from its current position and rotation //to the requested position and rotation in the requested time. //UNLIKE llSetKeyframedMotion, you specify the region co-ordinates and rotation! SFrame(vector pos,rotation rot, float seconds) { llSetKeyframedMotion([pos-llGetPos(),rot/llGetRot(),seconds], [KFM_MODE,KFM_FORWARD,KFM_DATA,KFM_TRANSLATION|KFM_ROTATION]); } SFstop() //stop the key framed motion { llSetKeyframedMotion([],[KFM_COMMAND,KFM_CMD_STOP]); } SFnotat() //call this from your not_at_target event { //not necessary with llSetKeyframedMotion, so this function is a NOP } default { state_entry() { llOwnerSay("reset"); llParticleSystem(params); //Start the smoke llSetTimerEvent(1.0); //recalculte movement every second SFsetup(); } on_rez(integer param) { //turn to a random direction on rez llSetRot(llEuler2Rot(<0,llFrand(PI-PI/2.0),llFrand(TWO_PI)>)); } timer() //every second, calculate a new direction to turn and move { vector pos=llGetPos(); //get my current position rotation rot=llGetRot(); //and rotation vector vel=<1,0,0>*rot; //use my direction as velocity //here are the RULES that give this critter behavior: //first (four) rule(s): Avoid the edges of things. vector xvel=llVecNorm(<vel.x,0,0>); //get orthagonal components of velocity vector yvel=llVecNorm(<0,vel.y,0>); if (!OKfly(pos+LOOKAHEAD*xvel)) //so you can pong off the edges of the sim vel -= DEFLECT*xvel; //slow down as you approach X edge. if (!OKfly(pos-LOOKAHEAD*xvel)) //checking both sides makes me vel += DEFLECT*xvel; //accelerate away from walls if (!OKfly(pos+LOOKAHEAD*yvel)) //do the same thing in Y vel -= DEFLECT*yvel; if (!OKfly(pos-LOOKAHEAD*yvel)) vel += DEFLECT*yvel; //I could use LOOKAHEAD to avoid running out of the water (I do that for the //ground below) but I thought it would be fun to allow this swimmer to jump //out of the water and fall back in float wat=llWater(ZERO_VECTOR); if (pos.z>wat) //after I have already popped out of the water, vel -= <0,0,1>*DEFLECT; //accelerate back down //When the critter gets within LOOKAHEAD meters of the ground, I start //accelerating back up. Using the ground normal makes it turn sideways //away from cliffs instead of always turning straight up. vector npos=pos+vel; //next position if ((npos.z-LOOKAHEAD)<llGround(vel)) //if my next position is too close to the ground vel += llGroundNormal(vel)*DEFLECT; //deflect away from the ground normal //I'm limiting this critter to 1 meter per second, you could go faster //but beware, llAxes2Rot requires unit vectors! You would have to //calculate a separate vector that is the normalized velocity and use that below. vel = llVecNorm(vel); //limit my velocity to 1m/sec //here I convert the velocity vector into a rotation. These steps result in the //prim always rotating to keep the head "up". Actually the local Y axis is always //parallell to the XY plane, the local Z axis is allowed to rotate away from //straight up to turn the nose to rise or fall. vector lft=llVecNorm(<0,0,1>%vel); rot = llAxes2Rot(vel,lft,vel%lft); //calculate new rotation in direction of vel //SFrame will refuse to go somplace that OKfly does not like, but I do //another test here and try to do something random to avoid getting stuck. if (!OKfly(pos+vel)) //final test: If I'm still going out of bounds, { if (llVecMag(lft)<0.5) //detect Gymbol lock! lft=<0,1,0>; //and make a hard turn in this unusual case. vel = llVecNorm(vel+lft*(llFrand(2.0)-1.0)); //randomly turn left or right lft=llVecNorm(<0,0,1>%vel); //to try to get out of edge lock rot = llAxes2Rot(vel,lft,vel%lft); //re-calc the rotation vel=ZERO_VECTOR; //stop and wait for rotation to turn me } SFrame(pos+vel,rot,1.0); //start moving and turning } //once SFrame is running, even the build dialog cannot change the position //or rotation without it being changed back. So I added this touch to stop the //critter so I could move it or rotate it, then touch start it moving again. touch_start(integer num) { if ((run = run^1) ==0) //toggle the run flag { llSetTimerEvent(0); SFstop(); //demonstrate how to use SFstop! llParticleSystem([]); //turn off the smoke while stopped. llOwnerSay("stopped"); } else { llSetTimerEvent(1.0); //the next call to SFrame in timer will start it up again llParticleSystem(params); llOwnerSay("running"); } } }
  4. Ah, you should have stressed one thing! The objects that I want to transfer, have to be marked as "next owner can transfer", or they will not transfer with the parcel. The land sold sooner than I expected, and for a while I thought I had given away the store, in the form of my vending machines. But none of them were marked TRANS so they all still belone to me. WHEW! Problem is, many prims I planed on transfering. Now I have to mark those as for sale in place and let the new owner buy them...
  5. In preparation for putting my SIM up for sale, I combined all the parcels into one, marked it for sale, including the prims, and set the price to a HUGE VALUE. I chose the value to prevent someone from purchasing the parcel, since it was the SIM I wanted to sell. In fact, I set the parcel price to the ammount I hoped to get for selling the whole SIM. Then within a day, someone purchased the parcel for that HUGE sum! Well, that's great and if she wants the SIM as well, I'll sell that to her for L$1 more since I already got the price I wanted. I wish I had a fiew minutes of warning to remove a few personal prims before they were all aquired. But this whole transaction is bothering me. Why would someone pay so much just for a parcel? This person has not tried to contact me. I am still the owner of the SIM and the estate manager. I checked her profile and she has been a resident for years, implying some experience here. So I'm wondering if this sale is too good to be true...
  6. I have a region with sim extenders that are cusom made to look like they are continuations of the terrain out into the Void Sea. I want to include these as part of the sale (yes, I have transfer permission on them). How do I include these as part of the region transfer? I see the button in setting a parcel for sale that has the option to include prims when someone buys a parcel. If I set that before the region transfer, do the prims get tansfered to the new owner with the land? Or should I set that option and then have them buy the whole parcel with the prims before starting the transfer? (If they then back out it might be a hassle to get ownership of all the prims back). I could mark everything for sale for L$0 in place, but I don't want to have to do that with every tree... What is the best practice for transfering all the prims with the region?
  7. There are products for sale in the marketplace that will tell you when your friends (or enemies) log in and out of SL. I assume you can point them at yourself. I wrote one once and had it keep statistics like how many hours spent in-world per month. My GF felt that "that thing" was a violation of her privacy, so I named the prim STALKER. I never put this up for sale because I found out there were several of them already in the marketplace under names like "Friend Finder".
  8. It is unclear to me what your Light Saber does in RL or in SL. It is difficult to imagine that it does the same thing as a movie light saber in RL, since several of the effects of Light Sabers are physically impossible in RL. Snel's Law tells what light does when crossing the boundary of a lens, it cannot make a glowing buzzing blade that extends only a meter out of the lens and cuts through solid metal. By reading between the lines of your post and looking at the pictures, it looks like your SL light saber is an optics simulation program that casts rays through simulated lenses and verifies that the lenses do what they were designed to do. I don't think you will find many people in SL who would be interested in this. I suspect that if you offered a Light Saber script or object in SL, most people would expect this to be a role-play weapon. They would expect a cool looking handle that sprouts a glowing blade when activated and makes a buzzing sound. Extra points if it changes sounds when moving, penetrating prims or passing near another light saber.
  9. I have used ixwebhosting for years, perhaps over a decade. And I have used their server, PHP, MySQL, etc. for many different SL and OpenSim based projects. They have worked well, been reliable, and the price is incredibly low. I don't see the plan I am on, but their current pricing is under $8 per month (paid in an annual lump sum in advance).
  10. On OpenSim, physics is an iffy proposistion. If this is a SIM that you are maintaining, you can use the new Bulletsim physics engine which is under active development and getting better. The old ODE physics engine is full of bugs and regularly crashes SIMs and nobody is working on fixing it. And even if the physics routines worked, llMoveToTarget doesn't move objects at a linear velocity, it moves them at a "critically damped" velocity, slowing down as it reaches the target. The only way to move a physical object at a constant velocity is to use the vehicle functions which are very complicated to use and even less likely to work well in OpenSim. You might consider instead using llSetKeyframedMotion (SKFM) wich has several advantages: It works on OpenSim 0.7.6, it moves non-physical objects, it moves objects at a linear speed, it doesn't require a debugged physics engine, and it is deterministic (unlike all physics engines, even the one in SL). SKFM accepts a list of delta positions, rotations, and times, but I usually call it with a list of one, then re-calculate the next position and call SKFM again. Sort of like llMoveToTarget but without the overhead and wierdness of physics. I published a script in the OSGrid Scripting Forum some time ago that impliments a simple flying critter. That was written before OS 0.7.6 came out and does not even use SKFM, but could be easily modified to do so. It could be modified to stick to the terrain surface, use llCastRay to try to avoid objects, etc.
  11. I know of two ways to sit multiple avatars on a single prim. I am surprised that AVsitter does not do this for you in the script. Perhaps you should contact them and find out how to enable this feature. Here is a link to an article with a script that I wrote, that script will sit an infinite number of avatars on a single prim! How many avatars can sit on the head of a prim?
  12. I don't think this is what you asked for, and it is certainly not libs. But the Phoenix family of viewers have had a pre-processor for LSL for years now that have an #include command and other things you expect from a pre-processor. I have been using this for some time, and have "libraries" of modular functions that I can just #include in a new script. The included files come off my hard drive, so I can't give someone a script written this way. (Well, you can, but they can only use the post-processed half of the script, with the comments stripped off and the included files added to the body of the code). It's not perfect, in fact it is sometimes difficult to use. It splits your code into pre and post processed listings. The LSL compiler reports errors in the post processed list, sometimes it is difficult to find where those errors are in your original code. The viewer will let you edit the post processed code, so sometimes I fix things there without realizing I'm not editing the original code and the pre-processor is going to undo all my work.
  13. By "grow" I thought the original poster meant "slowly increase in size like a plant growing", not blow up instantly. I think s/he is looking for something like: float size=1.0; //start out 1mdefault{ state_entry() { llSetTimerEvent(0.5); } on_rez(integer param) { size=1.0; //go back to 1m on rez llSetTimerEvent(0.5); } timer() { llSetScale(<size,size,size>); size += 0.1; if (size>5.0) //bigger than 5m? llSetTimerEvent(0); //stop the clock }}
  14. That “do { llSleep(30); } while” loop in your first posting made my hair stand on end! I'm glad Innula told you better, but I would like to emphasize this. Any time you are using an indefinite loop, you are violating the principles of event-driven-programming. Loops are for looking at lists, doing other things that won't take much time. You should strive to return AS SOON AS POSSIBLE from any event. I don't know how Linden Labs does it, but in Open Simulator it turns out that llSleep blocks the thread that is running your script. The simulator has a limited number of threads, so if enough scripts call llSleep at the same time, it could lock up all scripting (on Open Simulator at least). Your first posting was potentially spending HOURS in that do loop, hogging system resources to do nothing! Is there a page in the Wiki that has a list of "good programming practices" for LSL?
  15. For a long time I have had this problem where some of my texture maps turn white on my viewer. They are not white to anyone else, just me until I clear the cache. It seems to happen most often when I am going back and forth between different grids. I thought it was caused by different texture maps in different grids having the same UUID, but I'm told that is astronomically unlikely. Well, I found a way to force the problem to happen now! I have a script that loads a series of sculpt maps to animate the head of a critter. I load them by UUID so that multiple copies of the build use the same texture maps and all the nearby viewers only have to load them once. I also paint the sculpt maps on the surfaces of a hidden prim to prevent them from being forgotten by the viewer cache when not in use for a minute. I have the same build and the same script running on several grids, so I have an #ifdef in the code to load a different set of UUIDs on each grid. (I use the Firestorm pre-processor for this sort of thing). Well yesterday I updated the script on one grid (InWorldz) without changing the #define and built it with UUIDs from another grid (Virtual Highway). The head of my critter turned into a blob and I immediately realized my mistake. But as the script re-loaded the sculpt map over and over, the blobs turned into the correct shapes, even though the UUIDs were from a different grid! The viewer had the sculpt maps from the other grid still in the cache and for a while everything worked! I re-built with the correct UUIDs, and the head of my critter turned back into a blob. I waited for the local copies of the sculpt maps to get into the cache but some of them never did. I looked at those sculpt maps in inventory and saw that they had turned white! The only way to get them back was to clear the cache on the viewer and re-log. I'm not sure why this should be happening, I was loading the bad texture by UUID and for a while it was still in the cache so I see why things temporarily worked. Then I loaded the correct texture, also by UUID. It should have seemed like a completely new texture. The only thing the two textures had in common was the name in inventory. Somehow the viewer decided to associate the correct UUID with the contents of the bad UUID which was invalid in the current grid so a white texture map was substituted. Yeah, I suppose I should submit this as a bug to the Phoenix/Firestorm people.
  • Create New...