Void Singer

with planar mapping you can use the image above as-is (assuming the angles are right) on prims that are pinched or cut into triangular shapes.... some prims use planar mode by default for faces (the tops of cylinders IIRC). planar mode applies textures projection style onto the surface, rather than wrapped, so it's not well suited to curved surfaces like spheres or torii (with few exceptions)

in addition, be aware that generally aditi regions self clean... meaning they roll back to a specific state so that anything that affected it in between doesn't pollute results going forward... and of course crashes can often take recent items/changes with them, occasionally restoring removed items. you can monitor remotely as well with llRequestSimulatorData by polling DATA_SIM_STATUS, but I haven't tried it to see how effective it is. ETA: NVM I misread Darkies suggestion when I was skimming, which is the same.

shameless self promotions, here I come.... If you so much as DARE to quote my post I shall have my Loyal Lackeys™ banish it to the moderation queue which was actually a joke from when LL was trying to fight spam by filtering keywords, and my name was caught by the filter... so anyone quoting me would get auto-moderated =D..... and is the source of my current signature.

considering the poor state of SL support for paypal withdrawals? not so shady.

all the Avatar Alpha Clothing Layer can do is cut holes in the texture surface of the avatar, it doesn't apply any color information. it treats any alpha in the texture as something to cut out, and any color is ignored.

a link to a RL picture of it might help, but I'm guessing you can do what you want by using planar mapping mode for the end texture (checkbox on the texture tab)

the cost on that mesh is only 2 prims?! my hat is off to you!

yay an optimized version... ...and now to make everything relative, and not reset when in the up position: integer gBooMoved;default { touch_start( integer total_number ) { llSetPos( llGetLocalPos() + llList2Vector( [<0.0, 0.0, -0.1>, <0.0, 0.0, 0.1>], (gBooMoved = !gBooMoved) ) ); llOwnerSay( llList2String( ["Down","Up"], gBooMoved ) ); llSetText( (string)gBooMoved, ZERO_VECTOR, 0.0 ); //llSetColor( <1.0,1.0,1.0> * gBooMoved,1 ); //--fails to show the first move if color is already white }}

heh, and now that I know the exact behavior I could make one more suggestion, although from your comments inworld I'm guessing you arelady figured it out (so this is for the thread readers).... use llTextbox so that the user can send the string as is @Gadget: it might matter (and did this time). the better a problem is understood, the better it can be addressed... devil's in the details and all that. my question wasn't intended as condescending, it was genuine confusion about what was to be accomplished... and more options is always good =)

do you have a small cache size and large draw distance set? seems a little fast and consistent for a memory leak (well for one they haven't caught yet) also try turning off all media/sound to see if one of those may be the culprit.

actually a variation of Immies suggestion is what I was going to offer next.... now that I know the use case... llSetObjectName( llGetObectName() + ": /me" ); llOwnerSay( "/me " + llGetSubString( output, 4, -1 ) ); llSetObjectName( llGetSubString( llGetObjectName(), 0, -6 ) ); the only bothersome thing is that in V2 and several of the TPVs, the entire object name is linked in a different color (plus it doesn't play nice at all with v2's non-plaintext chat since they fixed /me for that) ETA: why are you starting a new line with /me anyways? doesn't seem like a normal thing to do in a script, and if it's for a notecard you can always catch the leading space with llStringTrim. if it is a script, you can actually cheat and print multiple lines, and use inline comments to negate the objects name by appending /* to the end of one block and */\n to the begining of the next... as long as it's not a continued string literal it's perfectly safe

you need to reset it when it attaches =) although my test with the same code showed something ridiculous... I had to make moves of 1.4m or more before the viewer would show it to me on V2... adding llSetText at the end of the touch cured it, but that shouldn't be happening (and it's not your code at fault)

umm NO, it's called fraud and breach of contract.

assuming this only happen on your home region I'm betting that something in the scene isn't rezzing immediately, and when it does it's giving your vid card a fit.... if this is the case, turn on highlight transparent and see if you can't spot the likely culprit (ctrl+alt+t if the advanced menu is open)

you problem was using llGetPos, which returns the avatars position when called from the root of an attachment, use llGetLocalPos instead

input = llDumpList2String( llParseStringKeepNulls( input, ["/me "], [] ), "/me " ); I cheat.... view as html to see how ETA: a leading space is probably better, since mine will also print the literal string if copied from chat... but if you are just looking to supress /me from strings, it works a charm

replace: data = llStringTrim(llDeleteSubString(data, 0, s), STRING_TRIM); with data = llDumpList2String( llParseStringKeepNulls( llStringTrim( llDeleteSubString( data, 0, s), STRING_TRIM ), ["\\n"], [] ), "\n" ); note that I bolded your original code, and that it replaces "inputString" from the original, to see where it's all going

it would appear that you have them attached to the wrong sides.... make sure to change your ruler mode to "attachment" after attaching them and move the nearer to the 0 point =)

quick and dirty \n from text replacer inputString = llDumpList2String( llParseStringKeepNulls( inputString, ["\\n"], [] ), "\n" ); the problem with the notecard not being re read, I'm not sure about.... but I do see that you are resetting the whole script when you get ANY changed event when it's in the second state, you really don't want to do that... that's where you should be checking if the notecard key is the same as the saved key, then if it's not, change back to the default state which will rerun init and update it if (CHANGED_INVENTORY & change){ if (llGetInventoryKey(notecard_name) != notecarduuid){ state default; }}

yeah, unfortunately they found that while XMPP can handle large multiples well, it can't handle large single loads like they had hoped no one had ever tried large groups for single chats, only large amounts of single chats.... the latter it handles fabulously, the former, unfortunately, hasn't seen any scalable solutions tested.... obviously XMPP failed that test.

I agree that it is a blunder that when changing/porting privacy settings, they should always default to least permissive, unlike what you saw with sections being suddenly exposed

you might just be better off downloading the previous version... you can always find those towards the bottom of this page ETA: in this age of massive home storage, I recommend keeping a copy of installers for products that you use frequently/always, and saving them in a special folder just so that you have them if you need to go back, and can't find it online =) you can always delete older versions as you find one that works for you.

how I would do it.... in collision_start, call your llParticleSystem. make sure to set PSYS_SRC_MAX_AGE in collision_end, either use a short sleep then call llParticleSystem( [] ) (or call a timer with the same code and also stop the timer) why not rely on PSYS_SRC_MAX_AGE? there's an annoying bug, that if a particle system is set, new viewers that come into range will trigger it for that viewer, even though the run is already expired for the original person that triggered it. the only way to prevent that is to clear the system after it's been triggered... your timeout to kill the system need to be at least as long as the PSYS_SRC_MAX_AGE. it'll still have that side effect while its set, but this way you at least minimize the unwanted behavior. note: you don't have to wait for collision_end, you could do the same right from the collision_start, but this might give you a little side benefit for people coming into range after another person triggers it, and is still colliding with it.

oh I wish we could do something like that... unfortunately it'd cause massive conflicts as is with the integer based handles we get now.... some scheme like that could work if the listen handle spit out keys, and they put in some logic to close all the KEY handles with matching channels when listen remove got an integer.... I doubt such a setup will ever occur though

oof, that' not good... those should be saved to user settings anyways... and run as admin might be a workaround, but it's probably more of a security hole than the original problem =(