Quistess Alpha

FWIW you would only need one script for all your buttons, using llDetectedLinkNumber() and llDetectedTouchFace() to determine which button was pressed.

You could certainly use a naming format. You'll need some way of storing data on which texture is of which type, and an implementation of some naming convention. to parse the texture names, you might use either llParseString2List() or llGetSubString() to separate the name of the texture into meaningful chunks. for storing the data on what texture is which type, you'll want to use either several lists for each type, or a big strided list. there are pros and cons for each, but I'd say if you want each kind of texture to go together as a set (EYE_1 FACE_1 BODY_1 all grouped together as set one for example) I think it might be easier to manage a strided list, but if all of your things are separate (you have more eye options than face options for example) then separate lists would e the way to go. You'll probably want to organize the texture names in both state_entry() and changed() events, so a global function to do the organizing would probably be prudent. Using separate lists, a parsing function might look something like this: list gFaceList; list gEyeList; uParseTextureNames() { list gFaceList=[]; list gEyeList=[]; // good safety to clear the lists first to avoid filling them with duplicates. integer index = llGetInventoryNumber(INVENTORY_TEXTURE); while(--index>0) { string name = llGetInventoryName(INVENTORY_TEXTURE,index); string subname = llGetSubString(name,0,2); // first 3 letters of name if(subname=="FAC") gFaceList+=name; if(subname=="EYE") gEyeList+=name; else llSay(0,"Bad texture Name: "+name); } }

Are you actually suggesting setting up a self-hosted server, or am I reading more into that than you said? The 'most reliable' method would be to use a paid service like Azure or AWS to host and manage things for you. keeping everything on your own harddrives and such is entirely possible, and the traffic you'd get form some in-world stuff /probably/ wouldn't be too awful to manage on a good home internet connection, but that sort of thing really isn't for the feint of heart.

It's slightly more complicated, but if you request camera permissions from the seated avatar (which IIRC are automatically granted without annoying the sitter.) you can use LlSetCameraParams() to change the camera position.

Well, if RLV was involved it would probably be easy to have an llOwnerSay(@sittp:5=n); in there somewhere.

I've just been testing this. In the "Normal scenario" where the listening object and the object sending the dialog are one and the same, the response will go through as long as the object is rendered in the dialogee's viewer. the toucher can be 3 or four sims away, and the response will still be heard, because the response comes from the object sending the dialog. Try this, make a simple object with a script like so: default { state_entry() { llSetTimerEvent(10.0); } timer() { llDialog(llGetOwner(),"This is a Test",["OK"],0); } } and rez it. whenever you press "OK" anyone within 20m of the object will hear you say "OK". even if you're a few sims away.

According to the wiki, the maximum distance llSensor detects things at is the 4th parameter you give it, up to a limit of 96.0 : http://wiki.secondlife.com/wiki/LlSensor llDialog() however has a more or less 'infinite' range when used in the usual way (don't quote me on that, I've not tested it across region borders and corners yet), and llRegionSayTo() is limited to the current region. FWIW you can replace llRegionSayTo(llGetOwner(),0,"Dialog menu timeout."); with llOwnerSay("Dialog menu timeout."); to improve its range.

Something tells me that the little blue box that says "this post is xyz days old, prease consider if replying to this post is important..." or something like that isn't big and scary enough to catch the attention of newbies. Maybe it should be red and in all caps bolded, with a much larger font to boot

Ooh, clever! for the case of both being on but different intensities you could scale and offset the on/off, so OP's case isn't actually that different, except for the fact that the hues are a bit different which would get a bit overly-complicated (but not actually impossible) to differentiate by scaling and offsetting the 'bulb_lit' variable.

Grasping at straws as to what you're trying to do, but for a sane example of using a touch_start() touch_end() and timer() event to do something only if the object is touched for 2 seconds (or longer): default { touch_start(integer i) { llSetTimerEvent(2.0); } touch_end(integer i) { llSetTimerEvent(0); } timer() { llSetTimerEvent(0); llSay(0,"I have been touched for 2 seconds."); } }

It's not really clear why you would need a timer even for a simple on/off lightbulb. For comparison, here's my light bulb script, which I think might have been the first pr second script I ever wrote in LSL: integer bulb_lit=FALSE; default { touch_start(integer total_number) { if(bulb_lit==FALSE) { llSetPrimitiveParams([PRIM_POINT_LIGHT, TRUE, <1,1,1>, 1, 10, 2]); llSetPrimitiveParams([PRIM_GLOW, 0, 0.15]); bulb_lit=TRUE; } else { llSetPrimitiveParams([PRIM_POINT_LIGHT, FALSE, <1,1,1>, 1, 10, 2]); llSetPrimitiveParams([PRIM_GLOW, 0, 0.0]); bulb_lit=FALSE; } } } (Yes I know it might have been cleaner to use the bulb_lit=!bulb_lit; flipping trick) this section: touch_end(integer num_detected) { llResetScript(); } seems quite out of place. Resetting the script is something you generally don't want to do very often, and this will reset the script every time you stop touching the object.

Not sure what system Animats was referring to, but the closest thing I found there was the Infinity Swim System by Matt's Beach : https://marketplace.secondlife.com/p/Infinity-Swim-Swim-and-dive-OFF-SIM/10731221 which is specifically for swimming in off-the-sim locations, and doesn't automatically attach any diving gear.

100% agreed.

Well, for /that/ sort of employment, there are several 'slave auctions' you can find through inworld-search. The way those generally work is you put your name your picture and some basic details on a board, and spend about a week enticing people to bid on you. Then, the next week you get about half of the highest bid, and roleplay with the highest bidder as per the terms you set out on the board. There's also a different type of slave auction where you get 'captured' do a quick auction scene with whoever happens to be around (the capturer usually getting the bid) then do a single scene with the bidder. You probably wan to make sure you're getting into the first kind, not the second. Auctions are generally framed as a way to meet up with people you'd like to get together with rather than a way to make money, but if you really worked it you could probably make 1k per week or more.

Firstly, Google doesn't index the marketplace very well, you should really try using the search built into the MP. Secondly, you can't possibly have a system that makes someone wear a wetsuit and works for every possible body type, unless it's BOM; and if it's BOM, you'd need to wear it from inventory. Assuming Mesh, and no inventory complications on the side of the user, I don't think it would be too hard to script something that rezzed out some fitmesh bodysuits and swimgear, temporarily attached them to the avatar, then changed their animation override settings. If you want the snorkeler to not swim in the air, you might need to give them a scripted AO that also includes flying animations. you can get full-perm snorkling equipment from Meli Imako, do check their license agreements to make sure that they're compatible with your intentions. https://marketplace.secondlife.com/p/Full-Perm-Fitmesh-Womens-Wetsuit-Slink-Ocacin-Voluptuous-Maitreya-Ocacin-Standard-Belleza/15185615 https://marketplace.secondlife.com/p/FULL-PERM-CLASSIC-RIGGED-MESH-Mens-Male-Black-and-Blue-Short-Sleeve-Diving-Suit-Wetsuit/4799091 https://marketplace.secondlife.com/p/Full-Perm-MI-Dive-Mask-and-Snorkel/9686972 https://marketplace.secondlife.com/p/Full-Perm-MI-Palets-Style-3/9589717

Yeah, it's probably detecting itself. you could get around that by making 'start' a bit lower than your actual position: vector start = llGetPos()-<0.0, 0.0, HullRadius+Fudge>; where HullRadius+fudge is a float slightly larger than the distance between your vehicle's center and its underside. Edit: a bit of a nitpick, but you probably want to do a lot more than just setting 2 vehicle params to change the state. I would reccomend making some global functions to hold all the stuff you do to change the vehicle type

You're so welcome <3. I love it when an amazingly simple solution works well!

Well, it /can/ be all done in-world, but there are advantages and disadvantages to different methods.

well then the problem becomes a sort of "how do I determine if a thing is a runway or a bird" problem. you couldtry to do a llSensorRepeat() and test for unscripted things below you that are of a certain size perhaps.

Also, for the record, you can be a bit clever about an 'all of these bits are set' test: integer bitfield = 1<<0|1<<2|1<<3|1<<4; // 1<<n is 2 raised to the nth power, or equivalently, an index for the nth bit. integer test = 1<<2|1<<3; // we want to know if all of these bits are set. if( (bitfield&test) == test) //returns true iff all bits in test are on in the bitfield

It really depends on the use-case. Looping through all the items in the prims inventory and checking them against multiple strings might be unnecessarily wasteful if you've already somehow confirmed the existence of those two things earlier in the code.

Did a bit of digging, For the reccord, you can (should) use "LlClearPrimMedia(gMediaFace);" instead of llSetPrimMediaParams(gMediaFace, [PRIM_MEDIA_CURRENT_URL,""]); to clear the webpage:

Madelaine beat me to the punch. it's mostly built-in functions and events that use that sort of thing (control() for example) with language-defined constants. because LSL doesn't support user-defined constants, you're probably better off just using 32 separate integers and setting them to 1 or 0, unless the meaning of the bits is self-evident from the position (for example up to 32 sittargets and a bitfield representing "is an avatar on this sittarget")

Ahh, if you want to 'automatically' transition from land to air or visa versa, you need to try and devise some sort of test that determines when you should go from one to the other, for example, perhaps when you're flying if you're less than 50 linden-units off the ground, transition to either the land or water state. timer() { integer groundLevel = llGround(ZERO_VECTOR); integer waterLevel = llWater(ZERO_VECTOR); vector myPosition = llGetPos(); if(waterLevel > groundLevel) { if(myPosition.z - waterLevel < 50 ) state boat; }else // ground level is higher. { if(myPosition.z - groundLevel < 50 ) state vehicle; // or whatever function to land the } } you would also want to be sure not to start the test until you got a bit above 50 units off the ground/water (say 75 units), so you don't immediately fall right after taking off. for going from driving/boating to flying, you might devise some sort of speed-based test.

That's in the right ballpark, but there are a few things you could do to clean it up. changing the spacing to make it more readable for one, which would make it easier to catch some mis-matched barces. also I'm not sure why you need slightly different options for the owner and regular users. for a multiple-game switcher, you could try something like this: list gSites=[ "https://emulatorgames.online/games/n64/bomberman-64", "https://archive.org/details/Stargunner", "https://tss.asenheim.org/eve-burst-error.html" // no final comma. ]; list gSiteNames = [ "Bomberman", "StarGunner", "Eve: Burst Error" // no final comma. ]; integer gSitePointer; integer gButtonRightFace=2; integer gButtonLeftFace=4; integer gButtonOff=1; integer gMediaFace=0; default { state_entry() { integer success =llSetPrimMediaParams(gMediaFace, [ PRIM_MEDIA_CURRENT_URL, llList2String(gSites,0), PRIM_MEDIA_AUTO_PLAY, // " Sets whether the media auto-plays when a Resident can view it. " TRUE, PRIM_MEDIA_PERMS_CONTROL, // who can change the url with the control bar. PRIM_MEDIA_PERM_NONE, // chose from 'NONE,OWNER,GROUP,ANYONE' PRIM_MEDIA_AUTO_ZOOM, //makes the user's camera zoom onto the prim when they interact with it (if TRUE). TRUE, PRIM_MEDIA_PERMS_INTERACT, // who can change the webpage the site is on through navigation PRIM_MEDIA_PERM_NONE // no final comma. ]); } touch_start(integer total_number) { //llSay(0,(string)llDetectedTouchFace(0)); if(llDetectedTouchFace(0)==gButtonRightFace) { ++gSitePointer; }else if(llDetectedTouchFace(0)==gButtonLeftFace) { --gSitePointer; }else if(llDetectedTouchFace(0)==gButtonOff) { llRegionSayTo(llDetectedKey(0),0,"Power off."); llSetPrimMediaParams(gMediaFace, [PRIM_MEDIA_CURRENT_URL,""]); return; } else return; if(gSitePointer>=llGetListLength(gSites)) gSitePointer=0; string Site=llList2String(gSites,gSitePointer); string Name=llList2String(gSiteNames,gSitePointer); llRegionSayTo(llDetectedKey(0),0,Name); llSetPrimMediaParams(gMediaFace, [PRIM_MEDIA_CURRENT_URL,Site]); } } in a cube prim with 0.01 size in the z dimension, and 0.30 taper for x and y.