Wulfie Reanimator

My wild conspiracy theory is that this is totally related to the migration to AWS. /mild sarcasm

above average eye size overall larger head size no big or especially duck lips slightly puffy cheeks round chin smaller ears etc. But it's not just the shape of the head, but the textures as well that make a big difference. Smoother, less detailed skins work best for a young, child-like look. (No any visible pores or wrinkles) Very dark or blue eyes with larger pupils work well. (Especially with the "big eye shape") No make-up, trust me

This isn't really how encryption works. You can't have two "keys" that are both able to decode the same file, this would make the form of encryption inherently much less secure overall. While you can have a "master password," this would be used for the actual key used to decrypt the files. It's a second level of encryption, or a second password for your password. You might think that the viewer can just "automatically give the master password then," but that doesn't prevent the issue mentioned in this thread because it's the last encryption that fails. That said, this could be caused by either: File permission error or corrupted file For the former, the error is caused because the viewer is not allowed by the OS to open the file. There are some utilities for "taking ownership of a file" on your OS of choice. (You'll have to google that yourself because it depends on your OS.) For the latter there's no salvaging it. Even a slight change in the file will cause it to not return any valid decrypted data, causing this error. However, since the encryption method (as far as I've seen) seems to be based on the network ID of the computer, like the error says, a router swap, new connection, etc. is eventually going to change your locally designated decryption key. Also like the error says, your only hope is to change everything back the way it was. Otherwise you'll just have to start over with the logins. P.S. OS updates do not change regular files or how they are encrypted, this would be incredibly harmful to all users and businesses. Edit: Found this - https://jira.secondlife.com/browse/BUG-139291

The Kemono has a section in the UV layout for PG nipples specifically, which is displayed when you toggle PG nipples. You must texture that area separately. (it's somewhere near the top-center of the UV)

Your avatar cannot be literally pregnant. It's just the HUD that pretends you are, and it doesn't need RLV to do that. Ignore the HUD, it doesn't affect you unless you wear it and want it to.

Do you even know who I am?

Do you even know who I am?

Hey @LoganNJ1013! It's usually best to just post whatever script(s) you have already so we can give better examples/explanations. From your explanation it sounds like all of these lights are separate from each other and not a single linkset. To synchronize the colors between all of these is going to be a bit complicated for a total beginner, and I would suggest linking them all together and learning to use things like llSetLinkColor or llSetLinkPrimitiveParamsFast (for things that can't be changed with another function, like lights). But, let's take "setting prim colors" as an example. You could do it like this in a linkset of 5 prims: llSetLinkColor(2, <1.0, 0.808, 0.4>, ALL_SIDES); llSetLinkColor(3, <1.0, 0.808, 0.4>, ALL_SIDES); llSetLinkColor(4, <1.0, 0.808, 0.4>, ALL_SIDES); llSetLinkColor(5, <1.0, 0.808, 0.4>, ALL_SIDES); It's gonna make the linkset look like this (white box is the "root"): http://puu.sh/CU7qP/3958d87cbe.png It's important to know that these colors are not set at the same time. The script will change one prim and then wait until the sim lets it use another function (to put it simply). If the sim is laggy, the wait could be noticeable. Alternatively, you could set the color of all 4 prims at the same time with one function, using llSetLinkPrimitiveParamsFast: llSetLinkPrimitiveParamsFast(1,[ PRIM_LINK_TARGET, 2, PRIM_COLOR, ALL_SIDES, <1.0, 0.808, 0.4>, 1, PRIM_LINK_TARGET, 3, PRIM_COLOR, ALL_SIDES, <1.0, 0.808, 0.4>, 1, PRIM_LINK_TARGET, 4, PRIM_COLOR, ALL_SIDES, <1.0, 0.808, 0.4>, 1, PRIM_LINK_TARGET, 5, PRIM_COLOR, ALL_SIDES, <1.0, 0.808, 0.4>, 1]); You can probably see the similarities pretty easily, except there's a couple new things. The function takes two things: a link number, and a list of parameters with expected values after each one. By default, the list is applied to the specified link number. The PRIM_LINK_TARGET must be followed by an integer number, indicating a new link number for the following parameters. If you look at the second table on the wiki page, you can see this row: It tells you what parameters (the type, and a descriptive name hint) should follow PRIM_COLOR, including PRIM_COLOR itself. You can split lines into multiple parts without causing issues, just don't forget a comma if you're splitting up a list, and don't forget the closing brackets and semicolon. You can add more parameters to this, such as "full bright" and a light source, like... llSetLinkPrimitiveParamsFast(1,[ PRIM_LINK_TARGET, 2, PRIM_COLOR, ALL_SIDES, <1.0, 0.808, 0.4>, 1.0, PRIM_POINT_LIGHT, TRUE, <1.0, 0.808, 0.4>, 1.0, 10.0, 0.75, PRIM_FULLBRIGHT, ALL_SIDES, TRUE, PRIM_LINK_TARGET, 3, PRIM_COLOR, ALL_SIDES, <1.0, 0.808, 0.4>, 1.0, PRIM_POINT_LIGHT, TRUE, <1.0, 0.808, 0.4>, 1.0, 10.0, 0.75, PRIM_FULLBRIGHT, ALL_SIDES, TRUE, PRIM_LINK_TARGET, 4, PRIM_COLOR, ALL_SIDES, <1.0, 0.808, 0.4>, 1.0, PRIM_POINT_LIGHT, TRUE, <1.0, 0.808, 0.4>, 1.0, 10.0, 0.75, PRIM_FULLBRIGHT, ALL_SIDES, TRUE, PRIM_LINK_TARGET, 5, PRIM_COLOR, ALL_SIDES, <1.0, 0.808, 0.4>, 1.0, PRIM_POINT_LIGHT, TRUE, <1.0, 0.808, 0.4>, 1.0, 10.0, 0.75, PRIM_FULLBRIGHT, ALL_SIDES, TRUE ]); Now each linked prim will be the same color, be set to full-bright, and emit light matching the prim's color. Hopefully this makes llSetLinkPrimitiveParamsFast look less intimidating. You don't necessarily have to look at the biggest table in the wiki page, it's the same as the second table but with more descriptions added. P.S. And just to make everything more readable and harder to mess up, you can use a saved list since the "prim color/light/fullbright" is the same for each prim: list parameters = [PRIM_COLOR, ALL_SIDES, <1.0, 0.808, 0.4>, 1.0, PRIM_POINT_LIGHT, TRUE, <1.0, 0.808, 0.4>, 1.0, 10.0, 0.75, PRIM_FULLBRIGHT, ALL_SIDES, TRUE]; llSetLinkPrimitiveParamsFast(1, [PRIM_LINK_TARGET, 2] + parameters + [PRIM_LINK_TARGET, 3] + parameters + [PRIM_LINK_TARGET, 4] + parameters + [PRIM_LINK_TARGET, 5] + parameters ); It's important for me to point the new things out again: You cannot put lists within lists in LSL, so instead I'm adding the list [PRIM_LINK_TARGET, X] with the list of parameters I want for each light, then adding the next to that, and so on, until each prim has its own parameters.

As far as I know, no. However, you could do other things like rezzing the object you want, rotating it by 45 degrees, and moving it by the little dual-colored triangle between each individual axis. (The triangle will have the colors of the two axes it will move the object along) and eye it with that. Or, you could keep one prim in the center of the build, rez the object as far away from the center as you need and rotate it whichever way you want it to face toward the center, and then add the center prim to your selection (check edit at root) and rotate the objects into place that way. Or, you could rotate the entire build and all of the intended furniture by 45 degrees until the spot you want aligns with the real coordinate grid, then rotate it back (and again) when you're done.

Probably. It happens.

Don't write it at all. There's no benefit from having that on your product page. If you're within your rights to DMCA something, you don't have to ask/warn first. You're also not going to realistically sue anyone IRL because they probably 1) don't live in the US and 2) don't have enough money to pay for your legal fees, let alone any "penalties." If you want to make it clear somehow that there are limits to what's allowed, list those limits and leave it at that.

It would be pseudorandom if the result is predictable in advance, but is it? Never mind, I retract what I said there. The more I think about it the deeper I sink into the unknowables. But in short, I would say: "Yeah, is it?"

Do we, though? Do we really? What benefit does this point system bring us that we don't already get by asking "can you do X?" (Especially since this is an ambiguation of different skills towards a single score. We would still have to ask that question.) And why should mistakes count as achievements worthy of proving how "experienced" a "builder" is?

I think the reason why llFrand is being called "pseudo-random" is because the random result is shared for all scripts/regions on the same sim(aka server). Even if llFrand was based on thermal noise, the fact that it's shared still makes it pseudo-random. (Though I'm not sure if this is true.)

LSL doesn't support lists-within-lists, so I like the idea of using JSON for that. What I've actually used it for is a menu-system. I allow users to write their desired menu layout into a notecard (not in pure JSON but something simpler), and then I parse it into JSON. Though, even the pure-JSON format would be pretty simple for menu-layouts. (Some superfluous brackets omitted) "main menu": { "menu a": [ "button 1", "button 2", "button 3" ], "menu b": [ "button 1", "button 2", "button 3", "button 4", "button 5", {"submenu 1":[ "button 1", "button 2", "button 3" ]} ], "menu c": [ "button 1", "button 2", "button 3", "button 4" ] }

The correct answer is "oh no" and leaving the room.

This is becoming a little pedantic of me, but what I meant with is that looking at the end-result of a big average doesn't tell you whether that average came about through randomness or design. If you repeat a die-roll result of "1 2 3 4 5 6" to infinity and average it, you'll get 3.5. You could also write any sort of "random pattern" that was fixed (repeating) or just flawed (easily predictable, evenly distributed but not random enough), but would average out in the end if you run it long enough. That's the crux of "big numbers" that I was referring to. With large numbers you lose any nuance by just averaging it out. Similarly (and more related to the first post), if you have two numbers: 10'000'000 and 0, you can tell that these numbers are very different. But if you were to increment both of these numbers by 1 to infinity, they would become indistinguishably close to each other, as the difference of 10 million would become insignificant when both numbers become unfathomably large. The same applies if you have a tally of 10 different values and increase those by 1 whenever a random number picks them, they'll start off showing differences but those differences will fall within "margin of error" with time.

I think you're either wording yourself really poorly, or you've misinterpreted the wiki somehow. You keep saying "an average of 9.8" or "9.9" or "10," but I have no idea where you get those specific numbers. LLN states that the numbers will tend towards the "expected result" (average), but nowhere does it say any of those numbers you're giving. More specifically, if you throw a 6-sided die an infinite number of time, the average result of all of your throws will get closer and closer to the average of all the possibilities (1,2,3,4,5,6), which is 3.5. But this is just mathematical probability and not a measure of true randomness. Edit: And, to that effect, llFrand fits right in. I ran a test of getting "the average of running llFrand(1) 100'000 times", repeated 100 times, then averaging all of the averages. The lowest average of 100K random numbers was 0.497872 (0.002128 margin) The highest average was 0.501863 (0.001863 margin) Total average of all 100 averages was 0.500046 This was my code: default { state_entry() { llOwnerSay("going"); integer k; float average_average; while(++k <= 100) { integer i; float average; while(++i <= 100000) { average += llFrand(1); } average /= 100000; average_average += average; llOwnerSay("average: " + (string)average); } average_average /= 100; llOwnerSay("average of averages: " + (string)average_average); } }

Because it's generally not an alt, but a dozen. In an empty box. And it's very egregious. See: Skybox at +1000 meters while the actual location is at ground level. Parcel privacy is set to hide avatars, so you can't see them unless you fly above ~80 meter. Flying is disabled. Most of these avatars are the LL starter avatars and/or empty profiles besides the land group. "Bot" is just a colloquialism for "not being used by human." An alt used primarily to passively boost traffic is a "bot" just the same as any other.

I don't know if "MMOs are expanding into SL's virtual world space" is very accurate. These games (or this live DJ thing) don't compare to SL's platform and MMORPGs with "land-ownership" (however you define that) have been around at least as long as SL. My go-to example is Entropia Universe (since 2003), which is a lot like SL in more ways than not, but further gamified and far more strictly economy-based. (For example: You can buy land deeds for hundreds (or hundreds of thousands) of USD worth of in-game currency from other players through auction, and you must further maintain your land by providing services and wildlife for other players to make use of while you automatically collect your chosen amount of tax for various activities. You can then cash your in-game currency back out into real USD.) You could equally find any number of "proper" MMORPGs with land ownership or housing, with similar but more simplified economies and social interaction. They've been here all along, though they're becoming more visible and/or you don't/haven't considered these to be the same thing as SL. (And they're not.) P.S. What I'm not saying though, is that SL shouldn't be on its toes. I'm not going to make any time predictions, but I think everybody (including LL, see: Sansar) knows that SL's time is limited as rewriting the code into modern standards is just not feasible (or would take them several years and having to pull out practically all resources from SL as it is). People are going to keep trying to make the next big virtual world, and I have a feeling it's not going to be SL.

While this does have a point, it should also be acknowledged that Fortnite has a massive userbase to begin with. Had it begun as a "live virtual DJ stage," it would not have these articles written about it. Heck, as someone who was involved with closed alpha testing of Fortnite since 2014, I can say that Fortnite was struggling to stay on its feet as a base-building player-versus-AI game. Only after they switched to a new and popular genre (as free-to-play) did they explode in popularity.

Can you link a study on that? Doesn't match any of my understanding of true randomness and I'd love to educate myself.

Stephy's just misunderstood some script error in the long lost past and attributed it to integer/float mixing, even though they are implicitly typecast as needed and wouldn't ever throw a script error. Even their holy Wiki reads: "If a function requires a float as a parameter, and the number is an integer (e.g. 5), you can add the .0 to clearly indicate it's a float, but omitting the .0 is equally valid and actually saves bytecode space in the compiled code." You could create a loop to show the position of each prim in the linkset (and then copypaste the values into your script) like this: Though, if your linkset is more complex than the one you showed, you might need something a little more sophisticated. default { state_entry() { integer prim; while(++prim <= llGetNumberOfPrims()) { list local_position = llGetLinkPrimitiveParams(prim, [PRIM_POS_LOCAL]); llOwnerSay((string)local_position); } } }

The shorthand operator in "x += y" is equal to saying "x = x + y" Basically, "Add Y to X (and store the result)." "changed" is a standard LSL event. Basically a function that is called automatically when certain things happen, much like state_entry or touch_start.

The funny thing about "randomness" and "true random" is that you can't really use statistics to prove how random something is. If the curve looks like a bell-curve (most values in the range of 2-8), is that random? If the curve is mostly flat (values evenly distributed across 1-0), is that random? If you flip a coin an infinite amount of times, will it be exactly 50-50? In the cases most people use random numbers in, perception is more important than being truly random. In fact, true randomness can be a negative thing. For example, the random question selection is going to feel bad/boring/annoying if the same question keeps getting picked a lot. To improve the "quality" of randomness, it would be better to keep a record of the most recent questions and never pick those until enough other questions have been picked. This could still lead into some questions not being picked very often, and to prevent that as well, each question's pick count could be tracked and if any question falls below a certain threshold, they would be picked automatically (as long as they also haven't been picked recently).