Wulfie Reanimator

I'm no expect so I can't offer any specific advice or guides, but this process is called "rigging." Once you have created the 3D model, you can then download the SL mesh body model/skeleton from the wiki and then "attach" your model to any relevant "bones" of the SL skeleton. Some reading material: http://wiki.secondlife.com/wiki/Mesh/Uploading_and_wearing_a_rigged_mesh http://wiki.secondlife.com/wiki/Mesh/Rigging_Fitted_Mesh

Looping sound is in fact a permanent prim property, much like particles or hovertext or color. The sound would keep playing forever, even after taking it into inventory with no script and rezzing it again.

Notecards that have never been saved are plsceholders, not backed by an asset on the asset server. This is expected behavior. (And I think it's in the caveats on the wiki for reading a line.) I don't know off the top of my head if there is a way to check whether a notecard has been saved or not. What is the key of the notecard before it's saved? I have a vague memory that it's NULL_KEY.

It's a teleport offer from an avatar, not a group invite. Similarly, the real group invite dialog can only be created by an avatar sending a direct group invite. You would need a bot for this, otherwise you're stuck with chat links even with an Experience.

Yes, but not easily and it might break LLs stance on "shared experience."

You probably (should) already know this, but scripts are the last thing to get any processing time per frame, and only the spare time allotted per frame after everything else. And since sims have their dedicated core, it's pretty hard (if not impossible) for one sim to slow down another. What you could do to test that is to break something more important, like physics. While scripts alone can't crash a sim, physics certainly can. Even if you don't (and shouldn't) go that far, you'll observe all kinds of other lag in other areas.

Friend, this post is 8 years old.

I apologise on Steph's behalf. You're not crazy though, this does happen occasionally regardless of how good your computer or connection is. Sometimes the response from LL's service just gets delayed and there's nothing you can do to fix that as a user. The link works because it's based on UUIDs, it's just the name-service that's faulty. (Not literally broken)

How is it "good" in Sansar? How do you quantify that?

Typing "maitreya sim" into Google brings up this: https://maps.secondlife.com/secondlife/Maitreya Isle/178/175/23

It is. (And it's not affected by animations.) Any script that relies on a free-standing avatar's rotation will be inevitably inaccurate in very noticeable ways. The only option would be to use a large area like you did, to estimate the general direction instead of being an accurate spot. This is caused by animations though. If you have "Turn around when walking backwards" disabled and start moonwalking, the attachment will position itself just like it would if you were walking forward. Relative positions and all that. But if you have this setting enabled (or move sideways with Shift+A/D), avatars have a procedural animation that turns them toward their horizontal velocity. The avatar's actual rotation doesn't change.

Out of curiosity -- why?

When you say "3D map viewer," do you mean just "2D map on a 3D plane?" Because it looks that way and it's a little misleading to call it straight up 3D. P.S. I've messaged Animats and we'll probably be able to make this properly 3D.

Here's a thread from 2009: http://forums-archive.secondlife.com/327/f9/352372/1.html

In a very general sense, variables will always be faster and use less memory than a list. This is because a list has some additional overhead required for storing and keeping track of the things in that list. A variable is a direct reference to a value, you don't really get much faster than that. When you have a list with more than one value, you must use one of the llList2* functions to access specific values. This is already less speed efficient, but it also takes more memory in bytecode because of the two parameters and return value. Lists get more efficient the bigger they get though. A list with 1 value contains as much overhead for storing it as a list with 10000 values, but lists will never be as efficient as a direct variable. But if you ever have to search a list for a value, speed efficiency tanks almost always. However, you can't use multiple individual variables for this purpose, so it is your only option sometimes. With all of this said, you really shouldn't worry about the "efficiency" of variable vs list. The difference rarely makes... a difference... and you should focus instead on code that makes sense. Worry about efficiency only after you find a real problem.

If your friend has the AO, they should be able to look at who created it. (Right-click it in inventory, go to Properties) Oracul also sells a couple very smooth "flying character" AOs, you can find their in-world store at a sim called Kuso.

Close, it went up from 0.99 to 1.49.

More specifically, even if (and I don't know, I teach myself -- poorly) Blender had a great general tutorial on how to make any kind of model, it wouldn't cover SL's needs. The workflow required for SL is a subsection of a subsection of Blender's feature-set. Performance budget, texturing (and not being able to rely on Blender to display textures as they will appear in SL), LOD models, etc. The things we do for SL are not things that Blender should be teaching for Blender users in general. Even if Blender made a "game asset tutorial," it would still be pretty close to the original problem. The workflow for Unity models (for example) isn't the same as you'd need for SL. Edit: What I'm saying is that we should have an SL-specific set of guidelines (not necessarily rules) from Linden Lab. What's recommended? What makes sense? What should you not do and why? Community-created tutorials are nice and all, but tutorials are often followed very literally and if the tutorial makes uninformed decisions, those are passed on which perpetuates bad habits that are difficult for most people to correct on their own.

Assuming this is in your Second Life USD balance (you didn't specify where the $2.44 is), you must simply sell more linden (or however else you can increase the USD balance) until your balance is above $2.50.

And bears! Grizzly or grizzled, doesn't matter..

Can't be done unless the person being tracked actually wears (or rezzes) a tracker that would report its position to someone else.

IMs used to be sent as plain text between viewers, but that's no longer the case. IMs in general are relatively "snoop proof," unlike a bunch of other things that aren't/can't be protected. That said, "HUDs" in SL are pretty powerless to do anything of real harm. Sure, they can push your avatar around, track your online status and spam messages to you, but nothing to actually worry about.

Oh, duh. I forgot about ol' anim. (Hence why it looks like jumbled mess in a text editor -- it's a binary file unlike BVH which is human-readable.) I meant more like Developer > Avatar > Animation Info or llGetAnimationList and copypaste to new-found URL. But there are easier ways to do this if you wanted to I guess. *shrug*

This is a small utility function I wrote for someone because it was an interesting little thing. It's fairly safeguarded to prevent "accidents." This is intended for cubes and cylinders, or any prim type that can be properly "sliced" at the ends. Its original purpose was to create a liquid fill/drain effect. The "animation" (changing slice in a loop) is optional, and can be used to just set the prim slice value once as well. This was the original function + example: // link: (0 for unlinked, 1-256 for linksets) The linked prim to change. // amount: (0.02 to 1.0) The final value of Slice End. // animate: (TRUE or FALSE) Whether or not to simulate filling/draining or just set the new Slice. fill(integer link, float amount, integer animate) { // Limit the range if(amount < 0.02) amount = 0.02; else if(amount > 1) amount = 1; vector slice = llList2Vector(llGetLinkPrimitiveParams(link, [PRIM_SLICE]), 0); if(animate) { float difference = amount - slice.y; float step = difference / 16.0; integer i; while(++i <= 16) { llSetLinkPrimitiveParams(link, [PRIM_SLICE, <0, slice.y += step, 0>]); } } else llSetLinkPrimitiveParams(link, [PRIM_SLICE, <0, amount, 0>]); } default { touch_start(integer n) { // These are examples // Animate to 0.0 slice (empty) fill(2, 0, TRUE); llSleep(1); // Animate to 1.0 slice (full) fill(2, 1, TRUE); llSleep(1); // Set slice to 0.5 (no animation) fill(2, 0.5, FALSE); llSleep(1); // Back to full fill(2, 1, FALSE); } } And this version includes time as a parameter, to play the effect over X seconds. It also calculates the minimum steps needed based on maximum change per loop. (0.1 in this case) // link: (0 for unlinked, 1-256 for linksets) The linked prim to change. // amount: (0.02 to 1.0) The final value of Slice End. // animate: (TRUE or FALSE) Whether or not to simulate filling/draining or just set the new Slice. // time: (0 to inf) fill(integer link, float amount, integer animate, float time) { // Sanity checks so you can't break anything. if(amount < 0.02) amount = 0.02; else if(amount > 1) amount = 1; if(llGetNumberOfPrims() > 0) link = 0; else if(link < 1) return; else if(link > llGetNumberOfPrims()) return; time = llFabs(time); vector slice = llList2Vector(llGetLinkPrimitiveParams(link, [PRIM_SLICE]), 0); if(animate) { float difference = amount - slice.y; float step = 1; integer steps = 0; while(llFabs(step) >= 0.1) { steps += 8; step = difference / (float)steps; } time /= steps; integer i = 0; while(++i <= steps) { llSetLinkPrimitiveParamsFast(link, [PRIM_SLICE, <0, slice.y += step, 0>]); llSleep(time); } } else llSetLinkPrimitiveParamsFast(link, [PRIM_SLICE, <0, amount, 0>]); } default { touch_start(integer n) { fill(2, 0, TRUE, 3); llSleep(1); fill(2, 1, TRUE, 1); } }

Good.