Wulfie Reanimator

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.

It has nothing to do with attachment order, it's only used for the order in which rigged attachments are "drawn" on the screen. It helps with alpha-glitches.

Well yeah, but aren't we talking about inventory assets? The main point might be about textures in specific, but the description as we interact with it isn't any different between inventory item types. It's always readable regardless of owner/permissions, scripts just don't happen to be able to read it.

What kind of privacy issue? An inventory item's description is always visible, even if you're not the owner. It does!

The places that use LLCS (Linden Lab Combat System, AKA health) set up the spawn areas so that anyone can set their home there, regardless of group.