Frionil Fang

Peeve: it's not enough to get such intense stomach pain at 3 AM that I had to call an ambulance, but I got robbed while waiting for my ride. A young thug demanded a smoke, I was too much in pain to humor him, so he took my wallet instead. Not a lot of cash in there, just the hassle of having to renew all my cards. Delight: I'm high on opiates waiting for more tests and got all the paperwork dealt with already. What a night, tho.

By definition the DROP mode doesn't give particles any speed or offset, so changing those won't make a difference. They will be affected by acceleration, wind, source position if that flag is enabled, and will start moving towards their target if those flags are enabled, though. Assuming you mean to make the particles reach their target faster, turn down their max age: the target is reached in the particles' lifetime, no sooner, no later. If you meant the particles are spawning too slow, then you'll need to adjust the burst rate.

You put the function outside the event (and mispelled it), which is illegal. Try this instead: ... touch_start(integer total_number) { if ( llDetectedKey(0) == llGetOwner() ) { ...

Looks reasonably similar to me? Left: plain ol' fullbright prim with a randomly chosen color. Middle: GLTF override with llsRGB2Linear applied to the same color. Right: point light with llsRGB2Linear. Basic "sunset" environment. Same, except a random non-PBR-adjusted environment from my inventory and a different color. As you can see in the top picture, the PBR cube is illuminated despite being emissive, the fullbright classic cube is not, so it could be some kind of a lighting thing with your particular settings, but as far as I can tell classic fullbright is equivalent to PBR+sRGB2Linear or light+sRGB2Linear.

Short answer: no, like Rolig said. Long answer: no, scripts can never affect anything inside your inventory. Workaround: if you use Firestorm, there is a selection of commands that can be entered in local chat. "ztake" might do what you want to do, while saving you some trouble, see this page: https://wiki.firestormviewer.org/fs_zdrop_ztake_mtake Basically, you would do the following: Rez everything you want separated Select everything Create a new folder in your inventory, for example "pickup" Enter "ztake on pickup" in local chat and wait for the command to gather selected objects into the pickup folder. Enter "ztake off" in local chat. Done.

Devilishly clever. I always forget which all functions exist in the viewer URI scheme, the chat function supports only channels above 0 (not spamming local chat is understandable, not sending on negatives is a bit weird) which is why I may have glossed it over previously. I like this approach, missing only some kind of an indicator if there's more stuff to go back/forward to.

Doing things like this gets a little involved since most services don't provide open APIs anymore so you'll need to register for a developer account, learn the web API specifics, etc. By the looks of it, the Apple Music web API doesn't offer a "now playing" endpoint, best it has is "recent tracks" but that's not quite the same thing and there appears to be no way to check if the track is playing right now, and when it was played.

If you were thinking which inventory items take the most space the answer is none, the inventory assets are just pointers to things and they're not stored on your drive or in the inventory directly. Focusing on any specific type to clean up isn't going to really make a difference.

Uploading a .bvh doesn't seem to retain the priority 6 on the bones even if the animation was created as such and the animation asset itself claims to be "priority 6", you'd have to use something that can create the internal binary .anim format instead. Some of my findings in another thread some time ago.

Texture animations are pretty janky to begin with, but non-looped ones seem extra inconsistent to the point what I'd call buggy. Turns out the -1 length offset affects all animations that aren't LOOPed, logically llSetTextureAnim(ANIM_ON|SMOOTH, ALL_SIDES, 0, 0, 0, 1, 1) should scroll the texture once with the duration of one second, but nothing happens; using 2 as the length does what you'd expect. There are other caveats like negative speed with non-looped actually looping (since it tries to go backwards from start to end), frame-based animations having a bizarre frame order with negative speed, no way to specify the actual step size when using non-smooth rotate/scale, etc. Some mode combinations just don't seem to have ever been fully specified. As for changing parameters of the animation on the fly, it's also quirky, some of them aren't reset unless you sufficiently change the animation mode and start over like Quistess's example above. For instance, integer d = 1; default { state_entry() { llSetTextureAnim(0, ALL_SIDES, 0, 0, 0, 0, 0); } touch_start(integer _) { llSetTextureAnim(ANIM_ON | SMOOTH | ROTATE, ALL_SIDES, 0, 0, 0, PI+1, d*PI_BY_TWO); d = -d; } } will first turn the texture upside down on the first click, then rewind on the second click but it never stops since speed is negative, and the time to start rewinding is equal to how long you let it sit at the upside down position; the animation timer is still running in the background but isn't reset by the change to animation parameters.

For many purposes the basic overlay blend mode in most image editors is actually "good enough" for blending together normal maps -- not for every situation, but like if you wanted to apply grooves on top of an existing normal map. You *should* normalize the normal map afterwards since the overlay blend won't account for things going outside normal vector range but but SL doesn't care that much in practice.

Since the non-physical omega effect is completely unrelated to the actual object rotation, it should be enough to "nudge" the rotation after stopping omega to return it to a known good state. I can't test right now but I believe if you try to set the object rotation to what it already is, no update happens, and the visual rotation derived from omega isn't cleared. E.g. llSetRot(<0, 0, 0.01, 0.9999>); llSetRot(ZERO_ROTATION); sets it to a tiny non-zero rotation for a moment and then back to ZERO_ROTATION, which should ensure an update to the object.

Colors in LSL are in range 0.0-1.0, not 0-255 like "everyday" RGB. Trying to set your color to <67, 67, 67> for instance gets capped to <1, 1, 1> which is white. The easy way is to divide your existing vectors by 255 to bring them into the 0.0-1.0 range, e.g. llSetColor(<67, 67, 67>/255, ALL_SIDES).

As a side note that does not apply to this case with ROTATE: when using frame-based, that is, non-scaling non-rotating non-smooth animation, you can't use negative speed to reverse, the frame order gets convoluted and wrong which also causes jerkiness. For example, a 4x4 animation grid will end up going in the order 0 3 2 1 12 15 14 13 8 11 10 9 4 7 6 5, instead of 0 15 14 13, etc. Use the REVERSE flag instead to ensure consistent reversed animation regardless of mode.

ROTATE mode texture animation's length is in radians, not frames or seconds or whatever. Set your length to TWO_PI.