Profaitchikenz Haiku

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?

Or one of his alts

For the OP, and for anybody else wishing to learn a little more about debugging scripts when all you get is the icon and a small window telling you what the error was but not where in the script it originated: The window said the error was in a call to llGetPrimitiveParams, and that the supplied parameter was invalid There were several places in the script where such a call was made. I bracketed such calls with two lines such as llOwnerSay("Query " + llList2String(Param_Names, i)); list r = llGetPrimitiveParams([j]); // What are its values? llOwnerSay("Query got " + llDumpList2String(r, ",")); These lines would then show me what particular parameter value was being supplied, and what the resulting returned string was. Since the error said an invalid parameter was being supplied I was therefore looking for an empty list on the return from the call. The particular problem area was a tricky one to debug in that it was all compressed into one line with functions called from within functions all in the return statement, so the answer was to duplicate the function return line in separate lines, thus : string osp(integer p) { llOwnerSay("Query osp " + (string) p); string answer = llDumpList2String(llGetPrimitiveParams([p]),","); llOwnerSay("Query got " + answer); return llDumpList2String(llGetPrimitiveParams([p]),","); } Which gave the output [09:02] (Unnamed): Query osp 24 [09:02] (Unnamed): Query got And the lack of any return after "got" was the giveaway This technique of homing in on areas of suspicion is fundamental to debugging scripts, and is something that I think needs to be developed by aspiring scripters even before they try to learn styles and coding formats. In this particular episode it was the particular coding style chosen by the author that made tracking don the problem particularly hard. I would urge people to try for clarity where possible. Form is all very well, but at the end of the day it is content that makes a script work, be easy to understand, and easy to adapt, debug, and use.

In fairness to the OP, these calls were buried deep in layers of surrounding functions, for example the error was initiated by string osp(integer p) {return llDumpList2String(llGetPrimitiveParams([p]),","); } which in turn was called from string param(string p , integer q) { return p + "," + osp(q); } Which was set in motion by this line sayn("// " + param( "PRIM_CAST_SHADOWS",24)); so the actual call to param was itself buried. Furthermore, the fact that the calls to llGetPrimitiveParams were theselves inside llDumpList2String which in turn was specified as the function return value made it even harder to track down. It was pure luck that I saw the PRIM_CAST_SHADOWS comment pop up just before the script error icn popped up too.

It's not an easy one: just looking in world the chat output is verbose, but the error manifests itself as a script error, and there's no immediate way to relate it to any particular line in the scrript ETA The script error is occurring during a call to function osp with an integer value of 24 , possibly PRIM_CAST_SHADOWS? Confirmed, PRIM_CAST_SHADOWS was constant 24 and is no more. The impact on the script's functionality is actually minimal anyway given that it runs from start to end. Commenting out the line that makes this call with parameter 24 will remove the script error. Thus ends today's episode of "Waking the Dead"

I have to agree with Rolig, the amount of white space and stylistic comments make this a real pig to review. I have to say that I find dredging through scripts like this that are more than ten years old a bit of a waste of time. I sometimes dream of a major data-centre fire that removes all scripts prior to 2016 plus any backups. But then, I realise, some enterprising soul is going to find them on the WayBack machine... The way to handle debugging this particular script is to have an llOwnerSay to chat out the name of the parameter from the list just prior to making one of the calls to llGetPrimitiveParams.

I quite agree, but I'm in a similar situation with some script that aren't operating as anticipated in regions where the percentage scripts run is less than 40%. I didn't expect this level of performance degradation when I wrote the scripts, and I was hopeful of Linden rectifying the situation, which hasn't happened for well over a year now. I've been experimenting to see how feasible it is to amend the scripts to try and cope with delays in things occurring but it's going to be quite a major operation. All I can say to people is, go to a private island where you can get restarts more rapidly than on mainland.

The IP-Woke brigade are out to cancel alts

They will do something if a suitable abuse-report is raised and they determine that abuse is indeed taking place. That is the only way by which they would become aware of such a situation.

Possibly we're at sixes and sevens here, my interpretation of what the OP is saying is "It's rocking fine, but it I turn it around it just snaps back to the original direction it was pointing". This leads to an interesting challenge. At present, the only way once the boat has been rezzed to align it to a different direction is to stop the script, edit it to change the rotation, and then reset the script so that it reads the new Z-rotation, but here we hit on problem. If we stop it when it is partway through a roll and a rise (oo-err missus) when we restart the script it's going to get those X and Y axis rotation as well as the vertical offset and take them as the new rezzed-rotation. We can't use moving_end to detect when we have stopped turning the boat in edit mode because there's going to be a spate of moving_end events each time it rocks, rolls and rises. The only kludge I can think of is to have a touch_event that detects if the user has touched it, and if it is in motion, returns to the no-pitch no-roll no-rise state and then stops the timer. Once the owner has re-aligned the boat, they touch it again, and this time the script does a re-read of the basic position and rotation and starts all over again. (I prefer this approach to a full script reset). I'm coming at this from a previous build of mine, the Sealey Punts that went to and fro across Lake Kness, and would be in a chaotic state after the monster from the deep had come up and swallowed punt and occupants and spat the punt back out, when in addition to rocking and pitching it had to spin slowly around before drifting back to shore. I used a simpler method then Wulfie of getting a bobbing motion and because the punts went too and from from one jetty to another didn't have to worry about the alignment until the after-belch event.

It would be a monumental task for somebody to create this many alts, but f they did, and managed to get away with it, subsequently using those alts to target an individual would be a suitable subject for an AR. However, from past experience as a land-owner plagued by a persistent alt-creator, I have to say that the victim is often being fooled into hurting themselves here with the thought of what damage the army of alts might be doing to their reputation: in all the cases I saw, those outside of the immediate drama treated the attempts by the alts to stir up trouble as exactly that, drama that had no bearing on them. My advice is to mute the alts as each new one is discovered, until the number of them reaches something like a dozen, and then raise an AR for harrassment and stalking.

If this is the case, then banning an apparent alt from land they they own isn't a violation of the ToS if they haven't made it publicly known that so-and-so and so-and-so1 have been banned because they have the same IP adddress? In which case, the item that started off the whole thread is Ok?

I might be a bit dim today because of the heat but isn't a more appropriate way to get the current Z-rotation an apply that to whatever the X and X axes rotations are? As I understand it the Z-axis should be allowed to adopt various rotations to allow different headings but it's the Y and X axes that are going to be jiggling to and fro?

Inside the touch event, Your test for light == FALSE is Ok, but then you assign Light == TRUE; It should be Light = TRUE And similarly for Light == FALSE, the assignment is incorrect. I'm not actually sure what value is gong to be assigned to Light in these two cases: I would also suggest removing the line which resets the script, it shouldn't be necessary to do that given the other lines in both the touch event and timer event.

I agree, where I re-enter after a crash is where I logged into, but things like the inventory floater that were open when I logged in from cold aren't when I relog from a crash. It's this that has got me puzzled, if you were to restart from where you were initially, then surely the open inventory floater is all part of the wake-up scenario, why isn't it restored? The other thing I recall seeing sometimes after a crash, though not always, is a brief message about clearing corrupt cache followed by all the textures apparently being refreshed quite slowly, as if they are all being downloaded yet again, despite them supposedly being in the cache, but the message is so fleeting I've never yet remembered to pay attention to the full text. This is peripherally involved with the thread topic in that a large chunk of one's inventory is of course held in cache.

Unless, of course, the receiving region needs to be told things about the incoming avatars attachments, which are obviously all in inventory, so it's just possibly that the entire inventory gets loaded by the receiving region? This thread has got me mulling over a few things that have been niggling me lately, most notably, when you have a TP-failure and crash to desktop, before you crashed, your inventory floater was open because you had been selecting and clicking on an item in it, when you log your way back into the world all bleary-eyed, the inventory floater isn't open, it's been snuffed, but when you successfully TP or log in from cold, the inventory floater is usually open. So what is it about a TP-fail that shuts the inventory folder? (The other item that is regularly snuffed is the mini-map)

I think it would be perfectly good enough if you used the beam and waterline length as multipliers, so the amount of roll is proportional to the beam/length. SL is an approximation at best. But only the OP can work out which is beam and which is length axes, as we cannot see the build details. Regarding your simple wave-function, I gotta ask, is the cat alive or dead?