Quistess Alpha

Nautilus and Bay city both get double prim allotment per M2. and generally such land goes for around 175L$/m2. But here, the answer is water access. https://places.secondlife.com/auctions/history/26285557 The cardona plot is completely submerged and has a lot of nice boat-able area around. https://places.secondlife.com/auctions/history/26285553 Miramire is technically in bay city and gets 2x prims.

llGetLinkPrimitiveParams PRIM_POS_LOCAL vector posA = llList2Vector(llGetLinkPrimitiveParams(linkA,[PRIM_POS_LOCAL]),0); vector posB = llList2Vector(llGetLinkPrimitiveParams(linkB,[PRIM_POS_LOCAL]),0); vector difference = posA-posB; The difference between 2 things isn't exactly rocket science? ETA: while I'm posting wiki links: https://en.wikipedia.org/wiki/Cross_product More usefully, crossing 2 of these axes in counter-clockwise order gives you the third: Thumb%pointer=middle; pointer%middle=thumb; middle%thumb=pointer

This (section of the) forum is more for discussing general ideas and methodologies for how to do things, not for asking people to write a complete script for you. I feel a bit crass saying this, but you really ought to learn to script it yourself, or pay someone else to do it for you (for which you might try the 'wanted' or 'in-world employment' sub-sections of the forum).

You can make each linked prim's x-axis face any which way you like, you just need to set X to a normalized vector indicating the direction (in local coordinates). Conveniently for the above example, the local position of a linked prim is a vector pointing from the root to the prim. A vector pointing from one linked prim to another would be the difference in their positions.

Yeah, they ~can be used to communicate with external things, but they're quite useful on their own. Not to distract form your main discussion, but some use cases: In-world server: If you have land you can permanently place a prim on, you can emulate external-database solutions using only in-world tools, although obviously not 100% as robust. Email is used to send low-volume or moderately important info to the server-prim, and to update the client object with its current HTTP address. HTTP is then used for fast and higher volume data transmission. The server can be on an experience enabled parcel, and always have access to KVP for long-term data storage. data-out: This is a bit subtle, but sending data over http is actually quite useful for giving users binary data *hint hint*. if you can nudge someone to open your prim's obtained URL in an external web-browser, they can save whatever page you send them to their harddrive. Getting the data back into SL isn't 100% user friendly. if you don't trust people to know how to copy and paste. . . create a new script -> edit it -> file -> load from file (choose file saved to) -> ctrl-a ctrl-c open a new notecard, edit it, ctrl-v. I could have sworn it was also possible to load a notecard from disk

HTTP and lsl Email are SL internal services. see llEmail and llRequestURL.

KVP would be decent for this, but the 2 parties would both need to be on land with the experience enabled. Also, for grid wide, you could send the data over an http connection (or Email, but in this scenario that gets all the downsides and none of the benefits between the two) rather than a chat channel: person A clicks their thing's button and it requests a URL, and says it to person A. person B puts that URL into their thing somehow. person B's thing http requests the URL. person A's thing HTTP responses the data. Also FWIW attachments are not "safe" for storing data if the user is jumping between sims a lot. I worked on a system ~9 months ago that stored data in a HUD, and there have been complaints that crashing on region crossings caused people to lose some or all of the data stored in the HUD. You'll probably want some way to store backup in some object or system that is not attached.

It works fine for most people, it didn't work fine for you. This happens in large automated systems, sometimes something goes wrong and an actual person needs to fix it. FWIW I didn't need to file a ticket to be able to sell L$.

default { state_entry() { integer link = llGetNumberOfPrims(); do{ vector X = -llVecNorm(llList2Vector(llGetLinkPrimitiveParams(link,[PRIM_POS_LOCAL]),0)); vector Y = llVecNorm(<0,0,1>%X); vector Z = llVecNorm(X%Y); llSetLinkPrimitiveParamsFast(link,[PRIM_ROT_LOCAL,llAxes2Rot(X,Y,Z)]); }while(--link>1); } } note to self: vecNorms are actually required for accurate results.

If you read between the lines, LL obviously wasn't trying to make something better for ~All of us, otherwise they would have just given an extra 1024 to premium members (and maybe increased the fee under the rug) It's a specific new product and if you're looking at it as a way to get the same benefits you might already have with lower cost, you're looking at it wrong. Case and point, Decreasing the fee won't do much for people who already have business, but perhaps there are new innovative things people can do if they upload a bazillion textures or sounds without thinking about cost. It's no longer a significant risk if I want to upload a single word sound for the most common 2000 words in English or something crazy like that. TL;DR don't think "can I buy this and decrease my overall costs?" but instead "does this get me anything premium absolutely doesn't have?" and it makes more sense. I'm still leaning closer to a no sale on the second type of evaluation, but at least it makes more sense in that framework.

"apex" is just a fancy term for top/'very good' probably meant in a snarky way. ETA. 9.50/3.05 = 311%; or if you're a sales person, a 211% increase.

Given the next sentence, I'd suppose they meant the ~avatars need to present as 21+

I disagree, the way I heard patch say it implied upgrading ~would get you the bonus.

Yes all of that is possible, no, I don't feel like doing it. I didn't sleep well last night, and am grouchy.

https://files.catbox.moe/rsyu2e.mkv

integer gAccumulator; integer gGravityPoint = 14; default { state_entry() { llSetPhysicsMaterial(8,0,0,0,0); // 0 gravity. llSetStatus(STATUS_PHYSICS, FALSE); // llLookAt is Z-forward, axis crossing example is X-forward. //llSetRot(llEuler2Rot(<12,0,0>*DEG_TO_RAD)); // specific initial orientation for testing. llSetRot(llEuler2Rot(<292.5,0,270>*DEG_TO_RAD)); // specific initial orientation for testing. llSetStatus(STATUS_PHYSICS, TRUE); //llSetVelocity(<0,0,1>,TRUE); llSetVelocity(<1,0,0>,TRUE); llSetTimerEvent(0.2); } timer() { if(++gAccumulator==gGravityPoint) { llSetPhysicsMaterial(8,0.1,0,0,0); llSay(0,"Gravity on."); } //llLookAt(llGetPos()+llGetVel(),0.2,0.2); rotation rot = llGetRot(); vector X = llVecNorm(llGetVel()); //vector Z = <0,0,1>*rot; // different order seems to givve a slightly nicer result: //vector Y = Z%X; //Z = X%Y; vector Y = <0,1,0>*rot; vector Z = X%Y; Y = Z%X; llRotLookAt(llAxes2Rot(X,Y,Z), 0.2, 0.2); } } The bouncing box after it lands is actually kinda fun. . .

Ugh, fiiine, I'll go debug it.

That or just using KFM instead of trying to game the physics system. As for smoothness, llRotLookAt() is smooth and physics based, so it can look decent on the slower side of fast timers (0.5 seconds or so?). You also have to remember that just because you don't ~See the code behind the vehicle functions, doesn't mean it doesn't exist. somewhere the server has to set the rotation of the object, whether that's explicitly by your code, or implicitly behind a vehicle function system.

Gravity is modifiable per object. in this case, setting it to zero for the projectile is probably what would make the most sense. llSetPhysicsMaterial(8,gravity,0,0,0); is preferable to llSetBuoyancy in pretty much any circumstance I can think of. llLookAt(llGetPos()+llGetVel(),0.5,0.5); or rotation rot = llGetRot(); vector X = llGetVel(); vector Z = <0,0,1>*rot; vector Y = Z%X; Z = X%Y; llRotLookAt(llAxesToRot(X,Y,Z),0.5,0.5); in a timer (untested).

LL takes a 10% cut off of sales on the MP, which most people (probbably?) pay in L$ (you can actually pay in USD if you want to, but you're ~much better off buying L$ and paying with that.) I'd imagine that's a much bigger L$ sink than all the annoyance fees put together.

Owning one (1) premium plus account should(according to the talk patch gave) cost 249$ / year, you don't pay regular premium on top, and in fact he briefly mentioned you can apply what you've already paid on your premium if you want to upgrade, but "it's complicated".

Interesting LL doesn't charge VAT for annual premium subs, but they ~Do charge US sales tax now after the first year.

Patch just released the details; here's my rough summary: Price: 29.99/month, 249USD annual. Stipend: 650 linden /week. (signup bonus of 3000L$) "Free" tier increased to 2048. 140 group slots. an extra animesh attachment An extra land-scope experience. Non-mesh upload fees eliminated, other minor nuissance fees eliminated or reduced. Access to a special support phone line. Available June 23rd. I wasn't taking detailed notes so I may have missed some things. ETA: Ability to request a specific linden home with a support ticket. (many caveats apply) Premium plus sandboxes (eventually) random gifts

I know it's a rhetorical question, but destination guide is here: https://secondlife.com/destinations and in the standard LL viewer there's even a special floater for it, and a curated list of places pops up in the screen nobody looks too closely at as you log in. The only time I've really used it is if I have to find where the maitreya mainstore is (maitreya is so popular it's impossible to find them in search) or if I'm looking for something really geneneral (ex. animations) and I want to make sure I've covered my bases.

The single arm BOM slots only work if the body is textured in a way that supports them. it's possible that legacy may not be.