Wulfie Reanimator

Just had the opportunity to sit down and try out the new rez function and let's just say I'M REALLY EXCITED My plan was to make a really naive gun as a reference, then convert that to llROWP and see what the differences are before messing around with rez nodes for testing the potential rez-rate. Well... This is a single-script gun that rezzes scriptless bullets from the control event "if (level & CONTROL_ML_LBUTTON)" The rate of control-events changes depending on what the avatar is doing, that's why the bullets "rez faster" while I'm walking around. (This is why I mentioned that we may need a rez-node anyway for consistency.) No big deal. I was optimistic before, and still somehow really surprised by how well it works in practice as a starting point! This is a huge improvement from the jerry-rigged weapons we'd normally have to make. A single loop-based rezzer seems to be able to reach a consistent 1150 (+- 30) RPM with llROWP. That's almost twice as fast as anything timer-based, and almost thrice as fast as rezzing with the forced delay. Moving while using control events (with that single script) somehow reaches 1350 (+- 10) RPM very consistently. Rez-queue is of course still a thing if the sim is having trouble. There was a random moment in Jigglypuff that caused my gun to not rez anything at all for about 5-10 seconds. After that, all of the objects rezzed at once in one big shotgun-blast. It didn't happen again, and this is not how the grey-goo fence works, so it wasn't that. One little thing about REZ_POS and locality. Usually we want projectiles to rez relative to the camera, or at least its rotation, like this: vector position = llGetCameraPos() + ( <2,0,0> * llGetCameraRot() ) (Alternatively just llGetPos/llGetRot for mouselook-based weapons. Rotation will be the same, but position will be lower.) In the video, you can see I'm using REZ_POS as a local offset. It works, my bullets are rezzing from 2 meters in the Y-axis from my avatar, but it doesn't respect the rotation of the rezzer/avatar and the projectiles always rez from the same spot even as I look around. If I look toward the X-axis, the bullets will rez from my left. (This applies to non-attached rezzers as well.) This can be easily fixed by just doing the calculation as usual, but I feel it might be more beneficial if the "relative position" would take the rezzer's rotation into account. At least if the rezzer is an attachment? Thoughts? A really cool thing about the parameters is that all of the values can be potentially static values and the whole list could be stored globally. I don't know if there's any measurable difference between rebuilding the list for every call instead of just copied from a global variable, or appending the manually-calculated position data to it.

They're my own scripts that anyone can use if they have the TamperMonkey extension (or equivalent) installed. I use Firefox myself, so it definitely works there. I'll PM the details, nothing complicated. P.S. I'm a woman.

I agree, and it's kinda possible right now with browser extensions. 🙂

Yeah, you can tell it's the physics shape simply from seeing the LI shoot up after you set the physics mode to Prim. That's when it's using your custom shape, so the change in LI is a direct result of that. And when it comes to your physic model, it's way too detailed, I would've expected it (and your other physics models) to have high LI before even checking! When making a physics model, remember that it's never actually seen. It's just there to approximate collisions. For example, you don't need that beveled edge on the step inside the tub. You also don't need that many loops around the cylinder, you can safely remove half of them with no noticable effect on the "shape" of the pool. Getting rid of those should significantly ease the LI cost of the tub already. There's a whole bunch of other simplifications that could be done, but this might be enough.

How about a screenshot of your hot tub's physics model? It's a tub -- you probably don't need anything substantially more complex than a 6-sided cube.. maybe an indent if you want to let people freely stand in it.

ElleEvelyn's suggestion is pretty much the only way to stream live music wherever your avatar is. Another alternative would be tied to land (parcel music or media stream) or a rez-rights (rezzed media-on-a-prim which has a much higher chance of being heard by others). If you just want to be able to play music (not live), you could use one of many different notecard-based music players. Those can be worn and heard by others by default.

There's really not a "strain" added to the group chat system from having one bot sit in a group and reading/sending messages on behalf of a bunch of people. If anything it can reduce the number of avatars that has to be sent a message by LL's system and alleviates the "struggle." Builder's Brewery is one really good example of a large group starting to use Discord for things like classes/homework and getting more help from people who just aren't in-world at the time when somebody asks a question. The group has a bunch of really knowledgeable people who mostly respond from Discord. That help would be missed.

Most people have no idea where the boundary between LSL and RLV is. 😋 I wouldn't focus on specific terms like this, same with OP's interchangeable use of "give/take." We still get the idea. (I say this to both of you.)

I still kinda don't understand what the shoulder issue is supposed to be. I don't think anyone's ever posted a picture to demonstrate it. Are they referring to shapes using wide shoulders or something?

Like people don't already put overly shiny materials on most things?

A warning is a warning, just make sure that your recording isn't choppy and be prepared for whatever you're trying to record (like SL) to be less responsive and/or run with less framerate. If you don't notice a problem, there may not be one.

Maybe? Even if it wasn't against any rules and you couldn't get into trouble with LL, it feels wrong to keep money that was given during fetishplay if they regret it, at least when it's "a large amount." In that situation, the right thing to do would be to give it back, and stop findomming that person if they're prone to regret. If it can't be given back because it was already spent, then the right thing to do would be to just stop taking more. Findom is a consent thing, without that it's just stealing. 😋 For what it's worth, LL has access to all IMs between you and that other person. If it's very clear that the person was okay with you taking the money with scripts, you should be fine. Otherwise I imagine LL would rather treat it as fraud.

Generally speaking, some groups have "anyone can join" turned off so you can't join it from search, but uses a bot to automatically invite anyone who visits the sim or otherwise request an invite.

Which Vista AO do you use? It's completely normal for modern AOs to continue working even after you detach them! This is documented and intended behavior for the script command llSetAnimationOverride. The AO will keep working after the script is detached, unless the script turns them off at the same time. To make it stop, detach the scripted AO and stop animations from the "Avatar Health" menu. (If that somehow doesn't work or you can't find the menu, relog while the AO is detached, and don't put it back on.) Firestorm's built-in AO doesn't use scripts and it won't keep playing animations if you turn it off.

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. 🙂