DoteDote Edison

There is a 60 second timeout if no response is received. From the wiki: Status 499 Requests must fully complete after 60 seconds, or else the response will be thrown away and the http_response status code will be 499. Besides the usual HTTP status codes, SL implements a special status code 499. This code isn't generated by the remote web server but by SL's servers (see Simulator_IP_Addresses), it can indicate: Request timeout (60 seconds)

More of a question for the mesh section probably. If you made the mesh, check that the normals are inside-out? Also, check the LODs to ensure there isn't an LOD model that's incorrect. Seems that invisible meshes is common; search for "second life invisible mesh" for better advice. This is a link to an explanation about face normals: https://community.secondlife.com/forums/topic/437557-invisible-inside/

Ah, that makes more sense. The process would be the same, just replace the llGetPos() in llVecDist with a second call to llGetObjectDetails(), only using your own id instead of the id from the listen() event. Basically, store your id/key into a global variable when the script starts using llGetOwner(). Each time the script hears something, get your position and the position of the speaker using llGetObjectDetails(), and use llVecDist() to get the distance between your position and the person speaking.

Interesting question because if the script is attached to you and if it can only hear chat within 20m, and if you set it to ignore anything within 20m, then everything it hears will fall into the 20m range and thus be ignored. Nevertheless, to get the distance of the avatar speaking, use "list details = llGetObjectDetails(id, [OBJECT_POS])" to get their position. "id" is the key of the avatar returned by the listen() event. That function will return a single-item list, so convert to vector using "vector pos = llList2Vector(details, 0)". Then, do "float distance = llVecDist(llGetPos(), pos)" with llGetPos() as your position. "If (distance > 20.0) llOwnerSay()".

I don't know the context of your situation, but one way is to use llGetAnimation(llGetOwner()) in an attached prim. SL default animations are; "Standing" if not sitting, "Sitting" if sitting on a prim, or "Sitting on Ground" if sitting on the ground. Of course, any AO usage will complicate the result. If the animation name is "Sitrting" then TRUE, you're on a prim, else if it's "Sitting on Ground", then FALSE, you're not sitting on a prim.

You could minimize testing by only doing so when the matching CHARS index is not found (equals -1). The FURWARE script already performs that test but assigns index 68 (a "?") on NOT FOUND. Instead, use that opportunity to jump out of the loop and send a link message back to the referring script requesting a safe name.

Like Wulfie says, the problem isn't LSL-related, it's just that the Furware Text font texture only includes certain characters, not a full set of every possible fancy character. You can see which characters are supported by viewing the entire font texture, or by outputting the CHARS string to chat like below. If the character doesn't exist in the set, you get a question mark. You can create your own font texture and replace the lesser-used characters with characters more commonly used in names, then update the CHARS string with the same new characters. Typically, the script is given a string to display, looks up each character in the CHARS variable to get its index, and calculates the texture scale/offset to frame that single character. abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789.,:;!?"'´`^~+-*/\|()[]{}<>=@$%&#_ àáâãäåæªçðèéêëìíîïñòóôõöøœºÞšßùúûüýÿžÀÁÂÃÄÅÆÇÐÈÉÊËÌÍÎÏÑÒÓÔÕÖØŒþŠÙÚÛÜÝŸŽ¢£€¥§µ¡¿©®±×÷·°¹²³«»¬…‹›– ¼½¾™•┌┬┐┏┳┓╔╦╗─╴╷╻ ┯▲◀▼▶○◔◑◕●├┼┤┣╋┫╠╬╣╺━╸│┃║┿↑←↓→↺↻☐☑☒└┴┘┗┻┛╚╩╝ ═ ╵╹ ┷┠╂┨↕↔♀♂⚠ℹ❌⌖∡⌛⌚♪♫ ♠♣♥♦⚀⚁⚂⚃⚄⚅✔✘☺☹■◾▬▮█

Write the variable to the description of the prim, then llResetScript(). If you want to conceal that variable, write it, reset, then get description, then replace description with empty or whatever else. In other words, ditto to the comment above.

What makes the angle at the pointer relative? I see you can get the angle - or bearing (pink line) - from the table to the person or the person to the table, but I'm not sure how you associate the seemingly arbitrary rotation angle of each individual object based on the other.... unless it's calculated based on the bearing angle between the two objects? Don't you need another variable such as: child forward is 50% of the angle between green and pink?

This is a grid-offset game, so math can help. First, re-link them all properly so that the bottom left is link 2, then to the right is link 3, 4, 5, 6, and the next row up starts at 7 and so on. Now you can calculate the grid position of the touched prim. Set X and Y variables (or a vector) to store coords of the touched prim. vector.x = (linknum - 2)%5+1. The minus two compensates for the root prim and the plus one makes the grid start at 1,1. That gives X a value 1-5 per five columns. vector.y = llFloor((linknum-2)/5)+1. This gives Y value 1-5 with the bottom row at 1 and the top row at 5 (llFloor() rounds down). So now, every prim has unique coordinates. Assign coordinates to your "winning" prim too, then, as Wulfie suggests, use llVectDist() to calculate the distance between then touched prim coords and the winning coords. if that equals 0, then you have a winner, else colder the greater the distance.

There's a way to do it, depending on the stream service/source and whether or not you can include a time parameter with the video url. Suppose you're watching a long youtube clip. With youtube, you can append &start=[seconds] to the url to indicate how many seconds into the clip to start. So, when a movie first plays, your script in SL would do a llResetTime(). That resets an internal script timer (not to be confused with the normal timer event). If a friend comes to the party 30-minutes late, you could program a "re-sync" button on your media player that calls llGetTime() - which would be the time in seconds since the script reset the time when the movie started. Using that time value, re-request the media url with the added &start=1800 (1800 secs = 30 minutes). The movie may glitch a bit for everyone else, and maybe replay a second or two, but worth it to have your late-coming friend in-sync with everyone else. For auto-switching, I think you'd need to either program the run-time for each clip and use the SL script to request a new url when the time is up... or depending on the streaming service, create a playlist on that service and play the playlist as the parcel media url. Check this link for Youtube's url parameters (note "playlist" and "start"): https://developers.google.com/youtube/player_parameters

I commented out the user function and uncommented each llTargetOmega() separately... I'm in Morris Sandbox if you wanna stop by. Region Morris.

I just finished a project that successfully calls llTargetOmega() in a timer(), so I took your script to Morris for testing. After 100 clicks, 50 first omega, and 50 second omega (with ChangeRotation() floated), it worked every time. Since this is client-side, I'm on the standard SL Viewer 6.4.8.548890.

The simple solution is to A) append 1, 2, 3, etc. to the end of the button name as suggested above (fiddle with leading spaces to keep centered), or B) only use one button and apply the result to all receivers. As you stated, using UUIDs as button labels is meaningless to the user... well, two buttons that do two different actions but use the exact same label can also be meaningless. How would the user know which button goes to which item? Adding a number (or letter A, B, or anything) would help the user to differentiate the two buttons and it makes the scripting problem go away. In your unique scenario, if you really really needed to use multiple buttons with the 'same' label name... you could possibly substitute the "O" character with "0". For instance; "FOOD BOWL", "FOOD B0WL", "FO0D BOWL". But your initial thought is correct, there is no way to get two different actions from two identical messages.

If you’re getting Stack Heap Overflow, you need to pinpoint where that occurs within the script. Add an llOwnerSay() as the first line of every event that will say the name of the event. Also add them to any user function, and at the beginning of every loop, right after the “for”, “do” or “while” line. if you add those everywhere, you’ll see in chat where the script was when it crashed. Insert more detailed llOwnerSays which output variables or llDumpListToString() if there’s a list. After the next crash, you should know exactly the cause.