Nova Convair

Changing a position with llSetPos or llSetRegionPos is no movement. You only change a number in the objects data field. Physics is not involved here. You can "move" through and inside of other objects. Phantom is meaninless here, it works with and without that setting. There are some limits: You can only use it if physics is OFF. If you go on another parcel or sim - object entry has to be allowed If you go over 4096m - DELETED. If you go over the sim border and there is no sim - not possible with llSetRegionPos - with llSetPos - RETURNED (don't depend on that) If you go over the sim border and there is another sim - not possible with llSetRegionPos - with llSetPos - works If you go under the ground - not possible So you cant move it under the ground level because that violates one of the laws of SL: "There shall be no object under the ground"

Regarding speed tests. One thing is what your connection can do but what counts is what the SL server is willing to give you. If I TP into a '"heavy" place with empty cache I saw 2-3 peaks of 8 MBit but many peaks of 2-3 MBit. Most of the time it stays below 1 MBit. So it doesn't matter for SL if you have a 5, 10 or 100 MBit line. My ping is much higher than any of the americans since I'm in europe. But I have no troubles in SL. That lets me guess that the ping is not the problematic factor either. I have zero packet loss though. That is maybe one of ther more problematic issues.

The viewer doesn't use my 4770 cpu fully. All cores each under 50% usually and SL seems to use about 1.5-2 cores so replacing your cpu will not give you any performance advantage I assume. The biggest impact on performance will you will get by replacing your ATI with any NVIDIA of comparable performance level. A 980 should do fine but on the high end SL does not scale well with the GPU. (means 200% GPU is not 200% fps) You can utilize the GPU by setting up the quality though.

I use something like that to display a radar-sphere around an object. No sensor needed in the whole thing, especially not in the scan balls since they only monitor one avatar. This script uses ancient technology and shouldn't be used without an overhaul. However - it doesnt matter what prim/sculpt/mesh-prim in whatever rotation and whatever size is used as scan ball. If you want to display that on a surface instead of a 3D space you need to map the coordinates. 3D to 2D flat or 3D to 2D on a sphere surface or whatever. Some math is needed. 1st you need to find out what exactly you want to display. "somehow on the prim instead of inside" is no base for calculations. You have 3D coordiantes and want to display that - how? Edit: OOPS - wrong button - was meant as a reply to the OP

Wiki says you define a box so you can separate floors. But in this case I'd rather make a test 1st to see if this really works as described.

I see. If you cant get along with the animation script you need to replace it. How complicated that is depends on the way the wings are build. it's surely more complicated than the flight detection. Using other wings can lead to the same problems - you will not know until you tried it. You could ask the creator if the animation script can be changed. But many builders can't script and will hire a scripter so things can become more complicated. The flight detection script could halt the animation script b4 it makes the wings invisible. But need to think about how to activate it again when needed.

Get familiar with SL and spend some time with it. Read tutorials. It makes no sense to ask questions when knowing absolutely nothing. If you don't want to take your time you need to hire a scripter - if you find someone that is patient enough.

You have 4 pairs of wings and the animation script makes them visible and invisible as needed. So the solution is simple. Don't make them visible! The animation script will do that for you. You only make them invisible on landing. Take the line out of the script that makes them visible and leave the line that makes them invisible untouched.

That script will still work. You probably did not understand how to use it. Putting a script into every prim was necessary then but today it's a stupid idea and maybe you will get tarred and feathered for that. You need only the main script, just a little change needed. // Agent Flying Detection//// This is the main script. Place one copy of it in the attachment in question,// usually the root prim.//// Cross Lament's messy code follows.integer isFlying = FALSE ;default{ state_entry() { llSetTimerEvent( 2 ) ; // Polling rate, check every couple of seconds } timer() { integer flystatus = llGetAgentInfo( llGetOwner() ) ; // if the agent is flying, and the status holder says they're not... if( ( flystatus & AGENT_FLYING ) && !isFlying ) { isFlying = TRUE ; llSetLinkAlpha(LINK_SET, 1.0, ALL_SIDES); } // if the agent is NOT flying, and the status holder says they are... else if( !( flystatus & AGENT_FLYING ) && isFlying ) { isFlying = FALSE ; llSetLinkAlpha(LINK_SET, 0.0, ALL_SIDES); } }}

There is ONE llSetTextureAnim possible per prim. If you have more the last one is active. So you have the choice of one face or all faces. For 3 faces I only know a non script solution: Make a mesh cube and set 3 sides to one mesh face or material or whatever you name it.

I don't see the need for states and Rolig explained everything about 2 timers. If you want to do 2 things at the same time - states will not help you since only one state is active at a time. I have the impression that you aren't aware of that. For 2 simultaneously running timers you can use a multiplexed timer or 2 timers (sensor trick) or 2 scripts but not 2 states. For 2 timers runnung after each other you can use different states, but is not necessary. I noticed that you have a 2 sec timer and every llSetLinkTexture and llSetLinkPrimitiveParams has a delay of 0.2 seconds. So it's possible that the execution one one loop takes longer than 2 seconds and that will result in troubles. I don't know how many texture changes the double loop in changetexture() will use. Another thing: if you enter a state the state_entry() event is executed. So every time you return to state default - if you want to return - the state_entry() event will run. If that is supposed to happen every 2 seconds you don't want to have the llOwnerSays there.

Kurt Jiagu wrote: well i`m guessing they are concerned about the impact ,of the scripts used in the boats , on the sim.......... some seem to think that a boat with a few scripts causes more impact than a boat with just one script ........ is this so ? I mean if its scripted well with several short scripts how will that compare to something scripted using just one longer script to achieve the same results ? Every script cause a small idle load so it's always a good idea to keep the script count low. But what matters is the script load in action. 10 scripts with 0.02ms are better than one script with 0.5ms so the number alone means nothing. I made a few load tests a while ago. If we are talking about a few 100 scripts the numbers are meaningless. The script execution got into troubles when I triggered 3000 listening scripts simultaneously a few 100 times. So a few boats alone cant shatter a sim. The spectators will shatter the sim much more. Don't confuse that with lag. If the script execution is overloaded that will only lag other scripts. Not avatars or movement or teleportation. So the biggest impact on a race will be the spectators. Strip them naked and make them drop all huds or something.

Perrie Juran wrote:You must be hanging out at a nude beach if you are seeing more lower power Ava's. And it is getting more and more like this every where I go. Overall Mesh clothes has been increasing average ARW 50 to 100% and in some cases more. And if you put a dozen Ava's in one place it's adding up to a huge impact. And I've seen two instances of Ava's wearing mesh boobs who topped 500,000. (All three pictures taken at same dance event) ETA: In many instances some people don't realize they are their own walking lag bombs. I answered about scripts and avatars seem to have fewer scripts lately. Overmeshed clothes by clueless designers are another story. And since more and more mesh bodies are out there you don't even need clothes for a mega triangle count. I can and will mute avatars if I ever identify a trouble maker - but that did not happen yet. I still can render them all even the bad ones.

Define "lag". Nothing in this thread is about lag. If you mean impact on sim performance: there is none, so just forget it. If you want to compare the amount of load on the sim's script execution - that's not easy. Many - so called - script meters show the amount of memory usage. Bad thing is that it isnt possible to find out the memory usage of a script - so that devices have errors of a few 1000%. You can only find out the max. possible memory usage. But that has nothing to do with the used amount of memory. Not to mention code sharing - equal scripts will use the same code. So 100 scripts use the same space as 1 script. (old resizers for example) Script execution time is more interesting. But a short check gives you zero info. The scripts need some time to get to the final state. There is a difference of course when the object is just standing there idle or is running. If it's running the values will change alot. So it will take quite some checks to find out what objects have higher impact. Compare that with the avatars on sim and maybe you'll find out that you probably should better kick avatars than objects. But that depends. I've seen more low power avatars lately.

There is a bug - an old one - so old that I don't think that LL will ever fix it since I assume they can't. If one avatar unsits - this avatar will loose the camera controls - that's intentional. But all other avatars sitting on the same object will loose their camera controls as well. What I do is: my script detects if an other avatar unsits - then it restores the camera controls for the avatar it has permissions. That is not smooth - just better than nothing. There is no direct way to detect when camera controls get lost and if an avatar unsits it takes a little time until the other avatars loose controls. So I see no way for a super quick and smooth restoration. If someone finds one - post it.

You have 2 straight lines and want to connect them with a curve. You will always need a mathematical funcion to do that. Cubic splines will do fine but the math will cause a heavy headache - well - for me. Bezier curves look easier but not sure if that isn't too much for LSL. A circle is very easy to calculate but you need to arrange the center and radius of the circle in a way that your straight lines are tangents to the circle segment. - If that's not the case it isn't smooth. You need to calculate the tangent of a given point as well since that gives the rotation for that specific point but thats a piece of cake for a circle. I'd like to have a function that delivers a waypoint list. I need to think about it. Maybe there are easier ways for less accurate results too.

Movement and rotation and independant from each other. It doesnt matter how you rotate your object. The rotation of the object has nothing to do with the movement of the object. The movement is always in a straight line from point A to point B. If you want to simulate a curve you need to chop the movement into many short little pieces so it will only look like moving in a curve. The rotation has nothing do do with that movement but of course you need to calculate that so the object will point into the direction of movement. To keep that in sync you need to chop the rotation into the same amount of many little pieces than the movement. The only way to avoid that is to use physical movement. Then the physics engine and the viewer will do the work for you.

How did you construct your curve? There is a center point and a radius and an angle. If you don't have that you need to set markers or set a rectangular triangle (prim) and calculate the curve parameters. Then make a list of waypoints for llSetKeyFramedMotion between starting and ending angle of the curve. Maybe every 2° or 5°? you need to test if it looks smooth enough. so we have an angle a in deg - like starting at 10° and ending at 100° in a global direction, like a compass increase by 2..5 maybe for every waypoint. xofs, yofs = center of the curver = radius of the curve to calculate a point for an angle you do: x = sin ( a * PI / 180 ) * r + xofs y = cos ( a * PI / 180 ) * r + yofs you can get rid of the PI/180 of course when you use radians instead of degrees The length or the bow is: length = a (in radians) * r The travel time for the whole curve is: time (s) = length (m) / speed (m/s) Thats the math. Getting that into LSL is the next step but I'm waaaaayyyy to tired for that

Benson Gravois wrote: Come on guys, Like role playing I mean, and a social place to meet someone. That works in RL but not in SL. You can be instantly everywhere and talk to everyone and nobody needs food. So all that kind of places are maybe used 1-2 times when they are new and thats it. The only fun in places like that are to build them. Once they are there. Delete and make something new.

Install a 2nd (different) viewer to see if it is viewer or system related.

I noticed that this behaviour is gone lately. Well for teleports and logins. If I throw away my camera a few 1000m and pull it back it can still happen.Stomping on the ground fixes it though. (I mean I right click or span a selection frame) Seems the viewer is still not 100% aware when to update what object. It's good enough for now - but things you don't fix will bite you in the ass - one day. You use one of the newest viewers and no old version yes?

I tested llVolumeDetect lately. Is pretty reliable and no flicker. collision_start triggers if someone enters and collision_end triggers if nobody is in. The number of avatars is meaningless, only if the last one leaves collision_end will trigger. A non flickering detector is easy to script. If the prim is 1m high - its sufficient - except someone jumps. But its possible to fill the room with that prim. Prim is made invisible of course and llVolumeDetect will make it behave like phantom. --- Update: I checked what I have done with llVolumeDetect Not that easy, you need to have a list of all avatars and track who enters and leaves to make it multi-avatar-proof - well still not too difficult but maybe too much for a noob.

The "pressure plate" needs to be a prim that uses llVolumeDetect and sends every status change to the indicator by using llRegionSay. The indicator changes the color according to the received status messages. If the "pressure plate" uses llVolumeDetect you can not link it. If it is required to be linked you need to use llSensor and a timer or llSensorRepeat.

Gestures are not server side but played by the viewer. So a script can NOT play gestures. As mentioned above only thing you can do is rebuild the gesture. But you need the sounds for that and I assume you have only the gesture. So the answer stays: NO.

A script can send IM's ( llInstantMessage ) or ( llRegionSayTo (same sim) ) but as mentioned they are shown in the local window. Only avatars or bots can send you an IM that will show in a new window. You can send a dialog box by ( llDialog ) thats an extra window that requires to be clicked off.