'tl 'TREK SETUP INSTRUCTIONS''%'
This document describes all sorts of nifty things
before you start to muck around
with the trek source code.
Please read them carefully.
There are a number of shell files
which you may use to maintain the system.
"Prtrek" produces a copy of the source code.
It pipes its output to lpr
"Comp" compiles up to nine source modules
and leaves them in .o files.
"Compile" is the same as "comp"
except that it loads after compiling.
If stated without any arguments,
"Compall" compiles all the .c files
It redirects its output to the file "output".
To recompile the entire system,
Main.c contains a variable called "Mother".
This is initialized to the result of the
"getuid()" call for the maintainer of trek
Only Mother is allowed to set trace flags
and run the game at other than the default priority.
trek eats up a lot of system resources.
Hence, it normally runs at a very low priority.
This makes it almost impossible to play
the -pN flag sets the priority to N,
which makes it possible to debug
when the system is loaded.
The default priority is set by a #define of
which is set to 10 in the default system.
Trace information is provided
which may be useful in debugging things in the system.
If you are in a bad way for space,
comment out the #define xTRACE
This will cause the trace stuff to not occur
The version of trek released to you
is compiled with the -f flag (for no floating point)
and should work without problems on your machine.
You can edit out the -f flag
in "compile" if you have floating point hardware
so that it will take less space.
The portable C library was used
the version which we had at Berkeley
had a number of small bugs
which caused trek to do bad things at times.
(temporary insanity perhaps)
I rewrote the portable C library.
This version is much smaller than the old version
However, there are a few minor differences
which you should be aware of.
Scanf no longer ignores the noise characters "\\n",
"\\t", and space in the format string;
these characters now require a match
which is the file descriptor
If f_log is greater than zero
a copy of everything read from
is written in the file f_log.
I am getting pretty sick of playing this game.
the version which you get may have several bugs
that it is probably buggier
than some previous versions.
the game never had quite everything implemented
that was originally intended.
If you see things that look weird,
There are even some features which I have taken out
upon deciding that I didn't have the energy
to implement them correctly.
There are several things that I would like to ask of anyone
who does work on the source code.
Please let me know of any bugs which you find
and any fixes which you may have.
Other copies will probably be going out to other people later,
and it would be nice if those copies where less buggy.
I would be interested in hearing about any
enhancements of the game which you might install.
Please note that I have a distinct coding style.
I feel that it is cleaner
and easier to read than a more
especially if you end up sending tapes back to me.
This goes along with my whole belief in clean code:
I ask you to please avoid obscure code
please don't let me see it.
There are many neat things
if there were only enough space.
I have specifically not gone to seperated I/D
The main reason is that I would like future versions
SUGGESTIONS FOR THE FUTURE
If you happen to have more energy than I do,
you may want to examine the following areas.
These are things that I may get to,
but don't hold your breath.
making the portable C library work
I should have done the I/O in a more
It is my intent to rewrite the I/O
routines to bypass the portable C library entirely.
The routine "capture" is quite unclean.
First, it should have a manner of selecting Klingons
either selecting the most likely
or asking the captain (probably best).
It should either be fully implemented,
which includes adding a "board" routine
on some tapes as board.x)
which sends a boarding party to forcefully
or it should go out completely,
which is probably what I will end up doing.
the transporter will go completely.
It seems that the space may be better used
for something which more directly enhances the game.
Electronics Research Laboratory
Berkeley, California 94720