Profaitchikenz Haiku

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?

If it gives Beq any pointers, I have bouts of intermittent problems saving scripts with Singularity, where I will get an error "unable to upload the asset because the server is experiencing technical difficulties". Almost always making a non-essential edit such as adding a space to the end of the line and re-saving works. Singularity is notorious for using older error codes (wire chewed by rabbit) so it's possible it's the same error that Rasterscan sees but with a different reason. It is usually specific to a particular region and time, it will persist for an hour, but can be cured by logging out and back in again, so it's more the connection with the region than the actual region itself.

The universe never ceases to amaze me, but maybe this is good. To paraphrase a hollywood star, "If you wake up in the morning and the universe doesn't amaze you, you died in the night" This does actually make some sense to me: I remember asking Oz at the server user group meeting once why I should get chat-lag in busy areas and why trying to cursor back to correct typo should make it dramatically worse. His reply was that all the typing and shown text is graphics-intensive in the same way that rendering any other visible item on the screen is. I had been expecting that chat would just be unicode bytes thrown to and fro, not bit-mapped to the screen. So if you divide the viewer operations into visible and under-the-hood, anything under the hood must take place at the expense of the visible.

There is an SL convention that vectors and quaternions (rotations) use the implicit order X Y Z in their arguments. In the LSL portal this is probably buried in the section "Types" This is most likely because you are either copying a snippet (ie an incomplete script) or you have missed a bracket at the very end of a multi-line chunk that is in a window with vertical scroll bars For the first, get into the habit of viewing the script first of all as chunk, there must be a "default" in the body of text, it must have an opening "{" and at the end of all the events a closing "}" When copying a script from the wiki, position the cursor at the very top of the code, then use Ctrl-A to select everything including any portions hidden by the limited extents of the window. I suspect Wulfie is allowing the boat to roll from side to side (possibly the X axis) and rock from stem to stern (possibly the Y axis), which is OK for a coracle or multi-hull but not for a classic displacement hull. My feeling is that the stem-to-stern motion when the boat is not underway should be much less than the side to side rolling , perhaps a fifth (if that).of the side to side. try reducing the amount of tilt in one of the two axes ( use tilt * 0.2) and seeing what the effect is. A more precise determination is to rezz the boat, edit it, and see which way the axes are. If the X-axis (red) goes from stern to stem then this is the axis around which the boat will roll from side to side,

Create a new script. This will give you the basic default state script with a touch event. Add a second event inside the default, just below the touch_start, called timer. Put Wulfie's snippet inside the timer event. inside state entry, add a line llSetTimerEvent(0.5); The timer will activate very half second, giving a very slow up and down motion (note, not tested in-world ) default { state_entry() { llSetTimerEvent(0.5); } touch_start... { } timer { // put Wulfie's snippet in here } } To ve very clever, you can then create a global variable called something like rock, initially set to 1. When you touch the prim, if rock ==1 set the timer ev

You put the global variables in the timer section so they are constantly being re-initialised once a second. The timer section needs to update the rotation and then adjust the beam by calling setPrimitiveParams, but I don't see an option in the code to repeatedly increase the rotation amount

Personally, I think people panic far too much about the possibility of griefing. Yes, it's annoying when a major attack takes place, but anybody worth their salt can mute and eject trouble-makers as soon as it's obvious what's going on. Blanket-bans of new avatars is a knee-jerk reaction and might be having undesirable consequences.

He seemed to me to be getting on quite well with finding his way around and making things work, I wasn't sure if he was looking for voice chat when he said he wanted somebody to talk with, but this was definitely a lost customer simply because the destinations guide failed completely, the best guess it made sent him to places that kick newbies. If there had been a hang-out category prominently in the list I think he might have had more luck. Sadly though, the closest he found was SL's new niche, music with pictures. London City is good, but slow, and I don't know if there's voice there much, as I'm always mic-off when I wander.

So an interim solution would be to rent parcels on a private island where you at least have a chance of persuading the estate management team to restart? It's actually quite a quick process so provided there aren't a dozen other inhabitants there to protest the interruption you've a good chance of getting a restart when you need it. I moved off such a private island and onto mainland, not realising how much harder it can be to persuade somebody at Linden to restart mainland. Unfortunately I love where I am too much to go back to a private island now.

I agree, it was appalling that he got thrown out of most of the places for being new, it strikes me that places implementing minimum age levels shouldn't be allowed to advertise themselves in areas where newcomers will be arriving. I thought he did pretty well with moving around and learning the menus, suggesting SL isn't such a bad interface as it's been made out to be.