On 29/04/13 22:54, Dahlia Trimble wrote:
I wasn't looking for people to blame, but now that you mention it..... *evil
grin*
I am a little concerned that a bit of a catch-22 situation has come about with
the current solution. Viewer developers
are unable to test in existing grids due to the default setting, and nobody
will want to change the setting as it might
disrupt the user experience. Any viewer testers will need to overcome the
hurdle of learning that the setting exists and
setting up a test grid. In the mean time users of alternative viewers are left
out in the cold.
What would you consider "significant"? Personally I'd consider Radegast usage
significant and it is not based on LL
code. While it's based on libomv and I have had success teleporting beyond 4096
with other libomv based clients, I've
not been able to test it in Radegast to date due to the existing default.
Perhaps a protocol extension might be an alternative? Some way that a viewer
could signal the simulator that it's
capable of distant teleports and the sim could bypass the restriction for such
viewers?
That would be good, though I'm not sure there's any existing mechanism for a viewer to signal the simulator as to what
features it supports. Possibly one could do something along the same line as the SimulatorFeatures cap and make an
uploaded set of key:value pairs available in the AgentData. This would be a better long term solution than adding
viewer names to a configured list.
On Mon, Apr 29, 2013 at 2:36 PM, Justin Clark-Casey <[email protected]
<mailto:[email protected]>> wrote:
So that Dahlia knows who to blame, I was the one who created this check. I
was very tired of accidentally
teleporting to very remote regions and screwing up my session and I don't
think it's a good user experience.
As other people have said, this restriction is configurable. One could
also have a regular expression whitelist to
let selected viewers to attempt the teleport.
I don't favour changing the default until there are a significant
proportion of viewers in use that could handle
4096+ teleports. As we've seen, we're not even sure what the problem is in
the LL viewer codebase and TPVs.
On 29/04/13 09:38, Ai Austin wrote:
Thanks Dahlia. The explicit limit was added by Diva to try to make lie
easier for users/avatars getting stuck in
limbo, but can be turned on and off with an OpenSim.ini parameter,
default being that it is on. So it can
clearly be removed. Now there is a distinct branch for some viewers
like Firestorm, and that there are already
improvements in Firestorm 4.4.0(OS) to improve the OpenSim experience,
some critical issues like zthe rally
panful and awkward to explain to new users 4096 jump issues just might
now be on te cards to be fixed.
I am sure if this were technically possible in commonly used LL viewers
with an Openim specific branch then the
OS server side default setting for the 4096 jump restriction could
simply be set as OFF by default rather than
ON by default?
On 28 Apr 2013, at 20:59, Dahlia wrote:
There was a time when libomv based viewers could teleport beyond
4096 and
still function correctly, however since then someone added some
code to
OpenSimulator to prevent *any* viewer from teleporting beyond 4096.
While
this effectively prevented the viewing failures experienced with
LL-based
viewers, it also prevented anyone from being able to fix the
problem from
the viewer side. Given that libomv-based clients did not have the
problem
suggests that it's likely entirely withing the LL codebase.
_________________________________________________
Opensim-users mailing list
[email protected] <mailto:[email protected]>
https://lists.berlios.de/__mailman/listinfo/opensim-users
<https://lists.berlios.de/mailman/listinfo/opensim-users>
--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
_________________________________________________
Opensim-users mailing list
[email protected] <mailto:[email protected]>
https://lists.berlios.de/__mailman/listinfo/opensim-users
<https://lists.berlios.de/mailman/listinfo/opensim-users>
_______________________________________________
Opensim-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-users
--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
_______________________________________________
Opensim-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-users
