Jump to content

Badena Atheria

Resident
  • Posts

    14
  • Joined

  • Last visited

Reputation

1 Neutral

Recent Profile Visitors

177 profile views
  1. I am sorry that I have been so unclear to explain my problem. The land is set to group A. I wear the tag of group A. I put on the hud and it is set to group A. So far all normal. I log out keeping the hud on. I log in and now the unexpected happens - the hud changes always to group: none. I need to detach it and wear it again to set it to the group. I haven't experienced this with any other hud.
  2. I recently made a hud where I found out that it does not take the group of the land although I do wear the tag. Only when I detach the hud and put it back on it is set to the group. However, when I log out and come back in, the hud switched back to no group. Settingt the group in the edit window does not work either. Only detach and reattach works, just for the present session only. Any help is greatly appreciated, thank you
  3. To put a longer story short: Having an attached hud as a link set, two scripts in the root prim. Communication between the two scripts are usually done with llMessageLinked(....) and link_message(...). For some reasons which do not matter here, I found as a reliable alternative solution that one script writes the data in the name or description field of a child prim. So that the other script can read the data at any other time. So far so good. Imagine a simple TRUE/FALSE example, here in abbreviated form. The script wrote the state TRUE or FALSE into the PRIM_NAME field as a string 1 or 0. This switch caused the same and/or the other script doing or not doing something by reading 1 or 0 from the PRIM_NAME field. Worked fine. With growing complexity of the scripts, however, it did not work anymore. 0 or 1 were not read properly. I checked with llOwnerSay("Tell me if 0 or 1 is in the PRIM_NAME field"). It proved that the field had always the correct entry. Now comes the strange thing: Obviously only because the content of the field was used with a function, the data was read corerrectly, when I removed llOwnerSay(...) the script went back again not recognizing a change in the name field. I think the same happened with other text entries as well, only that I had not been fully aware what was going on until I found out about it today with checking a simple switch. A similar thing happened btw with a 1024x1024 texture, a chart divided into 10x10 fields with a letter in each field. Moving from one letter to the other by changing the offset of the texture moved the texture, but despite texture refresh it did not show in the viewer (Firestorm). This was proved by reading the current offset of the texture by a script, which gave the correct new offset, while the viewer still showed the texture with the previous offset. Just want to share this because knowing it may safe a lot of time.
  4. If you consider to do something with the output rather than reading like llMessageLinked or Email or http://.... Take into account that these functions need time or are limited in the amount within a minute to avoid spamming.
  5. Reading any number of elements from a list can be done with a loop (make sure that the elements are not longer than 255 characters before adding them to the list): list myList = ["255", "255", "255"]; integer length = llGetListLength(myList); integer i=0; for(i; i<length; ++i) { llOwnerSay(llList2String(myList, i)); } llSay: anybody around you can see the text poured into chat. llOwnerSay: only you can see the text. if you want to read the elements line by line every touch shows the next line and starts over again if end of list is reached: integer counter = 0; list myList = ["251", "252", "253", "254"]; default { touch_start(integer n) { integer length = llGetListLength(myList); llOwnerSay(llList2String(myList, counter)); counter++; if(counter == length) { counter = 0; } } }
  6. 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.
  7. 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.
  8. 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
  9. 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...
  10. 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
  11. 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(); } } }
  12. 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>); } } } }
  13. 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...