Profaitchikenz Haiku

I found something in the answers section https://community.secondlife.com/t5/Answers/qac-p/Answers it won't actually link to the answer directly, but I typed in "I can't upload mesh to the beta grid", and about fourth down saw " I have a good Mesh Upload status on the main grid, but when testing on the beta, I am unable to?"

You will also have to pass the test on the beta grid account, the test that you took to upload to the main grid does not carry over to the Beta.

It works fine when I try it. Are you sure you aren't missing what is happening becuase you're putting it in a cube with equal X and Y dimensions and missing the actual change? It's an interesting method which I haven't seen before. The main drawback I can see is that it can only work for an object which is aligned along the normal (rotation = 0,0,0)

OK, I have a better idea of what you are trying to accomplish. I think you might be better off trying a simpler approach inside the control event. In a global variable, record the last value of the spin variable. ( will be 0 on startup, and presumably spin value will also be 0) Interrogate the keys, if a right key has been pressed, increase the spin variable by 1 and possibly clamping it to a maximum, if left has been pressed, decrease the spin variable by 1, possibly clam[ping it to a minimum value. Then, compare the new value of spin variable against the last saved value. If less than the last value then If greater then 0, apply slowing down right spin. else apply increasing left spin If greater than the last value then if less than 0, apply slowing down left spin else apply increasing right spin if 0, stop spin. finally, set the last saved value to the current value. ETA Just spotted the other thing, you are using && when testing for a control key being pressed, but the integer specified as the second argument to the control event is a bitfield, so you need to test for a bit being set by using & instead of testing for logical AND with &&. In addition, you have commented out the line that would decrement spinRate, so you are going into a block of code where Right is TRUE and spinRate > 0, but then there is only a test for spinRate <= 0, which will never evaluate TRUE unless you first decrement the value which was > 0 to get into that block in the first place Note that the user might be pressing both the left and right keys together. If so, the way your code is written at the moment, once a left keypress has been detected, there will be no subsequent test for a right key press. This makes sense in your application, but in other instances you could have a user pressing both right and up keys together and want it to mean something.

Using the two information tools available to a land owner, the debug->top scripts tab of the region/estate option and the script-info button on the land info floater, I see the following: If a script is running, it will be shown in the top-scripts with a value in milliseconds denoting how much time it requires. The amount of memory it requires is also shown in the script-info display. If a script is stopped, it is not shown in either of the two displays. However, by toggling a script from running to stopped and back again, I am certain stopped scripts remain loaded in memory, since they start instantly. Regarding lag due to scripted objects, trhis used to occur when avatars entered a region and was supposed to be a mono issue with loading the script. It was noticeable back in 2010, but has presumably been fixed since then, as I have not seen any sign of it lately. I have only one experience of script-lag about two years ago, when there was a gallery event hosted on the island, and suddenly everything stopped. Coincidentally I had the debug-top-scripts floater open at the time, and doing a refresh on it, saw that somebody who had just arrived had a script count against them of more than 2 seconds. Given a typical avatar with a hetfy AO and hair/shoe resizers usially weighs in at 0.3 milliseconds, this one person was equivalent to seven people arriving at once. I bounced them, found we went back to normal in the island, and IMed them to explain that I had been compelled to take emergency measures. They said they didn't know what could be wrong, and I never did get to find out just what they were wearing that grabbed that much script time. Your third tool is the View-Statistics floater, expand the time section of this, and you will see the total frame time the sim you are in broken down into various sub-sections, which may prove helpful.

Very quick thought as I'm doing stuff myself, but in the spin left, you use "rotStep *= -1", which , the first time you use it, will negate the value of rotStep, but if called subsequently, is going to flip rotStep between positive and negative values. Is this what you intend to happen? Did you instead intend to decrement the value of rotStep there to increase the spinrate?

What does the parcel info tab for script memory give? Ideally it will show you the location of and memory used by all scripted object within the parcel. If it does, it suggests that the scripts are still indeed loaded into the server, as one would expect. In order to check if they are actually running, you need to then try a couple of tests: 1) try attaching or rezzing an object in that parcel that does or says something, and see whatg happens 2) try entering the parcel wearing an object and see if it still operates My expectation (which I can't try because there are too many things that would get upset if I turned off scripts in one of my parcels), is that all scripts for objects within the parcel will still be loaded into memory and show as such, but will not be running. What I cannot predict but would like to know is for 2), does an avatar or object crossing into a no-script parcel nevertheless load the scripts into the memory for that parcel?

And yet you understand global vs local rotations, where I go rushing to the wiki every time Here's the lookup table method I was first proposing, and a fascinating insight. The savings on running time are all of 0.002 milliseconds for pre-calculating the vectors (0.025 vs 0.027), and a doubling in script memory, for no visible alteration in motion. It shows that I was initially proposing a too-heavy solution. Mind you, in the steam locomotive I have running on the island, the six wheels, two crank axles and two coupling rods that are moved around all the time really do show a saving over run-time calculations. // Master script for objects rotating around a fixed point on the Z axis// there will be other scripts within the object to handle multip-sits, those scripts should not try// to affect pos or rot of the object at allinteger benchChan; // define as requiredvector myPos;rotation myRot;integer spinning = 0; // set to 1 if llTargetOmega is in force, 0 otherwiselist posAndRot = []; // strided list of vector and rotation for each angle from 0 to 359 degreesrotation turnRot; // keeps track of actual rotation and is applied if spinning == 0integer count; // varies from 0 to 360setup(){ vector centre = <120.0, 184.0, 25.743>; // location about which to rotate float radius = 3.0; // distance to keep from centre float angle = 0.0; // start from 0 radians and increase to TWO_PI radians float degree = PI / 180;; // calculate as 1 degree in radians rotation deg1 = llEuler2Rot(<0.0, 0.0, degree>); // calculate as 1 degree Z rotation turnRot = ZERO_ROTATION; integer ii; for( ii = 0; ii < 360; ++ii) { posAndRot += <centre.x + radius * llCos(angle), centre.y + radius * llSin(angle), centre.z>; posAndRot += turnRot; angle += degree; turnRot *= deg1; } }newPos() // calculate a new X and Y based omn angle, X = centre + R*Cos, Y = centre + RSin{ ++count; // if rotating by more than 1 degree at a time, use count += amount; if( count >= 360) { count -= 360; } llSay(benchChan, llList2CSV(["angle", count]) ); // tell the slave seats where we are vector newPos = llList2Vector(posAndRot, (count*2)); turnRot = llList2Rot(posAndRot, (count*2) + 1); list params = [PRIM_POSITION, newPos]; if( !spinning) params += [PRIM_ROTATION, turnRot]; llSetLinkPrimitiveParamsFast(LINK_THIS, params);}default{ state_entry() { setup(); count = 0; llSetPos(llList2Vector(posAndRot, count*2)); llSetRot(llList2Rot(posAndRot, count*2 + 1)); turnRot = llGetRot(); llSay(benchChan, llList2CSV(["angle", count]) ); // tell the slave seats where we are llTargetOmega(<0.0, 0.0, 0.0>, 0.0, 0.0); spinning = 0; llSetTimerEvent(0.2); // off we go } touch_start(integer touches) { if( !spinning) { llTargetOmega(<0.0, 0.0, 1.0>, 1.0, 1.0); spinning = 1; } else { llTargetOmega(<0.0, 0.0, 0.0>, 0.0, 0.0); spinning = 0; llSetRot(turnRot); // and turn ourselves to face where we actually would be facing } } timer() { newPos(); }}

Check that your current group is the same as any land-group that you have set for your home ( look at the parcel information details to see what group is in force) , this is the usual reason for getting the "land-owner does not allow" message, although as Alwin says, trying to rez an item on top of another one especially if mesh is involved can also trigger it. Some viewers have an option under preferences to "rezz items under the land group where possible", see if you can set this.

I was tongue-in-cheek about the dented hat, I'll post full scripts when I can sense the OP will be better off tweaking a simple working example rather than adding snippets into a script. When it comes to reading other people's scripts ghowever, I am TL;DR personified. I've ripped these scripts out of the benches by removing the chunks which implement the multi-sit, becuase I think the major problem we all experienced earlier on was trying to contemnplate too many issues at once. Here's the master seat script, ripped from the main bench seat // Master script for objects rotating around a fixed point on the Z axis// there will be other scripts within the object to handle multip-sits, those scripts should not try// to affect pos or rot of the object at allinteger benchChan; // define as requiredvector myPos;rotation myRot;integer spinning = 0; // set to 1 if llTargetOmega is in force, 0 otherwisevector centre = <120.0, 176.0, 28.848>; // location about which to rotatefloat radius = 3.0; // distance to keep from centrefloat angle = 0.0; // start from 0 radians and increase to TWO_PI radiansfloat degree; // calculate as 1 degree in radiansrotation deg1; // calculate as 1 degree Z rotationrotation turnRot; // keeps track of actual rotation and is applied if spinning == 0integer count; // varies from 0 to 360newPos() // calculate a new X and Y based omn angle, X = centre + R*Cos, Y = centre + RSin{ ++count; // if rotating by more than 1 degree at a time, use count += amount; if( count >= 360) { count -= 360; } angle = degree * (float) count; llSay(benchChan, llList2CSV(["angle", count]) ); // tell the slave seats where we are float newX = centre.x + radius*llCos(angle); float newY = centre.y + radius*llSin(angle); turnRot *= deg1; // if not spinning, adjust our rotation to this list params = [PRIM_POSITION, <newX, newY, myPos.z>]; if( !spinning) params += [PRIM_ROTATION, turnRot]; llSetLinkPrimitiveParamsFast(LINK_THIS, params);}default{ state_entry() { llSetPos(<centre.x + radius, centre.y, 25.64094>); // for angle 0, cos is 1, sin is 0 llSetRot(<0.00000, 0.00000, 0.00000, 1.00000>); myPos = llGetPos(); myRot = llGetRot(); turnRot = myRot; degree = PI / 180; deg1 = llEuler2Rot(<0.0, 0.0, degree>); count = 0; llSay(benchChan, llList2CSV(["angle", count]) ); // tell the slave seats where we are llTargetOmega(<0.0, 0.0, 0.0>, 0.0, 0.0); spinning = 0; llSetTimerEvent(0.2); // off we go } touch_start(integer touches) { if( !spinning) { llTargetOmega(<0.0, 0.0, 1.0>, 1.0, 1.0); spinning = 1; } else { llTargetOmega(<0.0, 0.0, 0.0>, 0.0, 0.0); spinning = 0; llSetRot(turnRot); // and turn ourselves to face where we actually would be facing } } timer() { newPos(); }} And here's one of the two slave seats, the other is identical but uses 240 as it's offset angle // script to go in a slave seat, in this instance one of three to be spaced 120 degrees around, a third will be at 240 degreesinteger benchChan; // set as per main scriptinteger bhandle;vector myPos;rotation myRot;integer spinning = 0;vector centre = <120.0, 176.0, 28.848>; // location about which to rotatefloat radius = 3.0; // distance to keep from centrefloat angle = 0.0; // start from 0 radians and increase to TWOPI radiansfloat degree; // calculate as 1 degrerotation deg1; // calculate as 1 degree Z rotationrotation turnRot;integer count;integer myAngle = 120; // set as appropriatenewPos() // calculate a new X and Y based on angle, X = centre + R*Cos, Y = centre + R*Sin{ if( count >= 360) { count -= 360; } angle = degree * (float) count; float newX = centre.x + radius*llCos(angle); float newY = centre.y + radius*llSin(angle); turnRot *= deg1; list params = [PRIM_POSITION, <newX, newY, myPos.z>]; if( !spinning) params += [PRIM_ROTATION, turnRot]; llSetLinkPrimitiveParamsFast(LINK_THIS, params);}default{ state_entry() { degree = PI / 180; count = myAngle; deg1 = llEuler2Rot(<0.0, 0.0, degree>); llSetPos(<centre.x + radius*llCos(degree*count), centre.y + radius*llSin(degree*count), 25.64094>); llSetRot(llEuler2Rot(<0.0, 0.0, degree * (float) myAngle>)); myPos = llGetPos(); myRot = llGetRot(); turnRot = myRot; llTargetOmega(<0.0, 0.0, 0.0>, 0.0, 0.0); spinning = 0; bhandle = llListen(benchChan, "", "", ""); } touch_start(integer touches) { if( !spinning) { llTargetOmega(<0.0, 0.0, 1.0>, 1.0, 1.0); spinning = 1; } else { llTargetOmega(<0.0, 0.0, 0.0>, 0.0, 0.0); spinning = 0; llSetRot(turnRot); } } listen(integer ch, string name, key id, string msg) { list temp = llCSV2List(msg); if( llList2String(temp, 0) == "angle") { count = myAngle + (integer) llList2String(temp, 1); newPos(); } }} Usual warning about my propensity to typo applies

And what I've learned from this is that the LSL wiki is excellent at showing you how to use the built-in functions, but the examples it gives aren't always the best solutions to a problem. This problem was decomposable into 1) Get an Object which can seat several avatars on it. Fairly straightforward. 2) Spin it on it's own Z axis - straightforward using llTargetOmega 3) rotate it in a circle around a centre point. Here, the wiki provides an example using several vectors, rotations, and transformation/translations. The wiki solution for 3) is far too complicated. The simple solution is to use the trignonemtric functions Sine and Cosine. So for a centre point X,Y, the calculation for the position of an object rotating around it at radius R becomes as simple as myX = X + R * Cos(theta) and myY = Y + R *Sin(theta) where theta, in radians, varies between 0 and Two PI In fact, for speed, the best way to calculate theta is to have a global float set to PI / 180, which is therefore 1 degree expressed in radians, and an integer counter which increments from 0 to 360, then returns to 0. the counter value times the float gives theta in radians, and the amount by which the counter variable increments can be 1, 5, 10, 30, and so on, depending on how fine a circle you wish. So to do this with four seats requires all seats to have the function in them that, given Centre X and centre Y, Radius R and theta, calculates and sets the object position, then make one of them the master, and have it chat on a channel the value of theta it has just used, the others the other seats listen, add a preset number (90, 180, 270) to that angle, trim it to be within 0 and 360, and then calculate and set their own positions. So my lookup table method here was also an over-complication. Just goes to show, we all fall in love with working out how many angles can dance on the head of a pin sometimes.

Mainland is land where Linden Lab own the land and rent it out to landlors who then rent to you, or you buy a parcel of it and pay tier ( rent) for it to Linden Lab direct, Estates refer to collections of land that landlords own and manage Homesteads are smaller versions of private islands, both of them are owned by landlords who then rent out to individuals. The only ways to be certain of having no neighbours are a) rent a homestead or private island yourself. b) rent a parcel on mailand and be so obnoxious to your neighbours that they all leave. Of these, a) is tricky given your budget and b) is frowned upon by most people and is my tongue-in-cheek observation on the behaviour of various people I have lived next to in the past. You best strategy is to place an ad in the wanted sections with your stipulations,m and hope there is a landlord somewhere who has a sparsely-populated island and wants to keep it quiet If you become a pemium member you get an allocation of land, which means you can find that-sized parcel fo land somewhere and put a house on it, for no extra rental.With the risde of low-LI mesh houses and furniture you can manage to get a reasonable setup within the tight prim budget that 512 sqM of land equates to. With your budget you could find such a parcel and then buy some adjoining parcels for the extra amount you have mentioned, allowing you to have more room to spread yourself out in and more prims to play with.

Make up a strided list of the form [position, rotation, ... ] let's say with 72 pairs of entries, and at startup, read a notecard or call a function to calculate the positions and rotations, it's as simple as using x = centreX + radius*llCos(angle), y = centrey + radius*llSin(angle), and in this instance, starting from an initial rotation, multiply by a rotation of 5 degrees on the Z-axis, store that, multiply it again for the next entry.... Therefore when you consider index taking the values 0 to 142 in steps of 2, llList2Vector(lookups, index) and llList2Rot(lookups, index+1) will return the pre-calculated position and rotations for any angle in steps of 5 degrees. If you are using llTargetOmega to spin the seat you do not actually want to rotate it, the only time you use the rotations is either if an enpty non-spinning seat ius to be shown, or when llTargetOmega stops and you want to rotate the seat to where it actually should be considering where round the circle it has stopped. I have at the moment a one-prim sculpted bench which will seat up to three avatars orbiting slowly around a lamppost , the bench is also spinning around it's central Z-axis using llTargetOmega, and two avatars are sitting happily on it going round and around, although at least one of them is showing signs of motion-sickness. I would post a script but my hat has become increasingly dented of late by reminders that this forum is not for posting complete scripts in ETA added two more benches, spaced at 120 degrees from each other, each rotating round the lamppost, each spinning using llTargetOmega, one bench chats it's current angle to the other two, there's no lookup tables involved, and the total script time for them is still only 0.06 milliseconds. It would probably halve if I switched them all to lookup tables, but as it is, it's low enough for the visual effect it provides

I had originally thought you wanted each seat to be rotating around its centre point which was itself rotating around the ride centre point. Having seen what you are trying to do, I think I would go for a simpler option. Make each seat a root prim, and rotate them around a fixed centre. Give each seat a lookup table of position and rotation. Make one seat the master. It trasnmits to the others the index number in the lookup table it is at, each other seat then applies an offset to get it's own index and works out where it should be at. The four-arm spider can similarly listen to the master seat and adjust it's position accordingly, so it tracks the master seat. This system means that you can sit two avatars on the root prim by having two child cushion prims with sit targets, the seated avatars will therefore rotate exactly as the root prim rotates, and there is no complicated messing around with local position and rotations, all you need to do is get all seats rotating around a fixed point, (for which there is a wiki example, and staying the same relative distance away from each other.

I'm not an expert in KFM, but I do have some successful implementations of it on my island, (and a ton of failed projects stored in little boxes....) Keyframed motion in a circle or an arc seems to suffer from a lack of precision in the moving_end event, but that becomes most noticeable when you are either doing a pendulum-type swing, or want an object to reach or stop at precise locations. Unlike a train with wagons following it around a circle, your fairground ride might not look too odd with some variation in the positions of each seat, so I think it's worth you trying it. My suggestion would be to go along Innula's route, the seats being individual prims, and give each of them a pre-calculated look up table of position and rotation at various points on the circle around the central part of the ride. At each point, the look up table gives it the rotation and position deltas to apply in order to get to the next point. If necessary, the seat could also have the regional position and rotation it is supposed to have achieved at the end of the keyframed motion, and adjust it's position accordingly using SLPPF. The same precalculated table will do for all seats, they just start and stop at a different point in the table. They can then have their own target omegas to do the axial-spin

It has stopped working because it cannot now find two animations. What you could try doing is copying the c animation to a folder, renaming it first to l and copying that back into the prim, then rename it to r and copy it back, so you cve "c", "l" and "r" inside the prim to keep the script happy.

Not at all, but the only people who can tell you truly what to expect of it are the development team. Here, we're all afloat on a sea of dubious speculation.

It can be as simple as editing the boat, choosing "edit linked prims", and looking through each prim in turn until you find animations in the contents. However, simply removing them is likely to cause script errors when the script tries to play them. A better approach is to rename them, and copy in another animation or two, naming them for the renamed animations. Again, you may run into problems here if the sit position and sit rotation for the earlier animations are not the same as the replacement animations. For this reason, I recommend you rename rather than delete the original animations.

If you reduce pressure your tyres and tubes won't last as long, you really need to pump them up.

Have you tried turning off water reflections and seeing if that makes a difference? The only other thing I can think of is that you have draw-distance set very high. In a forest the surrounding objects will keep the client busy taking stock of objects around it, but on an expanse of water it might be trying to see to the very edge of the sim to build up the lists of objects it needs to try and render.

Have a look at the thread https://community.secondlife.com/t5/LSL-Scripting/Rotation-Math-Global-to-Local/td-p/2953989 on page 2 of this subforum, somebody has already asked a very similar question about global to local rotations, and also about rezzing objects which must then assume rotations dependant on the rezzer prim's rotation. Also have a look at "I...Hate...Rotations" further down the same page, because it is even more appropriate to your question. In your snippet above, by the way, you have written a vector following the PRIM_ROT_LOCAL specifier, but it should be a quaternion. The wiki reference on llEuler2Rot() will give you some pointers to the way to convert between degrees/radians and quaternions.

There is also llPushObject, but it is a bit hit-and-miss (sorry). You can specify a force as a vector, and an angular component,( which I have yet to try). In terms of precision, forget it. However, they do not need to be sitting on a prim or wearing any special attachment. What I have been able to do using it is move an avatar outside of a blue police box when they arrive inside it from a remote Tardis interior by detecting them colliding with the interior floor pad, opening the doors, applying a push in the appropriate direction to send them outside the doors, and then closing the doors. Using a value calculated from their mass times an emprically-established factor I was able to move them 2 metres, but when establishing the factor I noticed that under a certain value the push didn't move them at all, and then when they did start to move it was with a bit of a rush. Too much, and they actually went through adjacent prims. Trying to move them 1.2 metres so they were just outside the doors was impossible to achieve with any sort of repeatability. ETA I also have a memory of when first trying to use this in something else, finding that the script object doing the push has to belong to the parcel owner. I assume this is an obvious anti-misuse policy.

Have a look at the #RLV folder method, it's the only way you will be able to manipulate objects in your own inventory in such a manner.

The post immediately prior to this one mentioned that, you must change to planar mapping for the face in question, TYou will then find the H & V repeats will probably need reducing quite a lot when you apply the texture to it.

Yes, I'm seeing the chat lag and sit/stand go into the blue problems, however, you risk splitting attention away from the original post in this forum on bad lag. It's probably best to concentrate on that thread for the moment. Regarding location, BTW, I am also UK-based, but the simulators will be hosted on servers in the States, and since some of my visitors here reporting these problems are themselves logging in from the West Coast of America, I don't think it's a network issue.