Jump to content

Wulfie Reanimator

Resident
  • Posts

    5,723
  • Joined

Everything posted by Wulfie Reanimator

  1. You don't have to create the group unless you want to make it harder for someone to squat on the land without your permission. You can totally leave rezzing available to everyone and just check the land every now and then. One benefit might be that the tenant won't need to contact you to get into the group after paying. (I don't remember how group-owned land works.)
  2. Yep, since you own the land and the group, you can return their stuff and kick them from the group.
  3. You'll want to restrict rezzing to a group (or watch for squatters), then just make sure the tenant pays the rental box and joins the group. The group could be invite-only, if you want to really keep squatters from placing their own stuff down. A bot could be automated to invite new tenants to the group when they pay, or you'll have to invite them yourself. I dunno about CasperLet either but the general idea is simple. You should own the land on Mainland, always. If you sell it, you can't reclaim it like Private Sim owners can.
  4. And mainland tier has been reduced. And you can now buy homesteads without owning a full sim if you're Premium Plus. And you can pay tier with lindens, without selling them on LindeX.
  5. llDetectedDamage springs to mind... I'd assume that's been Jira'd at some point, can we revive/remake a ticket? Non-physical damage prims are used in things like raycast weapons and explosives, pretty common occurrence. Speaking of damage! @Rider Linden I found one damage-enabled parcel in Aditi, but I can't rez in it. Did negative damage make it in? Also, in case it got lost in my my previous post, I think relative REZ_POS should take the rezzer's rotation into account.
  6. OBJECT_GROUP works even better, without risk of spoofing!
  7. It's also impossible to export lights from blender. You have to create them yourself in-world.
  8. You can get them back from the "library" section of your inventory. It should be at the very bottom. The library is something everyone has access to, and nothing can be deleted from it. You can find all of the starter avatars in there.
  9. The neck seam is always there under most lighting conditions, unless the head's neck is specifically made with the body in mind. The problem is caused by the edge-normals not matching at the seam, so each mesh will respond differently to light. A common solution is to cover it up with something, like a necklace/choker/collar/turtleneck/etc.
  10. 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.
  11. 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.
  12. I agree, and it's kinda possible right now with browser extensions. 🙂
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.)
  18. 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?
  19. 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.
  20. 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.
  21. 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.
  22. 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.
×
×
  • Create New...