 Okay. Can people hear me? Hello? Anyone out there? All right. So, great, great, great. Sounds good then. So, I'm looking at the audience, and I see people who already know everything there is to know, but I'm actually more than me, about all the various respects about config files like Robert at the back there. But I'm going to go in three of these anyway, because I always have this difficulty doing, because I kind of want to do a presentation, which is actually, I shouldn't say it like that, actually useful. No, I want to do a presentation, which is actually practical, but at the same time I'm afraid of pitching at a point where everybody attending is actually going to know all this stuff already, and won't be interested. So, we'll see how it goes. So, I'm probably going to end up finishing a little early, and then we can just kind of, I guess, kind of answer any kind of questions. Okay. Passed the audio, still okay for other people? Okay. In that case, I am going to start starting. I'll get to the inventory box. Okay. So, basically this is a talk about configuration, which is an exciting subject, and one which anybody who does anything on OpenSim gets to know in intimate detail sooner or later. So, I'm going to talk about, basically some of the background of how this configuration system came about, a kind of an overview of the structure of the system, how the different config files kind of include and load each other, and then a review of some of the significant configuration parameters, which I should say will be hopefully some of the more obscure ones of varying levels of usefulness, depending on who you are. But there will also be a Q&A. So, if anybody really does want to talk about anything, configuration-related, exciting as that prospect is, that'll be the point. There are any other kind of parameters that I've always wanted to ask about, as to why they're there or what they do, and I may or may not know, because to be honest, there's so many of them. Now, I really don't know what they all do. Okay. Whoa. Whoa, wrong slide. Fantastic. I knew I should have reordered the numbering in here. Okay. Oh, I see. They probably loaded in the order. I wasn't expecting them to. Okay. Right. You're going to experience a small delay while I go through a couple of slides. Yes. Basically because my slides are misordered, because I think I made a mistake, not because I just reloaded them and I made a mistake of not fixing the numbering properly. Yeah. Yeah. It's a quick presentation. All right. Great. So, I'm going to make a couple of assumptions in this talk because it is a low-level detail kind of talk. I'm going to assume you've run your own open simulator so you know what I'm talking about and aren't thinking what is this config crappy is on about. I'm going to assume you're familiar, and this isn't really that important, but I'm going to assume you're familiar with what terminology like the high-level stuff as it were in open sim, like standalone grid and hypergrid. In fact, hypergrid's not actually necessary, but so standalone and grid. I'm going to assume that you know that open simulator lies on configuration files, such as OpenSim.id. If you don't know what OpenSim.id is, then this probably isn't going to make a lot of sense, this talk, to be honest. And now you're familiar with any file structure, and by that I mean, well, actually, I'm going to go to, I'll go to the example. No, I'm going to write. What I'm going to do for this talk, I'm actually going to try the media on a PIM. I'm actually going to try coding, not coding, I'm trying to go and try config file stuff in Google Docs, which may or may not be a good idea. And if it's a bad idea, we'll have to abandon that. Ooh, that doesn't work very well. Okay. So I'm going to bring up, in fact, this first screen now, and is that appearing for people? Yes, I kind of, so some of you on some viewers might actually need to click it. It shouldn't matter, you should be able to see it, but you might actually need to click the thing. Yeah. Okay, if you're not, yeah. If you're not seeing it, you kind of have to click on it and then it appears, yeah. It seems to depend on the viewer. Some of them will just display it, and some of them for some reason, you have to click on it. Okay, so, okay, Nick. I'll just carry on for now, but hopefully actually, what I will say will actually make sense even if you can't see the media on a PIM, because to be honest, I originally wrote a presentation thinking I wouldn't do media on a PIM. So, I mean, by a config file, I just mean something like this. This is a very basic snippet of a config file where of an .ini file where you kind of have the heading, kind of different sections in square brackets or braces or brackets there, I guess technically, such as start up here, and then you have, then the lines starting with kind of a semicolon are comments for various reasons. There's double semicolons here, and then the actual parameter here is commented, which I could actually change. This is where, in theory, doing it like this will actually be useful, and I'm gonna wait for that to appear on my screen, so I did it in my web browser, and you're gonna appear, what's it gonna say? It's saying you're actually editing this elsewhere because you've gone to the other link, you fool. Okay. What? Really popular? No, it isn't. Okay, so that's not the best thing in the world where we're not actually transmitting changes. It's gonna make this slightly less useful. All right. So the URL, yes, I could paste the URL in the notes that might be useful. I'm just gonna try actually pasting in without the edit link here because that doesn't really help anybody, at least or me. Like, the other thing is this isn't the easiest thing to actually switch back and forth. So if this ends up taking too much time, I will abandon this particular idea. Okay, so let's see. I just actually reloaded the page. So if it's gone away from you, you might need to click it again, and I'm just gonna put some random gibberish in here and see if it actually transmits, if it actually resyncs. And it might not resync for me, and it might resync for you. This is not, this actually did this work when I tried it. This did work when I tried it, and it's not very happy now, for whatever reason. Does anybody see any random gibberish? Yeah, that did happen, but then I also wrote some random gibberish in there. And that for, yeah, that's what it should say. And of course, this is the thing where everybody's gonna see a slightly different view of the actual thing, including myself, which doesn't really help. Okay, I'm not gonna assume that, I'm gonna keep trying it, but I'm not gonna assume that it's actually gonna show changes, but I think it's still useful. Okay, I'm gonna switch back to the presentation. So if people start losing track, do say in the chat, and I will, yeah, that's what it should say. For some reason, it doesn't say it for me, the random gibberish. Okay, so if people, if that gets too much for people, please do say in the chat, and I will kind of abandon it, because it does mean switching a lot between these screens. And to be honest, it's probably gonna, anyway, we'll see how we go. Okay, so I'm now gonna try and switch back. And hopefully it's actually gonna let me, because it won't be very useful if it doesn't. All right. Did the screen disappear for anybody? In fact, maybe I'll have to click one of these things. Okay, all right. I might just try and restrict the use of that to the stuff where it's actually most useful, because I'm not sure it's working well. Okay, so those were the assumptions. So yeah, you're not in any file structure, through file structure looks like. Okay, so in terms of background, and really I'm not saying anything that unobvious, I think, is that like many, many things in OpenSim, it's an evolving and evolving system that has to suit a number of purposes. So for instance, some standalone operation, we wanna ideally, and this is the way we try and do it at the moment, ideally out of the box, you start OpenSim, you don't need to do much if any configuration at all. And assuming you've downloaded the binary package and it works because the config files are set up, all the config files are set up so that standalone works as you would expect. But it also needs to be able to kind of be wildly adapted for the grid instance, if you to run multiple simulator instances, so instead of connecting to a standalone, simulators are connected to a grid and backend services with things like a robust.ini, which is another configuration file, I'm sure many of you are familiar with. And it's got, and it wants to do things like separate the commonly changed parameters, like what, if you're using MySQL, what data, MySQL database, what parameters you're using to connect and a lot more obscure parameters, like changing the number of physics frames it processes per second, which is not normally something you wanna be fiddling with, unless you really want to try and debug something or you really know what it's doing. So it kind of needs to fulfill quite a number of different purposes and it's evolved to do this. So the structure of any file is it's kind of a cascading structure. So, oh, that's interesting. I didn't delete that text. Okay, right, we'll go back to that second. Okay, so the structure is kind of a cascading structure. So, for example, in grid mode, in fact, we can ignore this text because I have it here. Basically, any files end up including each other, not in each other. They end up including other any files. So, in this particular diagram, for instance, and I hope you can actually read these slides because I kind of, I try to keep the conceit of a world tour and get some, actually, all these pictures are from OpenSim. Many of them are from Annabel Franchot who very kindly provided them, but you can't really see them because I had a great amount to get the text on. So, yeah, that was all great. So the kind of the structure of one of these things is that you see OpenSim at the bottom there and what always happens is that OpenSim defaults to any is loaded first. And that's the file which contains a lot of the expert and debug parameters. If you go through that, for instance, the physics ones I mentioned or things like actually making sure you can bump into any objects and a lot of that kind of detailed stuff. So that's loaded separately and normally we don't ask people to change that. And then, apart from that, OpenSim.ini is loaded and I'm talking the OpenSimulator, Simulator instance here. OpenSim.ini is loaded, which you're very familiar with and that's copied from .ini.example. But that in itself, if you've ever looked at the bottom and you kind of have had to do this if you actually want to run it in grid mode unless somebody gave you your any file, there's a number of kind of include lines. And one of those is to include a file. And I'm assuming these are all in the bin directory, of course, as I'm sure you know. So one of those lines, for instance, if you want to run it in grid mode is to, instead of including standalone.ini, you include grid.ini, which is a bunch of configuration lines for actually telling the simulator, hey, I want to connect to a grid and not to actually use in-process kind of services like asset and inventory. And that in itself also then goes on to include grid.com.ini, which is the file you would actually change to put in the parameter like where you want to, the IP address of your kind of back-end rebus services, in this case, which is the file you would actually change and don't ask you why it's called grid.com.ini. Maybe, I don't know, at a time I thought it could have been better named, but we'd already gone down that road. And to be honest, I don't know. Changing any files is a nightmare. I've already tried it years ago and nobody was very happy. And then itself can also include a file called flotsamcache.ini, which is the standard caching for OpenSim. And normally you don't need to do that, but if you wanted to change those parameters, you could kind of copy that.exampl file, flotsamcache.ini, the example. And then I'm end up editing that. So already it's a pretty complex structure. And if I go on to the next slide here, so you see that a lot of those files kind of included from each other. But when they're included, some of them maybe counter-intuitively, they're always kind of merged afterwards and not inline. So if you had to include, and I really could ideally would show you what an include line looks like, right? I'm not going to switch to the meter on a prim or try that just yet. But ideally they would kind of, you know, as you would expect in the programming language that that should be included inline so that if you had config file, config parameters after your include line, then they would override the ones in the include. But unfortunately because OpenSim kind of, because OpenSim kind of adds this to the library itself rather than like the kind of the config reading library doing it, which is called Nini or NINI, then we can't do that. So we end up merging them after, which can be counter-intuitive. But it's also the case that later identical parameters overwrite earlier ones. So that's why you can, you can put in, why we kind of suggest that instead of ever going, editing opens and defaults to any, if you do want to change any of those kind of less commonly changed config things, you do it in OpenSim that any instead. And that's, that works because OpenSim that any is loaded afterwards and then overwrites anything that was in defaults. If there are settings with exactly the same parameters or rather there are identical attributes. And so we also know that region files themselves are loaded to them somewhere else. In this case, the kind of bin regions directory and they're a little different. And some of the settings there can overwrite and they kind of, sorry, they kind of name the actual, the actual region name and the UID. And I'm sure you're all very familiar with that because, although maybe some of the distributions actually managed out for you, but if you're just using for little OpenSim you end up editing those files. And some of them have settings to override main file settings by which I mean OpenSim.ID settings primarily like non-physical prim max so that you can change the maximum size of a non-physical prim in one region, but not in another. And the other would use the defaults or rather ones in OpenSim.ini. So now I'm going to talk about a few of the various different config parameters. And as you know, there are hundreds of these things are all of different levels of importance. And some of them don't even work. Hopefully those are actually pretty rare, but I know they're a couple which don't work. So I'm just going to talk about a few of these. Some of them you might find useful and some of them you think, I really know that already. You're an idiot. Why are you even talking? Or of course some stuff you might think that's actually not at all useful Justin. What are you talking about? So I'm going to switch, I'm going to try switching back to the media on a prim now. I actually need to switch. I actually need to click it, I think. And then I did practice this. I must admit in practice, it didn't work that well either. Right, now you want me to re-click you again. Okay, great. All right, come on. I don't want the edit bit. All right. Okay, so actually this is just going to be if hopefully people can see this and of course you might need to click it. So this is my Google doc and this, oh my God, it disappeared. Right, it's back. Oh, I've got the random gibberish which doesn't really help. All right, delete that for God's sake. It really, it thinks this page is really popular but I can't think it's that hugely popular unless 20 people or whatever is enough to actually trigger that. Maybe it is. So you might need to ignore the random gibberish for a second, but this is the first very basic thing. I think some time ago, I think it was actually Dan. Dan said that it would be useful to be able to rename the console prompt. So he knew what he was looking at, I think, when he looked at one of the many simulators or maybe one of the ones on white plaza. So, yes. So this is one of the things which actually, like a bash prompt, you can kind of change the name of the console prompt a little bit. For instance, the default here, if you ignore the random gibberish line for a second is region slash r, so that's why you see region and then the region name in brackets. But you could conceivably change that to whatever you like, like this is Dan simulator and the region name or, you know, why have we got a console prompt and a log in the same screen that doesn't really make, that's just, what the hell are you doing? Any kind of prompt you like. Right, so I'm gonna try switching back. Does it say Google doc login? Oh man, there should be a public doc, that's the thing. Oh man, okay, I'm just gonna one second. Maybe this is why it's not being very happy. So I'm just gonna check. Right, it thinks that it is public on the web but maybe I'm using the wrong link. That could be why I'm, yeah, I think that it wants me to do something slightly different. Okay, well, we'll try this link. Let me just paste this in here a second. Though actually it wants me to click and then go back again, okay. Right, all right. So I don't know if people can see that. All right, because I actually pasted the link that Google wants me to use when I'm showing in the public which might be a better idea. I admit, rather than pasting whatever happens to be in the address bar. All right, unfortunately I have to touch it because I have to now switch off it again. All right, you might have to click your screen take if at least try that. Okay, I'm just gonna try a little bit of editing to see if that would actually work. And sorry, I know I'm stretching your patience here because this did work for me in the test. Okay, I will paste the link, yes. So the actual link, yes. If you actually wanna use a web browser then that's the actual document link. Okay, I'm not sure this is actually syncing up here. Okay, well, if you do have a white screen please do bear with me. And hopefully it will still make sense anyway. So yeah, it's a console problems one. So if I actually go to something more in fact why don't I just keep it on the media on a prim? That would make a hell of a lot more sense than me switching back and forth to the presentation, wouldn't it? Okay, so in fact, can people still see that if they are seeing it? Okay, anybody, any luck of seeing that? I see, I told you, I told you this was not a good idea. All right, I'm gonna assume people can see that and if you can't tell me, okay, great. And yes, you can see an external browser. So, hi man, yes, I thought that's what might have happened, okay, I'm gonna try and bring it back. I'm sorry about this. But I thought, you know, experimental conference, why don't we have an experimental presentation as well? Because that would be a great idea. All right, I'm just told it to bring the page back now. Okay, so hopefully people will be able to see that. It might appear white again, which is thrilling. And I'm going to actually find the page with all these bits on, okay, great. So the next kind of parameter, I think, oh my God, where'd it go? All right, I've got a blank page now. Okay, I'm just about on the verge of, I think it's gonna say, yes. Okay, I'm just gonna continue this a bit longer, but if it blows up, then I'm gonna abandon this particular approach, right. So I'm actually gonna replace this, oh man, it's not gonna update. Okay, right, I'm giving up on the media on a PIM. It's not gonna work today. I'm gonna go back to the presentation. Sorry about that, folks. Right, it's gonna be a little less obvious because you're gonna have to imagine slightly exactly where in the file I'm talking about some of this stuff. Yes, I've now taken it off screen. So you should be seeing, yeah, you should be seeing the presentation again now. Okay, right. So the next thing I did want to talk about is async core method. Now this is much more obscure. What this does is control the thread pool used by the core system. So I say the core system because the X-engine script engine actually uses a different thread pool. Now by default, we actually use a thread pool called a smart thread pool. And anybody actually looking at the web browser can see this, because I pasted in the text. But essentially the smart thread pool is kind of like a separate pool of threads in a different packet, not actually part of the runtime package itself, which was available for use. And originally when we were many years ago when OpenSim was a bit younger than it was now, the version of the mono was also quite immature and the thread pool in that did not work well. So we use the smart thread pool. But some people on Windows report that it works a lot better with a pool with a setting here called unsafe queue user worker. In front I put some of this in the chat that might actually help. Called unsafe queue user work item. And this is in the startup section, which actually on Windows does work a lot better because, well, I say that, but there are reports on Windows, it does work better because it uses Windows inbuilt thread pool instead of this other software package. And a mono, some people report it's fine and some people report it isn't. So that's why we're stuck with the default setting, which is smart thread pool. But if you actually want to experiment then that might actually improve in problems on Windows. And so the first setting we're gonna talk about here is one some people will be familiar with, which is combined contiguous regions, otherwise known as mega regions. And this is the setting which says for any square set of regions you've got in the Sims, so say you had ones between, say you had ones at 1,000, 1,000, 1,000, 1,000, 1,000, and 1,000, 1,000, 1,000, 1,000, which would actually, if you set this setting to true, combined contiguous regions equals true, then those would already combine to one mega region and you would be able to move in the viewer seamlessly between them, but it is a bit of a, and two of us, I'm sure you're saying this, is a hack in the best sense of the word, it's a clever hack, but it's not perfect because we do have kind of teleport issues and some other issues with that. But if you do use that flag, then you can actually move between regions seamlessly. At the expense probably of some, maybe some loss of performance in terms of physics engine. Yeah, so the difference between those Latif in C-sharp, so I've read about this, and the difference is basically a privileged escalation. Now, I can't remember the exact details, unfortunately, but essentially, if I think you're running code that you don't completely trust, then in some cases, then if you allow it, if you do unsafe queuing work items, then it is able to actually escalate privileges. But if you use safe, then all rather, just queues a work item that it isn't. But in our purposes, unless you're running, unless you're actually trusting DLLs from other regions, which would be kind of crazy if you don't actually control those regions anyway, in front of it, I should remove that from the config explanation, because that doesn't make sense. Then basically an open-sim is safe because we don't run untrusted code in that manner. They, yes, they both use .NET for it, but it's basically just, the difference is just a security check, essentially, between the two. As far as I, from all the stuff I've read, and I don't tend to be a complete expert in .NET fed pooling. So from a Diva distro, I suspect that uses smart fed pool just like open-sim default does currently. Yes, they're both really Windows settings. As I said, I think there's reports on Mono, they're fine, but there's other reports that says they're not, and hence we kind of default to smart fed pool. But on Windows, you could get better performance with the kind of unsafe Q user work item. Yes, there is a performance difference, but that's what it is, as Robert says. So the third setting, yeah, as I was saying, combined contiguous regions, that's the mega region setting, set to true if you want to try mega regions, and they are useful in some circumstances. And there are bugs, but I think some of those bugs we can overcome. So actually I think there are definitely things that could be fixed with mega regions, but they are kind of like, they are exploiting stuff that the fear is doing, but which was not really meant to be done in the way that we're doing it. Okay, so yeah, I know unsafe, just because it's a very technical thing, and maybe unsafe is not the word we should be using. We've kind of directly exposed the kind of net settings, but maybe they're not really necessarily suitable in this context. Okay, so I was going to talk about robust settings on startup, for instance, and these would be actually a little difficult, perhaps if we can't see them, I really should have taken into account that it might be difficult. But basically these are actually, I can just paste a little few of the features in the chat. Yeah, some of them do have pretty crazy names, partly because they are pretty crazy, and actually using them is not always the best thing. Right, so by service list, service list is actually a relatively new thing in OpenSim. It's something that mainly changed to make it actually easier to see all the configuration of connectors. Oh God, I didn't mean to post that. Right, it was a bad idea. Sorry about that, that was the whole file. And that was it again, because Synergy is not being very happy moving between, right, that's a bit better. So I was only going to post one example. So service list is actually a list of connectors, which controls which DLLs are used to connect to grid services. So this is something one would specify in robust.ini. And these are the things which actually say, for instance, in this case, the asset service connector, it says we want to use the asset service connector class from the DLL, OpenSimServerHandlers.dll. And the port we want to use is 803. And another one, for instance, the login service connector, if I attempt to paste that without repasting every single line I have here, because people in the, right, people looking at the dot can see it. So at a login service connector, for instance, uses port 802 in this case and uses that class service in connector, thanks Dan, and uses the handler.dll. And the important thing to note here, so this is where you can change your port numbers. So if you want to use a completely different port for login, for instance, this is where one would end up changing it, but you have to be very careful that you're exposing and this is not, to be honest, this is a deficiency in OpenSim because it relies on being very careful as to not exposing your kind of private grid ports. But for instance, the login has to be accessible by somebody externally for anybody to log in, for instance, to your grid. So 802 is the default, but the kind of internal services, if you're not running an open grid like OS grid, for instance, where you can kind of take other measures to kind of counteract any issues. But for instance, if you want to use different port, well, sorry, the asset service really only needs to be accessible by internal regions. And so it uses the port 803, which you would not want to expose by default kind of through your firewall to anybody with a viewer. So one can change those numbers, but one has to be careful that one is probably firewalling against that. To be honest, there's a weakness because it does rely on being careful and relying on people being careful is, and to be honest, I'm not very careful. This is the thing, you know, relying on users like that is not the best of ideas, but anyway, that's how it is right now. So I for some reason have gone back to slide one, which is good. I think that was user error though. Okay, so one second while I progress through slides. All right, slide eight, that's great. I've clicked it too many times. All right, if you'll do me the honor of appearing, that would be great. No, that's not the best slide I wanted. 12, sorry. Oh, I see, yes, because I misordered the slides originally I actually managed to hit the end, I think, of the deck, but I really did want to start at the beginning. So if that's the case, we would only be a second here. All right, yep, that we see, we saw, that of course we saw, and slide 16 was coming up right now. There we go, right. Okay, and now I'm going to talk about some of the X-Engine settings, which are some of the, probably the most interesting settings. So X-Engine as, and to be honest, that title is not correct. The presentation is correct in my double capitalization, where I didn't really want it to, I find that kind of thing tremendously annoying. So this is about X-Engine, which is OpenSim's one and only currently, kind of scripting engine, hence of course, is the default. So the X-Engine setting in OpenSim.ini controls, controls of course, how X-Engine works. So one of the most interesting settings here is one called app domain loading. An app domain loading basically controls scripts are loaded in the same or separate app domains. Now by this, by being true, basically every script gets its own kind of container, if you like, and sorry for the people who really do know real technical guts of this, but each script gets its own container, and hence when a script actually has to go from a region, it can be unloaded from memory. So you don't get scripts which are no longer used. Say somebody's deleted the object of the script in and it can be unloaded, they don't hang around and take up memory in your simulator until you restart it. So that sounds like a great idea. Why isn't that always a good thing? Well, the reason is that on Mono at least, it takes a very long time relatively speaking to actually load into those separate app domains. So say you have 1600 scripts on startup in Mono, that would take a very long time and then if any of these experiences, that would take 10 minutes or something to actually load up if you have app domain loading equals true. And that's because Mono, I expect goes about this in a rather different way to .NET and we end up with it taking a long time and it takes so long that to be honest, certainly in a lot of the situations I've been in, it's kind of nicely just to say, no, load everything into the same app domain. And of course that takes nowhere near the same amount of time. You know, it takes, I don't know, maybe a 20th of the time to actually do that on Mono at least. So, but then of course you end up leaking memory because when you unload a script, you can't any longer unload the app domain. You can't unload its container, you've got to keep it around. Now, in theory we could improve this by say, loading all scripts in the region into the same app domain and then anybody coming in with an attachment of a script and load that into a different app domain. So they can be unloaded because one of the common memory leaks of course is that when somebody has scripted attachments and they leave your region, then you really want to unload those scripts ideally but if you can't, well, the usage of memory just hangs around and to be honest, it's not a huge amount of memory. You may not even notice it but it's one of these things which can be annoying because there's no way to reclaim it. So that might be a setting right and now I need to go to the beginning because that might be a setting you might be interested in actually changing. By default in opensim.ini, it's set to load everything in the same app domain because of this, yeah, never ever garbage collected. It can't be. It's just kept around in the same app domain as every other script. And that's the issue. Exactly, you can't get rid of it unless you load it in its own app domain. So that's something by default that set to actually load in every app domain is true in a default opensim but if you find your scripts are really taking a long time to load and you don't really care about maybe leaking a little bit of memory over time then you might want to try setting that to false. So, yeah, on Windows it's no any of the same issue. It's actually a lot quicker to actually load into app domain. So it's one of these things where you kind of try it. Okay, so the next setting I want to talk about is delete scripts on startup which is another exchange is setting. So originally maybe back in the O7 three days or maybe a little earlier all scripts are always deleted and recompiled when you restarted opensim. And this was to avoid issues if some of the opensim code changes and yeah, exactly, it's only really an issue on mono. Yeah, this is to avoid a problem with the opensim code changes and your scripts are still assuming the older version of the code. And so they end up failing with strange errors when you kind of restart them or you restart the sim. Sorry, they sound like failing with strange errors when you restart the simulator if you're kind of updating from the source control repository directly. So I think kindly actually, Owen Hervitz from kindly came along and contributed to the patch which said, well, you can actually set this to false so that you don't kind of delete all scripts and recompile and yeah, I should go through my slide. Basically, if you're deleting recompile you still preserve state because that's actually a separate file. You don't kind of read your state information necessarily but it does take a long time. So what Owen did is introduce a setting called delete scripts on startup which one can set to false of course and I know you know what that looks like but I'm gonna do type in chat anyway. So you could set that to delete scripts on startup equals false and then you don't end up recompiling every script on startup and that again is a lot quicker if you don't need to recompile everything. Your startup's not gonna take anywhere near as long especially if you have thousands of thousands of other individual scripts. So that is perfectly safe. If you're using a release version of OpenSim it's perfectly safe to enable that because your underlying code is not changing you're using a stable version. Of course then you need to watch out if you upgrade OpenSim and you're upgrading in place you're using exactly the same thing you're not doing an approach like kind of transferring or it's across to anything then you need to watch out that you don't get strange errors if you did have that setting and you did change it on the line code. So basically on an actual binary installation of OpenSim that is actually set to false we don't delete scripts on startup because if you're using a binary we kind of assume well you're not changing, you know just using the binary you're not actually changing the source and recompiling all the time the underlying OpenSim source. So that's set to false but in the source actually and this might be something to slightly change I think in the source distribution for instance it's still set to true so you kind of keep me deleting. So if you do find you're recompiling on each startup and you don't think you really need to then you can set that to false and it might be a lot quicker or it would be a lot quicker if you've got a lot of scripts. Right. Oh yeah well co-op is one of the experimental ones I was actually going to talk about but we can quickly at the end because maybe I'll quickly mention it now if you've ever looked at and this is actually only in development OpenSim versions I'm not going to get too off track here but basically and I'm now scrabbling around in my own files because I would actually like to refer to what the file itself says because even though I wrote it doesn't mean I can actually remember it defaults I think still was it? So there's basically a setting called yeah, script stop strategy which can either be as it is now abort or it can be, sorry it should be abort of course or it can be co-op. Now this is an experimental setting in X-Engine which basically controls how we stop script. So abort means that we actually abort the threads running the script directly we kind of yank it out no matter what it's doing at the time and co-op actually waits for because basically X-Engine works by compiling NSL down to C-Sharp and then running the C-Sharp directly there's no kind of nice way to actually get the threads to stop in the middle of operation. So one way is to get the threads to continually check a state flag effectively a flag saying should I stop now? Should I not? So if you do co-op for instance they start checking that flag rather than aborting in the middle perhaps of doing something and that can be more stable and certainly the reason I actually developed this and the reason I developed it because actually the 3D Aftar School people who if you're in an early presentation I was working for we were suffering this issue and it was causing unreliability on Sims and so it turned out to be well certainly it seemed to be that if you start aborting script threads you can end up with nasty kind of conditions where you're kind of leaving issues in the runtime where the state is not consistent. If you just end up aborting threads and this is kind of documented on the web as well. I know I'm not sure it's strictly in the MSDN which Dali will say well and then it's not actually there you idiot but it is an issue you know quite a lot in Stack Overflow threads and that kind of thing but if you abort the threads kind of in the middle of doing something you can leave the virtual runtime in a bad state and that can cause issues later on. Now and actually abort has been on for so long it's not usually a huge issue but there are situations and maybe it's different on Windows because we were using Modo a lot and Mono it certainly can occur in certain circumstances but quite rarely in that if you end up aborting a thread you end up in difficulties. Now abort is kind of stands banded we do actually wait for threads to complete a little while we don't literally gonna abort them straight away. So in many many many cases the thread does stop properly and we don't end up aborting the thread and then in many many cases even if you abort the thread it's absolutely fine it's not actually an issue but there's kind of a one enough I don't know maybe one in a thousand or more where it can be an issue so yeah so co-op is the alternative but it's not ready it's still I'm still flagging this as experimental because I haven't quite fully worked out the migration strategy if you switch the flag and to be honest migration isn't that complicated you just have to recompile all the scripts in fact one of the ways is to say delete scripts on startup as we saw earlier equals true and then actually delete the scripts and recompile but I don't know I wasn't quite ready to flip the switch but something definitely I'm considering doing at some point right so I'm gonna get back on message so I'm very briefly going to talk about the function threat level kind of settings now everybody if anybody has ever tried to use an open script sorry an open sim script function they're probably cursed I shouldn't say cursed they're probably they're familiar with this functionality where function threat level is a number of kind of different so each open sim kind of script is classified by its perceived possible threat level to the simulator and in many contexts this is very sensible because as you can imagine there's a lot of if once you allow complete strangers to come if you're allowing complete strangers or pretty complete strangers to come with your sim and run their own scripts then that's a pretty scary thing to do to be honest that's a really complicated thing to do Yeah so kind of I think I mean I do think it's sensible a lot of these functions if you've ever seen are kind of labeled with different threat levels so for instance I think OS teleport agent would be kind of maybe a popular one which has caused difficulties in the past so for you can imagine OS teleport agent is a pretty interesting function because it allows you to teleport anybody to anywhere and there is one kind of restriction but it's still a pretty strong function so for instance that would be the URL and that has a threat level of severe severe being the highest because it does allow people to do a lot of teleport anybody anywhere which is a pretty high power so by default the function threat level is none I think even OS functions are not enabled by default but one way to enable that is to kind of turn the levels to severe but then severe kind of enables it for everybody on your sim which you really might not want so kind of a way of controlling this is there's a kind of a way of allowing certain function names to only be executed by certain people so for instance in the slide here in the slide here it says you know you can control it by user UID that's what that means or you can say certain things like and I think the name the person who contributes this kind of slips to my mind but you can basically say password group members any members of the password group can execute this function or only the parcel owner if the assuming the sim is over sorry the script is over a parcel and then only the only of that owner of that parcel can actually execute say OS teleport agent for instance or maybe the estate manager or that kind of thing and also you can do it by creators certainly maybe only creators of a certain script can actually execute OS teleport agent and some of these are blunt because you need to do it by user UID which is not necessarily very portable between simulant between grids for instance but you know there are ways of controlling this and probably it needs to be more fine grained but there are settings there if you've ever needed to kind of think about that there are ways of controlling it so login service I'll go over very briefly the map tile URL basically when we get to kind of later versions of viewers they actually end up communicating with the grid the map service directly to fetch their map tiles if you've ever kind of logged in and not being able to see any map tiles that's one of the reasons why and there you will provide a URL to actually be able to get two those map tiles so maybe you would say map tile URL equals and then your external IP and this will be an external IP for instance I think that's it sorry I should refer to my notes quickly so sorry I'm lost amongst mine I should really have shut down some of these windows that really would have been a good idea okay so map tile URL actually you know that's the wrong kind of URL so for instance what it's set to by default is 0019000 because that's the standalone but and there shouldn't be the quotes at the end but in another case you might want to you need to if anybody's externally accessing your grid they need to be able to reach this particular address so say if your external address was for some unlikely reason that sorry and you're using a standalone you'd do something like that so that people can actually see map tiles on later versions of the viewer which is probably most versions nowadays that kind of like later than Linda lab viewer too okay so I'm just going to check I think that's actually the last slide people might be familiar let me move back yeah that's the last one okay with grid info service which is a setting either in standalone condo any for standalone for instance or for robust robust any and probably for hgrobust.hd.ini yes there's all kind of and Robert is probably very familiar with these config files I think he actually knows more about it than I do so grid info service is a way of actually having your grid return some URLs to a viewer for instance a viewer that actually implements this so that it can display for instance the splash page if you've ever wondered how when in the grid manager you select OS grid and it comes up with a nice splash page or even the conference grid that has a splash page as well but in the grid info service section basically yes so the section called a grid info service yeah so there are settings like for instance the login URL which is usually a pretty important one so I'm going to say my grid.com port 9000 for instance which should we should advertise the login URL to the grid manager and stuff like the grid name for instance and probably the one we've just talked about the welcome page which is the splash page which for some reason in my config says it's currently unused which I think is a complete lie this is one of the confusing things about a config file sometimes there's comments which don't get updated and that one needs to be updated so like for instance it shouldn't be the code on the apologies would kind of take would allow you to put up an HTML page where people could see could actually get a nice page when they click on something in a grid manager for instance and look at your grid so that's all these stuff I had I'm very sorry about the presentation difficulties I probably shouldn't have experimented kind of like that because it was pretty difficult it's kind of a lesson learned but thank you very much for paying attention and I think we're probably at the end now but to be honest since there isn't another session if there are any, if anybody does want to talk about if anybody's curious about any particular config parameter and they want to nail me to the spot now then please ask in the chat otherwise than that, thank you very much right, yes Ken that's one again that's one I'm not that familiar with it's one of these settings I've never played with so I know in fact even on this grid even this grid there's been a bit of experimentation about that trying to get things to res in the right order it's in fact if I looked at the one for this region we're in breakout three aren't we so config show is it in startup? I think it probably is so this is update prioritization scheme in fact are we even using anything other than default is that in the startup section? okay probably look at my own any file very quickly so prioritization oh no, so that's in interest management right okay yes and this grid for instance it's actually set front-back so I believe what that means is that the objects and things nearest your avatar are kind of sent to you first and then kind of the ones further away from you but I'm slightly hypothesizing here the I believe the best avatar responsiveness is the idea that yeah I think it's meant to do AV res first but again it might be one of these settings it's not quite working as well as it could right so join the hyper grid so in the hyper grid that's another world to itself almost so if you did that for instance it's one needs to use the robust.hg.ini there are this is one of the areas which is kind of quite quickly evolving because as you might have seen in the other talks Chris is putting in all these kind of extra security things and that kind of thing I do have to echo Melanie I agreed you've got to be very careful it's one of these things you suddenly open up your system to being connected to by anybody else and there is the potential for kind of problems there we don't haven't seen a huge number of them it is a very complex thing so you probably want to check out carefully the hyper grid files unfortunately I probably can't really give you any really great advice at this point but there are probably a good few settings you should look at right any yeah absolutely if you're using any of these config things I know it's really complicated and I do agree I think people have been talking about config being really complicated I kind of I'm kind of ambivalent funny enough I'm kind of ambivalent about that because as I said at the beginning we do need to do a lot of people want to do a lot of different things of these systems and doing them through configuration is the way and by making it kind of easy in one context you make it maybe a bit harder in another so if you made it easy I mean standalone tries to be the easiest but if you made it easier for grid for instance then standalone might become difficult so we have all these kind of different mechanisms for changing these files but they do become a bit complex and to be honest that's one of the things I always kind of thought well maybe a downstream distribution can like divas for instance setups have a very different kind of config and can do that because of the way we kind of allow a lot of things to change and maybe that some of these downstream things do make it simpler because they either do it automatically or they kind of only present a much more restricted set of parameters so maybe that's the way maybe it isn't because it does does make things kind of complicated elsewhere yeah it can be hard to figure out I mean it does allow you the more config parameters you have the more room you have to shoot yourself in the foot and we try and make that a bit simpler by having that default file so that there's a whole bunch of stuff in there that hopefully you never need to see or change unless you're really interested in kind of trying an experimental setting or something like that but that kind of does have to trade off of having yet another config file which you're kind of looking at and if you do want to use those settings then you need to start copying and pasting and working out what is this overriding that thing and that kind of thing so you know there's a lot of trade-offs going on here yes I mean vanilla open sim kit is kind of I mean and you know that is for kind of the experts really in a sense I mean when we produce a release for instance I do I do fill it with a few of the config settings to make it simpler like for instance as I kind of mentioned earlier the delete scripts on startup becomes false whereas in the source tree it's true so there's a few things we fiddle with for the actual releases but yeah I mean if you're using kind of the source the open sim kit code and it is more complicated but I think that's kind of I don't know it's hard to do anything about this without causing problems elsewhere I think yeah so yeah I mean the distributions do make it simpler they do make it and there's been stuff which is always you know because it's the O.S. Crit district it's always pretty cutting edge if one didn't want to stay with that and to be honest I think Robert was saying earlier and this is something I didn't put in the presentation there was actually and I didn't actually realize this is one of the things I didn't realize this was this is code in there since 2009 but there is a hidden piece of code to read a config directory if you have a config directory you can actually put an any file in that to actually override things without having to change your open sim not any for instance which can be handy if you if you don't want to reintegrate if you're following open sim releases and you don't want to reintegrate all your settings every time because I know we do this do this annoying thing where we say well if you change anything and you upgrade open sim you've got to manually pull your changes over you can't just dump in your any file and we say that because in the past we've found that when somebody does that there's a hard there if because there are a lot of settings if somebody does that and then there's a new setting being introduced with a default which which doesn't actually work with their other settings then you can end up as somebody said earlier in the chat you can end up with obscure errors which are very difficult to pin down so maybe maybe that's something we can look at and actually having because that conflict directly doesn't actually seem quite good and if you can actually dump your settings in there and kind of this is kind of taking the defaults one layer further almost though but maybe that's not a bad thing you kind of dump your settings in there and they end up overriding well whatever's an open sim.ini and that ends up overriding defaults and you've got another layer but maybe maybe that would make sense so I mean there is probably room for improvement yes bullet sim is another would it be another interesting setting maybe I should have mentioned that which is the default the alternative physics engine in open sim which Robert Adams of who is here has worked on an awful lot because that is a really complicated area in itself but that is kind of shaping up nicely but it's still not the default because you know changing physics engine is kind of I mean it is a complicated piece of code and you want to make sure then it's going to be pretty it's going to be working pretty well and ODE I mean bullet sim is definitely getting there very quickly so when and the plan is after the next release then bullet sim will become the default pretty promptly and it will end up being the default soon but right now one can still experiment with it in 075 I think it was still pretty raw but in current development code now let me just find the setting actually if anybody isn't familiar with it I mean it's very early on it's kind of right up at startup right so startup section so it's the one if you're going if you're going to startup and let me find it properly and okay interesting it's not in mine probably because I've done stunning study when I'm looking at the wrong file I expect I shouldn't look at D4 yeah I'm looking at the defaults file doesn't really help okay right I mean there's a setting yeah in the startup so in the startup section where it says physics yeah exactly Marx he just pasted it in the default is open dynamics engine but if one wants to experiment with bullet sim then you just uncomment the bullet sim line sorry and comment out the open dynamics engine line so if I were to when if I paste it it wouldn't work but basically uh yeah basically you uncomment the bullet sim line by removing the semi-carillon as I'm sure you all wear and comment the open dynamics engine line by putting in a semi-carillon at the start and and then you'll be trying the bullet sim engine and in 075 it was still probably pretty raw really but certainly in current development code it is it's come along an awful long way and in fact it's what we're using in the conference when I say this and we are actually using bullet sim so that's how good it is we are we've been able to run this whole conference on that so really you'd say yeah it's it does actually getting there Justin it probably should be the default but me being the conservative person that I am I think it would be nice just to put one final release out with ODE and then very quickly kind of switch over and I'm just double checking that that is the case and I'm not just told you the wrong thing default scripting and yes there we go physics equals bullet sim so actually this is probably something I should go through say very quickly if you've ever wanted to see exactly what config open sim is actually using from all these config files at a terminal you can type config show and that will show that will probably it'll be quite a lot it will show you the entire actual loaded config settings but if you say if you're on a particular section if you say config show startup for instance that would show you only the startup section of config so that's one way of checking what has actually been loaded from all those different .illy files into config so thank you very much everybody I know we're at 31 past the hour now so at the official end and for the people who are still here thanks a lot for coming to the conference it's been it's been worth a lot better than I think we could possibly have hoped for so that's been really really great we had a few hiccups of course like the keynote one today but apart from that it's been and a few little other odds and ends but really nothing that can be handled so it's gone remarkably well and of course a lot of this has been kind of performance improvements lately to get the conference going but all this will be in the next release which hopefully won't be won't be too far behind we'll come out pretty soon now so thanks very much