Quistess Alpha

I've seen a few in the events section, lemme see if I can pull up a few links. . . I thought there were more, but all I'm seeing at the moment is classes for learning English https://secondlife.com/my/community/events/event.php?id=8578668 https://secondlife.com/my/community/events/event.php?id=8611147

Indeed, especially when it comes to moral questions, unless the framework you're arguing under is well established, and all parties to the debate accept the framework, (or agree to argue with respect to it for the sake of debate) the discussion really can't lead to anything of value, other than tacitly asserting one's own moral framework as the "correct" one.

There's no 'reliable' solution, but I think you could probably get "OK" results if you restrict the problem domain to only single-person upright chairs: Find the chairs intrinsic axes and compare to world axes, If <0,0,1> and chair's Z are similar enough, sit at <chair's position>+<0.25,0,0.25>*<chair's rotation> or so, with rotation = chair's. Otherwise, guess the forward axis of the chair and sit accordingly.

Perhaps not useful in this specific scenario, but I keep forgetting OBJECT_GROUP_TAG exists, which can allow for more specificity than just the active group, but also what role the avatar has in the group.

"Deformer" usually refers to a SL product that changes the positions of your Avatar's bones to make shape changes more specific than can be done by editing your shape and moving the sliders. The main techniques are usually using a specially made piece of mesh, or playing a special animation. Both techniques, are kindof "hacks" (in my opinion) that are unintended and can have some weird side-effects, but people like the results enough to buy the product. Defeats the point of the discussion, but for posterity: vector Axis = <0,0,1>; // z axis float Angle = 15*DEG_TO_RAD; // 15 degrees. llSetRot(llAxisAngle2Rot(Axis,Angle)*llGetRot());

That's part of LL's secret sauce. I think the only way to know for sure is to create some tests and run them.

Yeah, my thoughts were that it was probably something related t not resetting on owner change, or not resetting when the links are changed/renamed. Both of which are fairly simple to add to a script.

We can't help with no-mod scripts, that's something the scripter has to figure out. That's also one of the reasons I always sell custom commissions as full-perm. Only thing you can do is ask for a careful side-by side comparison, your scripter passes you the script, you both do the same steps one at a time, and see if/where you get different results. Tangent, but isn't the latest viewer version 6.5.5 now?

searching the MP for trousers (or 'cargo pants'), with price set to 0 or 1 (to get demos and filter out most of the 99 color option spam) under woman's bottoms gives quite a wide variety of results. (cargo) https://marketplace.secondlife.com/p/Full-Perm-Futuristic-Casual-Sports-Cargo-Pants-For-Legacy-Maitreya-Slink-Belleza-Kupra-Tonic/23552436 trousers: https://marketplace.secondlife.com/p/IROS-High-Waisted-Trousers-Black/5001011 https://marketplace.secondlife.com/p/RowneLyn-Trousers-Demo/6223824 https://marketplace.secondlife.com/p/QE-Heather-Trousers-DEMO/22295048 https://marketplace.secondlife.com/p/Blueberry-Rene-Mesh-Leather-Pants-MaitreyaBellezaSlink-DEMO/7821081 https://marketplace.secondlife.com/p/Gawk-DEMO-Summer-Drainpipe-Pants-Mesh-for-Maitreya-Mesh-Body-Classic-Avatar/14615925 https://marketplace.secondlife.com/p/COCOWideLegTrousersDEMO/15012305 some of those might be a bit more tight-fitting than you were looking for though.

IIRC scripts created in inventory can also default to mono being off. always a good idea to keep the mono and running check-boxes as one of the obvious things to check in your mental "why is this not working?" checklist.

Oh and as for things I don't know: animation and mesh modeling. How anyone can do serious work with a modeling system (blender) that works on a vertex-line-face model rather than a volume/operation model is beyond me. In my super limited experience with blender, I'm constantly a bit annoyed that I did something slightly wrong 2~3 steps ago, and have to undo/redo steps rather than just plugging in numbers to the older steps after the fact.

Despite how simple the basic script is, I constantly run into people passing me variations(so that I can fix it to do the thing they want) that have been artificially complicated. FWIW Here's my base particle script, a link to the wiki and my off-the-top-of-my-head checklist of most common problems people have with particles default { state_entry() { llParticleSystem( [ PSYS_PART_FLAGS, //PSYS_PART_BOUNCE_MASK| // particles 'bounce' when falling down to the z=0; plane relative to root. //PSYS_PART_EMISSIVE_MASK| // fullbright particles //PSYS_PART_FOLLOW_SRC_MASK| //follow source, but disable burst radius. //PSYS_PART_FOLLOW_VELOCITY_MASK | // particles point their 'up' towards their heading. PSYS_PART_INTERP_COLOR_MASK | //color and alpha change over the particle's lifetime. PSYS_PART_INTERP_SCALE_MASK| //particle size/scale changes over the particle's lifetime. PSYS_PART_RIBBON_MASK | //PSYS_PART_TARGET_LINEAR_MASK | // straight line between src and target. //PSYS_PART_TARGET_POS_MASK | // particles attracted to target. //PSYS_PART_WIND_MASK | 0, // makes (un)commenting easier. /*------------------------------------------------------------------------------------*/ //System Presentation PSYS_SRC_PATTERN, //chose one of the following //PSYS_SRC_PATTERN_EXPLODE, PSYS_SRC_PATTERN_ANGLE_CONE, //PSYS_SRC_PATTERN_ANGLE , //PSYS_SRC_PATTERN_DROP , //PSYS_SRC_PATTERN_ANGLE_CONE_EMPTY, // questionable implementation. PSYS_SRC_BURST_RADIUS, 0.05, // float value PSYS_SRC_ANGLE_BEGIN, 0.0,// range 0 to PI PSYS_SRC_ANGLE_END, 0.0, // range 0 to PI. //PSYS_SRC_TARGET_KEY, //llGetKey(), // Key of the Target object. /*------------------------------------------------------------------------------------*/ //Particle Appearance PSYS_PART_START_COLOR, <1.0, 0.25, 0.5>, PSYS_PART_END_COLOR, <1.0, 1.0, 1.0>, PSYS_PART_START_ALPHA, 1.0, // 1.0 - 0.0 ; opaque to transparent. PSYS_PART_END_ALPHA, 1.0, PSYS_PART_START_SCALE, <0.75, 0.75, 0.0>, // z is ignored. PSYS_PART_END_SCALE, <0.75, 0.75, 0.0>, // z is ignored. PSYS_SRC_TEXTURE, TEXTURE_BLANK, // texture must be a UUID or in the emitter prim's inventory. PSYS_PART_START_GLOW, 0.02, // range 0.0 to 1.0 PSYS_PART_END_GLOW, 0.00, /*------------------------------------------------------------------------------------*/ //Particle Flow PSYS_SRC_MAX_AGE, 0.0, // how long to have the emitter on. PSYS_PART_MAX_AGE, 8.0, // range 0.0 to 30.0 PSYS_SRC_BURST_RATE, 0.017, // 0.0 to inf. Ammount of time between particle bursts. PSYS_SRC_BURST_PART_COUNT, 1, // number of particles per burst (an integer) /*------------------------------------------------------------------------------------*/ //Particle Motion PSYS_SRC_ACCEL, <0.0, 0.0, 0.00>, PSYS_SRC_OMEGA, <0, 1, 0>, // rotation of emiter around X,Y,Z REGIONAL axes. approximately radians per burst. PSYS_SRC_BURST_SPEED_MIN, 0.0, // initial speed of particle. PSYS_SRC_BURST_SPEED_MAX,0.0// no final comma. ]); //llParticleSystem([]); //llTargetOmega(<0,0,1>,0,1.00); } } Wiki: https://wiki.secondlife.com/wiki/LlParticleSystem#llLinkParticleSystem Checklist: Don't set PSYS_SRC_MAX_AGE to anything other than zero unless you really know what you're doing, set a timer or sleep instead then stop the particle system with llParticleSystem([]); If you do, make sure the burst rate is strictly lower than the max age. Particles are always based around the +-Z axes of the object. If that's not what you want, add a linked prim with the correct orientation. Read the other wiki caveats.

Interesting, I have some sidewalks and a tractor beam that move an avatar with llPushObject(), but the tractor beam in particular (I.E up/down movement) is a bit too sensitive to lag* and needs fiddly adjustment for any specific height. *last time I tested it was before the script efficiency update.

That's a perfect use-case for an integer bitmask integer is_taken; state_entry() { is_taken = (1<<1)|(1<<9); // links 1 and 9 do not give out candies. } touch_start(integer n) { integer link = llDetectedLinkNumber(0); if( !(is_taken&(1<<link)) ) { is_taken = is_taken|(1<<link); // take the candy from link //... } }

I could actually make that a bit nicer looking. . . vector uWallLimitRay(vector start, vector end, vector dimension, float limit) { // return the point the ray would hit on the wall. vector diff = (end-start); float f = (limit-(start*dimension))/(diff*dimension); return start+(f*diff); } vector uSimLimitRay(vector start, vector end) { // return end, or end truncated within the region if out of bounds. if(end.z<0) { return uWallLimitRay(start,end,<0,0,1>,0); }if(end.y<0) { return uWallLimitRay(start,end,<0,1,0>,0); }if(end.x<0) { return uWallLimitRay(start,end,<1,0,0>,0); }/*if(end.z>4096) { return uWallLimitRay(start,end,<0,0,1>,4096); }*/if(end.y>256) { return uWallLimitRay(start,end,<0,1,0>,256); }if(end.x>256) { return uWallLimitRay(start,end,<1,0,0>,256); } return end; } /// the actual raycast vector start = llGetPos(); vector end = uSimLimitRay(start,start+<60,0,0>*llGetRot()); // do raycast. still early morning, no guarantees against math or programming errors.

Some early morning "don't wanna sleep" general sketch: vector diff = (end-start); float magDiff = llVecMag(diff); // calculate where the ray would hit the floor: if(end.z < start.z) { float f = (0-start.z)/(diff.z); // the 0 is overkill, but makes the similarity to below clearer. vector floor_hit = start+(f*diff); if(llVecDist(start,floor_hit)<magDiff) { end=floor_hit; jump raycast; } } // repeat above with x and y. // . .. // calc where would hit east wall: if(end.x > start.x) { float f = (256.0-start.x)/(diff.x); vector east_hit = start+(f*diff); if(llVecDist(start,east_hit)<magDiff) { end=east_hit; jump raycast; } } // similarly for y. // ... @raycast; // do the actual raycast form start to end. Edit: You can make the distance comparisons more efficient by using quadrances instead (distance squared = (a-b)*(a-b)) but adding that optimization might obfuscate the intent a bit too much for the forum post.

It's pretty easy to tile cubes in SL if you know the right editor tricks, but 0.5 li per cube adds up fast.

Remaining quantity says nothing about your place on the list, and "remaining quantity" isn't 'how much L$ is there that I can have" it's how much L$ Isn't being transferred because there's no second party to the transaction. if it's going up, then fewer people are selling than want to buy. "limit sell" seems to be set at 250, so there should be a decent number of stupid hurried people selling at that price. anything above that, someone would need to make a specific effort to sell at a bad price.

I can confirm, the OP is in fact on the ban list for the beach.

Doesn't sound very unique to me; false advertising!

OOp, yeah, need to get my eyes checked I suppose.

You're not going to find something exactly like a RL photo, but some of the Trompe Loeil houses are kinda similar. For example https://marketplace.secondlife.com/p/Trompe-Loeil-Caylin-Modern-Ranch-A-V14-mesh/21318823

Firestorm only it seems. anim.ini should work in all viewers, including the official one, even if the way it functions is a bit of a hack.

So, I was nosing my way in the viewer source code for BVH interpretation and found something rather useful. If you go to your viewer's installation directory and modify the file app_settings/anim.ini to look like so: Translations 1.0 [GLOBALS] priority = 6 then when you go to upload a bvh animation the priority box will show 6, and you can upload a priority 6 animation. (Similarly for priority 5 animations, set priority to 5 in anim.ini) If you touch the priority box the priority will flip back to 4, so don't do that. I tested it on the beta grid, and it does indeed seem to result in higher than normal priority animations. anim.ini should also allow adding constraints to a bvh animation, some basic tests with that just broke the upload window though. Footnote: editing xui/<language>/floater_animation_bvh_preview.xml to allow higher priority uploads will result in an animation that ~looks like it has a high priority when inspected, but which functions as a priority 4 animation.

There's nothing stopping you from using a simple script to boot people from your special magic place if their last name isn't (for example) Resident.