Quistess Alpha

I was just thinking that if you got a lot of requests at once, you would only be able to see the latest one by default with this method, because your viewer normally limits you to one dialog box per object. This would require some testing, but I think you could get around this by going into your debug settings (under the advanced menu) and changing ScriptDialogLimitations to 1, then modifying the script a little so each request sends you a dialog for a different channel like so: integer gChannelTextbox=100; integer gChannelThrowaway=-200; uNotifyOwner(key From,string Notice) { string text = "secondlife:///app/agent/"+(string)From+"/inspect"+ " has sent you a message:\n"+ Notice; //use one or both of the following 2 lines: llDialog(llGetOwner(),text,["OK"],--gChannelThrowaway); //llOwnerSay(Text); } default { state_entry() { llListen(gChannelTextbox,"",NULL_KEY,""); } touch_start(integer total_number) { llTextBox(llDetectedKey(0), "Send a message to "+"secondlife:///app/agent/"+(string)llGetOwner()+"/inspect .", gChannelTextbox); } listen(integer Channel,string Name,key ID,string Text) { uNotifyOwner(ID,Text); } } That might be worth looking into.

I happen to have a full-perm bike that has a flying mode, which is basically the opposite of what you want lol. glancing over it's script it has a separate state for 'ground' driving and 'air' flying (each with their own state_entry() control() and listen() events and such) if you were clever about it you could probably get away with writing a some global functions that would reset all the vehicle parameter stuff for different modes of operation, which might cut down on some code duplication.

Might want a bit of a content warning for the last few images in the set.

Also, it looks like someone else just posted asking for a fix to their script which at a glance seems to be a script for a boat: you could certainly try that and see if it does what you want for your boat.

Well the easiest thing you could possibly try is to stick a full-perm vehicle script into it, for example: then change the vehicle type to boat (find the line that says llSetVehicleType(VEHICLE_TYPE_CAR); and change 'CAR' to 'BOAT') , and mess with some of the parameters. Otherwise, find a full-perm boat and see if you can pull the script out of it and put it into your boat, or failing that, script it yourself or perhaps pay someone to do it for you.

While we're on the subject though, putting "/11 test" into a gesture's 'Chat' step will actually make you say test on channel 11.

The wiki is a bit confusing on what the distance limits are, but I did a teensy bit of testing and this seems like it might work, assuming the owner of the button is the singer: integer gChannelTextbox=100; uNotifyOwner(key From,string Notice) { string text = "secondlife:///app/agent/"+(string)From+"/inspect"+ " has sent you a message:\n"+ Notice; //use one or both of the following 2 lines: llDialog(llGetOwner(),text,["OK"],-1); //llOwnerSay(Text); } default { state_entry() { llListen(gChannelTextbox,"",NULL_KEY,""); } touch_start(integer total_number) { llTextBox(llDetectedKey(0), "Send a message to "+"secondlife:///app/agent/"+(string)llGetOwner()+"/inspect .", gChannelTextbox); } listen(integer Channel,string Name,key ID,string Text) { uNotifyOwner(ID,Text); } }

If the singer and the button, or the button and the toucher are more than 20m apart you'll probably need some clever solutions.

I think I can do that, I'll message you in-world.

When it wasn't working, was it just not working, or did the page partially load and throw an error? Check your media settings, You might have to turn off 'activate on touch' if you don't plan on touching every piece of (prim) media you intend to interact with, and of course make sure that media is on. (in your audio settings for whatever reason)

I don't do a whole lot of shopping, but I have seen listings that mention in-world discounts.

Just out of curiosity, are you looking for full mesh, or prim with mesh components? What is your Li budget, and do you want it pre-textured, or are you going to texture it yourself?

If your objects are in different regions, you can either llShout() over the region border (I've never actually tried this, but I'm fairly certain it works) or use llEmail(). http://wiki.secondlife.com/wiki/LlShout or http://wiki.secondlife.com/wiki/LlRegionSayTo pair with: http://wiki.secondlife.com/wiki/Listen and http://wiki.secondlife.com/wiki/LlListen -- http://wiki.secondlife.com/wiki/LlEmail goes with http://wiki.secondlife.com/wiki/Email

Yeah, when's the last time you've heard about a DJ buying a streaming license for their music on (for example) Soundexchange.com? So much easier to rip from youtube illegally.

Messaged

It's much easier to set prim media via the viewer controls than via script, and it's not clear if you want to show multiple sites at the same time, or switch between them. for a very simple site switcher you could try something like: list gSites=["www.secondlife.com","www.DuckDuckGo.com","www.Google.com"]; integer gSitePointer; integer gButtonFace=0; integer gMediaFace=2; default { state_entry() { integer success =llSetPrimMediaParams(gMediaFace, [ PRIM_MEDIA_CURRENT_URL, llList2String(gSites,0), 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_PERMS_INTERACT, // who can interact with the site. PRIM_MEDIA_PERM_ANYONE // no final comma. ]); } touch_start(integer total_number) { if(llDetectedTouchFace(0)==gButtonFace) { ++gSitePointer; } else return; if(gSitePointer>=llGetListLength(gSites)) gSitePointer=0; string Site=llList2String(gSites,gSitePointer); llSay(0, "Setting Site to "+Site); llSetPrimMediaParams(gMediaFace, [ PRIM_MEDIA_CURRENT_URL, Site ]); } }

FYI I'm fairly sure you can't edit posts after a certain amount of time.

Yeah, basically that. you could also name your objects the same, and 'filter' based on name though. Another thing you might keep in mind is if you expect the object you're scanning for to /not/ be there most of the time, it might be nicer on the server to implement a messaging protocol with llShout() or llRegionSay() and llListen(), for example having the 'sensor object' say "PING" on a timer, and the thing you're detecting say "PONG" if it hears the ping and is within the correct range.

I believe the general consensus is you should use a single script when possible for best performance and lowest lag (to the server). If performance isn't an issue there are a couple of different specific reasons to use separate scripts. 1. Separating functionality for easier development. If I wanted to script a bunch of different doors for example, I might want to have things separated into three scripts, one for presenting a nice dialog to the user for changing configuraton options (locked/unlocked, who has a key, should it open on touch or try to sense someone coming etc etc.) another for determining when the door should open (could be rolled into the first script) and a third for actually opening the door. this would make it a bit easier manage scripting several kinds of swapable opening mechanisms (rotating double doors, single doors, sliding doors, turnstile doors. . .) while leaving the configuration options alone. 2. Data storage. If you have a script holding some mission-critical data, and aren't using some sort of external storage, it might be a good idea to have a separate script store the data, so you can make changes and fixes to the 'main' script without affecting the stored data, since you only get 64kb of memory per script (for mono scripts), this is also a decent way of expanding your memory allotment if you need to store some large (but not over 64k) lists. 3. Parallelism. All Scripts in SL are single-threaded. If you know what you're doing there are some /very specific/ instances where you might be able to take advantage of multiple scripts to do many things at once. 4. Code reuse. This is a bit limited, but you could also use a separate script for doing things you might want to do on a regular basis in different scripts, and use it as a sort of library. "give a nice dialog to someone and let them select another person in the same region" is one that I have a separate script for.

Reading a bit on the wiki, it does seem you can only have one llSensorRepeat() active at any time. @Wulfie beat me to the solutions I would suggest.

Yeah, I guess you're right Innula. it does rather irk me though that AVsitter uses 2 rather large scripts, when the basic functionality of the OP, and the use case many people actually want could be done in a 100-200 line single script.

AVsitter seems rather bloated and cumbersome in my opinion, but if you want/need to use it by all means go ahead.

That's easy enough to do. for each button you have a global integer that you increment which acts as the index into a list of textures. when the integer is greater than or equal to the number of textures in the list, set the integer back to zero. You can indeed read texture uuids from a notecard, but reading from a notecard is slow (1 second per line in the notecard) and a somewhat intermediate programming challenge. I might recommend just using textures that are in the prim's inventory. integer gTextureIndex; uSetTexture(string texture) { /*apply the texture here*/ } default { touch_start(integer i) { uSetTexture(llGetInventoryName(INVENTORY_TEXTURE,gTextureIndex++)); if(gTextureIndex>=llGetInventoryNumber(INVENTORY_TEXTURE)) gTextureIndex=0; } } I didn't test this but that should do roughly what you want. Following is an example with how to do the same thing, but reading the textures from a notecard (also untested): string gNotecardName=""; integer gNotecardLine=0; // set this to the number of lines to ignore before expecting every line to be a texture UUID or name. key gNotecardRequestKey; integer gTextureIndex; list gTextures=[]; // you can add some specific textures here. uSetTexture(string texture) { /*apply the texture here*/ } default { state_entry() { gNotecardName=llGetInventoryName(INVENTORY_NOTECARD,0); //comment out if using hardcoded notecard name. gNotecardRequestKey=llGetNotecardLine(gNotecardName,gNotecardLine); } touch_start(integer i) { uSetTexture(llList2String(gTextures,gTextureIndex++); if(gTextureIndex>=llGetListLength(gTextures)) gTextureIndex=0; } dataserver(key ID,string data) { if(ID==gNotecardRequestKey) { if(data!=EOF) { gTextures+=data; gNotecardRequestKey=llGetNotecardLine(gNotecardName,++gNotecardLine); } } } } if there are a lot of textures to read, and no textures listed in gTextures, you might want/need to add some code to stop the user from trying to set the texture before all the textures are loaded in from the notecard, possibly by moving touch_start() to a separate state that you transition to from the dataserver even when data==EOF.

If you ever do, I'm fairly certain you want to use one or the other and not both.

Funnily enough I was just working on a similar problem. I used detected velocity instead of a position differential. collision_start(integer n) { vector vel = llList2Vector(llGetObjectDetails(llDetectedKey(0),[OBJECT_VELOCITY]),0); vel = vel/llGetRot(); if(vel.y<0) llSay(0,"Wrong Way!"); else llSay(0,"Right Way!"); } My object also was llVolumeDetect(TRUE), which may or may not affect things for your application.