Wulfie Reanimator

Not unless you manually check each avatar in the sensor event and make sure they are on the same parcel.

I think it's appropriately named. It has certainly attracted some rustling.

-

What do you mean by "light ray casts?" I have a couple guesses, but not sure.

There is, and it's relatively simple but it's not perfect. Assuming you've cut the songs into equal length clips, you can write a script that plays each sound sequentially. I've already written a music player like this (with extra features) and posted the code here on the forum:

Everybody likes graphs:

What happens if you list a service (such as commissioned work), but it isn't/cannot be completed "in a timely manner" (subjective to what the buyer wants) and the buyer complains/flags it? How is the completion/delivery of services even tracked, since you can't give a reason while flagging a listing?

Add mirrors to the list of No-Nos.

I'm not much into simulators, but Beat Saber alone has made my Vive worth it. Excellent workout, too good even (because I play until I'm sore for days), and just fun. I do have a friend who seems to have spent a great amount of time in simulators though. My graphics card (1060, 3GB) is slightly worse than yours, but it handles 90% of games very well. (And the ones it doesn't, seem to be badly unoptimized or somehow bugged.) I don't think you should pull the trigger on the new graphics card until you've had your GamerGoggles™ for a while and still think it's worth that much.

Whenever the next iteration of headsets come, they almost definitely won't be cheaper than what you can get now. Index isn't cheaper than Vive ever was, etc. If you're concerned about price or performance, go for the Vive or Oculus since they're cheaper and lower resolution. (I personally have a Vive.) Have you looked into what kind of VR things you want to try out? Any games already planned? You might also want to measure the distance between your eyes and make sure the headset can be adjusted enough for your eyes. Some don't come as far apart or close together as others. What are your PC specs? Do you have enough ports for the cables to plug in?

You're right, I don't know you. But look at the things you're saying in this thread.

Well, we have the answer.

Another update. After tweaking the numbers and writing myself some sensible debug messages, I found that using a much lower force had much better results. I originally started with 100, then 25, and here's the result with 5. Video: https://puu.sh/FBO57/7ee82e2903.mp4 It seems to remain stable and even regular movement isn't enough to destabilize it. There are a few quirks that allow you to still get launched (for example, if you free-fall into it). Partial source code: sensor(integer n) { target = llDetectedKey(0); gravity_center = llGetPos() + GRAVITY_CENTER; llOwnerSay((string)["target ", target]); llSetColor(<1,1,0>, -1); while (TRUE) { list data = llGetObjectDetails(target, [OBJECT_POS, OBJECT_VELOCITY]); vector avatar = llList2Vector(data, 0); vector velocity = llList2Vector(data, 1); vector direction = gravity_center - avatar; float distance = llVecMag(direction); if (distance > escape_range) { llOwnerSay((string)["exit"]); jump exit; // Exit condition! } float modifier = (1 / distance); if (modifier > 1) modifier = 1; vector impulse = direction * force * modifier; float strength = llGetObjectMass(target) * llPow(distance, 3); llPushObject(target, (impulse - velocity * 0.55) * strength, ZERO_VECTOR, FALSE); llSleep(0.044); if ((growth *= 1.5) > MAX_GROWTH) { growth = MAX_GROWTH; // llOwnerSay((string)["growth ", growth]); } if ((force += growth) > MAX_FORCE) { force = MAX_FORCE; // llOwnerSay((string)["force ", force]); } } @exit; init(); } The biggest change I made was add a little "force modifier" which is just (1 / distance) with a maximum value of 1.0, making the primary force slightly weaker over distance so the target won't get multiple full-strength pushes back towards the center, making them overshoot more and more. I also had to remove about 55% (arbitrary) of the avatar's velocity from the impulse because 100% would cause them to shake pretty violently during the first second of the grab and 0% would just fling the avatar right out of the trap.

Their key will stay the same.

https://puu.sh/FBIlB/7d0b8bbb9a.mp4 Script: http://puu.sh/FBImq/0187dc0d22.txt More accurate replica: (Is that Game Of Life, by the way?) https://puu.sh/FBJpk/1d03d4f060.mp4 Script: http://puu.sh/FBJpT/7282c81f96.txt

Why couldn't you do that with a single script and llSetLinkPrimitiveParamsFast?

I have no control over any attachments the avatars can or won't wear. Zero control besides what my own objects do. It's just the LL combat system, any HUDs people tend to wear are proprietary to their own group with few shared standards and zero cross-compatibility. I have made MoveToTarget-based things before, they're fun and easy, but don't apply to this case.

That's why I'm using a loop to apply many pushes while accounting for different variables. And due to the "must be forced" nature of the effect, temporary attachments aren't viable since I need to request permission to do it, and the enemy team is definitely not going to wear an attachment I tell them to. RLV isn't an option either since combat sims don't mandate it, and force-sitting an avatar is very different from the "feeling" I want to create. This needs to be done with llPushObject, and the knowledge I'm going to get from this can easily carry over to lots of other things. Back on topic a bit though, right now I'm accounting for: Distance: llPow(VecMag(direction), 3) Avatar velocity: llGetObjectDetails Avatar mass: llGetObjectMass My final calculation is along the lines of "(impulse - velocity) * strength" where: impulse = direction * force strength = llGetObjectMass * llPow(distance, 3) (direction = gravity center - target position, force = float) So in theory whatever my impulse is, I want to remove the avatar's current velocity from it. Meaning if my impulse is low (avatar is close to where it should be), it should start only counter-acting the avatar's velocity to prevent it from falling or moving. In practice it's not really doing that and it doesn't even sound right the more I think about it. Thoughts?

Unfortunately no, the sim(s) I might use this on don't have Experiences. It's quite possible. llPushObject-based avatar grabbers can and have been done. I can even show you the one I have. Even if you try to move while you're being held in the air, you won't be able to move much. But this is what mine does. I'm not touching any inputs and I get thrown about to the point where I escape without trying.

This has a couple problems -- I want the target to be able to escape within the first few seconds of being grabbed, and they would most likely be shot by enemy combatants while they are trapped mid-air, so the cage shouldn't block the avatar's movement or physical objects flying at it. The second part is relatively easy to build around, but the first part is the hard one. I can do the initial pulling part just fine now, but the problems happen when I'm supposed to be holding the avatar in place in the air. I don't know what kind of counter-forces I can use to cancel out the "bounciness" that gets more extreme over time.

What kind of edge-case, out of curiosity? The one you vaguely mentioned is 1) not synchronous, 2) prone to lost messages, and 3) at least partially doable with SLPPF unless the changes are script-related. (I assume so.) The kinds of situations I can think of are gun-related and we have workarounds for the workarounds!

So I'm working on a little something. It's game inspired and for use in combat sims or my own amusement. Essentially, this: (7 second video) The goal is to wait for an avatar to walk within a certain range, then use llPushObject to pull them in and up into the air. Problem is that llPushObject seems very weak, especially the further the avatar is from the point I want them to "gravitate" towards. My current code looks something like this: key target; vector gravity_center; float force = 3.2; float grab_range = 3; float escape_range = 6; float exponent = 0.0002; // snipped sensor(integer n) { target = llDetectedKey(0); gravity_center = llGetPos() + <0,0,2>; llOwnerSay((string)["target ", target]); llSetColor(<1,1,0>, -1); while (TRUE) { vector avatar = llList2Vector(llGetObjectDetails(target, [OBJECT_POS]), 0); vector direction = gravity_center - avatar; // Vector TOWARD the center. if (llVecMag(direction) > escape_range) jump exit; // Exit condition! float mass = llGetObjectMass(target); llPushObject(target, llVecNorm(direction) * force * mass, ZERO_VECTOR, FALSE); llSleep(0.044); if (exponent < 2) // Slow curve to force-growth, chance to escape. { exponent *= 2; llOwnerSay((string)["increment ", exponent]); } if (force < 1000) // 1000 is still very weak. { force += exponent; llOwnerSay((string)["force ", force]); } } @exit; llSetColor(<1,0,0>, ALL_SIDES); } Yeah; repeating sensors, infinite loops, AND jumps! What a time to be alive. One event is faster than one every fraction of a second, we don't have break to terminate a loop, and the object does not need to respond to anything during the loop. Adding the avatar's mass to the equation didn't seem to do anything. So my question is, how do I account for the distance so avatars would be more strongly affected? Are there other pushing functions I'm forgetting? Edit: Update! The wiki page for llPushObject says "The push impact is diminished with distance by a factor of distance cubed." So... llPow(llVecMag(distance), 3) does a good job at counteracting the distance falloff. It's a great start, but when the avatar is near the target, it tends to "overshoot" and bounce and can't hold the avatar in place while in the air, so I'm still looking for help/input.

I put my main script in the root and the other 19 into a microscopic mesh triangle where people won't find it.

Never mind that you can use the same payment info on multiple accounts even if you don't buy anything...

The only unironic use of the base body I've seen are from naked guys looking to hump anything that moves in 2007-era sex sims.