Quistess Alpha

when you have a list of true/false values with less than 32 entries, you can do some boolean arithmetic to store it in a single integer. integer engine_active = 0; // no engines are active.\ // ... test if engine #n is active: if(engine_active&(1<<n)) { // if #n was active make it inactive; if it was inactive, make it active: engine_active=engine_active ^ (1<<n); // make engine #n active enginve_active = engine_active | (1<<n); // make engine #n inactive engine_active = engine_active & (~(1<<n)); // redundant parentheses. } Yeah, you can manage 'sets of parts' in a more generic way now: get_links() { llLinksetDataReset(); // somewhat bad form, but works for a simple example. integer prim = llGetNumberOfPrims(); // for each link, write its link # to the linksetData key 'Link:<linkName>' do{ string name = llGetLinkName(prim); string key = "Link:"+name; // conversion to a list technically unneccessary. list prev = llCSV2List(llLinksetDataRead(key); prev += prim; llLinksetDataWrite(key,llList2CSV(prev)); }while(--prim); llLinksetDataWrite("LinksReady","True"); } // after the function has run, llCSV2List("Link:"+linkName) shjould return a list of all links with the given name. state_entry() { if(llLinksetDataRead("LinksReady")!="True") get_links(); } changed(integer c) { if(c&CHANGED_LINK) { get_links(); } }

That should be possible with a bit of custom scripting and the new on_death() event Yes, that should be possible with the current proposal. specific hit detection isn't really accurate due to animations being client-side, but using llDetectedPos() in the on_damage event should let scripts in attachments have a rough idea whether the damage might be to head/chest/legs. My guess is probably not. AFAIK, it's not really possible to 100% identify if a given attachment even is a specific weapon; 'cheaters' could make a different weapon with the same name and creator as one in the whitelist.

If you're just given a free thing, you're less likely to go and tell your friends (who possibly aren't group members) to get the thing. then after people have "worked" to get the thing, they're more likely to brag to everyone about the awesome thing they got for low low price of "effort" and probable endorsement.

The ability to have different limits for different damage types or different limits for attachments (and things rezzed by them) and non-attachments (and things rezzed by them) might be useful, but Idunno how easy to implement or if that would be too fiddly for land owners.

To add to the difficulty, an avatar's exact facing direction isn't precisely accurate for all observers unless they're sat on something. In the worst case, one hand-holder might see the hands correctly holding, and the other might see the hands a foot apart. This kind of situation can quickly lead to neither avatar wishing to hold hands anymore as they get more and more confused

Assuming maitreya, wear any clothing layer and increase the shininess via your body's HUD. Alternatively, you can increase the shinyness of your skin directly. look for an advanced/materials button on the skin and/or layers page of the hud and play around with them.

Disclaimer: I don't really do weapon scripting, but I think it is. you can still emulate an additive offset with something like llAdjustDamageRelative((oldDamage+offset)/oldDamage); just that might not play nicely in a race condition. Some more off-the -top-of-my-head ideas/thoughts: maybe there could be a function that returns the number and keys (and possibly other info) of other attachments which have running scripts with a on_damage event? or possibly on_damage could work more like listen: only feed scripts damage events with damage type numbers they are interested in. How hard would it be to make damage types strings rather than integers? Integers leave a lot of room for different creators to accidentally or not-so-accidentally overlap (Creator A uses type 27 as "magic damage", creator B uses it as "slash damage") OTOH, integers do make it easier for a single creator to block out different "categories" (ex. 100-149 are 'medieval era physical' types of damage (slash, pierce, burn. . ), 150-199 are 'modern physical' (bullet, chemical, gas), 200-299 are magical (elemental, arcane, divine, ...) ) ETA: Oh NVM, that's basically what @Amalia Irata was asking about.

I think we want more than one thing to be ~able to adjust the damage (say I'm wearing both armor and shield, both should be able to decrease damage) but there needs to be a promise for only one to actually adjust the damage, OR, actually, if the specification were adjusted so that llAdjustDamageAmount applies a multiplier to the received damage, (ex. llAdjustDamage(0.8) causing the damage from the event in which it's called to be reduced by 20%) rather than directly setting it to a new value, there might be less of an issue.

with the current implementation this could probably be implemented specifically in a script, but it might be nice to add support for a temporary 'damage ban' (a few minutes to a few days no access to the parcel in which the avatar died, same timeperiod for everyone set somewhere in land settings) after death: for some games, you might want "death" to have a longer or shorter "consequence".

if you can inline an image as part of the xhtml, (svg file format works very well with this) that can work, but LSL's limited mimetypes are indeed a pain. ETA: very small raster images can be converted to inline (x)html with tools such as https://ezgif.com/image-to-datauri or use the trick described here: https://devtoolstips.org/tips/en/convert-image-to-data-url/

Using content ripped from games (or anything else you don't have legal permission to use) is against SL's terms of service. Anyone with the ability to upload mesh in SL should know this, because you need to specifically agree to the 'mesh IP agreement' to do so.

FYI, ".*" is implied at the beginning and end of a regex unless "^" (beginning of key) or "$" (end of key) is specified. So, "^v:" should be equivalent. *This was not the case in early implementations of LSD functions, but has been fixed for some time.

list glEmotes = [ "pats %o's head.", "does a barrel roll with %o.", "hugs %o tightly." // no final ',' ]; default { touch_start(integer n) { key kOwner = llGetOwner(); string sOwner = "[secondlife:///app/agent/"+(string)kOwner+"/inspect]"; key kToucher = llDetectedKey(0); string myName = llGetObjectName(); integer nEmotes = llGetListLength(glEmotes); string sEmote = llList2String(glEmotes,(integer)llFrand(nEmotes)); // Wiki is unclear, does llRSS use literal pattern matching, or regex? sEmote = llReplaceSubString(sEmote,"%o",sOwner,0); llSetObjectName(""); llSay(0,"/me secondlife:///app/agent/"+(string)kToucher+"/inspect "+sEmote); llSetObjectName(myName); } } or so. (untested)

They need to sign the mesh IP agreement (basically just says 'I agree to not upload pirated material' ) they should log into secondlife.com then go to https://secondlife.com/my/account/ip/ Those are fees you pay if you want your items to be advertised more prominently to potential buyers.

Can even be done with just two llTargetOmegas in opposite directions, depending on the build. I've done that on a few occasions, and as Rolig says, it's most easily done with a custom script. It's very fiddly to get it to synchronize correctly; I believe last time I did it, I had the animation be non-looped, so that the script could re-synchronize with each throw. If your animator can use some magic secret sauce (may only work with certain versions of avastar?), it's possible to animate the hand's attachment point, which can let an animation 'throw' an unrigged, unscripted object.

Check that you have permission to rez things where you are. If your land is deeded to a group, your object might need to be set to the same group (in most viewers this is done automatically if you are in the land group) if the name of the object you want to rez is not "prim cafe" you'll have to replace that in the script, or change it to something like llGetInventoryName(INVENTORY_OBJECT,0)

If everything were the same alpha level, you could of course use LINK_SET to change all the links at once. or if (for example) one or two links are always visible, but the majority is the same alpha level, you could LINK_SET to change everything to the most common value, then change the visible parts back to their previous value.

The most performant isn't necessarily the most sane. If you have global variables for each link, then just: gLinkAlpha-=gLinkAlphaDelta; gLinkAlpha*=(gLinkAlpha>0.0); llSetLinkAlpha(gLinkNumber,gLinkAlpha); //gLinkAlpha2-=gLinkAlphaDelta2 ... or so manually typed in for each link rather than iterating through a list would probably be close to optimally fast, but would take up a bit more memory than a loop. Personally, I'd usually keep the link number and alphas in a strided list (or 2 associated lists), depending on the other things the script has to do with the link #s and whether it makes sense to think of them all in one block.

"good pay" is pretty relative to your expectations. If you have/can learn a "content creation" skill, like 3d modeling/texturing/scripting, it's not impossible to make something on the order of a RL wage, if you have enough talent and can market yourself well. If you have a good amount of disposable RL money, you could try making money with SL real-estate, but unless you work for someone else there's no guarantee of return, you could just as easily lose money as make it. Sex work can pay decently, depending on various things. host/DJ club stuff usually doesn't pay much more than tips, but it might be enough if you just need some change to spend on 50 linden fridays.

Thanks for following up with the solution. Anecdotally, most of the "erroneous things you shouldn't do with jumps" cause unhelpful errors, making them hard to spot.

via a a quick test with the given URL, it seems de-facto only zoom level 1 is supported.

This, the US made a dumb rule lowering the 'you need to do more paperwork' threshold from 2000 USD to 600. The IRS didn't enforce it last year, and they announced today they're not going to enforce it this year, but paypal, tillia etc. are going to need to send out a lot of nuisance tax forms, maybe next year or the year after. . .

If you're spawning something for everyone, I'd go with a temporary attachment on a HUD point. HUD sounds are louder and only heard by the person wearing the HUD. Temp-attachments require an experience or permission (although, perhaps opt-out might be a good thing).

AFAIK, no. You only get one "volume" setting, which at its max of 1.0 is too quiet for many use-cases. llSetSoundRadius() is relatively new so I've not fiddled with it, but from what the wiki says, it only makes it so you ~can't hear the sound from far away, it doesn't make the sound more audible at close range. The main exceptions are media (see previous post) and parcel audio (the music stream.)

Actually not. AFAIK, in Secondlife, sounds generally come from a 'point' location: if you make the prim larger it doesn't affect sounds that come from it. What I was suggesting is make a prim somewhere, edit it, (turns out MOAP doesn't like directly using raw media files) to use a script like this one, simplified from an example I have in the script library, changing the media file and the length of the timer event as needed: