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.

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.

There's a string indexing error in the function, making it return FALSE unless the strings match exactly. That wouldn't cause a math error but dunno. You're giving the substring length as the ending index to llGetSubString, but it returns the characters *inclusively* between the indices so it should be decremented. For example your beginsWith("abcd", "abc") would get string length 3 for the prefix, and would then compare llGetSubString("abcd", 0, 3) => "abcd" to "abc", failing every time unless the strings match exactly and the overflowing ending index compensates. For instance, check the string length being 0 before comparing (separate if clause to avoid the string function being evaluated if the string length is 0, I guess, LSL logical AND/OR aren't shortcutting so every part of the statement gets executed), and then use length-1 instead. integer beginsWith(string str, string substr){ integer ss_length = llStringLength(substr); if(!ss_length) return FALSE; if(llGetSubString(str, 0, ss_length-1) == substr) return TRUE; return FALSE; }

If you're talking about streamed parcel music fading in and out, that's been happening for some 7 years now across 3 different computers and several ISPs. I do some lowkey DJing and it happens once or twice per set for me. The viewer uses a premade library for handling audio streams and it's just configured weird or buggy, occasionally running out of data and fades out for a moment. Never found any good manual fix or explanation, and it's clearly not high priority on LL's list of bugs, dunno if it even happens for everyone. Edit: parcel media/media on prim like youtube do not use the parcel audio stream, so they wouldn't suffer from that bug.

Games often include a brightness/gamma setting, but here's the thing... they're games, made with consistent art direction, the content in scenes designed to work together, so there's not much need to fiddle with things to make mix'n'match work. There's the reference environment you could design on (https://github.com/Jenna-Huntsman/Second-Life-Resources/tree/main/PBR/HDRi) but I don't see it being very foolproof in practice, not that baking in lighting and eschewing any materials or using old Phony-Bling materials is any more so.

The supported character set could be changed, but you'd have to change the typeface textures as well, etc. As seen above, the set defined in the code is as follows (though it appears to be missing a couple of the line-drawing characters for some reason, maybe the version I checked is old or something):

Yes, that was my gist, sorry I'm a bit extra verbally challenged today. The unfortunate design here is that the ambient occlusion is packed into the same texture as roughness and metallic, with no way of separately tiling/offsetting the different packed parts, so they're permanently stuck to each other. You're not changing only one without having to create a new texture asset. Personally I'd love to have a separate scale/offset for each of the packed ORM channels, but probably not going to be a thing.

Alpha blended surfaces are often be displayed in the wrong order. Imagine you had those occlusion-shadows as a "decal" on an object, then a person with alpha blended hair stands in front of it; it's very possible for the hair to be drawn *behind* the occlusion shadow. It's aggravated by the objects overlapping or at least being close to each other in some sense: my neighbor has alpha blended palm trees far outside my window and I can't find an angle where the order goes wrong, but the prefab glass of the window that I covered with a blended effect layer will display the dull grayish glass on top about half the time, and my own enhancement the other half. It's not a SL fault, alpha blend sorting is a hard problem in general (making the sorting reliable is expensive, and usually not worth it) and if you pay attention you can see it happening in many games. More modern games can do different tricks to mitigate/circumvent the issue, but they're probably not very applicable to SL. If there're no multiple alpha blended surfaces occupying the same pixels on your screen, then there won't be unstable ordering.