Wulfie Reanimator

While you can write a script that just rapidly moves the camera along a path in short increments (with a timer or a loop), it does not look smooth at all. Edit: Oh yeah, the Flycam is one option. It works especially well if you own a controller or a joystick.

This is probably going to derail a bit, but, what's your point? It's LTT who decides what you see on the video, it's all highly edited. If they wanted to make Linus look like a tech-god on their channel, they could. Regardless of that, why would it matter if he hadn't all the knowledge in his head on the fly? The videos where they explain any particular topic are read from a prompt. You could put any tech-illiterate person in front of the camera and make them believable.

You got a source for that since you insist on it?

And anything above 24 FPS...

I don't think there's an actual limit on maximum script time, but there IS a limit on how much time overall the sim can spend on "working" within a certain time limit. Scripts have the lowest priority, so the longer anything else is taking, the less total script time there will be for all scripts. Based on some testing @animats did, if I recall correctly, a Homestead can't practically handle more than 4000 scripts recently. Full sim starts struggling at 6-8000. In this thread's context, that's not true. Scripts do not cause lag for your viewer, even if you're "looking" at 10000 of them. The actual objects in your view -- the prims, the mesh, the particles and textures -- are what cause lower framerates for you. Object updates also cause network lag for you, which can sometimes be a side effect of scripts but not all scripts cause object updates (or many).

Why not use the LSL Preprocessor which literally allows you to #include files?

That's not an RLV feature. It's the fact that you're wearing something, same as you explained earlier in your post. But even without knowing any location, it's pretty easy to find people when you've known them for a while and know that they tend to go to a "group only sim." If you don't change your habits, you're predictable. The built-in avatar radar shows people in restricted parcels as well. Even if it didn't, scripts can do it too. Should you change your habits because of a breakup? Unfortunately in some cases. An easy way to mess with these stalkers is to just hang out in someone's home they don't know about, rent a new place, or just never log out so they don't know if you're actually active or not. (Or log in before going to sleep and leave your avatar parked in some random corner of mainland. Use the map, don't search for a public place.)

Even if the program wrote a little text file saying 32/64, LL would then add some code to the viewer to check for that file and its contents. Even if they did that, a system can change drastically from one login to the next, like if the user swaps their graphics card, or the viewer is installed on an external drive and plugged into a different machine. It's an extra point of failure just to make it "remember." It's easier, simpler, and safer to just make a new check each time. In your specific case it might not be needed, but code is rarely tailored for individuals.

You should post this in Inworld Employment or Wanted instead.

Yes, all events must be entirely separate of each other. An event cannot contain an event. (But you can cause some events to trigger from another event, as you do with llSensor inside the listen event.)

You can actually merge all of those states into a single state fairly easily, like so: key user; vector sit_position = <0.0, 0.0, 0.1>; vector sit_rotation = <0.0, 0.0, 0.0>; integer target_id; vector target_pos; default { state_entry() { llSitTarget(sit_position, llEuler2Rot(sit_rotation * DEG_TO_RAD)); llListen(PUBLIC_CHANNEL, "", NULL_KEY, ""); } listen(integer channel, string name, key id, string message) { message = llStringTrim(message, STRING_TRIM); if(message == "1") { // state a; llSetStatus(STATUS_PHYSICS, TRUE); llSensor ("1","",PASSIVE,96.0,PI); } if(message == "2") { // state b; llSetStatus(STATUS_PHYSICS, TRUE); llSensor ("2","",PASSIVE,96.0,PI); } // This part is not necessary. The script will not get stuck. // else // { // llResetScript(); // } } sensor(integer num) { vector iTarget = llDetectedPos(0); vector offset = <-3,0,0>; iTarget += offset; target_id = llTarget(iTarget, 1.0); llMoveToTarget(iTarget,0.5); } at_target(integer tnum, vector targetpos, vector ourpos) { if (tnum == target_id) { llSetStatus(STATUS_PHYSICS, FALSE); key user = llAvatarOnSitTarget(); if(user) { llSleep(1.0); llUnSit(user); // This is also not necessary for the script to work properly. // llResetScript(); } } } } One thing that seems necessary to point out is that when the script gets to the "end" where there's no more code to execute, the script will just exit that event and wait until a new event is triggered (meaning it will restart from the top of that event again). You don't need to restart the whole script at the end of everything. And just to clarify, "events" are those things like state_entry, listen, sensor, at_target, etc. The code in those events have to be triggered somehow, like the listen event is triggered every time a chat message is sent near the script, on a channel it's already listening on.

You're not even talking about the same thing? Why are you yelling on the internet? Daniel: "Selling lots of lindens means you might have to identify yourself." Selene: "THAT IS NOT TRUE, I HAVE NEVER SOLD LINDENS AND NEVER WILL!! SCREEE" How are you this disconnected from a two-party conversation?

Prettier Windlight as a shareable inventory item.

This is called ghosting (or "ghosted attachment"), and it can happen to any attachment for no fault of the creator. While relogging will fix it, you can also go to Advanced > Refresh Attachments to fix it without relogging.

As someone who's been asking for 2-factor authentication for SL (a password for your password), it was a very joking post. It's still amusing.

I heard you like passwords...

Do you mean making new textures for the walls? That has always been a pretty niche skill, but maybe the people who would buy a wall addon are more familiar with editing. Do you mean manually swapping the texture on the walls from a set in their inventory that you've included with the walls? My cynical answer is no, because it seems like most people are used to scripts and no-modify products and forgot the built-in edit window exists. My Magic 8-ball says: "There's still hope."

Personally I feel like scripted functionality is a weird cludge a lot of people use only because they're too paranoid to make their product modifiable. That, or they think there's an expectation of scripts by the user because the user doesn't know how to edit objects manually.

That phrase is about as true as "the customer is always right." It's not literal, it describes an attitude and a philosophy of weighing pros and cons. "The customer is always right" in practice: "Sure, we'll accept this returned item even though we don't sell it, because this customer is likely to spend more with us in the future." (Also "It's cheaper to keep a customer than gain a new one.") "Any publicity is good publicity" in practice: "I'm going to sell literal bath water, because the stupidity of it will spread like wildfire and more people know about me than before and some will stick around because they saw something else they like." (This becomes less effective the bigger you become.) Having a random SL fire department's logo on an (alleged) griefer's profile picture is not the same. For one, it's copyright infringement. You can tell a story about something dumb but you can't just slap their work on its own into an otherwise empty article. And the likelihood of anyone opening their profile and going "Wow, a fire department! I wonder what they're about? I'll go check after I ban this douche." is very unlikely. It's not even effective advertising because there's barely anything to look up based on that logo.

This could be because it takes a while for the animation to load into/from cache (client-side problem with network or hard drive), or because the script is lagging and there's a noticeable gap between playing (stop and start) the separate animations.

Stop it with the knee-jerk reactions. Act rational and read.

These lines, specifically. I added the constant name as a comment. They're listed in the particle system wiki page. PSYS_PART_BLEND_FUNC_SOURCE, 4, // PSYS_PART_BF_ONE_MINUS_DEST_COLOR // "Scale the RGBA values by the inverted RGBA values of the destination" PSYS_PART_BLEND_FUNC_DEST, 5, // PSYS_PART_BF_ONE_MINUS_SOURCE_COLOR // "Scale the RGBA values by the inverted RGBA values of the particle source."

Ah, yes, that would work fine. Here's an extreme example of what I was talking about: That's 5 x 5 x 2 meters, same model used for mesh and physics. 5 LI by default, 4 if you make it larger. But if you make it smaller, it becomes 10 LI at 50% scale and 20 LI at 25% scale. If those cylinders were more separated, they wouldn't get so high LI so quickly. (But after a certain point, the physics shapes are simplified automatically and the LI drops to 4 again.)

I'm not sure what you mean, but this is what I mean. Brighter-orange box should be the physics model. (Excuse the hilariously oversimplified 30 second remake of OP's model.)

Every time this is mentioned, it's also worth pointing out that the iOS client will be text-only. No in-world view.