Wulfie Reanimator

Sure, here's a whole page of issues given to FS by LL: https://jira.firestormviewer.org/browse/FIRE-33607

Correct. This is exactly why piracy exists.

The attach event is more of a "subset" or more specific version of the on_rez event. It's useful when you're scripting something that's only meant to be used as an attachment (or especially if you need to do something before it detaches). Since you're scripting something that can be rezzed on its own and you don't care about detachments, there's no reason you should use the attach event.

Simply upload your textures in-world, then create a new Wearable (the plus-icon in your inventory > New body parts > New eyes), and select your texture in there. And that's it, you've made BOM-compatible eyes. Some mesh eyes expect your texture to be rotated 90 degrees left or right. (I forget which way, or whose grand idea that was.)

Rider Linden has opened two combat regions on the beta grid: Gallipoli and Thermopylae All of the new combat features are going to be tested on those first, for example llGetHealth

I don't think anyone who is against no-mod products is complaining about no-mod scripts.

Attachments remember where they were last attached, including position and rotation. When you give an object to someone else, it will attach in the same way as it did last. Could it be your glasses are scripted to move/rotate? Or maybe you're not giving a copy of the exact item you were wearing?

The benefit of jpeg2000 or "j2c" over other formats is that it's inherently progressive, you can download only the data you need to display a lower resolution version of the image. PNG and TGA require you to download the max resolution into memory, and then do extra processing to create a smaller copy, and then delete the original. Repeat this anytime you want to resize the image.

That's a Premium Plus feature. (Is joke!)

When I edit the examples on a wiki page, I add new ones and leave the existing ones on the page. There needs to be a really good reason to delete an example, even if it's one of those really verbose and over-engineered ones for a simple function.

To be fair, you can easily limit regular touch range too. The hunt object will check how far away the detected avatar is, and decide what to do from there.

You're correct, scripts cannot detect an avatar touching other objects. The scavenger hunt items need to announce themselves to the HUD when touched.

This is caused by alpha-sorting issues when two alpha-blending surfaces overlap. One solution is to use alpha masking instead if possible, or disabling the alpha channel entirely by setting the alpha-mode to none in-world. If you must use alpha blending, then another solution is to split the surface so the blending part is separated from the rest of the roof.

Word of the day: infohazard

No, unfortunately.

This question was answered in the 4th post in this thread.

For this reason, LL is considering/working on adding a new function called llSetVisible (or similar) which can be used to show/hide an object without affecting its actual color/alpha values. The problem of changing PBR alpha without affecting PBR color will still remain, but hide/show is a very general thing people need.

That would be pretty useful. It would essentially create a custom mesh asset and be a step toward in-world mesh editing. Prims as they are now have been designed to be very simple and cheap to transport over the network. Internally they're just a collection of parameters and the thing we actually see is created on-the-fly by each of our own viewers.

OH! Sorry, my head was in Blender. The same principle works in SL when editing texture-repeats on prims, it's just a more manual process. If you want a single texture to cover a 3x3 grid of prims, you need to set the texture repeats to 1/3rd on each prim, and then offset the texture accordingly. This gets trickier with irregular shapes, but you can at least get the repeats correct by typing some math into the editor field. (The viewer supports math equations in them.) For example, if your platform is 32m wide and you have 8m piece, you can get the correct repeats for that with 8/32. Same for the other axis and pieces.

With UV mapping. If I'm imagining the shape correctly, you can select all of the pieces, look at them from above, and unwrap with "project from view." This should give you a UV layout with each surface aligned to different parts of a texture.

FWIW, I don't care either way. The reason why LL has done away with the forward-renderer is because the amount of work it takes to maintain two very different rendering methods has gotten to the point where it's just not worth the labor. It slows down the development of new features because everything has to be done and tested twice. The decision came a little after some recent viewer performance improvements and when work on PBR had started. Nobody is stopping TPVs from continuing to support non-ALM.

While the 400+ FPS is silly, the sim's "FPS" has nothing to do with this. The viewer has no trouble rendering the screen more often between the updates coming from the sim. You will benefit from higher FPS.

Movies are a bit different because they aren't interactive media. Movies also have very consistent FPS, while you can definitely feel the jumpy FPS in games, even if it never drops below 30 or even 60 (depending on the game).

Disabling specific events is one of them!