Re: [Opensim-dev] Error detection when storing an asset
Hi Oren, I disagree about propagating exceptions. To the caller, asset calls are opaque and cannot fail. There are too many places where exceptions would cause issues and the focus has always been on keeping the sim up and running at almost any cost. That said, no old asset servers (UGAIM) exist anymore, so the comment and the bad handling of null returns should be fixed. I would like to see assets being cached on asset server failure, but then retried using a disk based queue with exponential back-off. Allowing an asset to fail storing is better than having the sim crash, but of course storing it as soon as the asset server is back is preferable. We have something similar, but memory based, for Avination and it has served us well. I believe even our code may still have the bad return calue checking in it. I will see about putting our asset retry code into core as a starting point, then the rough edges can be smoothed and disk based queueing introduced so that assets can be retried even across a simulator restart. - Melanie On 18 Apr 2014, at 10:44, Oren Hurvitz or...@kitely.com wrote: I have found that when OpenSim tries to store an asset using AssetServicesConnector, it doesn't handle failures well. There are several problems in AssetServicesConnector.Store(), and some of them seem to be based on historical considerations that may no longer be relevant, so I'd like to see if anyone knows about these issues before pushing a change. AssetServicesConnector.Store() uses SynchronousRestObjectRequester to send the request. The first problem is that SynchronousRestObjectRequester.MakeRequest() hides exceptions and just returns null. This is a mistake: MakeRequest() should propagate exceptions, so that callers will know that an error occurred. Store() already catches these exceptions (as it should), so this won't make a big difference in our case. But of course, this change in behavior to MakeRequest() may affect other places in the code as well. It's better to fail-fast when errors occur, and not hide them, because doing so makes the errors much harder to diagnose once they become apparent. This brings me to the next problem... The second problem is that AssetServicesConnector.Store() compares the return value from MakeRequest to string.Empty, but in fact the return value that is returned in case of error is null. So it mistakenly treats 'null' as a valid Asset ID, which causes it to cache the asset. This can cause the operation to appear to have succeeded for a while, since OpenSim will have the asset available, but the moment the asset is loaded from the asset server the jig is up and the asset will be missing. This can explain many problems people have had with disappearing assets. The third problem is a comment found in this method, which says that a return value of 'null' is considered to be success because of old asset servers that don't send any reply back. That's a really old comment (from 2009). Can I assume that we no longer need to support such servers and we can treat 'null' as the error value that it is? Oren ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Error detection when storing an asset
In most cases there is no viable failure path that does not detrimentally affect user experience. The viewer is unable to handle asset upload failure gracefully and transparently to the user. As far as messge queues go, I have in-depth knowledge of MQ Series, IBM's message queue service. I agree that such a framework would be beneficial to many communications tasks in OpenSim, but that is, as you say, a matter for another day. The asset subsystem, however, should present an error-free interface to the upper layers, as there is much code that depends on assets never failing and provides no usable error path. Our retry solution combines a good user experience without user visible error messages with a sound subsystem that can tolerate transient erros like asset server failovers, net glitches or temporary overload conditions. Asset writing, btw, is not related to wearing clothing as baked textures do not go to the asset server, but to the XBakes server. In standalones, they are not persisted but are transferred from one region to another. Your obeservation about message queueing is a good one, I may spend a few cycles to see if an appropriately licensed implementation in C# exists. - Melanie On 18 Apr 2014, at 13:05, Oren Hurvitz or...@kitely.com wrote: Regarding the hiding of exceptions: to be clear, I was already bitten by this behavior; that's why I started to investigate how assets are stored. I have therefore already changed Kitely's version of OpenSim to propagate exceptions, and the question is whether other people would like me to contribute this change. If anyone has an opinion then please reply. Regarding your suggestion to save assets to local disk and retry them later: this is basically what a persistent message queue does. If you're going to go that route then it would be best to add a real message queue rather than a home-grown one. I would LOVE it if OpenSim used a message queue for communications, as it would allow ripping out thousands of lines of homemade communications code, and would be faster and more reliable to boot. But that's a bigger issue and I'll put it aside for now. In this particular case, using a persistent message queue isn't be the right solution: the right solution is to report failures immediately. Otherwise you'd get weird behavior such as a user who thinks they've successfully worn a piece of clothing, but when they teleport to another region it disappears because the other region can't load the asset (because it was never saved). To prevent these problems you need to fail-fast, and tell the user immediately when a problem happens. This doesn't mean to crash the sim; I strongly doubt any asset failure would cause that, it would just fail the specific packet or message that is currently being handled, as it should. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-asset-tp7579223p7579225.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Error detection when storing an asset
Name one valid use case where current OpenSim is able to handle such an exception gracefully, e.g. without user-visible error. - Melanie On 18/04/2014 13:28, Mike Chase wrote: I'm inclined to agree with Oren. Asset Writes could fail for a variety of reasons and there are lots of use cases where you need to know the asset is on disk. I think propagating exceptions is the more sound approach IMO. I also agree re: the custom comms vs a persistent queue mechanism but I don't want to derail this topic. That can wait for another day. Mike -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Oren Hurvitz Sent: Friday, April 18, 2014 7:06 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Error detection when storing an asset Regarding the hiding of exceptions: to be clear, I was already bitten by this behavior; that's why I started to investigate how assets are stored. I have therefore already changed Kitely's version of OpenSim to propagate exceptions, and the question is whether other people would like me to contribute this change. If anyone has an opinion then please reply. Regarding your suggestion to save assets to local disk and retry them later: this is basically what a persistent message queue does. If you're going to go that route then it would be best to add a real message queue rather than a home-grown one. I would LOVE it if OpenSim used a message queue for communications, as it would allow ripping out thousands of lines of homemade communications code, and would be faster and more reliable to boot. But that's a bigger issue and I'll put it aside for now. In this particular case, using a persistent message queue isn't be the right solution: the right solution is to report failures immediately. Otherwise you'd get weird behavior such as a user who thinks they've successfully worn a piece of clothing, but when they teleport to another region it disappears because the other region can't load the asset (because it was never saved). To prevent these problems you need to fail-fast, and tell the user immediately when a problem happens. This doesn't mean to crash the sim; I strongly doubt any asset failure would cause that, it would just fail the specific packet or message that is currently being handled, as it should. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-ass et-tp7579223p7579225.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Error detection when storing an asset
The point is no NOT let it fail. Asset storing never fails permanently if it's retried until successful. The upper layers (all the way to the viewer) are not equipped to handle an asset storing failure. Propagating the exception would just annoy the user with needless messages. Since asset servers can be gone for a while, for instance when there is a net failure, there is no way to give it a timeout, either. A sim in OSGrid, if it gets disconnected, could run on locally cached assets and manage to reconnect after 20 minutes and simply upload all new assets since then. Screaming failure at the user is pointless in such a scenario. - Melanie On 18/04/2014 22:56, Oren Hurvitz wrote: There seems to be a misunderstanding here. We're talking about a case where the operation has FAILED. The only question is whether to pretend that it succeeded, so that the user will find out that it failed later, to their surprise, or to report failure immediately. Obviously it's better to report failure immediately. On Fri, Apr 18, 2014 at 10:40 PM, Melanie mela...@t-data.com wrote: Name one valid use case where current OpenSim is able to handle such an exception gracefully, e.g. without user-visible error. - Melanie On 18/04/2014 13:28, Mike Chase wrote: I'm inclined to agree with Oren. Asset Writes could fail for a variety of reasons and there are lots of use cases where you need to know the asset is on disk. I think propagating exceptions is the more sound approach IMO. I also agree re: the custom comms vs a persistent queue mechanism but I don't want to derail this topic. That can wait for another day. Mike -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Oren Hurvitz Sent: Friday, April 18, 2014 7:06 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Error detection when storing an asset Regarding the hiding of exceptions: to be clear, I was already bitten by this behavior; that's why I started to investigate how assets are stored. I have therefore already changed Kitely's version of OpenSim to propagate exceptions, and the question is whether other people would like me to contribute this change. If anyone has an opinion then please reply. Regarding your suggestion to save assets to local disk and retry them later: this is basically what a persistent message queue does. If you're going to go that route then it would be best to add a real message queue rather than a home-grown one. I would LOVE it if OpenSim used a message queue for communications, as it would allow ripping out thousands of lines of homemade communications code, and would be faster and more reliable to boot. But that's a bigger issue and I'll put it aside for now. In this particular case, using a persistent message queue isn't be the right solution: the right solution is to report failures immediately. Otherwise you'd get weird behavior such as a user who thinks they've successfully worn a piece of clothing, but when they teleport to another region it disappears because the other region can't load the asset (because it was never saved). To prevent these problems you need to fail-fast, and tell the user immediately when a problem happens. This doesn't mean to crash the sim; I strongly doubt any asset failure would cause that, it would just fail the specific packet or message that is currently being handled, as it should. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Error-detection-when-storing-an-ass et-tp7579223p7579225.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Legacy region XML support - Remove?
Yes - Melanie On 12/04/2014 14:27, David Saunders wrote: Hey I Just dug though my web based region file, and its base on a single line XML format region name= location_x= ... / Would this be needed to updated with this proposal? On Sat, Apr 12, 2014 at 1:36 AM, Michael Emory Cerquoni nebadon2...@gmail.com wrote: +1 the only grid I know that probably was using it was Reaction Grid, and they are no longer open so I also doubt anyone else is using it at this point either. On Sat, Apr 12, 2014 at 3:14 AM, Justin Clark-Casey jjusti...@googlemail.com wrote: I don't see any problem with removing this - it's an extremely old format that I'd be surprised if anybody still uses. On 11/04/14 02:03, Melanie wrote: Hi, the RegionInfo class supports an ancient form of XML, one that is based on attributes rather than tags. At this point, we believe no one uses this format anymore. Further, NINI offers another form of XML that is much more up to date and a better replacement for the ancient XML in any case. The affected installations would be those that use pre-0.6 configuration files (regions.xml) or use web loading. The old config files would need to be redone by hand in .ini format, and people who web-load would need to change the server scripts to provide the same data in the new format, which is not too hard a task. I propose to remove the support for the legacy format, which has last been updated in 2007 and has been unused for two major revisions. Thoughts are welcome. Melanie ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev . -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Michael Emory Cerquoni ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Legacy region XML support - Removed!
I have now removed support for the legacy format. The new format for XML, both for files and for web loading, is below: Nini Section Name=Region Name Key Name=RegionUUID Value=acae2f54-24fc-427f-92b0-7c3d6a5597d4 / Key Name=Location Value=981,1009 / Key Name=InternalAddress Value=1.2.3.4 / Key Name=InternalPort Value=9000 / Key Name=AllowAlternatePorts Value=false / Key Name=ExternalHostName Value=1.2.3.4 / Key Name=NonPhysicalPrimMax Value=1024 / Key Name=PhysicalPrimMax Value=64 / Key Name=ClampPrimSize Value=false / Key Name=MaxPrims Value=45000 / Key Name=MaxAgents Value=100 / /Section /Nini Multiple Section statements can be placed within Nini. - Melanie ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Legacy region XML support - Remove?
That format needs to be changed. The old format is: region name= location_x= ... / The new format will be: Nini Section name=Region_1 key name=Name value= / key name=Location_x value= / /Section /Nini Server script that generate the old format dynamically need to be changed to generate the new format instead, - Melanie ... /region On 11/04/2014 15:35, David Saunders wrote: How does this relate to the XML format for web configuration? On Fri, Apr 11, 2014 at 7:10 AM, R.Gunther ri...@rigutech.nl wrote: Suprissed its still there, well people did have time enough to change the xml files to ini files on newer versions. For me, using long time ini files so you can remove it. On 2014-04-11 03:03, Melanie wrote: Hi, the RegionInfo class supports an ancient form of XML, one that is based on attributes rather than tags. At this point, we believe no one uses this format anymore. Further, NINI offers another form of XML that is much more up to date and a better replacement for the ancient XML in any case. The affected installations would be those that use pre-0.6 configuration files (regions.xml) or use web loading. The old config files would need to be redone by hand in .ini format, and people who web-load would need to change the server scripts to provide the same data in the new format, which is not too hard a task. I propose to remove the support for the legacy format, which has last been updated in 2007 and has been unused for two major revisions. Thoughts are welcome. Melanie ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Parcel Access Enforcement
The code for parcel access works, as far as I'm aware. It was originally fixed in Avination and that should have been donated to OpenSim a long time ago. Maybe a good starting point is to see what you would like that doesnt' work before you go and fix things that aren't broken. Melanie On 10/04/2014 17:05, James Stallings II wrote: Subsequent work (instrumentation to Scene) shows that the permissions checking code is also being called twice there. Cheers James On Thu, Apr 10, 2014 at 9:30 AM, James Stallings II james.stalli...@gmail.com wrote: After some further exploration, I have seen where the method calls taking precedence from out of Scene are handling ViaLogin; but they are also doing some of the same lifting performed in the Land Management module. This seems to be duplication of effort, if not duplication of code; and is certainly less elegant than I would hope to find in our codebase (in an ideal world ;) This is likely the result of the ad-hoc nature of the development life of the project over the years; I can see the scene code being a good deal older than the Land Management module. I'll be working with this throughout the day, hoping to improve the code as I'm able; your thoughts, advice and commentary are solicited and appreciated. Cheers James On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II james.stalli...@gmail.com wrote: Greetings Devs :) I have a use case that requires the unlikely and less than popular parcel permissions access control featureset. Historically speaking, this has not been an area of development that has seen much love, and understandably so; none of us are particularly interested in fully duplicating the operational envelope of the Second Life experience. That coupled with the ability to deploy regions at whim, it is no wonder no one wants to involve themselves particularly deeply with making this work properly. That being said, I have a need at present, and there is also the simple fact that we have a dearth of UI components in the viewer we may well never get shut of, and a lot of of unfinished and/or unpolished code in the repo that touches on this functionality. The short story is, it may be above the waterline, but there is a hole in the boat, and one of my users is driving it headlong into the surf. So much for metaphors. I have heard a variety of conflicting reports about the state of this part of the codebase; some say it works well; others say it should not be counted on to work at all. The commit logs tell the tale that some have taken an interest and are working diligently to eliminate certain bugs; unfortunately, the work in progress has not yet brought the functionality into a state where it is yet useful, at least according to my testing. I'm not unwilling to undertake the work needed to bring this situation into a more satisfactory light; indeed, I've already begun, and I need only a little guidance today. I have thoroughly instrumented the method public void EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int localLandID, UUID regionID) in the land management module, and was immediately confronted with a couple of surprises: First, when the code is called at all, it is called twice; and as far as I can tell, it is called only after a successful login has been completed. Neither does it seem to be called when an avatar teleports into the region. Instead, the method public bool TestLandRestrictions(UUID agentID, out string reason, ref float posX, ref float posY) is called from OpenSim/Region/Framework/Scenes/Scene.cs and OpenSim/Region/Framework/Scenes/ScenePresence.cs, and mediates (rather less than consistently) whether the avatar is allowed into the parcel on the region. Being aware that there are several ways for an avatar to enter a parcel, which I will leave off enumerating at present, I would suggest that perhaps I have some misapprehensions as to the proper stages of authentication at login-time. So my question is this: should both of these functions come into play as an avatar enters a region (and consequently, a parcel)? or should there be a single methoid conducting these presence permission checks? Please advise at your convenience :) Many thanks and cheers James/Hiro -- === http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -- === http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Parcel Access Enforcement
I'm not even being defensive. I just don't like the idea of poking code with a sharp stick instead of debugging it properly. - Melanie On 10/04/2014 17:20, James Stallings II wrote: Maybe a good starting point is to see what you would like that doesnt' work before you go and fix things that... Actually, that *is* where I began. My user reports various failures, which are repeatable on the running regions. No amount of reconfiguration predictably affects the experience on the regions. We do have a couple of regions that seem to work perfectly, including that which I'm working with; it started working after I completely replaced the OpenSim.ini with one that was identical excepting the http_listener specifcation. Unfortunately, repeating this process with the same OpenSim.ini on a different region that doesn't work did not produce a region that does. To say that it works intermittently is a bit of an understatement; though it does seem that once it begins working it continues to do so. Try not to be so defensive Mel; I'm not attacking you or your work, I'm just attempting to figure out what's happening on these regions. I have eliminated everything I can find but the code, which I am told by others is not to be trusted as fully functional; and I am not afraid to get in and get my hands dirty. Cheers James On Thu, Apr 10, 2014 at 10:10 AM, Melanie mela...@t-data.com wrote: The code for parcel access works, as far as I'm aware. It was originally fixed in Avination and that should have been donated to OpenSim a long time ago. Maybe a good starting point is to see what you would like that doesnt' work before you go and fix things that aren't broken. Melanie On 10/04/2014 17:05, James Stallings II wrote: Subsequent work (instrumentation to Scene) shows that the permissions checking code is also being called twice there. Cheers James On Thu, Apr 10, 2014 at 9:30 AM, James Stallings II james.stalli...@gmail.com wrote: After some further exploration, I have seen where the method calls taking precedence from out of Scene are handling ViaLogin; but they are also doing some of the same lifting performed in the Land Management module. This seems to be duplication of effort, if not duplication of code; and is certainly less elegant than I would hope to find in our codebase (in an ideal world ;) This is likely the result of the ad-hoc nature of the development life of the project over the years; I can see the scene code being a good deal older than the Land Management module. I'll be working with this throughout the day, hoping to improve the code as I'm able; your thoughts, advice and commentary are solicited and appreciated. Cheers James On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II james.stalli...@gmail.com wrote: Greetings Devs :) I have a use case that requires the unlikely and less than popular parcel permissions access control featureset. Historically speaking, this has not been an area of development that has seen much love, and understandably so; none of us are particularly interested in fully duplicating the operational envelope of the Second Life experience. That coupled with the ability to deploy regions at whim, it is no wonder no one wants to involve themselves particularly deeply with making this work properly. That being said, I have a need at present, and there is also the simple fact that we have a dearth of UI components in the viewer we may well never get shut of, and a lot of of unfinished and/or unpolished code in the repo that touches on this functionality. The short story is, it may be above the waterline, but there is a hole in the boat, and one of my users is driving it headlong into the surf. So much for metaphors. I have heard a variety of conflicting reports about the state of this part of the codebase; some say it works well; others say it should not be counted on to work at all. The commit logs tell the tale that some have taken an interest and are working diligently to eliminate certain bugs; unfortunately, the work in progress has not yet brought the functionality into a state where it is yet useful, at least according to my testing. I'm not unwilling to undertake the work needed to bring this situation into a more satisfactory light; indeed, I've already begun, and I need only a little guidance today. I have thoroughly instrumented the method public void EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int localLandID, UUID regionID) in the land management module, and was immediately confronted with a couple of surprises: First, when the code is called at all, it is called twice; and as far as I can tell, it is called only after a successful login has been completed. Neither does it seem to be called when an avatar teleports into the region
Re: [Opensim-dev] Parcel Access Enforcement
No biting needed :) Debug output is a pretty good start and you did answer my concern when you mentioned the intermittent nature of the issue. I was worried that this would lead to a refactoring frenzy, possibly breaking even the parts that do work, but the fact that it's not consistently reproducible means that you're doing the proper debugging already. - Melanie On 10/04/2014 17:52, James Stallings II wrote: So, Melanie, I'll bite: What do you suggest for 'proper debugging' in this context? On Thu, Apr 10, 2014 at 10:25 AM, James Stallings II james.stalli...@gmail.com wrote: The only code I'm affecting the local copy on my server; it isn't as if I'm going to break break the central repo back to 2006. Hell, I don't even have commit. And FWIW, last I hear adding log statements to code is a valid tried and true debugging method. On Thu, Apr 10, 2014 at 10:23 AM, Melanie mela...@t-data.com wrote: I'm not even being defensive. I just don't like the idea of poking code with a sharp stick instead of debugging it properly. - Melanie On 10/04/2014 17:20, James Stallings II wrote: Maybe a good starting point is to see what you would like that doesnt' work before you go and fix things that... Actually, that *is* where I began. My user reports various failures, which are repeatable on the running regions. No amount of reconfiguration predictably affects the experience on the regions. We do have a couple of regions that seem to work perfectly, including that which I'm working with; it started working after I completely replaced the OpenSim.ini with one that was identical excepting the http_listener specifcation. Unfortunately, repeating this process with the same OpenSim.ini on a different region that doesn't work did not produce a region that does. To say that it works intermittently is a bit of an understatement; though it does seem that once it begins working it continues to do so. Try not to be so defensive Mel; I'm not attacking you or your work, I'm just attempting to figure out what's happening on these regions. I have eliminated everything I can find but the code, which I am told by others is not to be trusted as fully functional; and I am not afraid to get in and get my hands dirty. Cheers James On Thu, Apr 10, 2014 at 10:10 AM, Melanie mela...@t-data.com wrote: The code for parcel access works, as far as I'm aware. It was originally fixed in Avination and that should have been donated to OpenSim a long time ago. Maybe a good starting point is to see what you would like that doesnt' work before you go and fix things that aren't broken. Melanie On 10/04/2014 17:05, James Stallings II wrote: Subsequent work (instrumentation to Scene) shows that the permissions checking code is also being called twice there. Cheers James On Thu, Apr 10, 2014 at 9:30 AM, James Stallings II james.stalli...@gmail.com wrote: After some further exploration, I have seen where the method calls taking precedence from out of Scene are handling ViaLogin; but they are also doing some of the same lifting performed in the Land Management module. This seems to be duplication of effort, if not duplication of code; and is certainly less elegant than I would hope to find in our codebase (in an ideal world ;) This is likely the result of the ad-hoc nature of the development life of the project over the years; I can see the scene code being a good deal older than the Land Management module. I'll be working with this throughout the day, hoping to improve the code as I'm able; your thoughts, advice and commentary are solicited and appreciated. Cheers James On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II james.stalli...@gmail.com wrote: Greetings Devs :) I have a use case that requires the unlikely and less than popular parcel permissions access control featureset. Historically speaking, this has not been an area of development that has seen much love, and understandably so; none of us are particularly interested in fully duplicating the operational envelope of the Second Life experience. That coupled with the ability to deploy regions at whim, it is no wonder no one wants to involve themselves particularly deeply with making this work properly. That being said, I have a need at present, and there is also the simple fact that we have a dearth of UI components in the viewer we may well never get shut of, and a lot of of unfinished and/or unpolished code in the repo that touches on this functionality. The short story is, it may be above the waterline, but there is a hole in the boat, and one of my users is driving it headlong into the surf. So much for metaphors. I have heard a variety of conflicting reports about
Re: [Opensim-dev] Parcel Access Enforcement
The QueryAccess is a pre-authorization. So the double call is intentional and unavoidable. - Melanie On 10/04/2014 18:14, James Stallings II wrote: It would seem that the two invocations of the TestLandRestrictions method in Scene occur in each of NewUserConnection and QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly obviously, and event callback method; at this point I don't have but a guess where this might be called excepting from within EventManagerOnSignificantClientMovement. I'd like to think that the two calls to TestLandRestrictions in Scene might be reduced to one; but I'm not yet convinced it is the way to go. More to follow. Cheers On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. rk...@pobox.comwrote: On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: And FWIW, last I hear adding log statements to code is a valid tried and true debugging method. I wish to subscribe all of my students in my programming class to your newsletter. (The number of times I told them to print stuff to figure out where the code was, and the number of times I told them to print in more places, was phenomenal. They got tired of hearing me say it, but somehow still needed to hear it.) (They often needed similar guidance in figuring out how to use breakpoints in debuggers.) -Rob -- --Rob Knop E-mail:rk...@pobox.com Home Page: http://www.pobox.com/~rknop/ Blog: http://www.galacticinteractions.org/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Parcel Access Enforcement
It used to go through event manager - an ancient way of doing it. - Melanie On 10/04/2014 18:44, James Stallings II wrote: There are still getters and setters on the property, but I cant ref the config point anywhere On Thu, Apr 10, 2014 at 11:43 AM, James Stallings II james.stalli...@gmail.com wrote: Mel, cant get a grep on allow_f* anywhere in the source tree, looks like it has gone the way of the elves On Thu, Apr 10, 2014 at 11:37 AM, James Stallings II james.stalli...@gmail.com wrote: I thought I recalled such a thing, been about as long since I looked at it ;) Thanks Mel James On Thu, Apr 10, 2014 at 11:37 AM, Melanie mela...@t-data.com wrote: Yes. allow_forceful_banlines, I believe. Long time since I looked at it. - Melanie On 10/04/2014 18:33, James Stallings II wrote: Quick question (related) is there a configuration point I'm missing that enables 'forceful bans'? On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II james.stalli...@gmail.com wrote: I kinder suspected something to that effect. It goes without saying that a lot occurs during the login process than is immediately apparent when one sits and watches the consoles. Right now I'm leaning towards the previously-mentioned edge case. On Thu, Apr 10, 2014 at 11:29 AM, Melanie mela...@t-data.com wrote: The QueryAccess is a pre-authorization. So the double call is intentional and unavoidable. - Melanie On 10/04/2014 18:14, James Stallings II wrote: It would seem that the two invocations of the TestLandRestrictions method in Scene occur in each of NewUserConnection and QueryAccess. EventManagerOnAvatarEnteringNewParcel is, fairly obviously, and event callback method; at this point I don't have but a guess where this might be called excepting from within EventManagerOnSignificantClientMovement. I'd like to think that the two calls to TestLandRestrictions in Scene might be reduced to one; but I'm not yet convinced it is the way to go. More to follow. Cheers On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. rk...@pobox.com wrote: On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings II wrote: And FWIW, last I hear adding log statements to code is a valid tried and true debugging method. I wish to subscribe all of my students in my programming class to your newsletter. (The number of times I told them to print stuff to figure out where the code was, and the number of times I told them to print in more places, was phenomenal. They got tired of hearing me say it, but somehow still needed to hear it.) (They often needed similar guidance in figuring out how to use breakpoints in debuggers.) -Rob -- --Rob Knop E-mail:rk...@pobox.com Home Page: http://www.pobox.com/~rknop/ Blog: http://www.galacticinteractions.org/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- === http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- === http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 -- === http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] Legacy region XML support - Remove?
Hi, the RegionInfo class supports an ancient form of XML, one that is based on attributes rather than tags. At this point, we believe no one uses this format anymore. Further, NINI offers another form of XML that is much more up to date and a better replacement for the ancient XML in any case. The affected installations would be those that use pre-0.6 configuration files (regions.xml) or use web loading. The old config files would need to be redone by hand in .ini format, and people who web-load would need to change the server scripts to provide the same data in the new format, which is not too hard a task. I propose to remove the support for the legacy format, which has last been updated in 2007 and has been unused for two major revisions. Thoughts are welcome. Melanie ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSimDefaults.ini clean up
The GUI configurator doesn't even exist yet. It's not proprietary, it's just not done yet. The work was put in to create this formatting to encourage the creation of such a GUI tool. It will certainly not be removed. - Melanie On 08/04/2014 16:32, James Stallings II wrote: I think if any of this is touched, it should be to the OpenSim.ini file, to remove the proprietary formatting for the gui configurator that is not present in opensim core. For my part, it isn't a problem; but as far as I'm concerned modifying the format of OpenSimDefaults.ini is probably going at it a bit backward. Cheers James On Tue, Apr 8, 2014 at 9:19 AM, Shaun T. Erickson s...@smxy.org wrote: Yeah, I would definitely vote against moving things to the end of sections. It's perfectly fine to have, say: A B C D E in the defaults file, but only have, say: A C E in OpenSim.ini.example. -ste On 4/8/14, 7:49 AM, Jak Daniels wrote: +1 for this, however moving things in defaults that are not in example to the end of a section, particularly in the larger sections might move a setting more out of context and make the defaults file less readable. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSimDefaults.ini clean up
I'm also against moving things to the end of sections. Having the options present in Opensim.ini in the same order as in the defaults file makes sense for diffing, but moving them to the end of sections does not because it would cause the readability issues mentioned as well as make it even more confusing if someone copies a section to their ini from the defaults file, breaking that scheme. The defaults file is overwritten in every update. - Melanie On 08/04/2014 16:19, Shaun T. Erickson wrote: Yeah, I would definitely vote against moving things to the end of sections. It's perfectly fine to have, say: A B C D E in the defaults file, but only have, say: A C E in OpenSim.ini.example. -ste On 4/8/14, 7:49 AM, Jak Daniels wrote: +1 for this, however moving things in defaults that are not in example to the end of a section, particularly in the larger sections might move a setting more out of context and make the defaults file less readable. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSimDefaults.ini clean up
Well, you're familiar with the command line, which many are now. Also, without cygwin, Windows is somewhat command line challenged. As for the proprietary bit - Avination does not use ini files. This encoding was done for the benefit of the open source community, we ourselves have no need of it. Melanie On 09/04/2014 00:45, James Stallings II wrote: Actually Mel, I would not suggest that you do so. I've found some fairly useful workflows involving the shell utilities find, diff, grep and sed that really kind of move such concerns aside, allowing me to analyze and/or edit large groups of files all in one big glorious command line invocation :3 Note that heavy CYA safety nets are in place ;) It isn't especially advanced by way of technique what I'm doing, really just using those tools together for their intended purposes. If someone does get around to writing a gui configurator, that would be awesome (/me pokes marcus) Sorry for the confusion about the proprietary nature of the thing Mel, I guess I got the wrong idea last time we spoke of it, and that has been quite some time. In any case, my strategy is basically to use grep as a filter to get rid of the 'comments' on the fly, single out things I need to compare, etc which I then pass to diff or sed. I use find to generate lists of paths to the files I need to compare or edit (or not, depending whether I'm working on files in bulk). It's kind of a cowboy way of doing things, but it's very quick and effective if you don't get too crazy with it. Safe too if you make sure to keep good backups. Cheers! James/Hiro On Tue, Apr 8, 2014 at 11:43 AM, Marcus Llewellyn marcus.llewel...@gmail.com wrote: In regard to the specially formatted comments meant to aid external configuration tools, it may be worth considering adding these to OpenSimDefaults.ini. Currently, OpenSim.ini.example contains them, but OpenSimDefaults does not. When one strips OpenSim.ini.example down to *only* active sections, keys, and values while including those configuration comments, you end up easily seeing that every single option is being paired with a special configuration comment. On the other hand, if you do the same thing to a grid's OpenSim.ini file (I used OSgrid's), it becomes much less consistent. Sections like Startup or XEngine will only have a few of these config/option pairings. Some sections like RegionReady, VivoxVoice, and BulletSim have none at all. The authors of these OpenSIm.ini files aren't at fault. They simply have more imperative things to do than track down all of the possible option values or dependencies. Since, presumably, options added to OpenSim.ini files like OSgrid's are largely derived from OpenSimDefaults.ini, it could be of benefit to provide the config comments in OpenSimDefaults as well. OpenSim.ini.example is setup only for standalones. Simulators configured for grids obviously use more options (about 7 times the options in OSgrid's case). Any future configuration tool would probably be most useful on configuration files meant for either mode of operation. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] REST handlers use partial string matching
Thanks, that was a good catch! Melanie On 02/04/2014 08:07, Oren Hurvitz wrote: I changed BaseHttpServer to require handler paths to match a full path component. For example, these match: /assets and /assets/12345 But these don't match: /assets and /assets_exist -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579140.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Viewer doesn't render attachments after teleport
I don't know if this may be related, but for some reason OpenSim fails to update the viewer's notion of position properly. The most noticeable effect is that sometimes after changing regions or even parcels, sound is no longer heard. The audibility check happens viewerside, just as the object visibility check. If the viewer gets a wrong location, it may consider the attachments as too far away and not render them - that is probably related to why zooming can make them appear. Therefore I don't believe we need to send any extra packets related to these objects, but rather we are missing some packet or sending wrong data related to the avatar's location. This appears to be the case on moving in world as well as teleports, but I have so far never observed it at login. Melanie On 02/04/2014 13:16, Oren Hurvitz wrote: I got some great advice off-list from Nicky Perian. When there's a problem of missing prims, go to the Graphics Preferences and toggle the option Basic shaders. I tried this, and toggling this option (on or off, both work) makes the missing prims appear immediately. This proves that the viewer has the correct data, and it's just not showing it. But I still want to find some combination of packets that will make the viewers show the prims, since obviously most users will not know to use this trick, and it's a hassle. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143p7579146.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] REST handlers use partial string matching
The REST URLs need to use partial matching, however, current semantics are broken. Without partial matching, URLS like /assets/782911. would not work. the issue here is that it should match whole URL parts, not partial URL parts. Matching partial words as it does now seems like someone was cutting corners, it's not by design. /assets/ should match /assets/9887234.. but not /assets_exist. The slash is the differentiator and partial compares of URL string prefixes should be done by full-string matches of slash/delimited parts, not prefix matching of the entire URL. Melanie On 01/04/2014 15:00, Oren Hurvitz wrote: I tried to add a REST handler at the endpoint /assets_exist. It turns out that I can't do that, because REST handlers are searched using partial string matches, so servers that don't implement the new handler will mistakenly choose the /assets endpoint instead. For now, I solved the problem by using a different endpoint: /get_assets_exist. For the future, I think that this should be changed so that only full string matches work. Otherwise each time a new handler is added it will have to find an endpoint name that isn't a prefix of any current endpoint -- a difficult and error-prone task. Before I do that, does anyone know of endpoints that rely on the current behavior (partial string matches)? -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] REST handlers use partial string matching
It is required because it's the basis of extra path info. It's not part of REST, but rather part of HTTP. Requesting /asset/456392f6-c0b3-a346-6465-8218cbe7abe84592 which is not a registered URL, will invoke /asset/ which is. The ID passed as part of the URL is then given to that handler as the extra path info. You have the same thing in apache. Basically, any URL longer than and starting with a registered URL will invoke that registered URL with extra path info. The fallacy in our server is that the matching isn't by path parts, but character-wise. Melanie On 01/04/2014 20:03, Justin Clark-Casey wrote: In what context is such partial matching required? It is not a requirement of REST, as far as I know. On 01/04/14 18:55, Melanie wrote: The REST URLs need to use partial matching, however, current semantics are broken. Without partial matching, URLS like /assets/782911. would not work. the issue here is that it should match whole URL parts, not partial URL parts. Matching partial words as it does now seems like someone was cutting corners, it's not by design. /assets/ should match /assets/9887234.. but not /assets_exist. The slash is the differentiator and partial compares of URL string prefixes should be done by full-string matches of slash/delimited parts, not prefix matching of the entire URL. Melanie On 01/04/2014 15:00, Oren Hurvitz wrote: I tried to add a REST handler at the endpoint /assets_exist. It turns out that I can't do that, because REST handlers are searched using partial string matches, so servers that don't implement the new handler will mistakenly choose the /assets endpoint instead. For now, I solved the problem by using a different endpoint: /get_assets_exist. For the future, I think that this should be changed so that only full string matches work. Otherwise each time a new handler is added it will have to find an endpoint name that isn't a prefix of any current endpoint -- a difficult and error-prone task. Before I do that, does anyone know of endpoints that rely on the current behavior (partial string matches)? -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] REST handlers use partial string matching
The proper method is to break up the local portion of the URL into words using / as the separator, then matching that list of words against similar lists created from the registered URLs, usually stored as a tree. There are two ways to match, shortest match and more specific. The algorithm used by apache is shortest match, meaning that as soon as a word list is fully matched against the request's words, it's considered a match and the handler is invoked. Everything past the matched portion becomes extra path info. Melanie On 01/04/2014 21:08, Mic Bowman wrote: so what you're saying is just make sure the '/' is part of the match? to terminate the match? i think the problem is that /asset matches /asset_test which is not what is expected. so all registered partial matches should include the trailing '/' to disambiguate... or am i missing the point? On Tue, Apr 1, 2014 at 12:00 PM, Melanie mela...@t-data.com wrote: It is required because it's the basis of extra path info. It's not part of REST, but rather part of HTTP. Requesting /asset/456392f6-c0b3-a346-6465-8218cbe7abe84592 which is not a registered URL, will invoke /asset/ which is. The ID passed as part of the URL is then given to that handler as the extra path info. You have the same thing in apache. Basically, any URL longer than and starting with a registered URL will invoke that registered URL with extra path info. The fallacy in our server is that the matching isn't by path parts, but character-wise. Melanie On 01/04/2014 20:03, Justin Clark-Casey wrote: In what context is such partial matching required? It is not a requirement of REST, as far as I know. On 01/04/14 18:55, Melanie wrote: The REST URLs need to use partial matching, however, current semantics are broken. Without partial matching, URLS like /assets/782911. would not work. the issue here is that it should match whole URL parts, not partial URL parts. Matching partial words as it does now seems like someone was cutting corners, it's not by design. /assets/ should match /assets/9887234.. but not /assets_exist. The slash is the differentiator and partial compares of URL string prefixes should be done by full-string matches of slash/delimited parts, not prefix matching of the entire URL. Melanie On 01/04/2014 15:00, Oren Hurvitz wrote: I tried to add a REST handler at the endpoint /assets_exist. It turns out that I can't do that, because REST handlers are searched using partial string matches, so servers that don't implement the new handler will mistakenly choose the /assets endpoint instead. For now, I solved the problem by using a different endpoint: /get_assets_exist. For the future, I think that this should be changed so that only full string matches work. Otherwise each time a new handler is added it will have to find an endpoint name that isn't a prefix of any current endpoint -- a difficult and error-prone task. Before I do that, does anyone know of endpoints that rely on the current behavior (partial string matches)? -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] REST handlers use partial string matching
Well, with URLs, it's not known which part (word) of the url local part is a directory and which is a file/script. http://www.example.com/dir/file.php/extra/info is legal. At the time of parsing, it is not intrinsically knowable that file.php is a script. Therefore, you can't look at just the last element, but need to match wordwise left to right. Melanie On 01/04/2014 21:47, Jim Williams wrote: I think the correct way to look at this is that any URI /handler/... should be passed to the correct handler handler; which should then pass the rest of the path on to any sub-handlers as appropriate. You shouldn't be looking at the parts of a path element unless it is the leaf (follows the last slash). The URI began life as a directory tree, and you would not match part of the directory thinking it was a file. Any valid semantic URI parser will interpret elements of a URI strictly in context, and never assume anything about elements except within the context of the element to its immediate left. It would be ok for /asset and /asset_test to be treated as a match, but never ok for /asset/ and /asset_test or /asset_test/ to match. One is matching a directory to a file, and the other is matching two different directories. On Tue, Apr 1, 2014 at 3:08 PM, Mic Bowman cmick...@gmail.com wrote: so what you're saying is just make sure the '/' is part of the match? to terminate the match? i think the problem is that /asset matches /asset_test which is not what is expected. so all registered partial matches should include the trailing '/' to disambiguate... or am i missing the point? On Tue, Apr 1, 2014 at 12:00 PM, Melanie mela...@t-data.com wrote: It is required because it's the basis of extra path info. It's not part of REST, but rather part of HTTP. Requesting /asset/456392f6-c0b3-a346-6465-8218cbe7abe84592 which is not a registered URL, will invoke /asset/ which is. The ID passed as part of the URL is then given to that handler as the extra path info. You have the same thing in apache. Basically, any URL longer than and starting with a registered URL will invoke that registered URL with extra path info. The fallacy in our server is that the matching isn't by path parts, but character-wise. Melanie On 01/04/2014 20:03, Justin Clark-Casey wrote: In what context is such partial matching required? It is not a requirement of REST, as far as I know. On 01/04/14 18:55, Melanie wrote: The REST URLs need to use partial matching, however, current semantics are broken. Without partial matching, URLS like /assets/782911. would not work. the issue here is that it should match whole URL parts, not partial URL parts. Matching partial words as it does now seems like someone was cutting corners, it's not by design. /assets/ should match /assets/9887234.. but not /assets_exist. The slash is the differentiator and partial compares of URL string prefixes should be done by full-string matches of slash/delimited parts, not prefix matching of the entire URL. Melanie On 01/04/2014 15:00, Oren Hurvitz wrote: I tried to add a REST handler at the endpoint /assets_exist. It turns out that I can't do that, because REST handlers are searched using partial string matches, so servers that don't implement the new handler will mistakenly choose the /assets endpoint instead. For now, I solved the problem by using a different endpoint: /get_assets_exist. For the future, I think that this should be changed so that only full string matches work. Otherwise each time a new handler is added it will have to find an endpoint name that isn't a prefix of any current endpoint -- a difficult and error-prone task. Before I do that, does anyone know of endpoints that rely on the current behavior (partial string matches)? -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev
Re: [Opensim-dev] REST handlers use partial string matching
HEAD is meant to test if a request endpoint is implemented and to retrieve metadata like detailed capabilities/options/flags. Melanie On 01/04/2014 21:49, Oren Hurvitz wrote: Re: why use POST instead of HEAD: because this lets me check the existence of many assets at once with a single HTTP request. The main use of the AssetsExist call is with HGAssetGatherer, which knows the full list of assets that it wants to send, so it's able to check all of them at once. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] REST handlers use partial string matching
Because REST is cleaner and more modularized than RPC. Just compare the code and you will see that. Efficiency is achieved by designing the REST calls intelligently. The /asset/ endpoint for instance can benefit from keep-alive because it supports HEAD/GET?POST so multiple operations can reuse the connection. The exists query is orthogonal to that and should be another request endpoint. Melanie On 01/04/2014 21:56, Dahlia Trimble wrote: Not sure about this particular application but keeping a connection open can eliminate the need to instantiate a connection whenever a request is made; a process that can make several round trips to multiple endpoints. On Tue, Apr 1, 2014 at 12:52 PM, Mic Bowman cmick...@gmail.com wrote: Do you really save much with a single request vs a keep alive on the connection? HTTP connection overhead is likely much smaller than the database operations... do you have a feel for how much we'll save with the multiplexed call? --mic On Tue, Apr 1, 2014 at 12:49 PM, Oren Hurvitz or...@kitely.com wrote: Re: why use POST instead of HEAD: because this lets me check the existence of many assets at once with a single HTTP request. The main use of the AssetsExist call is with HGAssetGatherer, which knows the full list of assets that it wants to send, so it's able to check all of them at once. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Optimize pushing assets to other grids
Hi Oren, the correct way is to create an additional post handler that is reachable at a different URL, e,g, /AssetQuery/ Servers that don't implement it would return 404. Don't try to shoehorn this functionality into the existing post handler. Melanie On 31 Mar 2014, at 13:55, Oren Hurvitz or...@kitely.com wrote: I have implemented this method. I found that the Assets Service already had a method to check for assets' existence, so I just had to extend it to check multiple asset ID's at once, and make it available remotely. But now I'm not sure what to do about backwards compatibility. I'm sending the request using POST, because sending a lot of data is better done using POST than GET. But as it turns out, AssetServerPostHandler doesn't handle unknown requests well. First, it assumes that all requests will contain an AssetBase, but this request doesn't. Second, its try/catch clause doesn't catch the exception that is generated, because it's an InvalidOperationException and not an XmlException (which is what's currently caught). The unfortunate result is that the server doesn't send back *any* reply, which means that the caller must wait for the full timeout (100 seconds!) before giving up. [BTW, I'm going to investigate this further because it may explain the 100-second timeouts users occasionally experience.] I've already fixed this problem in the current patch (not yet submitted), so that in the future AssetServerPostHandler will return an error code immediately for unknown requests (HTTP 400). But that won't help when connecting to old grids. I see two ways to fix this: 1. Send the request using GET instead of POST. AssetServerGetHandler handles unknown requests a little better than POST: it tries to find the parameter as an Asset ID, but if not found then it just returns HTTP 404 immediately. 2. Add a way to query the server for its capabilities, to find out if it supports this request. I prefer approach #2 because it can be used in the future for many other new features. How about adding a method to IGatekeeperService, something like this: Dictionarystring,string GetServerCapabilities(); In this example, the capability will be: SupportsAssetsExist=true -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579100.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Optimize pushing assets to other grids
This isn't designed as RPC, it's designed as REST. One URL/VERB combination for each function. We wanted to get away from the RPC concept. Let's not take backwards steps here. Melanie On 31/03/2014 15:15, Oren Hurvitz wrote: This isn't overloading: it's an RPC endpoint that accepts many methods. You wouldn't create a separate endpoint for each method, would you? -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579104.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Optimize pushing assets to other grids
This isn't designed as RPC, it's designed as REST. One URL/VERB combination for each function. We wanted to get away from the RPC concept. Let's not take backwards steps here. Melanie On 31/03/2014 15:15, Oren Hurvitz wrote: This isn't overloading: it's an RPC endpoint that accepts many methods. You wouldn't create a separate endpoint for each method, would you? -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579104.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Optimize pushing assets to other grids
There is no implicit versioning in the actual request protocol. That would have been impossible to maintain in the long run. Instead, there is a protocol version. We can bump it when there are incompatible changes on any protocol and it invalidates all of them. So a sim version 7 will refuse to connect to a server version 6 and vice versa. This gives us both control and simplicity. Melanie On 31/03/2014 18:45, Jim Williams wrote: Seems reasonable to me...A design approach I would have taken. One question. Is there some sort of versioning built into the protocol? One verb yes, but the dictionary numbers the definitions. On Mon, Mar 31, 2014 at 12:35 PM, Melanie mela...@t-data.com wrote: This isn't designed as RPC, it's designed as REST. One URL/VERB combination for each function. We wanted to get away from the RPC concept. Let's not take backwards steps here. Melanie On 31/03/2014 15:15, Oren Hurvitz wrote: This isn't overloading: it's an RPC endpoint that accepts many methods. You wouldn't create a separate endpoint for each method, would you? -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579104.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Optimize pushing assets to other grids
Because even if badness exists, that is not a reason to add more badness. Let's do future additions the right way. Melanie On 31/03/2014 18:52, Oren Hurvitz wrote: If you say that the intention was to use REST then of course I accept what you say. But whatever the vision was, the implementation today is very different: many services use RPC. The /auth endpoint, for example, handles 6 methods. The /avatar endpoint handles 5 methods. And that's just for services that start with the letter 'A'. So why the pushback on the assets endpoint, when so many other services already work this way? -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579112.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Stop saving SculptData in serialized SceneObjects
Looks like you found the culprit! All those suggestions sound good. Melanie On 27 Mar 2014, at 17:03, Oren Hurvitz or...@kitely.com wrote: When a prim is a Sculptie or Mesh, the prim's shape contains a field called SculptData which stores the full mesh or texture (for sculpties). If the prim is serialized then the field SculptData is also serialized, which is a problem because it contains the entire contents of the mesh or texture. This makes actions such as detaching a mesh attachment extremely slow. I think that we should remove SculptData from the serialized XML format of prims. This means that we'll stop serializing it, and when we get an XML with SculptData we'll ignore it. See also: http://opensimulator.org/mantis/view.php?id=7038 (Unwearing mesh attachments very slow). As far as I can tell, the shape's SculptData field (in memory) should usually be empty. It only needs to be filled with the asset data in two cases: 1. When the mesh is first uploaded 2. If the Physics system needs to create a physics mesh In both cases, after the mesh data has been used it should be cleared immediately, to save memory. Regarding the behavior of the physics system, I see a few things that could be a problem with the way it's currently implemented. What currently happens is this: ODEPrim.CheckMeshAsset() loads the mesh/sculptie data if it's needed. Later, Meshmerizer.CreateMeshFromPrimMesher() clears the data once it has finished using it. This raises a couple of questions: 1. Where does BulletSim load the mesh data? It doesn't use ODEPrim. 2. It looks like Meshmerizer.CreateMeshFromPrimMesher() can sometimes return early, without clearing the mesh data. Seems to me that it should always clear it. So besides removing SculptData from the XML format of prims, I also want to make Meshmerizer clear the data more aggressively. And I don't know how BulletSim uses meshes, but perhaps it also needs to be changed. Thoughts? Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Stop-saving-SculptData-in-serialized-SceneObjects-tp7579079.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Stop saving SculptData in serialized SceneObjects
In that case, i concur, just exclude it from serialization. Melanie On 27/03/2014 19:26, Dahlia Trimble wrote: That field contains the asset data, which, in the case of a sculptie is not a mesh but a texture. For ODE, the resulting mesh will be cached once generated and reused, however the asset will need to be reaccessed later if a mesh with another scale is required, or one with different optional parameters such as invert or mirror being set. If you remove the asset data, it will need another asset fetch and multiple attempts to create a mesh until the asset becomes available again. I'd suggest *not* removing the asset data, but rather exclude it from the serialization when it's being stored for attachment purposes so as to reduce as many asset fetches as possible and keep sim startup/load time low. On Thu, Mar 27, 2014 at 10:41 AM, James Stallings II james.stalli...@gmail.com wrote: Knock 'em dead Oren xD On Thu, Mar 27, 2014 at 11:29 AM, Melanie mela...@t-data.com wrote: Looks like you found the culprit! All those suggestions sound good. Melanie On 27 Mar 2014, at 17:03, Oren Hurvitz or...@kitely.com wrote: When a prim is a Sculptie or Mesh, the prim's shape contains a field called SculptData which stores the full mesh or texture (for sculpties). If the prim is serialized then the field SculptData is also serialized, which is a problem because it contains the entire contents of the mesh or texture. This makes actions such as detaching a mesh attachment extremely slow. I think that we should remove SculptData from the serialized XML format of prims. This means that we'll stop serializing it, and when we get an XML with SculptData we'll ignore it. See also: http://opensimulator.org/mantis/view.php?id=7038 (Unwearing mesh attachments very slow). As far as I can tell, the shape's SculptData field (in memory) should usually be empty. It only needs to be filled with the asset data in two cases: 1. When the mesh is first uploaded 2. If the Physics system needs to create a physics mesh In both cases, after the mesh data has been used it should be cleared immediately, to save memory. Regarding the behavior of the physics system, I see a few things that could be a problem with the way it's currently implemented. What currently happens is this: ODEPrim.CheckMeshAsset() loads the mesh/sculptie data if it's needed. Later, Meshmerizer.CreateMeshFromPrimMesher() clears the data once it has finished using it. This raises a couple of questions: 1. Where does BulletSim load the mesh data? It doesn't use ODEPrim. 2. It looks like Meshmerizer.CreateMeshFromPrimMesher() can sometimes return early, without clearing the mesh data. Seems to me that it should always clear it. So besides removing SculptData from the XML format of prims, I also want to make Meshmerizer clear the data more aggressively. And I don't know how BulletSim uses meshes, but perhaps it also needs to be changed. Thoughts? Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Stop-saving-SculptData-in-serialized-SceneObjects-tp7579079.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- === http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Stop saving SculptData in serialized SceneObjects
Attachments can be dropped and then need the proxy again. Melanie On 27/03/2014 19:29, Dahlia Trimble wrote: Another strategy may be do something along the lines of deleting it if the SOP is part of an attachment. Attachments are phantom and do not need physics proxies. On Thu, Mar 27, 2014 at 11:26 AM, Dahlia Trimble dahliatrim...@gmail.comwrote: That field contains the asset data, which, in the case of a sculptie is not a mesh but a texture. For ODE, the resulting mesh will be cached once generated and reused, however the asset will need to be reaccessed later if a mesh with another scale is required, or one with different optional parameters such as invert or mirror being set. If you remove the asset data, it will need another asset fetch and multiple attempts to create a mesh until the asset becomes available again. I'd suggest *not* removing the asset data, but rather exclude it from the serialization when it's being stored for attachment purposes so as to reduce as many asset fetches as possible and keep sim startup/load time low. On Thu, Mar 27, 2014 at 10:41 AM, James Stallings II james.stalli...@gmail.com wrote: Knock 'em dead Oren xD On Thu, Mar 27, 2014 at 11:29 AM, Melanie mela...@t-data.com wrote: Looks like you found the culprit! All those suggestions sound good. Melanie On 27 Mar 2014, at 17:03, Oren Hurvitz or...@kitely.com wrote: When a prim is a Sculptie or Mesh, the prim's shape contains a field called SculptData which stores the full mesh or texture (for sculpties). If the prim is serialized then the field SculptData is also serialized, which is a problem because it contains the entire contents of the mesh or texture. This makes actions such as detaching a mesh attachment extremely slow. I think that we should remove SculptData from the serialized XML format of prims. This means that we'll stop serializing it, and when we get an XML with SculptData we'll ignore it. See also: http://opensimulator.org/mantis/view.php?id=7038 (Unwearing mesh attachments very slow). As far as I can tell, the shape's SculptData field (in memory) should usually be empty. It only needs to be filled with the asset data in two cases: 1. When the mesh is first uploaded 2. If the Physics system needs to create a physics mesh In both cases, after the mesh data has been used it should be cleared immediately, to save memory. Regarding the behavior of the physics system, I see a few things that could be a problem with the way it's currently implemented. What currently happens is this: ODEPrim.CheckMeshAsset() loads the mesh/sculptie data if it's needed. Later, Meshmerizer.CreateMeshFromPrimMesher() clears the data once it has finished using it. This raises a couple of questions: 1. Where does BulletSim load the mesh data? It doesn't use ODEPrim. 2. It looks like Meshmerizer.CreateMeshFromPrimMesher() can sometimes return early, without clearing the mesh data. Seems to me that it should always clear it. So besides removing SculptData from the XML format of prims, I also want to make Meshmerizer clear the data more aggressively. And I don't know how BulletSim uses meshes, but perhaps it also needs to be changed. Thoughts? Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Stop-saving-SculptData-in-serialized-SceneObjects-tp7579079.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- === http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2 ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Changes to OpenSim.log, etc, log config
IMHO, this is a change that should have been discussed beforehand. This is just the kind of change we try to avoid making without consultation. That said, I am against this change. A possible alternative would be to include this as an alternate configuration, commented out, i these files and maybe document how to change it, but to change the default is not the way we do this. It will play hell with installations where people use operating system features and/or external programs to rotate and/or archive logs. Options are fine, changing defaults without discussion is not. Melanie On 26/03/2014 07:35, Oren Hurvitz wrote: This doesn't change the amount of data logged; it just makes it easier to use since the files are smaller, and it makes finding events of interest easier. Your objection is to the *number* of files? I admit that this wasn't a concern for me because I do save the logs in a log subdirectory. So how about we do that? If we're changing the behavior of log files then we might as well make all the changes we want at one time. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Changes-to-OpenSim-log-etc-log-config-tp7579053p7579058.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Detaching mesh objects causes the region set send full asset data -- including geometry -- to the asset server
And the answer is: NO.
That should NEVER happen. It's a BIG hairy-legged bug!
Melanie
On 26/03/2014 12:52, Aine wrote:
Bingo!
I just ran my test again with a newly created test mesh and did not observe
the mass of data being sent to the asset server when I unwore it (as per
Oren's post in the mantis). I then wore it again and added a generic empty
script
default
{
state_entry()
{
llSay(0, Script running);
}
}
I then unwore it and saw the massive amount of data sent. I guess I've been
observing this so frequently with attached meshes because I often add a
script to allow me to conveniently tint and texture it (selecting faces on a
conforming mesh can be an exercise in frustration).
So the issue shifts to is it really necessary to resend the entire mesh
geometry data every time it's unworn if the mesh contains a script?
-Original Message-
From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Melanie
Sent: Tuesday, March 25, 2014 10:50 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Detaching mesh objects causes the region set send
full asset data -- including geometry -- to the asset server
Hi,
this is a potentially very serious bug.
For prims, OpenSim will indeed save the prims back into an asset when they
are unworn if they have changed or contain scripts.
This is because script states are saved as part of the object.
Mesh of course needs to be detected and treated differently.
Resaving mesh is incredibly wasteful and should just not happen.
Melanie
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Detaching mesh objects causes the region set send full asset data -- including geometry -- to the asset server
No. Assets are immutable, so each time you detach, a new one is
generated. That is correct behavior. The scene object must be saved
because a contained script could have changed textures or colors or
the geometry, also, script states are saved in the scene object as well.
The issue here arises when the object is a mesh. In that case the
scene object should be saved, however, the mesh data itself should
not be saved as no script can change it. It is also normally quite
large, so we would certainly not want it to be saved again and
again, unchanged. We do still want to save the scene object, though.
Melanie
On 26/03/2014 13:33, Mike Chase wrote:
I don't get this. I thought assets were immutable. Why would you ever
update an asset. Contents yes I can see that but not the asset itself. I
suppose that's the bug?
Mike
-Original Message-
From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Melanie
Sent: Wednesday, March 26, 2014 8:33 AM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Detaching mesh objects causes the region set send
full asset data -- including geometry -- to the asset server
And the answer is: NO.
That should NEVER happen. It's a BIG hairy-legged bug!
Melanie
On 26/03/2014 12:52, Aine wrote:
Bingo!
I just ran my test again with a newly created test mesh and did not
observe the mass of data being sent to the asset server when I unwore
it (as per Oren's post in the mantis). I then wore it again and added
a generic empty script
default
{
state_entry()
{
llSay(0, Script running);
}
}
I then unwore it and saw the massive amount of data sent. I guess I've
been observing this so frequently with attached meshes because I often
add a script to allow me to conveniently tint and texture it
(selecting faces on a conforming mesh can be an exercise in frustration).
So the issue shifts to is it really necessary to resend the entire
mesh geometry data every time it's unworn if the mesh contains a script?
-Original Message-
From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Melanie
Sent: Tuesday, March 25, 2014 10:50 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Detaching mesh objects causes the region
set send full asset data -- including geometry -- to the asset server
Hi,
this is a potentially very serious bug.
For prims, OpenSim will indeed save the prims back into an asset when
they are unworn if they have changed or contain scripts.
This is because script states are saved as part of the object.
Mesh of course needs to be detected and treated differently.
Resaving mesh is incredibly wasteful and should just not happen.
Melanie
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Detaching mesh objects causes the region set send full asset data -- including geometry -- to the asset server
Hi, this is a potentially very serious bug. For prims, OpenSim will indeed save the prims back into an asset when they are unworn if they have changed or contain scripts. This is because script states are saved as part of the object. Mesh of course needs to be detected and treated differently. Resaving mesh is incredibly wasteful and should just not happen. Melanie On 25/03/2014 22:16, Aine wrote: At today's dev meeting, Justin asked me to post to the mailing list to ask whether anyone can confirm my observation that when you wear a mesh object and then un-wear it, the full mesh data is being sent from the region server to the asset server and waits for an update response before it processes any further actions. Steps to most easily reproduce: 1. Create a mesh object that is far more detailed than you would normally create (something in the 40k vert range). Rigged, weighted, UV mapped and normal-mapped, this will result in a dae that's about 10MB in size which will then be easy to spot when testing. Obviously a 10MB mesh is far too large to wear normally but this is the best means to demonstrate the issue. I can supply a test file if someone wants to try this but isn't able to create the dae. 2. Stand in a region where you are able to monitor the outbound and inbound data traffic between the region server and the asset server (for super-easy test, be in a home-hosted region with an ISP connection under 5Mbps that is connected to OSG) 3. Upload the mesh (brew coffee while waiting for it to finish). You'll notice outbound traffic during the upload as the geometry, etc is being sent to the asset server. The total traffic will be a little larger than your original file because LOD and physics also has to be stored. If you're very patient, upload it with silly LOD settings to have it display at nearly maximum mesh resolution at all distances and to use the highest possible quality physics mesh just so the asset is truly enormous (but never do this for a real asset!) 4. Select an attachment point that you normally have something else attached to (the skull, for instance, where most people wear prim hair). Detach whatever is currently there. 5. Attach the mesh to that point. Don't do anything else -- don't texture it or change it in any way. Just attach. 6. Now from inventory, wear whatever normally mounts to that attachment point (assuming your viewer is set to replace objects on attachment points by default) which will cause the mesh to be detached and the other object to be attached. 7. Monitor the outbound data traffic for the region and also see how long it takes your other object to appear. 8. Repeat this over and over again, swapping back and forth between the hair (or whatever) and the mesh while watching the traffic. Depending on your debug settings, also watch the console for messages. Once you hit step 8, both objects are being worn from the viewer cache at this point so there is almost no traffic at all between the viewer and the region other than very small blips of data. Every time you unwear the mesh, there's a lengthy delay and the outbound traffic will show that a huge amount of data is being sent -- at least the entire geometry and possibly this also includes the UVs, normals, LOD and physics data (I have no idea since I'm only looking at total MB of data sent, not the actual contents of the packets) -- and it isn't until that data is fully sent that your other object (hair) will attach itself and rez. When you detach the hair, it disappears and is rapidly replaced with the mesh (since it's coming from your viewer cache) and there is minimal outbound traffic (barely a blip) between the region server and the asset server. When unwearing the mesh object if you're in a region with a slower outbound connection speed you will also see a console warning message complaining about how long it took to received a response from the asset server to confirm that the asset had been updated. Example: 17:33:09 - [SynchronousRestObjectRequester]: Slow request 9912 POST http://assets.osgrid.org/assets/ took 7098ms, 94ms writing, ??xml version=1.0 encoding=utf-8?AssetBase xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns Obviously this shouldn't be happening. Mesh attributes such as geometry, physics, etc can't change after upload so the only data that *should* be sent is the normal block sent when you unwear a prim or sculptie; and both Justin and Dahlia were skeptical at the dev meeting when I reported the issue so it would be helpful to know if anyone else is experiencing this, or to have someone else independently test and confirm that it's happening. Obviously nobody should be wearing mesh attachments of this extreme size; however a full mesh avatar wearing mesh clothing, mesh footwear, mesh jewelry, etc can begin to approach these sorts of total
Re: [Opensim-dev] Proposal: notify clients when Robust changes a user's inventory
In the past we have studiously acoided abusing thr instant message protocol as a message transport. The Linden protocols use the InstantMessageDialog for similar purposes, but way back when it was decided to not make the same mistake. So while notifying the client of such inventory changes is a good idea, using instant messages as the protocol may not be agreeable to all. Personally, I'm not opposed to it. Melanie On 13 Mar 2014, at 18:16, Oren Hurvitz or...@kitely.com wrote: Sometimes Robust makes changes to a user's inventory on its own initiative (i.e., not as the result of a client request). E.g., this happens when it creates the My Suitcase folder. When that happens we should notify the client, so that the new item or folder will be visible in the inventory window immediately. Otherwise the user won't be able to see the changes until they restart the client, which is confusing and frustrating. I want to use the existing IM service to do this, since it already has 95% of the necessary code. It already has services in place for Robust to find which region the user is in, and send a message to that simulator. It can even do this if the user is in a different grid. My proposal is to define a special format of GridInstantMessage, which tells the simulator to send SendBulkUpdateInventory() to the client. The data about which specific folder/item were added will be encoded in the field 'binaryBucket'. OpenSim will recognize this new type of message, and call client.SendBulkUpdateInventory(). This mechanism will work cleanly with older simulators: I'll remove a key field from GridInstantMessage, e.g. 'from_agent_id', and this will cause old simulators to ignore the message. This can be seen in MessageTransferModule.processXMLRPCGridInstantMessage(): the removal of a required field causes the simulator to ignore the message. Only new simulators will recognize and handle this new type of message. Any comments or objections? Is there a simpler way to do this? Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Proposal-notify-clients-when-Robust-changes-a-user-s-inventory-tp7579018.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Proposal: notify clients when Robust changes a user's inventory
In SL, IM is used for a lot of things besides actual IM. We at some point decided to try and use more specific messaging/APIs to accomplish our communications goals. I've adhered to that in my core contributions but my out of core work does use IM as transport and it works like a charm. IM is, because of this agreed limitation, a pure client - sim thing, as we translate the IM things (like friend stuff) into the above mentioned more specific APIs. However, there is nothing that prevents external services to query presence and inject IM using different IntantMessageDialog values into the last known sim the user is in, leveraging the hunting mechanism IM already has, to deliver a message from a service to a client. From all appearances, that's not too different from what LL do. Melanie On 14/03/2014 02:01, Justin Clark-Casey wrote: I think IM is just viewer - simulator and simulator - simulator or am I wrong? On 14/03/14 00:50, Diva Canto wrote: On 3/13/2014 5:48 PM, Justin Clark-Casey wrote: I think this would be the first case of service - simulator comms. Except for IM itself... ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] Status of master
We have come quite a ways with this merge, but there are still some issues left to address. Unfortunately, I was taken ill a few days before Christmas and have still not fully recovered. Because of that, things are not happening as swiftly as I and everyone else could have wished for. Since my last report, a couple of issues have been addressed. Master is essentially usable for it's intended purpose, which is to test and develop against. At this time, we can't say for sure that there are no regressions, so master cannot be recommended for any kind of production use. But then, that has always been the case. One of the issues that cannot be easily fixed is the introduction of additional Visual Params by Linden Labs. Visual Params are essentially the sliders that the viewer uses for the shape and clothing manipulation. Since the last time this code was touched, Linden Labs has added some more Visual Params, to wit, the physics wearables. Master now supports these sliders, but adding this support uncovered a long standing bug in the code for sending the data to the viewer. Essentially, an array was accessed without bounds checking, resulting in red ink whenever an avatar from a sim running master enters a sim running an older version. The avatar will also remain a cloud in most cases where this happens. I have pushed a fix for this to 0.7.5-post fixes on git and users who compile their own can pick it up from there and update their 0.7.5 regions. Versions 0.7.4 and earlier have not received this fix and will not work with master regions anymore. I would ask all packagers who ship 0.7.5 to pull the patches from post-fixes and respin their distributions. Anyone still running 0.7.5 or lower is urgently requested to upgrade to this fixed 0.7.5 release as soon as possible. With everyone working together, we can make this transition as painless as possible for the metaverse. We have at this time decided not to make this a mandatory upgrade to avoid disruption of grids and HG destinations, but please do consider upgrading as soon as possible. - Melanie ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] GIt master is broken until further notice
It's definitely planned to be done before than. :) Melanie On 13/12/2013 13:58, R.Gunther wrote: Agree with justin, especially because people aroujd xmas maby like to test dev version. Gives hardhat to dahlia. :) On 2013-12-13 01:54, Justin Clark-Casey wrote: This needs to be done very soon or we need some imminent timeframe. The rest of the code needs to be merged in so that master can be fixed and we can move forward. Leaving it broken over Christmas would be a very poor show. On 11/12/13 02:05, Dahlia Trimble wrote: Melanie has begun merging her region crossing code into git master and expects that the changes will break the repository for some indefinite period. The last usable commit was 08750501617ca332ab196b2f25030e3c635c9dd6 made on December 10th. Please do not use commits after this until master is fixed. -dahlia ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] GIt master is broken until further notice
I will likely need to add some dummy methods to Bullet to satisfy the new physics interface. In particular, part of the crossing code is a method to save and restore vehicle parameters. They are shadowed in SOP or SOG, i forget which one, and re-set on crossing. You may need to flesh out these methods. Melanie On 13/12/2013 18:02, James Stallings II wrote: That's definitely good to hear :) A quick question related to the work: Will this change be compatible with Bullet or will this be for ODE only? TIA and Cheers! James On Fri, Dec 13, 2013 at 9:38 AM, Melanie mela...@t-data.com wrote: It's definitely planned to be done before than. :) Melanie On 13/12/2013 13:58, R.Gunther wrote: Agree with justin, especially because people aroujd xmas maby like to test dev version. Gives hardhat to dahlia. :) On 2013-12-13 01:54, Justin Clark-Casey wrote: This needs to be done very soon or we need some imminent timeframe. The rest of the code needs to be merged in so that master can be fixed and we can move forward. Leaving it broken over Christmas would be a very poor show. On 11/12/13 02:05, Dahlia Trimble wrote: Melanie has begun merging her region crossing code into git master and expects that the changes will break the repository for some indefinite period. The last usable commit was 08750501617ca332ab196b2f25030e3c635c9dd6 made on December 10th. Please do not use commits after this until master is fixed. -dahlia ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] GIt master is broken until further notice
We do it the same way for a lot of stuff. Now, some of the vehicle stuff and some other SOP stuff is too specific to be generlized, but I understand where you're coming from. Melanie On 13/12/2013 20:27, Mister Blue wrote: I will generalize these after you have added the functions because there are other uses for being able to 'pickup' and move physics state. The functions should be more general than just get vehicle state. For instance, BulletSim is getting an extension to linksets which allows linkset links to be other than static constraints (slider, hinge, 6DoF, ...) and the linkset specification also needs transferring. The returned vehicle state should be a dictionary or OSDMap and not a structure. This makes the interface contract looser but allows extensions. One technique I've used to extend the physics interface is, since PhysicsScene is a class, to add a virtual method to PhysicsScene and override it in any physics engine that implements that method. That way I don't have to tweak all the different physics engines since a default function exists. --m b On Fri, Dec 13, 2013 at 10:46 AM, Melanie mela...@t-data.com wrote: I will likely need to add some dummy methods to Bullet to satisfy the new physics interface. In particular, part of the crossing code is a method to save and restore vehicle parameters. They are shadowed in SOP or SOG, i forget which one, and re-set on crossing. You may need to flesh out these methods. Melanie On 13/12/2013 18:02, James Stallings II wrote: That's definitely good to hear :) A quick question related to the work: Will this change be compatible with Bullet or will this be for ODE only? TIA and Cheers! James On Fri, Dec 13, 2013 at 9:38 AM, Melanie mela...@t-data.com wrote: It's definitely planned to be done before than. :) Melanie On 13/12/2013 13:58, R.Gunther wrote: Agree with justin, especially because people aroujd xmas maby like to test dev version. Gives hardhat to dahlia. :) On 2013-12-13 01:54, Justin Clark-Casey wrote: This needs to be done very soon or we need some imminent timeframe. The rest of the code needs to be merged in so that master can be fixed and we can move forward. Leaving it broken over Christmas would be a very poor show. On 11/12/13 02:05, Dahlia Trimble wrote: Melanie has begun merging her region crossing code into git master and expects that the changes will break the repository for some indefinite period. The last usable commit was 08750501617ca332ab196b2f25030e3c635c9dd6 made on December 10th. Please do not use commits after this until master is fixed. -dahlia ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Rate Limit DOS Protection
I'm worried that people with larger installations will see service failures because legit traffic is seen as abusive. This could cause issues for the lerger grids out there. I don't believe that whatever tenuous protection this may offer for small grids and standalones outwieghs the potential service impairment it may cause for unsuspecting larger grids. Not every grid operator reads this list, So I'd again suggest that we stick to the way we've always done it and make the default for new features be off. Melanie On 8 Oct 2013, at 09:31, Teravus Ovares tera...@gmail.com wrote: I understand what you're saying. It's hard to argue to leave people unprotected from attacks, though.I'm certainly open to making the defaults less protective, and, I'm concerned enough about it that I'd prefer to leave some protection in place there. What are your thoughts on that? Best Regards Teravus On Tue, Oct 8, 2013 at 12:41 AM, Melanie mela...@t-data.com wrote: Hi, in keeping with our SOP, the defaults provided should be emulating the previous behavior, e.g. NO rate limiting. I would much appreciate if that procedure would be adhered to, unless we vote to abandon it. Users could suffer because they don't expect the default config to change on them. Cheers, Melanie On 08/10/2013 05:42, Teravus Ovares wrote: Hi there, I just wanted to inform -dev that I added some rate limiting DOS protection classes to use to protect your opensim based services from rapid calling. At the moment, this will be most noticeable in the Login Service.I have, both as an example, and good practice, applied the Rate limit protection to the login service.There are new Configuration options in StandaloneCommon.ini and Robust.ini that control how the connections are rate limited and if trusts the X-Forwarded-For header.Just for the sake of getting something up there, I set the defaults to something sane, however they may not work for everyone, so it may be wise to take a look at the new configuration options in the [LoginService] section of your bin/Robust.ini.example and /bin/config-include/StandaloneCommon.ini.example AND/OR have discussions on what would be more sane default options. There's a chance that this could affect anyone, so don't neglect to take a look at it. You may also notice messages on your console and in your logs like: 21:56:29 - [LOGINDOSPROTECTION]: client: 192.168.1.213 is blocked for 12 milliseconds, X-ForwardedForAllowed status is False, endpoint:192.168.1.213 This is an example of the DOS Protection blocking a connection because the client went beyond the rate limit. The rate limit is defined by X requests in Y period of time and is implemented in a rolling Y fashion. It also has a 'forget' period of time that will unblock the blocked user. At this point, there's one implemented for XMLRPC handlers, one for GenericHTTPHandlers and a base class for StreamHandlers based on BaseStreamHandler. If you are interested in the code changes, you can check the diff: http://opensimulator.org/viewgit/?a=commitdiffp=opensimh=f76cc6036ebf446553ee5201321879538dafe3b2 There's still more to do, and, here's a start to providing some modicum of protection on the services. If you have any questions, feel free to reply and ask.. or send me an e-mail personally. Thanks and Best Regards Teravus ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Rate Limit DOS Protection
The login server should only ever see one connection per client, any more is most likely a DOS. Services that are called by regions are way more critical, as they get all requests from a few entities only. The inventory service, for instance, can't be rate limited because a single login creates a slew of requests. Also, it should not normally be accessible to the world. Melanie On 8 Oct 2013, at 18:27, Teravus Ovares tera...@gmail.com wrote: Just to be clear, and comment/answer some questions. I did add the DOS protection variables to the Robust.ini.example in the [LoginService] section. The Rate Limit code does 'per connection' velocity counts. The default rate setting is 5 requests in 10 seconds.If you have a transparent proxy, such as squid, you need to set DOSAllowXForwardedForHeader to true so that the code trusts the X-Forwarded-For header that your proxy adds to the headers.If you want to turn it off, set DOSMaxRequestsInTimeFrame = 0. If you want to allow individual clients to do 20 connections in 5 seconds, set DOSMaxRequestsInTimeFrame = 20 and DOSRequestTimeFrameMS = 5000. If you want to change how long individual connections are blocked when they go over the rate limit, change DOSForgiveClientAfterMS. Hopefully this helps get you started with the config options. One more thing, this DOS protector is configured and implemented 'per service',So, if it's implemented in the login service, it's not going to get triggered by the Group Service. If there's DOS protection on the Group Service and the login service, and a connection gets blocked on the login service, they'll still be able to access the Group Service because they're individually rate limited... This is for flexibility.Choosing what the best rate limit is cannot really be done server wide, it has to be based on the needs of the individual service and that's why it was implemented this way. At this point, the only major service that has rate limiting on by default is the login service. I'll be happy to answer more questions and discuss default settings. Best Regards Teravus On Tue, Oct 8, 2013 at 8:04 AM, James Stallings II james.stalli...@gmail.com wrote: As I have often been told by you, Melanie, if I am upgrading and not auditing, adjusting, and testing my configs in accordance with changes, I'm doing it wrong. I think that statement probably applies more to those running larger concerns than anyone else. Honestly, Teravus typically does a better job of coding than to produce work that does not take such matters of scale into consideration. I'm comfortable with whatever he chooses to do, and if it turns out it isn't a case of 'one size fits all', I'll make adjustments accordingly. On Tue, Oct 8, 2013 at 7:52 AM, Melanie mela...@t-data.com wrote: I'm worried that people with larger installations will see service failures because legit traffic is seen as abusive. This could cause issues for the lerger grids out there. I don't believe that whatever tenuous protection this may offer for small grids and standalones outwieghs the potential service impairment it may cause for unsuspecting larger grids. Not every grid operator reads this list, So I'd again suggest that we stick to the way we've always done it and make the default for new features be off. Melanie On 8 Oct 2013, at 09:31, Teravus Ovares tera...@gmail.com wrote: I understand what you're saying. It's hard to argue to leave people unprotected from attacks, though.I'm certainly open to making the defaults less protective, and, I'm concerned enough about it that I'd prefer to leave some protection in place there. What are your thoughts on that? Best Regards Teravus On Tue, Oct 8, 2013 at 12:41 AM, Melanie mela...@t-data.com wrote: Hi, in keeping with our SOP, the defaults provided should be emulating the previous behavior, e.g. NO rate limiting. I would much appreciate if that procedure would be adhered to, unless we vote to abandon it. Users could suffer because they don't expect the default config to change on them. Cheers, Melanie On 08/10/2013 05:42, Teravus Ovares wrote: Hi there, I just wanted to inform -dev that I added some rate limiting DOS protection classes to use to protect your opensim based services from rapid calling. At the moment, this will be most noticeable in the Login Service.I have, both as an example, and good practice, applied the Rate limit protection to the login service.There are new Configuration options in StandaloneCommon.ini and Robust.ini that control how the connections are rate limited and if trusts the X-Forwarded-For header.Just for the sake of getting something up there, I set the defaults to something sane, however they may not work for everyone, so it may be wise to take a look at the new configuration options in the [LoginService] section of your bin/Robust.ini.example and /bin/config
Re: [Opensim-dev] Rate Limit DOS Protection
People like us have the protection in the proxy and need to turn the feature off. Not a problem for me, I'm aware of it, but my concern was for those who didn't listen to me tell them Dont' blindly reuse configs Melanie ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Rate Limit DOS Protection
Hi, in keeping with our SOP, the defaults provided should be emulating the previous behavior, e.g. NO rate limiting. I would much appreciate if that procedure would be adhered to, unless we vote to abandon it. Users could suffer because they don't expect the default config to change on them. Cheers, Melanie On 08/10/2013 05:42, Teravus Ovares wrote: Hi there, I just wanted to inform -dev that I added some rate limiting DOS protection classes to use to protect your opensim based services from rapid calling. At the moment, this will be most noticeable in the Login Service.I have, both as an example, and good practice, applied the Rate limit protection to the login service.There are new Configuration options in StandaloneCommon.ini and Robust.ini that control how the connections are rate limited and if trusts the X-Forwarded-For header.Just for the sake of getting something up there, I set the defaults to something sane, however they may not work for everyone, so it may be wise to take a look at the new configuration options in the [LoginService] section of your bin/Robust.ini.example and /bin/config-include/StandaloneCommon.ini.example AND/OR have discussions on what would be more sane default options. There's a chance that this could affect anyone, so don't neglect to take a look at it. You may also notice messages on your console and in your logs like: 21:56:29 - [LOGINDOSPROTECTION]: client: 192.168.1.213 is blocked for 12 milliseconds, X-ForwardedForAllowed status is False, endpoint:192.168.1.213 This is an example of the DOS Protection blocking a connection because the client went beyond the rate limit. The rate limit is defined by X requests in Y period of time and is implemented in a rolling Y fashion. It also has a 'forget' period of time that will unblock the blocked user. At this point, there's one implemented for XMLRPC handlers, one for GenericHTTPHandlers and a base class for StreamHandlers based on BaseStreamHandler. If you are interested in the code changes, you can check the diff: http://opensimulator.org/viewgit/?a=commitdiffp=opensimh=f76cc6036ebf446553ee5201321879538dafe3b2 There's still more to do, and, here's a start to providing some modicum of protection on the services. If you have any questions, feel free to reply and ask.. or send me an e-mail personally. Thanks and Best Regards Teravus ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Missing config option ProfileURL = in ini files ?
Since that is not a core module, you will need to add the configuration for it yourself; core doesn't come with it. Melanie On 25/03/2013 23:09, R.Gunther wrote: Ok, i where looking and testing the profile module from http://opensimulator.org/wiki/Profile But for some reason when you get at step 3. and you do a search on part of the word. the following part is not found in any ini file. is the wiki outdated ? or is moved to config-include but not compleet ? i have for now add the following part like the wiki says to opensim.ini [Profile] Module=OpenProfileModule ProfileURL=http://yourwebserverdomainname/pathto/profile.php; But still curious why theProfileURL is not there. i tried btw the profile stuff. but in grid mode it seems to fail without that line in opensim.ini Not sure if thats indeed coirrect setup for test grid. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Avination's Physics vs. BulletSim
Hi, Avination has not donated the entire physics system but has donated the glue that enables Bullet to work in the same Framework that has been tried and tested in Avination, thereby reducing the need for duplicated effort. This code donation is not competing with Bullet, it is supporting it. Melanie On 11/02/2013 17:01, drWhiet wrote: Hi all, I just wonder how Avinations decision to contribute their physics back to opensim affects the development of BulletSim. Will both exist next to each other ? Mayby Adam can say something about this ? Best regards, Wordfromthe Wise ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Sending extra prim properties to clients
We have all this code I just haven't had a chance to push it yet. You wasted that work, sorry to say. My commit message _did_ say yet and that more is to come. Melanie On 07/02/2013 08:37, Oren Hurvitz wrote: Hi, Recently Melanie added support for the Extra Physics Parameters, such as Physics Shape Type and Density. I implemented support for receiving these parameters from the client. However, I'm not sure how to send these parameters *back* to the client, so right now on the client it looks as if the changes didn't take place because the values remain at 0. This is an area of the code I'm not familiar with. How does sending prim properties to clients work? It looks like it's done in LLClientView.ProcessEntityPropertyRequests(). However, the physics parameters should be sent in a different packet: ObjectFlagUpdatePacket. Should this packet be sent automatically whenever we send a prim-properties packet? That would mean doubling the number of packets sent per prim. Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Sending-extra-prim-properties-to-clients-tp7578537.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Dynamic attributes
A word of caution:
Many people have scripts that would store copious amounts of data.
Some limits need to be placed on the overall storage given to a
script so it becomes unattractive to store lots of data in the
simulator. Scripts needing lots of storage should use a web server,
not sim resources.
Melanie
On 07/02/2013 02:59, Mic Bowman wrote:
for discussion purposes...
added the jsonstore connection to the dynamic attributes. here's an example
of an LSL script that sets the attributes (create a notecard called
JsonData with some json structure inside it)... you can interrogate the
store through channel 30... eg /30 jstoretest.test1.field
btw... i really think that hooking up the object store with a variant of
llrezobject() would be very good. it would make passing more complex
initialization parameters a LOT easier (better than the one integer you get
right now). i'm doing this with a modified version that uses a global
jsonstore...
--mic
integer iChannel = 30;
string sInitCard = JsonData;
key kStoreID;
InitializeObjectStore()
{
llOwnerSay(initializing the object store);
JsonSetValueJson(kStoreID,jstoretest,{'test1': {'field' : 22}});
JsonReadNotecard(kStoreID,jstoretest, sInitCard);
}
default
{
state_entry()
{
kStoreID = JsonAttachObjectStore();
if (JsonTestPathJson(kStoreID,jstoretest) == 0)
InitializeObjectStore();
llOwnerSay(object store is + JsonGetValueJson(kStoreID,.));
llListen(iChannel,,llGetOwner(),);
}
listen(integer ch, string name, key id, string msg)
{
if (ch == iChannel)
{
list tokens = llParseString2List(msg,[ ],[]);
string path = JsonList2Path(tokens);
string value = JsonGetValueJson(kStoreID,path);
llOwnerSay(path + == + value);
}
}
}
On Wed, Feb 6, 2013 at 3:00 PM, Mic Bowman cmick...@gmail.com wrote:
one more thing... is there a strong reason for XML serialization as
opposed to json? (I assume the primary reason is for consistency with other
properties.) the OSDMap data structure corresponds fairly closely to JSON.
serializing works fine for either format though it is easy to provide an
xml document that will not deserialize into an OSDMap.
--mic
On Wed, Feb 6, 2013 at 1:58 PM, Mic Bowman cmick...@gmail.com wrote:
Justin,
I took a look at the DAMap data structure have some questions. What's
the value of explicit methods for the top level of the structure? It is
still possible to have name space collisions since there is nothing that
prevents one module from writing into another module's name space. Also,
whats your expectation for locking? The top level accessor locks the
structure, but modules that share the rest of the structure will have to do
their own locking anyway. I guess one value of controlling the top level is
that *IF* modules are making exclusive access to the structure, the locking
is minimized. Hard to control that, though.
Did you get a chance to look at the JsonStore structure? The path-based
accessors are very different than providing immediate access to the OSDMap.
As we discussed, I made that decision to support the synchronization
operations (take read) and it removes the exposed OSDMap so that the data
structure can be replaced. I think the path-based accessor is probably too
heavyweight for DAMap... well... maybe... given that we dont have any
examples yet its hard to tell. :-)
--mic
On Mon, Feb 4, 2013 at 5:09 PM, Justin Clark-Casey
jjusti...@googlemail.com wrote:
Okay, I have now merged this branch (dynamic-attributes2) to master.
Please report any problems (or fix them :)
As this is experimental functionality, if necessary it can be
changed/bug-fixed without any attempt to preserve existing data. Any code
using it should handle the 'expected data not found' case anyway.
On 26/01/13 19:52, Adams, Robert wrote:
This implementation will work for physics. The physics engine cannot
reference Scene (circular reference madness) so, on creation of the
scene's
physics instance, I will pass in the instance of DAMap (since it is
defined
in OpenSim.Framework) much the same way the asset request method instance
is passed in.
I am +2 on this branch's inclusion into master.
-- ra
-Original Message-
From:
opensim-dev-bounces@lists.**berlios.deopensim-dev-boun...@lists.berlios.de[mailto:
opensim-dev-bounces@**lists.berlios.deopensim-dev-boun...@lists.berlios.de]
On Behalf Of Justin Clark-Casey
Sent: Friday, January 25, 2013 5:14 PM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Dynamic attributes
On 25/01/13 08:40, Oren Hurvitz wrote:
Ok, great. I hope all goes well and this will be added to master soon.
What do you mean by put the code in for MSSQL? The code already
supports MySQL, MSSQL and SQLite.
Apologies - my brain stored the assumption
Re: [Opensim-dev] How does the viewer know the user's maturity rating
Your version of OpenSim is too old. This is not a bug, but a new CAP that as added in SL to disallow setting a viewer's content pref to something higher than what the server knows to be true. Simulators that don't implement that cap will not allow changing the value. Avination donated the implementation of this cap weeks ago but we don't know if it is in a formal release yet. However, OpenSim core code in Git has it. Melanie On 04/02/2013 16:23, Oren Hurvitz wrote: Yes, I know where to find this setting. But when I try to change it, Firestorm says that I'm not allowed. That's the problem that I'm trying to solve. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/How-does-the-viewer-know-the-user-s-maturity-rating-tp7578517p7578523.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Raise minimum mono version to 2.6
It has always been our policy to use the _lowest_ version of Mono that we can get by on to support the largest possible number of configurations and systems. This is not going to change. The feature required by recent code additions is found in Mono 2.6, so we are discussing Mono 2.6 now. We are not discussing Mono 2.10. Melanie On 27/01/2013 15:32, Ilan Tochner wrote: If, as we both agree, OpenSim works differently with different versions of mono then people are going to report bugs that exist when OpenSim is run on mono versions prior to 2.10 that don't exist with mono version 2.10 and later. How many people are there in the OpenSim dev community that still actively use a mono version prior to 2.10? In fact, AFAIK, many devs are already looking to see when they can safely move to mono 3.0. So, who is going to work on fixing bugs that no longer exist with mono 2.10 and later? If no ones is going to work on doing that then we can't honestly say that mono 2.6 or 2.8 are still supported. If we intend to have new OpenSim users, we should have them using the mono version with which they'll get the best experience with the existing / future code base. It doesn't help anyone if they use an outdated version of mono and find that the problems they encounter aren't going to be addressed because they no longer exist with newer versions of mono. Cheers, Ilan Tochner Co-Founder and CEO Kitely Ltd. On Sun, Jan 27, 2013 at 2:36 PM, Dahlia Trimble dahliatrim...@gmail.comwrote: Nobody is asking you to use an older version. The minimum version is simply the earliest version that would be required to run OpenSimulator. Anyone is free to use any later version if they so choose. It's also not true that later versions are necessarily better. I've personally had to disable features in OpenSimulator and remove them from core due to newer versions of Mono which introduced new bugs that made such features unusable. On Sun, Jan 27, 2013 at 1:05 AM, Ilan Tochner i...@kitely.com wrote: Mono 2.10 was released Feb 15th, 2011, i.e almost two years ago. I don't think there is any target platform that mono 2.6 runs on that doesn't have mono 2.10 working on it as well. There have been many bug fixes in mono between the 2.6 release and the 2.10 release, some of which can definitely effect OpenSim performance and stability. Who would choose to use the older mono version when a better one has been available for at least two years? If someone reports a problem with OpenSim I think we should require them to at least test it using mono 2.10 so we can rule out the older mono being the cause of the problem. Cheers, Ilan Tochner Co-Founder and CEO Kitely Ltd. On Sun, Jan 27, 2013 at 4:28 AM, Dahlia Trimble dahliatrim...@gmail.comwrote: I think the point is raise it to the minimum version which supports the codebase. If there was some feature in 2.10 that did not exist in 2.6 and that feature was required for proper execution, then 2.10 would be a better target. Otherwise it would just be forcing people to upgrade who would not otherwise need to. There's nothing stopping anyone from upgrading to 2.10 if they desire, however, requiring a higher version than is really necessary limits potential users of the software to those who are able to install those versions in their setups. If a goal of OpenSimulator developers is wide adoption, then it makes sense to have it be usable on as many existing hardware/software configurations as possible. On Sat, Jan 26, 2013 at 11:51 AM, Ilan Tochner i...@kitely.com wrote: I second setting 2.10 as the base. If we'll be forcing people to upgrade I think we should upgrade to the latest stable release and not to one that is outdated. If OpenSim works fine with 3.0 then I'd vote for it to be the base. If we're still calling OpenSim alpha we should at least get the benefits of doing so. Supporting old versions of mono is a waste of developer resources. Cheers, Ilan Tochner Co-Founder and CEO Kitely Ltd. On Sat, Jan 26, 2013 at 9:20 PM, Trinity trinit...@gmail.com wrote: if we can get a way with it why not go to 2.10 else quickly be out of date agian On Sat, Jan 26, 2013 at 9:38 AM, James Hughes jam...@bluewallgroup.com wrote: +1 On 01/24/2013 10:29 PM, Justin Clark-Casey wrote: Whilst writing JsonStore regression tests this evening, I hit the problem where modInvoke script methods of more than 4 parameters cannot be registered on Mono 2.4.3 as it doesn't implement the required larger multi-parameter Func generic types. Therefore, I want to bump the minimum Mono version for OpenSimulator up to 2.6 which was released more than 3 years ago. This also involves bumping the minimum .net framework version up to 4.0, as also detailed at [1] [1] http://opensimulator.org/**mantis/view.php?id=5971http://opensimulator.org/mantis/view.php?id=5971 Any comments
Re: [Opensim-dev] Raise minimum mono version to 2.6
Since you have already stated that you will not support older versions, our decision will not affect you in any way. We have, for a long time, used mono 2.4 as the base simply because versions of distros in common use don't offer it as part of their repo. OpenSim targets not only Windows users but all operating systems, including Linux. As long as people use versions of Linux that don't natively supply 2.10, we cannot make it our baseline. That is simply not open for discussion. Melanie On 27/01/2013 21:56, Ilan Tochner wrote: That's all well and good but saying we support mono version 2.6 and actually supporting it are two very different things. Who here is willing to spend their time fixing problems that only appear in versions before mono 2.10? (this isn't a rhetorical question, if you are willing to commit to doing so then please reply and let the group know) If anyone is, do you think that doing so is better use of our limited development resources than telling the person who had the problem to just upgrade to a slightly more modern version of mono that can be easily installed? It makes sense not to drop support for old operating systems, as they usually can't be easily upgraded, but installing a newer version of mono is very simple when there are repositories you can just apt get / rpm it from. What exactly will be served by saying mono 2.6 is supported when no one will invest (waste?) their time debugging for it? Wouldn't our users be better served by having OpenSim run as best as it can (given our limited resources) on a better performing version of mono that those users can easily install? I know Kitely won't be spending resources on debugging for old mono releases so my only horse in this is wanting OpenSim to advance as quickly as it can without leaving people behind. Setting mono 2.10 as the baseline makes it easier for this open source dev community to accomplish this goal. Cheers, Ilan Tochner Co-Founder and CEO Kitely Ltd. On Sun, Jan 27, 2013 at 5:44 PM, Melanie mela...@t-data.com wrote: It has always been our policy to use the _lowest_ version of Mono that we can get by on to support the largest possible number of configurations and systems. This is not going to change. The feature required by recent code additions is found in Mono 2.6, so we are discussing Mono 2.6 now. We are not discussing Mono 2.10. Melanie On 27/01/2013 15:32, Ilan Tochner wrote: If, as we both agree, OpenSim works differently with different versions of mono then people are going to report bugs that exist when OpenSim is run on mono versions prior to 2.10 that don't exist with mono version 2.10 and later. How many people are there in the OpenSim dev community that still actively use a mono version prior to 2.10? In fact, AFAIK, many devs are already looking to see when they can safely move to mono 3.0. So, who is going to work on fixing bugs that no longer exist with mono 2.10 and later? If no ones is going to work on doing that then we can't honestly say that mono 2.6 or 2.8 are still supported. If we intend to have new OpenSim users, we should have them using the mono version with which they'll get the best experience with the existing / future code base. It doesn't help anyone if they use an outdated version of mono and find that the problems they encounter aren't going to be addressed because they no longer exist with newer versions of mono. Cheers, Ilan Tochner Co-Founder and CEO Kitely Ltd. On Sun, Jan 27, 2013 at 2:36 PM, Dahlia Trimble dahliatrim...@gmail.com wrote: Nobody is asking you to use an older version. The minimum version is simply the earliest version that would be required to run OpenSimulator. Anyone is free to use any later version if they so choose. It's also not true that later versions are necessarily better. I've personally had to disable features in OpenSimulator and remove them from core due to newer versions of Mono which introduced new bugs that made such features unusable. On Sun, Jan 27, 2013 at 1:05 AM, Ilan Tochner i...@kitely.com wrote: Mono 2.10 was released Feb 15th, 2011, i.e almost two years ago. I don't think there is any target platform that mono 2.6 runs on that doesn't have mono 2.10 working on it as well. There have been many bug fixes in mono between the 2.6 release and the 2.10 release, some of which can definitely effect OpenSim performance and stability. Who would choose to use the older mono version when a better one has been available for at least two years? If someone reports a problem with OpenSim I think we should require them to at least test it using mono 2.10 so we can rule out the older mono being the cause of the problem. Cheers, Ilan Tochner Co-Founder and CEO Kitely Ltd. On Sun, Jan 27, 2013 at 4:28 AM, Dahlia Trimble dahliatrim...@gmail.comwrote: I think the point
Re: [Opensim-dev] Raise minimum mono version to 2.6
Hi, times change. Avination is 2.10.9 these days. +1 Melanie On 25/01/2013 23:31, Shaun Erickson wrote: As I recall, Melanie has/had strong objections to doing this, as it would affect her grid. -ste On Jan 25, 2013, at 5:20 PM, Mic Bowman cmick...@gmail.com wrote: +1 On Fri, Jan 25, 2013 at 1:57 PM, Diva Canto d...@metaverseink.com wrote: +1 On 1/24/2013 7:29 PM, Justin Clark-Casey wrote: Whilst writing JsonStore regression tests this evening, I hit the problem where modInvoke script methods of more than 4 parameters cannot be registered on Mono 2.4.3 as it doesn't implement the required larger multi-parameter Func generic types. Therefore, I want to bump the minimum Mono version for OpenSimulator up to 2.6 which was released more than 3 years ago. This also involves bumping the minimum .net framework version up to 4.0, as also detailed at [1] [1] http://opensimulator.org/mantis/view.php?id=5971 Any comments? ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Thread.Abort() considered harmful
The issue with Thread.Interrupt is that it requires cooperation. Thread.Abort is used precisely to stop non-cooperating scripts from running. Properly written scripts would not need aborting, this is to stop rogue scripts. They really should fix Thread.Abort. It's understood that locks held by the aborted threads will not be unlocked but the system should not become unstable as a whole because of that. Melanie On 09/01/2013 21:37, Serendipity Seraph wrote: Forgive me if this question makes no sense as I am not an OpenSim code expert. But in addition to effectively putting a should stop event at the head of the targeted threads event queue would it also make sense to be able to find and stop any work and release resources that may be scheduled/attached on the thread's behalf? Or does that not make sense due to details of the actual architecture? I can see that it would get tricky to get the timing right. Also, is there any mechanism to detect locks that would cause deadlock or waits on things that do not exist or have no producers? Is it possible to introduce such? - s On Jan 8, 2013, at 5:42 PM, Justin Clark-Casey wrote: Over the past couple of months, I have been struggling with an issue where mono 2.10.8 would sometimes crash badly on a heavily loaded simulator (2000+ scripts). Symptoms are 100% cpu use, simulator locking up with all threads waiting on a lock which no other thread holds or crashing with native stack trace From analysis, this seems to be due to the use of Thread.Abort() to terminate script threads whose events do not complete within a short (or sometimes no) timeout. This is used in llDie() and llResetOtherScript(), amongst other things. The use of Thread.Abort() is considered harmful, leading to the kind of system instability described above [1] [2] [3], etc. This affects scripts running in both separate AppDomains and the same AppDomain, since script functions constantly reach into core OpenSimulator code. One could extend the timeout, but there is a tradeoff with timely script stopping. Also, even a large timeout would not guarantee that threads would not be aborted. Therefore, I will probably soon investigate a mechanism for stopping scripts without calling Thread.Abort(). This will probably involve the use of Thread.Interrupt() for Sleeps and the insertion of 'should I stop' flag checks in generated code where that code may be long running (e.g. control structures for, goto, etc. and user defined functions). This is the normal approach one would take to co-operatively stop threads and avoid the chance of leaving Mono/.NET in a bad state. The existing Thread.Abort mechanisms will remain default until this approach is shown not to have significant bugs/problems. However, I think in the long term we have to stop using Thread.Abort() by default since it is not a safe thing to do. Comments welcome. [1] http://stackoverflow.com/questions/1051838/killing-a-thread-c [2] http://msdn.microsoft.com/en-us/library/7a2f3ay4%28v=vs.80%29.aspx [3] http://stackoverflow.com/questions/2251964/c-sharp-thread-termination-and-thread-abort -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] IRegisterInterface for extending scene entities
Hi, first off, extending scene entities is a Good Thing. I'll think a bit about the ins and outs of it and the caveats (for instance, module load order will have some hidden traps for the unwary) and serialization - well, there be dragons, you can't serialize module refs/interfaces since the destination may not have them. llSetKeyfranedMotion can most likely not be implemented that way. We know, because we have implemented it. Also, there is no need to reinvent the wheel - llSetKeyframedMotion has been slated for core release for a while now, we just haven't found the dev time to extract it. So there is really no need for a second, competing implementation. So, in summary +1 on extension points for scene entities -0 on a second implementation of llSetKeyframedMotion as a tested and working one already exists. That's -0 because of you really want it I won't kee you from doing it - it's just a waste of effort. Melanie On 28/12/2012 08:38, Adams, Robert wrote: The discussion about the implementation of the llKeyframeMotion function hinted at a need for region modules to be able to add data and functions to existing scene items. Here is a modest proposal for discussion[1]. Define a general module/interface registration interface to add to EntityBase (and thus to SceneObjectGroup and ScenePresence). IRegisterInterface Void RegisterInterfaceT(T iface); Bool TryGetT(out T iface); T GetT(); Void ClearRegisteredInterfaces(); Any class that implements the IRegisterInterface interface would contain a: Private DictionaryType, object m_registeredInterfaces = new DictionaryType, object(); 'Scene' already has a RegisterModule interface which has a bunch of neat features (like being able to register multiple instances of the same interface type) but I'm not sure that is needed here (discussion?) Particularly industrious changing could merge this proposed interface and the existing 'Scene' functions. So, something like a llKeyframeMotion implementing region module could register a KeyframeMotionState type structure on the SOG to save information about the keyframe for that SOG. Other uses could be a uniform way for adding classes of functionality to scene objects (get me the interface for extracting the physical mesh for this SOG) or just adding limpet like code to a scene entity. Not sure of the nuances of serialization. I believe that the registered interfaces would just be serialized with the SOG (thus saving and restoring the values in the registered interface instances) but I can't be totally sure of that. Anyway, run your sword through this strawman. -- ra [1] This is similar to other interfaced proposed in the past (particularly one by Adam Frizby). ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] IRegisterInterface for extending scene entities
I suggest we bounce this about a bit and maybe cooperatively work on a test case/POC. That will certainly clarify issues. I could also pull out the prosal I did for ReX which deals with this Melanie On 28 Dec 2012, at 18:38, Adams, Robert robert.ad...@intel.com wrote: I agree with not reinventing the wheel. And your valid concerns about the implementation are probably just the tip of the iceberg. I have been toying with the architectural idea that OpenSim core only provides a basic framework. Functionalities are added as plugin modules rather than implemented as if's and tests imbedded in core. For instance, could linksets be implemented as a plugin module[1]? Or maybe entity physical representation (meshing)? I merely consider llSetKeyFrameMotion as a test case to expose needed core features which support plugin modules (Necessary events available? Correct data-structures exposed/hidden? ...) Like you, I am pretty sure the ability to programmatically extend scene entities will be needed and is a Good Thing. Since llSetKeyframeMotion has already been completed and will be incorporated soon, I'll look for another simple test case to exercise the requirements for full featured plugin modules. -- ra [1] Why would one want to do this? I've been thinking about fancy linksets where the joints are not fixed and static but could be parameterized and dynamic (hinges, sliders, 6DOF, ...). This could be used to support skeletons, doors with real hinges and/or weird and wonderful vehicles. Rather than mangling OpenSim core with lots of experimental code, it would be nice if I could build an ExtendedLinksets module that could be plugged in and experimented with. -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Melanie Sent: Friday, December 28, 2012 12:44 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] IRegisterInterface for extending scene entities Hi, first off, extending scene entities is a Good Thing. I'll think a bit about the ins and outs of it and the caveats (for instance, module load order will have some hidden traps for the unwary) and serialization - well, there be dragons, you can't serialize module refs/interfaces since the destination may not have them. llSetKeyfranedMotion can most likely not be implemented that way. We know, because we have implemented it. Also, there is no need to reinvent the wheel - llSetKeyframedMotion has been slated for core release for a while now, we just haven't found the dev time to extract it. So there is really no need for a second, competing implementation. So, in summary +1 on extension points for scene entities -0 on a second implementation of llSetKeyframedMotion as a tested and working one already exists. That's -0 because of you really want it I won't kee you from doing it - it's just a waste of effort. Melanie On 28/12/2012 08:38, Adams, Robert wrote: The discussion about the implementation of the llKeyframeMotion function hinted at a need for region modules to be able to add data and functions to existing scene items. Here is a modest proposal for discussion[1]. Define a general module/interface registration interface to add to EntityBase (and thus to SceneObjectGroup and ScenePresence). IRegisterInterface Void RegisterInterfaceT(T iface); Bool TryGetT(out T iface); T GetT(); Void ClearRegisteredInterfaces(); Any class that implements the IRegisterInterface interface would contain a: Private DictionaryType, object m_registeredInterfaces = new DictionaryType, object(); 'Scene' already has a RegisterModule interface which has a bunch of neat features (like being able to register multiple instances of the same interface type) but I'm not sure that is needed here (discussion?) Particularly industrious changing could merge this proposed interface and the existing 'Scene' functions. So, something like a llKeyframeMotion implementing region module could register a KeyframeMotionState type structure on the SOG to save information about the keyframe for that SOG. Other uses could be a uniform way for adding classes of functionality to scene objects (get me the interface for extracting the physical mesh for this SOG) or just adding limpet like code to a scene entity. Not sure of the nuances of serialization. I believe that the registered interfaces would just be serialized with the SOG (thus saving and restoring the values in the registered interface instances) but I can't be totally sure of that. Anyway, run your sword through this strawman. -- ra [1] This is similar to other interfaced proposed in the past (particularly one by Adam Frizby). ___ Opensim-dev mailing list Opensim
Re: [Opensim-dev] ScriptEvents Module
Hi,
you may want to hold off on this. In the vein of the custom script
functions and constants we have already, I have been looking to
allow custom script events which would be real events.
Melanie
On 19/11/2012 02:28, Diva Canto wrote:
Hi,
I am working on a module that passes interesting scene events up to the
scripts in a manner that's very easy to act upon. An example is attached
at the end of this message.
Question: What other events would people like to grab? The idea is to
have the module do all the complicated logic, and pass only simple facts
to the scripts.
state_entry()
{
llSay(0, Script running);
modSendCommand(Script Events, subscribe|AvatarArrived,
llGetKey());
modSendCommand(Script Events, subscribe|LastAvatarLeft,
llGetKey());
}
link_message(integer sender_num, integer num, string message, key id)
{
list parts = llParseString2List(message, [|], []);
if (llGetListLength(parts) = 2) {
if (llList2String(parts, 1) == AvatarArrived) {
// message is: event|AvatarArrived|True or False --
LocalTeleport or HG Teleport
if (llGetListLength(parts) = 3) {
if (llList2String(parts, 2) == True) {
llInstantMessage(id, Welcome to the Gateway!
Choose your destination by walking into one of the teleporters.);
llRegionSay(region_channel, ports foreign);
} else {
llInstantMessage(id, Welcome to the Virtual
Lab's Gateway! Choose your local destination by walking into one of the
teleporters.);
llRegionSay(region_channel, ports local);
}
} else {
llSay(0, Malformed message + message + +
(string)llGetListLength(parts));
}
play_music();
} else if (llList2String(parts, 1) == LastAvatarLeft) {
// message is: event|LastAvatarLeft
llRegionSay(region_channel, ports reset);
}
}
}
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] [Windows] possible intresting registery setting.
All three methods pertain to Windows Sockets, the Win/BSD socket API extension. These settings are irrelevant for .NET. Melanie On 05/11/2012 22:46, Nebadon Izumi wrote: the 1st link seems to only apply to older versions of Windows NT, so I do not really so how this could possibly have any effect on Windows 7, also the second one also seems to not be relevant to Windows 7 either, though it may have some effect on Windows Vista based machines, even though it does not claim it would, I do however know that Windows 7 handles TCP very differently than any previous version of windows, so I am highly skeptical that either of these changes would have any effect on OpenSimulator running on Windows 7. On Mon, Nov 5, 2012 at 3:40 PM, R.Gunther ri...@rigutech.nl wrote: Mijn sims zijn nu 4 dagen up met een aangepaste registery setting in windows. Het lijkt hier voor mijn gevoel even wat soepeler te lopen. Ik he aan windows7 de volgende key toegevoegt. **NonBlockingSendSpecialBufferin**g Its also available for other windows version, only location is slightly different in registery. So, am curious what others think. Here are some Microsoft KB articles http://support.microsoft.com/**kb/126967http://support.microsoft.com/kb/126967 http://support.microsoft.com/**kb/823764http://support.microsoft.com/kb/823764 ALso because this, is opensim useing the push bit for tcp ? DOnt useing the p[ush bit can give some problems with tcp, That maby explains why this setting works better for me ? Keep testing here.. __**_ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/**mailman/listinfo/opensim-devhttps://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Update for group module flotsam
The presence service already has a call to fetch the online status for a list of users rather then for just one user, AFAIR. At least I remember putting such a call into the design. Melanie On 29/10/2012 01:13, Michelle Argus wrote: I have updated the proposal page and listed the diffrent alternative from A onwards sothat its easier for us. My current favorite is the alternative E: The group server requests the online status from the grid server itself and caches this data instead of the grid server keeping the group server updated. - Simulators request their data directly from the group server and sends IMs itself OR - Optionaly the Simulator communicates via a relay service with its own cache. The relay service requests its data from the same central group server. The relay service can additionaly send IMs if wanted to reduce resource usage simulator side. The relay service can be hosted by anyone for a worldwide network. The same concept could be used for other services such as assets, presence, inventory, friendslist etc which are meanwhile causing many issues due to slow requests in bigger grids such as OSGrid. Am 23.10.2012 04:40, schrieb Justin Clark-Casey: Apologies, it's [1]. Please feel free to edit it as you see fit - I've put you as one of the proposers. This page is to keep track of the issue rather than a formal proposal mechanism. No rush on this - please feel free to take your time in responding. In truth, I only have a certain amount of time for these issues currently myself. Having messages route through a service rather than be largely handled by simulators themselves is an interesting approach. It's the argument of a distributed versus a more centralized architecture. Although I can't see OpenSimulator going down this route in the near future, if anybody wants to experiment and needs additional config settings then patches are very welcome. [1] http://opensimulator.org/wiki/Feature_Proposals/Improve_Groups_Service On 20/10/12 11:06, Michelle Argus wrote: Justin, could you post the url to the suggestion page, I think you forgot to add it ;) One issue that having the sim updating online status is, that if someone has the group module diabled or uses a diffrent setting then the status is not updated. As other modules hosted by the grids also might this information, one should consider adding something to the gridserver for this. I also like the idea from Akira to have the groupserver to receive the full IM and then sending it to everyone instead of having the sim send the message. One then could have a specialized server installed for the group module which cannot create any lagissues simside. This could then also be used for a gridwide spamfilter or filtering illigal activities within the grid. Havnt had much time though as I have a longer event running which ends on sunday... Am 20.10.2012 04:32, schrieb Justin Clark-Casey: Regarding the groups work, I have now implemented an OpenSimulator experimental option, MessageOnlineUsersOnly in [Groups] as of git master 1937e5f. When set to true this will only send group IMs to online users. This does not require a groups service update. I believe OSGrid is going to test this more extensively soon though it appears to work fine on Wright Plaza. It's temporarily a little spammy on the console right now (what isn't!) with a debug message that says how many online users it is sending to and how long a send takes. Unlike Michelle's solution, this works by querying the Presence service for online users, though it also caches this data to avoid hitting the presence service too hard. Even though I implemented this, I'm not convinced that it's the best way to go - I think Michelle's approach of sending login/logoff status directly from simulator to groups service could still be better. My chief concern with the groups approach is the potential inconsistency between online status stored there and in the Presence service. However, this could be a non-issue. Need to give it more thought. On 14/10/12 22:53, Akira Sonoda wrote: IMHO finding out which group members are online and sending group IM/Notice etc. to them actually should not be done by the region server from which the group IM/notice etc. is sent. This is a task which should be done centrally in case of OSgrid in Dallas TX ( http://wiki.osgrid.org/index.php/Infrastructure ). The region server should only collect the group IM/notice etc. and send it to the central group server or in the other way receiving IM/notice etc. from the central group server and distribute it to the Agents active on the region(s). That concentrates all distribution on a central point rather than spreading it amongst simulators. Then OSGrid has the problem of scaling this up. Having said that, there are advantages to funnelling things through a reliable central
Re: [Opensim-dev] [Opensim-users] Slow handling of POST -
I posted a pull request to them to pick up the fix I made. Melanie On 03/10/2012 01:11, Mic Bowman wrote: Did mono fix the other problem that multiple concurrent connections to the same endpoint would always cause excessive delay (concurrent requests would not start until seconds after the previous one completed). That's why the serialize requests code was put in there. --mic On Tue, Oct 2, 2012 at 3:50 PM, Justin Clark-Casey jjusti...@googlemail.com wrote: Actually, it appears that due to a bug in Mono [1] this may only help with asset fetches. But I think it's worth trying anyway. [1] https://github.com/mono/mono/pull/472 On 30/09/12 10:37, Ai Austin wrote: That sound very much like the issue I am seeing as Melanie also first mentioned. The POSTs are handled eventually I think but sometimes 10 minutes (!) AFTER the avatar logs out. meanwhile no activity on the region or login to that region seems to be possible. Sounds like a serious block? At 01:09 30/09/2012, opensim-users-requ...@lists.berlios.de wrote: This method blocks waiting for content to post; if there is no time-out set and you do not provide content, your application will block indefinitely. On 2012-09-22 02:22, Justin Clark-Casey wrote: There are no timeouts on these particular requests, which probably isn't a good thing - OpenSimulator is inconsistent when it comes to timeouts. However, I suspect that's going to be peripheral to the issue here. On 20/09/12 11:44, M.E. Verhagen wrote: I wonder if there is a timeout on the fetch request ? Or are they stacking up and just waiting till they are in the front of the line to be processed ? 2012/9/20 Justin Clark-Casey Fetch times of 1068560ms (which is more than 15 minutes!) are pathological - something is wrong. ___ Opensim-users mailing list opensim-us...@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-users -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc ___ Opensim-users mailing list opensim-us...@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-users ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Is it OK performance-wise to long-poll a money module?
You can use the PollServiceManager to do this. It's the same
mechanism the viewer uses.
However, if only one instance of the application long-polls, that is
one thread so you don't need to worry about resources too much.
Melanie
On 15/09/2012 11:53, Dahlia Trimble wrote:
I've had excellent luck serving many simultaneous long-poll requests with
the HTTP server that comes with OpenSimulator. Bear in mind though that
each active request may consume a thread so you might need to increase
available threads if you see problems. I'm not certain if the request
threads are managed by the threadpool in OpenSimulator or if they are
direct calls into .NET framework. I did search through the code once and
found many threads that were not treadpool managed but I can't remember if
HTTP threads were or not.
On Fri, Sep 14, 2012 at 9:07 PM, Edmund Edgar e...@avatarclassroom.comwrote:
I've got a situation with the money module I'm working on where I'd
like an external program (running on the client PC in parallel to the
viewer) to be able to be in almost constant contact with the server
while the user is logged in. (I want it to be able to find out
whenever the user wanted to buy something.)
I figure I can do this by having the external program long-poll the
OpenSim server. (The external program makes a request, the server
waits such time as it has something to tell the external program, then
responds. It gives up and responds if there's nothing to say after 30
seconds or so, at which point the external program will make a new
request and start the cycle again.)
At this point if I was serving a web application with Apache I'd start
worrying that I was hogging a bunch of threads and eating through the
memory. Is this the kind of thing I should be worrying about with
OpenSim, or can I merrily go ahead and long-poll without worrying?
The kind of thing I'm thinking of follows:
public void FirstRegionLoaded ()
MainServer.Instance.AddHTTPHandler (/checkfortransactions/,
CheckForTransactions);
}
public Hashtable CheckForTransactions(Hashtable request) {
UUID userUUID = (get a user id using a session ID passed in the
request or something);
int i;
// poll for 30 seconds then give up
for (i=0; i30; i++) {
if
(m_transactionsAwaitingNotification.containsKey(userUUID)) {
// Reply to the request
Hashtable reply = new Hashtable ();
reply[int_response_code] = 200;
reply[str_response_string] = { Some JSON goes
here };
reply[content_type] = text/json;
return reply;
}
Thread.Sleep (1000);
}
Hashtable reply = new Hashtable ();
reply[int_response_code] = 204; // No Content
return reply;
// The client will get this reply then hit /checkfortransactions/
again.
}
PS. Thanks for the replies to my C#-ignorant questions on previous threads.
--
Edmund Edgar
Avatar Classroom
Your classroom, on the web, in a virtual world.
e...@avatarclassroom.com
+81 090 3912 3380
Skype: edmundedgar
Second Life: Edmund Earp
Linked In: edmundedgar
Twitter: @edmundedgar
http://www.avatarclassroom.com
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Question on where estate info for regions is kept
OpenSim assumes the OSGrid scenario of a federated grid of independent simulators. Therefore, central estate storage cannot be provided. However, if you run multiple simulators from the same platform, or run a private grid, you can create estates spanning these servers. Simply point the estate database to a database server that all your regions can access. This will give you estates that span your servers, or, in the event of a private grid, your entire grid, without forcing federated grids to also store this data. This is an advanced option and somewhat underdocumented. Melanie On 13/09/2012 12:33, Ai Austin wrote: I note that each Opensim.exe instance maintains the estate details for the region for grids as well as standalones, whereas the region UUID and details themselves are held in the central (Robust) services for grids. Is there a reason for that? It would seem that the estates ought to be something that spans all regions, and that regions are associated with them, rather than being separate to a specific region server/Opensim.exe instance? ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Questions about Vehicle scripting calls
Hi, we use a module that is been developed for us as custom work. It allows running unmodified SL vehicle scripts - well, mostly. We also have llSetKeyframedMotion() for things that don't really need to be physical. The latter will be donated to OpenSim at some point. Melanie On 06/06/2012 19:41, Bengt Falke wrote: Does anybody know what kind of physics Avination use? Physics works better there if I remember correctly? Void Pipe 6 jun 2012 kl. 19:10 skrev James Hughes: I have been experimenting with trains in SL and would like to make a physical one that works in OpenSim. Hopefully these cases aren't some limitation of the physics engines and can have a proper fix. -BlueWall On 06/05/2012 07:46 PM, Mike Higgins wrote: I was talking to Justin Clark-Casey at the OpenSim developers meeting this morning, and he suggested that the mailing lists would be the easiest way to have a conversation about vehicle physics on OpenSim. Justin you there? Is this where you meant? Anyone else want to talk about vehicle scripting in OpenSim? I am in the process of testing the OpenSim vehicle scripting calls and trying to find out what works and what can be worked around. I am submitting mantis reports when I think I see a true bug, issue numbers 0006039 http://opensimulator.org/mantis/view.php?id=6039 and 0006040 http://opensimulator.org/mantis/view.php?id=6040 for starters. Instead of submitting 1000 line vehicle scripts that do not work, I am writing small 10-line scripts that demonstrate a particular problem. Issue 0006040 http://opensimulator.org/mantis/view.php?id=6040 is particularly interesting because if my hypothesis is correct, the linear motor direction is being actively projected onto the global XY plane. I cannot get an airplane to glide up, or a balloon to rise using the linear motor. (Hover height works with balloons, but not the linear motor even with hover height disabled). The interesting thing about this is that my hypothesis suggests that there is extra code doing this projection onto the XY plane. I checked the vehicle flags and there isn't one that should force this extra projection into the calculations. Vehicle type balloon is supposed to have all the flags removed, but just to be sure I used the remove call to clear them all. The linear motor still cannot go up. Can someone familiar with the code look at the linear motor and tell me why this is happening and if there is a way to disable it? (I tried turning flags like VEHICLE_FLAG_NO_DEFLECTION_UP on to see if this flag was inverted, and if it applied to the motor instead of deflection, but no luck). The fun thing is that I can write one kind of vehicle that works well -- assuming this bug is there. I built a vehicle that has the linear motor set to 0,0,20, pointing straight up. When the vehicle is perfectly horizontal, the projection of this motor onto XY is 0,0,0 and the vehicle does nothing. But then when you tilt the vehicle in any direction, the projection of the linear motor on XY becomes non-zero and causes it to start moving in the direction of tilt. This feels a lot like an RL helicopter, so I used the control keys to pitch down/up to move forward/backwards, added yaw left and right, and used page-up/down to increase/decrease the hover height. I put it in a hacked together helicopter build and it is a lot of fun! I'm looking for work-arounds for the current vehicle routine behaviors. One work-around for an airplane is to turn on hover height, check the airplane speed and pitch once a second in timer(), calculate what altitude the plane should get to in the next second, and set hover height to that altitude. The things we do to get stuff working! ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] What do you like about OpenSim?
You are correct in your assumptions. The intention is to produce a few posters, each focusing on one statement and expressing that statement both visually and in text, as well as flyers listing those statements. Melanie On 01/05/2012 00:09, Borun (a.k.a. Boroondas Gupte) wrote: On 04/30/2012 12:08 PM, drwh...@spacefriends.de wrote: As i live at the other end of Germany i am not able to attend the Event. What exactly do you mean by flyers / Posters and why is the Subject of your Email opensim Key facts ? What kind pf Information is yet available ?? Best regards Wordfromthe Wise On 29.04.2012, at 03:47, Melanie mela...@t-data.com wrote: [W]e would [...] like to hear [...] what you like about OpenSim and what OpenSim is to you. If I've understood Melanie's email correctly, the facts she wants to collect are (supposedly short and catchy) statements about why you like OpenSim. E.g., if you were thinking I like OpenSim because it is open source., the corresponding fact might be OpenSim is open source.. The term fact might be a bit misleading here, as this inquiry doesn't seem to be about what all /could/ be known about OpenSim, but rather what you /do/ already know /and like/ about it. I guess these statements are then candidates to be used on some feature lists or fact sheets on the posters and flyers. So they would be for promotional purposes only, not manuals, not specs, nor reference texts or other kinds of documentation. Thus, (in this context) you shouldn't have to bother what information is already available, as comprehensiveness and completeness aren't required or even aimed for. (Just my interpretation. Please correct me if I got this backwards.) Cheers, Borun PS: Writing this message reminded me of how ack is promoted. (See http://betterthangrep.com/, http://betterthangrep.com/why-ack/ and http://betterthangrep.com/testimonials/.) ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] Opensim key facts
Hi, we are getting ready to do final graphics and design for the real life presence of OpenSimulator at LinuxTag, Berlin, from May 23rd. For that, we would like to generate some more copy for posters, flyers, etc. Although this is a German event and these will ultimately have to be done in German, we would still like to hear from all of you (in German if you can, otherwise in English) what you like about OpenSim and what OpenSim is to you. We are looking to collect these key facts to gather some ideas as to what copy would grab people's interest. Please reply before May 5th as these things have to be in print by end of play, European time, on the 4th. Also, we could still use people to staff the booth on the 23rd, 24th and 25th, answering questions about OpenSim and doing demonstrations. German language is a must, English is nice to have. Location is Berlin, Germany from 23rd of May till 26th of May. If you'd like to help, please email i...@opensimulator.org. Cheers, Melanie ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] Opensim key facts
Hi, we are getting ready to do final graphics and design for the real life presence of OpenSimulator at LinuxTag, Berlin, from May 23rd. For that, we would like to generate some more copy for posters, flyers, etc. Although this is a German event and these will ultimately have to be done in German, we would still like to hear from all of you (in German if you can, otherwise in English) what you like about OpenSim and what OpenSim is to you. We are looking to collect these key facts to gather some ideas as to what copy would grab people's interest. Please reply before May 5th as these things have to be in print by end of play, European time, on the 4th. Also, we could still use people to staff the booth on the 23rd, 24th and 25th, answering questions about OpenSim and doing demonstrations. German language is a must, English is nice to have. Location is Berlin, Germany from 23rd of May till 26th of May. If you'd like to help, please email i...@opensimulator.org. Cheers, Melanie ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Remove check for IsGod in some OSSL functions
Any such checks should use Scene.Permissions.IsAdministrator() which will return true is the UUID given is of the estate owner, an estate manager or a god. Melanie On 13/04/2012 12:36, Oren Hurvitz wrote: While I'm on the subject of OSSL permissions, here's one more suggestion: if an OSSL function's Allowed setting is set to ESTATE_MANAGER then all the estate managers *except* for the owner are allowed to call that function. I think that isn't what users expect: since the list of estate managers always contains the estate owner, if I specify permission level ESTATE_MANAGER then I expect that the owner would also be able to call the function. See CheckThreatLevel() in OSSL_Api.cs. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Remove-check-for-IsGod-in-some-OSSL-functions-tp7462127p7462243.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Change parcel permission handling
Here, also, Scene.Permissions.IsAdministrator should be checked, then the parcel owner should be compared. Checking CanEditParcelProperties would have too broad a scope. Some of these functions are DANGEROUS and for instance renters should not be able to use them. So, -1 on broadening this check. Melanie On 13/04/2012 13:12, Oren Hurvitz wrote: I found another place that should be changed: if the permission level is set to PARCEL_OWNER then we should check World.Permissions.CanEditParcelProperties() instead of just checking if this is the parcel's owner. That would allow the function to be called by Gods, Estate Managers, and possibly group members (if the parcel is group-owned). In addition, there are 3 functions that check parcel ownership permissions on their own. These checks should be deleted, since they've been replaced by the general OSSL permissions mechanism: * osSetParcelDetails * osSetParcelMediaURL * osSetparcelSIPAddress -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Remove-check-for-IsGod-in-some-OSSL-functions-tp7462127p7462349.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Fix OSSL threat level checks
I know with the JSON function it was intentional. As for the Npc one, I don't know. Justin, can you enlighten us? Copy/Paste error or good intention? Melanie On 13/04/2012 11:59, Oren Hurvitz wrote: Hi, There are two OSSL functions that check the wrong string for their threat level: osParseJSONNew() - checks osParseJSON osNpcStopMoveToTarget() - checks osNpcStopMoveTo I was going to fix this, but then I thought that perhaps this was done so that the same threat level can be used for families of functions, e.g. both osParseJSON() and osParseJSONNew(). So is it ok to change these strings, or should I leave them alone? Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Fix-OSSL-threat-level-checks-tp7462134p7462134.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Remove check for IsGod in some OSSL functions
First, HARD -1 on allowing gods all of OSSL. I run a grid where
certain functions just CANNOT be allowed to run, no way, no how.
There must be a way to achieve that, you can't force the
availability of OSSL for gods on grids.
Also, HARD -1 on changing existing functions, it will break things
in too many ways for established users.
The check for estate managers already allows estate owners.
OpenSim/Region/ScriptEngine/Shared/Api/Implementation/OSSL_Api.cs:377
//Only Estate Managers may use the function
if(m_FunctionPerms[function].AllowedOwnerClasses.Contains(ESTATE_MANAGER))
{
//Only Estate Managers may use the function
if (World.RegionInfo.EstateSettings.IsEstateManager(ownerID)
World.RegionInfo.EstateSettings.EstateOwner != ownerID)
{
return;
}
}
A god check _could_ be added in the parcel owner, parcel group,
estate manager and estate owner clauses as it can be assumed that if
anyone is allowed to run the function gods should be allowed to run
it, too. However, if a function is indeed disabled it must be
disabled for gods as well.
Melanie
On 13/04/2012 14:39, Oren Hurvitz wrote:
Currently CheckThreatLevel() doesn't check for God at all. It should probably
allow gods to call any function, regardless of its threat level.
There is no other change necessary to OSSL in order to support
administrators, since there are already permission checks for estate owners
and managers. (Although, as I've said, the check for estate *managers*
should allow the estate *owner* as well.)
While we're talking about IsAdministrator(), I want to mention again that
this method is incorrect: it's identical to IsGod(), since it requires users
to be Gods. It should be changed so it doesn't require users to be gods
anymore.
--
View this message in context:
http://opensim-dev.2196679.n2.nabble.com/Remove-check-for-IsGod-in-some-OSSL-functions-tp7462127p7462562.html
Sent from the opensim-dev mailing list archive at Nabble.com.
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Change parcel permission handling
Not true. Even in SL estate owners/managers don't have some parcel rights. If I specify parcel owner, i expect parcel owner. Maybe a way needs to be found to combine multiple strings, e.g. ESTATE_MANAGER,PARCEL_OWNER. That would be acceptable. Changing the current behavior that people already depend on to relax security is not acceptable. It may mean that someone suddenly can do something they could not do before and the owners may not be aware of this, causing issues. Also, in case of a group owned parcel, group permissions govern what people in the group can do. Group members are by no means owners, often parcels are deeded only for access control but normal members have no rights whatsoever. Giving them potentially dangerous functions is not an option. On group owned parcels, those functions can be allowed either to group owners only (the group invite functions already do this check) or to deeded prims only. Allowing them for every member of the group is really bad. You don't really want to have your roleplay's members osTeleportAgent the opponents out of the fight! Again, relaxing existing constraints is not an option, but as you can see above, ways can be found to define combinations of permissions to allow more flexibility. Melanie On 13/04/2012 14:42, Oren Hurvitz wrote: The decision whether to allow the parcel owner to call a function or not is set by whoever setup OpenSim.ini: they can choose to allow PARCEL_OWNER, or only ESTATE_OWNER. If they decided to allow the PARCEL_OWNER then we should also allow the estate manager/owner to call that function. In addition, in the case of a group-owned parcel, all members of the group are owners. So this change doesn't allow more permissions: it would only correct the implementation of the existing permissions system, when PARCEL_OWNER has been specified. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Remove-check-for-IsGod-in-some-OSSL-functions-tp7462127p7462567.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Remove check for IsGod in some OSSL functions
Not so. ESTATE_MANAGER MEANS estate MANAGER. This is intentional. I
reread the code and found that it already allows a comma separated
list notation, so you can use ESTATE_OWNER,ESTATE_MANAGER.
This allows for finer grained control. Please understand that estate
owners may be significantly different from estate managers, for
instance in the case of a mainland. This division is useful and,
again, making changes could cause privilege escalation in some
grids. So, -1. What you want to achieve can already be achieved.
Same, btw, goes for parcels, you can specify
PARCEL_OWNER,PARCEL_GROUP_MEMBER to get the behavior you're looking
for, and/or add the estate management as well.
I would propose to add GODS to the list of keywords, since they
can't currently be allowed as a class.
Melanie
On 13/04/2012 15:36, Oren Hurvitz wrote:
About gods: ok. I don't allow any users to be gods for security reasons,
but I had assumed that if someone *does* have god permissions then they
should be able to do anything. Since that is not the case, I won't be
making any changes related to gods.
I assume by -1 on changing existing functions you mean not to change
IsAdministrator(). Ok, but that means we still have two methods that do the
same thing: IsGod() and IsAdministrator(). This doesn't affect what I'm
doing so I have no reason to push for this change, but it looks like a
longstanding bug. If anyone is interested in pursuing this, Godspeed :)
Regarding whether ESTATE_MANAGER includes the estate owner: it doesn't,
because of this code: World.RegionInfo.EstateSettings.EstateOwner !=
ownerID. It explicitly disallows the estate owner, while allowing all the
other estate managers. That's the code that should be removed.
Oren
On Fri, Apr 13, 2012 at 3:56 PM, Melanie-2 [via opensim-dev]
ml-node+s2196679n7462585...@n2.nabble.com wrote:
First, HARD -1 on allowing gods all of OSSL. I run a grid where
certain functions just CANNOT be allowed to run, no way, no how.
There must be a way to achieve that, you can't force the
availability of OSSL for gods on grids.
Also, HARD -1 on changing existing functions, it will break things
in too many ways for established users.
The check for estate managers already allows estate owners.
OpenSim/Region/ScriptEngine/Shared/Api/Implementation/OSSL_Api.cs:377
//Only Estate Managers may use the function
if(m_FunctionPerms[function].AllowedOwnerClasses.Contains(ESTATE_MANAGER))
{
//Only Estate Managers may use the function
if (World.RegionInfo.EstateSettings.IsEstateManager(ownerID)
World.RegionInfo.EstateSettings.EstateOwner != ownerID)
{
return;
}
}
A god check _could_ be added in the parcel owner, parcel group,
estate manager and estate owner clauses as it can be assumed that if
anyone is allowed to run the function gods should be allowed to run
it, too. However, if a function is indeed disabled it must be
disabled for gods as well.
Melanie
--
View this message in context:
http://opensim-dev.2196679.n2.nabble.com/Remove-check-for-IsGod-in-some-OSSL-functions-tp7462127p7462694.html
Sent from the opensim-dev mailing list archive at Nabble.com.
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Change parcel permission handling
Permissions don't necessarily inherit. For instance, an estate manager cannot change the parcel description or set a parcel to show in search in SL. There is some sovereignity in he parcel owner role. Permissions are indeed separate and a non-inheriting model allows some useful combinations that an inheritance based model does not. Melanie On 13/04/2012 15:48, Fleep Tuque wrote: I'm trying to think of a use case when I wanted a PARCEL_OWNER to have privileges that the ESTATE_MANAGER did/should not have and can't think of one off the top of my head. In every scenario I can think of where I assigned an Estate Manager through the Estate tools rather than using group permissions, it was because I expected them to have MORE permissions than the parcel owners and was setting that explicitly. Having said that, I do agree with Melanie that I would not expect a permission change on PARCEL_OWNER to affect the permissions for ESTATE_MANAGER. Generally I think of permissions inheriting down the hierarchy, not up, and I'm not sure the average grid owner would expect that kind of behavior. - Chris/Fleep Chris M. Collins (SL/OS: Fleep Tuque) Center for Simulations Virtual Environments Research (UCSIM) UCIT Instructional Research Computing University of Cincinnati 406A Zimmer Hall 315 College Drive PO BOX 210088 Cincinnati, OH 45221-0088 chris.coll...@uc.edu (513) 556-3018 http://ucsim.uc.edu On Fri, Apr 13, 2012 at 9:02 AM, Melanie mela...@t-data.com wrote: Not true. Even in SL estate owners/managers don't have some parcel rights. If I specify parcel owner, i expect parcel owner. Maybe a way needs to be found to combine multiple strings, e.g. ESTATE_MANAGER,PARCEL_OWNER. That would be acceptable. Changing the current behavior that people already depend on to relax security is not acceptable. It may mean that someone suddenly can do something they could not do before and the owners may not be aware of this, causing issues. Also, in case of a group owned parcel, group permissions govern what people in the group can do. Group members are by no means owners, often parcels are deeded only for access control but normal members have no rights whatsoever. Giving them potentially dangerous functions is not an option. On group owned parcels, those functions can be allowed either to group owners only (the group invite functions already do this check) or to deeded prims only. Allowing them for every member of the group is really bad. You don't really want to have your roleplay's members osTeleportAgent the opponents out of the fight! Again, relaxing existing constraints is not an option, but as you can see above, ways can be found to define combinations of permissions to allow more flexibility. Melanie On 13/04/2012 14:42, Oren Hurvitz wrote: The decision whether to allow the parcel owner to call a function or not is set by whoever setup OpenSim.ini: they can choose to allow PARCEL_OWNER, or only ESTATE_OWNER. If they decided to allow the PARCEL_OWNER then we should also allow the estate manager/owner to call that function. In addition, in the case of a group-owned parcel, all members of the group are owners. So this change doesn't allow more permissions: it would only correct the implementation of the existing permissions system, when PARCEL_OWNER has been specified. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Remove-check-for-IsGod-in-some-OSSL-functions-tp7462127p7462567.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Remove check for IsGod in some OSSL functions
That would overomplicate things, IMHO. There is no VIEWER BASED
permission that an estate manager has that an owner doesn't have.
Therefore creating a whole new method just for a single use (OSSL)
seems unnecessary to me.
Looks to me like a case of Don't touch a running system.
Melanie
On 14/04/2012 00:21, Justin Clark-Casey wrote:
I can see an argument for ESTATE_OWNER and ESTATE_MANAGER being separate
categories. I'm assuming that in the viewer
estate owners are can also be listed/not listed as estate managers. As
Melanie says, we have to be aware that
OpenSimulator is trying to accomodate many different use cases.
However, that does not mean that permission categories can be allowed to
become a confusing and/or overlapping mess.
Whether that is or isn't the case I don't know - this needs to be written out
properly on the wiki for all permission
types (parcel, estate, etc.) rather than only being embedded within the code.
I see that EstateSettings.IsEstateManager() regards an owner as a manager,
whilst OSSL_Api.CheckThreatLevel explicitly
does not regards an owner as an ESTATE_MANAGER. This is a contradiction.
The code MUST be internally consistent both
for sanity's sake and for ANY hope that the code can document itself.
In the first instance, I would want to create
EstateSettings.IsEstateManagerOrOwner() and call this where appropriate,
with IsEstateManager only returning true for estate managers, as is proper.
On 13/04/12 15:07, Oren Hurvitz wrote:
Regarding estate owner vs. manager: here's the existing implementation of
EstateSettings.IsEstateManager():
public bool IsEstateManager(UUID avatarID)
{
if (IsEstateOwner(avatarID))
return true;
return l_EstateManagers.Contains(avatarID);
}
It explicitly adds the estate owner to the list of managers. The permission
ESTATE_MANAGER should match the method
IsEstateManager(). Therefore, it should include the estate owner.
Oren
On Fri, Apr 13, 2012 at 4:49 PM, Melanie-2 [via opensim-dev] [hidden email]
/user/SendEmail.jtp?type=nodenode=7462795i=0 wrote:
Not so. ESTATE_MANAGER MEANS estate MANAGER. This is intentional. I
reread the code and found that it already allows a comma separated
list notation, so you can use ESTATE_OWNER,ESTATE_MANAGER.
This allows for finer grained control. Please understand that estate
owners may be significantly different from estate managers, for
instance in the case of a mainland. This division is useful and,
again, making changes could cause privilege escalation in some
grids. So, -1. What you want to achieve can already be achieved.
View this message in context: Re: Remove check for IsGod in some OSSL
functions
http://opensim-dev.2196679.n2.nabble.com/Remove-check-for-IsGod-in-some-OSSL-functions-tp7462127p7462795.html
Sent from the opensim-dev mailing list archive
http://opensim-dev.2196679.n2.nabble.com/ at Nabble.com.
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Remove check for IsGod in some OSSL functions
Well, current assumption in the code is that an estate owner ism
able to do anything a manager can do. Except in OSSL. It's one thing
to rename a method to make it's function more clear, but I believe
the separate method you proposed is not needed.
If you rename a method, any external code that used it will fail and
will have to be adapted.
If you, however, rename a method and then introduce another one with
the name of the old one, but different functionality, external code
will still compile but behave wrong.
So I would not oppose renaming the function to
IsEstateOwnerOrManager, but I would suggest not to implement a
specific IsEstateManager function at this time. That functionality
is only needed in one place and there is already code there that
emulates it.
Melanie
On 14/04/2012 01:08, Justin Clark-Casey wrote:
You are conflating two separate points, a category system for OSSL functions
and the fact that the code is internally
inconsistent in its view of whether an estate manager includes an estate
owner or not.
Any philosophy of Don't touch a running system is the way to long term
irrelevance and code that is increasingly
complicated for new contributors to work out. It has no place in an
alpha-level open-source project.
On 13/04/12 23:59, Melanie wrote:
That would overomplicate things, IMHO. There is no VIEWER BASED
permission that an estate manager has that an owner doesn't have.
Therefore creating a whole new method just for a single use (OSSL)
seems unnecessary to me.
Looks to me like a case of Don't touch a running system.
Melanie
On 14/04/2012 00:21, Justin Clark-Casey wrote:
I can see an argument for ESTATE_OWNER and ESTATE_MANAGER being separate
categories. I'm assuming that in the viewer
estate owners are can also be listed/not listed as estate managers. As
Melanie says, we have to be aware that
OpenSimulator is trying to accomodate many different use cases.
However, that does not mean that permission categories can be allowed to
become a confusing and/or overlapping mess.
Whether that is or isn't the case I don't know - this needs to be written
out properly on the wiki for all permission
types (parcel, estate, etc.) rather than only being embedded within the
code.
I see that EstateSettings.IsEstateManager() regards an owner as a manager,
whilst OSSL_Api.CheckThreatLevel explicitly
does not regards an owner as an ESTATE_MANAGER. This is a contradiction.
The code MUST be internally consistent both
for sanity's sake and for ANY hope that the code can document itself.
In the first instance, I would want to create
EstateSettings.IsEstateManagerOrOwner() and call this where appropriate,
with IsEstateManager only returning true for estate managers, as is proper.
On 13/04/12 15:07, Oren Hurvitz wrote:
Regarding estate owner vs. manager: here's the existing implementation of
EstateSettings.IsEstateManager():
public bool IsEstateManager(UUID avatarID)
{
if (IsEstateOwner(avatarID))
return true;
return l_EstateManagers.Contains(avatarID);
}
It explicitly adds the estate owner to the list of managers. The
permission ESTATE_MANAGER should match the method
IsEstateManager(). Therefore, it should include the estate owner.
Oren
On Fri, Apr 13, 2012 at 4:49 PM, Melanie-2 [via opensim-dev][hidden email]
/user/SendEmail.jtp?type=nodenode=7462795i=0 wrote:
Not so. ESTATE_MANAGER MEANS estate MANAGER. This is intentional. I
reread the code and found that it already allows a comma separated
list notation, so you can use ESTATE_OWNER,ESTATE_MANAGER.
This allows for finer grained control. Please understand that estate
owners may be significantly different from estate managers, for
instance in the case of a mainland. This division is useful and,
again, making changes could cause privilege escalation in some
grids. So, -1. What you want to achieve can already be achieved.
View this message in context: Re: Remove check for IsGod in some OSSL
functions
http://opensim-dev.2196679.n2.nabble.com/Remove-check-for-IsGod-in-some-OSSL-functions-tp7462127p7462795.html
Sent from the opensim-dev mailing list
archivehttp://opensim-dev.2196679.n2.nabble.com/ at Nabble.com.
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Cannot trigger sensor event from at_target ?
The best way to fond out is to post a Mantis report including the script so others can test it and also maybe spot script errors. Melanie On 04/04/2012 03:23, R.Gunther wrote: I created a difefrent script, with waypoints. If the last waypoint is reached, then i try to load new data with the llsensor and sensor event from inside the at_target event. Now am not sure if this a bug or some limitation in lsl. But when i final reacht the last target, i see with a llownersay that the if get trigger. But then the sensor event dont get triggered. it works fine after you save the script then state_entry() get triggered and the first set of targets get loaded/created. but afetr that i dont get any sensor event trigger. So i see the objects keep useing over and over the same target points. Bug ?... or a limitation ? Richard ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Uniqueness in MySQL useraccounts ('Name' field)
Actually, it's the combination FirstName, LastName and ScopeID that needs to be kept unique as different scopes may well contain users with identical names. Such a change would break some existing code (web interfaces mostly). Opensim allows you to modify the database, so if you add/change this on your system opensim will still work. This may be a better and faster solution for you. Melanie On 07/03/2012 07:16, Kevin Buckley wrote: I have a question/request which was being discussed on the Opensim Users list and Justin suggested it might be better handled here? As a developer of an Opensim member/user system I need to maintain the attribute that the combination of FirstName and LastName is unique within an individual Opensim implementation. To achieve that, on a server which supports multiple, concurrent signups, the best way is to have a unique, composite key in the useraccounts table which includes FirstName and LastName and then trap MySQL error 1062 (duplicate entry) when attempting to create a new user record. This avoids the situation where the code checks for uniqueness in step-1 and then, if it satisfies that, writes the new user record in step-2; with the risk that another process writes a duplicate record between those steps. There are other ways to deal with this but they introduce their own issues and they're not as efficient as the method above. The Opensim setup process already goes to the trouble of creating such a composite key, called 'Name'. However, it doesn't give it the UNIQUE attribute. So, currently (as an easy fix and to avoid having to remember to manually edit the database index every time I upgrade Opensim) my code forces 'Name' to be UNIQUE every time a new user subscribes. But clearly this is a large and mostly pointless overhead as it actually only needs to do it once. So my question/request is: is it possible to modify subsequent Opensim releases so that 'Name' is given the UNIQUE attribute by default (probably a one line code change I imagine)? I can't see any downside to this and, unless I'm missing something, it seems a logical thing to do? Kevin ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Uniqueness in MySQL useraccounts ('Name' field)
It allows to keep data from more than one grid in the same set of
tables (for hosting multiple grids on shared systems)
Melanie
On 07/03/2012 11:42, Kevin Buckley wrote:
What does ScopeID do (if that can be answered in one sentence)?
-Original Message-
From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Melanie
Sent: 07 March 2012 10:25
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Uniqueness in MySQL useraccounts ('Name' field)
Actually, it's the combination FirstName, LastName and ScopeID that
needs to be kept unique as different scopes may well contain users
with identical names.
Such a change would break some existing code (web interfaces
mostly). Opensim allows you to modify the database, so if you
add/change this on your system opensim will still work. This may be
a better and faster solution for you.
Melanie
On 07/03/2012 07:16, Kevin Buckley wrote:
I have a question/request which was being discussed on the Opensim Users
list and Justin suggested it might be better handled here?
As a developer of an Opensim member/user system I need to maintain the
attribute that the combination of FirstName and LastName is unique within
an
individual Opensim implementation.
To achieve that, on a server which supports multiple, concurrent signups,
the best way is to have a unique, composite key in the useraccounts table
which includes FirstName and LastName and then trap MySQL error 1062
(duplicate entry) when attempting to create a new user record. This
avoids
the situation where the code checks for uniqueness in step-1 and then, if
it
satisfies that, writes the new user record in step-2; with the risk that
another process writes a duplicate record between those steps.
There are other ways to deal with this but they introduce their own issues
and they're not as efficient as the method above.
The Opensim setup process already goes to the trouble of creating such a
composite key, called 'Name'. However, it doesn't give it the UNIQUE
attribute.
So, currently (as an easy fix and to avoid having to remember to manually
edit the database index every time I upgrade Opensim) my code forces
'Name'
to be UNIQUE every time a new user subscribes. But clearly this is a
large
and mostly pointless overhead as it actually only needs to do it once.
So my question/request is: is it possible to modify subsequent Opensim
releases so that 'Name' is given the UNIQUE attribute by default (probably
a
one line code change I imagine)?
I can't see any downside to this and, unless I'm missing something, it
seems
a logical thing to do?
Kevin
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] using LSL functions from a region module
You cannot call any code in LSL_Api.cs. Anything you need from there needs to be duplicated. Melanie ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] using LSL functions from a region module
LSL_Api is for script use. It doesn't live in the normal opensim space. You could probably tweak things enough to instantiate a usable copy, but that would be unsupported and ay break in the future. Frankly, it's more trouble than it's worth. Melanie On 02/02/2012 18:34, CJ Davies wrote: On 02/02/2012 05:31 PM, Melanie wrote: You cannot call any code in LSL_Api.cs. Anything you need from there needs to be duplicated. Melanie ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev Thanks Melanie. Is the reason as I suspect one to do with scope? Or are there more complex things at play? Regards, CJ Davies ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] SaveChangedAttachments on RemoveClient
Hi, it should happen only on logout / disconnect, not when leaving a sim. Good catch! Melanie On 01/02/2012 06:10, Diva Canto wrote: Hi Justin, In case I don't see you in the IRC, could you please look into what's going on in AttachmentsModule.SaveChangedAttachments, specifically commit 8880ae and 62b3e7 both on 2011/9/13. That method is being called when avies leave the sims, and, as is, it's saving the attachments independent on whether they were changed or not (when they have scripts). The assetID in inventory is being changed. This screws up inventory when the avie is visiting other grids, because the assetID at that point exists only in the visited grid, and is not being posted back. I would fix it, but I don't know what the intentions of that code are... It seems very odd that attachments are always being recreated when avies leave sims. Thanks. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] SaveChangedAttachments on RemoveClient
Yes, I think that is a good first step. Melanie On 01/02/2012 10:21, Bo wrote: Hello, and my congrats Diva. Please forgive me a noob question, but i wonder if that should be not disabled for HG visitors at all. Not sure, but don't HG visitors technically log out from remote grid while while they go home? Bo On Wednesday 01 of February 2012 10:10:04 Melanie wrote: Hi, it should happen only on logout / disconnect, not when leaving a sim. Good catch! Melanie On 01/02/2012 06:10, Diva Canto wrote: Hi Justin, In case I don't see you in the IRC, could you please look into what's going on in AttachmentsModule.SaveChangedAttachments, specifically commit 8880ae and 62b3e7 both on 2011/9/13. That method is being called when avies leave the sims, and, as is, it's saving the attachments independent on whether they were changed or not (when they have scripts). The assetID in inventory is being changed. This screws up inventory when the avie is visiting other grids, because the assetID at that point exists only in the visited grid, and is not being posted back. I would fix it, but I don't know what the intentions of that code are... It seems very odd that attachments are always being recreated when avies leave sims. Thanks. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSim Code
The entire concept of Master Avatar has been removed from Opensim in favor of the god level the viewer supports. There is an Estate Owner and that is initially set via console, this is intentional. Why do you have an issue with it? Your config file can give the names of avatars who have god mode available to them, this is what replaces the Master Avatar. Melanie ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSim Code
It's simply that it is set in database tables that don't exist before the first run. However, it wasn't thought through to the point of taking those values from the configuration file, which is entirely possible to do. I would suggest a new section: [EstateDefaults] EstateName = Name EstateOwner = Avatar Name The title, EstateDefaults, would make it clear that changing this owner will not change the owner of the estate once it's created, since it's only a default. It was one of the issues with the Master Avatar that people expected to change the aster avatar name in the config file and have the parcel owner of the sim sized parcel (which they confused with ownership of the sim) change as well. Master Avatar was a code, logic and support nightmare. I would be in favor of the above being added as optional config options. Melanie On 22/01/2012 00:41, Fernando Francisco de Oliveira wrote: Hello, Do you know why the Estate Owner was intentionaly set via console ? Security issues or something like that ? Fernando Oliveira http://oliveira.eti.br 2012/1/21 Melanie mela...@t-data.com The entire concept of Master Avatar has been removed from Opensim in favor of the god level the viewer supports. There is an Estate Owner and that is initially set via console, this is intentional. Why do you have an issue with it? Your config file can give the names of avatars who have god mode available to them, this is what replaces the Master Avatar. Melanie ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] OpenSim Code
Hi, you should really submit a patch to core. There is little point in keeping stuff that is generically useful in forks as too much fragmentation only means that a user will be unable to find the feature mix they want in any one fork. Better to keep things of general interest in core so all distros have it. Melanie On 22/01/2012 02:27, Fernando Francisco de Oliveira wrote: Hi Melanie I liked your suggestion and I will try to do it on my fork of source code :) Thanx for it Fernando Oliveira http://oliveira.eti.br 2012/1/21 Melanie mela...@t-data.com It's simply that it is set in database tables that don't exist before the first run. However, it wasn't thought through to the point of taking those values from the configuration file, which is entirely possible to do. I would suggest a new section: [EstateDefaults] EstateName = Name EstateOwner = Avatar Name The title, EstateDefaults, would make it clear that changing this owner will not change the owner of the estate once it's created, since it's only a default. It was one of the issues with the Master Avatar that people expected to change the aster avatar name in the config file and have the parcel owner of the sim sized parcel (which they confused with ownership of the sim) change as well. Master Avatar was a code, logic and support nightmare. I would be in favor of the above being added as optional config options. Melanie On 22/01/2012 00:41, Fernando Francisco de Oliveira wrote: Hello, Do you know why the Estate Owner was intentionaly set via console ? Security issues or something like that ? Fernando Oliveira http://oliveira.eti.br 2012/1/21 Melanie mela...@t-data.com The entire concept of Master Avatar has been removed from Opensim in favor of the god level the viewer supports. There is an Estate Owner and that is initially set via console, this is intentional. Why do you have an issue with it? Your config file can give the names of avatars who have god mode available to them, this is what replaces the Master Avatar. Melanie ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Prospective ODE physics changes
Hi, On 02/01/2012 21:51, Justin Clark-Casey wrote: I'm thinking of making two ODE related changes. 1) Replace the current ODE libraries in OpenSimulator with ones compiled using the older GIMPACT collider instead of OPCODE. This is to address ODE crashes in simulators with more than one region as detailed in [1] and [2]. These don't appear to occur with GIMPACT. I'm not happy with that as a general decision. We should, if anything like that is done, include both versions to give users the choice. The OPCODE should remain the default in order to not jeopardize existing setups and the GIMPACT libs can be copied in by those experiencing the bug. Many people don't run multiregion at all and would see only downsides if this were done. 2) Reducing contacts_per_collision in [ODEPhysicsSettings] from 80 to something much lower, maybe even 1. In my own testing, reducing this number can halve scene physics time. Normal avatar operations, such as standing on prims or walking up ramps appear to be unaffected even at 1. However, more testing is probably needed to arrive at a compromise number. This would greatly affect scripts using physics. I believe the optimum would be 16-20, which would ensure that the scripting maximum (16) collision contacts are always available. Melanie ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Sit position changes in OpenSimulator b6df9e9 (Sat 5th Nov 2011)
If any option then it needs to default to the new offsets or no change will ever happen. However, I would much prefer no option as I see everyone flipping it on to save themselves the pain. Melanie On 05/12/2011 04:49, Edmund Edgar wrote: Going forward it sounds the right way has to be to fix the thing and deal with the pain, but as a general principle, the system administrator in me says you should provide a config switch if you can do it without a lot of extra work. When you have to make a change that affects your users, it's always best to have options which steps you perform in what order. For example, in a behind-the-firewall school build you might have a load of content that you don't want to mess with in the middle of the term, but you might still want to upgrade to get some bug fixes, especially if there are some security issues involved. It's also good to have the option of reverting a user-facing change if somebody discovers something they've overlooked and need to spend more time preparing for. A version upgrade can often be reverted with effort, but it's much easier to revert a config change. It's true that giving administrators this choice risks keeping the old thing circulating for longer, but not doing that risks them just not upgrading, which causes the same problems plus a bunch of other ones. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Sit position changes in OpenSimulator b6df9e9 (Sat 5th Nov 2011)
As I am the one who did it, +1 on leaving it fixed. Items can be fixed and copy/paste compatibility for new objects coming in from sl is more important, IMHO. Melanie On 05/12/2011 04:14, Trinity wrote: i say fix it and let the chips fall where they may On Fri, Dec 2, 2011 at 3:55 PM, Justin Clark-Casey jjusti...@googlemail.com wrote: OpenSimulator commit b6df9e9 (dev code) changed the sit target adjustment to better match that used in Second Life. Unfortunately, this has the effect of making all existing sit positions set by scripts using llSitTarget() inaccurate (e.g. avatar ends up hovering above a chair). From a user/scripter point of view this is a bad thing. Not only do existing objects with user inventory/prim inventory now have wrong values, but positions loaded from OARs/IARs will now be wrong without adjustment, and OARs/IARs saved in dev code or future 0.7.3 will have wrong sit values when loaded into older OpenSim releases. However, I believe that's it's practically impossible to have old objects correctly use the old sit adjustment and new objects the new one. Here are the alternative courses of action and my considered pros/cons of each 1. Change sit adjustment with no other action. PROS: llSitTarget() is now implemented correctly. No legacy mess in the code. No extra complexity required. No development work required. CONS: Without adjustment, all region, inventory objects and scripts now use wrong sit values. Wrong sit values in OARs and IARs. Wrong sit values when OARs/IARs/objects moved between dev/future 0.7.3 versions and older OpenSim versions. 2. Provide a tool to correct sit values in scripts CONS: Too difficult since requires massive amount of script analysis. Might be possible in a limited way to catch 80/20 cases. 3. Use different sit adjustment depending on prim creation date (pre Sat 5 Nov 2011 use old value). PROS: Stops older sit positions from being wrong. Doesn't require much code change. CONS: A user has to know an opaque magic date when the sit position changed. Somewhat messy legacy code. Future upgraders from 0.7.2 will get some prims with 'wrong' sit positions and others with 'right' depending on when they were created, which is in the long term possibly more confusing than everything needing adjustment. 4. Revert llSitTarget() behave and create an osSitTarget() using the new adjustment instead. PROS: All existing sit targets continue to be 'correct', and old scripts still work correctly in new objects. CONS: llSitTarget() remains wrong for all time (could warn on use and eventually change, but users don't pay attention to such warnings). 5. Store new sit positions in a different field on SOP and use this if present with new sit adjustment, otherwise use old field with old sit adjustment. PROS: Works invisibly as long as old scripts don't set new values. CONS: Messy legacy code. Old scripts probably will set new values - then would need to act differently on script item creation date, with same issues as 3. 6. Provide a config switch to use old sit adjustment or new. PROS: Administrator controllable. In a future OpenSim release, admin can decide when they are going to flip to using the 'new' value. This might be done anyway for the use case where OpenSim is being used with content in isolation from elsewhere. CONS: Encourages the creation of more objects using the old sit values, encouraging a continuous mix of old and new values which can't both be used on the same region. Doubtless there are other strategies, but on the face of it there doesn't seem to be an ideal solution. It's made much more difficult by the fact that these values can only be scripts rather than as properties on the part (a decision which I find hard to swallow). On the whole, I think that it's better to accept the pain of change as early as possible and move to a world where all values are correct rather than remain with one where things are incorrect or a mish-mash in the long term. As I said to Akira, the alpha nature of OpenSim is meant to be a signal that these things can change as bugs are fixed. However, I'm certainly happy to hear alternative opinions or well-researched and intelligent alternative proposals. -- Justin Clark-Casey (justincc) http://justincc.org/blog http://twitter.com/justincc __**_ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/**mailman/listinfo/opensim-devhttps://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Supporting shell environment variables
There are both pros and cons to this: On the pro side, it gives one more way to set variable data into otherwise static files, easing synchronization of configurations. On the con side, the syntax is awkward as hell and it' useful to only a very small group of people (those who grok *nix) I think what clinches it is that nini has been dormant for so long that the risks in a fork are negligible. So, +1 Melanie On 23/11/2011 06:34, BlueWall wrote: Hi All, About a year ago, I was working on the Fortis-OpenSim project and had started digging into the configuration system a bit. One of the things I wanted to to was provide the means to interact with shell environment variables during the configuration. So, I studied the insides of Nini and added support for the environment variables in a way that lets it deal with the shell environment like already interacts with ini/xml/registry configuration media. I tried contacting the Nini author to ask if they would incorporate the changes into their distribution, but Nini development has been dormant for some time and I never got a response. A few days ago, I had a conversation in IRC about environment variable support and decided to look at putting it into OpenSim. And today I was able to use the modified Nini to get it working. I have done some testing here and it works well. I want to push this to core, but I wanted to discuss the forking of Nini. How does everyone feel about that? I think having the ability to manipulate shell variables is pretty good for us, and seeing that the Nini development has been dormant so long it shouldn't be as much of an issue. If development starts back up on it, then I'm pretty sure we could get the changes into the distributed version. Thanks! BlueWall PS: for reference - http://pastebin.com/f3R0sk5N ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Any way for the server to get the viewer to send some information to another process on the client PC?
You can send the Go to website dialog from a money module as well. Both the VirWox module and DTL currency do this. On 11/11/2011 11:55, Edmund Edgar wrote: On 11 November 2011 18:31, Melanie mela...@t-data.com wrote: The easiest way would be to make your bitcoin client open port 80 on your local host (or another port) for localhost use only. Then a script could send you to 127.0.0.1:/pay?to=---- or similar and you complete the transaction onn this locally served html page. Actually I wasn't really thinking there would be an LSL script involved at all - I was hoping for some kind of way for the money module to send a message. For example, Fumi Iseki's version of the money module code http://www.nsl.tuis.ac.jp/svn/opensim/opensim.currency/trunk/OpenSim.Forge.Currency/MoneyModule.cs ...has things like: remoteClient.SendAgentAlertMessage(Unable to buy now. You don't have sufficient funds, false); ...which presumably sends a message to the client, which the client displays to the user. In my dreams, I could do something like: remoteClient.SendArbitraryHTTPMessageToSomethingListeningOnLocalPort(9876,1234 BTC,1Q4uC95NvGSw3JrmFAcc4ZDRDNGZ2u3bFT); ...or maybe: remoteClient.WriteToLogWeMadeUpJustForThisPurpose(bitcoin_transaction_request.log,1234 BTC,1Q4uC95NvGSw3JrmFAcc4ZDRDNGZ2u3bFT); But maybe I could somehow create an LSL script and make the client run it... The GridProxy thing is an interesting thought - it occurs to me that I'd also need to pass BitCoin addresses from the BitCoin client to the server, and associate them with the logged-in avatar, and it could help with things in that direction too. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] WiFi Suggestion
The problem with that is that the vanilla Linden Viewer can be triggered to display the TOS dialog, but the URL it's fetched from is hardcoded to the LL servers. Therefore, although a grid may put out a viewer that has this check in it and fetches that grid's TOS, a user who uses a vanilla Linden viewer would be presented with, and agree to, the LL TOS. This is not legally binding for the user on the third party grid, therefore this isn't practicable. Melanie On 09/11/2011 20:21, Bo wrote: Hello, just an quick idea, SL does request TOS confirmation directly in the viewer after each change. Not sure, maybe someone would like to implement it into OS too? Thanks for reading, Bo On Wednesday 09 of November 2011 19:16:14 Jason Spriggs wrote: 1. Options to have a user agree to a TOS/EULA before they can register. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] The case for greater than 1024x1024 pixel textures.
You are disregarding a number of factors. First, OpenGL just doesn't seem to be capable of it. Second, OS content is created by amateurs who think bigger is better, as evidenced by existing creations. For social, SL-like grids, this certainly must remain disabled even if a way is found to implement it. Melanie On 07/11/2011 15:02, David Kaplan wrote: I whole-heartedly support this proposal in whatever the solution may be - regardless if it's an issue with the viewers or the server. I don't see that have larger textures will create appreciably significant performance issues because, much like web designers, people who are competent in building on OS are aware of bandwidth and optimization concerns when it comes file size. If they aren't, awareness will have be raised on this issue but I don't think a lack of awareness should impede creativity. OS has a lot of competing products out there (e.g., Unity, etc) and they all manage to do the job well while also allowing for robust textured graphics. I understand software like Unity is implemented differently but there is little reason why this issue should different. My two cent. On 11/7/2011 12:06 AM, Nebadon Izumi wrote: Lani This is a viewer issue and not really an OpenSimulator issue per say, it would be better taken up with the viewer devs, there are really no limitations on the server side for that limit the size of any texture, in fact the viewer also has no problem displaying larger textures, i have several 2048x2048 texture in SL, i believe they were uploaded with a special LibOMV client back in the day before LL closed some holes. Technically the only place that limits the size of the texture is when the viewer converts the image to a jp2 image before it sends it to OpenSimulator, if this can be modified then we could upload larger textures, though there may be some other good reasons we would not allow this, such as performance and such, the files could be quite large, and having to download lots of these large textures could really cripple things, we would need to do some tests to be sure, there may also be other difficulties involved for TPVs with the Terms of Service of secondlife and making such modifications to the viewers, this really needs to be taken up with the Viewer Developers to see what they think. On Sun, Nov 6, 2011 at 9:53 PM, Amy Smith amy88sm...@yahoo.com mailto:amy88sm...@yahoo.com wrote: This is part of an effort to increase the awareness in the developer community of a longstanding need among OpenSim content creators and designers of simulator environments, for higher resolution pixel textures (images greater than current 1024x1024 pixels) to be used in stand-alone and/or grid operation of sim regions using OpenSimulator. We are cartoons... The present limit of 1024x1024 pixels contributes to a cartoon-like or sub-optimum look and feel to OpenSimulator. If we are to make progress in 21st century 3D graphics, higher resolution imagery is needed. Is it in only in the Viewer? Some devs point to the viewer clients being coded to limit the image size at upload. Since OpenSimulator project has recently changed license and participation method, to provide increased interaction between viewer developers and simulator developers, perhaps there is a renewed possibility to solve this problem in the near future. Some TPV viewers have provided compatibility switches in the Grid Manager section for use with OpenSimulator. Is there a SIMULATOR or server-side solution? If the only limits are in the viewer UPLOAD, then perhaps a method of image insertion at the database level or in the simulator console could be provided for higher resolution textures. What should the limit be?It is estimated that increasing the limit to at least 4096 x 4096 pixels would suffice for most applications. But, for future expansion, it should be up to the designer, the sim operator, or the grid operator to set such limits (if any). The areas of design that suffer the most from current texture size limits (1024x1024 pixels) are: 1. AVATARS: Avatar skin and system clothing. (Currently: very blurry! ) 2. HUGE PRIMS: Large prim objects, such as buildings, environment/ space/ sky/ backdrops/ backgrounds, etc. 3. SCULPTY: Visible texture applied to surface of sculpted objects. 4. MESH: Visible texture applied to surface of mesh objects. 5. LAND: Teraform, land/ground RAWs, textures, and data maps. Reproduction of the current situation: 1. Upload a 4096x4096 image for use with avatar upper body UV wrapped texture for system avatar. 2. Observe after upload, that the image has been converted by down-sampling and poorly compressing to a resulting 1024x1024 texture
Re: [Opensim-dev] Avatar say / shout dont move with avatar that sits on moveing object.
I believe that fix made it in when I updated the SP to AVN code. We fixed that ages ago. Melanie On 08/11/2011 00:48, Justin Clark-Casey wrote: To me, this sounds like a bug to file on Mantis. However, I suspect that updating the listen position when a prim moves will take a bit of code fiddling. On 05/11/11 02:40, R. Gunther wrote: I found out that if you go sit with your avatar on a prim, that contains a listener it works fine. But when your avatar get out of chat range from the source location. it stops responding when the object gets to far away from source location. But the avatar is sitting on top of the listener. Have more seen this ? I need to dive more into it sometime. lets say avatar is starting at 10,10 then it moves on the object with listener to 100,100 the object still thinks your staying at 10,10. Richard. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Signal Handling
You should Mantis it and then maybe post the Mantis link here. I for one might be interested in signals processing, like proper SIGTERM and maybe SIGHUP. Melanie On 08/11/2011 00:31, Justin Clark-Casey wrote: Hi Rory. I think most people currently achieve this kind of thing via the RemoteAdmin interface [1]. However, I don't personally have any objection to having POSIX handling code in OpenSim if that's useful to people. The best place for such a thing could be a separate OpenSim.ApplicationPlugins.PosixController package (or similar) rather than mixing it in with OpenSim.cs. Things such as #if and #endif do exist in C# [2]. To be honest, I don't think you need to detect Windows as long as it does compile under Windows - one can include the mono.posix.dll in OpenSim directly if necessary. And some Windows environments (e.g. Cygwin) do provide POSIX handling so it might work there. If you want to submit a patch please create an account on Mantis [3] and post it there, putting it into the Patch included state. As I would classify this as a feature, we will need you to sign and submit a contributor's agreement [4]. Thanks. [1] http://opensimulator.org/wiki/RemoteAdmin [2] http://stackoverflow.com/questions/5159657/isolate-mono-specific-code [3] http://opensimulator.org/mantis. [4] http://opensimulator.org/wiki/Contributions_Policy On 07/11/11 15:50, Rory Slegtenhorst wrote: Dear List, My very first post in the dev mailing list, as I am going to spend much more time in my personal OpenSim. I have written some code quite a while back and wanted to share my thoughts and start a discussion about it. *Signal Handling* Currently, OpenSim services do NOT support POSIX signal handling when POSIX is available. This support is available on pretty much any *nix platform including MacOS X. Windows does NOT support POSIX period. In Mono, POSIX signal handling can be easily accomplished using the mono.posix.dll. I have currently implemented nothing more but the TERM signal, to ensure the services are properly stopped, instead of simply killed on the spot. This means that the service actually goes through the shutdown procedure (if any). The next goal would be to implement HUP to reload the service. My current problem, is that the code is just there. No ifdef statements, nothing. I simply lack the knowledge in .NET/Mono to exclude the code from an environment that does not include posix. Some pointers in the right direction would be much appreciated. *Discussion* When creating services, there must be an easy way to start/stop them. Especially on *nix this comes in handy. Shoving the word exit or shutdown into the service cli is just not working all the time and is error prone. Adding POSIX signal handling would be considered standard in such services. The fact that MS Windows does not support POSIX signals is simply disregarded. The equivalent on Windows would be to have a service binary that runs the OpenSim services (I think that already exists). There aren't that many other standard solutions to the same problem, and although signal handling wouldn't work on ONE platform (ONE being Windows), it is guaranteed to work on ALL others (ALL being the *nix ones lol). So to start the discussion, here are some questions: 1. Is there any interest in this code? With this I mean: would we want POSIX signal handling or will we try to develop a different way to solve the same problem? 2. If there is any interest, who do I send my patch to? With kind regards, Rory Slegtenhorst rory dot slegtenhorst at gmail dot com ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] I'd like to remove to the attempt at autopilot when a sit target is selected from a distance
As said in chat, +1 On 05/11/2011 02:38, Justin Clark-Casey wrote: Hi folks. I would like to remove the code which attempts to autopilot the avatar to a prim if it has no sit target and is more than a short distance away. This code is broken anyway (doesn't actually sit when it reaches the target) and it's not the behaviour you see on other grids. On the Linden grid, for instance, the avatar will warp to sit if = 10m away and ignore the request otherwise. This seems reasonable behaviour to me. Please let me know of any issues with this. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Remote admin, change region command missing ?
All remote admin functions that deal with a single region take a region UUID parameter. If you use admin_console_command, you need to send the change region command as you send any other commands. Melanie On 03/11/2011 02:19, R. Gunther wrote: I just wher ein chat. if you use a megaregion the say best to save every region seperate. its anyway good. Also for more regions in one instance. Only i have that scripted. And now i cant find any command at http://opensimulator.org/wiki/RemoteAdmin to change the region. SO you can save oar automatic. but you never can save every region seperate automatic. Is the command change region really missing in remoteadmin. if so how easy can that be added ? Greetings richard ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Script not working correctly in Opensim
Replace
params = (params=[]) + params + params;
with params += params;
Melanie
On 20/10/2011 10:09, Chris Collins wrote:
It does come up saying multiple assignments to params results may differ
between SL and OSSL when I save the script. Would anyone know of a work
around instead of using the param?
Chris
On Thu, Oct 20, 2011 at 12:48 AM, Chris Collins ch...@tipodean.com wrote:
only problem with that is that the grid that will get the script does not
allow OSfunctions. What is weird is that my script works in some cases.
On Thu, Oct 20, 2011 at 12:35 AM, Fritigern Gothly
fritigerngot...@gmail.com wrote:
Hmmm... Why not use osTeleportAgent?
http://opensimulator.org/wiki/OsTeleportAgent
On Thu, Oct 20, 2011 at 9:25 AM, Chris Collins ch...@tipodean.com
wrote:
I have the following script that is working within SL but does not
always
work in OpenSim. Sometimes it works other times it does not. Can anyone
see
anything that would be causing issues on Opensim
vector DEST = 130, 182, 36;
vector SITPOS = 0,0,0.5;
key gAv;
moveTo(vector origin, vector destination ) { // removed jumpdist
float dist = llVecDist(origin, destination);
integer passes = llCeil( llLog(dist/10.0) / llLog(2.0) );
integer i;
list params = [PRIM_POSITION, destination];
for (i=0; ipasses; i++) {
params = (params=[]) + params + params;
}
llSetPrimitiveParams(params);
}
teleport(key av) {
if (av == NULL_KEY)
{
return;
}
vector origin = llGetPos();
llSetAlpha (0.0, ALL_SIDES);
moveTo(origin, DEST);
// no need to sleep -- llSetPrimParams has 0.2s delay
llUnSit(av);
moveTo(DEST, origin);
llSetAlpha (1.0, ALL_SIDES);
}
default
{
state_entry()
{
llSetClickAction (CLICK_ACTION_SIT);
llSitTarget(SITPOS,llEuler2Rot(0,0,-90 * DEG_TO_RAD));
}
changed(integer changebits)
{
if (changebits CHANGED_LINK)
{
gAv = llAvatarOnSitTarget();
if (gAv != NULL_KEY)
{
teleport(gAv);
}
}
}
}
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
--
-- Friti
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
--
--
Chris Collins
CEO
Tipodean Technologies
+1 415-515-6928 | ch...@tipodean.com
Skype: cozza13 | SL: Chris Collins
Website: www.tipodean.com
Twitter: http://www.twitter.com/tipodean
http://www.linkedin.com/in/collinschris
http://www.builtbuy.me
Tools for your distributed workforce
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Continual object update resends if acks are missed
It may be that the update is sent with a new sequence number. The update resending should work by either removing the newer update from the queue entirely and resending the packet using the old sequence number until acked or just resend the packet as is, leaving the newer updates in the queue. The viewer might not like too many sequence numbers missed, it does spit warnings when packet sequence numbers are not ok. Melanie On 12/10/2011 07:43, Mic Bowman wrote: We should collect more information on what is actually happening. The old behavior was to resend infinitely (and very badly). It would send old updates even when there were new updates for the same object. We changed the resend to transmit the current data rather than old data. If there are still no acks coming back after some time then we need to figure out what the viewer is expecting when it no longer acks packets. There is a write up on the procedure in an old email message on this list. --mic On Tue, Oct 11, 2011 at 3:55 PM, Justin Clark-Casey jjusti...@googlemail.com wrote: Hi dslake (since this is chiefly addressed to you :) In commit b5ab33b5 back on Wednesday 20th April 2011, you made a change so that the resend of object updates or property updates is threaded back through Resend methods on LLClientView rather than the normal resend within UDPServer. The normal resend only performs the resend once, while going through the LLClientView.Resent*() methods will continually attempt the resend until acked as they put the requests back on the m_entityUpdates/m_entityProps queue. From my experience, often the client will not reack such packets. This means that they are continuously resent until the client logs out. I can see this happening by uncommenting the log lines in LLClientView.**ResendPrimUpdates() and ResentPropertyUpdates(). This is chiefly seen on remote regions (I can't repro on a localhost). What do you think? Can we resend such packets just once? Thanks, -- Justin Clark-Casey (justincc) http://justincc.org/blog http://twitter.com/justincc __**_ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/**mailman/listinfo/opensim-devhttps://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Continual object update resends if acks are missed
It appears this mechanism has already been removed for prim updates because intermediate updates are needed fro proper motion of physical prims, but was left in for property updates. However, culling of later updates as well as preservation of sequence numbers was not done. Melanie On 12/10/2011 07:43, Mic Bowman wrote: We should collect more information on what is actually happening. The old behavior was to resend infinitely (and very badly). It would send old updates even when there were new updates for the same object. We changed the resend to transmit the current data rather than old data. If there are still no acks coming back after some time then we need to figure out what the viewer is expecting when it no longer acks packets. There is a write up on the procedure in an old email message on this list. --mic On Tue, Oct 11, 2011 at 3:55 PM, Justin Clark-Casey jjusti...@googlemail.com wrote: Hi dslake (since this is chiefly addressed to you :) In commit b5ab33b5 back on Wednesday 20th April 2011, you made a change so that the resend of object updates or property updates is threaded back through Resend methods on LLClientView rather than the normal resend within UDPServer. The normal resend only performs the resend once, while going through the LLClientView.Resent*() methods will continually attempt the resend until acked as they put the requests back on the m_entityUpdates/m_entityProps queue. From my experience, often the client will not reack such packets. This means that they are continuously resent until the client logs out. I can see this happening by uncommenting the log lines in LLClientView.**ResendPrimUpdates() and ResentPropertyUpdates(). This is chiefly seen on remote regions (I can't repro on a localhost). What do you think? Can we resend such packets just once? Thanks, -- Justin Clark-Casey (justincc) http://justincc.org/blog http://twitter.com/justincc __**_ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/**mailman/listinfo/opensim-devhttps://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
