Jump to content

Rufus Darkfold

Resident
  • Posts

    300
  • Joined

  • Last visited

Everything posted by Rufus Darkfold

  1. I'm going to be chopping out the name "Resident" where it appears in the radar output. That should help with newer avatars at least. The names could also be sent to chat. That way is particularly nice if you send slurls to their profiles, e.g: secondlife:///app/agent/<agent key>/about Recent SL viewers will display the avatar name underlined as a link instead of the slurl itself.
  2. I have updated it to account for root prim rotation. it may work better for you now. The bounding box itself is not rotated, but its center is relative to the root prim's position and rotation.
  3. .4 - Allow more control over prim usage. Leave the background screen (root prim) alone. .3 - Implement xyz controls .2 - Prevent disappearing dialogs
  4. The following is submitted in the interest of helping us all be good neighbors. It is easy to encroach by accident when one is building in the sky and cannot see property lines. This can lead to annoyed neighbors, parts of the build getting returned, and ARs. This script checks the bounding box to ensure that it is entirely contained in one parcel, and reports any encroachment on other parcels by chat. If the object crosses a sim, that is reported by chat, and the portion in the adjacent sim is not checked for encroachment. When the object is moved or resized or clicked on, it is checked again. It may be necessary to click after moving the object, since the moving_end event does not always fire. This script could be removed from the platform once it is sized and placed, if it is not expected to be moved again. A more elaborate encroachment checker is included in the platforms rezzed by primcontrol /// Check for encroachment on other parcels on move or resize. list details; vector newsize; vector newpos; rotation newrot; float fudge = .05; // bounding box seems to be .1x.1 bigger than the object // Returns parcel ID for current location (region coordinates) // The rest of the "details" list is also used for reporting key parcelid(vector pos) { details = llGetParcelDetails(pos, [PARCEL_DETAILS_ID, PARCEL_DETAILS_NAME, PARCEL_DETAILS_OWNER, PARCEL_DETAILS_GROUP]); return llList2Key(details,0); } // Is this object encroaching on another parcel? check_encroach() { integer encroached = 0; list boundbox = llGetBoundingBox(llGetKey()); newpos = llGetRootPosition(); newrot = llGetRootRotation(); vector lo = llList2Vector(boundbox,0); vector hi = llList2Vector(boundbox,1); llOwnerSay("Bounding Box is " + (string)(lo) + " to " + (string)(hi)); lo = newpos + (lo * newrot); hi = newpos + (hi * newrot); float t; if (lo.x > hi.x) {t = lo.x; lo.x = hi.x; hi.x = t;} if (lo.y > hi.y) {t = lo.y; lo.y = hi.y; hi.y = t;} if (lo.z > hi.z) {t = lo.z; lo.z = hi.z; hi.z = t;} llOwnerSay("Bounding Box is " + (string)(lo) + " to " + (string)(hi)); lo.x = (float)((llFloor(lo.x + fudge) / 4) * 4); // round down to next lower multiple of 4 lo.y = (float)((llFloor(lo.y + fudge) / 4 ) * 4); // round down to next lower multiple of 4 hi.x = (float)(llCeil((hi.x - fudge) / 4 ) * 4); // round down to next lower multiple of 4 hi.y = (float)(llCeil((hi.y - fudge) / 4 ) * 4); // round down to next lower multiple of 4 llOwnerSay("Checking from " + (string)lo + " to " + (string)hi); key thisid = parcelid(newpos); if (llList2Key(details, 2) == llGetOwner()) { llOwnerSay("You own this land"); } else if (llSameGroup(llList2Key(details, 3))) { llOwnerSay("You are a member of the group secondlife:///app/group/" + llList2String(details, 3) + "/about"); } else { llOwnerSay("You are neither the owner nor a group member. Your build might be returned"); } if ((lo.x < 0.0)||(hi.x > 256.0)||(lo.y < 0.0)||(hi.y > 256.0)) { llOwnerSay((string)newpos + " crosses a sim boundary"); encroached++; } vector p; for (p.x = lo.x; p.x < hi.x; p.x += 4.0) { for (p.y = lo.y; p.y < hi.y; p.y += 4.0) { if (parcelid(p) != thisid) { encroached++; llOwnerSay("Encroaches @" + (string)p + " on " + llList2String(details,1) + " owned by secondlife:///app/agent/" + llList2String(details,2) + "/about" ); } } } if (!encroached) { llOwnerSay("Entirely contained in parcel " + llList2String(details, 1)); } } // Call it whenever we move or resize or get touched. // Note that the moving_end event doesn't always fire. Touch to check if it doesn't. default { state_entry() { check_encroach(); } on_rez(integer start) { check_encroach(); } moving_end() { check_encroach(); } changed(integer what) { if (what & CHANGED_SCALE) { check_encroach(); } } touch_end(integer num) { check_encroach(); } } updated for better accuracy at the margins. updated to account for root prim rotation.
  5. Given that the purpose of this forum is to discuss scripting and to help each other with scripting questions, it is unfortunate and rather baffling that LL seems to have run off its most knowledgable and helpful contributor.
  6. Since it was a button I couldn't place the script in the root of the HUD. Why not? The root prim can detect touch events in child prims, and manipulate them almost any way it wants to. With all the new link functions, there is hardly any need for scripts in child prims anymore. Dialogger would be an example of this. Feel free to look at, critique, and steal the code. It's open source, so you get to do that. All you have to do is join the Dialogger/Primcontrol/ChartTracker Beta
  7. That's a nasty bug! I can't believe they haven't fixed it in over 2 years. Have the Lindens been willing to fix content that is damaged by this bug? That would be enough to put me off the whole idea of renting on an "estate". I'll stick to mainland!
  8. Beta 3 is now available. http://community.secondlife.com/t5/LSL-Scripting/Free-primcontrol-HUD-Easy-Prim-Torture-Beta-3-Avaiable/m-p/1092569/highlight/true#M5485 A couple of minor changes for beta 3: The background is no longer darkened while dialogs are displayed. The caller will have to do this if they want it. Text labels will not display if they have more than 3 dashes. This allows UUIDs to be used for textures without having them display (ugly), and allows the labels to be suppressed by using names like --foo--.
  9. I don't know the answer the the first question (I have used every particle system parameter EXCEPT PSYS_SRC_TARGET_KEY), but to turn the particle system off, give it an empty list: llParticleSystem([]);
  10. Miranda Umino wrote: Change SLURLTeleportDirectly at true Make avatars teleport merely from gazing upon thee.
  11. It won't move by itself then, but you can move it in your touch event if you detect that it is being dragged more than some tiny amount. I use this in my HUDs so I can more them around on the screen easily. (though note the llDetectedGrab is rather broken for HUDs, often (but not always) returning negative coordinates due to the current local position being subtracted twice).
  12. I think you would need a bot to give to selected avatars regardless of where they are. The "pigeon" would not be able to reach private estates, and even on mainland it would run afoul of no-object-entry restrictions.
  13. Kaluura Boa wrote: Meaning: This llTeleportAgent() function is already gridwide. :matte-motes-evil-invert: I think I am going to have some fun (and frustration) trying to find the syntax... It compiles with the syntax give here: http://wiki.secondlife.com/wiki/LlTeleportAgent but it doesn't do anything when I execute it.
  14. I'm experimenting with building some out of flexiprims, animating them by varying the x/y/z force, tension, drag and softness. That lets the clientside do most of the work.
  15. Is there any reason this could not be an attachment? That will automatically cause it to follow you and face the right way, even without any scripting. It does not have to be physically touching you, as long as it is within linking distance.
  16. Monti Messmer wrote: …Tails either are physical moving with wind and avatar movement or animated with a script… I would expect the tail to be a flexi prim. Wnd is one of the flexi parameters.
  17. You could use a smaller step size to make it less jerky, but if you want it really smooth it has to be physical. The above was true when I posted it, but no longer. Use llSetKeyframedMotion
  18. I would expect stopped scripts to be faster at sim crossings, since their state is not sent across to the new sim. I would also expect a small improvement in message processing with fewer scripts having to look at the messages. I would not expect the difference to be noticeable unless there were quite a few scripts. Do these seem like reasonable expectations? Has anyone actually benchmarked this somehow?
  19. If the script is disabled and the sim resets (or the object crosses into another sim) that can reset the script. https://jira.secondlife.com/browse/SVC-26?
  20. You can repeat this a thousand times, and you'll get the same results every time, no chaos, no randomness, no Plinko effect. The physics remain entirely predictable, each time. I'm seeing quite a bit of randomness in my experiments with SL physics. Maybe it's the wind. Physics could be augmented with random values applied to llPushObject if things seem too deterministic. ETA: It's also worth noting that even if you could get the Plinko board to work physically, you really wouldn't want to. Physics calculations take place on the server. The more collisions it has to deal with, the slower it runs. Sufficiently complex physics problems can cause serious lag, and can even crash a sim. How do combat sims function at all then, with all those weapons and bullets flying about and colliding with things? Even fairly quiet sims will have plenty of collisions. We generate collisions every time our avatars walk somewhere.
  21. There is an LSL mode in emacs. emacs runs on just about everything.
  22. Rufus was a bat in a children's story that painted himself all different colors and flew around in the daytime.
  23. I have had to slice and dice a torus to make the buttons for my HUD. A box would have done fine, but I need to slice it so the hovertext appears on the button instead of above it. It needs to be done by script because the HUD has a bank of generic prims that get configured for whatever the HUD wants to do at the moment. It works, but I'm sure it's more overhead on the sim than a sliced box would be.
  24. It wouldn't have to be directly under, as llGround takes an offset vector as an argument. The trouble with using llGround is that if you are in a building, it will put it on the ground in the basement, which usually isn't where the avatar is.
×
×
  • Create New...