Wulfie Reanimator

Curveball: Do you have other old files you can reupload and compare? Is that the only example? (Doesn't sound like it's the only one, but...) I've uploaded a bunch of textures recently and haven't noticed any issues with quality. The newer texture looks like it hasn't loaded all the way - and maybe the asset server has somehow managed to cache a partially loaded version?

I bought a neck tattoo from Stardust that uses similarly thin lines, and this is what it looks like in-world: It's also a 1024x1024 texture but we can see the same issue with thin lines; the texture is just "stretched" too thin across the whole body and there aren't enough pixels for fine details like this. It's not as big of a problem for large shapes (or skins in general) where the change in contrast is low and less noticable. Most other tattoos from Stardust use thicker shapes which probably look much better. 🙂

The pixelation comes from the texture itself. The lines are simply too thin, just look at your tattoo at 200% scale: There's no trick around this as long as you're using LL UV. Do you have examples of these other tattoos?

They may not be defined explicitly, but the viewer (Firestorm at least) does respect priorities higher than 4 by allowing them to play even if new P4 animations start afterwards.

I also like it when the picture is included. It's a lot faster to go through my inventory when I don't have to attach everything, especially when a sim is laggy and it takes over 20 seconds for one thing to attach, and several more to detach it. 😋

If the store name has multiple words, you may need to use quotes. Simple queries work at least. For example: shoe maitreya vs shoe NOT maitreya Edit: I take it back. While the results are very different, products with "maitreya" in keywords/description are still included. It looks as if it's only excluding product names or... something. Quotes don't work either. I tried relevance search: shoe maitreya NOT "PURERICH Nails" What a mess.

Another super interesting thing I'm going to test is the rate of rezzing multiple projectiles. These days, most weapons use at LEAST one separate script that does the actual rezzing - because of the forced sleep from llRezObject. (Often there are multiple "rez nodes," depending on how high of a fire-rate you need, but there are other limiting factors beyond 700-900 RPM that affect the "stability" of rezzing things at a consistent rate. Weapons can go as high as 1200-1400, but it inherently varies.) Since the new function returns immediately, I'm hoping/wondering if we can potentially get rid of "rez nodes" entirely while keeping the same rates. This would obviously further reduce the number of scripts required for typical combat. There's no explicit throttling in the function, is there? (Rezzing is throttled in general, we know it as "grey goo" - the SL wiki could use some updated details.) I imagine we'll still need that one extra script for rezzing at a consistent rate during automatic fire (due to how control events behave, and timers being.. timers), but it'd still be an improvement from 2-3 extra scripts for the same purpose.

Generally speaking yes, the UUID should be enough. And yeah, the choice of limiting last names to time/amount seems to be just an arbitrary (read: not technical) choice. You could argue that it has some positive social effects, but personally I'd prefer to at least be able to choose any existing last name.

See my last comment above yours. Click here to get English back: https://marketplace.secondlife.com/?lang=en-US

Objects bigger than 64m (previously 10m) are called "megaprims" and they were all created a long time ago. It's not possible to create new ones anymore as far as I know, so it can be a bit of a hunt to find the size you need. If you try to change the size of a megaprim, it will snap to the current maximum size limit.

The wiki page for object_rez event clarifies that the event is only triggered in the same prim/link. 🙂

Are you talking about doing that in the script/object that called the rez function? Of course that's useful. Bleu's question was about communicating that non-existing UUID to another, external object. If you do that, you've lost the ability to immediately detect rezzes and rez failures. You have to either use a fast timer to repeatedly check "is it rezzed yet?" and manually time out, or you can use a slow timer and end up with an even bigger delay between rezzing and stuff happening... and manually time out. To me it seems like added complexity for no pay-off. Continuing to script external objects the same way as before should work just fine, unless there's some specific use-case I'm not seeing. Is there one?

From a "keep it simple and consistent" perspective... llGetObjectDetails would behave as if you gave it llGenerateKey(), and the object_rez event is where you'd communicate the UUID to other scripts. I don't see any great benefit for "preparing" other scripts for the future UUID, since they can't do anything with that information and would later have to query it themselves (with no possibility of determining whether it will/did ever rez).

All of those other games still use proper names, no gamer is happy being just a number. The main difference Gwyn tried to point out is that the account system could've been designed so that the last name had no impact on how LL recognizes accounts so that we can freely choose any last name we want. The example of 114055US5 is exactly equivalent to the random 32-character UUIDs we have.

UV maps are never identical between different brands of mesh bodies in SL, so seam issues are expected (and much more noticable on high contrast textures like this). While most mesh bodies try to match the LL UV map, it's impossible to get it perfect when there's so many varying shapes and mesh densities. The original LL UV is not very high-topo.

My understanding (with absolutely no prior experience about this disability) is that they don't "see photos as three dimensional," but rather 3D and 2D are indistinguishable to them, similar to a color-blind person saying "red appears green to me." But yeah, I'm pretty sure PBR doesn't have any downsides in this case. It's just a different way of getting the same result. The two lanterns look different because the other one is reflecting the dark grass from the ground.

While I agree that being able to rez objects with custom data already in them is very convenient, I still think that the main goal of having totally scriptless projectiles (that can be used by most weapons) is a way more important feature for the new rez function.

Can we chill with hateful comments like this? It comes off as if you're calling him a sex pest or someone who would take advantage of women, and for what?

REZ_FLAG_NO_COLLIDE_OWNER | REZ_FLAG_NO_COLLIDE_FAMILY 🙂 And yeah, a set of flags similar to STATUS_ROTATE_X/Y/Z (default false?) is the only missing thing, everything else seems to be there and I couldn't be happier to see this.

https://wiki.secondlife.com/wiki/LlManageEstateAccess

You look very handsome today, new hat?

The numbers would correspond with the index in "nameList" in your example. When a user picks the button that says "2", you choose llList2String(nameList, 2);

One of the easier things to do would be to show a list of names in the menu's message area, with the buttons showing matching numbers for each name. As a crude example, the dialog would look like: 1. Wulfie Reanimator 2. SEMaster Aftermath [1] [2]

This, pretty much. I often joke about how SL isn't intuitive even after a decade of experience. It's not even because of problems with the viewer (we don't even have to go there), but because every brand/store has their own way of doing things. It's always a bit of a learning process when everything feels so inconsistent. That's the nature of "everything is created by other users" and while it sets SL apart from many other virtual worlds, there's also sacrifices made along the way.

Make sure none of your BOM layers have temporary textures in them. You said you've started from a default avatar - was it grey when you started? If not, add one thing at a time until you get grey textures. That's where your issue is.