Frionil Fang

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.

Yup, child prims can have their own omega independent of the root (you can even have both, with the entire linkset rotating via the root and the children rotating individually on their own axes). Either set it via a script inside that specific prim, or via a llSetLinkPrimitiveParamsFast call from a script in another prim.

Texture rotate animation doesn't have a pivot you can choose, it rotates around the midpoint of the texture (and I guess a corner for PBR materials, haven't checked). If what you're trying to animate isn't centered on the pivot on the UVs, it won't work. Best you could do is rotate the entire object with llTargetOmega, which may or may not be doable considering you said you didn't want to do that -- if you were concerned about performance, non-physics TargetOmega is a viewer-side effect and doesn't have much cost resource-wise.

Sounds like you might have multiple UV maps which SL doesn't support, check this post: The post was about the problem in older Blender but the same principle applies with modern versions.

Like Wulfie said, most of these are no help without type punning and/or unions. There's also the fact that user-defined functions are *slow*. From a quick test, 100000 square roots takes less than a second; 100000 user-defined square root function calls to a single-iteration Newton approximation (which is obviously terrible and useless) already takes more than twice as long. With a reasonable number of iterations, we're talking ~10x as long. Consider what you are using these rotations for, too: nlerp is already meant to be fast and loose, functions that don't require normalization (like plain old llSetRot/PRIM_ROT) will work even if the results might not be accurate, that probably wasn't the goal in the first place. Functions that do require normalization (llSetKeyframedMotion comes to mind) won't be satisfied with a sloppy approximation, they need the magnitude of the rotation to be close enough to 1. TL;DR stick with multiplying by 1/llSqrt(mag) for accuracy, leave it out entirely for speed if it works.

Yes, I know, that's when I made the expansion: fitting 60*1 kB memory banks into linkset data (the other 4 stay in script memory), when you have no binary encoding, was more or less an impossible task. It uses base64 to achieve a 3 bytes into 4 base64 characters -ratio without a too horrible hit to performance on swapping. Hex dumps would be more performant, but that gets a measly 1 byte per 2 characters, and is used only for the system bus/DMA, and wouldn't leave enough linkset data space for all the other stuff.

Yeah, I could retroactively go and just add line breaks anywhere especially now that the storage device uses -Sync reading, the file is a contiguous block of data and linebreaks don't matter for how the computer itself sees them, but I'd rather them just fix the regression sooner than later.

That may have been me, though I know I'm not the only person to write a 6502 emulator in LSL. It's not cycle accurate and forgoes emulating many of the hardware quirks (illegal opcodes, RMW behavior) and BCD arithmetic mode, the NES did fine without the latter. It doesn't emulate a real computer either, instead implements its own "hardware" so it won't run any code that isn't written for it specifically; the CPU runs at roughly estimated 400 Hz instead of 1-2 MHz so it's not exactly going to be competitive with an Apple II, C64 or NES, so I figured to just give it appropriate peripherals rather than try to target a real architecture. It used to have only 8 kB of memory, all I could fit into the main CPU+memory+system bus script, but it now uses linkset data to swap 1 kB memory banks and can see the entire 64 kB address space, keeping 4 banks in script memory. Not that there's any reasonable way to use up such massive quantities, 64 kB? The biggest program I've made for it is just over 3 kB, and that's mostly just graphics. To stay on the topic of notecard reading though... can't see any corruption in the above picture thanks to fortunate positioning, but it's there. The data storage device reads arbitrary files as hex dumps and crams them into system memory. The files were laid out as 1024 character lines (512 memory bytes per line, in other words) to minimize the amount of lines to read, everything already runs at a very retro pace and no need to make it any slower. Now that even the old notecard reading function broke and returns only 1023 hex digits, the last byte on each line is misread, and with the way the system's video memory is laid out in 4+4+8 bit units at 32x24 character resolution (background color, foreground color, character) this means one character every 8 lines is corrupted. Also not noticeable on most of the corrupted lines, but bottom right corner is clearly wrong: it's supposed to be character 0xBD, the storage device detects the missing nibble and kludges it into 0xB0 (it would otherwise end up as 0x0B). Thankfully it was just a picture and not code, you wouldn't want your LDA <16-bit address>,X opcode to turn into BCS <signed 8-bit offset>. Just for fun, below is the program+data in the notecard:

My SL computer loads programs that are written as hex dumps into notecards. Because notecard loading was so painfully slow, minimizing the line count was important and maxing out line length was a good idea. Sure, reading with the sync notecard reader is so much faster that using, say, 512 character lines would no longer be a limiting factor in loading speed, but that doesn't change the fact that no script that was relying on 1024 byte lines works anymore until they fix their regression. Anyway, wrote the bug report: https://feedback.secondlife.com/scripting-bugs/p/server-version-2024-02-217995320426-broke-notecard-reading-limit

They broke it though, and broke llGetNotecardLine at the process. llGetNotecardLine and llGetNotecardLineSync now return only up to 1023 bytes (used to be 1024 for async) and I was relying on that behavior. Time to write a jira uncanny canny feedback.

Only PBR-material faces are not rendered.

That doesn't "turn PBR off", it just disables rendering of anything using PBR materials. Anything else is unaffected, including the lighting.

One last idea... your mesh wouldn't be using PBR materials, would it? Old SetColor/SetAlpha/SetTexture don't work on something that has PBR materials applied; you're changing the underlying old parameters, but the PBR material ignores those and uses its own settings. You'd have to use the glTF overrides instead.

Your state_entry sets alpha on the root prim to 0 on all faces, but your touch event sets textures on face 5 and doesn't set it visible anywhere? The page2 state also sets alpha to 1 only on face 3, which isn't something that's being changed here. As a side note, it's not safe to change state from a touch_start event, it's bugged and may end up losing the next touch event. Should change state from a touch_end event instead.

Completely useless tidbit but since I just read about it for unrelated reasons, on x86 (integer) modulus and divide are the same operation, you get the other one "for free" at the same time. DIV (unsigned) and IDIV (signed) produce both the quotient in AL/AX/EAX/RAX and the remainder in AH/DX/EDX/RDX.