HDTenEightyP/NetNews huggingface dataset:
From: colles@marcus.its.rpi.edu (Grey Knight (Shawn Collenburg))
Subject: NBR Proposal: Varible help window
Summary: The help window should track your keymap
Keywords: nbr
Date: Thu, 19 Nov 1992 21:39:53 GMT

Reading about having a way to bring up a remote Options window, and
the response of changing a newbies keymap on them, reminded me of
something I've done a few times - change my keymap, and forget
what I changed it to, or having not played for (a summer), not
remembering what I mapped to what. It would be really nice if
the help window showed what the keys CURRENTLY are, instead of
the default keys all the time.

I'm not sure how the proposal thing goes, but I think I have
to keep track of seconds via email to colles@rpi.edu . . .

Shawn aka
Grey Knight
Newsgroups: rec.games.netrek
Subject: Re: BRONCO: Is now RSA.
From: jch+@cs.cmu.edu (Jonathan Hardwick)
Date: Wed, 18 Nov 1992 20:59:31 GMT
Organization: School of Computer Science, Carnegie Mellon

jwh@cs.bham.ac.uk (James "Oolon Colluphid" Hawtin) writes
> |> 
> |> ObTrek : when will we see the first player from a .su site? 
> |> 
> 
> Well Spaceman I think the answer to your question is NEVER, as all
> you Yanks will be running RSA servers which means that you will have
> it all to yourselves! 

Wow.  My first "Yank" insult.  Shome mishtake, shurely?

> This is apart from discovery server god who
> seems about the only clue person around, because he realise that RSA
> will lock a lot of people out and so they are apparently not
> converting. Also We may see them in the UK first because everyone 
> will always be able to play here =:*)

Au contraire, I'd expect Russian hackers to be only too able to break
crypt, and willing to put in the time to do so rather than flinging
insults hither and yon.  The limiting factor in their case is probably
the spread of X11 hardware.

Jonathan H.
From: echeverr@scf.usc.edu (5150)
Newsgroups: rec.games.netrek
Subject: Re: Swiss pairings (long-but read anyway)
Date: 23 Nov 1992 20:43:40 -0800
Organization: <censored>
NNTP-Posting-Host: girtab.usc.edu

In article <cf4OJk200VpdE2P2gZ@andrew.cmu.edu> "Timothy C. Worsley" <tw1r+@andrew.cmu.edu> writes:
>	Another possible way of schedualing the INL is by Swiss pairings.  This
>is the way in which chess tournements are run.  
{deleted}
>	I'm not going to get terribly upset with the council if they don't use
>Swiss pairings, but it is worth looking into.

{FLAME ON}

What took you so #@$@#$ long to post this??????

{FLAME OFF}


5150
i like it i like it
Newsgroups: rec.games.netrek
From: amueller@beech.cis.ohio-state.edu (andrew j mueller)
Subject: Re: Whatever happened to? Minimal clue server?
Organization: The Ohio State University Dept. of Computer and Info. Science
Date: Wed, 18 Nov 1992 13:03:00 GMT

	< deleted stuff from Passing Wind >
>
>Well it is funny you should ask. I have just completed the modifications on
>guzzler to do just this. It basically works by sending this:
>
>
>GOD->YOU This is a clue player hour.
>GOD->YOU To stay in the game you need to return the string:
>GOD->YOU clue:Earth
>
>When you return the string clue:Earth you are then allowed to stay on.
>You get approx. 1 minute to answer or else boom you're gone. I can set up
>any time or day for this. I was leaning towards thursdays being clue nights
>for guzzler. If it is successful I may increase the number of days for 
>clueful playing. I'll set it up this way and see what kinda response I get.
>If you want to play you have to have a RSA client. The address for guzzler
>is on the metaserver but here it is anyway.
>
>Address: guzzler.ecst.csuchico.edu
>Port: 5858
>
>
>Nick Trown
>Netherworld
>Server God of Guzzler.

	to whom do you send this string ????   R2->GOD  ????????
==============================================================================
Andy                           | I remember now
amueller@cis.ohio-state.edu    | I remember how it started
                               | I can't remember yesterday
bloodwing                      | I just remember doing,
:MINDCRIME                     | what they told me...told me...told me...
==============================================================================
From: mcn@cwru.edu (Michael C. Neuman)
Newsgroups: rec.games.netrek
Subject: Re: NeXT netrek (NeXTrek)
Date: 19 Nov 1992 15:32:29 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
Distribution: world
Reply-To: mcn@b62103.student.cwru.edu
NNTP-Posting-Host: b62103.student.cwru.edu

In article <1992Nov19.085422.20920@alijku05.edvz.uni-linz.ac.at>  
siegl@risc.uni-linz.ac.at (Kurt Siegl) writes:
>From the ftp-list:
>b62103.student.cwru.edu 129.22.242.151  NeXT stuff.
>
>I got access to a NeXT now instead of an X-term and
>just fetched the code but it's an old client.

  Well, it's just the 'plain vanilla' client. I'll be porting Hadley's client (and others) as soon as the time presents itself. (They'll prolly only be ported as RSA, however).

--
        Mike Neuman                mcn@b62103.student.cwru.edu
  "To make a machine that will be proud of us." - Thinking Machine's motto
==============================================================================
* Maintainer: NeXT netrek archive--b62103.student.cwru.edu:/pub/games/netrek *
Newsgroups: rec.games.netrek
From: mikey@sgi.com (Mike Yang)
Subject: Re: BRONCO: Is now RSA.
Organization: Silicon Graphics, Inc.
Date: Tue, 17 Nov 1992 06:07:19 GMT

In article <BATHURST.92Nov16133807@felix.noaapmel.gov> bathurst@noaapmel.gov (Bill Bathurst) writes:
>decrypt it:decrypt it:
>
>        crypt key.sun4 < rsa_client.sun4.static.Z.crypt > rsa_client.Z
>
>Then try to uncompress it.  The problem is compress doesn't recognize it
>as being a compressible file.  Has anyone done this yet?

The crypt key is not key.sun4.  That is the RSA key for server admins.

To get the crypt key, you must send mail to mcp@cs.umd.edu and assert
that you're a US citizen.  This is because RSA binaries cannot be
legally distributed outside the US.  That's why they were crypt'd.

Here's the contents of the crypt.readme file from pittslug:

To decrypt the files in this archive, you must be a US or Canadian
citizen. Simply send me mail stating "Yes, I'm a US (resp. Can) citizen."
(You must also be physically within the US or Canada... )
I'll send you the crypt key. You can then crypt key < file.crypt > file
to get the tar files.

If you intend to upload any clients/code to any ftp site, you must compress it
and crypt it with the key you get from me. I'd like to keep it down to one key.
No clients and/or code may leave the US or Canada, and none of it may be
distributed to non US/Can citizens. Sorry for any inconvenience, but these
are not my rules. RSA has a "no - foreign" designation. If you have any questions,
please don't hesitate to ask.

Send mail to:
<mcp@cs.umd.edu>

Under the terms of res-rsa/RSA-README, you may give the crypt key to
other US/Can citizens within those countries in keeping with the distribution
license. I will make RSA-README available as plaintext in the archive.

-----------------------------------------------------------------------
                 Mike Yang        Silicon Graphics, Inc.
               mikey@sgi.com           415/390-1786
From: envmhs@epb11.lbl.gov (Max H. Sherman)
Newsgroups: rec.games.netrek
Subject: Catching up
Date: 19 Nov 1992 20:15:59 GMT
Organization: lbl
Distribution: world
NNTP-Posting-Host: 128.3.12.123

I have been away from rec.netrek for months and it appears I have
missed server changes, RSA etc.  I went through the old messages
and I don't see a FAQ or server list etc.  I am awaiting a key
from mcp and but I don't know if those codes are UDP or things like
that.
From: hadley@thoth.ics.uci.edu (Tedd Hadley)
Subject: Re: GB vs LAR lag
Newsgroups: rec.games.netrek
Organization: UC Irvine Department of ICS
Date: 20 Nov 92 16:58:09 GMT

In <1ei6t7INNk6@agate.berkeley.edu> tom@soda.berkeley.edu (Tom Holub) writes:

>)   Think you would have come back from a 6 planet deficit?

>We came back from a 5 planet deficit.  We had 14 armies on the base
>at the time, so yes, it's quite within the realm of probability.

   Yes, but at the time your base was heading for earth :)  I kept
   moving it back to rom until the network cleared up.

>Tedd Hadley writes
>>    A good argument for an INL server proposal:  have the server pause
>> the game automatically if any player is ghostbusted.  I suppose it could

>But the server doesn't know when players are ghostbusted for a good
>long while,

   Part of this delay is due to UDP.  Ghostbusts (the server actually
   exploding the ship) occur whenever the TCP connection is broken (the UDP
   connection is another story).  However, during typical network problems,
   what really happens is that the server doesn't find out about the problem
   until the TCP Send-Q buffer fills up.  If you're using UDP, that means
   the TCP buffer isn't filling up as fast -- most packets are getting
   dumped into the UDP Send-Q.  Eventually the TCP Send-Q buffer gets full,
   the write() in the ntserv process blocks, and the daemon starts
   incrementing the 30 second ghostbust timer.  This is one possible
   scenario.  There are others but I think this one is the most common.

   One possible fix is to make the TCP queue as small as possible, and
   implement a send queue in the server.  On each TCP write it is then
   possible to determine the status of the connection by checking for the
   error status on the write.  This strategy could also be combined with
   a timer check on the read side (reset each time the server gets a command
   from the player).  It would probably take some fine-tuning but at least
   initially the server could be able to notify captains (or the ALL board)
   of possible ghostbusts.

>and it can be argued that one player out isn't enough
>reason to pause the game.  I think a unilateral pause command would
>take care of things well enough.

   Yes, that's an important thing to have in any case.   Maybe change the
   current semantics of PAUSE to pause the game if either captain requests
   it but unpause only when both request it.

> -Tom

In <BxzM7K.DFn.2@cs.cmu.edu> hill@norman.VI.RI.CMU.EDU (Robert Hill) writes:

>I was under the impression that the INL server freed the ghostbusted slot
>as soon as it knew that the player was ghostbusted.

   No, I think it's back to standard ghostbust behavior.  At least my
   copy of INL3.0 is.

++
   Tedd Hadley (hadley@uci.edu)
From: jch+@cs.cmu.edu (Jonathan Hardwick)
Newsgroups: rec.games.netrek
Subject: Re: BRONCO: Is now RSA.
Summary: I don't think so (ObMojo)
Date: 17 Nov 92 02:37:55 GMT
Organization: School of Computer Science, Carnegie Mellon

bathurst@noaapmel.gov (Bill Bathurst) writes
> Which brings up another question.  Why the hell didn't they just put the
> rsa clients in there in the first place instead of making people search
> everywhere for a crypt program (it isn't standard on Suns and Decs).

Because then naughty evil pinko commie ogger scum would anon FTP over
from kremvax, grab the RSA binary, decompile it, work out all the
wonderful inner secrets that haven't ever been published anywhere, not
even in sci.crypt, honest guv, cross my heart and hope to be killed by
a warp 1 scout with 100 fuel, and, damn where was I, oh yes, build
super-duper new military encrypted communication doohickeys which
they'd use to plot the capture of the Bronco database and the demise
of MUCUS PIG. 

What, you want a serious reason?  Oh, ok : the RSA hackers (may their
bits never rot) are just jumping through the hoops that PKP and/or the
US government are putting there.  Sure, it's silly, but they're
following the CYA principle.  Write a congresscritter or something.
Just make sure you adopt the "netrek is a wonderful real-time network
test, *and* it teaches teamwork, *and* it develops the skills that our
next generation of space fighter pilots will need when we fight the,
uhhh, Martians" approach...

ObTrek : when will we see the first player from a .su site? 

Spaceman "what is the Russian for scum, anyway?" Spiff
From: markiel@callisto.pas.rochester.edu (Andrew Markiel)
Newsgroups: rec.games.netrek
Subject: Re: Lag and the standard on bronco (SC bombers rule!)
Date: 20 Nov 92 04:51:15 GMT
Organization: U(r) AstroTheory Group

In article <surge.722127801@mowgli> surge@cqs.washington.edu (Jonathan Sari) writes:
>hill@norman.VI.RI.CMU.EDU (Robert Hill) writes:
>>Scout bombing is the toughest and most important job, in my opinion.  I  
>>don't scout bomb in INL games because my talents lie elsewhere.  In pickup  
>>games, I frequently scout bomb when the bombing isn't gettting done.  If  
>>my team has a bomber, I take planets and ogg, if not then I bomb.  It is  
>>the most effective way to kill armies.
>
>But sometimes you can scout bomb like crazy and still lose in a big way
>because you have armies sitting on your planets, or in the ships of og
>bait.  In clueless games, you can win by simply putting every one of your
>armies that pops on an enemy planet, even if the other team has incurable
>scums.  The other team dinks around with its armies and you can og or
>delay enough of them to win the war of attrition.
>
It sometimes happens that the best thing to do is just take planets. Taking
planets is essentially premature bombing, because the planet you took
would have produced bombable armies if you hadn't taken it. If you go at
it enough, eventually the enemy just starts running out of planets, which
means they start running out of armies. The breakeven point is where the
planets you take start making armies for you: that's basically production
you've taken from the enemy that's working for you. If you can take
planets fast enough that you reach this point, you're probably going to win.

Usually, you can't do this, because you run out of armies to take with, and
then they use their armies to take all the planets back. However, a big
planet push, timed when the enemy is out of kills, can gain a lot of
ground, because all the enemies' armies don't help with nothing to carry
them in. If you can then bomb out a lot of the armies before they can
get enough carriers to use them all, you'll have made great progress.

Sometimes, just doing the simple thing is the best you can do.
>
>-Ensign Pac-man

-Grey Elf
From: srt@aero.org (Scott R. Turner)
Newsgroups: rec.games.netrek
Subject: Re: GB at LAR
Date: 18 Nov 92 17:40:19 GMT
Organization: The Aerospace Corporation, El Segundo, CA
NNTP-Posting-Host: sun-marino.aero.org

jsin@oahu.cs.ucla.edu (Jonghoon Sin) writes:
>Alas, it still doesn't look like there will be all-UCLA team (unless 
>"TCB" is interested in forming his own team?  :)   I'd like to see a game
>on his Synchronized-Swim netrek server.

I don't want to hear acrimonious remarks from the Russian ("Golden
Bear") judge, thank you :-).

"Ve could not compete vairly because of the capitalist lag!"

					-- Scott T.
From: echeverr@scf.usc.edu (5150)
Newsgroups: rec.games.netrek
Subject: Re: GB at LAR
Date: 16 Nov 1992 22:00:22 -0800
Organization: <censored>
NNTP-Posting-Host: girtab.usc.edu

In article <1e9slvINNgfr@agate.berkeley.edu> tom@soda.berkeley.edu (Tom Holub) writes:
>Yes, LA Riot was quite cool about handling the ghostbusts during our
>game, although I wouldn't call agreeing not to play on a ridiculous
>server "gracious."  I think LA Riot deserved most of the acrimonious
>comments; to play a game on calvin when other servers are available
>is intentionally taking unfair advantage of the home field.

Utter bullshit.  Any USC team has to deal with the exact same kind of lag
playing outside of Southern Cal.  We will play our games at calvin because
it's the only advantage we can get, since we have the exact same 1-min-freeze-
every-10-min lag playing elsewhere.

My team next semester is going to play on calvin unless we can actually set
up servers in ucsb or sdsu to accomodate whiney boys who can't deal with lag.

5150
From: ahabig@bigbang.astro.indiana.edu (Alec Habig)
Newsgroups: rec.games.netrek
Subject: Re: RSA Clients are cleared!
Date: 22 Nov 92 17:38:45 GMT
Article-I.D.: usenet.By4p0L.5JG
Organization: Indiana University Astrophysics, Bloomington, IN

Yay!  Thanks to all who helped work on this.  Now we can all get back to
playing netrek instead of debating cryptology laws.

	Alec
Newsgroups: rec.games.netrek
From: leonard@mimsy.umd.edu (Leonard Dickens)
Newsgroups: rec.games.netrek
Subject: Re: freedom of bitmaps
Date: 15 Nov 92 23:46:26 GMT
Organization: Deep Thirteen, Gizmonics Institute

ZZnew guy writes:
>	Several people have sent me mail which says, in essence, that bitmaps
>don't make any difference, and that one should be allowed freedom to
>make whatever bitmaps one wants to for a client.
>	So, if someone wanted to make 16 SB bitmaps to show what direction a
>base was flying in, would this be OK?  If so, why?  If not, why not?

I think that generally bitmaps don't matter, and a user should be able
to customize what HE sees (or she).  But not what the OTHER guy can
see.  Also, there are a few exceptions like that for bases: there is
only once base bitmap for each race, duplicated 16 times.  Right now
you cannot see where a base is headed easily, which is one of the
small advantages bases have.  I think this should be preserved.

In short, you should never be able to get MORE info by replacing
bitmaps, at least until the net votes that it is OK.  This rules out
having multiple base bitmaps for direction.  Getting the info that is
there MORE CLEARLY should usually be OK.  As long as it is already
there.

I think the idea of being able to design your own ship bitmaps is nice
in concept, but we will not be able to find a way to implement it
without making it exploitable by people who are willing to spend the
time to learn to use something ugly in order to get an advantage over
others.  For instance, consider the case where a person makes all of
his cruiser bitmaps identical solid squares... yuk.

-Leonard
Newsgroups: rec.games.netrek
From: jch+@cs.cmu.edu (Jonathan Hardwick)
Subject: Re: GB at LAR
Organization: School of Computer Science, Carnegie Mellon
Date: Fri, 20 Nov 1992 16:27:14 GMT

rone@girtab.usc.edu (Ron Echeverri) writes
> von@cory.Berkeley.EDU (Steve Von Worley) writes:
> >I don't give a shit whose fault it is and what you have to suffer with.
> >Other people should not have to suffer because you do.
> 
> So basically, USC is fucked because we have a shitty connection.  So we have
> to bus our asses to UCLA for any INL 'home' games we may have, yet suffer
> "calvin" lag for all our away games.  Let's see how many people agree with
> you.

If USC's net connection has degraded sufficiently that the farce is
becoming Reed-like (correct school, right?), then I think USC should
do the honorable thing and leave the INL until they can get a
reasonable net back. 

Spaceman "IMHO" Spiff
Newsgroups: rec.games.netrek
From: jasonp@oslts0.Prime.COM (Jason Pascucci)
Subject: RSA minor problem....
Organization: ComputerVision Services
Date: Sun, 22 Nov 1992 06:36:46 GMT

While I agree the RSA method is fairly well done, and I have to 
admit I haven't seen the source, I believe that the consensus
is that they key can be ripped out of a client, and once this
has been done, it most likely will be possible, as easily
or more, in the next release, so I propose to do something
about it SHOULD the time arise when the key is broken.

How about doing a simple encryption scheme on the key itself? 
Xor it with a value compiled into the client somewhere, and do some 
more tap dances on it. This will hold off a person who
is just looking for the key. However, if someone has decompiled 
the binary, then this doesn't work. 

One, never keep the full key in the same place, split it up 
into fragments, and reconstruct it on the fly.

Two, split what you are doing to the key (adding 100 to the
top half, multiplying by 50, whatever random mathmatical
operations you want to do, etc, etc) into different
places in the code. Put part of it in the main(),
part of it when you make the connection, etc, etc,
all over creation, and operate on different parts
of the key. This is a pain for the client guys,
but it will make it nigh impossible to decrypt. Even
this doesn't preclude doing a binary cmp, and decoding
the instructions that are different, but that will
be fairly difficult, especially if you make use
of lots of short loops...let the computer do things for 
you...

I'm just thinking of all the things I would do if
I wanted to break the code. And I'm not even all that 
clever, but we have to be much more clever than
the crackers. If I had no ethics, I probably would
try to do it myself, but since I do, I'm stuck trying to be
more clever than people who would try to hack it. 

Oh..>VARY THE LD<. Put some modules first sometimes, 
switch modules in the middle, etc. This will make it PAINFUL
to cmp, but, again, not impossible. 

(BTW, someone should do something like this soon, because
there are at least a half a dozen people who have read
this post, and said 'Oh, yeah...I can do that'.)

If anybody does crack a key, please post it. You won't 
be censured. I will even applaud your efforts. But,
the key will be changed, and we will put into effect
a better scheme. Is it a deal? Isn't this more fun
than playing a blessed borg?

Anyways, nightnight.

--
Jason R. Pascucci
jasonp@primerd.prime.com
From: envmhs@epb11.lbl.gov (Max H. Sherman)
Newsgroups: rec.games.netrek
Subject: Re: Base stats for NBR
Date: 20 Nov 1992 18:03:23 GMT
Organization: lbl
Distribution: world
NNTP-Posting-Host: 128.3.12.123

In article <62202@mimsy.umd.edu>, leonard@mimsy.umd.edu (Leonard Dickens) writes:
|> It would be cool if the server kept track of a few base stats in the
|> NBR server.  Here are some ideas for base stats.
|> 
|> Offense:  kills/time
|> Defense:  deaths/time
|> Armies:   armies on board/time
|> Bombing:  armies killed on board enemies/time 
|> Position: ratio of distance from own home planet to enemy home planet/time
|> Repair:   total shield+internal damage repaired/time
|> 
|> -Leonard

What about 
	ARMIES TRANSFERRED TO SHIPS
	Planets taken - planets lost
	Time spent with players docked
	kills made with players docked

Basically base play is a function of the rest of the team.
Most of the important things a base does is to support/protect
the other activities.  Ratio is the dumbest indicator, (at least in
t-mode) because it gives no indication as to how the base is helping
the team