Madelaine McMasters

Qie Niangao wrote: steph Arnott wrote: So basically unless I need a value then return is pointless in it's use and could even create a bug. I'm not sure how you got that impression, but it's certainly not the case, and return can greatly simplify code, both for readability and (especially) execution. The readability thing is a bit controversial because there's a line of thinking going back decades that the flow of program control might be more obvious if each block only has a single exit. As with most things, taken to an extreme, this can lead to some very convoluted programming -- even in languages specially designed for it. (I'd also just mention off-topic that the order in which conditionals are tested can affect program performance. Some of the sample code is testing a string match and then an integer, both of which need to be true for a branch of code to execute; unless there's a vast difference in frequency, it would be faster to filter first by the integer value, string operations being so much slower.) I use "return" frequently in my professional coding, as I often find myself in a place where my work is done (or more likely, I've tested my way down to an error condition) and can't see an easy way to get to the end of the routine. At that point, I return an error code. I don't think I've used "return" in any of my small LSL projects, simply because they never reach a level of complexity that makes a "return" attractive. Your advice about decomposing complex conditionals (or rather avoiding their construction in the first place) is spot-on. I often nest simple "if"s for the reasons you cite, minding the execution times of the tests and their likelihood of failing. You'd want to do the fastest tests first, so that their failure will save you from executing costlier tests. When the tests are all of similar speed, you want the most failure prone tests first, so they'll maximize the chances the other tests can be skipped.

When you code a function or handler, you want to return from it the moment you've completed the job and have the result, or have determined you can't do the job and must return an error code (handlers don't return values, but functions can). That moment may not be at the end of your code. It's understandable to think that all code should end at the end, and you usually try to code it that way, but "return" gives you a way out when ending at the end would be difficult or inefficient. In your original code example, the first return statement was actually useful because it would have prevented the computer from executing the second "if" if the first one passed (meaning the second "if" would certainly fail, and doing second "if"s test would be a waste of time). Changing the second "if" to "else if" did the same thing, in a more logical and less error prone fashion, making the first "return" redundant. The "else" makes the second "if" go only if the first one fails, and the code would end at the end, as you'd expect. If you are coding a function that returns a value, you can't avoid using "return", as something must specify the thing to be returned. Here's an example that shows how return is used in a function, and also shows why you might use more than one return. Let's imagine a function that returns the name of the day of the week given the number of the day, where 0 is Sunday, etc. There are better ways to code this, but I want to make an example... string dayName(integer day){ if(day==0){ return "Sunday";} if(day==1){ return "Monday";} if(day==2){ return "Tuesday";} if(day==3){ return "Wednesday";} if(day==4){ return "Thursday";} if(day==5){ return "Friday";} if(day==6){ return "Saturday";} else return "?"; } You could also code this as: string dayName(integer day){ string name = "?"; if(day==0) {name = "Sunday";} else if(day==1) {name ="Monday";} else if(day==2) {name = "Tuesday";} else if(day==3) {name = "Wednesday";} else if(day==4) {name = "Thursday";} else if(day==5) {name = "Friday";} else if(day==6) {name = "Saturday";} return name; } Which do you prefer? There are more complex situations in which escaping a function or handler via a "return" well before the end of the code makes more sense than trying to end at the end.

You're shaming me with both your kindness and your generosity, LepreKhaun. And pardon me for not noticing that was your debut post, Flint. Welcome aboard! ;-)

steph Arnott wrote: I see what you mean, i never thought that way. As I'm sure you are learning, when you deal with computers, you sometimes find yourself thinking "that way". I have been told by friends that I'm a pain in the ass because I think too logically. I don't doubt I'm a pain in the ass, but I think that's for other reasons. ;-)

FlintMorgan wrote: link_message(integer linknum, integer num, string str, key id) { if(str == "died" || str == "detach" || str == "nohealth") { llMessageLinked(LINK_SET,1,"ok",NULL_KEY); //add here whatever disables the object } else if (str == "reset" || str == "attach") { //add here whatever enables the object again } } Well, for starters, that's not a complete script by any means. It has no default state and it's missing code to actually do anything upon receipt of a message, as hinted at by the "add here whatever" comments. What are you trying to do, Flint?

Steph, if the only messages this thing will ever get are "exitOpen" and "exitClose", you can be a bit lazy and omit the test for "exitClose". If you get a message and it's not "exitOpen", it must be "exitClose", right? And, if you do the comparison for the proper "number" before checking the message, you only have to do that comparison once, which will improve the execution time very slightly. By using "else if", you'd also do the number comparison only once, but I thought it might be useful to show that there are times when it's wise break out the parts of a complex conditional. If this script will get other messages that it must ignore, you'd have to do the test for "exitClose". link_message(integer sender_number, integer number, string msg, key id) { if(number == 2003000) // no need to go further if number is wrong { if(msg == "exitOpen") { if(closed) { integer step; do { llSetPos(llGetPos()-a); } while (++ step < 9); llSetPos(llGetPos()-a/2); closed = FALSE; } } else // msg must be"exitClose" { if(! closed) { integer step; do { llSetPos(llGetPos()+a); } while (++ step < 9); llSetPos(llGetPos()+a/2); closed = TRUE; } } } // if(number == 2003000) }

HI again lilmisslara, If this problem is only on that one club sim, it may be that your maximum bandwidth is set too high, and your viewer is dropping the audio stream to load textures. This might happen if the sim is particularly busy. If so, you may find that sound works when the club is not busy. If I understand correctly (and it's quite possible I don't), the Maximum bandwitch setting in Preferences->Network & Cache pertains only to the loading of scene data. If you set that too high, and your ISP bandwidth can't support the full load of scene data and audio stream, the audio stream will be dropped. Your Max bandwidth setting should be 1500 or lower. You could also try reducing your draw distance to reduce scene rendering bandwidth. It's also possible that your PC has a corrupted network setting, you might try a reboot of both it and your broadband modem/router. If you are on a wi-fi connection, try a wired connection to improve your network bandwidth. If none of those things helps, come back to edit your question via "Options" over there on the right. This will keep all our answers in one place and avoid pushing other questions off the front page. Good luck!

Hi lilmisslara, Go to the menu "World->Asset Blacklist", where you will see a list of the things you've blacklisted. Select the stream you want back and then click "Remove selected items from blacklist" at the bottom of the window. Good luck!

valerie Inshan wrote: I'd hate to fall asleep in the middle of the party! Aww, I enjoy what happens when you doze off on us... Good morning, Kids!!!

Kon'nichiwa, Japan: It's possible that some viewer support files from your previous viewer were corrupted, and are still being used by the new viewer. If this is so, you'll need to do a "clean install" of the viewer. Instructions for doing so can be found here... http://wiki.phoenixviewer.com/fs_clean_reinstall Although they are written for the Firestorm viewer, they should work for other viewers if you substitute the appropriate viewer name at various points in the instructions. If a clean install does not work, you might try installing a third party viewer like Firestorm. If that also doesn't work, come back to your question and edit it via "Options" over there on the right to tell us what you've tried. Good luck!

I agree with Sassy in thinking that it would be very difficult to get mo-cap from a single camera's perspective. Avatar motion is 3D and the video you have is 2D. Absent the parallax of another camera's perspective, a computer would have to understand a great deal about the scene, or have massive help from a human, to estimate motion in the missing dimension. I'm not aware of systems that can do this... yet. And, as you have multiple avatars in-scene, there is the potential for overlap, which could make even multiple camera mo-cap very difficult.

Did someone ask for bacon?... Don't mind the drool, it's antiseptic! Good morning, Kids!!!

Hi Kaedyn, I just checked your profile and see no RL photo. Were you able to remove it? Respond by editing your question via "Options" over there on the right.

Hi Elizany, Have you checked to make sure you are not wearing a facelight? That might illuminate your feet/shoes differently than your skin. Remove all other attachments, then put on only your shoes and see if the lighthing problem persists. If it does, come back and tell us by editing your question via "Options" over there on the right. Good luck!

Hi Aviborm, Without knowing what graphics processor your computer has, it'll be difficult to offer advice. Come back to your question and edit via "Options" over there on the right and tell us more.

Studio09 wrote: "Wag More Bark Less" And here's evidence to yield inconclusion... Studio, you gotta stop by more often. Val, Hippie and I are getting tired of scritching each other under the chin! So, where's my scritch? Hi, Kids!!! ;-)

It's in the menu World->World Map, and it's a toolbar button. If you don't see it in the toolbar, right click something in the toolbar and select "Toolbar buttons..." then drag the "Map" button from the toolbar window to whatever screen edge you want it on.

Hi GIanni, Have you installed the latest version of the viewer? Viewers determine compatibility with your card by examining a file called gputable.txt, which is included in the bundle of things that make up the viewer application. LL added your family of cards to that gputable.txt file in the latest release, which is 3.6.11.283787. If you are running the beta viewer, the "Project Interesting Viewer" or a third party viewer, the gputable.txt file may be out-of-date. Firestorm is usually pretty current, you might try that viewer. If you don't want to use the latest SL viewer and you are computer savvy, you might be able to find the gputable.txt file from the latest LL download and use it to replace the gputable.txt file in whatever viewer you are using. I don't know where you'd find it on a PC, but on a Mac, right click the SecondLife viewer application icon and select "Show Package Contents". Then navigate to "Contents->Resources" and you'll see gputable.txt there. Copy it and then navigate in the same way to the contents of the viewer you are using and paste it in the folder where you find that viewer's gputable.txt. Good luck!

Good morning, Hippie! Mom and I are off to market a day early. Our Thanksgiving company ate us out of house and home! Hi, Kids!!!

I just coded something akin to Qie's test and built it on three compilers I've used in production, one for an ARM processor, one for a digital signal processor and one for a small 8-bit microcontroller. As I expected, whether I use 1 or 1.0 to initialize either an integer or float variable produces no difference in the resulting code. The versions are byte for byte identical. I can't imagine a situation in which 1 would produce a different result than 1.0 for the compilers I use. (That doesn't mean there isn't one, it's just that I can't imagine it.) This has no bearing on LSL, of course, but does explain why programmers like me, and even the good ones, might use integer constants in floating point situations. The compilers figure it out. I do recall being admonished to put decimal points in constants I intended to be float, but that was by my Dad, who's PDP-11 compilers weren't as smart as those I use today. One might make a case for using 1.0 rather than 1 to telegraph to the reader that something is a float, but that becomes a stylistic issue, not a technical one. The compilers I use do the right thing, even if I'm lazy. And if being lazy gets me the desired result, can you blame me? On another note, I have used compilers that were certifed correct, running on hardware that was certified correct. I warned of the danger of allowing me to code on such a system, but I was ignored. At least LSL gives me reason to think I might not be the weakest link in the system. ;-)

Hi, Kids!!! Though it may not be Thanksgiving Day where you are, I hope you find your world full of things to be thankful for.

It's not laziness, Steph. In scientific circles, you don't specify more precision than you need. "1.0" implies that the tenths are important. If they aren't, you'd just say "1". And when you type "1.0", that's a string of three ascii bytes, which must be converted to a number before conversion to binary, rather than "1" which is only one. That conversion from ASCII to a number takes far more time than any float<->integer converstion. Once the byte code program has been compiled, the numbers are all in binary and there is no more conversion overhead as the program runs. And with a good compiler, it's possible that an integer arithmetic operation will be carried out in floating point, because the compiler may see that the processor's floating point unit is available to do the computation in parallel with the integer arithmetic unit. The sophistication of modern compilers can make it difficult to know exactly how to craft code for best performance.

You may be waiting forever, Chiaralena. Adobe doesn't seen to have the competence to make Flash work well on a Mac, let alone make it work at all in SL on a Mac. :-(

Hi Jpg, A chat/FPS problem has been encountered by another. Here's a thread about it... http://community.secondlife.com/t5/Second-Life-Viewer/MASSIVE-FPS-drop-when-using-IM-chat/td-p/2282269 Good luck!