 and welcome to the 2.30 to 3 o'clock PM session of the 2020 Open Simulator Community Conference. In this session we are happy to introduce a presentation called How to Submit Bugs to the Open Simulator Project. Our speaker is Kayaker Magic. Kayaker Magic has been a reporter for OpenSim for many years and submitted many bug reports. He gave a presentation at OSCC several years ago about the sad, sorry state of weapons development in OpenSim to bring attention to some of the bug. Things are much better now. He is a prolific writer of LSL scripts for OpenSim and you may have seen some of his work all over the metaverse and possibly all over the stage. Please check out the website found at conference.opensimulator.org for speaker bios, details of sessions, and the full schedule of events. The session is being live streamed and recorded, so if you have questions or comments during the session, you may send tweets to at OpenSimCC with the hashtag OSCC20. Welcome everyone, let's begin the session. Hi everybody, as you all probably know, OpenSimulator is an open source project written and maintained by volunteers. But the people writing the code cannot test every facet of this huge project. They depend on reporters to try everything out, verify when things are fixed and report new issues. Any of us can be reporters, but to be effective, there are procedures you should go through. Don't just whine, something doesn't work, fix it. You should go through several steps to submit a good bug report. And that's not easy, which I'll probably say several times. It's hard to do a good job. And so I'll go through the steps with some more stories of experiences I've had reporting bugs in OpenSim. And I hope to encourage more people to help improve OpenSim by reporting bugs. And I hope to show you how to improve the quality of your bugs, not of your bugs, of your bug reports. So here's the outline of the process. When you notice something is wrong, you should try and learn as much as you can about it to gather information. There's a process called submitting a mantis. And later, I highly recommend that people who report bugs go to the OpenSim, OpenHouse developers meetings. And when your bugs are hopefully and quickly fixed, you can test your bugs and report back to the developers to tell them what a great job they're doing. And then you can mark your mantis bug reports as having been fixed. The first step in gathering information is it's probably best to check and see if somebody else has already reported a problem that you've seen. So here's the URL, opensimulator.org slash mantis, that is the hub of tracking and checking bugs in OpenSim. There's a button on that called view issues, and it has a lot of options for narrowing your search. But the most important thing is a text box, search box, where you can type something like slow mesh or hypergrid failure or the name of an LSL function like llgettime. And it will tell you if other people have reported bugs about this and you can read those. And if you have information to add to a bug report that's already there, then there's a box for adding a note to the end of an existing bug report. So what other information do you need to collect? The most important thing is probably to try and find a way to get problems to happen on demand. And this is the hardest thing about submitting bugs. And if you can get a bug to happen on demand, this is absolutely fantastic because then the developers can make it happen and they are able to fix it much faster. If you are a scripter like me, it's a bit easier to find ways to get bugs to repeat. For example, you may say, every other time I go to a particular region, mesh doesn't res. Well, every other time is great. Often problems don't happen every time. Don't even happen very often. But a scrip can do something a thousand times in a second and exercise the system very, very hard and get problems to happen. Although I would discourage you to submit a 2000 line free vehicle script that you got from SL with a note that says it doesn't work. The developers are not going to debug your bad script for you. I like to say that a lot of the free scripts that you get from OpenSim are worth a lot less than you paid for them. An example of a script that I had noticed a problem in a function called lllisten in the library. And except it didn't hardly happen very often. Once it happened, it was very repeatable, but as soon as you restarted your region, if things would start working correct again. So I was at a loss for a long time as to how to fix this problem with lllisten until I tried to write this toy here, which is a device for painting prims in the air. And it turns out that every segment of the line in this thing I'm drawing in the air requires that each segment create a listen channel and then talk to the main HUD that I'm wearing. And then after a while, I'll listen would stop working. And so I was able to pair this down and down and down until I had a very small script that ran, that call lllisten a thousand times. And on the 600th call, it started to fail. And then when I submitted a bug with that script saying here's how to get it to fail every single time, within 24 hours, UBIT and thank you UBIT was able to fix that bug. And then this toy here that draws in the air, I had had this lying around for a while and I wasn't able to sell it on the Kitely Market because it always crashed whenever people tried to use it. Now I'm able to sell this on the Kitely Market and it works in any region that has upgraded, fortunately to OpenSim 0.9.1. So when you have gathered information about your bug, you need to fill out a mantis form. Well, here are the steps of filling out a mantis form, but let me try and show you what the mantis form looks like. You probably won't be able to read that. But this is what it looks like and I'll go through the parts of it. You get to this page from that main page that I gave you the link to earlier by clicking on the report issue button. By the way, you probably will need to create an account in the mantis and once you have created an account there, then congratulations, you are a reporter now. So there's a category box where you tell, there's a dropdown that you get to choose whether this is an issue with the scripts, whether it's an issue with the physics engine, whether it's an issue with the OpenSim core or a few other issues that have to do with the main server code that most of us don't deal with. But there are a lot of choices there for that box. There is a button for reportability or reproducibility and hopefully that's always. And there are, I'd like to say that this form is obvious and you just fill in the boxes, but there are some that have always annoyed me. For example, there's a box that says OS. Does that stand for OpenSim or actually no, it turns out that stands for operating system. And there are a couple boxes like for your Git number. And well, what is a Git number? How do I get a Git? And most of us, at least I didn't used to know what a Git number was. And so I couldn't fill in that box. But for the most part, you can skip the confusing boxes. There is a line to fill out saying, what is a one line short description of your problem? Like mesh load slow in region LBSA Plaza. That would be a short description and then a longer description saying what the problem is. And there's a separate box for how do you reproduce it, which I keep saying is the most important box. And then there's an additional information box. And what I usually stick in that box is a script. And of course, down at the bottom of this form somewhere, there's a submit button. And then you have submitted a bug to help the developers figure out what's going on in OpenSim. It's a huge project and you might say, well, why don't the developers find the bugs for us? And well, the debuggers are busy fixing things. And it's a huge project and they are cloud sourcing the search for bugs by asking the rest of us to help out. So you can be a big help by doing a concise job of reporting the things that you see go wrong. So one of the important things that I think you should do after submitting a bug report is to start showing up at the OpenHouse developers meeting, which takes place in OS Grid in a region called Dev Outreach. And Dev Outreach has a couple of wonderful features. It is a sandbox, so you can actually test your bugs there. And it is also rebuilt automatically most evenings. And so after a bug has been fixed, you can go to Dev Outreach and test your bug again to make sure that your bug has been fixed. And of course, you can talk to the developers there. And so I like to, when a bug hasn't been fixed yet, I like to go to the developers meeting and ask them every week, have you fixed my bug yet? Have you fixed my bug yet? And eventually they get so annoyed that they fixed my bugs just to make me shut up. And actually, sometimes the developers are supposed to get an email whenever something is changed in the Mantis system. But sometimes they miss those. And for example, I was showing up at Dev meetings every week. And there's one developer, Robert Adams, who I've seen around here today. He may be listening to me right now. And Robert Adams was the developer responsible for the BulletSim physics engine. And I found a couple of problems with the BulletSim engine and I submitted them as Mantisci, which is, I don't know exactly what the plural of Mantis is supposed to be, but Mantisci is fun. So Robert Adams showed up one day at one of these meetings and I said, Oh, Robert, I haven't seen you in a while. How are you doing? Have you looked at my three Mantises about BulletSim? And he said, What? He said he hadn't noticed them. He didn't know they were there. And during the meeting, he went and he read them and he said, Oh my God, you're right. That is an interesting problem. And within several weeks, he'd fixed them. So showing up at the Dev meetings, even when you're not trying to annoy them, is a good thing to do to make sure that they are aware of. Sometimes they'll be aware of your problems and they won't have time to work on them or they won't want to. And if you're signed up for the Dev developers' emails, you'll get emails whenever your Mantis is updated. So you might see the developers adding a note to your bug saying, This isn't a bug. This is a feature. Something that I forgot to mention earlier is that before you reported bugs, one of the pieces of information you might want to gather is to try running it on Second Life, try running it on an older version of OpenSim. Kitely was on OpenSim 0.8 for a long time. And it was often helpful to try your bug on Kitely or some others 0.8 region. And you might find several of those on the OS grid. There's a lot of dusty corners to OS grid that have old versions of OpenSim on it. But I would try my bug on Kitely, try my bug on the latest version. And if it worked on Kitely and it didn't work in 0.9, then ho, ho, ho, it was a new bug they had introduced and that was valuable information. And if the bug was there in both of them, it meant that the bug had been around for a long time. And that was also useful information. And so finally, when bugs are fixed, it's not the responsibility of the developers to follow around behind you and close your mantises. So if you are paying attention and going to the Dev meetings and testing your bug, then you can go to the Mantis page and mark your bug as fixed. One thing that I did to try and get bugs fixed was in 2005, I gave a talk that I, I joked was it designed to embarrass the developers into fixing some bugs. That you heard that at the beginning, the the sad sorry state of weapons development. And as a result of that, of that talk, the developers did in fact fix a bunch of bugs in weapons. And so I was thinking it might be fun to go postal and stand up here in front of the audience and shoot at them with a weapon. But that would not go over well. So what I have here is it's sort of a weapon. It's based on my snowball tosser. That is not the right. This was actually developed a couple of years ago. I had the idea of doing a performance here on the stage of giving the audience a toy that threw tomatoes. So you could throw a tomato at somebody in the audience or the audience could throw tomatoes at me if I said um too many times. And then that would tell me that they didn't like my talk. And then I have another similar device that instead of throwing tomatoes, it throws roses. So if you liked my talk, then you would throw roses at me. And this is the the rose tosser. Uh oh, that's not the rose tosser. So it would throw roses like this. Oops, I missed. And then the audience could throw roses at people. I'm not. There they are. Now I see the roses and to indicate that they liked the speaker. So that unfortunately didn't work because the audience isn't allowed to run scripts. So getting back to things you can do about OpenSim, one of the things you can do is you can install your own version, development version of OpenSim. Like I will go and recompile OpenSim on a server in my barn every week before the meeting. So I know what changes have been made in OpenSim lately. And then I can test on that recent version. Of course, if you don't have a spare server or the skill to install OpenSim. And it turns out it's fairly easy to compile OpenSim and install it. One way to make it easier is to install a region on OSGrid where Dan Banner does most of the heavy work of getting the asset server and the login servers and the central part of OSGrid to work. And all you have to do is add a region one at a time on your computer, on your PC, or on the server in your barn. And that way you can test with a recent version. And another thing you can do, and this is really advanced, is to learn to program in C-Sharp and try fixing bugs in OpenSim yourself. So instead of just saying it's broken, fix it. And instead of saying it's broken and here's how to make it break. And here's a script that makes it break. The next more powerful thing to do is to say it's broken and here is a patch that will fix it. But I have some bad news for you. That the developers are very protective of OpenSim and they will not accept your patches easily. And sometimes they will, I have never had a patch accepted. Although a couple of times when I have submitted a patch saying here's a way to test to see if it's okay to call a function before you call it. And they rejected my patch. But then Ubit found a way to test these things that was better than what I imagined. And so submitting a patch at least got Ubit thinking about how to test for whether or not you can call a function and that ended up working out really well in the end. Now I have sort of a sorry story to tell and that is that reporting bugs to OpenSim is kind of a leap of faith. That it's an investment in the far distant future. After a bug is reported it may take a while to fix it. After it is fixed it's sometimes years before a new version of OpenSim is released. And then it's years before many people update their regions. Like I said OS Grid is full of regions with old versions of OpenSim still running on it. And then sometimes it's years before commercial grids update to a new release. Kitely for example has fortunately updated to 0.9 and I'm real happy to see that. And unfortunately I'm a merchant in the Kitely marketplace and that means that if I find a bug tomorrow and I submit it to the developers and they fix it it's going to be a while before it will percolate into all the systems out there. It might be years before I could sell a product that uses a function that I had to report a bug in. And so that seems like a thing that might discourage you from submitting bugs. But patience and faith has eventually paid off for me and it has I have been around long enough that I've been able to sell that paint in the sky primitive tool and things continue to get better. And I hope that things will continue to get better and get better faster in the future because more of you will be reporting bugs. Okay all right we need to wrap it up. Yep that was the end. Okay I can see the links you've gotten while everyone looks at the links. Thank you Kayaker for a terrific presentation.