Date: Thu, 25 Jan 90 13:07:18
From: Bill Morrison (Coordinator) [email removed]
Reply-To: Traveller System Generation [email removed]
Subject: Traveller System Generation Group Digest V1 #1
To: [email removed]
Traveller System Generation Thu, 25 Jan 90 Volume 2: Issue:1
Today's Topics:
Bad news, and worse news...
DESIGN_SPEC
Galactic scale
Member's address
Mail from Joshua
Traveller Computer Programs
TRAV Sys Gen Digest
***************************************************************************
** STAR SYSTEM DIGEST: star system generation, storage, and display. **
** All followups on this topic should be sent to [email removed] **
** They will be edited for clarity and resent to the Traveller Mailing. **
***************************************************************************
***************************************************************************
** Administrivia: Well a new year has started and I'm already late **
** the next edition of the digest out. This issue contains**
** the BUILD 1 design specification of our system **
** generation program -- our thanks to those who directly **
** and indirectly put in all of the hard work. **
** **
** Since we've been having some problems with the group's **
** internal mail distribution, I'll be sending out a **
** revised mail alias supplied by James Perkins. This **
** alias is the one he uses from the TML distribution so **
** it is guarenteed to be more correct than the one I **
** created. **
** **
** I also want to thank Dan Corrin for all the work he **
** put in on compiling the survey results. **
** **
** The message "Galactic scale" was previously posted **
** to the TML, but is relevant to the generation of star **
** maps. Since it was posted to the TML, it is re-posted **
** without the explicit permission of the poster. **
** **
** The message "Mail from Joshua" contains some random **
** number and probability table look-up routines. More **
** detailed information on the table handling routines **
** can be found in the addendum message to this volume. **
** **
** The V02N01 addendum (a seperate mail message) contains **
** information on a hex mapping algorithm, the results of **
** the questionaire, and information on table handling **
** routines. **
** **
** Lastly, the machine I'm on still maintains its **
** connection to the world, but it is on a day-by-day **
** basis. So, I may not be able to continue as group **
** coordinator much longer. I'll get onr weeks warning so **
** I'll let the TML and the star systems group know as **
** soon as I do. If the next project I'm on has its **
** machine on the Internet, I'll be glad to continue. **
** **
** -- Bill Morrison **
***************************************************************************
- --------------------------------------------------------------------------------
Date: Tue, 12 Dec 89 08:48:28 EST
From: [email removed] (William B. Morrison)
Subject: Re: Bad news, and worse news...
Actually, I'm glad to see people volunteering in the event that I cannot
continue as moderator. Since everyone is mentioning scripts for doing
things, I have a copy of the "digestify" program used by various
newsgroups (sun-spots, uunet groups, etc) to automatically create digests
from articles saved in a mailbox. Since I'm not (read can't) use the alias
mail feature at our site to automatically reflect mail, it's the only
automation I really need.
BTW, I still have no further info on to what connectivity I'll have
come Jan 1, but I'll keep you all posted.
- --Bill
- --------------------------------------------------------------------
Date: Tue Dec 5 14:35:30 1989
From: [email removed] (Richard Johnson)
To: [email removed]
Subject: DESIGN_SPEC
Well, I guess I'll fire an opening salvo. Here's a proposal for
"build one", version 0.0
THIS IS REALLY LONG!!!!! ("Danger, Will Robinson...")
I am primarily going to talk about the interface, and user
considerations (that's my job, and I don't what I'll do to
the real designers with this..) As much as possible, I have
tried to interpret the results of Dan's questionnaire and use
them here.
- -----------------General Considerations--------------------------
1. Build one produces subsector maps, solar system maps, or
sector maps, in Megatraveller format.
Build two is another program that adds more mapping capability.
Build three etc. add more functionality, compatability and data
base usage of the star system files generated.
2. The primary output is postscript; letter-sized paper.
3. Secondary output is an ASCII file that can be used for data
manipulation (data-base type search/sort, etc.) as well as for
mapping.
4. The computer terminal is used to control the program, not as
an output device (except for preview).
5. Program control (terminal stuff again) should be to VT-type
terminals ("stdio" ?). This gives the greatest compatability,
and allows dial-in users.
- ------------------Output Map Considerations--------------------------
Subsector Maps------------------------------------
The "standard" sized (see MT ref'smanual, page 20) hex map
of a subsector (8 X 10 hexes) has the following characteristics:
It is half a page.
We will use a whole (8.5 X 11- inch) page (just to
start an argument).
Because we will generate more detailed world information, and
because we will use the computer to search and sort through
this more detailed data for us, we don't need to have a summary
of the sector's worlds right next to the map.
If we print the map "landscape" (sideways on the page -
"Portrait" is printing on a page with the narrow side of the
paper at the top), then we have half a page for notes and
information that is more textual than visual. Conversely, I
have used full-page maps, with larger hexes and prefer them
even though it means the world information is elsewhere. (Of
course, all of the more useful, more detailed world information
is elsewhere anyway.) Probably we should use of the page for
map; we'll need room for a key and some of the more imiportant
notes.
It has numbered hexes; I'm not sure we need to to this.
Hexes are shown. We should show hexes.
It has the name of each world at the bottom of that world's hex.
We should do this also.
We can play with type sizes and faces (this is PostScript)
till we find one suitable. When you photocopy small letters,
a medium sans-serif face, like Helvetica, copies the best.
It has the starport type identified. We should, too.
This is a single bold-face letter. I suspect some worlds may
have more than one starport. Do we put simply the best one up?
Do we somehow indicate > 1 class A starports?
Types of military establishments are shown. We should show these
too.
This is done by hollow or filled icons, a star for a navy base
(I suspect we could use a hollow star for a local navy base, a
filled one for "Imperial" navy (whatever that is now.), a
triangle for scout bases and stations, and a square for naval
depots. I believe judicial selection of a typeface will give
us these as characters, so we don't have to "draw" them on the
map.
Type of primary world is indicated. We should show stars, instead.
(another argument?)
Hollow or filled circles, or other appropriate images, are used
for the world, to indicate it's type. I think, from our
discussions and from the responses, we'd rather see some indi-
cation of the star in that location, and whether it is single
or multiple. If you're like me, you color in these circles by
hand to indicate the color of the star; it makes a very pretty
map.
In general, for subsector maps, we should do pretty much what has gone
before, only use up a whole page for the map. The actual file structure
we choose to do this, you experienced programmers can decide; just try
to pick one that we use later for other things (like data base queries).
Sector Maps-----------------------------------------------
For Sector maps, the official method is to have subsectors named
by a single letter. The naming is alphabetic (A,B,C,...P) and in
the same order as the way we normally read. I don't know which way
is "up" though; I THINK it's spinward.
Sector maps should have less detail. They should show only the
following information:
Class A starports
A-to-A trade lanes
MAJOR X-boat routes
Major military bases
Subsector Capitols
significant political boundaries
Sector maps should also be on a full sheet of 8.5 X 11 inch paper, but
should not have the hexes drawn on it (it would get cluttered).
Solar System Maps--------------------------------------------------
I think we should save the output side of this until later. There
should be a lot of detail that we need to consider with respect to
later builds and functionality. (i.e. I didn't do this yet)
Other Maps---------------------------------------------------------
See above...
- ------------------------Interface Considerations---------------------------
Most of the general thoughts about the interface, I listed in the
overall design thoughts. We should try to steer clear of hardware
dependency on initial builds. (I think we could maybe do this
modularly so that the machine-specific interfaces could be "hung
on" later - any thoughts?) Thus we should:
Limit output to ASCII, printable characters (and the space)
Use line oriented graphics (e.g. 24 lines, 80 columns)
Use only one color (well, one bit plane)
With this in mind, I propose we lay out the screen something like the
following example: (I hope you've got 80 columns)
- --------------------------------------------------------------------------------
| | |
| 60 columns X 11 ? lines | 20 columns X |
| for text output, messages, etc. | 12 lines for |
| | sample maps |
| | and titles |
| | |
| | |
| | |
| | |
| | |
| -----map title-------
| | |
| | 20 columns |
| | X 12 rows for |
| | Menus |
- ----------------------------a line-------------------------| |
| | |
| 60 columns by 8 ? lines for I/O | |
| and keyboard entry operrations | |
| (command line etc.) | |
| | |
- -----------------------------i think I counted about right----------------
I envision one line of the screen indicating what command is being
used, and a second that tells the user exactly what to do next
(i.e. "Create Base - Select and World and then make a menu selection.")
The map area should be continuously updated while the user is
interacting with the program. When in mapping mode, the user can
select worlds from it (can we do this?), and when n DB mode, it can
highlight the world being edited.
The user of the program will need to be able to issue the
following commands: (feel free to add some if you see the need)
Project Commands:
Create DB file (=city, world, solar system, subsector, sector)
Create map file (from DB file or random)
Delete file
Rename file
Edit map file
Edit DB file
Save file
Print file
Edit Map Commands: (notice that these WILL alter the DB file, too)
Select (move cursor (somehow) to desired spot on map display)
Unselect (escape?)
Make X-boat Route (select end points, or many points...)
Make Trade Route (ibid)
Make Political/Military Boundary
Edit World (select world --> enter DB file)
(indicate that mode is changing)
Add Base/Starport (submenu when star selected?)
Navy
Scout
Depot
Starport
Delete Base
Delete Starport
Delete World
Delete Trade Route
Delete X-boat Route
Delete Political/Military Boundary
Enter Edit DB File Mode
Exit to Main Menu level
Save file
Edit DB File Commands:
Open file
Save file
Move up one level (I think the DB is logically heirarchical?)
Move down one level
Add a record
Delete a record
Modify a record
Scan records
Enter Map Edit mode
Exit to Main menu level
Save file
Save record
As you can see, there are three basic modes of operation. The program
comes up in the Main mode, which offers commands to directly operate
the program.
The second mode is primarily for "touching up" maps; for making sure
that routes and boundaries are correct, etc.
I picture the Edit DB file command set being intitally in a "scan
records" mode. In this mode, a list of records available at that level
is displayed, and the user selects the one to play with.
- ---------------------------Command Descriptions------------------------
Project Commands:
These are available when the program first comes up. This is the
Main Menu level.
Set Path default Establishes a pathname prefix to attach to
all file names. For example, setting a
path default of "/usr/rdj/trav/" (we might
have to watch out on this when converting
to other systems) will cause the program
to look in this directory for all files and
to write files here, too. equivalent to
the UNIX "cd" or the VMS "set def" command.
Parms: pathname
Create DB file I'm not sure if this should be a DB "file" or
a DB "record". The structrue seems logically
Heirarchical (city -> world -> solar system ->
subsector -> sector).
This is ALWAYS randomly generated.
Parms: MT-rules || SpaceOpera || other
densly || sparsely populated
black holes on || off
nebulae on || off
TL limits (user-supplied)
other?
When we get this defined, we'll have a way to
transfer universes around.
Create map file The map needs to use the information in a DB file
to get itself drawn. This is the file that is
converted to the chosen output style by the
"print map" command and sent to the output device.
This file needs to still be in an editable form
so that mode two will work.
Parms: DB-filename
Delete file Removes a specified file from the user's disk.
Parms: filename
Rename file Changes the name or location of a specified
user file. Origin and destination names are
required. Rename should work with entire DB
files, but not with individual records.
Parms: source_filename
dest_filename
Edit map file Changes the program to mode 2, for editing
an already created map file.
Parms: filename
Edit DB file Changes the program to mode 3, for editing
an already created data base file.
Parms: filename
Save file Saves whichever file is open under the same
name (and path) in which it was opened.
Parms: none
Print DB file Copies a specified data base file to a specified
output device, in ascii format. (use a filter
to TROFF it, if you want).
Parms: filename
printer_id || terminal_id
Print map file Copies a specified map file to a specified output
device, in a specified format.
Parms: filename
printer_id || terminal_id
ascii || PostScript || other
Edit Map Commands: {Mode 2}
(notice that these WILL NOT also alter the DB file)
Set Path default Establishes a pathname prefix to attach to
all file names. For example, setting a
path default of "/usr/rdj/trav/" (we might
have to watch out on this when converting
to other systems) will cause the program
to look in this directory for all files and
to write files here, too. equivalent to
the UNIX "cd" or the VMS "set def" command.
Parms: pathname
Open a map file Opens a file from the default directory with
a (.map?) suffix. Displays a list of available
files. The user scrolls up and down this list
until the proper file is highlighted, then
presses <return>.
Parms: filename indicated by highlighted line
Select Move the cursor (somehow) to the desired spot
on the map display and indicate (somehow) that
you're there.
Output: When selected, bolds or flashes the
indicated location on the map preview.
Parms: cursor location
all selected locations (?)
Unselect Move the cursor (somehow) to the desired spot
on the map display and indicate (somehow) that
you're there.
Output: When unselected, returns location of
the map preview to normal text.
Parms: cursor location
all selected locations (?)
Make X-boat Route User selects a series of points and (somehow)
indicates that the route is done or continues
off the map.
Parms: cursor location
selected locations
Make Trade Route (ibid) User selects a series of points and (somehow)
indicates that the route is done or continues
off the map.
Output: none to screen- sets flags as appropriate
within the program to create the right
output on paper.
Parms: cursor location
selected locations
Make Political/ User selects a series of points and (somehow)
Military Boundary indicates that the route is done or continues
off the map.
Output: none to screen- sets flags as appropriate
within the program to create the right
output on paper.
Parms: cursor location
selected locations
Edit World Changes the program to mode 3 and brings up the
DB editor on the appropriate file and record for
the indicated world. The user selects a world in
the normal way.
Output: Changes program to mode 3
tells program which file and record to
edit tells user the mode is changing
Parms: cursor location
Delete Trade Route
Delete X-boat Route
Delete Political/Military Boundary
These three all work the same. The user selects
a series of points and (somehow) indicates that
the route is done or continues off the map.
Output: none to screen- sets flags as appropriate
within the program to create the right
output on paper.
Parms: cursor location
selected locations
Enter Edit DB Mode Changes the program to mode 3. Brings up the DB
editor with the DB file of the same name as the
map file being worked on.
Output: Changes program to mode 3
tells program which file to edit
tells user the mode is changing
saves map file being worked on as
"fubar.tmp?"
Parms: name of file being worked on
Exit to Main level Changes the program to mode one.
Output: changes program mode
tells user the mode is changing
Parms: none
Save file writes the active file to the default directory
with the same name in which it was opened.
Parms: none
Edit DB File Commands: {Mode 3}
(I think this is build 2 or three stuff, and I don't have it
well defined yet. RDJ)
Set Path default Establishes a pathname prefix to attach to
all file names. For example, setting a
path default of "/usr/rdj/trav/" (we might
have to watch out on this when converting
to other systems) will cause the program
to look in this directory for all files and
to write files here, too. equivalent to
the UNIX "cd" or the VMS "set def" command.
Parms: pathname
Open a DB file Opens a DB file from the default directory with
a (.DB?) suffix. Displays a list of available
files. The user scrolls up and down this list
until the proper file is highlighted, then
presses <return>.
Output: Once the file is open, the top-level
records within that file are displayed.
Parms: filename indicated by highlighted line
Save file Writes the active file to the default directory
using the same name with which it was opened.
Parms: none
Move up one level (I think the DB is logically heirarchical?)
Moves the selector display up one level of the
DB heirarchy - i.e. if the user has just closed
a world file, he can "move up" to subsector level
to see more worlds to conquer.
Parms/output - unknown
Move down one level See above
Add a record Creates a new record for the DB
Delete a record Removes a DB record and re-aligns the pointers
Modify a record Wow! finally some real editing!
Maybe we should require the use of a text editor?
Scan records This is the "normal" mode. It displays the names
of records in the text output field.
Enter Map Edit mode Changes to mode 2.
Exit to Main level Changes to mode 1
Save file Writes the open file to the default directory.
Close record saves the changes made in the DB record.
- --------------------------------------------------------------------
In case you hadn't noticed by now, I'm still out to lunch about
the record and data base editing capability of the program. I'd
like some feedback here.
It would be nice to name the program, too.
Later
Richard Johnson
- --------------------------------------------------------------------
Date: Thu, 14 Dec 89 10:11:45 PDT
From: Richard The Writer [email removed]
To: Traveller Mailing List [email removed]
Subject: Galactic scale
I found this in sci.physics and thought it would be of *enormous*
interest, especially to those who are contemplating maps...
Richard
- --------------------------------
>Subject: Relative distances and sizes in the Universe.
Several weeks ago I posted a request for slide sets comparing the
relative distances in the solar system and the other stars: It would
seem that slide sets of this scale system are rather hard to come by.
I sent out a request to several other computer networks, along with
calling a number of planetariums, museum stores, and searched through
various scientific catalogues, all without significant result.
I was able to use my resources and gather some information
from several friends on various types of relative celestial scales,
and have come up with some relevant information.
The first selection depicts the solar system on a major league
baseball field from E. C. Slipher's "Planet" section of THE WORLD BOOK
ENCYCLOPEDIA P, VOLUME 15, Field Enterprises Educational Corporation,
Chicago, Illinois, 1964. If the Sun were the size of a United States
half-dollar (fifty cents) on home plate, the planet Mercury would be
120 centimeters (four feet) away, Venus would be 225 centimeters
(7.5 feet) away, Earth would be 315 centimeters (10.5 feet) distant,
Mars would be 480 centimeters (sixteen feet) away, Jupiter would be
1,650 centimeters (55 feet) from the Sun (at the pitcher's mound),
Saturn would be 3,030 centimeters (101 feet) away (near second base,
and the last planet in the infield), Uranus would be 6,075 centimeters
(202.5 feet) away, Neptune would be 9,540 centimeters (318 feet) away,
and Pluto would be 12,615 centimeters (420.5 feet) distant from the
Sun, deep in the outfield.
To compare planetary diameters, if the Sun were the size of an
average beachball, then Jupiter would be a golf ball, Saturn a Ping-
Pong ball, Uranus and Neptune marbles, Mercury and Pluto pinheads,
and Venus, Earth, and Mars would be about half the size of tackheads.
The next comparison scale comes from the "Life on Other Worlds"
section of Carl Sagan's PLANETS, LIFE Science Library, 1966. This
one depicts the solar system on a map of Europe and Africa, with the
average distance between the Sun and Earth, 150 million kilometers
(93 million miles) - also known as one Astronomical Unit (A.U.) -
now equaling 240 kilometers (150 miles). If the Sun were situated
in Norway, Saturn would orbit just south of Italy, and Pluto would
be 10,400 kilometers (6,500 miles) away along the Cape of Good Hope
in South Africa.
The next source on various celestial scales comes from THE
STARFLIGHT HANDBOOK: A PIONEER'S GUIDE TO INTERSTELLAR TRAVEL, by
Eugene F. Mallove and Gregory L. Matloff (John Wiley & Sons, Inc., New
York, 1989, ISBN 0-471-61912-4, hardcover), which gives the following
description on page 5: If the Sun were the size of a one-centimeter
(0.4-inch) marble, then Earth would be 0.1 millimeters (0.004 inches)
in diameter and one meter (39.37 inches) from the Sun. The planet
Pluto would orbit 42 meters (139 feet) from the Sun, and Proxima
Centauri - the Sun's nearest stellar neighbor - would be 292
kilometers (175 miles) away.
The next two books listed are both authored by Neil McAleer.
The first is THE COSMIC MIND-BOGGLING BOOK (Warner Books, Inc.,
New York, 1982, ISBN 0-446-37932-8, paperback). On the front cover
of the book, the following comparison is made (one of my favorites,
from an aesthetic point of view): If the solar system out to the
orbit of Pluto could fit in a coffee cup, the Milky Way Galaxy
would be the size of the North American continent.
On page xiii - If you had a specially-designed automobile
which could handle the rigors of spaceflight, it would take you
201 billion years to "drive" from the Sun to the center of the
Milky Way Galaxy at 161 kilometers per hour (100 miles per hour).
Also, if the solar system were 2.54 centimeters (one inch) across,
the Milky Way Galaxy would be 161,000 kilometers (100,000 miles) wide.
On pages 3-4 - If the Sun were the size of a sixty-centimeter
(two-foot) beachball, Earth would be the size of a pea and 6,450
centimeters (215 feet) away. The planet Jupiter would be a large
orange 31,680 centimeters (1,056 feet) distant from the Sun.
On pages 12-13 - If the Sun were a 14-centimeter (5-inch) orange,
Earth would be a sesame seed fifteen meters (49 feet) away. Pluto
would be the size of a grain of millet six hundred meters (3,400
feet) away, and the star Alpha Centauri would be four thousand
kilometers (2,500 miles) from the Sun.
On page 83 - If you could fly a specially modified Boeing 747
jetliner through space at 965 kilometers per hour (six hundred miles
per hour), it would take you 1,903 years to fly from the orbit of
the planet Uranus out to the orbit of Neptune.
On page 128 - If the Sun were a basketball in New York City,
then Alpha Centauri would be another basketball eight thousand
kilometers (five thousand miles) away in Honolulu, Hawaii.
On page 129 - If you traveled at the speed which the APOLLO
spacecraft used in an average six-day round-trip journey to Earth's
Moon (approximately 40,000 kilometers per hour/25,000 miles per hour),
it would take you 850,000 years to reach Alpha Centauri. By contrast,
the faster PIONEER 10 and 11 and VOYAGER 1 and 2 Jovian probes will
reach that distance (4.3 light years) in only eighty thousand years.
On page 161 - If you used a starship traveling at one-tenth the
speed of light (300,000 kilometers per second/186,000 miles per second)
to reach the farthest star in the Milky Way Galaxy, the ship would
take 800,000 years to reach it from the Sun. If one Astronomical
Unit (A.U.) - the distance between the Sun and Earth, which is
roughly 150 million kilometers/93 million miles - were reduced to
2.54 centimeters (one inch), then that farthest star would be
127,000 kilometers (79,000 miles) away.
The next selection is from the other Neil McAleer book, THE
MIND-BOGGLING UNIVERSE (Doubleday & Co. Inc., Garden City, New
York, 1987, ISBN 0-385-23039-7, paperback):
On pages 10-11 - If the solar system out to Pluto were 2.54
centimeters (one inch) in diameter, then the center of the Milky
Way Galaxy would be 609 kilometers (379 miles) away. Also, to
walk one A.U. at five kilometers per hour (three miles per hour)
would take 3,500 years. To drive one light year at 88 kilometers
per hour (55 miles per hour) would take 12.2 million years.
On page 15 - The Milky Way Galaxy's longest spiral arm of gas,
dust, and stars is 125,000 light years long. It would take an
automobile driving at 88 kilometers per hour (55 miles per hour)
1.5 trillion years to cover that distance.
On page 35 - An automobile driving at 88 kph (55 mph) would
take 52 million years to reach Proxima Centauri from the Sun.
The next selection comes from THE UNIVERSE...AND BEYOND by
Terence Dickinson (Camden House Publishing, Ltd., Camden East,
Ontario, Canada, 1986, ISBN 0-920656-48-X, paperback):
On pages 16-19 - If the actual distance between the Milky Way
Galaxy and the Andromeda Galaxy (two million light years) were shrunk
to a typical book-reading distance, then the most remote galaxies
known would be 1.6 kilometers (one mile) away.
If the Sun were shrunk to the size of a 2.54-centimeter (one
inch) Ping-Pong ball, Earth would become a dust speck 240 centimeters
(eight feet) away, with the Moon being an even smaller speck just
6.25 millimeters (0.25-inch) from Earth. Jupiter would be a pea
1,200 centimeters (forty feet) from the Sun, and Pluto is a dust
speck nine thousand centimeters (three hundred feet) away. The
Oort Cloud of comets surrounding our solar system would be the
size of atomic particles and reside several kilometers distant,
with the comets themselves averaging several meters apart from
each other. The Alpha Centauri trinary star system would consist
of two walnuts (Alpha and Beta) and a pea (Proxima) 640 kilometers
(four hundred miles) from our solar system.
If Earth's solar orbit were reduced to the size of a United
States dime, the average distance between stars is now a little
over one kilometer (1.6 miles). The Milky Way Galaxy would be
the actual size of Earth. The distance to the Andromeda Galaxy
would be over half the actual distance between Earth and the Moon.
If you could hold the Milky Way Galaxy in your hand, the stars
in it would be sub-atomic in size, and the Andromeda Galaxy would
be 210 centimeters (seven feet) away.
My final textbook selection comes from CYCLES OF FIRE, by
William K. Hartmann and Ron Miller (Workman Publishing, New York,
1987, ISBN 0-89480-502-9, paperback):
On pages 14-15 - If Earth were the diameter of a microparticle
of soot, then the Sun would be one hundred times larger, the size
of a mote of dust, or one hundredth of a millimeter across. The
solar system would be the size of a saucer, and the Oort Cloud of
comets would exist several house lots away. Alpha Centauri would
be another dust mote one to two city blocks from the Sun, and the
Milky Way Galaxy would be the size of North America. Some of the
other nearby galaxies would be the varying sizes and distances of
Earth's continents. The known limits of the Universe would stretch
halfway across the solar system.
My friend and co-worker Drew LePage came up with some various
calculations on the celestial distance scale:
If the orbit of Pluto were the size of a U.S. dime, this would be
the size of various distances in the Universe:
Earth's orbit would have a diameter of about 0.5 millimeter (about
half the thickness of a dime).
One light year would be about 15.2 meters (49.9 feet).
One parsec (3.26 light years) would be about 49.7 meters (163 feet).
The closest star would be 65.4 meters (214 feet) away.
The closest one hundred known stars would be inside a sphere about
640 meters (2,100 feet) across.
The Sun would be 456 kilometers (283 miles) from the center of the
Milky Way Galaxy.
The Milky Way Galaxy would be 1,520 kilometers (945 miles) across.
To put intergalatic distances into perspective, if the Milky Way
Galaxy were the size of a dime:
The orbit of Pluto would be about the size of a hydrogen atom.
The Andromeda Galaxy would be 41.8 centimeters (16.5 inches) away.
One megaparsec would equal 61.9 centimeters (2.03 feet).
The recently discovered "Wall" of Galaxies would be about 40 meters
(125 feet) to 60 meters (190 feet) away, about 3 meters (10 feet)
thick, and extend for at least 100 meters (300 feet).
The most distant quasar known would be about 2.6 kilometers
(1.7 miles) away.
The size of the observable Universe would be about 5.7 kilometers
(3.5 miles) across.
If nothing else, these figures should give some idea as to just
how incredibly vast the known Universe is.
Larry Klaes [email removed]
- -------------------------------------------------------------------------
Date: 01 Dec 89 07:37:33 PST (Fri)
From: James T Perkins [email removed]
Subject: Mail from Joshua
- ------- Forwarded Message
- - ---- begin posting ----
I currently have a library of table handling and random number
generation routines out in beta test. If you want to be a beta tester,
or just want to see the documentation, please email me. I've listed
some of the features below. I can also send a more detailed design to
people who want to give me feed back on it.
random numbers
Takes strings representing dice rolls ("2d10", "1d8+1", etc.) and
returns the number. Also can generate random cards from a deck.
Has logging/playback facility. Untested facility to return floating
point numbers between 0 and 1.
table routines
Can read in, use, and print out tables. Currently supports two
types of tables, but is designed to be extendable to to other types.
Tables are stored in a human readable format (and can be created with
any text editor).
Joshua Levy [email removed]
{decwrl|sun|hpda}!athertn!joshua
home:[phone removed] work:[phone removed]
- ------- End of Forwarded Message
James
- -----------------------------------------------------------------------------
Date: Fri, 29 Dec 89 13:53:11 -0500
From: [email removed]
To: [email removed]
Subject: Re: Traveller Computer Programs
I doubt if anyone at GDW even knows what shareware is much less
understands the concept. There are no computer jocks (at least that I
know of) with the company. Almost all their software comes out of house.
Oh they write a few small programs for their PCs, but that is the extent
of it. The office PCs are used for standard business programming (mainly
text processing). A few of them may even have a PC at home. GDW as an
business is not currently on any computer network (although I am told
that one of the staff is privately).
If approached correctly you should have no problem, but shareware is not
a concept that is easy for non computer programming types to understand.
You have to stress that this is a simple playing aid that anyone could
write for themselves and all you are doing is saving them the trouble.
You should minimize the profit side of it, but not hide the fact that you
are asking money. They have been pretty liberal in the past about giving
permission to zerox out of print games, etc..
At any rate, I'll be seeing Frank and Loren next week and if a get a
chance to talk to him and I remember (note we will be quite busy with
other things so this is very doubtful) I'll try to bring up the subject.
Non Cuniculus Est,
Tom Harris
- -------------------------------------------------------------------------
Date: Mon, 20 Nov 89 11:06:44 EST
From: Dave Allen [email removed]
To: [email removed]
Subject: TRAV Sys Gen Digest
Bill,
I have subscribed to the Trav mailing list for a while and have enjoyed
the System Generation Digest. I would like you to add me to the
discussion group. This is a broadcast mailing list, right? That is,
there is some email address, and if I mail something there it goes to
everybody on the list. Boy, will I be embarrassed if THIS is the
broadcast address.
I was one of the people who started the Universal Simulation Mailing
List; I recently posted to rec.games.programmer the source to a
continental drift simulator I wrote. It generates planet maps that
look very realistic. Although I have been reading planetary science
journals for six years or so, it's just a hobby.
Although I missed the Survey deadline, let me give you a few comments.
I strongly believe ASCII is the right format, so that I can use a text
editor to fix up or create input to one of the programs in the toolset.
I am not interested in MegaTraveller format specifically; I think the
programs should generate _more_ information than MT needs. Perhaps
there could be an output filter which would take output from the
toolset and print it out on a MT-standard form, if there is such a
beast.
Hope to hear from you soon.
Dave Allen: internet [email removed]
- -----------------------------------------------------------------
End of Traveller System Generation Group Digest
******************************
All opinions and material above is the responsibility of the originator.
Submissions: [email removed], or [email removed]
Administrator: [email removed] (James Perkins)
The TML is made possible by facilities provided by Tektronix, Inc.