Wulfie Reanimator

Oh, you're right! That's neat, I've been using the preprocessor for years and didn't even think it could work. Works fine, and it turns out in-world scripts don't need an extra newline at the end, probably because it's implicit.

Finally, a man with some thighs. Didn't you say your previous avatar was the system body? Why aren't you using BOM (and alpha layers)?

Ignorance, laziness, or just an actual mistake (exported the cage by accident). The small triangles typically used to increase the bounding box have no negative effect on land impact or complexity, compared to these solid sides. Mathematically speaking, the small triangles are more efficient since the pictures you've shown have two triangles per all 6 sides, which is twice the amount needed. It shouldn't even affect the LOD distance, because the box is exactly the size of the visual object itself. It's not increasing the size of the bounding box. No matter the reason, it's pointless and bad design.

You can only #include files from your local hard drive, not other Scripts. This is also true.

Yes, Firestorm has an "LSL Preprocessor" built in. It's literally the same as other precompilers.

And just to clarify, LSL scripts cannot directly (or indirectly) "reference a variable or a function in another script." All you can do is communicate with that other script, and the other script is the only one with access to its own variables/functions. (This distinction might seem minor, but I'm not sure if @GManB is talking about something like class-members of other languages, which LSL simply doesn't have.)

Imagine being able to access the individual characters of a string through an array index without having to explicitly create a new string with a separate function call.

This is, most likely, just a coincidence with integer overflow. And/or primarily: "If str contains fewer than 6 characters the return is unpredictable."

I was responding to your first paragraph. What do you mean by "media length in milliseconds" and "being able to call a sound volume"?

My music player uses llAdjustSoundVolume for volume control. A "fade out" is still not very elegant. The simplest method would be to put that function into the timer event, and set the sound based on current velocity. Or you could just have a little loop to gradually lower the volume after movement stops.

Furware can't display even nearly enough characters to represent even a small fraction of the UTF character sets.

I've had my main account for over a decade, people know/call me by my name (Nina) than the actual username I chose back then. Using a display name in this case would reduce confusion. (Disclaimer: my display name is Legacy.Name because fight the system!) It's not much different than having a nickname. What I don't generally understand is people getting upset when you don't call them by their display name.

The "No" button triggers run_time_permissions as well. The value of the given permissions will be 0. And Rolig is correct, the permission dialog will stay open forever.

Instead, I would recommend the object_rez event. It's triggered whenever a script in that prim rezzes an object, and the event tells you the UUID of the object that was rezzed. You can easily add this UUID into a list for bookkeeping.

A "face" in SL is a "material" in Blender. To re-order the faces, switch the materials.

Either I'm doing something wrong, or you are, because I'm still getting different keys after the script recompiles. (I'm using the LSL Preprocessor built into Firestorm, which gives me the "Recompile" button. It just forces the script to be saved even if no changes were made.) An immutable asset is one that is unique and unchanging in any way. One asset ID, one set of data. If the contents of an asset can change (for example, the script gets modified but it keeps its asset UUID), it would be mutable.

Wulfie, I am not seeing this for scripts. This wiki page might explain things somewhat: http://wiki.secondlife.com/wiki/UUID Here, run this script in-world: keys(integer type) { integer i = 0; while (i < llGetInventoryNumber(type)) { string name = llGetInventoryName(type, i); llOwnerSay(llGetInventoryKey(name)); ++i; } } default { state_entry() { keys(INVENTORY_SCRIPT); } touch_start(integer total_number) { keys(INVENTORY_SCRIPT); } } Then restart it. Then restart it again. You'll get the same output every time. Then save it. Then save it again. You'll get a different output every time. Dunno.

This is pure speculation, but I would assume that Linden Lab makes no conscious effort to destroy any account data of deactivated accounts. That's to say, it doesn't matter if you're gone for 15 years with an inventory of 1 million items. It may just be that, over time, through the natural progression of the virtual world (land or region re-rented/moved/abandoned) and maintenance or server downtime/complications/migration could mean that deactivated accounts are the ones with less "protections" against data loss, whether intentional or not. Basically, LL is not obligated to maintain "abandoned data" forever, even if they intend to.

Making this distinction is actually very good. Edit: Or maybe not, see below.

All second life assets are immutable. Even scripts. Saving a script creates a new script. The fact that you cannot save a local-file script after a logout is expected behavior. You'll find that the same thing happens if you simply close the inworld script editor and try opening it again. This is because the viewer stops looking for updates on the file if the editor is closed, until you click the button to open the script externally again. Only this: Copy the Sublime Text version, paste it into the inworld script editor, and immediately click the "open externally" button. The script will be saved automatically.

Oh boy...

Computers are stupid. They'll do exactly what you tell them to, but that's not what we want. They should just calculate the right thing instead. Your current script isn't far off. In fact, it is correct. But you're doing both things instead of one or the other. On line 123...132 you have this code: if (level & CONTROL_ROT_LEFT) { angular.x = -50.0; angular.z = 0.0; } if (level & CONTROL_ROT_RIGHT) { angular.x = 50.0; angular.z = -0.0; } And on line 140...149 you have this code: if ((held & CONTROL_ROT_RIGHT) && (held & CONTROL_LBUTTON) || (held & CONTROL_ML_LBUTTON)) { angular.z = 10.0; } if ((held & CONTROL_ROT_LEFT) && (held & CONTROL_LBUTTON) || (held & CONTROL_ML_LBUTTON)) { angular.z = -10.0; } So, whenever CONTROL_ROT_* keys are pressed, you will first apply angular X motion (first part), then angular Z motion (second part). You need some way to tell the script that only one of these things should happen, or in this case, you want to make the first part have an additional condition that cannot be fulfilled at the same time as the second part. (They should be mutually exclusive.) The second part -- which is correct -- is supposed to trigger only when CONTROL_LBUTTON or CONTROL_ML_LBUTTON is held. So the first part should trigger only when those buttons are not held. !( (held & CONTROL_LBUTTON) || (held & CONTROL_ML_LBUTTON) ) We already have the two button-held checks. We'll just put parentheses around the whole thing (the result will be 1 or 0), then apply the "logical Not" operator ("!") to it. It changes a zero to one, and any nonzero back to zero. Basically it just inverts the meaning of whatever condition it's applied to. "If A or B" becomes "if A nor B". So the second part stays the same, but the first part becomes: if (level & CONTROL_ROT_LEFT && !((held & CONTROL_LBUTTON) || (held & CONTROL_ML_LBUTTON))) { angular.x = -50.0; angular.z = 0.0; } if (level & CONTROL_ROT_RIGHT && !((held & CONTROL_LBUTTON) || (held & CONTROL_ML_LBUTTON))) { angular.x = 50.0; angular.z = -0.0; } This is becoming pretty hard to read (and repetitive) though, so I would recommend making a few variables for convenience. integer start = level & edge; integer end = ~level & edge; integer held = level & ~edge; integer untouched = ~(level | edge); integer LButton = (held & CONTROL_LBUTTON) || (held & CONTROL_ML_LBUTTON); integer Left = (held & CONTROL_ROT_LEFT) || (held & CONTROL_LEFT); integer Right = (held & CONTROL_ROT_RIGHT) || (held & CONTROL_RIGHT); if (Left && !LButton) { angular.x = -50.0; angular.z = 0.0; } if (Right && !LButton) { angular.x = 50.0; angular.z = -0.0; } if (Right && LButton) { angular.z = 10.0; } if (Left && LButton) { angular.z = -10.0; } Or if you want to get really clever, all of those conditions can be reduced down to... if (Left) { angular.x = -50.0 * (!LButton); angular.z = 10.0 * (LButton); } if (Right) { angular.x = 50.0 * (!LButton); angular.z = -10.0 * (LButton); } Can you guess how that works?

What I meant by "exact units" was basically "integer offsets" but on second thought I'm not too sure on the exact details (like the fact that objects are scaled to unit-size volume, etc), so I would disregard that thought. Anyway, yes, the SL world is metric. Can you show an example of the actual model you're trying to make work, and where (what height) the gaps appear? This is not the connection made by Profait. It's true that trying to align 3.124m with 3.876m is going to be basically impossible (by hand), but that has nothing to do with the minimum object size of 0.1m. You can certainly have verts closer together than that. I made this real quick: The two planes are separate meshes, with one edge positioned exactly on top of each other. In SL it looks totally fine at 4000 altitude. (The seam is on the left side in the below picture, the camera is extremely close to where the gap would appear. No gap is visible regardless of camera angle.

The further you are from <0,0,0> (ground-level corner of the sim) and if your object's vertices aren't at exact units, the more likely you are to see gaps. This is caused by rounding errors in the rendering process and has always been the case, long before mesh existed.

You don't need a body fatpack to make one avatar.