Profaitchikenz Haiku

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.

Yes it is!

Although the forums.... well, that' another matter.

They like an audience so you'll be more likely to see them where there's a crowd, and not just that, a crowd that's going to react. Also, from looking at some of the youchoob videos, they like to voice, so if you're not on a voice-enabled parcel, don't expect to be bothered too much, if at all. Prim-rezzing leaves behind traces that identify them, voice, unlike IM and chat, isn't so easy to log. There have been some excellent trolls in the past, Lavender Storydel tops the list as far as I go, but I think they've got bored with the same old reaction that they started getting and went to look for more interesting venues.

I haven't written you an entire script, you have to add the code for working out if whichChild(ii) is a gate and if so, which gate, and then setting the appropriate entry in the list. Until you add that, nothing is going to happen.

This might negatively impact the number of registered/concurrent SL users, and next thing the "SL-is-doomed" greek chorus will be in full song.

Comparing lists is a tricky one, but from the wiki Equality test on lists does not compare contents, only the length. Hence: if ( [1,2,3,4] == [0,0,0,0] ) Always returns true, therefore when you try and compare your list gState against a list of the same number of elements it will always return true. You either have to do an element by element comparison to determine if two lists have identical content, or you have to adopt the tactic I showed above, to look for the presence of an element within the list that implies a desired result has not been achieved, in this case the presence of any 0 means the list is not all 1.

First thing: You are initialising the list to all zeros each time a collision_start begins, but then you are only testing for one of the multiple possible collisions. collision_start(integer num) { list gstate = [0,0.... integer ii; integer whichChild; for( ii = 0; ii< num; ii++) { whichChild = llDetectedLinkNum(ii); // and update the list if it's a plate } // now see how many of the list are still unset if( llListFindList(gstate, [0]) == -1) { // there are no un-collided plates, so let's do stuff } } I've done this the opposite way round to Quistessa's proposal partly because I'm bloody-minded but also because it might be simpler for you to follow the logic, her "while(~--num)" is more elegant but perhaps harder to understand. I also have some reservations about all the collisions occurring within the same frame such that you will be able to get them in a single event, I believe that the collisions are going to be spread over several milliseconds and so several collision_start events will be experienced before the avatar colliding has met all the plates.

There is a quick and dirty way of doing it: using link messages to send a 1 when collision_start occurs and -1 when collision_end occurs. Add up the 1s and -1s, when all the plates are recording a collision in progress your total will be the number of pressure plates. It will drop back to 0 when no plates are in the process of being collided with, and will be somewhere between 1 and the total number of plates when a few are being activated.

Stepped on at the same time, or all of them have been momentarily stepped on within a certain time?