Re: [Opensim-dev] client API bindings?
Toni, Cool idea. :) In OpenSim they are called ClientViews.They implement a protocol which clients can use to connect to the server. The prominent one is for the SL(tm) viewer, but there is an experimental one for another new VW protocol called MXP, and at least an IRC one as well. Also for the Realxtend project there is a modified ClientView where the SL protocol is extended to support Ogre meshes etc. hm, interesting OpenSim is a .NET project, written in C#, so you can use any language that has a .net implementation for writing your thing. IronPython is a pretty cool and mature implementation, I wrote an experimental .py region module loader for OpenSim once and probably you could use it to write a ClientView too if you prefer that to C#. But C# is also nice, kind of a mix of C++ and Python -- if those are what you know from before, should be easy to learn. The API is the same for any .net language. actually it's not that simple. for example, X-Plane has a plugin architecture, that accepts plugins written in C++, or in Python. thust the best is if there's a client implementation in any of these languages, as one has to create a shared object a python files (without native libraries linked) to integrate to X-Plane. (oh, and the native ones in three platforms, Linux, MacOS and Windows) other platforms would behave similarly. also, if one wants a proliferation of clients, one has to allow for a wide range of client implementations. It should be feasible in principle, and I think a quite interesting challenge for the platform. hm hm.. One problem is that due to the Second Life compatibility origins, the OpenSim worlds are partitioned in 256x256m regions, which run as separate instances. When you cross a region border, there is a handover procedure etc. So the default architecture is not at all suitable for flying 300m/s 'cause you'd need so many regions and it'd be doing the crossing procedure all the time. yes, this is a problem indeed. moreover, in a flight simulator, the horizon spans quite far. also, you actually need different update levels - for objects that are close, one needs fast and accurate update, while for objects far but still visible, one doesn't need that frequent updates. moreover, movement prediction is also important - the client needs to be able to predict the trajectory of the objects for smooth drawing, and graceful handling of network connection issues. I think there's an on-going experiment with different sized / large regions, just today Teravus touched this thing it seems, that might serve you and I guess he can tell more - /OpenSim/Region/CoreModules/World/Land/RegionCombinerModule.cs hm I'll take a look.. A trick I've been thinking for supporting fast large movements is to change the scale: make your planes 1/100 the size, so the default region size is then 25,6km for the lilliput pilot in the plane :) A 10x10 region grid or something would already give quite nice amount of space, and grids can be much larger too. Then you could fly past the giant avatars there and they'd have fun seeing small model planes fly :o hm, but what is the position precision then? is it precise enough? For example in MXP you don't have this kind of region stuff in the protocol at all - there you just have a thing called a bubble, which AFAIK is the sphere of perception for the viewer, and the server always tells the client about the things close to it. The client nor the protocol don't know anything about how the space is partitioned on the server(s). So in the MXP ClientView you can perhaps see an example how to adapt the OpenSim internal scene things to a different protocol. this sounds a better approach - but one still needs to treat 'near' and 'far' objects differently (see above) thanks for the input.. Akos ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] versioning question
With the use of git or svn, what is the relationship between the Version and the Build #? Once upon a time, we would do a show version in the console, and it was very clear which specific opensim version was being used. Now, it says: OpenSim 0.6.6 (Dev) (interface version 5) rather than something clearer (at least to me) like: OpenSim Version 10115 The problem is that I don't know which build to refer to as I would imagine that the code base changes daily. Thanks. -p -- Paul Fishwick, PhD Professor and Director, Digital Arts and Sciences Programs University of Florida Computer Information Science and Eng. Dept. Bldg. CSE, Room 301 P.O. Box 116120 Gainesville, FL 32611 Email: fishw...@cise.ufl.edu Phone: (352) 392-1414 Fax: (352) 392-1220 Web: http://www.cise.ufl.edu/~fishwick ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] versioning question
Yes, is very dark. In our server we are using the last Diva's version from git, than works in our case better than the 0.6.6 downladed from the wiki, a service with 0.6.6 .10108, in OSGrid, an other with 0.6.6 .239a1 and other with modrex. The 0.6.6.6 in the console show the same interfase v 5, very criptic and really dark. Albert 2009/9/3 Paul Fishwick fishw...@cise.ufl.edu With the use of git or svn, what is the relationship between the Version and the Build #? Once upon a time, we would do a show version in the console, and it was very clear which specific opensim version was being used. Now, it says: OpenSim 0.6.6 (Dev) (interface version 5) rather than something clearer (at least to me) like: OpenSim Version 10115 The problem is that I don't know which build to refer to as I would imagine that the code base changes daily. Thanks. -p -- Paul Fishwick, PhD Professor and Director, Digital Arts and Sciences Programs University of Florida Computer Information Science and Eng. Dept. Bldg. CSE, Room 301 P.O. Box 116120 Gainesville, FL 32611 Email: fishw...@cise.ufl.edu Phone: (352) 392-1414 Fax: (352) 392-1220 Web: http://www.cise.ufl.edu/~fishwick ___ 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] versioning question
The 'interface v5' part refers to the interface protocol between the region simulator and the grid (and defacto, between region simulators). It doesn't have anything at all to do with the OpenSim version (0.6.6). In principle, if you are running from a source repository update then the git version should be tacked on the end of OpenSim 0.6.6 (e.g. 0.6.6 239a1). This should also be true if you are updating from the SVN mirror (e.g. 0.6.6.10108). If this isn't the case then this is arguably a bug. Gustavo Alberto Navarro Bilbao wrote: Yes, is very dark. In our server we are using the last Diva's version from git, than works in our case better than the 0.6.6 downladed from the wiki, a service with 0.6.6 .10108, in OSGrid, an other with 0.6.6 .239a1 and other with modrex. The 0.6.6.6 in the console show the same interfase v 5, very criptic and really dark. Albert 2009/9/3 Paul Fishwick fishw...@cise.ufl.edu mailto:fishw...@cise.ufl.edu With the use of git or svn, what is the relationship between the Version and the Build #? Once upon a time, we would do a show version in the console, and it was very clear which specific opensim version was being used. Now, it says: OpenSim 0.6.6 (Dev) (interface version 5) rather than something clearer (at least to me) like: OpenSim Version 10115 The problem is that I don't know which build to refer to as I would imagine that the code base changes daily. Thanks. -p -- Paul Fishwick, PhD Professor and Director, Digital Arts and Sciences Programs University of Florida Computer Information Science and Eng. Dept. Bldg. CSE, Room 301 P.O. Box 116120 Gainesville, FL 32611 Email: fishw...@cise.ufl.edu mailto:fishw...@cise.ufl.edu Phone: (352) 392-1414 Fax: (352) 392-1220 Web: http://www.cise.ufl.edu/~fishwick ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto: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 -- justincc Justin Clark-Casey http://justincc.org ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] versioning question
Paul Fishwick wrote: Justin: Justin Clark-Casey wrote: The 'interface v5' part refers to the interface protocol between the region simulator and the grid (and defacto, between region simulators). It doesn't have anything at all to do with the OpenSim version (0.6.6). OK In principle, if you are running from a source repository update then the git version should be tacked on the end of OpenSim 0.6.6 (e.g. 0.6.6 239a1). This should also be true if you are updating from the SVN mirror (e.g. 0.6.6.10108). If this isn't the case then this is arguably a bug. Where does one find this build # (i.e., 239a1 or 10108) ? It is not produced through show version. If that is a bug, I can file it. -paul If you execute 'git log' on the command line, the long string after the word commit is the build identifier, e.g. in paste commit 4841858600cf35903966d48451015b2be5e97d5c Author: Chris Hart ch...@reactiongrid.com Date: Wed Sep 2 13:28:57 2009 +0100 MSSQL patch to mirror mantis 4077 for MySQL to improve region load times /paste 4841858600cf35903966d48451015b2be5e97d5c is the identifier. We often identify these only by the first selection of characters, e.g. 48418 These identifiers are not sequential. There might be a shorter way to get this information from the command line but I don't know what it is. Gustavo Alberto Navarro Bilbao wrote: Yes, is very dark. In our server we are using the last Diva's version from git, than works in our case better than the 0.6.6 downladed from the wiki, a service with 0.6.6 .10108, in OSGrid, an other with 0.6.6 .239a1 and other with modrex. The 0.6.6.6 in the console show the same interfase v 5, very criptic and really dark. Albert 2009/9/3 Paul Fishwick fishw...@cise.ufl.edu mailto:fishw...@cise.ufl.edu With the use of git or svn, what is the relationship between the Version and the Build #? Once upon a time, we would do a show version in the console, and it was very clear which specific opensim version was being used. Now, it says: OpenSim 0.6.6 (Dev) (interface version 5) rather than something clearer (at least to me) like: OpenSim Version 10115 The problem is that I don't know which build to refer to as I would imagine that the code base changes daily. Thanks. -p -- Paul Fishwick, PhD Professor and Director, Digital Arts and Sciences Programs University of Florida Computer Information Science and Eng. Dept. Bldg. CSE, Room 301 P.O. Box 116120 Gainesville, FL 32611 Email: fishw...@cise.ufl.edu mailto:fishw...@cise.ufl.edu Phone: (352) 392-1414 Fax: (352) 392-1220 Web: http://www.cise.ufl.edu/~fishwick ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto: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 -- justincc Justin Clark-Casey http://justincc.org ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] versioning question
I am using TortoiseGit and did a show log. When I do this, and show the graph clicking on the topmost message dated 9/2/2009, there is something that says Showing 10185 Revisions from Revision a82950 to 6cf610 not sure how to interpret this hexadecimal indexing. Should I consider 10185 to be the number? The actual commit # is a long hexadecimal string. The beginning of it matches what you said: 6cf610 is the revision #? Do we need to bring out the old HP calculators? :) -paul Justin Clark-Casey wrote: Paul Fishwick wrote: Justin: Justin Clark-Casey wrote: The 'interface v5' part refers to the interface protocol between the region simulator and the grid (and defacto, between region simulators). It doesn't have anything at all to do with the OpenSim version (0.6.6). OK In principle, if you are running from a source repository update then the git version should be tacked on the end of OpenSim 0.6.6 (e.g. 0.6.6 239a1). This should also be true if you are updating from the SVN mirror (e.g. 0.6.6.10108). If this isn't the case then this is arguably a bug. Where does one find this build # (i.e., 239a1 or 10108) ? It is not produced through show version. If that is a bug, I can file it. -paul If you execute 'git log' on the command line, the long string after the word commit is the build identifier, e.g. in paste commit 4841858600cf35903966d48451015b2be5e97d5c Author: Chris Hart ch...@reactiongrid.com Date: Wed Sep 2 13:28:57 2009 +0100 MSSQL patch to mirror mantis 4077 for MySQL to improve region load times /paste 4841858600cf35903966d48451015b2be5e97d5c is the identifier. We often identify these only by the first selection of characters, e.g. 48418 These identifiers are not sequential. There might be a shorter way to get this information from the command line but I don't know what it is. Gustavo Alberto Navarro Bilbao wrote: Yes, is very dark. In our server we are using the last Diva's version from git, than works in our case better than the 0.6.6 downladed from the wiki, a service with 0.6.6 .10108, in OSGrid, an other with 0.6.6 .239a1 and other with modrex. The 0.6.6.6 in the console show the same interfase v 5, very criptic and really dark. Albert 2009/9/3 Paul Fishwick fishw...@cise.ufl.edu mailto:fishw...@cise.ufl.edu With the use of git or svn, what is the relationship between the Version and the Build #? Once upon a time, we would do a show version in the console, and it was very clear which specific opensim version was being used. Now, it says: OpenSim 0.6.6 (Dev) (interface version 5) rather than something clearer (at least to me) like: OpenSim Version 10115 The problem is that I don't know which build to refer to as I would imagine that the code base changes daily. Thanks. -p -- Paul Fishwick, PhD Professor and Director, Digital Arts and Sciences Programs University of Florida Computer Information Science and Eng. Dept. Bldg. CSE, Room 301 P.O. Box 116120 Gainesville, FL 32611 Email: fishw...@cise.ufl.edu mailto:fishw...@cise.ufl.edu Phone: (352) 392-1414 Fax: (352) 392-1220 Web: http://www.cise.ufl.edu/~fishwick ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto: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 -- Paul Fishwick, PhD Professor and Director, Digital Arts and Sciences Programs University of Florida Computer Information Science and Eng. Dept. Bldg. CSE, Room 301 P.O. Box 116120 Gainesville, FL 32611 Email: fishw...@cise.ufl.edu Phone: (352) 392-1414 Fax: (352) 392-1220 Web: http://www.cise.ufl.edu/~fishwick ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] versioning question
Paul Fishwick wrote: I am using TortoiseGit and did a show log. When I do this, and show the graph clicking on the topmost message dated 9/2/2009, there is something that says Showing 10185 Revisions from Revision a82950 to 6cf610 It will be 6cf610, as this is only two revisions from the bleeding edge. a82950 is the very oldest revision and 10185 might be the absolute number of revs. not sure how to interpret this hexadecimal indexing. Should I consider 10185 to be the number? The actual commit # is a long hexadecimal string. The beginning of it matches what you said: 6cf610 is the revision #? Do we need to bring out the old HP calculators? :) -paul Justin Clark-Casey wrote: Paul Fishwick wrote: Justin: Justin Clark-Casey wrote: The 'interface v5' part refers to the interface protocol between the region simulator and the grid (and defacto, between region simulators). It doesn't have anything at all to do with the OpenSim version (0.6.6). OK In principle, if you are running from a source repository update then the git version should be tacked on the end of OpenSim 0.6.6 (e.g. 0.6.6 239a1). This should also be true if you are updating from the SVN mirror (e.g. 0.6.6.10108). If this isn't the case then this is arguably a bug. Where does one find this build # (i.e., 239a1 or 10108) ? It is not produced through show version. If that is a bug, I can file it. -paul If you execute 'git log' on the command line, the long string after the word commit is the build identifier, e.g. in paste commit 4841858600cf35903966d48451015b2be5e97d5c Author: Chris Hart ch...@reactiongrid.com Date: Wed Sep 2 13:28:57 2009 +0100 MSSQL patch to mirror mantis 4077 for MySQL to improve region load times /paste 4841858600cf35903966d48451015b2be5e97d5c is the identifier. We often identify these only by the first selection of characters, e.g. 48418 These identifiers are not sequential. There might be a shorter way to get this information from the command line but I don't know what it is. Gustavo Alberto Navarro Bilbao wrote: Yes, is very dark. In our server we are using the last Diva's version from git, than works in our case better than the 0.6.6 downladed from the wiki, a service with 0.6.6 .10108, in OSGrid, an other with 0.6.6 .239a1 and other with modrex. The 0.6.6.6 in the console show the same interfase v 5, very criptic and really dark. Albert 2009/9/3 Paul Fishwick fishw...@cise.ufl.edu mailto:fishw...@cise.ufl.edu With the use of git or svn, what is the relationship between the Version and the Build #? Once upon a time, we would do a show version in the console, and it was very clear which specific opensim version was being used. Now, it says: OpenSim 0.6.6 (Dev) (interface version 5) rather than something clearer (at least to me) like: OpenSim Version 10115 The problem is that I don't know which build to refer to as I would imagine that the code base changes daily. Thanks. -p -- Paul Fishwick, PhD Professor and Director, Digital Arts and Sciences Programs University of Florida Computer Information Science and Eng. Dept. Bldg. CSE, Room 301 P.O. Box 116120 Gainesville, FL 32611 Email: fishw...@cise.ufl.edu mailto:fishw...@cise.ufl.edu Phone: (352) 392-1414 Fax: (352) 392-1220 Web: http://www.cise.ufl.edu/~fishwick ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto: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 -- justincc Justin Clark-Casey http://justincc.org ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] 0.6.6 kind of working - except for inventory access issues - and does not have root folder errors
Making progress. I got 0.6.6 up with our old data base 0.6.3 data contents and 12 regions :-) I can even log in with SL viewer 1.23, and except for a few attachments not still being attached (like hair on avatars!) it all looks quite reasonable. But I am getting inventory access warning errors, and as soon as I open the user's inventory folder the SL viewer crashes. I see errors in the opensim.exe console that the avatar does not have root folder Before I start to delve deeper tomorrow, as it could be something silly with the IP addresses (all the same mac hone) or the data base access strings for MySQL, I just thought I would ask if this sound familiar to anyone and would appreciate any pointers. Best wishes, Ai (another day gone !) ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] versioning question
I have been playing around with a solution for the sequential version reporting, but it is not as simple as it may seem. The best description of the problem and solution I have found is at: http://michaelandlaura.org.uk/~michael/blog/index.php?id=379 The catch is that we appear to be using tag objects that are orphaned. To see an example of that, just run git show-ref on a clone tree for 0.6.6-release. The hash is shown, but then git log does not contain that hash, even when tracking the master. It seems that we need to switch to a slightly different policy of checking in and tagging at a release boundary and no orphaning that tag object. Alternatively, we could just lightweight tag the checkin that changes the release version file. Comments? Kurt Paul Fishwick wrote: With the use of git or svn, what is the relationship between the Version and the Build #? Once upon a time, we would do a show version in the console, and it was very clear which specific opensim version was being used. Now, it says: OpenSim 0.6.6 (Dev) (interface version 5) rather than something clearer (at least to me) like: OpenSim Version 10115 The problem is that I don't know which build to refer to as I would imagine that the code base changes daily. Thanks. -p -- Kurt Taylor (Kurt Stringer) ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] versioning question
Paul Fishwick wrote: Justin Clark-Casey wrote: It will be 6cf610, as this is only two revisions from the bleeding edge. a82950 is the very oldest revision and 10185 might be the absolute number of revs. As long as there is a way that we know how to compare revisions. IE: The next revision to 6cf610 will be 6cf610 + 1 = 6cf611, then at least there is some logic to it. This is exactly what isn't the case - the identifiers are generated randomly without any connection between them. This seems to be one of the (few) downsides of git. There was some talk on this list about somehow producing sequential numbers some time ago but I don't know the details. If my hex intuitions serve me, 6cf610 a82950 so does anyone know how these version #s are to be interpreted or are they random identifiers? And if they are random, how do we track where we are? maybe, I should go back to the 10185 revision(s) and use that #. -p not sure how to interpret this hexadecimal indexing. Should I consider 10185 to be the number? The actual commit # is a long hexadecimal string. The beginning of it matches what you said: 6cf610 is the revision #? Do we need to bring out the old HP calculators? :) -paul Justin Clark-Casey wrote: Paul Fishwick wrote: Justin: Justin Clark-Casey wrote: The 'interface v5' part refers to the interface protocol between the region simulator and the grid (and defacto, between region simulators). It doesn't have anything at all to do with the OpenSim version (0.6.6). OK In principle, if you are running from a source repository update then the git version should be tacked on the end of OpenSim 0.6.6 (e.g. 0.6.6 239a1). This should also be true if you are updating from the SVN mirror (e.g. 0.6.6.10108). If this isn't the case then this is arguably a bug. Where does one find this build # (i.e., 239a1 or 10108) ? It is not produced through show version. If that is a bug, I can file it. -paul If you execute 'git log' on the command line, the long string after the word commit is the build identifier, e.g. in paste commit 4841858600cf35903966d48451015b2be5e97d5c Author: Chris Hart ch...@reactiongrid.com Date: Wed Sep 2 13:28:57 2009 +0100 MSSQL patch to mirror mantis 4077 for MySQL to improve region load times /paste 4841858600cf35903966d48451015b2be5e97d5c is the identifier. We often identify these only by the first selection of characters, e.g. 48418 These identifiers are not sequential. There might be a shorter way to get this information from the command line but I don't know what it is. Gustavo Alberto Navarro Bilbao wrote: Yes, is very dark. In our server we are using the last Diva's version from git, than works in our case better than the 0.6.6 downladed from the wiki, a service with 0.6.6 .10108, in OSGrid, an other with 0.6.6 .239a1 and other with modrex. The 0.6.6.6 in the console show the same interfase v 5, very criptic and really dark. Albert 2009/9/3 Paul Fishwick fishw...@cise.ufl.edu mailto:fishw...@cise.ufl.edu With the use of git or svn, what is the relationship between the Version and the Build #? Once upon a time, we would do a show version in the console, and it was very clear which specific opensim version was being used. Now, it says: OpenSim 0.6.6 (Dev) (interface version 5) rather than something clearer (at least to me) like: OpenSim Version 10115 The problem is that I don't know which build to refer to as I would imagine that the code base changes daily. Thanks. -p -- Paul Fishwick, PhD Professor and Director, Digital Arts and Sciences Programs University of Florida Computer Information Science and Eng. Dept. Bldg. CSE, Room 301 P.O. Box 116120 Gainesville, FL 32611 Email: fishw...@cise.ufl.edu mailto:fishw...@cise.ufl.edu Phone: (352) 392-1414 Fax: (352) 392-1220 Web: http://www.cise.ufl.edu/~fishwick ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto: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 -- justincc Justin Clark-Casey http://justincc.org ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] versioning question
Justin Clark-Casey wrote: It will be 6cf610, as this is only two revisions from the bleeding edge. a82950 is the very oldest revision and 10185 might be the absolute number of revs. As long as there is a way that we know how to compare revisions. IE: The next revision to 6cf610 will be 6cf610 + 1 = 6cf611, then at least there is some logic to it. If my hex intuitions serve me, 6cf610 a82950 so does anyone know how these version #s are to be interpreted or are they random identifiers? And if they are random, how do we track where we are? maybe, I should go back to the 10185 revision(s) and use that #. -p not sure how to interpret this hexadecimal indexing. Should I consider 10185 to be the number? The actual commit # is a long hexadecimal string. The beginning of it matches what you said: 6cf610 is the revision #? Do we need to bring out the old HP calculators? :) -paul Justin Clark-Casey wrote: Paul Fishwick wrote: Justin: Justin Clark-Casey wrote: The 'interface v5' part refers to the interface protocol between the region simulator and the grid (and defacto, between region simulators). It doesn't have anything at all to do with the OpenSim version (0.6.6). OK In principle, if you are running from a source repository update then the git version should be tacked on the end of OpenSim 0.6.6 (e.g. 0.6.6 239a1). This should also be true if you are updating from the SVN mirror (e.g. 0.6.6.10108). If this isn't the case then this is arguably a bug. Where does one find this build # (i.e., 239a1 or 10108) ? It is not produced through show version. If that is a bug, I can file it. -paul If you execute 'git log' on the command line, the long string after the word commit is the build identifier, e.g. in paste commit 4841858600cf35903966d48451015b2be5e97d5c Author: Chris Hart ch...@reactiongrid.com Date: Wed Sep 2 13:28:57 2009 +0100 MSSQL patch to mirror mantis 4077 for MySQL to improve region load times /paste 4841858600cf35903966d48451015b2be5e97d5c is the identifier. We often identify these only by the first selection of characters, e.g. 48418 These identifiers are not sequential. There might be a shorter way to get this information from the command line but I don't know what it is. Gustavo Alberto Navarro Bilbao wrote: Yes, is very dark. In our server we are using the last Diva's version from git, than works in our case better than the 0.6.6 downladed from the wiki, a service with 0.6.6 .10108, in OSGrid, an other with 0.6.6 .239a1 and other with modrex. The 0.6.6.6 in the console show the same interfase v 5, very criptic and really dark. Albert 2009/9/3 Paul Fishwick fishw...@cise.ufl.edu mailto:fishw...@cise.ufl.edu With the use of git or svn, what is the relationship between the Version and the Build #? Once upon a time, we would do a show version in the console, and it was very clear which specific opensim version was being used. Now, it says: OpenSim 0.6.6 (Dev) (interface version 5) rather than something clearer (at least to me) like: OpenSim Version 10115 The problem is that I don't know which build to refer to as I would imagine that the code base changes daily. Thanks. -p -- Paul Fishwick, PhD Professor and Director, Digital Arts and Sciences Programs University of Florida Computer Information Science and Eng. Dept. Bldg. CSE, Room 301 P.O. Box 116120 Gainesville, FL 32611 Email: fishw...@cise.ufl.edu mailto:fishw...@cise.ufl.edu Phone: (352) 392-1414 Fax: (352) 392-1220 Web: http://www.cise.ufl.edu/~fishwick ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto: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 -- Paul Fishwick, PhD Professor and Director, Digital Arts and Sciences Programs University of Florida Computer Information Science and Eng. Dept. Bldg. CSE, Room 301 P.O. Box 116120 Gainesville, FL 32611 Email: fishw...@cise.ufl.edu Phone: (352) 392-1414 Fax: (352) 392-1220 Web: http://www.cise.ufl.edu/~fishwick ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] versioning question
krtaylor wrote:
I have been playing around with a solution for the sequential version
reporting, but it is not as simple as it may seem. The best description
of the problem and solution I have found is at:
http://michaelandlaura.org.uk/~michael/blog/index.php?id=379
The catch is that we appear to be using tag objects that are orphaned.
To see an example of that, just run git show-ref on a clone tree for
0.6.6-release. The hash is shown, but then git log does not contain that
hash, even when tracking the master.
hmm, i don't even get that tag:
% git show-ref | grep 0.6.6
cb7704e6498d2899fe4cd17c8f28d02522f80d77 \
refs/remotes/opensimulator.org/0.6.6-post-fixes
is all i get, but that hash is known to git:
% git show cb7704e6498d2899fe4cd17c8f28d02522f80d77
commit cb7704e6498d2899fe4cd17c8f28d02522f80d77
Author: Melanie mela...@t-data.com
Date: Sat Aug 8 01:42:50 2009 +0100
Change the default for internal IP address back to 0.0.0.0
diff --git a/OpenSim/Framework/RegionInfo.cs b/OpenSim/Framework/RegionInfo.cs
index 7ac1e62..4640406 100644
--- a/OpenSim/Framework/RegionInfo.cs
+++ b/OpenSim/Framework/RegionInfo.cs
@@ -493,7 +493,7 @@ namespace OpenSim.Framework
}
else
{
-address =
IPAddress.Parse(MainConsole.Instance.CmdPrompt(Internal IP address,
127.0.0.1));
+address =
IPAddress.Parse(MainConsole.Instance.CmdPrompt(Internal IP address,
0.0.0.0));
config.Set(InternalAddress, address.ToString());
}
i guess i'm missing something here...
--
dr dirk husemann virtual worlds research ibm zurich research lab
SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] 0.6.6 kind of working - except for inventory access issues - and does not have root folder errors
It's happened to us too, very strange, only for some avatars, not for others. Opensim claimed that it did notfind the root folder and proceeded to create another. Then the user had a duplicate Animations folder, duplicate Body Parts folder, etc. I was able to fix some of these users by manually deleting the spurious folders using SQL. It's not happened any more since we're on 10108. Since it never happened to me, I can't say much more about the subject (i.e., about the client used, or whether the problem indeed can repeat itself on 10108 or not, etc). /Zonja On Thu, Sep 3, 2009 at 6:40 PM, Ai Austin ai.ai.aus...@googlemail.comwrote: Making progress. I got 0.6.6 up with our old data base 0.6.3 data contents and 12 regions :-) I can even log in with SL viewer 1.23, and except for a few attachments not still being attached (like hair on avatars!) it all looks quite reasonable. But I am getting inventory access warning errors, and as soon as I open the user's inventory folder the SL viewer crashes. I see errors in the opensim.exe console that the avatar does not have root folder Before I start to delve deeper tomorrow, as it could be something silly with the IP addresses (all the same mac hone) or the data base access strings for MySQL, I just thought I would ask if this sound familiar to anyone and would appreciate any pointers. Best wishes, Ai (another day gone !) ___ 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] client API bindings?
On Sep 3, 2009, at 5:55 PM, Maróy Ákos wrote: region module loader for OpenSim once and probably you could use it to write a ClientView too if you prefer that to C#. But C# is also nice, kind of a mix of C++ and Python -- if those are what you know from actually it's not that simple. for example, X-Plane has a plugin architecture, that accepts plugins written in C++, or in Python. thust the best is if there's a client implementation in any of these languages, as one has to create a shared object a python files (without native libraries linked) to integrate to X-Plane. (oh, and the native ones in three platforms, Linux, MacOS and Windows) Hm, trying to get what you are saying exactly .. are you saying this is something that applies to both the server and clients? Where do you create the shared python objects? On either end, and then those are sent across and deserialized? I know how pickles work and how those can be used for sharing state, but am actually very surprised to hear that x-plane would use them in the protocol. I don't know basically anything about x-plane before. As you say 'without native libraries linked', perhaps ironpython and cpython are compatible, or can be made so, on that level .. am not sure exactly but we can find that out, if that indeed is the need .. i'm not sure I understood this correctly. Sounds that it may be really cool (pickles can be arbitary data and code .. which is also why they are often not used for security reasons, you must know what you are doing if you use them .. that might be a reason why linking to native libs is not allowed, dunno :o) also, if one wants a proliferation of clients, one has to allow for a wide range of client implementations. Well I thought that if you write an x-plane protocol implementation as an OpenSim plugin, a XplaneClientView or something, it would support any client that talks that protocol. Like the SL, MXP and IRC ClientViews do support any compatible clients. One problem is that due to the Second Life compatibility origins, the OpenSim worlds are partitioned in 256x256m regions, which run as yes, this is a problem indeed. moreover, in a flight simulator, the horizon spans quite far. also, you actually need different update levels - for objects that are close, one needs fast and accurate update, while for objects far but still visible, one doesn't need that frequent updates. For that it may not actually be much of a problem. As you can see in the viewers now, the horizon can span far. In ones that talk sl protocol the viewers can know about several regions at a time, so they can draw the neighbouring ones too, and they draw sky and sea etc. however they want of course. And there needs to be LOD (level of detail) systems for all usages, in many ways (for movement update detail amount, for 3d data resolution etc.). moreover, movement prediction is also important - the client needs to be able to predict the trajectory of the objects for smooth drawing, and graceful handling of network connection issues. Again, I thought that this was about a server implementation, as OpenSim is a server platform / SDK, and that you'd use existing Xplane clients. Or do you mean that the server also communicates expected trajectories, so the client can draw based on the 'future' info too? Should be doable, if it's done elsewhere too.. Client side movement interpolation is implemented in the current viewers, even in our Realxtend Naal which in very early stages still (0.0.1 dev preview was published in June after 4 months of dev work, 0.0.2 is targeted in october or so and something like 0.1 perhaps by the end of the year). So I don't know how much of that you need on the server with xplane, but certainly sounds like something that flight servers could do .. and again very cool if they do. A trick I've been thinking for supporting fast large movements is to change the scale: make your planes 1/100 the size, so the default region size is then 25,6km for the lilliput pilot in the plane :) A 10x10 hm, but what is the position precision then? is it precise enough? May be, could be tested .. I think they are floats, at least in our viewer, and floats are IIRC accurate near 1.0 .. hmhm well we can see, or someone wiser can tell, am too tired to do any math right now here. For example in MXP you don't have this kind of region stuff in the protocol at all - there you just have a thing called a bubble, which AFAIK is the sphere of perception for the viewer, and the server always tells the client about the things close to it. The client nor the this sounds a better approach - but one still needs to treat 'near' and 'far' objects differently (see above) Yes, both server and client need to be smart about that. Server to know what to send I guess, and client for what to draw (or what to request from server, when server can be dummier? Dunno, but there probably are solutions to this
Re: [Opensim-dev] ConsoleClient -pass option
On Thursday 03 September 2009 03:00:46 pm wrote: commit 6b70b5709913e9734f5864560e997b34dfd58b85 Author: Justin Clark-Casey (justincc) jjusti...@googlemail.com Date: Thu Sep 3 20:00:18 2009 +0100 * Add extra warning about using -pass in OpenSim.ConsoleClient.ini.example ... +; Please be aware that this is not secure since the password is in the clear +; we recommend the use of -pass wherever possible ;pass = secret Is the password not also in the clear, visible to any local user who does a 'ps', if you use the -pass switch? Access to OpenSim.ConsoleClient.ini can at least be restricted to specific user(s). I don't see how -pass is the lesser of the two evils. -coyled signature.asc Description: This is a digitally signed message part. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] ConsoleClient -pass option
It's choosing the lesser evil. Melanie Dave Coyle wrote: On Thursday 03 September 2009 03:00:46 pm wrote: commit 6b70b5709913e9734f5864560e997b34dfd58b85 Author: Justin Clark-Casey (justincc) jjusti...@googlemail.com Date: Thu Sep 3 20:00:18 2009 +0100 * Add extra warning about using -pass in OpenSim.ConsoleClient.ini.example ... +; Please be aware that this is not secure since the password is in the clear +; we recommend the use of -pass wherever possible ;pass = secret Is the password not also in the clear, visible to any local user who does a 'ps', if you use the -pass switch? Access to OpenSim.ConsoleClient.ini can at least be restricted to specific user(s). I don't see how -pass is the lesser of the two evils. -coyled ___ 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] ConsoleClient -pass option
I'd agree with Dave on this one. Just a simple long ps listing gets you the password if its on cleartext on the command line. At least the file can be locked down via permissions. A password on the command line is pretty much insecure. Might as well not have one. Mike -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Melanie Sent: Thursday, September 03, 2009 10:02 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] ConsoleClient -pass option It's choosing the lesser evil. Melanie Dave Coyle wrote: On Thursday 03 September 2009 03:00:46 pm wrote: commit 6b70b5709913e9734f5864560e997b34dfd58b85 Author: Justin Clark-Casey (justincc) jjusti...@googlemail.com Date: Thu Sep 3 20:00:18 2009 +0100 * Add extra warning about using -pass in OpenSim.ConsoleClient.ini.example ... +; Please be aware that this is not secure since the password is in the clear +; we recommend the use of -pass wherever possible ;pass = secret Is the password not also in the clear, visible to any local user who does a 'ps', if you use the -pass switch? Access to OpenSim.ConsoleClient.ini can at least be restricted to specific user(s). I don't see how -pass is the lesser of the two evils. -coyled ___ 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
