Quistess Alpha

You can add images to your SL "outfits" but I've never bothered because I'm too much of a penny pincher to upload a texture for every one. CTS wardrobe is probably the way to go, although I do wish it had a nice way to do 'sub-tags' or something similar (tags that can only be applied to something with a specific other tag, and collapse them all together on the left pane like it does for initial letters. )

It probably doesn't apply to this context, but plenty of full-perm creators exist with specific license agreements, most stating minimum resale requirements (must add some value and not sell below X linden dollars, with exceptions for hunts/ groupgifts perhaps)

trying to reach this page, just now I got for a bit. Might be a problem bigger than SL.

There are several methods that don't need an experience (sit-tp, SLURLs, map-destination) but an experience is indeed the nicest way to do it.

At the risk of sounding solicitous, you could always commission someone to write one for you. The only "hard" parts about that script would be using llDetectedTouchUV or similar to map a single prim face to several 'buttons' and assosiating each button with that day's gift.

Sound queuing does indeed have a lot of issues, I wouldn't be surprised if this is another. This may or may not be tangentially related to the fact that queueung can occasionally cause llLoopSound() to loop the wrong sound (when different sounds are being played/looped in a relatively (5 seconds?) short time).

While we're in the spitballing stage then, what about making new functions/capabilities mono-specific, but allowing scripts to be compiled lso if they don't use any future capabilities? the main/only problem I see there is making sure documentation is clear on which functions/capabilities are mono-only? Or, just a bad thought, add a third checkbox for mono+[not-yet-created-functionality].

llSay and llShout (and llWhisper) will indeed cross region boundaries.

practically speaking it wouldn't, but I've heard anecdotally that lso scripts can perform better at region crossings. If anyone knows some vehicle makers, maybe poke them about this?

take a look at llGetObjectDetails(); in particular: llList2Vector(llGetObjectDetails(KeyOfInterestingObject,[OBJECT_POS]),0);

I kinda skimmed your scenario, but if the 'universe of guessable numbers' is small enough (less than 500?) I'd probably go with a list of bitmask integers in script memory.

I'm also in #2 camp; I think it's easy enough to script around either case (ss long as it's well-documented) , so give preference to the one which is (trivially) less likely to overflow event buffers.

Azn Min at Builder's Brewery often does classes where she walks through some relatively simple scripts and how they work. In my opinion though, the best way to learn is just to have a lot of ideas for simple projects and try to make them work. The "simplest" things to script can usually be summarized in the form "When X happens, do Y". Like a basic lightbulb (When I touch the object, turn on/off the light) or maybe a simple one-direction elevator (when an avatar stands on the elevator, move to position B, if nobody is on the elevator move back to position A) As you work through and try and translate the simple idea into a working usable project, you'll often find that your original idea wasn't as clearly specified as you thought ( the elevator description earlier has numerous holes), in which case you need to go back and about what should happen in various scenarios (should the elevator move if a physical ball gets dropped on it?) and how to convert that part of the spec into a script (pro tip: one of the most accepted ways of detecting if a given key belongs to an avatar(agent) is with llGetAgentSize(), also for anything physics-based, you'll want to have a good understanding of llSetStatus and llSetPhysicsMaterial ) You also need ot find a comfy middle-ground between giving up on a project too early because scripting is hard and often frustrating, and spending too long on a project that may not even be possible or feasible within SL's limitations. Interacting with other scripters here or in-world is really the only way to know which end of that spectrum you're on other than experience.

There are a few different ways, but my preffered one is to have an attachment worn by the avatar use llSetForce() (or llSetVelocity() which I like less ) to push with/against the avatar's intended movement. Bonus usability points if you add a small positive amount to the z component of the force so they can go up stairs, but that can lead to sky-walking in laggy regions and overly high jumps if not handled very intelligently.

https://jira.secondlife.com/browse/BUG-232800 In case nobody else thought about it (I can't pay exact attention to 10 pages, sorry), What about making the value parameter a list?

do a llHTTPRequest on the URL (the one that isn't working) and see if you can parse where it's sending you.

The first URL leads to a redirection service, which makes it easier on the server, but SL parcel media doesn't understand how to follow redirection. (don't everyone stand in the same line, go stand in N different lines to make things N times faster) If you visit it in a browser it sends you to http://d1at8ppinvdju8.cloudfront.net/1/057/show_10576195_2018_02_06_18_31_36.mp3 That url seemed to be static for me, but there's no guarantee that blog talk radio won't change their backend at some later date. I've not tried but I assume ~that URL would work for parcel audio.

What about if the water is on a region that doesn't exist? Maybe then it's "Community No-use"?

As Rolig says, no one source is going to answer all your questions, and I (a relatively newcomer to SL) assume there's a lot more "junk" info that's been outdated since you were last here. But a crash run-through of those specifics: (From a scripting perspective) Mesh are kindof like prims but with most of the shape-changing functionality removed. you can scale and position and re-texture and that's about it. "Land Impact" replaces prim-count. Land Impact (LI) is a somewhat convoluted "worst of 3 factors" test. If a linkset has any mesh components, or uses certain 'new features" (advanced materials and physics shape specification come to mind) it uses the new LI calculation, otherwise it uses prim-count. you can read more about it here: Texturing a mesh object is mostly the same script-wise as texturing a prim, but the number of faces and where they are are determined by how it was made in an outside-SL program. A single mesh object may only have up to 8 faces. What's new to SL texturing is the introduction of "advanced materials" you can read about them here :People on very-low-end devices might not have the ability to see them turned on.

Nothing too wrong with it in this use-case, but I try to not use llRotBetween when writing an example. It usually doesn't do "the intuitive thing" (whatever that might be) when working in 3 dimensions, and if you want to work exclusively in the x-y plane, it might be "better form" to do something like: rotation rCargoUpdate = llAxisAngle2Rot(<0,0,1>, llAtan2(vLookAt.y,vLookAt.x) - llAtan2(vCargo.y,vCargo.x) );

A couple ways to go about it, here are two of them: rotation rMyGlobalRotation; // this is the orientation we want to have. (only used in option 1) default { state_entry() { rMyGlobalRotation = llAxisAngle2Rot(<0,0,1>,PI_BY_TWO); // assuming a 'standard orientation' object points east, // rotate 90 degrees counter clockwise to face north. llSetTimerEvent(0.2); } timer() { // // OPTION 1: // Constant global orientation rotation rRoot = llGetRootRotation(); llSetLinkPrimitiveParamsFast(LINK_THIS, [ PRIM_ROT_LOCAL, // PRIM_ROTATION is often borked for child prims. rMyGlobalRotation/rRoot ]); // // OPTION 2: // Turn by the global comapss angle (when tipped over: inaccurate but less wonky than option 1.) vector FWD = llRot2Fwd(llGetRootRotation()); // where is the root facing? float angle = llAtan2(FWD.y,FWD.x); // angle the root is facing in radians; // ^^ 0 radians == East, PI_BY_TWO == North, PI == WEST, -PI_BY_TWO = SOUTH rotation turn = llAxisAngle2Rot(<0,0,1>,PI_BY_TWO-angle); // ^^ want to face north (PI_BY_TWO) llSetLinkPrimitiveParamsFast(LINK_THIS, [ PRIM_ROT_LOCAL, turn ]); } } Of course, things change slightly for objects not in 'SL Standard Orientation' (z= up, x= forward East, y = left North)

A) Keep an eye on your restrictions list and make sure there are no folder attach restrictions (Ex. "@attachthis:...=n") B) In my anecdotal observations/guesses, the 'bigger' something is in terms of sim resources, the more likely SL is to bork on attaching it. Is the thing in question a large linkset/ have lots of scripts and/or object inventory? C) Is the object in question a literal copy or an inventory link? RLV(a) often dislikes inventory links in many scenarios. D) One possible fix/bandaid would be to lock the folder for a while : llOwnerSay("@detachallthis:/~MyCustomBody/1.0.0=n,attachallover:/~MyCustomBody/1.0.0=force"); llSleep(5.0); // adjust as needed. sleeping this long is somewhat bad form, but useful for testing before reimplementing with a timer. llOwnerSay("@detachallthis:/~MyCustomBody/1.0.0=y");

Last time I checked, when you link a set of prims 1234 to ABCD you often end up with something like A1234BCD. As others have mentioned, don't rely on link-numbers when you have a reasonable expectation that unlinking/relinking may happen. Do a scan for link-name/description on state_entry and CHANGED_LINK.

I'm inclined to agree, but if J.P. Morgan can push Tillia to enable payout to actual banks (I.E. anything other than Paypal+Skrill) that would be a major improvement.

hopefully a bit of sarcasm there, but among other major differences, phones have awful (non-existent) cooling capacity.