Jump to content

PeterCanessa Oh

  • Posts

  • Joined

  • Last visited

Everything posted by PeterCanessa Oh

  1. Plus the costs for your legal people - and theirs if you lose. Don't forget those. (I was answering "what can we do", not necessarily saying it was a good thing to do ^^)
  2. Elizabeth II, Queen of Britain, etc. etc. was a truck driver/mechanic during WWII. Girls should stick to programming though, otherwise they might start requiring me to go out and get messy too ^^.
  3. Contact a legal advisor Have them request the RL information for your 'former' friend from LL Take her to RL court
  4. While you are right "as far as it goes" my example script is usually part of a more elaborate dance. It might be necessary to perform some operation as each person is removed from the list, for instance. One fundamental difference is that my version sets the timer() delay to fire when the next 'job' is due ("llSetTimerEvent(llGetUnixTime() - llList2Integer(Pending, 0));") rather than simply waiting the maximum amount after each touch - which could result in slow responders being given more time than they 'deserve' ^^ Yours is much the simpler and to be preferred for that in most cases. Mine usually has a stride 3 or 4 Pending list with job-codes, repeat times, rescheduling and reodering. It's about twice the size just for 'infrastructure' but it makes multiplexing the timer pretty easy. If you need that sort of thing you might as well use it for the parts of a script that don't really - such as removing lazy avatars from a listen list :-)
  5. Oooh, you aren't the only one that gets mad at comments like that Steph. We also appreciate that you're asking "how do I start to understand all this" from a general perspective and hope that other people will get something from it too. You, unlike many other people, have the self-confidence to know you can understand this, given time and practice and the willingness to ask questions when you don't. "The only stupid question is the one you don't ask" - too many people are too scared/shy to look stupid by asking so they stay stupid (uneducated really) in silence ^^. We were all in the same position when we started and we all had to work hard(ish) to understand this gibberish before we 'got it'; some never really do. As you've found already though there are usually several ways to achieve the same result and no total agreement about which is best. YOU are writing YOUR scripts; choose the alternative that YOU are most comfortable with, but try to understand the alternative(s) too. Most of us would admit that if we look at programs we wrote several years ago we often want to scream at ourselves "why did you do it that way!" - not only does everyone have their own style but each person's preferences change over time as they appreciate other people's views more, or just meet different circumstances that benefit from a different approach. The point of the obfuscated code is that no-one can understand it! The contest started as a sort of joke, pointing out where people had made programs that were unmaintainable - if they had any errors or lack of efficiency then tough, no-one could read and understand them in order to fix them. Obfuscated code is the "what to avoid" of my "clear writing style". These are the sorts of games programmers play. There are many - hundreds or thousands of - different programming languages too, some invented just to be 'odd'. Such 'esoteric languages (http://esolangs.org/wiki/Main_Page) are another programmer's game but migh simply be confusing to look at - some are designed to be! I do like reMorse, however, in which all the commands are like Morse codes; that is everything consists of dots, dashes and spaces, no real words at all ^^ ---------------------------- Now to get mad (history of computers): "Girls should stick to makeup and cooking" - the first recognised 'programmable computer' is probably Charles Babbage's Analytical Engine (1837). The first known program, written by the WOMAN Ada Lovelace, would have worked except that the MAN's machine didn't (it was just too hard to build). Next big advances were probably 100 years later, during the second World War, when MEN designed and built the first electro-mechanical computers such as Colossus at Bletchley Park. All their hard work and ingenuity went into that - it was almost exclusively WOMEN that programmed the things! (Using switches, cables and dials). The WOMAN Grace Hopper invented programming languages. Such a bald statement probably isn't totally true, since such things aren't done in isolation. Nevertheless Grace Hopper is THE programmers' icon (unlike, say, Alan Turing whom the press always mention). 'In 1952 she had an operational compiler. "Nobody believed that," she said. "I had a running compiler and nobody would touch it. They told me computers could only do arithmetic."' (the wit and wisdom of Grace Hopper). She died in 1992 and was an inspirational speaker, fascinating 'guiding light' and, generally, pretty amazing. The short version is this: men invented ovens and told women to do the cooking. Women made better ovens that were so good even men could use them. ------------------------------ Programming languages: Low-level: Low-level 'languages' are all about directly programming the machine itself. They are a lot of work for people but easy for the computer. i) machine code - lots and lots of 0's and 1's, switches on and off, plugs in or out, etc. - you can't do it without making mistakes but that's all there was when the machines were first built. No-one programs in machine code if they can help it although it's the only thing the computer itself recognises. ii) assembler - commands and variables have names which directly correspond to the physical machine's (CPUs) construction and memory addresses. Names tend to be a bit cryptic (DJNZ R0 LP = "Decrement and Jump if Not Zero" from my early (8052) days) but you can write anything in assembler. The only people that do, usually, are those that are writing drivers for new hardware or somesuch where there isn't an available high-level alternative. Assembler is probably the most powerful way to program a computer reliably, since there's nothing else "in the way". The big drawback (apart from the effort!) is that the programs will usually only work on one type of machine because others will have been built differently. High-level: High-level languages try to let people write in "something like" natural language. They are easier for people but require an interpreter or compiler program to translate the 'source code' into machine code before the computer can execute it. i) compiled - when you compile (just 'save' in LSL) your program the compiler-program reads through it all and works out which machine-code instructions will do the same thing - "while(--Counter)" may well become "DJNZ E0 LP" in assembler and whatever actual switch-settings that equates to in machine-code. It usually requires several to many assembler/machine-code instructions to match each high-level command. Aside from reporting errors in your source code the compiler creates a new (machine-code) file that the computer can execute directly*. Unless you make changes to your script the source code file is not needed again. ii) interpreted - an interpreter does much the same job as a compiler but it does it every time you run your script, therefore the source code IS needed every time. Compiled programs are generally faster than interpreted ones (because the translation work has already been done) but are somewhat less flexible (because their machine-code will be specific to a type of machine). The arguments are a bit arcane but interpreters have come into fashion and faded again several times. Optimisation: What to do if you want your program, written in a high-level language, run more efficiently. i) know your compiler/interpreter - the biggest influence on how well a program runs may well be how good the generated machine-code version of it is. "for(i=0; i<1000; i++){// Do nothing}" is a loop that does nothing 1,000 times. A simple interpreter will dutifully read this line, translate it, keep incrementing the counter and will doing nothing - 1,000 times. A stupid compiler will produce the same machine-code but only has to do the translation once. Cleverer implementations will work out that doing nothing 1,000 times is the same as doing nothing once and, in fact, no machine-code is needed at all. In other, more common, cases "Num = Num + 1", "Num += 1" and "Num++" may result in different machine-code even though they do the same thing. Unfortunately the compilers for LSL are on LL's servers and we don't know which things they are good at and which they aren't, nor can we do anything about it, ii) inline function code - self-contained functions make it easier to read and maintain a program but there is a computer cost. Every time a function is 'called' the computer has to make a note of where it was, create copies of the parameters being passed to the function, do the work, tidy up and then go back to where it was. That all takes time and memory, so writing-out the code 'in line' with the other instructions, instead of in its own function, can improve performance at the cost of maintainability. iii) generally, make sure your program is only doing what it needs to. This might seem obvious but when you're patching-together different scripts and adding and editing over and over again it's fairly easy to find, for instance, that your script stops to re-read the configuration notecard every now and again. Getting rid of such logic errors is the reason for insisting on readability and maintainability - if you can't work out what it does you won't know if it's doing it sensibly. [*@ professionals: I realise that this explanation of compilers is not strictly true of JIT, .Net, Mono, etc. but it's confusing enough as it is - and only of specialist interest since we can't do anything about it].
  6. Ah, no, sorry you're on the wrong track. Apart from anything else for the script to work it needs __ to be initialised and _ populated in other events. This is just the final step of what the OP concerned was asking for. This is not meant to be an exercise, I was just thinking steph might like to see some obfuscated code. Perhaps I should have just posted the link to http://www.ioccc.org/
  7. I did say "mildly" obfuscated. Apart from the fun it does demonstrate why good variable names are important though. While you could replace those - what would you replace them with? LOTS of work to make it maintainable again.
  8. Just for fun you might like to look at code obfuscation some time (or not!) ^^ Here is a mildly obfuscated version of a script I posted here some months ago: list _;integer __;default{ touch_end(integer HowMany){ if((llDetectedKey(0) == llGetOwner()) && (__ > 0)){ integer ___; integer ____; integer _____ = (integer) (llFrand((float) __) + 1); string ______; while(_____ > ___){ ___ += llList2Integer(_, ____); ____ += 2; } ______ = llKey2Name(llList2Key(_, --____)); if("" == ______){ ______ = "not here"; } llSay(0, "The winner is " + ______); } }}
  9. Lindal's answer doesn't quite go far enough. Infringing their rights is not the end of the story. Anyone using a copyrighted image without permission is breaking the law. This applies even if they aren't "distributing" the content but simply using it for themselves.
  10. FWIW I quite often use a timed 'job queue' for various things. My preferred method for listening to several people uses that: integer Channel = -10; // The listen channelinteger Listener = 0; // The listen handlelist Pending; // Stride 2, time-due and avatar keyinteger PendingStride = 2; // (see - I told you)integer Wait = 30; // Maximum time to wait for each avatardefault{ listen(integer ChannelIn, string FromName, key FromID, string Message){ integer Index = llListFindList(Pending, [FromID]); if(Index != -1){ Pending = llDeleteSubList(Pending, --Index, Index + (PendingStride - 1)); } } timer(){ llSetTimerEvent(0.0); if(llGetListLength(Pending)){ integer Drop = -PendingStride; while(Drop < llGetListLength(Pending)){ if(llList2Integer(Pending, Drop + PendingStride) <= llGetUnixTime()){ Drop += PendingStride; } } if(Drop > -1){ Pending = llDeleteSubList(Pending, 0, Drop + (PendingStride - 1)); } } if(llGetListLength(Pending)){ if(Listener == 0){ Listener = llListen(Channel, "", "", ""); } llSetTimerEvent(llGetUnixTime() - llList2Integer(Pending, 0)); }else if(Listener != 0){ llListenRemove(Listener); Listener = 0; } } touch_end(integer HowMany){ while(HowMany--){ if(llListFindList(Pending, [llDetectedKey(HowMany)]) == -1){ Pending += [llGetUnixTime() + Wait, llDetectedKey(HowMany)]; } } llSetTimerEvent(0.1); }} In this case the dialog would be shown to each person as they were added to the list in touch_end() and their command processed where they are deleted in listen(). Edited: code error ^^ serves me right for not digging out the real thing.
  11. I think I have said before that my priorities are i) make it work, ii) make it readable for maintainability, iii) make it as efficient as it has to be. Efficiency is definitely an 'also ran' as far as I'm concerned - as long as the thing works and is easy to maintain. I see myself as a writer first and, for me, programming is the art of writing well - clearly, sensibly and possibly interestingly. This is, however, experience bred of large production (RL) systems where maintainability is much more of an issue than it's likely to be with LSL scripts. My largest SL system was only 1,000 lines or so, compared to a 'real' system which may be hundreds of times that size. Yours is an interesting question for another reason as well though. As a philosopher and as a programmer I find mathematicians to have a very negative, if persistent, influence on computing. First a lot of people are put off computers and programming because they think "computers do maths" or "you have to be good at maths" to program them. Second most programming languages are 'maths heavy' in their supplied functions and semantics; variable assignment of "[Let] X = 5", for instance, compared to ABC's "PUT 5 IN QUANTITY". Lol, I also hate operator precedence! WHY should the result of "3 + 4 * 5" be 23? Thirdly mathematicians write books like "Artificial Intelligence: a modern approach" which tells you all about the mathematics of a system and nothing about the data structures - which is the main thing any programmer will be interested in. Fourthly mathematical equations are a very poor way to 'sketch' a program; apart from not making the sequence of operations clear they tend to use single-letter variable names AND all that Greek! The philosophical objection is only that 'logic' is ours, not mathematicians'! They get the numbers *grin*. Some of the banking systems I've written handled trillions of US$ per day, but hardly did any maths. Yes, keeping track of a lot of things and adding and subtracting big numbers but hardly rocket science ^^ I've never written a scientific system where I would be talking to mathematicians or those who used advanced maths on a regular basis. Nor have I often needed it for any system that I have written, For me, therefore, the logic has not come from maths but from a detailed understanding of what the program is meant to do. That means talking to people about the things ('objects' if possible) they deal with, then writing that understanding clearly, in English (in my case) so they can follow it. That gets gradually refined, through pseudo-code, to something the computer can understand and execute and people can maintain. Clear and understandable is usually efficient enough. Only as a final step, where it is necessary, do I optimise the code for the computer's sake. ----------- Specifically, of the three things you mention: If the same code is used in more than one place then I put it in a function so there's only one place it needs changing Everything should be in as few scripts as possible because the communication between them is usually tortuous at best (The place to be modular is off-line, use your editor to assemble the modules for any specific script) I tend not to use states unless the functionality is VERY different. A typical script of mine would have four states though - initialisation, configuration, operation and 'oops'. I break these rules whenever it seems right to do so - such as inlining 'function' code
  12. I'm completely lost here. HOW are you meant to have multiple listeners open at the same time when each time someone clicks the previous listener, if any, is closed? That's exactly what the llListenRemove(gListener) does. It doesn't matter if multiple people are reported as having touched the prim in the same event because only lllDetectedKey(0) is used and has a listener opened for them. If someone clicks in a subsequent event the llListenRemove() will trigger again. True - there may well be multiple dialogs open at the same time, but not listeners.
  13. I'd love to be your friend. But I know what ou're like, so I can't.
  14. THE group - pick up a decade or two! http://www.thebangles.com/
  15. An excellent song and sentiment Perrie. I still have the record. And the gum.
  16. I'm trying to look posh. Don't want people thinking I always sleep in my clothes.
  17. More annoyingly, we don't get to enjot Pi day (3.14.nnnn)
  18. Exactly Maddy. The Sun (Murdoch gutter press) newspaper got itself unofficially banned from several of our military establishments during the Falklands conflict (1982) because, for instance, of a front-page picture of one of our troops ships (and 48 people) burning after being bombed by the Argentinians. It was the headline "Bastards" which was the problem, not the picture*. "Our enemy are not bastards. If they are not worthy of respect then neither are we" as my Sergeant-Major put it. [*This was only the final straw where I was based. Earlier photos/headlines such as "Gotcha" attached to the killing of 323 people in the sinking of the Belgrano were considered to be in extremely poor taste as well. There's a lot more I'd like to say about The Sun during the conflict but it would be libellous** :-( ] [**In UK law being true isn't usually a defence against libel]
  19. As the ladies have explained, the area of land you have determines how many prims (primitive shapes, but usually measured as Land Impact now) you are allowed to have in-world (rezzed) there at any time. If you want to buy a house or anything else that someone else has made then try the marketplace (see Shopping at the top of this page) or - much more interesting - visit shops in-world. Alternatively, if you want to build something yourself (and a house is just the same as anything else) then you do not need to buy the prims, you can simply create and edit them (free) any time you wish. The very simplest demonstration of this is: right-click the land, left-click 'build' in the menu, left-click land where you want the new prim. It would probably help you a great deal to learn more about how SL works - including shopping and building - if you visit Caledon Oxbridge, Builders Brewery, any of the NCI locations or another in-world helper organisation. They have helpers, freebies, classes and information on almost all aspects of SL.
  20. Caledon Oxbridge, Builders Brewery, any of the NCI locations (eg; Hamnida sim). These have the advantage of having helpers, freebies, advice and classes as well as just sandboxes. Incidentally - they also have changing-rooms so you don't have to try on clothes in public. If you are just trying to open boxes to get the contents out so you wear/attach/examine them then you don't need a sandbox. Just wear the box (yes, I know that's not what you want ...), that lets you right-click and open it so you can get everything into inventory. Then just detach the box again ;-)
  • Create New...