Frionil Fang

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.