Wulfie Reanimator

Well, looking at the red marks in the uploader should make the problem very obvious. "Physics mesh too dense; remove the small, thin triangles (see preview)." You've done an OK job at keeping most of the building's physics model very simple, but you skipped out on the stairs and apparently some of the floor or outside railings are too thin. For example, the side wall on your stairs has edges super close together, which will create super thin triangles: It should look more like this:

The "shared experience" relates to the world itself, not the interface through which you view the world. Otherwise text-only clients would definitely be banned.

Yes, SL ran better back in the day. Yes, SL was less complicated back in the day. No, graphics weren't better back in the day. This is an objective fact. We have the potential for more detailed content that is easier to make and is more common. (That content is also the reason why SL runs worse today, and is more complicated.) What you're experiencing is nostalgia. It's common for people to have fond memories of the past, such as remembering that a game looked/felt/played better than if you were to experience it again.

While it's true that you can do the retopo in Marvelous, I had never used it before so it was much faster to export the model into Blender and use the knowledge I already have there. The automatic remesh feature you and I have both mentioned does not create completely clean topology. Look at the bonus tip in the OP for an example.

For any tests you're going to do, you're gonna need to enable the "Render Info" display from Developer (Ctrl Alt G) > Show Info Otherwise any test is pretty meaningless, especially when nobody else can go to the same places to replicate/compare.

Fortunately it's not very hard to repeat that test these days. You can get to 1.6 million with just two Legacy bodies and nothing else.

SL won't render things the same as Blender. You can't really export the material properties for use in SL. Also, the reason why the model looks different in SL is because SL has a minimum size requirement of 0.01 meters for the bounding box of the model but your earring is even slimmer than that. You can fix it by adding a simple box or a couple triangles to the model to make it seem wider. Triangles are simpler since you can scale them to be so small they won't show up while selecting the object.

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?