Profaitchikenz Haiku

changed(integer change) { if( change & CHANGED_LINK) { key avatar = llAvatarOnSitTarget(); if( avatar != NULL_KEY) { llTextBox(avatar, "Type in your wishes", channel); // you will need to have pre-defined channel } else { // the avatar previously sitting has just this minute leeft // do your tifyups here } } }

Fascinating, I knew states grabbed chunks of memory but didn't realise that functions were granular in that way. For the OP, simplicity is the key, and that doesn't mean factorising out the code, sometimes linear-flow code with if-else or even gotos often works just as well, the main criteria from your perspective is, can you keep track of your own code? The main advantage to several scripts is that developing and testing can be a lot easier with smaller chunks and a few test-harnesses, once working, you can combine them into a single script.

I'd suggest you open a new post, this has the potential to be both interesting and useful. I wasn't able to play with the script and see what it could do, but Rolig spotted that very quickly. There are other minds here as well that will see very quickly what might be the stumbling blocks or what is a better way to do something. I'd suggest that before opening a new topic, add a comment block to your code explaining what it is you are trying to do in functional terms, such as the need for two distinct faces, and the need for it to be owner-only. Rather than repeat what you have already posted ere, begin the new topic with your current state, what the code is, what errors or non-behaviours you are experiencing.

Good to see other peoples methods. I've used several such ones in the past, but the thing I was aiming at was the simplest possible system for newcomers so they can start debugging at once without having to look up several LSL wiki pages first. Of the ideas so far, Molly's is perhaps the simplest since it only requires a newcomer to understand two functions, one of which they might already know and it's dead simple (llOwnerSay()), and one which is a bit more complicated but equally, simple to understand. Possibly below it you could show them the equivalent method of casting the individual items to a string, which is itself a vital debugging technique. Innula's method is both technically superior and 'proper' in terms of the environment we live in, but I think it's forcing too many unknowns on a fresh starter, likewise Lucia's techniques (which I have actually used quite a bit) are also expecting a greater degree of knowledge than could be reasonably expected. Once they've got the basics, subsequent additions to that topic could explain to them the Debug channel, controlling behaviour from the object description, and how bitwise fields work. What I think we need for a post to refer newcomers to is an example script that shows how to debug several of the typical events plus a user-defined function. It wants to be as simple and straightforward as possible, but then we could probably add to the thread with further examples showing the more complex methods.

It was bath time, I had no choice but to go. Interesting though to see what the global touched was for.

I'll get me coat ... It's very annoying having the machine on which I browse the forums not being the machine on which I log n, stops me from doing such explorattions. Sounds very very useful, though.

Well you're here now, so might as well continue. You've made a start in the touch_start with the check for llDetectedKey being llGetOwner, make sure the braces after that check encloses all the actual code the follows down to the end of the touch_start event. The do the same in the touch_end event if you plan on keeping it, the idea is the same, as soon as theres a touch, check the detected key against the owner, make sure that the braces then enclose all the stuff its meant to be doing. touch_start() or touch_end() { if( llDetectedKey(0) == llGetOwner() { // this brace matches up with } // this brace to group all the coe between them together }

It's only obvious when you already know it And yes, I think we could get some mileage out of showing a script with several events in them and diagnostics to illustrate where to put debug messages and what sort of things to output. So a worked example might be the best approach?

I can't see any real advantage to your splitting the code between touch_start and touch_end, I would suggest doing everything inside one event, probably touch_end. Unless you're expecting people to be clicking and holding the mouse for any length of time the two events are going to be occurring very close together. Also, for debugging, it's a lot easier for you to be working on a single event. Regarding bracket count, if it's compiling without errors there are a balanced number of braces, BUT If you've put some things inside a brace they become local to that block. In your code, touch_start only does something if its the owner touching, but touch_end then does very much the same regardless of who it was that clicked. So in your code, because the assignment of touched= false only happens inside a set of braces after testing for the owner having touched it, no change will take place to it's value when anybody else touches it. I know that touched is actually not used anywhere else in the code at present, but this is to illustrate a point about the braces. A quick way to debug this would be to alter the CMD_CH in new_hsl_colour to 0 so you would see in local chat exactly what was detected and how many times how close together. (others may mutter abut resurrecting an old thread and not actually following on from the topic but I'm wearing my nice face this month)

Something we are saying to novice scripters over and over again is to "put some llOwnerSay() messages in your code to try and see what is actually happening". Scattering llOwnerSay() messages through the code helps solve some problems but then introduces others: You have to clean up the statements afterwards There might also be some genuine llOwnerSay() statements that need to remain. You might clean up the debug statements too soon and wish you'd hung unto them for just a bit more testing I am starting to think that we are adding to their learning load here by forcing them to think out how to actually do this. I am thinking of suggesting a systematic method we could refer them to that will give actual examples and help The approach I have come to use works like this: At the very top of the script, define a global integer debug = 1; // could be 0 if you also have a listen statement to toggle in the area where functions are being declared, declare Dout( string tellMeAbouIt) { if(debug) llOwnerSay(tellMeAboutIt); } And then through the code, wherever a diagnostic is needed, add single statements of the form Dout("In function (name) At point " + (string) llGetPos() + " " + (string) llGetRot() ); We need to stress here that anything can be cast to a string in LSL, (except the name of the function/state/event the code is currently in) These messages are easily identifiable so cleaning up is quick and easy The debug can also be turned on and off if there is a listen event using if( msg == "debug") debug = ~debug; This allows some diagnostic capability to be retained into early production code by initialising debug to 0 instead of 1 and then turning it on if required I don't know if this post belongs in the LSL Library sub-forum, or if it is worth some of us working it over and making it a sticky. Thoughts welcomed. Practical example: // debugging a listen event listen(integer ch, string name, key id, string msg) { Dout("Listen on channel " + (string) ch + " heard name " + name + " (" + (string) id + ") say >" + msg + "<"); // and now do stuff }

This seems to be a result of having Advanced Lighting Mode on, you can un-check it and hings will brighten up a bit but then you'll lost the bump and specular maps.

/me flicks his hand back over his head and goes "Whoosh"

I think thy're the first and last elements of each sub-list? If so they allow set-inclusion and set-overlap which is quit a neat idea. From memory a sparse array had an index that recorded the array index start for each row. There was no need to record the extent because that was obtained by the difference between it and the next row start index value.

That's pretty close to how sparse arrays were set up. I used them on systems that solved simultaneous Linear equations, several thousand of them at a go. The idea worked because once all the equations had been set up in the arrays, no further addiions or deletions were needed, if it had been otherwise then I suspect the system would have been to slow. As it was, on DEC Alphas, Solaris machines and HPux boxe it was a three-to-four hour run.

People who KNOW they're right

That forum-mindset is prevalent everywhere, and for twenty years I have seen group after group around the net decline because the hard core of existing posters have snapped and snarled at newcomers for breaches of etiquette, failure to google for help before asking the forum, and failure to instantly adopt the cosiness of the group mind. I have seen these forums in many diverse areas dwindle as the older regulars died or drifted away and insufficient newcomers stepped in to fill the gaps. It''s no fun saying "I told you so" when those you told aren't there anymore This forum, I am glad to say, has managed to avoid that dead end, and it is indeed due to the regulars making a distinct effort to accept a more diverse range of people. The payback is a lot of interesting and challenging questions, and new insights either from the newcomers, or because of them asking questions that take us outside of our usual boundaries. I still agree that simply posting a full script in response to a question is a mistake, it doesn't encourage the newcomers to learn, it is often too specific to illustrate more general points, and it obviously robs some scripters of revenue. My approach for years has been that I will always those who will try and help themselves.

Lists within lists is just about possible in LSL to one extra level, although horrible inefficient. Consider a list of items describing the size, local position and local rotation of a child prim in a linkset list details = [<size>,<lPos>,<lrot>]; dump that list to a string using the pipe character as the separator string details_str = ["<size>|<lPos>|<lRot>"]; Now make up a list of such strings for every child in the linkset. List linksetDetails = [str1, str2,...]; To access the contents, read a particular string from the list, then either parse back to a list or simply slice substrings using the separator character With numerical details it's straightforward, but if you start including strings you have to be sure that the actual strings will never contain your separator, or indeed a comma. It's grossly inefficient because each character in the list is going to require 2 bytes .

This might need further work as I tried the url Molly typed above into the Pi400 Chromium web browser out of curiosity, and it played at once, but when I had earlier tried it in the Firefox browser on the Windows machine it came up with "content not available in the EU" report. Qie was able to play it, I wasn't able to play it all all in the first few regions, it was only in the last sandbox that it actually opened up and gave me the error popups. It's looking like it's not just the url but the region in which the request is being made, as well as the type of browser/requesting app. ETA Tested, ( the URL now plays in the Firefox browser without the location error I got earlier.) The following viewers played the url with no issues Catznip R12.3 Firestorm 64531 Singlarity Beta 8419 SecondLife Performance viewer 564530 But... The latest Linden viewer 564172 gave the crash. The details of the error box that I forgot to expand earlier are Problem signature: Problem Event Name: APPCRASH Application Name: SLPlugin.exe Application Version: 0.0.0.0 Application Timestamp: 614c5aeb Fault Module Name: libvlc.dll Fault Module Version: 3.0.9.2 Fault Module Timestamp: 002000a9 Exception Code: 40000015 Exception Offset: 000000000000b918 OS Version: 6.1.7601.2.1.0.256.48 Locale ID: 2057 Additional Information 1: 91eb Additional Information 2: 91eb63789ceb1b042f28b3e946a956ff Additional Information 3: ad97 Additional Information 4: ad975bb7a47d10ab9caac2b5eba6e3c1 This does rather point the finger at something in the Linden code. https://jira.secondlife.com/browse/BUG-231356

Yes, but from my Fortran days I would immediately look at sparse arrays as the best solution to this. In effect they were lists of lists.

^^^ This. It's a nice little compact language suitable for newcomers to learn by reading examples and doing. Adding to it would just increase the swirl of names before a beginners' eyes. Regarding structs, list come close but obviously fail on both the ability to include list within lists, and the ability to either have pointers to other lists or pointers to function addresses. But in all of my time here, I've never yet threw up my hands and said "this language is impossible to work with". But then, I grew up programming on machines where 16K of working set memory was generous, and most variable or procedure names were limited to 6 characters. Looking through some C# code I got the impression that the names of many of the functions had more characters in them then there were characters in the actual body of the code.

So we finally managed to reproduce the error on LL 564172, and it seems it is because the media requested to be streamed was not allowed in my geograaphical area. Anybody suggest which Linden we refer this to?

I just IMed you inworld to come and try for myself, but you were offline, and then I noticed my official update was to a lower number than yours

I've been running the perrformance improvement viewer, I turned on media and gallivanted around but saw no errors. I switched back to the officious official vewer which upgraded to 564172, and went round, again seeing no errors. I'm seeing what Qie's seeing, apparently Ok. Is this possibly something parcel/url specific?

Curious to know if it's just the LL viewer doing this or if any TPVs also do it? I can't test it because I have parcel media disabled.

Hmm, every time I visit your cafe, the NPCs come running out to greet me but when they see who it is, they turn and run away as fast as possible. They seem to know exactly how to do it @)