Quistess Alpha

Because putting scripts inside of objects that go inside other objects is a nightmare for version control and rapid prototyping? There is no way around the forced sleep though, other than not using forced-sleep functions and having the scripts pre-installed. *sigh*

Upper right of the window "export as collada" file selection: That's the most important checkbox, you might also need to fiddle with the axes under the 'main' tab in that section.

Does the "child prim" version not work in the root? As I said in another recent post, the root's local position is always ZERO_VECTOR and it's local rotation is ZERO_ROTATION. "Relative to the root" is just moving it to a specific local orientation & position.

IMO you shouldn't, make an invisible prim with a sane x-forward rotation the root of your vehicle. But for the sake of a more concrete solution, remove '/llGetRootRotation()' from your snippet. The root is always at zero rotation with respect to object-local coordinates.

Yeah, but you should make the 'basic rules' clear. if combining flint and wood is different than combining wood and flint, that should be made clear, as should whether you can combine 3+ things, or combine something with itself. It's very hard to make a puzzle about understanding the basic operations. it's possible (see 'Baba is you') but you'd really need to set-up and "motivate" a solution that really required doing something that wasn't explicitly provided as a possibility.

The opposite of that. If it's possible to do a thing, or use a specific word, there should be clear easily accessible documentation of it. Something like "help take" should also mention that "t" is an acceptable shortcut (if it is) and perhaps list a couple example invocations. "help" or "help commands" should list all the available words (perhaps not their abbreviations, I'd say its fine to leave shortcuts under their full-name) and group them into thematic sections.

According to @Frionil Fang's link, it's just unused. print(); causes an error ~after they keyword, but event; causes an error before the keyword. Interesting tangent: string s = print("string"); causes an "Internal server compile error".

At least, that's why I assume it's bringing up a syntax error in an otherwise perfectly fine script. string event; default { state_entry() { llSay(0, event); } } Syntax highlighting (in-world editor) isn't catching it though.

ZHAO II (the 2 is important) also uses llSetAnimationOverride, but has support for multiple stands and is fairly standard. You can get the source from https://www.outworldz.com/lib/ZHAO-II AO for Second life/ZHAO-II AO for Second life/Object/ZHAO-II.lsl

Just to eliminate possible name-mismatch errors, I tried: string strBall; default { collision_start(integer total_number) { llSay(0, "Hit by " + strBall=llDetectedName(0)); llCollisionFilter(strBall, NULL_KEY, TRUE); } } and it worked as expected. It's always a good idea to do a sanity check, like: string str1 = "Ball"; string str2 = llDetectedName(0); llSay(0,str1+"::"+str2+"::"+llList2String(["match","do not match"],str1!=str2)); because a space in the name of your mesh ball or capitalization could mess things up. ETA: Second Life Server 2022-07-07.573176 ; Rolig's script as she wrote in the OP works for me as well.

Perhaps the opposite. when you're testing on the beta grid, fly up close to 4096 meters.

press "OK" -> Interestingly, after deleting the thing, the links point to the thing in the trash, and after purging the thing from the trash, the links seem to get deleted.

in many TPVs (I dunno if it's in the main viewer that I can't really use) there's a "replace all links" function: right click on a thing that's in a lot of outfits, and then 'replace all links' and you cna select another object to get used in its place. useful for updating all your outfits with a new version of a thing. Also, that reminds me of another interesting facet of links. if an object has links to it, you get warned when deleting the thing, so you're less likely to break your outfits by accidentally deleting your meshbody, or something similar.

FWIW, I often mis-use the meshes that come with furware text. the UV mapping is a little off from ideal, but it's close enough, and having 8 faces in a row is useful for a lot of things.

Sounds like a problem for media on a prim. Make an image with CSS/HTML and display it on the prim.

Erratic's products are what I know the best, and yeah a lil' expensive for what it is, but not ludicrous. Bom/Applier are fine for plain sheer, but you really need something with better texture density for fishnets. ETA: A major difference between BOM/Applier and mesh is toenails, and the top rim. BOM won't always look exactly right at the top of a "sock" because mesh bodies don't always conform 100% to the LL UV map. Appliers made for a specific body shouldn't have that problem, but may or may not cover toenails (I've never really used appliers) If your toes and the tops of your legs are covered by something, and you don't need/want any particularly interesting texture to your stockings/nylons; a simple transparent BOM sock layer is almost trivial to make yourself.

Check again, general discussion (for example) is not visible, although you can see a preview of what the last post was.

Many of the sub-forums can't be seen without being logged in, but some can, like "favorite destinations" and "fashion" (but not "your avatar") for example.

I don't see why/how there could be any moderation on what you're allowed to put in a report. there aren't a whole lot of ways to be 100% sure someone's an alt and not, I dunno, a cult member though.

Yeah, I don't really know enough about viewer internals to say definitively, but I would imagine a TPV could let you attempt to "open" click-to-open things that aren't yours and just disallow the next step of taking to inventory if they wanted to. As it is now, if you can't modify such a thing, the cursor icon doesn't even change when you hover over it.

I think the real problem is that a non-owner can't open a box. "opening" is intended for moving things from a box into your inventory, that it happens to incidentally allow moving things into the box is an odd quirk. A more coherent "minimum demonstration" would be: default{ state_entry() { llAllowInventoryDrop(TRUE); llSetClickAction(CLICK_ACTION_OPEN); } } which doesn't allow drop by non-owners if it's not shared with a (not- 'none') group that droppers are a part of (and have modify group objects ability in).

Unfortunately what I posted is only a snippet that would help someone who is comfortable writing scripts improve an already existing AO script. I might post a full AO sometime in the future(TM) but it would be a bit of work to fix up mine to a 'presentable' state. I also didn't mention the caveat that when a region lags in a certain way (I'm not 100% which) it can cause your avatar to walk into the air, and it can mess with jumping, so you also have to add a button on the AO to turn it off and on again. . .

Actually I have 2 premium accounts, which I made the annual payment for within a month of each-other. I put in a support ticket to ask why one paid tax and the other didn't, and "first time purchases don't pay tax" was the answer I got.

if it works like US sales tax, you don't get charged the first purchase, but you ~Do pay when it gets renewed a year later. maybe in another 10 months or so I'll have the guts to ask/experiment to see if cancelling my premium for a few days then buying it again would save me a few dollars of sales tax. . .

This just in: A new LSL function (well several month old now. . .) llGetVisualParams lets you check how high you and your friends' (BOM) pants ride! default { touch_start(integer total_number) { list params = llGetVisualParams(llDetectedKey(0),[814]); integer height = (integer)(100*llList2Float(params,0)); llSay(0,"Your (BOM) pants are riding up "+(string)height+"%"); } } Discuss how this new functionality can be used to make SL the best it can possibly be!