<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">+1 also. <br>
<br>
Jak<br>
<br>
On 09/11/2015 16:22, Terry Ford wrote:<br>
</div>
<blockquote cite="mid:5640C84A.80308@digiworldz.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
+1 On seth's idea..<br>
I too would prefer to see only allow the option of either correct
or false values.<br>
<br>
~Terry<br>
<br>
<div class="moz-cite-prefix">On 11/9/2015 10:05 AM, Seth Nygard
wrote:<br>
</div>
<blockquote cite="mid:5640B650.1090904@gmail.com" type="cite">Let
the FPS wars begin so there can be confusion everywhere... <br>
Now those that want to can set a ridiculous fudge factor and
show 11000000FPS - WOW, look, waaaaaaay faster than "that other
grid"! <br>
<br>
I firmly disagree in adding anything that allows artificially
inflated metrics for any value. At this stage the configurable
fudge factor is an even worse "fix" IMHO. <br>
<br>
The correct fix is really to communicate the correct value(s)
and put pressure on the viewer developers to fix their lag
calculation(s). People can be expected to update their
viewer(s) which is not an unrealistic expectation. People
running old and/or unsupported viewers already have a plethora
of issues they need to be aware of and things that don't work
right, so why is the lag indicator any different? <br>
<br>
If we must have this user configurable then, instead of a fudge
factor value it should be a simple boolean setting such as; <br>
ShowArtificiallyInflatedAndIncorrectFPS = false; <br>
ShowArtificiallyInflatedAndIncorrectFPS = true; <br>
<br>
On my grid I have made it a point to inform everyone that the
calculated lag indicator is broken and the 11FPS is in the
correct and normal value. I also point out that what used to be
shown was in fact a falsified and artificially inflated value to
make things look like "that other grid". Most people simple say
"Oh yeah, I never paid attention to that anyhow. It doesn't
work right any of the time anyhow". Many then say they looked
at the wiki but couldn't find any information on what to expect.
<br>
<br>
If whenever people ask for documentation the standard reply from
the dev community is "read the code" then why is it so hard to
ask for, and expect the viewers to be fixed and updated? <br>
<br>
-Seth <br>
<br>
On 09/11/2015 8:56 AM, <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:opensim-dev-request@opensimulator.org">opensim-dev-request@opensimulator.org</a>
wrote: <br>
<blockquote type="cite">Send Opensim-dev mailing list
submissions to <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:opensim-dev@opensimulator.org">opensim-dev@opensimulator.org</a>
<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit <br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a>
<br>
or, via email, send a message with subject or body 'help' to <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:opensim-dev-request@opensimulator.org">opensim-dev-request@opensimulator.org</a>
<br>
<br>
You can reach the person managing the list at <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:opensim-dev-owner@opensimulator.org">opensim-dev-owner@opensimulator.org</a>
<br>
<br>
When replying, please edit your Subject line so it is more
specific <br>
than "Re: Contents of Opensim-dev digest..." <br>
<br>
<br>
Today's Topics: <br>
<br>
1. Re: Still on Sim and Phys Frames per Second (FPS)
(Melanie IMAP) <br>
<br>
<br>
----------------------------------------------------------------------
<br>
<br>
Message: 1 <br>
Date: Mon, 9 Nov 2015 14:56:22 +0100 <br>
From: Melanie IMAP <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:melanie@t-data.com"><melanie@t-data.com></a>
<br>
To: <a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:opensim-dev@opensimulator.org">"opensim-dev@opensimulator.org"</a>
<a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:opensim-dev@opensimulator.org"><opensim-dev@opensimulator.org></a>
<br>
Subject: Re: [Opensim-dev] Still on Sim and Phys Frames per
Second <br>
(FPS) <br>
Message-ID: <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:925ECFD1-AF4F-42EE-A1F7-806717665871@t-data.com"><925ECFD1-AF4F-42EE-A1F7-806717665871@t-data.com></a>
<br>
Content-Type: text/plain; charset="us-ascii" <br>
<br>
Hi, <br>
<br>
what has changed is that I had never used the "Lag meter",
because such a simplistic tool with "idiot lights" can't be
accurate. <br>
Therefore I didn't know it based it's findings on this stat. <br>
<br>
It takes a while for information to filter back from users to
grid operators, so I didn't haer about the problems in
userland until a month or so ago. <br>
<br>
Fact is that, previously unknown to me, the viewer uses this
stat in an arithmetic fashion as opposed to just displaying
it. <br>
<br>
While the past has shown that script and module writers are
happy to adapt to such changes, we know thet viewers are much
slower to update. Also, some widely used viewers are no longer
maintained at all. <br>
<br>
Because if this, the _option_ of restoring the "fudge factor"
was brought back. The default, which will be discussed
further, is 1.0, which means accurate stats remain n effect,
but grids with angry users will be able to restore fudged
values to keep peace in their communities. <br>
<br>
I still believe the accurate measurements should be reported,
but we needs must bow to realities like the Lag Meter. <br>
<br>
I have suggested to extend the reported data by a new field
that represents accurate values so viewers can choose to
diplay the accurate value and still have the normalized value
available to drive the lag meter. <br>
<br>
- Melanie <br>
<br>
On 9 Nov 2015, at 04:04, dz <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:dz@bitzend.net"><dz@bitzend.net></a>
wrote: <br>
<br>
Call me confused...... But don't tell me I can't read
history! <br>
<br>
This discussion is about a patch that was submitted in March
and that patch was based on questions that were raised in
February. <br>
According to my reading of the discussions that Google has so
kindly archived in my Opensim-dev folder the ONLY technical
objection to the proposed patch dealt with an issue on the
accuracy of time dilation factors. <br>
<br>
There were numerous calls for people who might be affected
to speak up... There were repeated calls for opinions
and I see +1's from Diva, BlueWall, Nebadon, and others
who saw fit to participate and voice opinions. The ONLY
objection raised to changing to an accurate reporting was
the assertion that "significant numbers of monitoring tools
and bots" might need to be reworked. Divas call for
additional discussion delayed the implementation of the patch
for over 2 months and NO ONE objected to modifying
their "numerous monitoring scripts" or even commented on a
potential negative impact. <br>
<br>
Its been months since the patch was applied and the world
hasn't stopped turning. Until just a few days ago there
was nary a PEEP about any adverse impact on the mailing
lists... WHERE is this horde of angry users??? They don't
seem to be participating in any of the OpenSim communities
I track... then after almost a WHOLE DAY a patch is
introduced into the next GIANT ( read Impossible to parse
through) Update to reverse the agreement that was
achieved. Pardon me if I wonder WTF ???? This sure
makes me confident! <br>
<br>
Of course there are always delicious tidbits of
perspective that a look in the history books provides....
these 2 both made me laugh.... <br>
<br>
Melanie <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:melanie@t-data.com"><melanie@t-data.com></a>
<br>
Apr 25 <br>
<br>
to opensim-dev <br>
I had been under the impression that the "fudge factor" on
these stats was common knowledge. <br>
Good arguments have been brought for changing them to provide
accurate metrics and I find I can't sustain an objection to
progress, especially since SL appears to have a limited shelf
life these days. <br>
Announcing this well enough should be sufficient, because I
somehow can't see how anyone using advanced monitoring tools
could not be subscribed to one of the mailing lists. <br>
<br>
Whats changed ??? <br>
When did the consensus achieved in the discussion group
become so unimportant? <br>
<br>
Now we hear that "new reporting statistics" will be
implemented to provide "Accurate reporting" ... <br>
....and that brings me to the last bit of history that
sums this whole thing up nicely.... a letter to the core
devs from teravus dated from 11/27 2009 <br>
<br>
( if you don't feel like tearing through the whole thing...
It is a call to start designing accurate performance
measurement metrics into the fabric of OpenSim rather than
relying on fudged stats that might make users "feel good "
about what is reported by the viewer. It also discusses
the absolute NEED for accuracy so performance progress can
be measured, and closes with the fact that the load tests
were ultimately FUTILE without efforts to move forward
and CORRECT the made up numbers) <br>
<br>
Teravus Ovares <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:teravus@gmail.com"><teravus@gmail.com></a>
<br>
11/27/09 <br>
<br>
to opensim-dev <br>
Hey there, <br>
<br>
A while back, we had somewhat reasonable statistics being
generated and presented to the client. They were not always
accurate, but based on what I saw, I could, pretty much pin
certain parts of the simulator as the limiting factor during
load tests. <br>
<br>
I'd say, the number 1 reason that they were semi-accurate and
not accurate.. in the past.. is because nobody ever thought
about instrumentation during the functionality design. It
was always 'tacked on later'. One example of this.. is
the current AssetCache implementation. There's no way,
currently, to know, at a glance.. how many external requests
it has open. Additionally, it will be extremely difficult to
put one in because of the way the objects are designed and
accessed. To put one in, an event needs to be added to the
IAssetService interface and each AssetCache implementation
will need an interlocked int to count how many gets and puts
it currently has open to the external data source as well as
it's own event calling schedule. Then, the IAssetService
property in Scene, (AssetService) will need an event
handler.. which updates the values in SimStatsReporter in
Scene (StatsReporter). This idea of external access resource
instrumentation should </blockquote>
re <br>
<blockquote type="cite"> ally have been built in to the design
of the AssetService. <br>
<br>
This last recent load test, there were no real statistics that
I could use to determine what the limiting factor was. Time
Dilation was pegged at 1.0.. even when the simulator was
obviously struggling. Total Frame time (MS) was -50ms even
when the simulation MS was 850ms and the Physics ms was 250ms,
so the inconsistencies made it impossible to know what part of
the simulator was struggling. Agent Updates were erratic..
sometimes high.. <br>
sometimes low when the simulator was fine and when it was
struggling. Pending Uploads and Downloads were always 0, so
there was no way to know how well the simulator was
downloading and uploading assets to and from the grid.
Packet stats were non-existant, so there was no way to know
how well the UDP handlers were faring under the load. When it
crashed, it crashed with a mono based stack trace which
pointed to out of memory errors, so the only way that you
could, scientifically, find out what the issue is.. is to
run a load test under a memory profiler. We know, that
running a public load test under a memory profiler is quite
impractical. <br>
<br>
To make something better, I need to know two things, where it
is, and where I want it to be. How can we make
OpenSimulator better if we don't have statistics that point to
where we are currently? <br>
<br>
On that note, I propose that, when designing objects for
functionality in OpenSimulator, that we also consider if the
objects should be instrumented and, what would be the best way
to go about instrumenting the objects. We should incorporate
instrumentation into the design of the objects. Some of that
instrumentation is appropriate for a client to see, some of it
might not be. Consider that, many of them should be client
facing and be included in the SimStats that get sent to the
client.. so that we can have a reasonable idea of what's
going on with a simulator at a glance. Also, in the design
of the instrumentation, we make sure that the instrumentation
is accurate and <br>
lightweight. <br>
<br>
The load test went reasonably... but, we didn't get half
of the information on the simulator that we needed to be able
to improve it. <br>
<br>
<br>
Please comment :) I look forward to hearing your
responses. <br>
<br>
Regards <br>
<br>
Teravus <br>
<br>
<br>
I guess it should be no surprise that the current call to
improve and provide ACCURATE performance statistics
reporting should be derided and dismissed. ( apologies to
those members of core who voted +1 ad helped us push
this forward) Not only are members of the communities calls
( AND contributions) to improve this area of OpenSim
ignored, so are the calls from fellow core devs about
what is needed and how it should be implemented... Forgive
me if I seem JUST A BIT CYNICAL that these corrected
stats are forthcoming... <br>
<br>
If you are going to accede to user demands, maybe you
should consider the effort some of us users put into to
getting this patch approved in the first place.... As far as
I can tell we are the ones contributing to the project by
participating in this forum... Please feel free to forward
me some names and email addresses of these clamoring
hordes of unhappy users so I can search for their outrage
in my other OpenSim related groups and invite them to
participate in future discussions here... <br>
<br>
<br>
<br>
<br>
<blockquote type="cite">On Sat, Nov 7, 2015 at 8:55 PM,
AJLDuarte <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:ajlduarte@sapo.pt"><ajlduarte@sapo.pt></a>
wrote: <br>
The fudge factor is now a configuration option on the
avinationmerge branch. <br>
It can be found in OpenSimDefaults.ini under the name
StatisticsFPSfactor, <br>
and can be set in OpenSim.ini as usual. <br>
Its default in code is the legacy value of 5.0. <br>
Current setting on file is temporary 1.0, until we decide on
a "final" <br>
default. <br>
<br>
Regards, <br>
Ubit <br>
<br>
<br>
<br>
-----Original Message----- <br>
From: <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:opensim-dev-bounces@opensimulator.org">opensim-dev-bounces@opensimulator.org</a>
<br>
[<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="mailto:opensim-dev-bounces@opensimulator.org">mailto:opensim-dev-bounces@opensimulator.org</a>]
On Behalf Of Melanie <br>
Sent: Sunday, November 08, 2015 02:35 <br>
To: <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:opensim-dev@opensimulator.org">opensim-dev@opensimulator.org</a>
<br>
Subject: Re: [Opensim-dev] Still on Sim and Phys Frames per
Second (FPS) <br>
<br>
There are too many viewers in the wild, having too many
users that are <br>
unwilling to switch or update, yet complain about "lag"
which they do not <br>
perceive, but which is indicated by a "lag meter" that is
geared to measure <br>
against constants provided by "that grid". <br>
<br>
It is a given that the data sent to viewers WILL be changed
to allow viewer <br>
features to work properly again. It is also a given that
control over this <br>
will be given to users of OpenSim, allowing them to see true
performance <br>
data instead of expected data. However, that option can't be
the default in <br>
a world where the primary use of OpenSim is to provide a
social virtual <br>
world. <br>
<br>
I had already suggested and here suggest it again to add
more data to the <br>
stats reporting that will track accurate and unfudged data,
but doesn't do <br>
so in fields currently interpreted in accordance to SL
standards by ALL <br>
mainstream viewers. <br>
<br>
This will allow viewers which become aware of the new data
to use it to <br>
provide accurate stats and, for instance, make an adaptive
"lag meter" in <br>
place of the current, constants driven one. <br>
<br>
The situation where viewer report an ERROR CONDITION because
of the desire <br>
of some to see "accurate" stats can not be sustained because
it undermines <br>
user confidence. <br>
<br>
The choices are to accede to user demands while creating a
way for viewers <br>
to get "smarter" or to live in a world where the change is
introduced at <br>
source code level by grid operators without an adequate
correct replacement <br>
stat, therefore locking in the current situation forever. <br>
<br>
Please understand that core exists to guide this project in
a way that <br>
allows it's users to work, not in a way that upholds
principles over people. <br>
<br>
- Melanie <br>
<br>
On 08/11/2015 02:53, dz wrote: <br>
<blockquote type="cite">The issue is promoting accurate
reporting of basic performance <br>
measurement statistics. ( something that has not
achieved nearly <br>
enough serious attention ) <br>
<br>
Significant money and manpower is currently being directed
at efforts <br>
to improve simulator performance. <br>
It is a simple fact that the continued funding of these
efforts <br>
relies on documenting the ACTUAL improvement against the
ACTUAL <br>
original performance characteristics. <br>
It is impossible to justify these efforts when the
reported numbers <br>
are "made up" and THAT fact is not documented except in
some <br>
obscure comment left behind in the source code. <br>
<br>
It is unfortunate that the original decision to include a
"Fudge <br>
factor multiplier" has created a pool of mis-informed
users ( including <br>
</blockquote>
myself <br>
<blockquote type="cite">and the viewer developers ) . <br>
This mistake was complicated by the fact that until very
recently <br>
there was a philosophical divide that prevented OpenSim
and viewer <br>
developers from cooperating on issues like these. <br>
This decision to "play pretend" with performance stats
effectively <br>
damaged the reporting credibility of everyone who
published these <br>
inaccurate results, It also created a rift between the
OpenSim and <br>
viewer developers over the decision to NOT discuss the
impact of <br>
</blockquote>
implementing the change. <br>
<blockquote type="cite"> The fact is, there are numerous
places in the OpenSim framework <br>
where numbers are "made up" just so that a number
appears in <br>
performance reports. That an effort is being made to
correct those <br>
sources of mis-information should be welcomed. <br>
<br>
It seems to me that the decisions made by core should be
made in <br>
favor of supporting the ongoing efforts to accurately
document and <br>
improve simulator performance. <br>
Justin realized this and lead many of the efforts to add
some measurement <br>
metrics. Even with those efforts, we still cannot
measure basic <br>
statistics like Events per Second sent to the script
engine, or tie <br>
those events to whatever script is handling them. This
makes <br>
identifying the scripts ACTUALLY responsible for
"lagging" a region <br>
impossible using the traditional TOP SCRIPTS report in
region manager <br>
</blockquote>
window. <br>
<blockquote type="cite">I would agree that a simple
solution might be to allow grid managers <br>
to add back the Fudge Factor to appease their vocal
users, but would <br>
disagree that the PROPER decision should be to continue
to report <br>
inaccurate results. It would be just as easy to
implement a <br>
multiplier in the viewer code "Lag Meter", This would
also allow <br>
the accurate reporting of statistics in the Advanced
Statistics <br>
window and administrative reporting. I believe it was
also one of <br>
the suggested resolutions put forth by the viewer
developers... It <br>
should be clear to anyone who has spent time in world
that the "lag <br>
</blockquote>
meter" is incorrect... <br>
<blockquote type="cite">You can walk, build, chat and TP
with the same level of sim <br>
performance as you could before the numbers were
changed. We've <br>
overlooked the fact that viewers have behaved
differently in OpenSim and <br>
</blockquote>
"that other grid" <br>
<blockquote type="cite"> for years. Why is it "all of a
sudden" CRITICAL that this one <br>
</blockquote>
viewer <br>
<blockquote type="cite">feature HAS to be the same? In
these days when core developers are <br>
releasing viewers, I cannot understand the urgency of
accommodating a <br>
minor feature of one viewer whose developers have already
<br>
demonstrated a willingness to work with OpenSim to tailor
a <br>
configuration to meet our needs. <br>
<br>
<br>
<br>
On Sat, Nov 7, 2015 at 1:19 PM, Melanie <a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:melanie@t-data.com"><a class="moz-txt-link-rfc2396E" href="mailto:melanie@t-data.com"><melanie@t-data.com></a></a>
wrote: <br>
<br>
<blockquote type="cite">The issue here is the so-called
"lag meter". Since removal of the <br>
multiplier, this reports all opensim regions as laggy,
without <br>
exception. Users' trust in the "lag meter" is damaging
OpenSim <br>
reputation. This is not a value that is merely for
display; the <br>
viewer uses this value for computations that are then
used to "judge" <br>
a sim to be "laggy" if it's below 35 or so fps. OpenSim
now always <br>
reports a lesser value. This is damaging and needs to be
made <br>
configurable and by default match the viewer's
expectations. <br>
<br>
- Melanie <br>
<br>
On 07/11/2015 16:38, Seth Nygard wrote: <br>
<blockquote type="cite">While I understand the arguments
surrounding the original decision <br>
to report values closely matching "the other grid",
IMHO doing so <br>
created an incorrect understanding in many users'
minds of how <br>
things work and/or behave. We are not that other grid
and should <br>
never pretend to be. Had figures been reported
correctly in the <br>
beginning then there would be no confusion now
surrounding this <br>
subject. However avoiding confusion is a poor reason
to roll back and <br>
</blockquote>
</blockquote>
</blockquote>
once again report the <br>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">artificially inflated values.
It is better to simply educate and make <br>
it clear that the value of 11fps is indeed the correct
value to <br>
expect, and is in fact the true value things always
have ran at <br>
despite what any inflated reported value said. <br>
<br>
It is true that many scripts and tools have already
been written to <br>
use the inflated values but they can all be changed
with relative <br>
ease. The viewers already have many aspects that are
different for <br>
Open Simulator so they can be changed easily as well
for new <br>
versions also with relative ease. All we need to do
as a community <br>
is establish what the correct and expected values are
and then document <br>
</blockquote>
</blockquote>
</blockquote>
and communicate them. <br>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">As a user, scripter, tool
developer, and grid manager, I for one <br>
want to see true and accurate values for any and all
metrics <br>
regardless of where they are shown or how they may be
used. I <br>
therefore am firmly against rolling back to any older
artificially <br>
</blockquote>
</blockquote>
</blockquote>
inflated values. <br>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">Regards <br>
-Seth <br>
<br>
<br>
_______________________________________________ <br>
Opensim-dev mailing list <br>
<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>
<br>
<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a>
<br>
</blockquote>
_______________________________________________ <br>
Opensim-dev mailing list <br>
<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a>
<br>
<br>
</blockquote>
<br>
<br>
_______________________________________________ <br>
Opensim-dev mailing list <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a>
<br>
</blockquote>
_______________________________________________ <br>
Opensim-dev mailing list <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a>
<br>
<br>
_______________________________________________ <br>
Opensim-dev mailing list <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a>
<br>
</blockquote>
_______________________________________________ <br>
Opensim-dev mailing list <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a>
<br>
-------------- next part -------------- <br>
An HTML attachment was scrubbed... <br>
URL:
<a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="http://opensimulator.org/pipermail/opensim-dev/attachments/20151109/594b6922/attachment.html"><http://opensimulator.org/pipermail/opensim-dev/attachments/20151109/594b6922/attachment.html></a><br>
<br>
------------------------------ <br>
<br>
_______________________________________________ <br>
Opensim-dev mailing list <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a>
<br>
<br>
<br>
End of Opensim-dev Digest, Vol 20, Issue 17 <br>
******************************************* <br>
</blockquote>
<br>
<br>
_______________________________________________ <br>
Opensim-dev mailing list <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a>
<br>
</blockquote>
<br>
<div class="moz-signature">-- <br>
---------------------<br>
<b>Terry Ford</b><br>
DigiWorldz Grid<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://digiworldz.com">http://digiworldz.com</a></div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>
<a class="moz-txt-link-freetext" href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>