First, let me just state upfront that I have no idea what interface
numbers mean. I haven't used them, and since there have been no
releases, I'm not sure what these numbers mean. Is this the grid-wide
interface number? If so, HG compatibility is correlated with it, but but
HG involves a lot more than intra-grid comms and needs its own
numbering. So far, there have been no HG interface numbering yet. Likely
to change soon.
All the work that you are talking about is happening in developers code.
Developers code often has bugs. That was probably the case here.
otakup0pe did a serious cleanup of service addressing in on his own
repo, which wasn't that much exposed to testing. I then took his changes
and merged them to master. Additionally, before I merged his code, I did
a few more things to HG related to the preservation of creator
information -- that was the reason why the configs changed.
As is often the case, otakup0pe's code wasn't perfect, there were a few
bugs that were exposed as I and others started testing, so they were
corrected. I'm sure my own changes may still have a few buglets. If you
happen to be running a revision that has those bugs -- too bad, things
will likely fail.
In general, when ppl test developers code, you *must* expect that things
will *not* work. Many times things break by accident, and we fix them a
few revisions later; other times they break on purpose, and that's when
we warn people.
When things are supposed to work, and don't, that's a bug. Please report
bugs as usual! -- but using revision numbers, not these interface
numbers. Thanks!
On 12/11/2010 3:24 PM, Ai Austin wrote:
We understand that there is incompatibility between the old HG 1.0 and
the more secure HG1.5.
As I understand it there was a change in some data base entries from
"interface 6 to interface 7" which also meant that HG 1.5 i6 versions
and before were incompatible with HG i7 and later. At least it was
observed that HG 1.5 i7 girds could interwork, and those could not
work with HG 1.5 i6 ones. Is that correct Diva, or is that just the
assumption that was made by some seeking to diagnose HG jump issues?
But now in testing recent versions with recent config changes for HG,
there may be further incompatibility with previous HG 1.5 i7 grids, or
it could be that they are just not yet properly configured. It would
be helpful if Diva could let us know if an incompatib8klity to earlier
HG1.5 i7 grids is known, =and what release version in 0.7.1 dev master
is the cut off point to have as a minimum upgrade level to be
compatible again. If there is an incompatibility, it cold be useful
to have a way to refer to this new partition of the hypergrid
compatible grids.
I am happy to continue testing if anyone wants to check out what is
happening, or to try to identify the issues in recent versions of
OSGrid with lack of HG jump capability. Some of the testing being
done, and the grids known to work under the new versions and that can
be used to test are listed at
http://opensimulator.org/mantis/view.php?id=5259
Grids that are known to work (via a chatted link) two way when on
latest 0.7.1 dev master are on our Openvue grid, and a test region
that Diva set up at UCI...
secondlife://virtual.aiai.ed.ac.uk:8002:Openvue/ (at 1000,1000)
secondlife://virtual.aiai.ed.ac.uk:8002:Vue-5000/ (at 5000,5000)
secondlife://virtual.aiai.ed.ac.uk:8002:Vue-9000/ (at 9017,9017)
secondlife://ucigrid03.nacs.uci.edu:9000/ (at 9000,9000) region name
"UCI Grid 03"
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
