[Opensim-dev] Error detection when storing an asset
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
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-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
Re: [Opensim-dev] Error detection when storing an asset
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 -- Oren Hurvitz VP RD Kitely Ltd. Email: or...@kitely.com i...@kitely.com ___ 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
There are several popular open-source message queues that we could use. If we're going to do that then we need to have an open discussion about the pros and cons of the various packages in order to decide which one to use. In the past I've used JBoss Messaging, but that's been discontinued so it isn't relevant. A big decision will be whether to use a message queue that's completely embedded in OpenSim, or one that runs standalone. OK, I've already said too much; I'm hijacking my own thread... On Fri, Apr 18, 2014 at 10:13 PM, Mike Chase mike.ch...@alternatemetaverse.com wrote: Or RabbitMQ... Or even ZeroMQ if an external MQ service is deemed too heavy. Mike -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Shaun T. Erickson Sent: Friday, April 18, 2014 1:22 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Error detection when storing an asset There's also the free ActiveMQ. On 4/18/14, 11:23 AM, Melanie wrote: MQ Series, IBM's message queue service ___ 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 -- Oren Hurvitz VP RD Kitely Ltd. Email: or...@kitely.com i...@kitely.com ___ 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
I feel that we've transcended from this mortal coil into heavenly spheres. Such powerful realms require poetry to comprehend, so I must quote from the poem Eloisa to Abelard: How happy is the blameless vestal's lot! The world forgetting, by the world forgot. Eternal sunshine of the spotless mind! Each pray'r accepted, and each wish resign'd; To deny failure is to deny reality. On Sat, Apr 19, 2014 at 12:43 AM, Melanie mela...@t-data.com wrote: 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
Re: [Opensim-dev] REST handlers use partial string matching
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
Re: [Opensim-dev] Optimize pushing assets to other grids
I've added AssetsExist to master. It's implemented using REST, at /get_assets_exist. Regarding getting server capabilities: later I realized that Hypergrid already has the helo command, which serves this purpose. Currently it returns only one type of property: whether the server is based on Robust or Simian. But it would be trivial to allow it to return other properties and preferences as well. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579142.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] Viewer doesn't render attachments after teleport
I'm seeing strange behavior from viewers: after an avatar HG teleports to another grid, his attachments sometimes aren't visible to *some* of the avatars in the region. The isn't that the attachments have been detached: the log shows that they came across perfectly. And some of the avatars in the region *do* see the attachments, while some do not. For example, in Singularity, an avatar already in the region sees the incoming avatar's attachments, whereas the incoming avatar himself does not! In Firestorm the problem is the reverse: the incoming avatar does see his attachments, but the avatar already in the grid doesn't. Waiting doesn't solve the problem. But other actions sometimes do: * Most tellingly, sometimes merely changing the zoom level of the viewer (using the mousewheel) makes the attachments appear. No packets are sent to or from the viewer at this time (I checked). * If the avatar walks forward then sometimes one or more of the attachments appear. But strangely, walking backwards doesn't make them appear. I looked carefully at the packets being sent to see if anything is missing, or whether the packets differ between avatars that do see the attachments and those who don't, but I can't see a difference. And in any case, the fact that sometimes the attachments can appear even without any packets being sent (as in the mousewheel example) means that it's something to do with the viewer. I don't want to just say it's a viewer problem and move on, because it's a problem for users of OpenSim. My working assumption is that by sending additional packets, or at different times, we can make the viewer refresh itself and show the attachments. This would only need to happen shortly after a teleport. Does anyone know what we could do to force the viewer to redraw the attachments? I tried sending additional ObjectUpdate packets for the attachments, but this didn't help. Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143.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
Re: [Opensim-dev] Viewer doesn't render attachments after teleport
Here's another interesting finding: even when the attachments aren't visible, I can click on them to edit them. The viewer renders a yellow outline around the shape of the attachment (in Singularity), even while the area inside the outline still doesn't show the attachment. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Viewer-doesn-t-render-attachments-after-teleport-tp7579143p7579144.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
Re: [Opensim-dev] Viewer doesn't render attachments after teleport
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
Re: [Opensim-dev] Optimize pushing assets to other grids
I already implemented SimianAssetServiceConnector.AssetsExist(). But since I didn't change Simian itself, it works by simply calling GetMetadata() to check if each asset exists. You can either leave this as-is, or implement an explicit AssetsExist operation that checks all the assets at once, like I've done in Robust. On Wed, Apr 2, 2014 at 6:38 PM, Mic Bowman [via opensim-dev] ml-node+s2196679n7579156...@n2.nabble.com wrote: How is this hooked up in the simulator? I'll need to update the simian connectors. On Wed, Apr 2, 2014 at 12:11 AM, Oren Hurvitz [hidden email]http://user/SendEmail.jtp?type=nodenode=7579156i=0 wrote: I've added AssetsExist to master. It's implemented using REST, at /get_assets_exist. Regarding getting server capabilities: later I realized that Hypergrid already has the helo command, which serves this purpose. Currently it returns only one type of property: whether the server is based on Robust or Simian. But it would be trivial to allow it to return other properties and preferences as well. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579142.html Sent from the opensim-dev mailing list archive at Nabble.com. ___ Opensim-dev mailing list [hidden email] http://user/SendEmail.jtp?type=nodenode=7579156i=1 https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list [hidden email] http://user/SendEmail.jtp?type=nodenode=7579156i=2 https://lists.berlios.de/mailman/listinfo/opensim-dev -- If you reply to this email, your message will be added to the discussion below: http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579156.html To unsubscribe from Optimize pushing assets to other grids, click herehttp://opensim-dev.2196679.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=7579093code=b3JlbmhAa2l0ZWx5LmNvbXw3NTc5MDkzfDIwMTU3MTI0NTc= . NAMLhttp://opensim-dev.2196679.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- Oren Hurvitz VP RD Kitely Ltd. Email: or...@kitely.com i...@kitely.com -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579157.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
Re: [Opensim-dev] Optimize pushing assets to other grids
The actual work is done in the assets server, and there's code in the simulators to call this API. On Wed, Apr 2, 2014 at 10:28 PM, Nebadon Izumi [via opensim-dev] ml-node+s2196679n7579160...@n2.nabble.com wrote: excuse my ignorance here but are these changes directly to the asset server itself or are these simulator level changes? -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579162.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] REST handlers use partial string matching
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
Re: [Opensim-dev] REST handlers use partial string matching
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
Re: [Opensim-dev] REST handlers use partial string matching
The AssetsExist API is implemented efficiently in all levels of the stack including the database, where a single query checks all the assets. So a single HTTP request will be vastly more efficient than multiple calls, even if KeepAlive works. And I never trust KeepAlive anyway because I've used proxies that didn't enable KeepAlive by default (mod_ajp_proxy). -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579137.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
Re: [Opensim-dev] Optimize pushing assets to other grids
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
Re: [Opensim-dev] Optimize pushing assets to other grids
As this is an assets-service request, it belongs in the assets-service handlers. They already handle many different requests: data, metadata, data+metadata, store, update. Creating a new handler would be easier for me at this moment, but perhaps not best for OpenSim in the longer term. First, because this request is related to the other asset requests, it makes sense to handle them together. Second, adding a new handler for every new feature isn't good because it creates a lot of duplicate code. Third, being able to determine a server's capabilities is useful. There are many places in the codebase where new features were added using copy-paste-and-modify. This makes it harder to add new features, and especially hard to refactor major systems because so many places need to be changed in parallel. I would like to get away from that. Oren On Mon, Mar 31, 2014 at 3:51 PM, Melanie-2 [via opensim-dev] ml-node+s2196679n7579101...@n2.nabble.com wrote: 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 [hidden email]http://user/SendEmail.jtp?type=nodenode=7579101i=0 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 [hidden email] http://user/SendEmail.jtp?type=nodenode=7579101i=1 https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list [hidden email] http://user/SendEmail.jtp?type=nodenode=7579101i=2 https://lists.berlios.de/mailman/listinfo/opensim-dev -- If you reply to this email, your message will be added to the discussion below: http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579101.html To unsubscribe from Optimize pushing assets to other grids, click herehttp://opensim-dev.2196679.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=7579093code=b3JlbmhAa2l0ZWx5LmNvbXw3NTc5MDkzfDIwMTU3MTI0NTc= . NAMLhttp://opensim-dev.2196679.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace
Re: [Opensim-dev] Optimize pushing assets to other grids
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
Re: [Opensim-dev] Optimize pushing assets to other grids
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] Optimize pushing assets to other grids
I want to improve how assets are transferred between grids in the Hypergrid. Currently there are two ways this is done: push and pull. In both cases, HGUuidGatherer is used to find all the assets that are embedded in the top-level asset. The Pull operation is efficient because it won't load from the remote grid an asset that already exists in the local grid. But the Push operation is inefficient because it doesn't know which assets the remote grid has, so it has to send all the assets (full data), and it never remembers which assets the remote grid already has. In order to improve this, I'm thinking of adding a Hypergrid method that will let the local grid know which assets the remote grid already has, so it won't have to send them again. Something like this: bool[] AssetExists(string[] uuid); Thoughts? Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093.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
Re: [Opensim-dev] Optimize pushing assets to other grids
It's already possible to know which assets are on the server by performing GETs, so this method doesn't change the security situation. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579096.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
Re: [Opensim-dev] Stop saving SculptData in serialized SceneObjects
I ended up just removing 'SculptData' from the XML format: http://opensimulator.org/mantis/view.php?id=7038#c25621 -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Stop-saving-SculptData-in-serialized-SceneObjects-tp7579079p7579092.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] Stop saving SculptData in serialized SceneObjects
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
Re: [Opensim-dev] Stop saving SculptData in serialized SceneObjects
The mesh/texture data is needed only if the prim is resized or otherwise edited as you've described. But in the vast majority of cases, prims are just viewed. We should optimize for the common case, i.e. release the memory. If the asset is needed again it will be loaded from the cache, which is very fast (not a network operation). -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Stop-saving-SculptData-in-serialized-SceneObjects-tp7579079p7579087.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
Re: [Opensim-dev] Prebuild versioning
As you've said, I followed the existing practice, which was to increase the version number locally. We've been using a locally-versioned Prebuild for a long time. There's no harm in changing the versioning practice next time, although I don't know if adding a textual string will work. BTW I tried to submit these patches to the main Prebuild project as well, to zero response. I looked around that site and it's as dead as a parrot. We're on our own. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Prebuild-versioning-tp7579054p7579057.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
Re: [Opensim-dev] Changes to OpenSim.log, etc, log config
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
Re: [Opensim-dev] How many sides does a tapered torus have?
Yikes! How can I know these things in order to fix GetNumberOfSides()? If shape.pathTaperX0 or shape.pathTaperY0 then +1 side? But I think this doesn't actually happen unless Radius is also 0. I really don't understand how these parameters interact. Maybe we should just drop GetNumberOfSides() altogether. Every place that currently uses this function should simply check all 32 possible sides, and Bob's your uncle. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/How-many-sides-does-a-tapered-torus-have-tp7579043p7579059.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
Re: [Opensim-dev] Detaching mesh objects causes the region set send full asset data -- including geometry -- to the asset server
This should have gone in the Mantis, so that we can keep track of the status of this bug. I tested this scenario and the asset data wasn't sent. See my comment in http://opensimulator.org/mantis/view.php?id=7038 . -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Having-struggled-with-the-privs-inherited-from-SL-I-wish-to-object-tp7579045p7579063.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
Re: [Opensim-dev] Changes to OpenSim.log, etc, log config
I included a comment in the config files (e.g., OpenSim.exe.config) that shows how to enable log-rolling. Just modify a few lines in the file. It would be a lot of work to implement this as an option in OpenSim because it would require using the log4net API to change how it works at runtime. It's not impossible, but I'm not going to attempt it. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Changes-to-OpenSim-log-etc-log-config-tp7579053p7579066.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
Re: [Opensim-dev] Prebuild versioning
I'm a bit confused by your question because my patches are *already* in the OpenSim Git, so I don't know what you mean by Would it make sense to merge these [changes]. Merge them with what? Anyhoo, if you're up to resurrecting Prebuild in Github then more power to you! My patches to Prebuild are, of course, open-source and free to use. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Prebuild-versioning-tp7579054p7579073.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] New OpenSim debugging aids
I added to Git master a couple of features that help in debugging OpenSim. First, I improved logging of HTTP activity significantly. This isn't a new feature, but there are numerous changes which make it more useful. These include: logging responses (not just requests); fixed cases where logging failed; better snippets; and more. See http://opensimulator.org/mantis/view.php?id=6949 for more information. If you turn on debug http all 5 on either OpenSim or Robust (or both) then you'll get a very good idea of the communications between them. Second, I added logging of activity in the main thread pool. This helps show what OpenSim is doing. It can also help see if OpenSim is overloaded, because in that case the number of threads active in the threadpool will be high, and the number of queued threads will never drop to 0. You can also see how long it takes between the time that a task is queued until it actually executes. For more information about this feature see: http://opensimulator.org/wiki/General-Purpose_Threadpool . -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/New-OpenSim-debugging-aids-tp7579042.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] How many sides does a tapered torus have?
I found a bug in OpenSim: it doesn't count correctly the number of sides in a Torus if the torus uses tapering. How to reproduce the problem: 1. Create a torus, and set TaperY=0.85 and Radius=0.7. 2. Change the prim's texture. The texture will change momentarily and immediately revert to the default texture. The function that contains the problem is SceneObjectPart.GetNumberOfSides(). It thinks that this prim has 1 face, but actually there are at least 2 faces. I'm not sure how to fix this because I don't know what is considered a side. Can someone who understands shapes in SL/OpenSim help out? Perhaps whoever wrote this function originally? The bug is described here: http://opensimulator.org/mantis/view.php?id=7059 Thanks! -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/How-many-sides-does-a-tapered-torus-have-tp7579043.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
Re: [Opensim-dev] Proposal: notify clients when Robust changes a user's inventory
Implemented in Git master df9845a2. The Suitcase is now created automatically when the user logs-in. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Proposal-notify-clients-when-Robust-changes-a-user-s-inventory-tp7579018p7579041.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
Re: [Opensim-dev] Proposal: notify clients when Robust changes a user's inventory
Zadark, you make a good point! Users need the My Suitcase folder available to them if they want to take anything when they travel to another grid. So it's better to create it in advance rather than on-demand (as today). Since this is obviously a Good Thing (tm), I'm going to implement it. I just need to find where... (Do I hear any objections?) This doesn't solve other cases where Robust might create inventory folders/items on its own, but it solves the immediate use-case, and it's much simpler as well. Zadark, for your service to OpenSim I award you the Gordian Knot medal and a collection of slightly used Louis Vuitton suitcases. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Proposal-notify-clients-when-Robust-changes-a-user-s-inventory-tp7579018p7579031.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] Proposal: notify clients when Robust changes a user's inventory
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
Re: [Opensim-dev] Proposal: notify clients when Robust changes a user's inventory
Yes, this would be stateless. If the user's client can't be found then the message would be dropped. The logic to find the user's client, especially in the presence of HG, is very complicated. I wouldn't want to replicate it, and of course we wouldn't want duplicate code. There are only two choices that don't involve code duplication: use IM as the transport for this message, or a big rewrite that would create a generic locate+transport communications system, and then run both IM and the new API over that communications system. Option #2 is an order of magnitude more complex than Option #1, and tbh I don't have the time to implement it. I can do Option #1 in such a way that it would be almost like a generic mechanism; so this change would only need to be done once, not over and over for each future message we may want to pass. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Proposal-notify-clients-when-Robust-changes-a-user-s-inventory-tp7579018p7579027.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
Re: [Opensim-dev] How to find a user's UUID on another grid?
Thanks, just what I was looking for! I notice that IUserAgentService has a comment, HG1.5 only. I assume that means HG1.5 or higher, i.e. that it will work with HG 2.0 as well, right? -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/How-to-find-a-user-s-UUID-on-another-grid-tp7578941p7578943.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] How to find a user's UUID on another grid?
Is there a way to find a user's UUID on another grid, using their name? I'm looking for a Hypergrid version of IUserAccountService.GetUserAccount(): UserAccount GetUserAccount(string serverURL, UUID scopeID, string FirstName, string LastName); OSGrid has a web service that does this, called Name2key: http://wiki.osgrid.org/index.php/Name2key. But I couldn't find an official API, that would work on all Hypergrid grids. Thanks, Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/How-to-find-a-user-s-UUID-on-another-grid-tp7578941.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] Fixing Unknown User problems using the database
I started using Hypergrid recently, and came across the Unknown User problem. So far I've seen UserUMMAU4 and UserUMMTGUN9. I poked around to see if I can do anything about this, and it seems that the mapping of UUID - Name is stored in memory only (UserManagementModule.m_UserCache). This has the following consequences: 1. Simulators don't share what they know. 2. When a simulator is restarted, it forgets even those bindings that it did know before. The simulators do attempt to rebuild their cache on startup, by examining all the prims in the scene. But this is insufficient. E.g., inventory items also have creators. I think we should create a table in Robust, similar to UserAccounts (or perhaps in UserAccounts itself), which stores these name mappings. Simulators would use this table as a fallback if they don't find a mapping in their own cache. This will solve all (or at least most) of the Unknown User problems. What do you think? Am I missing something? Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Fixing-Unknown-User-problems-using-the-database-tp7578750.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
Re: [Opensim-dev] Fixing Unknown User problems using the database
Maybe we should go a step further: create a global shared user directory. This would eliminate 100% of Unknown User problems, and would also allow IM to work regardless of which grids/simulators the users are on. The shared directory could be implemented without a central service, by having Robusts talk to each other to exchange information. OK, I might be getting carried away here... This is obviously a lot more work than just a single database table in Robust. But it's something we'll probably want eventually in order to improve the user experience of the Hypergrid. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Fixing-Unknown-User-problems-using-the-database-tp7578750p7578751.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
Re: [Opensim-dev] Fixing Unknown User problems using the database
Regarding GUN9: the viewer actually showed just (waiting), and when I debugged this I saw that the name that was chosen was GUN9 but there was code that prevented sending this to the viewer. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Fixing-Unknown-User-problems-using-the-database-tp7578750p7578757.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
Re: [Opensim-dev] Sending extra prim properties to clients
That's ok. The amount of code I have written in my life which I had to throw away would be enough to run the space shuttle. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Sending-extra-prim-properties-to-clients-tp7578537p7578539.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
Re: [Opensim-dev] Setting a single child prim to Phantom
To anyone who's following this thread: Melanie contributed code that allows setting a prim's Physics Shape Type to None, which has a similar effect to making it phantom. Therefore, it's no longer necessary to make single prims phantom. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Setting-a-single-child-prim-to-Phantom-tp7578513p7578529.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
Re: [Opensim-dev] Dynamic attributes
I used XML serialization because it preserves more type information than JSON. For example, XML serialization preserves the OSD types 'url' and 'uuid' whereas JSON serialization changes them into 'string'. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Dynamic-attributes-tp7578464p7578536.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] Sending extra prim properties to clients
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
Re: [Opensim-dev] How does the viewer know the user's maturity rating
Did you say that you CAN change that flag in the viewer? How? I tested on my own region, and although I can change the REGION's maturity level, I can't change the avatar's maturity level in the Avatar Preferences dialog. Which viewer are you using? Also: could you include links to the places where you reported this bug? I would be very interested to see what the responses were. Thanks, Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/How-does-the-viewer-know-the-user-s-maturity-rating-tp7578517p7578521.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
Re: [Opensim-dev] How does the viewer know the user's maturity rating
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
Re: [Opensim-dev] How does the viewer know the user's maturity rating
Ah, I see it. Thanks! -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/How-does-the-viewer-know-the-user-s-maturity-rating-tp7578517p7578526.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
Re: [Opensim-dev] Setting a single child prim to Phantom
I just tried this and it doesn't work. I can set a prim's Physics Shape Type to None, but it still collides. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Setting-a-single-child-prim-to-Phantom-tp7578513p7578515.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] How does the viewer know the user's maturity rating
Hi, It looks like OpenSim doesn't tell the viewer which maturity ratings a user is allowed to use. I'm using the latest Firestorm, and in the Avatar Preferences dialog I try to change the value of the listbox I want to access content rated from General to Moderate or Adult, but Firestorm says that I'm not allowed. So the viewer thinks my user is only allowed to access General content. I searched, but I couldn't find how the viewer is told the user's maturity rating. Does anyone know? Is it a UDP packet that we haven't implemented yet, or an HTTP request to Second Life? If the latter then we'll need to ask Armin Weatherwax to allow that request to be redirected to an arbitrary URL so that we can handle it in OpenSim. The problem with having the user stuck on General maturity level is that sounds that originate in a region with Moderate or Adult maturity rating aren't played. (They did play in Imprudence, but they don't play in new viewers.) Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/How-does-the-viewer-know-the-user-s-maturity-rating-tp7578517.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] Setting a single child prim to Phantom
I have recently become aware that there's an entire cottage industry of scripts whose purpose is to make a single prim in a linkset phantom. These scripts are needed because: a) Usually the phantom flag is set for an entire linkset, so it's necessary to use a script to change the flag for a single prim b) The LSL functions that change the Phantom flag (llSetStatus() and llSetPrimitiveParams()) change it for the entire linkset at once, so they can't be used to change a single prim. These scripts use a very complicated workaround that involve changing the prim's shape in several steps, which is brittle and dangerous. You can see the scripts here: http://wiki.secondlife.com/wiki/Phantom_Child In Second Life there is now a simpler and safer way to make a single prim stop colliding: llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_NONE]); However, this isn't implemented in OpenSim. And I don't know if it's exactly equivalent to making the prim phantom. I propose extending llSetStatus() to allow setting the phantom flag for a single prim. This involves adding the flag OS_STATUS_PHANTOM_PRIM. It works just like the existing flag STATUS_PHANTOM, but it operates on the prim that contains the script instead of the entire linkset. This behavior mirrors the way llSetStatus() works with the STATUS_BLOCK_GRAB flag: it also comes in two flavors, STATUS_BLOCK_GRAB (for a prim) and STATUS_BLOCK_GRAB_OBJECT (for the linkset). Any thoughts? Does anyone know of a different way to safely change the phantom flag for a single prim in a linkset? Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Setting-a-single-child-prim-to-Phantom-tp7578513.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
Re: [Opensim-dev] Dynamic attributes
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. Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Dynamic-attributes-tp7578464p7578470.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
Re: [Opensim-dev] Dynamic attributes
I have submitted the patch: http://opensimulator.org/mantis/view.php?id=6510 Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Dynamic-attributes-tp7578464p7578467.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] Dynamic attributes
In the interest of clarity I'm starting a new thread for this topic. Previous discussion can be found here: http://opensim-dev.2196679.n2.nabble.com/IRegisterInterface-for-extending-scene-entities-td7578406.html Justin, the dynamic attributes branch allows storing attributes both in Prims and in PrimShapes. Is there a reason for this? It would be simpler to store attributes only in the prim. Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Dynamic-attributes-tp7578464.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
Re: [Opensim-dev] IRegisterInterface for extending scene entities
Sorry, I've been busy with other things so I haven't had a chance to continue with the attributes, but I will get to them in a few days. I'm fine with mandating that all clients must store their data in an OSDMap: this is similar to requiring that programs have their own folder in the filesystem, or their own branch in the Windows registry. I'm definitely in favor the names being human-readable. I will write an update about this after I get into the code, next week. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/IRegisterInterface-for-extending-scene-entities-tp7578406p7578463.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
Re: [Opensim-dev] IRegisterInterface for extending scene entities
The typing problem is already solved since the dynamic attributes are implemented using OSD. Your proposal is much more complicated than the currently proposed attributes, and I don't want to suppress a good solution in favor of a perfect solution that might never be implemented (I assume you're too busy with BulletSim to do this...) Furthermore, it would prevent a very exciting use-case: the ability to use dynamic attributes from a script, using OSSL. (Well, unless you add a module for that specific purpose, but in that case you just added a layer of indirection around the key-value store.) Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/IRegisterInterface-for-extending-scene-entities-tp7578406p7578425.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
Re: [Opensim-dev] IRegisterInterface for extending scene entities
For namespacing we can take a pointer from MIME types: 1. Keys used by core OpenSim will have no prefix, e.g. media or prop.attr. 2. Keys created outside core OpenSim will use the vnd. prefix, followed by the name of the creating entity. For example: vnd.acme.myprop. We should stick to storing the data in a single field. Database access is much slower than in-memory string manipulation, so for any reasonable amount of data it would be faster to read and write it as part of the existing prims table rather than adding additional SQL operations on another table (primattr?). And of course, a separate table would be much more complicated to handle and I do like the simple life :) I did consider a different change: replacing OSD with JSON, which I like because of its simplicity and ubiquity. But I decided that it wouldn't make much of a difference; certainly not worth rewriting working code. Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/IRegisterInterface-for-extending-scene-entities-tp7578406p7578423.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
Re: [Opensim-dev] IRegisterInterface for extending scene entities
I just looked at the dynamic-attributes branch and it looks extremely useful! I was just now considering ways to attach data to scene objects, and this would fit the bill exactly. So I'd like to bring the dynamic attributes code over to the master branch (updating it as needed), plus add serialization into the XML, XML2 and OAR formats. Since it's been 2 years since that code was written, are there any caveats I should be aware of before I begin? Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/IRegisterInterface-for-extending-scene-entities-tp7578406p7578417.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
Re: [Opensim-dev] Multi-region OAR format
On Fri, Jul 20, 2012 at 4:15 PM, Robert L martin [via opensim-dev] ml-node+s2196679n7578165...@n2.nabble.com wrote: okay so if i wanted to make an OAR for Bad Wolf Island with a total of nine regions it would have row 1 (south) Southwest, South center , South East row 2 (center) West Center, Center, East Center row 3 (north) NorthWest , North Center, North east and if i wanted to have a 2X4 region then it would be row 1 (south) South West , South Center West, South Center East , South East row 2 (north) North West, North Center West, North Center East, North East and any region without data will create a hole in the sim That's right. if the server can be made to handle it i would suggest that a dummy manifest be used to create blank regions (modes would be fixed height, Blend or random) If I understand you correctly, you're asking for the load-oar command to create regions where none existed before. It doesn't do that currently, and I don't intend to make it start doing so. There are other ways to create regions (see Regions.ini), and I don't intend to add to them as that's a different feature. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Multi-region-OAR-format-tp7578162p7578166.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
Re: [Opensim-dev] Multi-region OAR format
There are two big advantages. First, sometimes a group of regions comprises a logical, indivisible unit. E.g., RPG groups often create their world using many regions. Saving and loading their data in a single file is far more convenient than having to load each OAR separately. This is my motivation for this feature. The second advantage is that this way we don't have to duplicate the assets in each region, which would lead to massive waste in storage and load/save time. On Fri, Jul 20, 2012 at 6:11 PM, Adams, Robert [via opensim-dev] ml-node+s2196679n7578167...@n2.nabble.com wrote: I’m not sure I see the advantage of multiple regions in one oar file. Say I have a 3x3 set of regions saved in a backup oar file. I might want to restore one. That necessitates new command line parameters for selection, etc. ** ** To handle multiple regions, another approach is to push the grouping up a level and add commands for loading and creating multiple oar files with one command. That keeps the existing oar file format but solve the grouping feature. Or how about if the target of a ‘load oar’ is a directory, it loads all of the oar files therein? ** ** -- ra -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Multi-region-OAR-format-tp7578162p7578169.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
Re: [Opensim-dev] Multi-region OAR format
I suppose some people will find this useful, but it's not something that is required for multi-region OARs so I won't implement it. Of course, you're welcome to add this feature yourself :) On Fri, Jul 20, 2012 at 6:40 PM, Robert L martin [via opensim-dev] ml-node+s2196679n7578168...@n2.nabble.com wrote: On Fri, Jul 20, 2012 at 9:38 AM, Oren Hurvitz [hidden email]http://user/SendEmail.jtp?type=nodenode=7578168i=0 wrote: If I understand you correctly, you're asking for the load-oar command to create regions where none existed before. It doesn't do that currently, and I don't intend to make it start doing so. There are other ways to create regions (see Regions.ini), and I don't intend to add to them as that's a different feature. Not create a region where there isn't one but create the CONTENTS (in this case just the Land part) of a region so for BWI if the Center sim does not have any assets you could put a dummy/keyword in that says Blend the land to its surroundings or Fill the land to 22 meters or create a random heightmap instead of needing to create a whole section just to rig this -- Robert L Martin ___ Opensim-dev mailing list [hidden email] http://user/SendEmail.jtp?type=nodenode=7578168i=1 https://lists.berlios.de/mailman/listinfo/opensim-dev -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Multi-region-OAR-format-tp7578162p7578170.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
Re: [Opensim-dev] Multi-region OAR format
That's an interesting idea. I'm wondering whether this would be slower, however, since OpenSim would have to untar all the data twice: once in the outer OAR, and again in the inner OARs. It might also take twice the RAM, depending on how the untar library works. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Multi-region-OAR-format-tp7578162p7578172.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] Multi-region OAR format
I want to extend the OAR format to support multiple regions. That's a significant change, so I'd like to get some feedback about the design before diving in. A multi-region OAR will store each region in its own subdirectory. Only the assets will remain in a top-level directory, to avoid storing multiple copies of the assets. I.e: my_oar/ assets/ - (all the assets) region1/ settings/ - region1.xml objects/ - (objects from region1) region2/ settings/ - region2.xml objects/ - (objects from region2) etc. The file archive.xml will get a table of contents that lists the included regions and their spatial relationship. Regions are listed first by row (South to North), and within each row regions are listed West-to-East: regions rowregionnameregion1/name/region regionnameregion2/name/region/row rowregionnameregion3/name/region regionnameregion4/name/region/row /regions The load-oar and save-oar commands will be extended as follows: save-oar - add a parameter called -all. If true then save all the regions in the simulator into a single OAR. If false or missing then save only the current region (as today). load-oar - when loading a multi-region OAR, load each region into the corresponding region in the simulator If the OAR contains only one region then we'll skip creating a subdirectory for the region, and won't include the regions element in archive.xml. This means all existing OARs will be compatible with the new format. Any thoughts? Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Multi-region-OAR-format-tp7578162.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
Re: [Opensim-dev] Multi-region OAR format
The table of contents in archive.xml defines the spatial relationship of the regions. It can represent any rectangular shape. Holes are represented by an empty region/ element. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Multi-region-OAR-format-tp7578162p7578164.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
Re: [Opensim-dev] Avatar sinking into the terrain
Thanks for this reply. It's sure something to think about, but I'm still hoping for a solution that doesn't require debugging ODE itself. Perhaps BulletSim will be the, um, silver bullet... -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Avatar-sinking-into-the-terrain-tp7578143p7578161.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] Avatar sinking into the terrain
Hi, I want to bring up again the problem of avatars sinking into the terrain. This problem has been discussed since at least 2008. Here are some previous bug reports: http://opensimulator.org/mantis/view.php?id=2905 (starts as another problem, but morphs into the terrain problem) http://opensimulator.org/mantis/view.php?id=2717 http://opensimulator.org/mantis/view.php?id=4184 I fiddled with various ODE settings as suggested in these bug reports, but there wasn't much improvement. Increasing av_capsule_radius helps a little, but then avatars have other problems (e.g., can't walk through doorways) so it's not a good solution. Increasing av_capsule_standup_tensor helps reduce the frequency of having the avatar's legs fold, but the avatar still sinks into the terrain; just with straight legs. I also switched to Bullet physics as a sanity check, and the problem disappeared, but Bullet isn't yet ready to replace ODE. Is there any update about this problem? Any known workarounds? I can always get out of the terrain simply by walking, but preferably this problem won't happen in the first place. Thanks, Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Avatar-sinking-into-the-terrain-tp7578143.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
Re: [Opensim-dev] Some features work only with the Active group
My initial post in this thread was mistaken: OpenSim *does* allow group features even if the user is just a member of the group (but it's not the active group). The only problem is that getAgentGroupMembership() has a bug if the user has never set *any* group as his active group. So that's what I'm going to fix. I don't know if that's how SecondLife behaves, but I feel strongly that it's how it should behave, and anyway it's how OpenSim works. The only thing the Active group should affect is the tag that is displayed above the user in the viewer. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Some-features-work-only-with-the-Active-group-tp7512633p7516011.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
Re: [Opensim-dev] Some features work only with the Active group
I'm not changing the behavior of groups. I'm only going to fix one function in XmlRpcGroups, which isn't working correctly in an edge case. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Some-features-work-only-with-the-Active-group-tp7512633p7516110.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] Some features work only with the Active group
Hi, A user can belong to many groups, but only one of these groups can be active. Some group features, such as Notices, work with all the members of the group. But other features, such as rezzing on group-owned land, are only permitted if the user activates that group. I was wondering: why is this? Can this restriction be changed? It's likely to cause confusion and frustration. (See for example http://community.secondlife.com/t5/Land/group-cannot-rez-objects/qaq-p/932807) I noticed that Snoopy Pfeffer committed a patch that removes this requirement when checking access to parcels (c68427d from Apr. 5 2012), but then reverted it. Snoopy, can you explain why? Thanks! -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Some-features-work-only-with-the-Active-group-tp7512633.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
Re: [Opensim-dev] Some features work only with the Active group
I'm using Flotsam's XmlRpcGroups. In xmlrpc.php, I see that getAgentGroupMembership() only returns True if the queried group is the user's active group. I think this is a mistake: if we change it to return True for any group membership, many features would start working as expected. That would require no changes to OpenSim itself. The reason getAgentGroupMembership() only works for the active group is that it uses JOIN osagent. In contrast, getAgentGroupMemberships() (notice the s at the end) uses LEFT JOIN osagent, so it returns *all* the groups. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Some-features-work-only-with-the-Active-group-tp7512633p7512748.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
Re: [Opensim-dev] Some features work only with the Active group
The situation is better than I thought. The problem only happens if a user has never set an active group, because in that case the user doesn't have an entry in the osagent table. If the user did set an active group, no matter what it is, then group features work as expected (i.e., the user doesn't have to make that group the active group). Fixing this bug seems simple, at least in Flotsam's XmlRpcGroups. In xmlrpc.php, getAgentGroupMembership() uses JOIN osagent but it should use LEFT JOIN osagent. That's what getAgentGroupMemberships() does. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Some-features-work-only-with-the-Active-group-tp7512633p7512819.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] Remove check for IsGod in some OSSL functions
Hi, There are 3 OSSL functions that only work if the requester is a God: * osSetRegionWaterHeight * osSetRegionSunSettings * osSetEstateSunSettings I believe these checks should be removed, since estate managers should be able to call these functions. OpenSim now allows specifying that only estate managers can call some functions, so there's no reason to place these permission checks in code. In addition, these functions should probably be changed from thread level Nuisance to High (the same as osSetTerrainHeight). By the way: PermissionsModule has two methods, IsGod() and IsAdministrator(), that are effectively identical because IsGod() calls IsAdministrator(). So why do we use two different terms for the same user level? Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Remove-check-for-IsGod-in-some-OSSL-functions-tp7462127p7462127.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] Fix OSSL threat level checks
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
Re: [Opensim-dev] Remove check for IsGod in some OSSL functions
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] Change parcel permission handling
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
Re: [Opensim-dev] Remove check for IsGod in some OSSL functions
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
Re: [Opensim-dev] Change parcel permission handling
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
Re: [Opensim-dev] Remove check for IsGod in some OSSL functions
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
Re: [Opensim-dev] Change parcel permission handling
I thought that estate managers do have full permissions over all of their parcels. After all, they can choose who *gets* the parcels. The solution you suggested already exists: it is possible to specify multiple permissions for OSSL functions. So that's off the table. It's still confusing to have two sets of permission checks: one in OpenSim.ini, and another one in code (where it's pretty much secret unless you're a developer). But I'm going to let sleeping dogs lie. So for these functions (osSetParcelDetails, osSetParcelMediaURL, osSetParcelSIPAddress) OpenSim.ini should be configured to allow anyone to call these functions, and we'll trust the code in OSS_Api.cs to perform the real permission check. Oren On Fri, Apr 13, 2012 at 4:02 PM, Melanie-2 [via opensim-dev] ml-node+s2196679n746260...@n2.nabble.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 -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Remove-check-for-IsGod-in-some-OSSL-functions-tp7462127p7462720.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
Re: [Opensim-dev] Walk animation doesn't stop
I found the problem. The walking script is notified whenever the user presses or releases a movement key, e.g. the Forward key. When that happens, the script checks which movement animation the avatar is currently using, and starts or stops the custom animation according to whether the movement animation is WALK or not. There were several problems with this: 1. In ScenePresence, when the client moves, the control notification was sent to the scripts before the avatar's animation had been updated, so the walking script was using the wrong animation to make its decisions. Now the scripts are notified only after the animation has been updated. 2. Sometimes multiple threads were trying to update the avatar's movement animation at once, again causing the script to see the wrong animation. I added a lock to prevent threads from interfering with each other. 3. When choosing the avatar's movement animation, if the avatar stopped walking while it was falling (even if the fall was really just a tiny bump in the ground) then the avatar animation remained on WALK. I changed it to set the animation to STAND in this case. (It would have changed to STAND soon anyway, but that delay caused the walking script to fail.) Note that this only affects the beginning of a fall; if the fall takes a long time then the avatar switches to the FALLING animation, and I didn't change that. The situation is much improved now: I haven't been able to cause the walking animation bug to happen anymore (although it's possible that there are other cases I haven't hit upon). I will submit this patch after I finish updating our system to OpenSim 0.7.3. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Walk-animation-doesn-t-stop-tp7453403p7459646.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] Walk animation doesn't stop
Hi, My avatar has a walk animation. When I use an arrow key to walk, and then release the key, the avatar stays put but the walk animation remains active. If I press the up or down arrow keys then the animation stops. I'm using OpenSim 0.7.3-post-fixes. This didn't happen in OpenSim 0.7.2. If I remove the walk animation then the problem disappears (i.e., the default walk animation does stop when the avatar stops). Does anyone have any idea how to fix this? ScenePresenceAnimator seems to be where this is happening, but I'm not clear where. Or is it in ScenePresence itself? Thanks, Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Walk-animation-doesn-t-stop-tp7453403p7453403.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
Re: [Opensim-dev] HTTP Server source code
Hi Diva, Any updates on the source code for HttpServer? If you don't have time to add it to Subversion or Git then could you zip up whatever you have and post it here? I would like to update my copies of OpenSim in order to incorporate my bugfix (the one from the beginning of this thread), but I want to include all of your fixes as well. Thanks, Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/HTTP-Server-source-code-tp6883843p6910711.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
Re: [Opensim-dev] HTTP Server source code
Justin, I saw the Mono patch, but indeed it's for a different problem. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/HTTP-Server-source-code-tp6883843p6887768.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] HTTP Server source code
Hi, Where is the source code for the HTTP Server used by OpenSim? All I can find is the binary version, HttpServer_OpenSim.dll. I believe I found a bug in this library and I would like to fix it. Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/HTTP-Server-source-code-tp6883843p6883843.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
Re: [Opensim-dev] HTTP Server source code
Is it this one? - http://webserver.codeplex.com/ If so then it seems the version we're using in OpenSim is very old. The part that contains my bug has been completely rewritten. How about I try to update the library to the current version? -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/HTTP-Server-source-code-tp6883843p6883850.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
Re: [Opensim-dev] HTTP Server source code
Hmm, what a sordid history this library has... I checked out the latest version from Subversion (thanks Nebadon) and applied my fix. It seems to work fine. The change is very simple: there's a certain uncaught exception that causes OpenSim/Robust to terminate. I just added a catch-all statement. This change should fix the following bugs: http://opensimulator.org/mantis/view.php?id=5471 http://opensimulator.org/mantis/view.php?id=5694 http://opensimulator.org/mantis/view.php?id=5718 Diva, I was able to checkout from Subversion and compile without any problems. However, since you have changes on your machine that haven't been pushed to Subversion it means that the DLL that I created isn't up to date. Could you apply this patch to your local copy of HttpServer and push the new DLL to Git? Thanks! http://opensim-dev.2196679.n2.nabble.com/file/n6885669/Catch-all-exceptions.patch Catch-all-exceptions.patch -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/HTTP-Server-source-code-tp6883843p6885669.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
Re: [Opensim-dev] HTTP Server source code
Alternatively, zip up the HttpServer directory and send it to me; I'll recompile and update the DLL myself. If someone could give me write access to this Subversion repository I can try to update it, too -- perhaps I'll have better luck in this, since I had no problems performing a checkout. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/HTTP-Server-source-code-tp6883843p6885715.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
Re: [Opensim-dev] Updating attachment assets
I'm actually adding deduplication right now, although we store the assets in our cloud infrastructure and not on disk. My motivation for this thread was the problem I've seen with attachments. All of our avatars (on Kitely) have an attachment with a Walk script. I've seen that often when viewers login they detach and then reattach the attachments. This causes a new copy of the Walk attachment to be created each time. I wanted to delete these unneeded copies, and I thought that this could be done easily, but it turns out that doing it safely is a lot of work. So I'm dropping this; the amount of data taken by these scripts is small compared to the other assets. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Updating-attachment-assets-tp6852172p6857717.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
Re: [Opensim-dev] Updating attachment assets
Thanks for that info! Indeed it's unsafe to delete assets in the scenario that I've described. It looks like it's not safe to delete assets at all (except for trivial assets such as map tiles) unless we add some form of reference-counting or garbage collection, since any asset might be in use in other peoples' inventories, or in a prim in some other region. Suppose I want to implement garbage collection of unused assets. I would need to find which assets are in use anywhere. Would the following procedure be sufficient? : 1. Find all the assets in the inventories of all the users 2. Find all the assets in the inventories of all the prims 3. Parse each asset to find if the asset itself points to other assets (use UuidGatherer) Is there any other place that uses assets? Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Updating-attachment-assets-tp6852172p6854026.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] Updating attachment assets
Occasionally, OpenSim updates the asset of an attachment. This is done in AttachmentsModule.UpdateKnownItem(). For example, this is done whenever the attachment is detached from the avatar. I have a couple of questions about this: 1. A new asset is created, but the old asset is not deleted; it remains as a zombie. I have changed my branch of OpenSim to delete the old asset, and this works well. However, this required making another change: currently OpenSim only allows deleting assets that are map tiles, and I changed it to allow deleting all types of assets. Why was this restriction ever made? If there's no objection, I will submit a patch for this change (delete old attachment asset + allow deleting all types of assets). 2. UpdateKnownItem() decides whether it should update an attachment's asset using this 'if': if (grp.HasGroupChanged || grp.ContainsScripts()) Why check for ContainsScripts()? This was added in 8880ae (Sep 14, 2011). It causes what seem to be unnecessary updates. Oren -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Updating-attachment-assets-tp6852172p6852172.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] Wiki documentation of plugins
I added a page to the wiki to describe the different techniques used in OpenSim to load plugins. If there are any mistakes then please let me know, or edit the page directly. In particular, I'm curious about the seemingly unused extension points: are they really unneeded, or have I missed where they are used? The page is here: http://opensimulator.org/wiki/Plugins -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Wiki-documentation-of-plugins-tp6807677p6807677.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
Re: [Opensim-dev] Proposal: cache compiled scripts across server restarts
Ok, I implemented this according to the second proposal (the more limited one). Patch submitted: http://opensimulator.org/mantis/view.php?id=5557 -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Proposal-cache-compiled-scripts-across-server-restarts-tp6492514p6499964.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] Proposal: cache compiled scripts across server restarts
XEngine currently caches compiled scripts in the ScriptEngines directory, so it only has to compile each script once, even if it's used many times. However, whenever OpenSim starts XEngine deletes all the previously-compiled scripts, which means they need to be recompiled. This makes region startup slow if the region has many scripts. I propose keeping cached scripts even across OpenSim restarts. The only challenge is to make sure scripts are recompiled if the script engine has changed. To do so, I'll append the compiler version to the compiled assembly filename. When XEngine starts, instead of deleting *all* the compiled scripts it will only delete scripts whose version doesn't match the current version. The compiler version will be defined by the user, in OpenSim.ini. For example: [XEngine] ... ;; The current version of the compiler (e.g., the version of OpenSim from Git) CompilerVersion = 94d3076 The default value would be an empty string, which means that the compiler version is undefined. In that case XEngine will continue to use the current logic, i.e. delete all the compiled scripts whenever OpenSim is started. I expect most casual users will keep the default value, so they will see no change from the current behavior. However, more advanced users who have a standard process to upgrade OpenSim (e.g., me ;) ) will be able to improve caching using this mechanism. The filenames would look like this (notice the compiler version at the end): CommonCompiler_compiled_14d3d7a9-0e3b-456d-8f09-54a31b5b2a22_94d3076.dll Any thoughts? -- Oren Hurvitz VP RD Kitely Ltd. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Proposal: cache compiled scripts across server restarts
Cool. Well, about not deleting the scripts: my proposal combined both a mechanism (don't delete the scripts) and a policy (don't delete if the version isn't X). How about I implement only the mechanism, and leave the policy to the sim owner? So, I would add a configuration option such as this one: [XEngine] ... ;; Whether to delete previously compiled scripts when the sim starts. If the compiled scripts aren't ; deleted then startup will be faster, but this might cause incompatibilities if OpenSim was updated ; since the scripts were compiled. DeleteScriptsOnStartup = true Then, the only code change is to check this flag before calling DeleteOldFiles(). -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/Proposal-cache-compiled-scripts-across-server-restarts-tp6492514p6492881.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
