Up: The WebOOGL Home Page
Troubleshooting Your WebOOGL Installation
Are the WebOOGL scripts executable?
Make sure that the WebOOGL scripts are executable files, located in
directories in your command path. You can check this with the csh
command
which weboogl.perl to-weboogl.perl gvgeturl.perl woogl2oogl vrml2oogl geomview gvx
Use the chmod command to make them executable if necessary.
Where is Mosaic installed on your system?
At some sites Mosaic is installed as the xmosaic command.
This problem can be fixed by editing the configuration line near the
top of weboogl.perl which reads:
$mosaic_cmd = 'Mosaic';
Where is Perl installed on your system?
If your system manager hasn't installed perl on your
system, grab a copy from the
Perl Archives. Note that the
WebOOGL scripts specifically assume that Perl is located in
/usr/local/bin/perl. You can check where it really is
with the csh command
which perl
If it has been installed in another location, you should edit the very
first line of all scripts appropriately. (For example, Irix 5 comes
with Perl pre-installed, but its location is
/usr/sbin/perl.)
Are you using the right version of Perl?
Note that you need version 4.036, there is a bug in
perl5 which causes problems with the libwww-perl code! You can check
the version by typing
perl -v
Is the 2D browser responding to remote control?
Make sure that you are running at least version 2.2 of X Mosaic or
version 1.1S of Netscape for reliable remote control.
(Note: we have received one report of a copy of X Mosaic 2.4 that did
not respond to remote control commands. If you have also experienced
this problem on your system and tracked down the cause, please let us
know.)
Do you have outdated binaries in your path ?
If you had previously installed WebOOGL 1.0, make sure the new
binaries have overwritten the old ones.
Are you trapped behind a firewall?
The new WebOOGL should be capable of using proxy servers. If you are
trying to connect from behind a firewall, make sure you've set up your
2D browser to use a proxy server. (This should theoretically work but
has not been tested yet.)
Is it normal for the software to crash?
It's a known bug that nonlegitimate VRML files can wreak havoc.
Unfortunately there are a lot of files out on the Web ending in ".wrl"
that contain non-VRML constructs. The WebOOGL package relies on the
QvLib parser, which is not incredibly robust and has a distressing
tendency to crash on bad input. We might be able to provide more
graceful failure mechanisms in the future.
Are you unable to load local files?
Sometime local files (those served through the "file" protocol instead
of the "http" protocol) have the MIME content-type headers stripped.
While the software attempts to recognize OOGL and VRML files anyway,
if you're having troubles try putting the files in a place that's
recognizeable to your Web server and using the http protocol instead.
Of course, make sure your server has is configured to properly serve .wrl
and/or .oogl files by adding these lines to the mime.types file:
x-world/x-vrml wrl
object/x-oogl oogl off list tlist grp quad mesh inst bez vect
Do you have a question not answered here?
Send mail to software@geom.umn.edu
for further help.
Up: The WebOOGL Home Page
The Geometry Center Home Page
Comments to:
webmaster@www.geom.uiuc.edu
Created: Apr 24 1996 ---
Last modified: Apr 24 1996