Quistess Alpha

What sorts of issues? I have a pretty large volume detect (or maybe phantom, I didn't script it so I'm not 100% on its internals) cube over my house that's part of a uh, RP system I use often. I've never had major issues with it, except I think it prevents sitting on unscripted prims.

The local position of another attachment isn't particularly useful unless you have a script in that attachment. If you have some HUD+attachment combination (for example) and you want the HUD to move the attachment with some arrows, I'd just have the HUD tell the attachment which arrow was pressed, and handle the movement in the attachment's script.

I'm not really fluent with javascript, I just know how to search for examples and apply them in context... It's almost certainly possible to style individual elements with javascript, and hypothetically you could read a CSS (or conveniently modified personal format) as plaintext and manually apply features, but that would be very involved. Simple duck-duck-go searches for 'load CSS with javascript' return some promising avenues, but I've not personally tested them, and as has been seen before in other threads, you really need a good sense of what you're doing and debugging workflow to make this stuff work.

Can confirm, not being able to serve separate CSS via LSL is a pain. If you really know your way around CSS, you can cook up some ok short stuff in the preamble, but it really eats into your memory usage. Have you tried complaining on the jira?

When a thread gets locked seconds before you post a clever (albeit off-topic) reply. . .

<.< I'm not from Saturn, you're the Saturnite!

key uuidOfPersonToSpam = "some UUID"; default { state_entry() { llSetTimerEvent(60*60*24); // #seconds in a day. } timer() { llGiveInventory(uuidOfPersonToSpam,llGetInventoryName(INVENTORY_NOTECARD,0)); } touch_start(integer n) { if(llDetectedKey(n)==uuidOfPersonToSpam) { llSay(0,"Really, please do stop spamming me!"); llSetTimerEvent(0); } } }

Using experiences rather than regular permissions would require a (fairly minor) change to the actual scripts.

"coming out" on a platform that doesn't directly link to your RL is completely different than coming out on a platform that actively tries to ensure (I'm not saying it succeeds) that every account corresponds to a specific RL identity.

Reading between the lines, it seems the feature is a bit buggy at the moment. We can only hope they're only doing it at the estate level only now to limit the amount of direct support work and fix the bugs before 'everyone else' gets access.

In the context of SL, often used as slang for someone who can do weight painting to make an attachment (clothing) move with your body when worn. Probably not what the OP was referring to in this case though.

Yup, llSetHoverHeight, llGroundRepel and llRotLookAt, llMoveToTarget, and presumably anything else which does a physics thing all turn off when the script is set to not running. Funny though, if a thing is stationary in the air when the script gets turned off, the simulator won't remember to kick gravity in until it gets a little shove. Coyote time perhaps? default { state_entry() { //llSetHoverHeight(3.0,TRUE,0.5); // choose one of 3 //llMoveToTarget(llGetPos()+<0,0,3>,0.5); //llGroundRepel(3.0,TRUE,0.5); llRotLookAt(ZERO_ROTATION,0.5,0.5); } } // set running to false ; see it fall and spin.

Yeah, I don't think there's anything that can be set without a script, which would be lost in a copy. There are also some odd ones like llHover which I think is set like a prim property but it 'turns off' if the script stops running.

also reset as far as I can tell. default { touch_start(integer total_number) { // set physics on and gravity to 0 in the build menu, //too lazy to script it in. llSetVehicleType(VEHICLE_TYPE_BALLOON); llSetVehicleFloatParam(VEHICLE_VERTICAL_ATTRACTION_TIMESCALE, 4.0); llSetVehicleFloatParam(VEHICLE_VERTICAL_ATTRACTION_EFFICIENCY, 0.5); } } copies fall (or go in whatever direction they think they've been pushed), but when set to balloon, floats to a specific distance above ground.

It's not at all obvious, and definitely the kind of thing I would test right before doing something where the behavior was somehow important, but because I was curious: Does X survive after a shift-copy? Linkset Data: Yes, survives copy. Particles: Yes, survives copy. Physics material (is physical, gravity, friction etc.): Yes, survives copy. Phantom: Yes, survives copy. Temp-on-rez: Copy is immediately deleted. Locked: Cannot perform the copy. Yes, Ctrl+d does perform a copy, and the copy will also be locked. Script state: No, is reset. Omega: No, is stopped. (even if was physical; copy may spin if physical and non-phantom because it gets pushed by original, not due to intrinsic omega/torque) Texture Animation: No, is stopped. Looped sounds: No, becomes silent. Torque: No, is reset to 0. Force: No, is reset to 0. llSetStatus parameters: Mostly No, STATUS_ROTATE is reset to default, and I would presume anything except phantom and physics (which do survive) is reset. Vehicle parameters: No, seem to be reset (see below). default { state_entry() { llSay(0, "Linkset Data: "+llLinksetDataRead("key")); llSay(0, "Torque: "+(string)llGetTorque()); llSay(0, "Force: "+(string)llGetTorque()); } touch_start(integer total_number) { llLinksetDataWrite("key","value"); llTargetOmega(<0,0,1>,0.5,0.5); llSetTextureAnim(ANIM_ON|SMOOTH|ROTATE|LOOP,ALL_SIDES,1,1,0.1,PI,0.2); llParticleSystem([PSYS_SRC_BURST_RATE,0.5]); llLoopSound("a3325291-3b1e-f4d4-b18c-94e77e415481",1.0); llSetTorque(<1,0,0>,FALSE); llSetForce(<0,0,0.01>,FALSE); llSetStatus(STATUS_ROTATE_X|STATUS_ROTATE_Y|STATUS_ROTATE_Z,FALSE); } }

https://www.dropbox.com/s/qogvwaks7atvi0y/ULTRA!.blend?dl=0 https://marketplace.secondlife.com/p/TMG-Bladencat-MK8-ULTRAUpdated-6-15-20/19280993

(couldn't be bothered to take a new screenshot in world so here's an old one): The red, green and blue control arrows that let you move an object while it's selected in edit mode and the 'move' tool is active. (I.E. neither the stretch nor align tools are active)

Shift-copy* resets scripts, which can be used as a very unintuitive hack to reset scripts in no-mod but copy-able objects. *By which I mean, rez the object in-world, right click on it-> edit, hold shift and drag one of the arrows. The copy that is moved will be the original not-working (presumably) copy, and a version with reset scripts will be where it was before being moved.

Bots have access to viewer functionality. LSL can't read your profile*, but a bot can. Bots are faster at 'reading' than people are. the time it takes me to pop into a busy sim with say, 30 avatars and read all their profiles is maybe 5 minutes if I'm just copy-pasting to a document. a bot could do that in a couple of seconds, and can find new regions with lots of people in them faster than a person doing it manually. Anything a bot can do, it can do faster than you. *Actually LSL could look up your web profile with a HTTP request, but that's not the point.

That's (more-or-less) a result of the 'gimbal lock' problem with euler-vectors; there are multiple values of x,y,z that correspond to the same orientation, and converting between them is, non-intuitive. It's even less intuitive that Linden-euler-vectors are not in the relatively easy to conceptualize pitch-yaw-roll format. If you wrap your head around axis-angle form, quaternions are (IHMO) actually easier to reason about. I've heard a 'orientation mixing' mental model can also be useful:

I think that's more-or-less just llSetRot(<1,0,0,1>*llGetRot()); // rotate 90 degrees on intrinsic x-axis with some obfuscation thrown in. <1,0,0,1> is a non-normalized 90-degree x-axis rotation.

oh, your keys seem to have a bad intrinsic rotation. try reversing the order of apply and rot as suggested in the script's comments.

Nice video, but I can hear your voice but not the sound that's supposed to be playing? (Oh! it's a typing sound, that's not confusing at all. . . ) maybe something louder and more obvious would have been better for demonstration.

It would help if you were more clear about what you want it to do; you have a lot of weird irrelevant stuff in the script. float rotClickAngle = 10; default { state_entry() { rotClickAngle*=DEG_TO_RAD; } touch_start(integer total_number) { integer link = llDetectedLinkNumber(0); rotation rot = llList2Rot(llGetLinkPrimitiveParams(link,[PRIM_ROT_LOCAL]),0); rotation apply = llAxisAngle2Rot(<0,1,0>,rotClickAngle); llSetLinkPrimitiveParams(link,[PRIM_ROT_LOCAL,apply*rot]); // reverse the order of apply and rot to use root axes instead of link axes. } touch_end(integer total_number) { integer link = llDetectedLinkNumber(0); rotation rot = llList2Rot(llGetLinkPrimitiveParams(link,[PRIM_ROT_LOCAL]),0); rotation apply = llAxisAngle2Rot(<0,-1,0>,rotClickAngle); // use negative axis for reverse. llSetLinkPrimitiveParams(link,[PRIM_ROT_LOCAL,apply*rot]); // reverse the order of apply and rot to use root axes instead of link axes. } }

There are many things you can do to make it seem more 'realistic', but the bare minimum is pretty simple: default { state_entry() { llSetStatus(STATUS_PHYSICS, TRUE); llSetStatus(STATUS_ROTATE_X,FALSE); // set these to TRUE or FALSE depending on the desired behavior and intrinsic axes of the object. llSetStatus(STATUS_ROTATE_Y,FALSE); llSetStatus(STATUS_ROTATE_Z,TRUE); llSetHoverHeight(0.0,TRUE,0.25); } } see also: