Profaitchikenz Haiku

If your code in state_entry resets such variables to null then each time you change states the variable(s) will again be set to null, thus making them worthless as globals. The way to deal with this is to have a variable at the top of the script that starts off set to 0, and state_entry checks this variable, if it finds it set to 0 it then calls a function to initialise any globals and sets this variable to 1, then any future state changes will interrogate this variable in state_entry and not call the initialisations.

This is particularly evident when using keyframe motion, as Molly said, rounding errors accumulating and moving_end lapses both cause this drift. It is particularly noticeable in regions where the %script run figure is 40% or less. My own workaround is to keep a record of the centre height or rotation angle and use a counter : every 20 movements or swings, when it has returned to what is supposed to be the centre, I will issue a llSetPos or llSetRot to actually enforce that position. The counter is then reset and the slow creep away begins once more. I find myself being forced reluctantly into a slow spiral downwards: adding defensive programming to try and cope with the region performance issues is actually making the problem worse in that it is yet more code to further load the region, and yet, there is no alternative.

That's probably more the result of draw-distance. If you have sculpted trees or rocks or similar on your skybox, the shadow they cast is not the same as their visible shape. I suggest you record the position and rotation of all objects above the ground and then take them back into inventory until the shadows vanish. If you don't want to take them back you can obviously just lower then down to the ground, but then they might get in the way of the shadows and prevent you seeing when they vanish. If your parcel is big enough then another option is to move things to one side or the other and see which things affect the position of the shadows that way.

When you reset the script it will read the current rotation of the object to get the starting point, and if you stopped it while it was in mid-rock, it will take that angle as the normal angle and then start rocking it side to side. You have to first remove any X and Y rotations that have been added by the oscillatory part of the script (and it isn't as simple as just setting the X and Y rotations to Zero, your object might be a strange mesh build that has to be rotated on the X or Y axis to assume a normal visible appearance).

Have you tried "draw distance stepping" in one of the FS extras preferences tabs? Also, does reducing your draw distance to 96m make any change? 208 means it's going to be trying to fill up an awful lot of surfaces all at once.

Coming from another thread, there used to be a way of doing this by a prim parameter PRIM_CAST_SHADOWS, now obsolete. However, that would not be sufficient, as in addition to turning off the shadow-casting ability for the skybox, things on it such as a hacienda would then start casting a shadow that had been previously occluded by the skybox, and so on... I think I can see now why this property was removed. It is simpler for the region to treat every object on it in the same way. One suggestion I have though, if you set the skybox to be totally transparent, does it still cat a shadow? If not, then you could just change it's alpha state depending on whether somebody was on the skybox or near enough to need to see it, or not.

Yes, it's the simplest solution. There is one slight complication as I mentioned in a post above. When you touch it and the motion stops, you must reset any small rotations or position variations, and then make the rotation, before touching it and starting again. I suggest you post what you already have working and we can then suggest how to add such a touch event handler to it. In passing, Molly's suggestion of using keyframed motion for this is both the most elegant and the most likely to give best visual effects, but from what you have indicated is your level of scripting knowledge, not the best one the start off with, I suggest you become comfortable with basic rotation and position manipulation first and then progress to the smooth stuff when you're happy.

I would start off with "a chemical being" which puts us into the class of animals in terms of basic constitution, after which comes "a communicating chemical being" to partially differentiate us from other animals, but since animals obviously do communicate something, we are now into the territory that David Chalmers said was characterised by "The Hard Question", and from now on it's a problem with using words that have many different meanings and values. Meanings are somewhat personal, words can be accidentally or deliberately misconstrued, logic is as fallible as mathematics - (See Godel). Some problems may never be solved, some questions may never be answered, some posts may run for ever without a resolution acceptable to all. You might as well ask how many angels can dance on the head of a pn, we're in much the same territory.

What is being suggested is not to explicitly move the boat up and down or rock it from side to side, but to set it to be a physical object and allow such region forces as the wind to disturb it. Because such forces would only move it around on the level of the water, some additional random impulses would have to be applied to make it rock and bob. My past experiences with this were that it's very difficult t get subtle motions like this, the object either doesn't visibly move at all, or else it starts leaping everywhere like a gazelle with piles.

Yes, it still does in exceptional circumstances when mesh won't load.

So if I'm following you, the viewer receives data for object "blah" size x,y,z at position x,y,x rotation x,y,z,s and while it's waiting for the shape data it throws up a default cube shape (or sphere if it's a sculpt), and that's the supposed companion prim, the best-guess in order to position the item whilst waiting for vertex data?

Just a guess, but maybe you're seeing the lowest LOD model or physics shape first, and then the vertices of the mesh object come into view? You can see a similar sort of thing with sculpts in a region that is running a bit slow, a sphere appears and then the actual shape.

Before lockdown I would have said eats meats and leaves

Something for you to bear in mind: as given above the code won't work because when you detect plate 1 being collided with, you replace gState(1)'s value to show is set. But list elements start from 0, and since you don't have a plate named "0" you will never change the first element of gState from 0 to 1. therefore, if you have 9 plates named 1 to 9, and nine elements in the list, the element that you must change from 0 to 1 for plate "n" is actually n - 1, so for plate 1 you do llListReplaceList(gState, [1], 0, 0) and for plate 2 llListReplaceList(gState, [1], 1, 1) Your naming convention does allow you to do this: integer index = (string) plate; // so plate "2" generates integer 2 gState = llListReplaceList(gState, [1], index -1, index - 1); // replaces the correct list element 0 to 8 // corresponding to plate "1" to "9" But I'd suggest you leave that for later and for now just manually add the numbers in, remembering to subract 1 when accessing the list locations

Try this as a starting point, it's very simplistic and requires you to add in all the remaining plates, sorry about the tabbing but Geany doesn't work nicely with the forum code And it hasn't been tested inworld so expect syntax errors list gState = [0,0,0,0,0,0,0,0,0]; default { state_entry() { llSetTimerEvent(0.0); } collision_start(integer num) { integer ii; string plate; if( llListFindList(gState, [1]) < 0) // we've only just begun { llSetTimerEvent(30.0); } for( ii = 0; ii < num; ii++) { plate = llGetLinkName(llDetectedLinkNumber(ii)); if (plate == "1") // plate name check { // do something llSay(0, "plate number 1 pressed"); gState = llListReplaceList(gState,[1],1,1); } // else if( plate == "2") //add in all the other plates here in a similar manner } if(llListFindList(gState, [0]) < 0) { // do MAIN_ACTION(); llSetTimerEvent(0.0); llSay(0, "all plates are pressed"); } } timer() { llSetTimerEvent(0.0); llSay(0, "Bad luck, move faster next time"); // and reset the script to have another go } }

Agreed, and agreed. So the list recording which plates have been touched needs to be a global llMinEventDelay is serving no purpose and may even be counter-productive Collision events are to be expected to occur either singly or perhaps two at a time There needs to be a finite time from the first plate collision within which the remaining plates need to be collided with, if exceeded then reset everything and start again Looking back up though, with what you and I have provided, it's all there, it just needs re-arranging. ETA Just thinking, there is scope for this idea to become a general-purpose puzzle routine: for example instead of simply activating all plates to get them on for the action to occur, you might have to activate them individually in a specific order, or else they are set to glow individually and you have to activate the one that has just lit up. Or you could make a hop-scotch game with it....

I'm still a little perplexed as to how an avatar is going to collide with 9 child-prims in a short enough space of time to generate 9 collision_start events that can be read in a single instance of the collision event. As soon as the first collision occurs an event will be queued, then another and another, and so on, but they are most likely to be either single collisions or just airs, remember we're talking milliseconds here. The use of llMinEventDelay(0.2) is going to further space out the time between subsequent collisions being queued. I could understand it better if it worked like this: no collision events have occurred, no children are glowing. A collision occurs, detected as being from one of the plates (possibly more than one) The list entries for the relevant plates are set to 1 and the plates in question set glowing. A test is made to see if all 9 plates have been hit. A timer is started, let's say 5 seconds. Further collision events are raised and when found to be from plates, the list entries are amended, the plates set to glow, the test foor all plates hit made, and the timer reset again to say 5 seconds If all 9 plates are found to have been touched, the timer is cleared, the action takes place, and then everything is reset to the basic condition. If on the other hand the timer event occurs, then not enough plates were touched and everything is cleared ready for the next round. I cannot see that it is going to be possible for an avatar to touch all child plates quickly enough for all 9 collision events to v detected in the single (first) event resutling from the first collision.

Ah, so that's how I get my first warning badge? Push the envelope

With the additional hint that more than five could incur a charge, so I find the premise that somebody can have 50+ alts a bit ludicrous, I mean, with LL always looking to increase the revenue, they could have just gone around surcharging the over-5 alts and left us premium members with our old payment instead of ramping it up.

I had read your post as being your RL car in your RL-driveway and experienced a brief spell of cognitive dissonance.

Have you tested it going in via VPN or perhps even Tor?

No, the problems predated the move, and in fact when asking about possible fixes, the reply from Lindens at the Server User Group meeting often took the form that it would be easier to address after the move to the cloud. There was also hope held out that the upscaling from moving to more modern servers might well improve things to. I believed them, because there was no other realistic option. With the exception of the Beta Grid I can't think of anything that the cloud move could be blamed for.

Looks good, but should there be code to implement not adding in the same link number more than once? (Which I assume will be a simple bitwise & to see if that power of 2 is already set)

Is this a 5-minute ignore or the full half-hour?

I find that CoolVlViewer always gives much louder wind noise than other viewers, if you turn around the sounds vary in volume quite considerably.