Wow, I just had my service upgraded at hughes net to higher speed and it's still dog slow to get into the session, especially with all of the server VoIP traffic going on while the session is rolling. Since we have owl2 idle, is there some way to use it as a login server and then pass the fully-enabled client over to owl1?
Better yet, since MOST of the time it's just loading the client and modules that takes so long, is there a plan to make a standalone client or at least a persistent client, so you don't have to go through the pain of loading the same ole same ole every time?? It took me about 20-30 minutes to get connected into the group. Last night I logged in when no one else was about and I was logged-in in no time. I would hope that this could be easily fixed. Ric
-- My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
http://linuxcounter.net/user/44256.html
Ric,
I agree. Seems to me that going through the same same every time should be
removed or some kind of check to see if the server version is the same as
the last load on this client. I would love to see a client that can load
itself up and then connect to a server. Since code already exists to change
the client world display when the server content changes a reasonable flow
would be:
Start the client up with code installed on the client.
Check on version match to server. Mismatch fails or goes into code download
mode.
Client logs in to the server.
Once login complete, server starts sending current world condition.
I think the WebStart is cute but in a real world it just doesn't perform
well.
On Wed, Jun 27, 2012 at 6:47 PM, Ric Moore <wayward4...@gmail.com> wrote:
> Wow, I just had my service upgraded at hughes net to higher speed and it's
> still dog slow to get into the session, especially with all of the server
> VoIP traffic going on while the session is rolling. Since we have owl2
> idle, is there some way to use it as a login server and then pass the
> fully-enabled client over to owl1?
> Better yet, since MOST of the time it's just loading the client and
> modules that takes so long, is there a plan to make a standalone client or
> at least a persistent client, so you don't have to go through the pain of
> loading the same ole same ole every time?? It took me about 20-30 minutes
> to get connected into the group. Last night I logged in when no one else
> was about and I was logged-in in no time. I would hope that this could be
> easily fixed. Ric
I agree that improvements could be made, but keep in mind that particularly on Wednesdays when we're testing new code, the system is getting re-built, so I don't think there's a way to completely avoid a download.
> Ric,
> I agree. Seems to me that going through the same same every time > should be removed or some kind of check to see if the server version > is the same as the last load on this client. I would love to see a > client that can load itself up and then connect to a server. Since > code already exists to change the client world display when the server > content changes a reasonable flow would be:
> Start the client up with code installed on the client.
> Check on version match to server. Mismatch fails or goes into code > download mode.
> Client logs in to the server.
> Once login complete, server starts sending current world condition.
> I think the WebStart is cute but in a real world it just doesn't > perform well.
> Is that kinda what you are thinking?
> Morris
> On Wed, Jun 27, 2012 at 6:47 PM, Ric Moore <wayward4...@gmail.com > <mailto:wayward4...@gmail.com>> wrote:
> Wow, I just had my service upgraded at hughes net to higher speed
> and it's still dog slow to get into the session, especially with
> all of the server VoIP traffic going on while the session is
> rolling. Since we have owl2 idle, is there some way to use it as a
> login server and then pass the fully-enabled client over to owl1?
> Better yet, since MOST of the time it's just loading the client
> and modules that takes so long, is there a plan to make a
> standalone client or at least a persistent client, so you don't
> have to go through the pain of loading the same ole same ole every
> time?? It took me about 20-30 minutes to get connected into the
> group. Last night I logged in when no one else was about and I was
> logged-in in no time. I would hope that this could be easily
> fixed. Ric
> -- > My father, Victor Moore (Vic) used to say:
> "There are two Great Sins in the world...
> ..the Sin of Ignorance, and the Sin of Stupidity.
> Only the former may be overcome." R.I.P. Dad.
> http://linuxcounter.net/user/44256.html
> Ric,
> I agree. Seems to me that going through the same same every time should
> be removed or some kind of check to see if the server version is the
> same as the last load on this client. I would love to see a client that
> can load itself up and then connect to a server. Since code already
> exists to change the client world display when the server content
> changes a reasonable flow would be:
> Start the client up with code installed on the client.
> Check on version match to server. Mismatch fails or goes into code
> download mode.
> Client logs in to the server.
> Once login complete, server starts sending current world condition.
> I think the WebStart is cute but in a real world it just doesn't perform
> well.
> Is that kinda what you are thinking?
Exactly. A standalone client that caches modules, maybe by sitename to an individual cache directory? Maybe some of the graphics could be cached as well?? Then updated while you are already there logged in?
That's kinda like how SL works. You download one honking big client, once. Then it is updated as you login and features there are cached for the next time you login. It took me almost 30 minutes to get into the conference today. But, I kept getting static over the USB audio once I did. So, I figured something was wacko system-wise and in need of a reboot. I never got back in again. Webstart is neat, but it could just as easily point to an application on the system. If it was just a standalone that I could start, and it would cache stuff in directories, then the OWL1 server wouldn't be burdened with the overhead of creating the clients wishing to login, wasting bandwidth and cpu that could be dedicated to more clients at once.
I even upped my Sat service to the next tier and even then I couldn't knock successfully at the door with 2X my old speed. The night before I got in with minimal strain. So, I tried owl2 and got right in, ~comparatively~ speaking. OWL1 was just congested?
Would this be difficult to do? I'm glad I wasn't trying to show it off to someone else.
-- My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
http://linuxcounter.net/user/44256.html
> I agree that improvements could be made, but keep in mind that
> particularly on Wednesdays when we're testing new code, the system is
> getting re-built, so I don't think there's a way to completely avoid a
> download.
I agree, there will always be SOME download, but the entire process over and over again is unnecessary and has to be a strain on the server if 3-4 users are consuming all that bandwidth just trying to login with all of those files streaming every time. Download once, run many times, until an update is needed. Just installing a cache would be a tremendous boost. :) Ric
-- My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
http://linuxcounter.net/user/44256.html
There's surprisingly a lot involved in a wonderland client. The nice
thing about webstart is that it will detect your OS version and
provide the correct libraries you need all in one fell swoop. For the
sake of argument, let's say we release a standalone client tomorrow.
We would have to roll out a separate client for each platform and
architecture: OS X, Win x86, Win x84, Linux x86, Linux x84. With
releases happening about every month or so, that would be a new 5
clients every month in addition to a server. Further, we'll probably
want to keep track of each version per month as well. Tech support
would probably be a nightmare with people wondering which is the right
client for them...getting mixed up with architecture and release
versions and client vs server downloads.
Don't get me wrong, I love the idea of a standalone client, I think it
makes great sense and I've been a huge advocator for such a feature
for quite some time. All I'm saying is caveat emptor, if tech support
is already a pain now...it can get a lot worse.
On Thu, Jun 28, 2012 at 2:25 AM, Ric Moore <wayward4...@gmail.com> wrote:
> On 06/27/2012 10:27 PM, Nicole Yankelovich wrote:
>> I agree that improvements could be made, but keep in mind that
>> particularly on Wednesdays when we're testing new code, the system is
>> getting re-built, so I don't think there's a way to completely avoid a
>> download.
> I agree, there will always be SOME download, but the entire process over and
> over again is unnecessary and has to be a strain on the server if 3-4 users
> are consuming all that bandwidth just trying to login with all of those
> files streaming every time. Download once, run many times, until an update
> is needed. Just installing a cache would be a tremendous boost. :) Ric
> --
> My father, Victor Moore (Vic) used to say:
> "There are two Great Sins in the world...
> ..the Sin of Ignorance, and the Sin of Stupidity.
> Only the former may be overcome." R.I.P. Dad.
> http://linuxcounter.net/user/44256.html
just to add a tiny bit to jW's; taking 30 minutes to go into a server
is not something that can be fixed with a bit of caching(which as far
as i know it's already in place, for better or worse). There's
obviously something else going on, when the others can log in in a
couple of minutes (or less) even if there are 10 or so other people in
the server already.
cheers,
José
On 28 June 2012 13:59, jagwire <pympno...@gmail.com> wrote:
> There's surprisingly a lot involved in a wonderland client. The nice
> thing about webstart is that it will detect your OS version and
> provide the correct libraries you need all in one fell swoop. For the
> sake of argument, let's say we release a standalone client tomorrow.
> We would have to roll out a separate client for each platform and
> architecture: OS X, Win x86, Win x84, Linux x86, Linux x84. With
> releases happening about every month or so, that would be a new 5
> clients every month in addition to a server. Further, we'll probably
> want to keep track of each version per month as well. Tech support
> would probably be a nightmare with people wondering which is the right
> client for them...getting mixed up with architecture and release
> versions and client vs server downloads.
> Don't get me wrong, I love the idea of a standalone client, I think it
> makes great sense and I've been a huge advocator for such a feature
> for quite some time. All I'm saying is caveat emptor, if tech support
> is already a pain now...it can get a lot worse.
> regards,
> -jW
> On Thu, Jun 28, 2012 at 2:25 AM, Ric Moore <wayward4...@gmail.com> wrote:
>> On 06/27/2012 10:27 PM, Nicole Yankelovich wrote:
>>> I agree that improvements could be made, but keep in mind that
>>> particularly on Wednesdays when we're testing new code, the system is
>>> getting re-built, so I don't think there's a way to completely avoid a
>>> download.
>> I agree, there will always be SOME download, but the entire process over and
>> over again is unnecessary and has to be a strain on the server if 3-4 users
>> are consuming all that bandwidth just trying to login with all of those
>> files streaming every time. Download once, run many times, until an update
>> is needed. Just installing a cache would be a tremendous boost. :) Ric
>> --
>> My father, Victor Moore (Vic) used to say:
>> "There are two Great Sins in the world...
>> ..the Sin of Ignorance, and the Sin of Stupidity.
>> Only the former may be overcome." R.I.P. Dad.
>> http://linuxcounter.net/user/44256.html
> There's surprisingly a lot involved in a wonderland client. The nice
> thing about webstart is that it will detect your OS version and
> provide the correct libraries you need all in one fell swoop. For the
> sake of argument, let's say we release a standalone client tomorrow.
> We would have to roll out a separate client for each platform and
> architecture: OS X, Win x86, Win x84, Linux x86, Linux x84. With
> releases happening about every month or so, that would be a new 5
> clients every month in addition to a server. Further, we'll probably
> want to keep track of each version per month as well. Tech support
> would probably be a nightmare with people wondering which is the right
> client for them...getting mixed up with architecture and release
> versions and client vs server downloads.
> Don't get me wrong, I love the idea of a standalone client, I think it
> makes great sense and I've been a huge advocator for such a feature
> for quite some time. All I'm saying is caveat emptor, if tech support
> is already a pain now...it can get a lot worse.
Can a permanent cache be used?? At least this would stop the endless downloading of the same thing, especially when you had just successfully logged in minutes before and have to re-download the entire lot. Me, my service is metered. I have to pay after i exceed download limits. I may not be alone in that situation. Ric
-- My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
http://linuxcounter.net/user/44256.html
> just to add a tiny bit to jW's; taking 30 minutes to go into a server
> is not something that can be fixed with a bit of caching(which as far
> as i know it's already in place, for better or worse). There's
> obviously something else going on, when the others can log in in a
> couple of minutes (or less) even if there are 10 or so other people in
> the server already.
Which is why I tested that, and got right into OWL2 after I couldn't make a connect with owl1 the second time. Same same, except one was heavily in use and the other wasn't. There can't be much caching going on if I had just successfully logged into owl1, exited and then had to re-download the entire lot 10 minutes later. I watched that going on like a hawk, pulling on my chin going "Yup! Yup! Wot! Dere it is!" That's the part that needs remedy. If there is some sort of switch I can throw within Java to enable ALL caching on my end, I'd like to know how. Then we should include it in the HOW-TO's.
Thanks! Ric
-- My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
http://linuxcounter.net/user/44256.html
Ric,
You really should experiment with using the local start client capability
that currently exists. If you are running a source release, move to the
wonderland/core directory and enter 'ant run'. The client starts right up
and in my experiments doesn't go through the downloads. I have set up my
'run-client.properties' file like below to make the startup more automatic.
I am also running similar OWL versions but not exactly the same. As I get
more time I will experiment some more.
I have previously entered the server world using webstart so that probably
helps it run.
# Set the username and fullname defaults in the login dialog
auth.username=morris
auth.fullname=Users Name
# The level of detail of the avatar; low, high
avatar.detail=high
# Desired frame rate for client
wonderland.client.fps = 30
# Control the size of the client window. The form should be WIDTHxHEIGHT
(ie 640x480) or fullscreen
wonderland.client.windowSize = 1024x768
# Set the user directory for the client, useful for running multiple
clients on one machine
# An easy way to use this setting is to copy this file to create a number of
# users and use ant -Drun-client.properties.file=<property file> run to
launch
# clients for each property file
#wonderland.user.dir=/tmp/.wltest
On Fri, Jun 29, 2012 at 1:52 AM, Ric Moore <wayward4...@gmail.com> wrote:
> On 06/28/2012 09:55 AM, Jos Flores wrote:
>> just to add a tiny bit to jW's; taking 30 minutes to go into a server
>> is not something that can be fixed with a bit of caching(which as far
>> as i know it's already in place, for better or worse). There's
>> obviously something else going on, when the others can log in in a
>> couple of minutes (or less) even if there are 10 or so other people in
>> the server already.
> Which is why I tested that, and got right into OWL2 after I couldn't make
> a connect with owl1 the second time. Same same, except one was heavily in
> use and the other wasn't. There can't be much caching going on if I had
> just successfully logged into owl1, exited and then had to re-download the
> entire lot 10 minutes later. I watched that going on like a hawk, pulling
> on my chin going "Yup! Yup! Wot! Dere it is!" That's the part that needs
> remedy. If there is some sort of switch I can throw within Java to enable
> ALL caching on my end, I'd like to know how. Then we should include it in
> the HOW-TO's.
Ric,
Also, since there is a property in the properties file that allows you to
set the user directory, I suspect that you could save the cache contents as
of the last run by using a different user directory for each server.
On Fri, Jun 29, 2012 at 8:19 AM, Morris Ford <morrishf...@gmail.com> wrote:
> Ric,
> You really should experiment with using the local start client capability
> that currently exists. If you are running a source release, move to the
> wonderland/core directory and enter 'ant run'. The client starts right up
> and in my experiments doesn't go through the downloads. I have set up my
> 'run-client.properties' file like below to make the startup more automatic.
> I am also running similar OWL versions but not exactly the same. As I get
> more time I will experiment some more.
> I have previously entered the server world using webstart so that probably
> helps it run.
> # Control the size of the client window. The form should be WIDTHxHEIGHT
> (ie 640x480) or fullscreen
> wonderland.client.windowSize = 1024x768
> # Set the user directory for the client, useful for running multiple
> clients on one machine
> # An easy way to use this setting is to copy this file to create a number
> of
> # users and use ant -Drun-client.properties.file=<property file> run to
> launch
> # clients for each property file
> #wonderland.user.dir=/tmp/.wltest
> On Fri, Jun 29, 2012 at 1:52 AM, Ric Moore <wayward4...@gmail.com> wrote:
>> On 06/28/2012 09:55 AM, Jos Flores wrote:
>>> just to add a tiny bit to jW's; taking 30 minutes to go into a server
>>> is not something that can be fixed with a bit of caching(which as far
>>> as i know it's already in place, for better or worse). There's
>>> obviously something else going on, when the others can log in in a
>>> couple of minutes (or less) even if there are 10 or so other people in
>>> the server already.
>> Which is why I tested that, and got right into OWL2 after I couldn't make
>> a connect with owl1 the second time. Same same, except one was heavily in
>> use and the other wasn't. There can't be much caching going on if I had
>> just successfully logged into owl1, exited and then had to re-download the
>> entire lot 10 minutes later. I watched that going on like a hawk, pulling
>> on my chin going "Yup! Yup! Wot! Dere it is!" That's the part that needs
>> remedy. If there is some sort of switch I can throw within Java to enable
>> ALL caching on my end, I'd like to know how. Then we should include it in
>> the HOW-TO's.
> Ric,
> You really should experiment with using the local start client
> capability that currently exists. If you are running a source release,
> move to the wonderland/core directory and enter 'ant run'. The client
> starts right up and in my experiments doesn't go through the downloads.
> I have set up my 'run-client.properties' file like below to make the
> startup more automatic. I am also running similar OWL versions but not
> exactly the same. As I get more time I will experiment some more.
> I have previously entered the server world using webstart so that
> probably helps it run.
Thanks! Hopefully I can just make a desktop link to there and a click-to to make it happen. That would be sweet!!! Thanks again. Ric
-- My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
http://linuxcounter.net/user/44256.html
> Ric,
> Also, since there is a property in the properties file that allows you
> to set the user directory, I suspect that you could save the cache
> contents as of the last run by using a different user directory for each
> server.
Great! I wrote about that, and it might not be such a large leap to eventually have something like that become a "client-cache module"? If I'm running my server here, and my client connects, then THAT bunch of downloading could get saved by my hostname for instance? Then I'd have .wonderland/0.5-dev/cache/owl1
.wonderland/0.5-dev/cache/owl2
.wonderland/0.5-dev/cache/iam
...etc, for every wonderland I visit. We're almost there now. So, something along that line hopefully will become considered to make it a "formal" behavior? The fun part would be to have standard modules be as they now are, only the different bits be in the hostname directories. That would really speed up things. Then, being network challenged with bandwidth, if I want to attend a conference in Spain, then I would login the night before, have myself fully loaded, then login the next day ...right straight in, unless something was changed at the last minute. Then all I would have is just that one changed module to download. That would save some cpu cycles and bandwidth demands on the server as well?? I hope we think on this one!
Wow, thanks again for all of your service, Ric--
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
http://linuxcounter.net/user/44256.html
