X-Git-Url: https://jxself.org/git/?p=super-star-trek.git;a=blobdiff_plain;f=doc%2FHACKING;h=0babf5cd6fe110ea5a6558d2265b70ffa8f0e6f7;hp=ef0ddb90e678a3deabd6156e9aa89ceeaf3759ad;hb=a404eb642e74b97233fa0f84b95a0601a86b5b66;hpb=22f7cb3bfdf2e4759470f5decce4dba8c306e139

diff --git a/doc/HACKING b/doc/HACKING
index ef0ddb9..0babf5c 100644
--- a/doc/HACKING
+++ b/doc/HACKING
@@ -1,7 +1,7 @@
 This is the hackers' guide to SST2K.  Read it before messing with the code.
 
 It consists of an introduction, a history, suggestions for regression testing,
-some notes on the Python translation.  For a to-do list, see TODO in the
+and some notes on the Python translation.  For a to-do list, see TODO in the
 top-level directory.
 
 INTRODUCTION:
@@ -178,13 +178,33 @@ worlds enabled, they must have one in the quadrant to beam down
 to; otherwise they die in space and this counts heavily against
 your score.  Docking at a starbase replenishes your crew.
 
-8. Still more BSD-Trek: we now have a weighted damage table.
+8. Still more BSD-Trek: we now have a weighted damage table.  Quoth
+Eric Allman in the code of BSD-Trek: "Under certain conditions you can
+get a critical hit.  This sort of hit damages devices.  The
+probability that a given device is damaged depends on the device.
+Well protected devices (such as the computer, which is in the core of
+the ship and has considerable redundancy) almost never get damaged,
+whereas devices which are exposed (such as the warp engines) or which
+are particularly delicate (such as the transporter) have a much higher
+probability of being damaged."
+
+This is one place where OPTION_PLAIN does not restore the original
+behavior, which was equiprobable damage across all devices.  If we
+wanted that, we'd return randrange(NDEVICES) and have done with it.
+Also, in the original game, DNAVYS and DCOMPTR were the same device.
+
+Instead, we use a table of weights similar to the one from BSD Trek.
+BSD doesn't have the shuttle, shield controller, death ray, or probes.
+We don't have a cloaking device.  The shuttle got the allocation for
+the cloaking device, then we shaved a half-percent off everything to
+have some weight to give DSHCTRL/DDRAY/DDSP.
+
 Also, the nav subsystem (enabling automatic course
 setting) can be damaged separately from the main computer (which
 handles weapons targeting, ETA calculation, and self-destruct).
 
-After these features were added, I translated this into Python and added
-more:
+After these features were added, I translated this program into Python
+and added more:
 
 9. A long-range scan is done silently whenever you call CHART; thus
 the LRSCAN command is no longer needed.  (Controlled by OPTION_AUTOSCAN
@@ -220,8 +240,8 @@ separate project).  I then hand-tuned and refactored the result.
 
 The LOC count dropped by almost exactly 20% during this process, from
 a bit over 8100 lines to a bit over 6500 lines.  If the code is still
-shorter than that when you read thism, it's because this file comtains
-nost of what used to be a huge header comment.  
+shorter than that when you read this, it's because this file contains
+most of what used to be a huge header comment.  
 
 SST is not a data-structure- intensive program, so it compresses less
 under translation to Python than the 50% drop in LOC I've found to be
@@ -245,3 +265,25 @@ FORTRAN all the vector representation was done with parallel arrays;
 in C, I introduced a struct; in Python, the class has a complete
 repertoire of vector-algebra operations.
 
+There's one weird archeological detail about the nav code that
+deserves a remark.  This program originally required input in terms of
+a (clock) direction and distance -- essentially, directions were real
+numbers modulo 12 with zero being north.  Somewhere in history, it was
+changed to Cartesian coordinates.  But the bearing method still computes
+polar coordinates in clockface units -- that's the reason for the
+wacky constant 1.90985, inherited straight from the ancestral FORTRAN.
+Elsewhere, there were a bunch of computations, now centralized in the
+course object, that looked like (15.0 - bearing)*0.5235988; this is a 
+conversion from clockface units to radians with zero on the X axis.
+
+As a previous maintainer, probably Tom Almy, observed: Probably
+"manual" input should still be done this way -- it's a real pain if
+the computer isn't working! Manual mode is still confusing because it
+involves giving x and y motions, yet the coordinates are always
+displayed y - x, where +y is downward!
+
+Because I think he's arguably right, I haven't ripped out all the
+clockface-to-radian conversions.  For this reason, and others, the 
+trig code is still a bit wacky and obscure.  Modify with caution
+and test thoroughly.
+