Wulfie Reanimator

The black layer is disabled, it does not get saved with the picture. Doesn't the green-and-blue gradient count as a "landscape picture?" That layer is enabled, it's just 1% opacity. There's nothing there besides the red pattern. The left-side screenshot in my previous picture had the black background for clarity of what the pattern was. The right-side screenshot is the one I exported. Here I've done the same process in Photoshop, making the sky emissive: The mountains are 1% opacity, with the ones in the background increasing from 30%, 50%, 70%, to 100% for the main sky. Again, I saved the images as PNG with the absolute default settings. (Yes, it's obviously a 32-bit PNG.) The point I'm trying to make here is -- don't paint the unwanted areas black or white.. ignore the color and make them transparent. Same in Paint Tool SAI finally, it even specifically asks which type of PNG to save: Although it looks like the background is solid white -- it isn't. It's trasparent except for the glowy bits, and the background is 1% opaque. Though, curiously the wall looks nothing like the original texture I used. It looks extremely harshly saturated, the color levels are all over the place. I think we're onto something now. Merging the two layers before saving didn't help at all, so this might actually be a problem with SAI rather than anything @LilithServil could've messed up.

Here, I created a random texture. On the left is the "base pattern" I want to be emissive. I drew it on its own layer which was transparent to begin with. Then I disabled the black layer (it was there only for clarity), added the background texture I actually "want" and set that background layer's opacity to 0.1. Then I export it as PNG with default settings. (I'm not familiar at all with Gimp so I won't even pretend effort.) It's also worth mentioning that setting the background layer to 0.0 opacity would result in all the transparent pixels appearing black, but I don't think that's a fault on SL's end, but rather because the color data is lost during the exporting. Settings: In-world, alpha blending against a black sky: Emissive mask with 50% glow to show it works: Late edit: I now realize OP was talking about Paint Tool SAI, not Gimp...

I believe the reason why the tail is showing up with pitch-black stripes is because their actual alpha mask isn't working and it's being uploaded with the solid-black colors still in the texture. We haven't been shown what the texture looks like in-world. (As in, the diffuse itself before being applied.)

No, that Jira concerns a very different thing. If you look at the two cubes in the Jira screenshots, the other is significantly darker than the original. This is the way it has always worked. I recall this from trying this stuff years ago. I believe your screenshots of the "alpha gradient" demonstrate the exact same effect.

With the textures you gave me to test with (p.s. thank you), what I said here is apparently accurate: On the left is the original texture as-is. It's transparent except for the 4 "lights" on the road. In the middle is the texture set to "alpha mode: none" which makes it fully opaque with no loss of color. On the right is the texture set to "alpha mode: emissive mask" which causes the (non-transparent) lights to appear fullbright. That is your texture without glow. If I add glow, only the 4 lights will be affected, which is where you're correct and it's what I already knew. The same applies to the official viewer, Firestorm, Black Dragon, and any other proper viewer.

Look up the "Chinese room experiment." You are the computer in the analogy. You may know what the word means, but your comment is a pretty clear reflection of how little you understand of the word and culture.

Unfortunately I'm still not home for the day so I may be talking completely out of my butt, but emissive alpha doesn't have any relation to glow. From the Material Data page on the wiki regarding alpha modes: Emissive The value is used to encode how brightly the pixel appears in the absence of light (ambiance): 0 = no additional ambiance (default); 255 = full brightness I interpret this as what we call "fullbright," not glow.

Comparing the price of SL subscription to anything else is not the way to determine "worth." What you should do instead is compare the price of the individual things you get with Premium to the total cost. 1024sqm land tier, 1200L$, etc. Before the price was raised, you would actually get more than you paid for, if you bought a full year of premium. Then there are the more intangible benefits like increased group capacity, priority entry for crowded sims, and transaction history. These are the things you need to value subjectively.

This actually works? llPlaySound ("sound", 0); Hm... That could explain something to do with my fullperm music sphere. Maybe Sound Queue also caches upcoming sounds?

I'm not at home to double check, but use the mask you've created in Gimp to select all the unwanted areas, then take an eraser and remove 99% of the opacity in the texture. If I recall, transparency is what defines the intensity of the emission. The texture will be fully opaque.

AOs don't need active scripts and deformers can be applied manually, so they're not even SOL.

Yes and no. It's not a coincidence.. in the sense that UUIDs are a general standard used in a lot of places, not just Second Life, so the Lindens did not come up with UUIDs with this in mind. But at the same time.. the fact that they chose this system is a happy coincidence/convenience that just happens to allow this kind of neat conversion (and maybe that's a contributing reason they chose it, but I doubt it). Even the way strings are interpreted as numbers is something seen in C/C++, so that's not specific to SL either.

Ah yeah, sorry, I misremembered that you do actually need to typecast it to string first, eg: integer int = (integer)("0x" + (string)llDetectedKey(0)); llOwnerSay((string)int); When you typecast a string, it will be parsed as a number. The type of number is determined by what's in front of the string. A string that begins with "0x" will be interpreted as a hexadecimal number, it will keep reading the number until a character other than 0-9 and A-F is encountered. A string that begins with a number will be read until a character other than 0-9 is encountered. int = (integer)"0x779e1d56-5500-4e22-940a-cd7b5adddbe0"; llOwnerSay((string)int); // 2006850902 int = (integer)"0x779e1d56?5500-4e22-940a-cd7b5adddbe0"; llOwnerSay((string)int); // 2006850902 (same as above) int = (integer)"0x779e1d56a5500-4e22-940a-cd7b5adddbe0"; llOwnerSay((string)int); // -1 (0x779e1d56a5500 is too big) int = (integer)"779e1d56"; llOwnerSay((string)int); // 779 (e is not a valid digit for regular numbers) int = (integer)"0b1111"; llOwnerSay((string)int); // 0 (but in some compilers this would be 15, "0b" means "binary") int = (integer)"0001111"; llOwnerSay((string)int); // 1111 (leading zeroes are ignored) And of course, any amount of function calls you can take out of your code is a performance improvement. With some limits.

(integer)("0x" + (string)llDetectedKey(0)) 😉

1. His sim, his rules. He doesn't have to stop only at what the TOS allows. The sim could be rated PG and still have kids banned. 2. Let's pretend for a minute that your avatar looked like an actual child. If you were hanging around near sex furniture, you'd definitely be risking The Boot from LL. While child avatars are allowed on Adult land, they are not allowed near adult activity. In this case the guy is just overly paranoid.

It's cheating in the sense that if your land has exactly 1 LI left, you can't rez and use any furniture from PrimPossible. You could if the shell was set to 'temporary,' but they didn't think that far. Do you think anybody 99% of us here are saying it's possible to reliably sit more than 1 avatar on 1 prim?

Everything can be accounted for with the right design, including everything Rolig listed. Whether or not you know/want to change your style of logic is something only you can choose, but it's natural for me to only initialize scripts once (with default values and in state_entry) with the data they need, and only do things in on_rez that would make sense to do if the object is being rezzed by a script. (Owner-change-reset should be done in the Changed event, not on_rez.) For most combat-related things, on_rez does very little. There's basically nothing you can't do before/after on_rez. For especially short-lived objects (< 2 seconds), I tend to put a check in on_rez to see if the param is nonzero. Only scripts can give a nonzero parameter to a rezzed object, so that helps me disable whatever normal behavior the script has whenever I manually rez the object to edit it. (Which happens very frequently...)

I'm sure there exists lots of text generators for that on the internet. But put some effort into your fancy-schmancy-ness if you're going to do it!

Something like that. There's two parts to it, the first is that objects rezzed by scripts don't have their scripts reset. Try putting this: integer global; default { touch_start(integer n) { ++global; llOwnerSay((string)global); } } Into this, after you have touched it a couple times to change the global: default { touch_start(integer n) { llRezObject("Object", llGetPos() + <0,0,0.5>, ZERO_VECTOR, ZERO_ROTATION, 0); } } You'll notice that the counter continues from where it was when you picked up the first object. Similarly, if the first object called llListen to open a channel, it would remain in effect for that script even after being rezzed as a new copy. The second part gets a lot more speculative. I don't think it's a "prim property" in the sense that there's any data stored in the object's attributes (which are sent to the viewer in full), more so that the state of the script contains a listener, and the moment the object is created, so is the script and the sim immediately becomes aware of its listener (because recovering the state of the script would inherently re-register the listener as well, and marking the beginning of the "chat history" that should eventually be sent to the script), long before the script becomes active.

Yup, that's the article I've read before (and commented on the respective thread on this forum). This wiki page explains it, and I could be wrong but I'm mainly convinced because I don't believe I'm so lucky that dropped messages happen so rarely in the unavoidably laggy conditions the gun is intended for that I don't notice and a whole group of people haven't mentioned it even once. Sometimes there's a delay of a couple seconds before the rezzed object acts on the message, but my rezzer sends the message (once) as soon as object_rez triggers, so it's definitely not getting lost. The thing is, if your rezzed object is supposed to call llListen during on_rez, it won't hear messages during the "object rezzed but scripts haven't started" period, because the channel isn't open. See, the article specifically assumes that the rezzed object initializes stuff after it has been rezzed. I don't do that. I initialize the listen before the object is taken into inventory. The same should be possible with llAllowInventoryDrop, I haven't tried.

This is not the case. I'm aware of the changes (and the thread where they provided a (fairly poor) example on the correct method, similar to what you described), but it does not affect this trick. The way the chat system itself works is kind of similar to the event queue. The script's listener will poll for new messages and is guaranteed to hear "unheard messages" that have been sent before the script actually started running. (As long as the object was alive, and unless the script's event queue is full and the message is received but the event is discarded.) Most recently, I used it for a gun intended for active SL combat. (It needed to have a visual "bullet trail" for its raycast mode, and I send the intended position to the visual prim with llRegionSayTo.) Lag is guaranteed to exist, but it never fails even when it gets so bad that avatars stop moving.

There's a thing called Animesh. It's quite literally animated mesh. It gives an object its own skeleton, and the object can then use animations made for avatars, assuming the object is also rigged for the SL skeleton.

Minor nit-pick, but you don't have to explicitly typecast keys to string before adding another string to it. And one thing regarding rezzers is that you can use the object_rez event to send messages to the newly rezzed objects. They're always guaranteed to exist and you'll have their key. This way, you can send messages even to multiple objects rezzed in quick succession (especially if they are rezzed by other scripts in the same object). Because events have a queue, you're guaranteed to send a message to each rezzed object. Though, for this method to work absolutely, the objects-being-rezzed must already have an open channel before they are rezzed. (llListen in state_entry, then pick up and put into rezzer. New copies of that object will never miss chat messages.) I can personally vouch for this simple trick because I've been using it for quite a while now.

Animations cannot normally be started by UUID. The viewer-built-in animations are the only exception. What Qie is saying is that if you want to avoid the permission request, the avatar needs be part of the same linkset as the script. Scripts can still animate avatars who aren't in the same linkset, but the permission-request will be visible to them.

And not just the number of digits you have on the left/right, but what those digits are. For example: 9.1 is 16 times more inaccurate than 1.1, and neither of those values can be stored exactly by a computer. 1.1 = 1.10000002384185791015625 9.1 = 9.1000003814697265625 And it's not just that, but everything you see on your screen in SL is the result of many layers of calculations, where these errors become very noticeable. Floating-point values (with the decimal point) are actually stored in two main parts. The "exponent" and the "mantissa". You can play around with them here: https://www.h-schmidt.net/FloatConverter/IEEE754.html All that said, your best fix is to be as close as possible to the region's <0, 0, 0> coordinate. Don't build or use your items in a skybox if you don't want to see "mini-jitter."