Wulfie Reanimator

You were never wrong. default { state_entry() { float val; float min = 0.5; float max = 0.0; integer loop; while(++loop) { val = llFrand(0.5); if (val > max) max = val; if (val < min) min = val; if (loop >= 1000000) // million iterations { llOwnerSay((string)[min, ", ", max]); if (min == 0.0) llOwnerSay("Zero!"); if (max == 0.5) llOwnerSay("Hero!"); loop = 0; } } } } llFrand: 0.000000, 0.500000 llFrand: 0.000000, 0.500000 llFrand: 0.000000, 0.500000 llFrand: 0.000000, 0.500000 llFrand: 0.000000, 0.500000 llFrand: 0.000000, 0.500000 llFrand: 0.000000, 0.500000 llFrand: Zero! It took 7 million iterations on a much smaller range, but it does return zero as according to the wiki. Same code with (0.0, 4.0] range: llFrand: 0.000023, 3.999999 llFrand: 0.000002, 3.999999 llFrand: 0.000000, 3.999999 llFrand: 0.000000, 3.999999 llFrand: 0.000000, 3.999999 llFrand: 0.000000, 3.999999 llFrand: 0.000000, 3.999999 llFrand: 0.000000, 3.999999 llFrand: 0.000000, 3.999999 llFrand: 0.000000, 3.999999 llFrand: Zero! Got zero within 10 million iterations. If we add a bit more code, we can see a (very rough) approximation of what value the min actually has. Sometimes the semi-random sequence just doesn't catch a zero for a long while. For example, it took 73 million iterations to get an exact zero (within the 0.0 to 0.5 range) at one point.

I don't disagree with literally any of that, but I don't think saying "22 USD for a bald head isn't that bad" to someone who is clearly asking for a budget option is the right call. She's obviously not a primarily English speaker, so you have to read past the literal wording of her post. She seems to just want a head that's affordable and not totally proprietary (eg. "lacking in support" and "can't mix and match makeup from different creators").

While this is true, zero is considered positive by the compiler. So unless you specifically go out of your way to ignore a randomly generated zero-result, it creates no bias. In this example (which is about integers, not what the topic is actually about), there are an equal chance of positive or negative results. The same applies to floats, in [-2.0, 1.99999] the "missing 0.00001" is the zero. an exact range of -2.0 to 2.0 would have a bias for positives. But if you actually need the full range from -2.0 to 2.0 (for example, to use as input), that's a different problem. Even so, the chance of getting an exact min/max or even zero is very small.

The Normie head is cheap and well made. It's modifiable, easy to set up for Bakes-On-Mesh, comes with Omega, and only costs 500 L$. Gentle reminder that 5000 L$ is about 22 USD.

Read the llListen caveats: A prim cannot hear/listen to chat it generates. It can, however, hear a linked prim. Chat indirectly generated (as a result of llDialog, llTextBox or from a linked prim) can be heard if in range. See also: http://wiki.secondlife.com/wiki/LlMessageLinked

A script can register a listen-event on (one or more) chat channels with llListen. If you want the script to only trigger the listen event on exactly the message "awesome, thanks!" you can register a listener like so: llListen(PUBLIC_CHANNEL, "", "", "awesome, thanks!"); The above code will make the script listen to anyone (no name or key constraint) on the public chat channel (0) saying the message "awesome, thanks!" It will not accept "awesome thanks" It will not accept "Awesome, thanks!" It won't even accept "That's awesome, thanks!" The message must match exactly. Instead, what you probably want is: llListen(PUBLIC_CHANNEL, "", "", ""); Now, the above code will make the script listen to anyone on the public channel saying any message So, a listen event will trigger for every message. But that's okay. You can then start parsing the chat message to see if your wanted message is in there. For example: listen(integer channel, string name, key id, string message) { // channel: WHERE the message was heard // name: the avatar or object's NAME // id: the avatar or object's KEY (uuid) // message: the actual TEXT content // Make all the text lowercase, so the input-case no longer matters. message = llToLower(message); // Search for an exact "awesome, thanks" from the message. // The index will be -1 if it wasn't found anywhere. integer index = llSubStringIndex(message, "awesome, thanks"); if (index != -1) { llOwnerSay(name + " said it!"); } } You can complicate it further by searching for the words "awesome" and "thanks" separately, and even making sure that the word "awesome" comes before "thanks." Make sure to read the wiki often. It really is your friend, even though some pages can be a bit much to take in. http://wiki.secondlife.com/wiki/llToLower http://wiki.secondlife.com/wiki/llSubStringIndex http://wiki.secondlife.com/wiki/llOwnerSay http://wiki.secondlife.com/wiki/llSay P.S. You can of course write 0 instead of PUBLIC_CHANNEL. I used that constant just for clarity.

Ah, yeah, even I got tricked by the syntax. See, I thought it would have a syntax error because of a dangling-else. Properly expanded, that code becomes: default { state_entry() { integer test; if (test) { ; } else if (test) { ; } else if (test) { ; } else { llSay(0, "i failed the test 3 times"); } } } As in, the if/else-if "blocks" only contain an empty statement that does nothing. What I expected at first glance was basically this: if (test) {}; else if (test) {}; else if (test) {}; else { llSay(0, "i failed the test 3 times"); } As in, the conditions would have empty blocks, then followed by an end-of-statement. This would cause a syntax error, but it's not what happens.

You can make weather systems in SL. You can make HTTP requests to outside APIs about real world weather data. Not too difficult to link the two.

While we're here, how is that a violation of the bot policy exactly? Bots aren't required to do anything -- move or talk. Edit: Found the answer, it was a bit awkwardly placed.

The answer is closer to "yes but no." You cannot force MOAP (media on a prim) to show up on its own. Each viewer has a setting about whether or not media can auto-play. For those that have it off, you're out of luck until they touch the object (but even that can be disabled).

Or again, doing it the PaleoQuest way. The collectibles are permanently rezzed inworld by the game host. (Either statically, or in some set location.) They periodically become visible (change alpha and/or move into their intended location) and actually "collectable." When a player bumps into one, it can play an effect, hide itself, and communicate with the game HUD. Turning them in can be done simply by walking near the turn-in point. You can use collisions again to activate the vendor just like the collectibles.

OP said "Turn in 10 rocks to this Panel and receive 1 linden." If the payment wouldn't have needed to be in linden, I don't think the question/example would've been worded like this. Maybe he'll clarify. And while checking inventory type/name/creator can be done, you'd have to be sure you've haven't made anything full-perm (or even mod/trans) publicly available. (I know you know this, Frit, I'm just clarifying.)

Now add 100-200 Mono scripts to yourself.

Incidentally, this is exactly what Linden Realms has, which is something created by LL with basic LSL features. https://secondlife.com/destination/paleoquest Objects can pay people with llGiveMoney or llTransferLindenDollars, but as the others sort of warned you, "little mistakes" or vulnerabilities in your script can turn out costly. If people are able to turn in fake items for example, they can drain you dry. I would at least recommend that the "turn-in vendor" is owned by an alt specifically created for that purpose, which you'll periodically transfer money to. This way, if someone manages to exploit the system, you won't lose all of your money. I would also recommend that you go look at PaleoQuest and take some notes. Using a HUD to keep track of the collectibles is much safer (and convenient) than actual inventory items.

Gettings things like chains to be "low LI" is extremely difficult, due to the topology chains normally* require. Primarily because you just can't make the lowest LOD look good with mesh alone -- and not skyrocket the download cost. For small objects (go to Upload Options and make sure the dimensions are about the same as the expected result), you really really REALLY need to focus on the lowest LOD, since that's technically the most prominent LOD according to SL's algorithm. Eg: 4968 tris Lowest LOD: Link segments 2-3 times wider with only one "surface" per link, 672 tris Uploading this at 0.5 x 0.5 x 0.2 scale costs 51 L$ with 39.792 download weight. Obviously no positives there. Removing half the links and the inward-half of the rest: 23 L$ with 12.234 download weight, 156 tris To show how much the lowest LOD matters, look at my higher LODs, which are just the first LOD minus one "surface" of each link: But really, I would recommend making just a simple, non-segmented ring "surface" and use a veeeery low-res texture on it, or even leave it solid-color. It's the lowest LOD after all, it's not going to be very visible while in use. Even for the higher LODs, you probably shouldn't be using full mesh, my example is an exaggeration. And if we're being realistic about the current state of SL, the lowest LOD is basically never going to show up for avatar attachments so the quality-importance drops even further.

Don't forget, you can do: if (test) { statement; statement; statement; } ...if you're chaotic evil. @Mollymews That's a syntax error.

Remember that llGetNotecardLine has a forced delay of 0.1 seconds. Since you added more lines to your notecards, it's almost unavoidably going to take longer.

I think as long as the filth-too-degenerate-for-my-Christian-SL can't be accidentally stumbled on from the ground level, you're good. Like, no signs/pictures that could be seen from outside the house, etc. If you have a teleporter to a separate skybox, that's all you probably need, but I'm no Linden.

It could be that I'm just not understanding the "model" of your product. I'm assuming that at some point the product is going to end up in the hands of an end-user who no longer needs to edit the notecard -- or view its contents. Otherwise you wouldn't need to encrypt the notecard, right? If that's the case, then you can do something similar to what Omega is doing. You have a "configuration file" (notecard or script), you pass that data into a no-modify script once (either by reading the notecard, or passing the configuration from one script to the next) so that the no-modify script will always remember the textures/instructions/whatever (so long as it doesn't get reset). This way, the object: can be easily configured/reconfigured while you (or someone else) is working on it. can't be changed (or directly ripped) by the actual end-user, even if it uses no encryption at all.

Get yourself an Omega Applier dev-kit and look at how they did it. You can get it from their in-world store for free. The dev kit uses two scripts -- one is full-perm and just sends the user-input (textures in Omega's case) to the actual applier-script that cannot be modified. After the textures are loaded, the full-perm script can be deleted and it's ready for customers.

Why do the textures need to be in a notecard? Why not in a script? Also, as a bonus: The simplest encryption I would recommend for you is simple scrambling. Swap parts of the string around, don't bother with any hashing functions as they're either one-way (useless for you) or so wide-spread that anyone can find a decrypter online. Swapping is simple and others won't know what or how many pieces you changed.

In that case it's a simple matter of making sure the object isn't too thin for the relevant velocities. It's no different from any other physics problem, MoveToTarget won't change anything. speed / 45 = thickness (minimum) So, if you're on a surfboard going 30m/s and the wave is coming at you 20m/s, the object needs to be at least 50/45(= 1.111) meters thick, or you risk going straight through it.

I guess since it's a percentage increase, you would benefit from splitting the object to isolate the alpha texture from every other cost. The same applies to every cost, really. I think there's no cost to additional links in a linkset, at least as far as I can tell.

The "object" here is a single link of a bigger linkset (if we're talking about linksets). The getRenderCost function is called in from other functions, like here, which calculates the total cost of an attachment's linkset.

Oh, Fenix...