Void Singer

actually, if the script targets itself with local values rather than region ones, it's just the same code, linked or unlinked. they also did finally give us some help on that buggy interface, and we now have PRIM_ROT_LOCAL for prim parameters, which behaves correctly for both set and get... I updated the wiki with a whole bunch of conversions in case people did want region relative, without the bugs. I'm guessing you haven't taken a look in a while, but you'll be pleased I think.

very ridiculous difference.... if they have the first problem with pretty much any gtx card they've screwed something up

it's actually a rather nice feature, now that i've had a chance to try it out on phoenix (I don't do a lot of land stream listening). although not all stream are going to tag music accurately (or even at all) I would think that if someone put in a feature request, it shouldn't be too hard to implement (it just requires a little feedback from the media plugin) although there may also be a small security risk with certain tagging formats, as has been exposed in the past on quicktime and other plugins/players, so that may have halted development.

http://community.secondlife.com/t5/Second-Life-Viewer/song-name-announcements/td-p/842301

attach( key vKeyOwn ){ if ((string)llGetObjectDetails( llGetKey(), [OBJECT_GROUP] ) != "group key goes here"){ //-- disable it, warn the user, set a variable, w/e } }

you aren't likely to see an appreciable difference for SL alone, but if you can get it to behave with SLi, then other things running at the same time may behave better

there should be a lighten tool in PS, but like Rolig says, you can just paint with a lighter color like bluish charcoal grey

slightly off topic, but whether a single prim door is linked or not really doesn't decide it's script complexity, it can be dog simple, or crazy mad huge with options to make a swiss army knife jealous. there's only really 2 methods (centercut/position-rot) available, 2 styles(static/dynamic), and 2 ways to manage them (local/networked) and they all work basically the same linked or not (as long as they aren't the root)

you can set bouyancy in advance, but what you might want to try is setting it non-physics before rez, give the region a moment to get the correct bounding structure, before going physical.... my guess is that there is a cut/sliced prim in there that would be intersecting (or nearly so) if it were not cut/sliced.

needs the group's key hard coded into it, and compare to llGetObjectDetails run on the object (objects assume the owner group when worn, but not if they change it after worn)

you can even use multiple variables in the returned javascript... or other javascript code(and you'll probably want to, it's easier than trying to detect when the file loads). Teacup is only there as an example of how to do it, so I'm not at all offended that it's overkill for your needs... I'm just happy to know it served as an example that sets people down the road to doing what they wanted.

it's BS, and there are tons of ways to find out if you are using more than one account, but this person is probably just guessing... it's an easy guess since accounts are free.

a horribly over simplified example: default{ state_entry(){ llListen( 1, "", "", "" ); } listen( integer Channel, string Name, key Source, string Message ){ if (llSubStringIndex( Message, llGetObjectName() ) == 0){ //--- message starts with the objects name list MessageList = llParseString2List( Message, [" "], [] ); //-- turn the message into a list, broken up by spaces if (llList2String( MessageList, 1 ) == "On"){ //-- second element is "On" llOwnerSay( "I was turned on" ); }else if (llList2String( MessageList, 1 ) == "Off"){ //-- second element is "Off" llOwnerSay( "I was turned off" ); } } }} the above example would be triggered by "/1<object name> On" or "/1<object name> Off" but will fail if the user doesn't use the exact capitalization, or puts any spaces before the object name the below example ignores those, and uses indexes from list find to tell it what to do... string gStrNom;default{ state_entry(){ gStrNom = llToLower( llGetObjectName() ); llListen( 1, "", "", "" ); } listen( integer vIntChn, string vStrNom, key vKeySrc, string vStrMsg ){ //-- !llGetSubstring, means it must start with the string we're looking for if (!llSubStringIndex( vStrMsg = llToLower( llStringTrim( vStrMsg, STRING_TRIM ) ), gStrNom ){ //-- we also saved the modified string back to itself, so we don't have to modify it again //-- check if the second part of the text (which is now lowercased) is on or off, and save the index. the result is -1 when not found integer vIntTst = llListFindList( ["off", "on"], [llList2String( llParseString2List( vStrMsg, [" "], [] ), 1)] ); if (~vIntTst){ //-- false if vIntTst is -1, meaning it wasn't found llOwnerSay( "I was turned " + llList2String( ["Off", "On"], vIntTst );//-- use the same indexes to find the mesage to send, so we only need one call to llOwnerSay to do the work of two } } }}

for anything you can see in a web page in your browser, assume it uses GET unless otherwise stated.... you can pretty much ignore any information about post I'm pretty sure you can use search strings in script tags src attribute (I suppose I should test that), but if you prefer, the "filename" on the lsl side is really just a string and not an actual file (I only treat it as such in my script for the benefit of people used to very basic web pages).... as long as the script receiving the link message understands that the name means it should respond to it, then you're good to go.

if your edit window is open when you rez something with that icon from inventory, all the separate parts will be selected together... (the icon means "coalesced object" or more plainly "multiple objects selected together") after the fact, when you select an object, you can include another one in the selection by holding down shift and clicking on it. when you have multiple objects selected this way, the position fields do gray out, this is normal and they come back when only one object is selected. any object that you happen to miss you should be able to move in the same manner as the others separately, by repeating the same steps you used for the first object.

if you are using opacity to control the lightness/darkenss then that might be the problem (I'm assuming when saving as TGA you have a separate alpha channel specified since it's not completely covering the skin, just the tatto itself is showing up too dark) the reason being that partially transparent layers blend the same way that "color to target" works, by taking the underlying layer rgb, and moving those values towards the overlying values by a percentage equal to the opacity of the overlying layer. this is going to be consistently darker than you expect if your background for the original is white. instead you would want to lighten the rgb of the tattoo image, and only deal with partial transparents at the antialised edges of your tatto (so that it looks naturally applied).... you could still do a partial transparency for the tatto, but it's going to need to be much more transparent, and this is going to affect how it looks different across different skins.

I'd never seen the jira before or I'd have added my own support for it. I see the concern for it possibly tweaking some peoples settings, but I think the fix is proper behavior (having no-group should not allow you to run scripts on non-group land)... I think it breaks land owner expectations if that happens, and results in more help and trouble tickets because of it. I always thought it was buggy that none was treated as a group (some lsl functions operate this way as well) many kudos to Maestro (or whoever got 61) & Kelly for banging out fixes for SCR 61 and 66 so fast (61 was just under a week old, and Kelly only heard about 66 yesterday!). I know it can be annoying to see small things go through before older issues, but it's nice to know that quick and simple fixes can get through the queue quickly and simply

Kelly recently solicited feedback about running a beta sandbox on AGNI (maingrid) as a way to prevent some of the more dire consequence like rollbacks, by making it more convenient to test without swapping grids, so that testing is more thorough with a better cross section of normal use. of course it's not without it's perils as it would mean content created there could interact with the regular grid, so there's a question of limiting access (similar to what was done with some mesh regions). in my eyes this does go a ways to proving the point that this likely isn't a problem of sloppy application, but rather of the limits of internal testing, that the appropriate staff are trying to explore other ways of addressing and preventing it, and I had the distinct impression that Kelly was upset that his changes ended up in a rollback.

actually my own observations are that Phoenix nets about ~40% of the market on average, lower in newbie dominated areas, higher in oldbie dominated ones especially among builders and property managers. V2 edges out above that at ~50%, and the rest going mostly to Imprudence and Ascent/Singularity and non-advertising v1x/snowglobe versions like Cool. that's still a bit embarrassing for V2 though since that means there primary adoption market is new users who probably have no clue about their alternative (because honestly, when you are looking for the download to make something work, do you really read through the whole page for other options? or just scan for the download link? most don't)

if you're wanting to use my version of the http-in server, the minimal parsing is listed in the protocols section, but i'll go ahead an expand on it here linked script will recieve source_prim = server prim link number integer_data = 418 (Teacup message channel) string_data = filename + "?" + search_string + "#ip=" + IP_Address + "&" + POST_data key_data = key of the request for returning data to to parse string_data for the search string as well as the filename use list myList = llParseString2List( string_data, ["?", "#"] ); this format will contain the the filename in the first element, the search string in the second, and the IP+postdata in any further elements. the search string may need to be run through llUnescapeURL (the browser encodes it automatically and server sends it as is to reduce overhead and ensure compatibility with endpoint script parsing) that format isn't entirely compatible with post data, but if that file doesn't handle POST (such as the scenrario you are using with script tags) then it won't matter. if you do need a compatible post format later it would be list myList = llParseString2List( string_data, [], ["?", "#"] ); 0 element is still the file name, search string is in element 2 and POST data is in elements 4+ (including the ip string) I haven't tried reusing the same script tag, as the one I use just holds the page code, so I wipe it out to reduce memory and prevent any incompatibilities with page scripts.... that you'll have to try on your own. any scripted reference to the tag should hold, but I don't know if just changing the source will cause it to be request a new file after one has been loaded.

whoops, of course as you already know I was quite impressed with them =) most reliable automated air transports I've seen.

the focus of the subject manner for the humanities might have some major bearing on our suggestions.... it seems to be that your focus is on the evolution of understanding starting from a basic non-scripting resident who is only a consumer, to a script editing writing and producing resident if I understand the conversation so far assuming that's the case, it will probably be most effective to walk a similar path. You've already started on that by reviewing the content here, the next step would be going over some of the content in the LSL Portal, and the Script library therein. After that I would recommend checking out some classes inworld (Search for NCI, they are a large resource for this) as well as some of the walk through content linked above.

my script takes any request to the server address (which I append a default "/" to) and spits it out to a link message.. whatever script handles that page should spit the file back to the server which sends it back to the browser. normal file naming conventions are used, so for instance, the bootstrapping javascript that I use gets requested as [http-in address]/teacup.js the server script spits "teacup.js?#ip=<whatever>&" out to the link message and a script catches that and sends back the actually text. it silently drops messages to the base server url so don't use that. as for the trick with (4 & variable) and (2 & variable), those are abusing bitwise values... 2 & x is true for 3 and 2 (because the 2 bit is set for both), and so on for each power of two, the higest value will will also catch negative 1 if you test for it first.

thanks =)

relevant details here but long and short prim goes temp 60sec timeout is started if prim goes to inventory, timer is paused but not reset (continues from where it left off when rerezzed) if prim is made non-temp before time gets to 60 timeout is NOT halted if prim is temp when timeout is reached, it derezzes, otherwise timeout is reset to zero (and stays there until prim is temp again) for your case, just don't set it back to temp via script, and instead rely on die, since the script had to be working to set it non-temp to begin with