Wulfie Reanimator

llSensor has a lot of limitations, just like llCastRay. So here's a combination that works much like a sensor, but only looks for one target. integer CastCone(key id, vector direction, float radius, float arc) { vector start = llGetPos(); vector target = llList2Vector(llGetObjectDetails(id, (list)OBJECT_POS), 0); vector length = target - start; if (length*length > radius*radius) return (FALSE); float angle = llRot2Angle(llRotBetween(direction, length)); if (angle > arc) return (FALSE); list ray = llCastRay(start, target, [RC_DATA_FLAGS, RC_GET_ROOT_KEY, RC_REJECT_TYPES, RC_REJECT_PHYSICAL]); if (llList2Integer(ray, -1) > 0 && llList2Key(ray, 0) != id) return (FALSE); return (TRUE); } Example use: default { touch_start(integer total_number) { llOwnerSay("Test"); integer result = CastCone(llGetOwner(), <1,0,0> * llGetRot(), 30, 45 * DEG_TO_RAD); llOwnerSay((string)result); } } Replicating llSensor behavior (returns a list of avatar names inside cone): default { touch_start(integer total_number) { vector direction = <1,0,0> * llGetRot(); list agents = llGetAgentList(AGENT_LIST_REGION, []); integer i = llGetListLength(agents); list detected; while (~--i) { key agent = llList2Key(agents, i); if (CastCone(agent, direction, 30, 45 * DEG_TO_RAD)) { detected += llKey2Name(agent); } } llOwnerSay("Found: " + llList2CSV(detected)); } } So, essentially, the CastCone function will return TRUE if the target (avatar or object) is inside the cone and there is direct line of sight to the target. It will return TRUE when the ray hits or misses the target. This is because moving targets may have changed position since the start of the function. If the ray hits something that is not the target, it will return FALSE. It only uses one ray and only if the target is already known to exist inside the cone. This makes it very efficient even if needed to use repeatedly. What I'm too lazy to do (and would like to see) is similar functions for boxes (BoxCast), especially ones that aren't positioned on the source object.

I would say llSensor is way worse than llGetAgentList, even if you have to do a bit of math yourself. For example: integer CastCone(key id, vector direction, float radius, float arc) { vector start = llGetPos(); vector target = llList2Vector(llGetObjectDetails(id, (list)OBJECT_POS), 0); if (llVecMag(target - start) > radius) return (FALSE); rotation rot = llRotBetween(direction, target - start); float angle = llRot2Angle(rot); if (angle > arc) return (FALSE); return (TRUE); } This is llSensor without an actual sensor (or distance limits), but it only detects a specific target by UUID (which you would get from llGetAgentList). You could add a llCastRay into/after this to check if there is line of sight. Edit:

I'm not sure about the missing physics issue, but don't analyze it if you're using a custom physics mesh because that will create a new and different physics shape, which might have holes or something in it.

Yes, but if you read the thread, KFM was already deemed unsuitable for this case.

Gaming policy violation does not apply to PaleoQuest or any other LL game. You can't use that to report cheaters, LL will just ignore the report. Gaming Policy refers to skill-gaming or "gambling regions" with slot machines and the like.

If you absolutely want to avoid llCastRay and the land has rezzing enabled, you could have an object that follows your camera's position/rotation, and uses llSensor. Otherwise you're stuck with a timer and multiple llCastRay calls, so you can create a cone-shaped detection area.

This would indicate that you messed something up. Simpler mesh doesn't have higher LI. (You should always bake high-poly to low-poly in the first place.) When you are importing mesh, look at the different weight values. If the download weight is high, make the lower LODs simpler. If the server weight is high, include a simple cube for the physics shape.

It's really unfortunate that we have 4 priority levels but realistically only 2 of them are usable/used, unless you rely on unsupported features.

How does disabling manual sitting help with any of these? Edit: NPV?

Yes, attachments have no physics shape that's used. That said, I would still highly recommend that you use a solid cube instead of a single triangle. You won't win anything by going the triangle route, it's not "less laggy" by any measure.

When you upload a video to Youtube, it's required that you declare your video either "made for kids" or "not made for kids." You have to pick one, there's no default option. The embedded disclaimer is unnecessary and not something required by Youtube.

To be fair, modern AOs don't work like this. You don't need an AO with a timer that checks what the avatar is doing to play an appropriate animation. We have the ability to replace the default animations, in a way that doesn't require any scripts for them to work. Even the old method shouldn't cause an avatar to randomly play another animation and then stop it. It's hard to guess what the real cause could be, based on a vague description of "avatar stands up then sits back down." A video showing it would be much better.

The collision shape of avatars depends on the state of the avatar. A free-standing avatar is top-heavy and coffin-shaped. A ground-sitting avatar is a pyramid with a flat top. An avatar sitting on an object is somewhat "wall"-shaped. http://wiki.secondlife.com/wiki/File:Avmeshforms.png http://wiki.secondlife.com/wiki/File:Ray_cast_example_07.png

I think you missed the part where he said "this is what avatars should look like." They aren't avatars, that wasn't the point. As for my previous comment, it was very tongue-in-cheek. I agree with everything that was said but this is also kind of preaching to the choir.

There's a looooot of things you can use scripts for, so I don't think there's necessarily that one thing you can learn that's generally applicable, besides general problem-solving and understanding the flow of events. I guess the most universal/useful thing is knowing how to build/manipulate lists. It really depends on what kind of things you want to make. If that's particles, learn particles. Firestorm has a built-in particle editor which lets you see how different settings affect their behavior instantly.

Rotate the object before exporting.

Script reset wouldn't exactly be practical, but re-rezzing seemed to work as well as setting a new memory limit. Why is it like that?

You can hold Shift to select multiple objects, and move them at the same time while keeping them exactly relative to each other. I don't think that's "a nightmare," but...

But to be fair, the color red is a strong part of Coca Cola's branding. When I think "Coca Cola," I immediately see the distinct red. (Or black if you say CC Zero.) Similarly I can recognize those labels from any distance just based on the vague white-on-red or white-on-red-on-black colors. When I think Second Life, I don't necessarily associate green with it -- at least not as strong as the other example. Similarly I would be much quicker to recognize the SL logo from the shape of it rather than color. That said I preferred the soft color gradient rather than flat bright blue. I like minimalist design but I don't like it as a global trend.

Walk into the parcels you rented and open the "about land" window. You should be able to see how many prims are available/used. Unless multiple people are using the same parcel (which would point to possibly scummy behavior), the amount of prims available is based on the size of the parcel, not the rest of the region. The reason why it might point to scummy behavior is that they can over-book the parcel with more tenants than can realistically share the prims, and even with two tenants the other person can hog everything and leave you nothing.

Easily proven, too: default { state_entry() { string kb = "1024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024102410241024"; string memory; integer i; llSleep(0.022); llOwnerSay(llList2CSV(["Used", llGetUsedMemory(), "Free", llGetFreeMemory()])); while (i++ < 25) { memory += kb; } llSleep(0.022); llOwnerSay(llList2CSV(["Used", llGetUsedMemory(), "Free", llGetFreeMemory(), "String", llStringLength(memory)])); memory = llGetSubString(memory, 0, 0); llSleep(0.022); llOwnerSay(llList2CSV(["Used", llGetUsedMemory(), "Free", llGetFreeMemory(), "String", llStringLength(memory)])); } } [08:34:42] Object: Used, 9080, Free, 56456 [08:34:42] Object: Used, 60280, Free, 5256, String, 25600 [08:34:43] Object: Used, 9082, Free, 5256, String, 1 First part is the easy part, appending to a string. This technically requires a reference to itself / allocating more memory and copying the old string to create a new string. Then we have a string that's 25600 bytes, with only 5256 bytes of free memory left. Then we pass the massive string to llGetSubString which would exceed our memory allowance since the function receives a separate copy of the 25600 byte string. The function does its thing and the string is replaced with a smaller string. The llSleeps are there to let the garbage collector run before llGetUsedMemory. Without them the output is inconsistent, but the script never crashes. Edit: One thing I didn't notice is that "free memory" is still reported very small. Interesting... It's not recovered even after sleeping 10 seconds or checking from another event.

To be fair, there's a bit of a difference between mommy's Facebook and your actual financial safety-net. My bank has had mandatory two-factor authentication for as long as I've been alive, in the form of a physical "number card" with like 300 number-pairs, from which the bank asks you to fill in a specific number. Only recently they added a mobile option which is less of a hassle. 2FA as an option is the modern standard for good reasons. With 2FA I could give you my password and you still couldn't log in. People are dumb. You can always exploit people, but 2FA makes it just a little bit harder for those who want it. Do you even have stats to back up the "miniscule" rates, or is it just one of those "it hasn't happened to me or my friends or I never hear about it" things? People don't generally steal accounts to keep them, because they know they can't. They steal them for the money and leave. Some might temporarily use the account for something like spamming, or trying to resell the account, but I would imagine those are less common because spamming is easier with new accounts and reselling can't be that profitable since LL will lock the account anyway.

I'm not sure if AVsitter has something specific for this, but a sitting avatar becomes a part of the object they sit on and can be moved just like any other prim. If you managed to move multiple prims in sync already, adding the avatar to that movement is trivial.

There are absolutely no problems with that at all. You are the creator, it has your name on it... what's the question exactly?

I kind of prefer the floating triangles, honestly...