Wulfie Reanimator

Faces are always single-sided in SL. You will need to duplicate the walls and "flip normals" so they face the other way. You can enable "backface culling" in Blender to see the same effect.

Which isn't allowed.

The LSL Preprocessor doesn't exactly "make your code better," definitely not faster. In fact it arguably does some damage for those who aren't using that feature. What it does optimize is unused code, which it removes. What it also does but shouldn't, is remove comments. (Meaning anyone not using the preprocessor won't see them.) The Preprocessor is a text-replacer, essentially. Its main features are #include to import code from your computer, and #define to create "immutable constants" rather than variables. It does also provide some quality of life things like lazy lists, but I recall it having its own set of edge-cases. For example, this is what the post-processed code looks like: //start_unprocessed_text /*string unused = "Goodbye, World!"; default { state_entry() { /|/ This is a comment! llSay(0, "Hello, Avatar!"); } touch_start(integer total_number) { llSay(0, "Touched."); } } */ //end_unprocessed_text //nfo_preprocessor_version 0 //program_version Firestorm-Releasex64 6.3.2.58052 - Wulfie Reanimator //last_compiled 05/02/2020 05:34:16 //mono default { state_entry() { llSay(0, "Hello, Avatar!"); } touch_start(integer total_number) { llSay(0, "Touched."); } } And if you are using the Preprocessor, the unprocessed code is in a separate tab from the post-processed one.

The size of the notecard window depends on the size it was when last closed, same with most other windows. Trying to create your own format inside the notecard (indentation, ASCII art, borders) is an exercise in futility since different viewers/users can use different fonts and font sizes, causing massive discrepancies in what they see.

Hi! Not really possible, we don't have volumetric cast functions like box-cast or sphere-cast. The ray from llCastRay is infinitely thin, it has literally no thickness. It's just a mathematical line/intersection. However, you can remedy that by using multiple parallel raycasts. It's not perfect, but it's usually good enough, depending on your expected target. You should not offset the rays more than the minimum width of whatever you want to hit, which isn't always an easy answer.

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.