Quistess Alpha

No, in world (better) or if you really want to try websearch. . . https://search.secondlife.com/

Navy+copper's 'Parfait' and NO.Match's 'NO_Muse' might be a bit shorter but are still a bit thick. NO.Match's "NO_Never" is a bit long, but leaves the back mostly uncovered by draping the ponytail over the shoulder. NO.Match 'NO.Please' might be short enough for you but I don't really like the style. 'Elira' by Truth seems like a good short ponytail. Edit: after a reread probably only 'No.Please' and 'Elira' fit what you're looking for.

when you defined x_range you did it using floats, so you need to pull them out of the list as floats using llList2Float. perhaps you should do a review of the basic data types: http://wiki.secondlife.com/wiki/Category:LSL_Types

and you're using logic where logic isn't what was asked for. is it possible that making something locked will break a script? maybe. Should the OP stop locking things? Probably not, because from everyone else's experience the reward is much greater than the negligible risk.

Even if locking an object were to break llPushObject() (not sure I believe that, but I'll take it as a given) I can't really imagine anything you would want to lock having that function in its script.

Most sandboxes are on general regions; You could try making things and selling them.

SLM= Second Life Marketplace?

As an ignoramus, what's wrong with steam? Also, What's an AAA?

Just be aware that there's a slight difference between tipjars that are scripted for different people to log into and personal tip jars. all you need to make a personal tip jar is to make a prim and drop a script like this one into it: integer Total; string OwnerName; default { on_rez( integer sparam ) { llResetScript(); } state_entry() { OwnerName = llKey2Name( llGetOwner() ); llSetText( OwnerName + "'s Tip Jar.\nAny tips gratefully received!\nL$0 Donated so far", <.2, 1, .6>, 1); } money(key id, integer amount) { Total += amount; // Shortcut 'cheat' to avoid multiple casts when constructing a message including non-string items string str = (string) [OwnerName, "'s Tip Jar.\nPlease tip if you are so inclined!\nL$", amount, " Was donated last!\nL$", Total, " Donated so far" ]; llSetText(str, <1,1,1>, 1); llInstantMessage(id,"Thanks for the tip!"); llInstantMessage(llGetOwner(), llKey2Name(id) + " donated L$" + (string) amount ); } } Copied from the wiki: http://wiki.secondlife.com/wiki/Money

with their script, it looks like it can expand up to 14 meters Diameter. With what I posted you can change the parameters like I described before.

Then just buy that. They put some effort into making it look nice, and it seems like it has some good quality of life improvements to just a basic particle script.

For a Hotspring I think you'd want a low rolling mist rather than a big steamball. Have a play with something like this : default { state_entry() { llParticleSystem( [ PSYS_PART_FLAGS, PSYS_PART_BOUNCE_MASK| // particles 'bounce' when falling down to the z=0; plane relative to root. PSYS_PART_EMISSIVE_MASK| // fullbright particles //PSYS_PART_FOLLOW_SRC_MASK| //follow source, but disable burst radius. //PSYS_PART_FOLLOW_VELOCITY_MASK | // particles point their 'up' towards their heading. PSYS_PART_INTERP_COLOR_MASK | //color and alpha change over the particle's lifetime. PSYS_PART_INTERP_SCALE_MASK| //particle size/scale changes over the particle's lifetime. //PSYS_PART_RIBBON_MASK | //PSYS_PART_TARGET_LINEAR_MASK | // straight line between src and target. //PSYS_PART_TARGET_POS_MASK | // particles attracted to target. //PSYS_PART_WIND_MASK | 0, // makes (un)commenting easier. /*------------------------------------------------------------------------------------*/ //System Presentation PSYS_SRC_PATTERN, //chose one of the following //PSYS_SRC_PATTERN_EXPLODE, PSYS_SRC_PATTERN_ANGLE_CONE, //PSYS_SRC_PATTERN_ANGLE , //PSYS_SRC_PATTERN_DROP , //PSYS_SRC_PATTERN_ANGLE_CONE_EMPTY, // questionable implementation. PSYS_SRC_BURST_RADIUS, 0.0, // float value PSYS_SRC_ANGLE_BEGIN, // think of these like the 'dimple' operation. 1.25,// range 0 to PI PSYS_SRC_ANGLE_END, 1.26, // range 0 to PI. //PSYS_SRC_TARGET_KEY, //NULL_KEY, // Key of the Target object. /*------------------------------------------------------------------------------------*/ //Particle Appearance PSYS_PART_START_COLOR, <1.0, 1.0, 1.0>, PSYS_PART_END_COLOR, <1.0, 1.0, 1.0>, PSYS_PART_START_ALPHA, 0.1, // 1.0 - 0.0 ; opaque to transparent. PSYS_PART_END_ALPHA, 0.01, PSYS_PART_START_SCALE, <1.50, 1.50, 0.0>, // z is ignored. PSYS_PART_END_SCALE, <0.75, 0.75, 0.0>, // z is ignored. //PSYS_SRC_TEXTURE, //"", // texture must be a UUID or in the emitter prim's inventory. PSYS_PART_START_GLOW, 0.000, // range 0.0 to 1.0 PSYS_PART_END_GLOW, 0.0, /*------------------------------------------------------------------------------------*/ //Particle Blending /* //Probably best to not mess with this to much, read the documentation first. PSYS_PART_BLEND_FUNC_SOURCE, PSYS_PART_BF_SOURCE_ALPHA, PSYS_PART_BLEND_FUNC_DEST, PSYS_PART_BF_ONE_MINUS_SOURCE_ALPHA, //PSYS_PART_BF_ONE, // option suggested by Wiki for better blending. */ /*------------------------------------------------------------------------------------*/ //Particle Flow PSYS_SRC_MAX_AGE, 0.0, // how long to have the emitter on. // a feature/bug causes the emiter to go off every time the prim is updated in the viewer, ergo, at every region crossing and on rez among other things. PSYS_PART_MAX_AGE, // particle lifetime. 30.0, // range 0.0 to 30.0 PSYS_SRC_BURST_RATE, 0.05, // 0.0 to inf. Ammount of time between particle bursts. PSYS_SRC_BURST_PART_COUNT, 12, // number of particles per burst (an integer) /*------------------------------------------------------------------------------------*/ //Particle Motion PSYS_SRC_ACCEL, // acceleration in region coordinates per particle. <0.0, 0.0, -0.2>, PSYS_SRC_OMEGA, // rotation of emiter around X,Y,Z REGIONAL axes. approximately radians per burst. <0.0, 0.0, 0.0>, //<0,0,0>, PSYS_SRC_BURST_SPEED_MIN, // initial speed of particle. 0.27, PSYS_SRC_BURST_SPEED_MAX, 0.25 // no final comma. ]); } } you can make the radius wider either by making the particles bigger (increase PSYS_SRC_*_SCALE) or increasing the spead at which they eminate from the center (increase PSYS_SRC_BURST_SPEED_* ) to make the radius smaller you could decrease PSYS_PART_MAX_AGE as well as the aforementioned parameters. Aditionally, if you have some way of hiding the particle death (if you put it at the center of a deep pool for example) you could increase the PSYS_PART_END_ALPHA a bit (up to PSYS_PART_START_ALPHA) which would make the radius /appear/ to be ever so slightly wider.

I've never really used keyframe motion before, but the only solution that hits me is to KFM_CMD_STOP the tractor instead of pausing it. this would reset the tractor to the beginning of its route, but perhaps, after stopping the tractor, you could place it at its last keyframe position and recalculate its route to start from there.

I'm to lazy to parse that unindented code, but all you need to play one animation from the prim at random is llStartAnimation(llGetInventoryName(INVENTORY_ANIMATION, llFloor(llFrand(llGetInventoryNumber(INVENTORY_ANIMATION))))); (assuming you have your permission requests in order) and similarly llTriggerSound( llGetInventoryName(INVENTORY_SOUND, llFloor(llFrand(llGetInventoryNumber(INVENTORY_SOUND)))) , 1.0 ); will play a sound for you. Aren't nested functions fun?

Hmm, Probably a BOM skin like for example this one: https://marketplace.secondlife.com/p/Blue-Dragon-Skin-withh-Bonus-Shape/5042394

There is a special texture called 'DEFAULT_MEDIA_TEXTURE' which when you set your parcel media will do just that. When your parcel media is off it happens to be a convenient shade of grey. You have to manually edit all of those surfaces to a blank texture and tint them grey to get rid of the media player problem.

I've seen an in-world effect where a 'projector' prim lights its texture onto the environment, so for example a 'projector' prim with the text "hello world" on its projector face pointing at a wall displays "dlrow olleh" or so onto the wall, if you have advanced lighting on in your viewer. I can't seem to find where this functionality is in LSL, or how to make such a prim.

Yes, very possible. How much you 'd need to pay depends a lot on your quality requirements. If you want to have someone make a complete mesh avatar from scratch, it's going to cost you a lot of $$$ it would be much easier to try and build your avatar from different components. Things you will need: Shape: I think 8 feet is just on the edge of what you can get with shape sliders, but making a tall shape or maybe adding in some deformers wouldn't be too hard. you can also make your ears pointy with your shape, but some heads support pointy ears better than others. (Mesh) Body & Head: What kind of body you get (if any) will affect the kinds of clothes that will fit you, and if any of the other parts you get are rigged, what body they are for will be an important consideration. Eyes: You can attach a glowing yellow sphere prim to each of your eyes. If you want pupils you might need to play with the texture a bit. Ears: Earrings are not hard to find or you can even make your own simple ones. if your head does not support pointy ears you might need to get a sepparate attachment. you'll also probably want something to make your ears look 'webbed'. Horns and Hooks: Horns are pretty simple to make out of prims, and should generally move with you correctly if you attach them in the right places. Hands: A three fingered Hand with long hooked 'fingernails' might need to be a custom piece of rigged mesh, assuming you want to use bento hand animations. Feet: a four toed foot might also need to be a custom piece, but you could probably get away with having it be unrigged, or having a 5 foot toe with the 4 fingernails and hoping nobody realizes the discrepancy. The nails and heal protrusions could be prims. . . Tail: There are a good number of rigged bento tails on the MP, or you could just make a flexiprim tail.

As far as I can tell Molly's code should do that, unless the code needs rotation division instead of multiplication: CAMERA_POSITION, llGetPos() + (<-3.0, 0.0, 0.5> / llGetRot()), I can never remember when you need one or the other, rotations are confusing.

When you save your preset, check 'Replace a preset' and replace the one that says 'Rear View'. or when you name the preset be careful to name it Rear View, both words spelled correctly an both capitalized.

You probably just need to change something that looks sort of like llSetLinkPrimitiveParamsFast(LinkNumber,[PRIM_COLOR,FaceNumber,Color,Alpha]); to llSetLinkPrimitiveParamsFast(LinkNumber,[PRIM_POINT_LIGHT,TRUE,Color,Intensity,Radius,Falloff]); putting in some values for Intensity, Radius and Falloff. Searching your code for 'PRIM_COLOR' would probably point you to the line you need to change.

A direct answer is yes. if you had a color changing hud with full perms on the script, it would be rather trivial to make it change the point light color rather than the texture color. When you change the light color, via script, you also have to change all of the other light properties (llslppf([ PRIM_POINT_LIGHT, integer boolean, vector color, float intensity, float radius, float falloff ] )at the same time, so it might be useful to have those integrated into the hud as well. Edit: to be more precise, you would only actually need to change the script you put in the receiving prim (the light bulb), assuming you knew the channel the HUD was sending commands on.

If you save your view as a preset, you /should/ go back to that view every time you hit escape or move around. If that's not happening yell at the firestorm people to fix their viewer.

Possible, yes. practical, maybe not. because there's no LSL provided api for slider bars, you'd need to program something yourself. Maybe I'm not buying the latest and greatest stuff, but all of the color slider huds I've seen are a bit finicky and unintuitive in my opinion, and I don't know if I would want to attach and detach a HUD just to change the color of some lights. that being said, a very basic color picker HUD isn't that hard to slap together, if you have those fancy gradient textures.

Doveryay no proveryay.