Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Badena

  • Rank
  1. Hi Adding something minor... gRepeat = <1.0, 1.0, 1.0>; // <x, y, z> : x is the horizontal repeat, y 1.0 is the vertical repeat, z remains unused. So I usually type <1.0, 1.0, 0.0> to remind me that this is for repeats and not for the color of white. gOffsets = <1.0, 1.0, 1.0>; // I would rather type <0.0, 0.0, 0.0>. <1.0, 1.0, 1.0> (or <1.0, 1.0, 0.0>, respectively, since z remains unused), shifts the whole texture completely all the way horizontally und vertically, the result is then the same as <0.0, 0.0, 0.0> which does not shift the texture at all. Too many texture shifts may result in undesired results in laggy areas. I strongly recommend Rolig Loon's suggestion to always use llList2String() and typecast it to integer, float, vector... whatever is needed. Stupid me suffered too long from believing you can rely on that other llList2....() work. No. No-no.
  2. Thank you Wulfie I rezz an object <golf ball launcher> at my position, it is non-physical, phantom tho. Sensor is llSensor("", "", PASSIVE|SCRIPTED, 5.0, PI). The workaround I just found is using llGetParcelPrimCount with PARCEL_COUNT_GROUP.
  3. I just found out that llSensor in a hud I am wearing does not detect objects I rezz, objects belonging to me, created by someone else. Sigh. Surprise, surprise. They are rezzed, not attached. The pages about llSensor dont tell. I probably belong to the species who should not do scripting but I would be very grateful if someone can tell me if that behavior of llSensor is known or if I am too [...fill in the blanks...] . Workarounds are welcome. llGetObjectDetails does not apply since it requires an UUID to sail in the sea of details, and every object is born with a fresh brand new ID which cannot be forseen. Thank you in advance for your comments
  4. Great, thank you I understand the matter now much better I found a way to get into the loop of a timer btw. When the timer in its loop is "forced" to grab a string from prim description, the script can deposit a string in the prim description and thus the timer changes its behavior according to the new info . Sounds useless, why not stop and restart the timer. But it is useful when you have a timer running waiting until a rolling golf ball comes to a halt where at the same time the player is moving. Actually a sensor runs first to detect the no-mod ball and hands over the ball UUID to the timer who in turn waits until the ball stops from where the distance to the player is checked...
  5. The widely used solution for a unique channel of an object is key objectKey = llGetKey(); integer channel = -1 * ("0x"+llGetSubString((string)objectKey(),-8,-1)) using the last 8 digits of its unique key. S a m e code for individual negative channels. Just keep in mind that every time an object is rezzed it creates a new individual key. . So the mother sends on her -99 channel, and the children reply on individual channels, loaded with exactly the same script, sending first their own channel on the common -99 channel.. The mother might want to store names and channels. Children answers can be written with an identifying part such as <prim name> + "no" or <objectKey> + "no" separating the identfying part from the answer upon arrival
  6. Rez a prim, put this script in, and touch it integer counter; default { touch_start(integer total_number) { counter = 10; // chosen amount of living time in seconds llSetTimerEvent(1.0); // setting timer to the interval of a second } timer() { --counter; // counter preceded by 2x minus dashes llSetLinkPrimitiveParamsFast(0, [PRIM_TEXT, (string)counter + " sec", <1.0,1.0,1.0>, 1.0]); { llOwnerSay("KABOOOOUMMMMMmmmm....."); llDie(); } } }
  7. Ahhh ... yes, you are right The problem is caused by a workaround to overcome the 64m limit of llMoveToTarget(). I had the idea to use a while loop with the norm vector, thus dividing whatever distance in fitting bits of sections. My avi walks then smoothly even across large distances within a region. Orientation on a golf course is a problem, to find your way to a certain tee box. So I can walk to any tee box in a region, with arriving in its vicinity. A manual stop is helpful when something blocks the path. Here comes the script (The menu is based on prim buttons). integer distance; integer distancePrevious; integer link; integer switch = FALSE; vector target = <128.0, 128.0, 24.0>; vector vGoTo; default{ touch_start(integer n){ link = llDetectedLinkNumber(0); if(link == 33){ switch = !switch; if(switch){ distance = llRound(llVecDist(llGetPos(), target)); distancePrevious = 1000; // freely chosen for the start of the loop, larger than the distance to the target while(distance > 2){ if(distancePrevious != distance){ vGoTo = llGetPos() - 5.0*llVecNorm(llGetPos() - target); // walking 5m in 5seconds llMoveToTarget(vGoTo, 5.0); llSleep(5.0); llStopMoveToTarget(); distancePrevious = distance; // keeping the current distance distance = llRound(llVecDist(llGetPos(), target)); // calculating the new distance } } } else{ // neither of those work llStopMoveToTarget(); llResetScript(); // what works is to reset this script from another script with llResetOtherScript(<ThisScriptName>); } } } }
  8. I encountered the problem that once my avatar was launched to go to a location by llMoveToTarget() from a hud script she could be stopped by llStopMoveToTarget(). The script did not respond to any inputs as long as target has not been reached. The workaround I finally found in order to manage manually an early stop is (1) to launch llMoveToTarget() in a separate script, and (2) to stop the motion at any time with llResetOtherScript(<script name where the llMoveToTarget is in>). Hope this is of some help
  • Create New...