Wulfie Reanimator

I prefer my title anyway.

Super Mesh Bros. They make a mesh body for children.

I guess a broken clock is right twice a day, or one of seven...

Bad wording on my part, it'll stay at least 5 meters above ground, as in you can't fly into the ground (which it would normally do, and dislocate your camera in a weird way).

Making avatars visible has a lot of implications. They need to first implement the SL skeleton, rigging data, attachments, animations, and a whole bunch of other things. I don't know anything about their development plans.

All the usual errors or non-happenings will happen. Objects can't exist independently outside of a region, so you cannot rez things off-sim. It'll just fail silently, since I don't think there's an error associated with "rezzing out of bounds." Personally I would create some kind of HUD that gives feedback like "weapons disabled" or "about to re-enter the region." The movement is way too extreme for any kind of in-world cockpit to be usable.

Yes, but no, but kind of yes. There is no proper 3D viewer for mobile devices like you have on desktop. There are some old unsupported viewers like Lumiya floating around. There is a browser-based viewer called SpeedLight in development. Since it runs in a browser, it even works on an iPad. It has a 3D view in development, but it's very rough.

Better late than never, I stumbled on it again! http://lsl.blacktulip-virtual.com/lslcalc/lslcalc.php

Add a global variable to your script: integer used = FALSE; When the item is used, set it to TRUE. When the object is attached (or whenever the effect would start), first check what value that variable has.

I'm already working on it. Edit: Well, this has been the most fun I've ever had with vehicles. @Nexii Malthus Below is some code for a very basic plane with pitch and yaw. Put the code into a prim and sit on it. It has a sit target 1 meter above the prim and you'll start flying right away. Hold E (jump) to go faster and C (crouch) to slow down. Regular movement keys to turn. Mouselook is strongly encouraged at high speeds. It doesn't limit how much you can pitch, so turning your camera in mouselook might get weird if you go straight up/down or upside-down. It'll fly through any objects, but it'll always stay 5 meters above ground. I don't know what happens if you enter a neighboring sim. If you don't wear your own vehicle of choice, you'll just fly around in your normal sitting animation. You'll also need to use the LSL Preprocessor (Firestorm feature) to compile the code. Sorry. 🤷 #define TIMER 0.05 #define MIN_SPEED 1.0 #define INC_SPEED 0.5 #define MAX_SPEED 85.0 #define VTURN_SPEED 2 * DEG_TO_RAD #define HTURN_SPEED 2 * DEG_TO_RAD #define MIN_HEIGHT 5 integer driver_link; key driver; vector position; rotation direction; float speed; start() { llTakeControls(831, TRUE, FALSE); // All WASD controls + up/down driver_link = llGetNumberOfPrims(); position = ZERO_VECTOR; direction = ZERO_ROTATION; speed = MIN_SPEED; llSetTimerEvent(TIMER); llOwnerSay((string)["Start"]); } end() { llReleaseControls(); llSetTimerEvent(0); llOwnerSay((string)["End"]); } default { timer() { position += <speed * llGetAndResetTime(),0,0> * direction; float ground_height = llGround(ZERO_VECTOR) + MIN_HEIGHT; if (position.z < (ground_height)) { position.z = (ground_height); } llSetLinkPrimitiveParamsFast(driver_link, [PRIM_POS_LOCAL, position, PRIM_ROTATION, direction]); } control(key id, integer held, integer click) { if (CONTROL_UP & held) { if ((speed += INC_SPEED) > MAX_SPEED) { speed = MAX_SPEED; } } else if (CONTROL_DOWN & held) { if ((speed -= INC_SPEED) < MIN_SPEED) { speed = MIN_SPEED; } } if (CONTROL_FWD & held) { direction *= llAxisAngle2Rot(llRot2Left(direction), VTURN_SPEED); } if (CONTROL_BACK & held) { direction *= llAxisAngle2Rot(llRot2Left(direction), -VTURN_SPEED); } if (CONTROL_LEFT & held) { direction *= llAxisAngle2Rot(<0,0,1>, HTURN_SPEED); } if (CONTROL_RIGHT & held) { direction *= llAxisAngle2Rot(<0,0,1>, -HTURN_SPEED); } if (CONTROL_ROT_LEFT & held) { direction *= llAxisAngle2Rot(<0,0,1>, HTURN_SPEED); // Roll: // direction *= llAxisAngle2Rot(llRot2Fwd(direction), VTURN_SPEED); } if (CONTROL_ROT_RIGHT & held) { direction *= llAxisAngle2Rot(<0,0,1>, -HTURN_SPEED); // Roll: // direction *= llAxisAngle2Rot(llRot2Fwd(direction), -VTURN_SPEED); } } run_time_permissions(integer perm) { if (perm) { start(); } } changed(integer change) { if (change & CHANGED_LINK) { if (driver = llAvatarOnSitTarget()) { llRequestPermissions(driver, 3092); // All auto-perms } else { end(); } } } state_entry() { llSitTarget(<0,0,1>, ZERO_ROTATION); llForceMouselook(TRUE); } }

Oh, that solves that mystery. It wooshed over my head that the vehicle asks permission to attach something to your avatar when you sit on it. Then the vehicle you sit on hides itself and you're left with the one attached to you. Then it moves your avatar as you described. Kinda ingenious. If you right-click the vehicle you're "sitting" on, it has the detach option, which I didn't even check. Here's a simple demo that you can sit on and click-and-hold to move yourself far off-sim. It reaches about 900 meters. vector pos; default { state_entry() { llSitTarget(<0,0,1>, ZERO_ROTATION); pos = llGetPos(); } touch(integer n) { llSetLinkPrimitiveParamsFast(2, [PRIM_POSITION, (pos += <1,0,0>) - llGetPos()]); } }

You warp onto the sim border, as expected. Inspecting how the object is built, I don't see anything out of the ordinary. It's 5 prims, 4 of them are tiny and hidden away (particle emitters/sound), and the main mesh. It doesn't have an offset root like I would've guessed, either. The object is set to temporary and phantom (not physical). It doesn't use physics as it says on MP and shown in the video, it's purely scripted movement. That's why the camera movement is so janky. It can't use llSetRegionPos, llSetPos, or PRIM_POSITION since those don't let you go far outside of sim bounds (tested)...

I went to try the demo in-world and okay, this is actual black magic until proven otherwise. I'm completely baffled as to how this jet ski is built, and I'm staring right at it, at <934, 99, 20>

Regarding the title and "so that it can go off my private region," I don't think what you're asking is particularly possible, if it is what I think it is. Objects can't leave the boundaries of a region, with some caveats. The root of an object must be inside of region boundaries, but individual links can go beyond. A vehicle could theoretically get about 64 meters outside the region boundaries if it was scripted in a very specific way, but I don't think that kind of technique is something that would be even remotely easy (or brief) to explain to a beginner.

Not possible.

What you see or experience as an end-user is no testament to what the script is actually doing. You are literally oblivious. Refer to the script I provided above.

Trust me, I know very well how to write the scripts for the things you're talking about. I'm very experienced with LSL with a long history of helping others here and in-world. Did you check the page I linked earlier? Here it is again: http://wiki.secondlife.com/wiki/LlRequestPermissions I'm starting to run out of ideas on how to communicate this to you any more clearly than I've already tried. Scripts have to request permissions for a lot of things or they will shout errors at you. Most permissions are granted automatically under certain circumstances: Attachments will automatically get permissions to: Replace animations (walking, standing, jumping, etc.) Detach themselves from the avatar Objects that you're sitting on OR wearing will automatically get permissions to: Know where your camera is Control your camera Take control of your movement keys and keep track of them Start and stop animations (dance balls, shopping bags, furniture, vehicles, weapons, etc.) "Automatically" means that you won't see a dialog asking for permission. When the script makes a request with llRequestPermissions, the script will just instantly get the permissions it asked for without you even knowing that it tried to ask for it. For example, the "start animation on attach, stop on detach" script is basically this: default { on_rez(integer start_param) { llRequestPermissions(llGetOwner(), PERMISSION_TRIGGER_ANIMATION); } run_time_permissions(integer permissions) { if (permissions) { llOwnerSay("I was given permissions!"); } else { llOwnerSay("Why are you mean to me?"); } } } If you put that script into a box and then wear the box, you'll see what happens. If you then detach the box and rez it on the ground, you'll see that something different happens. (Note to other scripters: I wrote it the way I did intentionally.) Edit: @KT Kingsley, there are some cases where an animation will get stuck during detach but I don't know off the top of my head what those cases are. I also know there's limited time during detach but certainly enough to stop at least one animation. (In my experience you get about 4 function calls' worth of time, not exact of course.)

I would love to see an example of your script that plays an animation without requesting permissions. I would also love to see a case where an animation stops when the attachment is taken off without the script doing that explicitly. The distinction is that vendors and tip jars don't "take" money. You "give" money, as in, the transaction is initiated by your viewer and not by any script. There are only two functions that can "take" money from you. llTransferLindenDollars and llGiveMoney (which is an older version of llTransferLindenDollars). They both have "scary" warnings because they can initiate transactions on their own at any time, as many times as they want, after the script has been given permission to do it once. That is a real concern no matter how useful those functions are. The bottom line is that as things are right now, what you're suggesting is impossible. Whether or not something new could be suggested is another conversation, but I don't think you'll find many people voting for automatic debit-permissions.

Permission to animate an avatar is automatically granted if the request is coming from an object that is attached to the target avatar. The request still needs to be done. If you rez your object on the ground instead of attaching it, you'll see the permission dialog (unless the script is written smartly in such a way that it won't try to request permissions if it's rezzed.. in which case it won't animate you either). Many permissions are granted automatically if the target is sitting on the requesting object, or has it attached. See this page. You being able to pay an object is completely different from the object taking money from you. They're like the opposite lanes of a highway. You definitely shouldn't confuse the two.

Quoting myself as well because I can't edit that post anymore. I'm not sure why I didn't realize this at the time but the rez solution has the same ownership problem as the demo/HUD. The rezzing has to be done by you, so you'd be the owner. So if you pay the vendor... you get your own money.

It looks like either your texture has an alpha channel (most likely, based on the screenshots), or your face normals are pointing the wrong way. To fix the alpha issue, edit your object, go into the Texture tab, and set "Alpha mode" to "None." To fix the face normals, look up "flip normals", "recalculate normals" or "fix normals" for Blender. Another question, how many triangles is your object?

The algorithm for sorting places is not always by traffic alone. The Websearch defaults to "relevance" which could be anything as far as I can tell: I'd show the legacy search for comparison but the results are quite wild. Well, if your goal is to meet people, the first place to look for most people is not low-traffic sims. It's a rich-get-richer type of thing from the average users. And ironically the ones that are "hidden away" are by far the easiest to find and instantly identify. This trend of "afk" hangouts makes it basically impossible to identify traffic bots in plain sight. Even real people use text viewers so they can afk more efficiently. Regarding the enforcement of traffic bots, it seems pretty hit-and-miss. I've noticed a handful of places get cleaned up a few days after my reports (I used to hunt for bots for entertainment), but I don't know whether that was because of reports or because nobody else actually visited the places and they just shut down. There are certainly some big places that have been around for a very long time that just don't seem to get touched at all. There's literally nothing that couldn't be faked by a bot. You can create artificial keyboard inputs and mouse movements, it's not worth chasing that goose when the viewers are open-source. Ideally, traffic would be changed to "activity" and it would take all aspects of what avatars can do into account, maybe with slight weights on things that promote social interaction the most, but that's probably not as important as it's very subjective. An avatar that does nothing should not count towards activity.

People won't stop selling skins though. Even if appliers go away, people will sell system skins at the same price. I don't think appliers will go away anytime soon, especially for backwards-compatibility, but still.

When it comes to appliers for a specific body, that's the ideal case because it means the texture is probably made with a template of that specific body. When it comes to "universal" appliers like Omega, there's only downsides compared to BOM. Omega does not make the textures universal, the only thing special about Omega is that it can talk to multiple bodies at once. The textures were still made with some specific template -- either a specific mesh body or just the base LL body. The texture will only match one body as perfectly as the creator made it, while the others will have at least minor defects. An easy example if you have Maitreya and Belleza bodies: Get your Omega applier and apply it to both bodies, then look at the toes. TLDR: Omega will die to BOM.