HDTenEightyP/NetNews huggingface dataset:
From: jb7m+@andrew.cmu.edu (Jon C. R. Bennett)
Newsgroups: rec.games.netrek
Subject: Re: INL plague code (was: Re: INL pop code)
Date: 10 Jan 93 12:16:49 GMT
Article-I.D.: andrew.YfI_1Fe00WD5M2kXgy
	<1ins22INNejo@phakt.usc.edu>
Organization: Robotics Institute, Carnegie Mellon, Pittsburgh, PA


echeverr@scf.usc.edu (5150) writes:
> So take those 30min away, and have 90min INL games.  2hrs is grueling, and
> 1hr games aren't long enough to really make a point to who the better team is
> IMO.

how about 2 back to back 1 hour games, where in the second game you switch
races, but get exactly the same resource setup, thus decresing the impact
of a good/bad set up

jon
Newsgroups: rec.games.netrek
From: exodus@IASTATE.EDU
Subject: Re: From the coUnCiLbOy: INL Council position openings.  Please read.
Reply-To: exodus@IASTATE.EDUIn article <1993Jan7.180718.7210@coe.montana.edu>, osyjm@cs.montana.edu (Jaye Mathisen) writes:
Organization: Iowa State University, Ames IA
Date: Thu, 7 Jan 1993 23:47:44 GMT

> 
> INL Council position openings.
> 
> As you may or may not be aware, Ben Polk (Washout), and Rob Hill (Spaceace!)
> have resigned as INL Council members.  This has created two openings that
> need to be filled.  (The INLC wishes to thank Rob and Ben for their
> service during the fall 92 season.)
> 
> The INL Council has two openings starting now.  The procedure for replacing
> them will be as follows:
> 
> Criteria:
> 
> Selection will be by popular vote, subject to the following limits.
> 
> Only 1 representative from any school/company present on the council at a
time.
> 
>   


   I hate to bring this up again, but the above limitation is _really_
stupid. There are more qualified people for INL council membership at
CMU & Berkeley than the rest of the country combined. I don't think
the "at-large" member compensates for this at all. We're just hurting
ourselves by only allowing 1 per school.....



						Exodus
 

Newsgroups: rec.games.netrek
From: jrichard@cs.cs (John 'MacGyver' Richardson)
Subject: Re: ntserv
Organization: /usr/ug/1993/jrichard/.organization
	<JRICHARD.93Jan4023715@cs.cs> <1ifq6cINNd2m@tamsun.tamu.edu>
Date: Thu, 7 Jan 1993 04:18:45 GMT



   Yes, I see your point.  In any event you'd have to worry about the connection being
   broken with the 'packet' half sent (note: not the client being killed, but a router
   going down).  For some reason I had thought there was a way to determine the amount
   of data avaliable.

:)  

I didn't even think about that one... 

   Have you tried not using ASYNC IO?  It sounds expensive.

Not using it with TCP?  No.  I haven't actually tried it except on "test"
programs.  BTW: all the test programs worked ok.  I don't use it with 
UDP though.

   |> Hmmm, did you mean re-connecting a borg to a socket?  I saw that but didn't
   |> think it would be a problem with this impementation.

   That's what I meant alright.  Could you explain why you don't think it would be
   a problem?

The way I see it there are two solutions to the problem.  

	o First off, the protocol I built makes a new UDP socket for each 
          conntection.  This simpilfies things so I don't have to compare
	  addresses to find which slot should be getting the packet.  So
	  the potential borg would have to know what port he was connecting
	  to on the server end.  Granted, there probably is some way to do
	  this (I'm no datacomm wiz, so I don't know offhand), but it could
	  be done now anyway (just no TCP packets could be sent).  I think.

	o Periodically send a request for ID to the client.  If it isn't
	  able to respond, nuke him! :)
	
Seem ok?  BTW:  I can't seem to mail to you.


John Richardson                |  "the more we live, the more we learn, 
jrichard@cs.ulowell.edu        |   the more we know... for each of us the road
jrichard@dragon.ulowell.edu    |   is clear, and life has just begun" -- Yes
From: bharat@shadow.Eng.Sun.COM (Bharat Mediratta)
Newsgroups: rec.games.netrek
Subject: Re: misconceptions
Date: 12 Jan 1993 22:57:41 GMT
Organization: Sun Microsystems, Inc.
Distribution: world
Reply-To: bharat@shadow.Eng.Sun.COM
NNTP-Posting-Host: shadow

In article 28042@ncsu.edu, jecoleb@eos.ncsu.edu (have clue, will travel) writes:
[...]
> >2) It's important to protect your starbase.  FALSE
> Usually false but situational.  In an average pick-up game, usually VERY false
> unless it's one of a number of specific situations.
> 
> Note: "protecting starbase" != "scumming a kill off of your starbase."

When I play a SB (which is most of the time :) I usually encourage
my teammates to scum kills off of me, since the SB's kills do the team
absolutely no good whatsoever.  I usually try to tractor/pressor enemies into
teammates' torps, and if there are no friendlies around, I try to cripple
the enemy and call for somebody to transwarp and kill him.

-Shade

[...]
> 
> 				---Commodore Video Sex Pope, NCSU
> 				---"Newbies 'R' Us."
> 
> --
>      jecoleb@eos.ncsu.edu      \\              To KLH:
>  "I don't know where you took   --=--      Love ya, Katya!
>  me, but I didn't want to leave."   \\  have clue, will travel.
>        ---------------------------------------------------



---
    /\        Bharat Mediratta
   \\ \       Graphics Continuation Group
  \ \\ /      
 / \/ / /     
/ /   \//\    SUN Microsystems, Inc.	
\//\   / /    Mailstop: MTV18-218
 / / /\ /     2550 Garcia Avenue, Building 18
  / \\ \      Mountain View, CA 94043
   \ \\       Phone:  (415)336-4347, FAX:(415)336-5471
    \/        Email:  bharat.mediratta@eng.sun.com



Newsgroups: rec.games.netrek
From: jecoleb@eos.ncsu.edu (have clue, will travel)
Subject: Re: ZZ predicts
Reply-To: jecoleb@eos.ncsu.edu
Organization: The Ghost Of Christmas Past Society
Date: Wed, 6 Jan 1993 04:19:02 GMT


Jeff Rosenfeld <jdr+@andrew.cmu.edu>
>	Well, it's the end of a year, so I thought I'd make some predictions
>for next season's INL.

This oughta be fun... :)

>	The INL council will adopt a modified version of Tom's scheduling
>proposal.  At the end of the season, a number of teams in the top and
>middle brackets will be upset, and a flame-war will insue.  This won't
>amount to much.
And any flame war DOES?

>	The INL council will adopt a more scattered popping code instead of the
>current 40 second code.
Works for me.  No biggie either way.

>Teams:
>	Rob "Spaceace" Hill's all-star team will win the championship match.  
>	Other dominating teams will include, TWNN (possibly with a new name), a
>team from SC, a team from Berkeley (probably named Golden Bears), Old
>McDonald's Farm, and the Illuminatus Cartel (possibly under a new name).
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Make that "definitely," for both "dominating" and "new name" criteria. Moohaha.

>	MIT, RPI, CU Boulder, KSU, Harvard and UNC Chapel Hill will all find
>themselves to have a few too few players for a full team.  @ large teams
>will get a lot of players from these spots.

UNC CHAPEL HILL?

PLAYING NETREK?

BWAHAHAHAHAHAHAHAHAHAHAHAHA...  *rolling on the floor in convulsive giggles*

Now, as for NCSU, we've got MORE than enough for a full team, even without the
three top players from last year (I defected, a second may yet defect with me
if he has enough spare time to play, and the third dropped out).  

Should the game ban be lifted, a full NCSU team should restore the good name
of the NCSU Legion of Netrek Twinks.

Tar Heels.  Netrekking.  *chuckle*  Bring 'em on, if they're out there. :)
  
>Players:
>	Guru and The Exodus will end up on the same team.  They may be
>co-captains, or Guru may be sole captain.
Errrrrrrr...  ummmmmmm...  nah, I'm not talking.  Taking bets, yes, but not
talking.  ;)  

>	MUCUS PIG will make a post on RGN.  This will turn out to be a forgery.
*grin*  Don't tempt me, Sparky. ;)  I've been back 2 days and am already bored.

			--Commodore Video Sex Pope, NCSU (I'm baaaaaaaaack...)
			--"My prediction: The championship INL game will be
			   decided by an unnamed player Chunging their team's
			   last 10 armies."

--
     jecoleb@eos.ncsu.edu    \\
              To KLH:          ---      Love ya, Katya!
                                  \\  have clue, will travel.
       ---------------------------------------------------
From: paulsen@eniac.seas.upenn.edu (Brian Paulsen)
Newsgroups: rec.games.netrek
Subject: Re: INL plague code (was: Re: INL pop code)
Date: 11 Jan 93 16:06:31 GMT
Organization: University of Pennsylvania

In article <1iqeid$6ri@agate.berkeley.edu> jh@heel.CS.Berkeley.EDU (Jack Hsu) writes:
>In article <YfI_1Fe00WD5M2kXgy@andrew.cmu.edu> jb7m+@andrew.cmu.edu (Jon C. R. Bennett) writes:

)If you switch servers too, then there this problem of preserving the
)same resource setup.

This shouldn't really be a problem.  Either xsg or saving the .planets file
should fix it up pretty easily.

)I am also of the opinion that 2 hour games are too long, and I tend to lose
)my concentration after the first hour. This is a list of suggestions from
)the net:
)	1) 10 minutes break after the first hour
This is probably the most reasonable.

)	2) substitute often
Teams can do this now, but don't.  I don't think this would have much of an
effect.

)	3) shorten competition time to 60 or 90 minutes
60 minutes seems too short.  In all of the games that I played against SS,
things were pretty near tied after 60 minutes.  It was only in the last
60 minutes that they would start to take our space.  Seeing as they were
the stronger team, it would be a shame if we won due to only time limits.

*However*, I also felt many times that if the game was 3 hours, we could've
come back to tie or even to win.  Perhaps the games should be extended and
only the truly deranged players win :) :)

)	4) keep it as it is
Another reasonable option...

)Each of the suggestions have their pros and cons, but I'm more in favor
)of option (2). This is because:
)	-even though it's long, I enjoyed every second of it.
)	-you do need that long to find the better team.
)
)What are your opinions?
)
)-Jack
) Gaia
From: turin@soda.berkeley.edu (Jimmy Reza de la Turin)
Newsgroups: rec.games.netrek
Subject: RE: Clue game
Date: 12 Jan 1993 00:14:36 GMT
Organization: U.C. Berkeley, CS Undergraduate Association
Distribution: world
NNTP-Posting-Host: soda.berkeley.edu


>PhaserPractice    
>One               
>delbaeth

What da fuck?????

Since when is One considered clue?

he sucks, plain and simple.

if he plays.. i don't want him on my team.


Duck Dodgers
From: jimmyhua@aludra.usc.edu (Jimmy Huang)
Newsgroups: rec.games.netrek
Subject: Re: manual for newbies
Date: 7 Jan 1993 21:04:12 -0800
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: aludra.usc.edu

jecoleb@eos.ncsu.edu (have clue, will travel) writes:

>		--"Chapter 24: How to Send Messages and Shoot Simultaneously"

Ouch, still can't do that...

Jimmy
From: hadley@vlsi.ics.uci.edu (Tedd Hadley)
Subject: Re: CLUE GAME site
Newsgroups: rec.games.netrek
Organization: UC Irvine Department of ICS
Date: 12 Jan 93 04:42:33 GMT

In <1itdpbINNclv@charnel.ecst.csuchico.edu> dtabb@ecst.csuchico.edu (Don Tabb) writes:

>MY NET sucks.  I was just told that it ok to have the
>game here but most people will have about 20% packet
>loss.   sh*t.  ok.   NOW we have people, we have a time.
>we have no server.   any SERVER GODS want to help out?

   Yeah, there's something weird going on there.  Look at this ping graph
   over 100 seconds to chico.csu.net:

   800 ms |   .   .   .   .   .   .   .   .   .   .
          |
          |
          |  .   .   .   .   .   .   .   .   .   .
          |
          |
   30 ms  |..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..
   0 ms   |
	  --------------------------------------------
	  0  10  20  30  40  50  60  70  80  90  100 seconds

   Every 10 seconds (closer to 11 actually) a hyperspace jump to
   ultra-lag.

   The same router really flaked out a couple times while
   I was playing on guzzler today: 30% packet loss, 1-10 second delays
   for about 5 minutes.  If it crashes like that all the time, seems
   like it'd be interfering with even the non-frivilous activities.
   Maybe there's a nic.csu.net or some network-trouble mailing address
   where one can file a bug report.

++
   Tedd Hadley (hadley@uci.edu)
From: bharat@shadow.Eng.Sun.COM (Bharat Mediratta)
Newsgroups: rec.games.netrek
Subject: Re: NetrekBiff
Date: 8 Jan 93 19:34:21 GMT
Reply-To: bharat@shadow.Eng.Sun.COM
Organization: Sun Microsystems, Inc.
NNTP-Posting-Host: shadow

In article 940@unidoct.chemietechnik.uni-dortmund.de, sn@plato.chemietechnik.uni-dortmund.de (sn) writes:
> Couple days ago someone posted server mods so whenever someone
> was logged in, the server would create a file ("on").
> This is unnecesary. Just use
> xbiff -file <netrek-dir>/logfile
> instead. Works great! 
> It has the drawback however, that you can only use it if you are 
> on the server.
> For all the others, I have this neat little shell script called trekbiff:
> ;-----------------------CUT HERE---------------------
> #!/bin/sh
> line_count=`ck_players $3 port $4 | wc -l`
> if test $line_count -gt $1
> then
>         ck_players $3 port $4 | mail $LOGNAME
> else
>         sleep $2
>         exec $0 $*
> fi
> ;-----------------------CUT HERE----------------------

Neat idea...but I'd hate to tie up my mailbox that way.  Why don't 
you have it send the output to a file instead of mailing it, and then
run xbiff on it?


---
    /\        Bharat Mediratta
   \\ \       Graphics Continuation Group
  \ \\ /      
 / \/ / /     
/ /   \//\    SUN Microsystems, Inc.	
\//\   / /    Mailstop: MTV18-218
 / / /\ /     2550 Garcia Avenue, Building 18
  / \\ \      Mountain View, CA 94043
   \ \\       Phone:  (415)336-4347, FAX:(415)336-5471
    \/        Email:  bharat.mediratta@eng.sun.com
From: sfd@soda.berkeley.edu (Scott Drellishak)
Newsgroups: rec.games.netrek
Subject: Re: Scattered Pops in INL
Date: 7 Jan 1993 19:22:56 GMT
Organization: Metaphor Computer Systems
NNTP-Posting-Host: soda.berkeley.edu

In article <gfH5m9G00YUoE=lXQU@andrew.cmu.edu> jb8n+@andrew.cmu.edu (Joseph E. Beck) writes:
)10 second granularity is much less predictable than 40 second (making
)plans based on things that may happen in 10 seconds is much more
)difficult than 40).  But 10 is just an arbitrary number.  Scott said
)his pop code worked on 1 second intervals (I think he said 1), and
)since he's the INL server hack he shouldn't have any problems.  If the
)interval is smaller, you can't take advantage of the timer as easily,
)and 1 second certainly seems a small enough interval.

I am *not* the INL server hack, I'm just Very Important.

By the way, I chose 1 second intervals because you can't divide a
planet in half -- 40 planets in 40 seconds is one planet a second,
but not one-half planet every half-second.
-- 
/--------------------------------------------------------------------------\
| Scott Drellishak   sfd@neuromancer.metaphor.com                          |
|                "Spumco ... the Danes call it quality."                   |
\--------------------------------------------------------------------------/
From: jb8n+@andrew.cmu.edu (Joseph E. Beck)
Newsgroups: rec.games.netrek
Subject: INL pop code
Date: 6 Jan 93 13:21:05 GMT
Article-I.D.: andrew.MfGqZVG00YUn895KYE
Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA


I'd like to make an INL proposal to change the pop timer from the
current 40 seconds to a 25% every 10 seconds (like the final Bronco
release).  People have commented that it doesn't make much difference
how the pops work but it *does*.  If you know that your opponents
won't be popping any armies for 30 seconds, that certainly changes
your SC bombers strategy (they're now free to ogg for awhile).  Also,
you can take an AGRI in 2 trips and be certain of it not popping in
the meantime.  If you aren't popping for awhile there's no reason to
sit in your home space and wait for armies.  It fixes this, and
shouldn't be that difficult (the code has been written).

Comments?

	joe
	Purple haze
	Lamb, Leg Of
From: dtabb@ecst.csuchico.edu (Don Tabb)
Newsgroups: rec.games.netrek
Subject: CLUE GAME site
Date: 12 Jan 93 03:26:35 GMT
Organization: California State University, Chico
NNTP-Posting-Host: hairball.ecst.csuchico.edu



%$#@##!^$%#%$#

MY NET sucks.  I was just told that it ok to have the
game here but most people will have about 20% packet 
loss.   sh*t.  ok.   NOW we have people, we have a time.
we have no server.   any SERVER GODS want to help out?

don
scorn!
dtabb@cscihp.ecst.csuchico.edu
Newsgroups: rec.games.netrek
From: mdm@hadrosaur.cis.ohio-state.edu (Michael Moore)
Subject: Re: Netrek 358: Starbase Theory & Concept
Organization: The Ohio State University Dept. of Computer and Info. Science
Date: Mon, 11 Jan 1993 20:34:14 GMT

In article <104311@netnews.upenn.edu> paulsen@eniac.seas.upenn.edu (Brian Paulsen) writes:
>
>By the way, I've yet to see a strategy of taking out a base to defeat a
>LPS actually work.  I'm sure it happens, but I would guess against only the
>most clueless of teams.
>

	I would say a good base can double your chances of taking the
last planet.  In most situations where you would bring the base up
to do this I'd say it makes it an average of 15 percent likelyhood.  

	But I certainly don't think it can hurt.  If you didn't take
the SB out you'd be in a normal ship, but your chances are still very
small....    and at least with the Base you get to have fun blowing 
enemies up until your big goose egg goes super-nova. :)

	-Michael (Ged)
-- 
|\  Michael  Delbert  Moore     _   /|     Home   : (614) 471-1937         /|
| \ OSU Student  Programmer     \`o_O'     Office : (614) 292-7161        / |
| / Undergraduate CIS major       ( )      Email  : mdm@cis.ohio-state.edu\ |
|/-------------------------        U       --------------------------------\|
From: paulsen@eniac.seas.upenn.edu (Brian Paulsen)
Newsgroups: rec.games.netrek
Subject: Re: Netrek 358: Starbase Theory & Concept
Date: 11 Jan 93 23:13:20 GMT
Organization: University of Pennsylvania

In article <1993Jan11.225420.17344@galileo.cc.rochester.edu> markiel@callisto.pas.rochester.edu (Andrew Markiel) writes:
>In article <63309@mimsy.umd.edu> leonard@mimsy.umd.edu (Leonard Dickens) writes:
>>However, remember that I am here to have fun, no other reason, and
>>part of that fun for me is the killing joy of the triple speed phasers
>>and the SMACK! of the huge base plasmas.  If I refuse to get out of
>>the base, then YOU must suck it up and deal.  Sorry, in advance, to

Hey, I understand completely.  The thing that I hate is when the base player
gets injured and people on the team start screaming about how we *must* save
our base.  I would understand if people want to protect the base (it is a
lot of fun) but I do hate when people spout bad advice over the message
board.

>Well said. (All of it).

>>-Leonard

>-Grey Elf
>markiel@callisto.pas.rochester.edu

Welcome, Elf, to TWNN!!!!!

Brian


Newsgroups: rec.games.netrek
From: exodus@IASTATE.EDU
Subject: Re: CLUE GAME time
Reply-To: exodus@IASTATE.EDU
Organization: Iowa State University
Date: Tue, 12 Jan 1993 01:09:21 GMT



 looks like it'll be a great game.....but have a
question......what day is it going to happen? you
said 6:00 PDT, but didn't give a day or a server
address? are you mailing that to us? or including
that info in your next post? thanks :)


				Exodus
From: surge@buck.cqs.washington.edu (Jonathan Sari)
Newsgroups: rec.games.netrek
Subject: Re: Netrek 358: Starbase Theory & Concept
Date: 11 Jan 93 01:06:45 GMT
Article-I.D.: buck.surge.726714405
Organization: University of Washington
NNTP-Posting-Host: buck.cqs.washington.edu

Bases can be a drain, and they can be useful.  The point is really
whether the number of slots tied up keeping the base alive (including
the base itself) is less than the number of slots tied up attempting
to kill it.

I played a base in a recent bronco game against a very good team.  I
basically picked up every spare army and sat in our space, heading to
the front for rare pickups.  Eventually (probably when they noticed
hordes of people picking up off me and scumming planets) they decided
to mount an ogg.  I lasted far longer than I deserved to, and by the
time I was ogged the enemy team was down to 4 or 5 planets, requiring
more than an hour for them to get back to even.  I don't think the
same thing would have happened if I was flying a cruiser, although I
have certainly had the opposite occur, when I was facing a team of
ogg-bait, and I was able to ogg everyone on their team who picked up
after I got ogged out of the base.  Such situations are rare, though.

If the opponents never bomb armies on planets, you never need a base.
However, against a clueful team, a base is a very effective way to
keep armies alive.  Bases also can be powerful front-line defensive
weapons, but this use can be quickly neutralized by a good team, and
against a bad team, you can win doing just about anything.

-Ensign Pac-man
Newsgroups: rec.games.netrek
From: ahabig@bigbang.astro.indiana.edu (Alec Habig)
Subject: Re: Was that the real PIG BOY?
Organization: Indiana University Astrophysics, Bloomington, IN
Date: Sat, 9 Jan 1993 12:39:50 GMT

In article <1993Jan8.192658.26745@colorado.edu> piperno@boulder.Colorado.EDU writes:
>I propose a new(?) logging in procedure:
>
>1. The player writes his name.
>2. All invisible characters are replaced by a space ' '.
>3. All series of 1 or more spaces are then replaced by one space ' '.
>4. Follow the rest of the current procedure.
>
>We may get rid of unwanted "aliases"...

I, for one, rather like the ability to use spaces.  Why?  Because someone, long
ago, in a galaxy confined to the old Bronco and Sequent, name scummed my
favorite name, "Entropy".  Although George has kindly given me the no-spaces
version on Bronco, on the legion of servers that copied the Bronco and Sequent
databases I am forced to go by "Entropy " (note the space).

So there is at least one "legitimate" use of space padding in login names :)

	Alec
	(Entropy (or Entropy ))

PS - of course, this leaves unanswered the question of "why in the hell would
I _want_ to be recognized as the same player across servers, given my usual
low level of skill", but that's because I don't have an answer to that :)
From: chris@inconel.uucp (Christian)
Newsgroups: rec.games.netrek
Subject: Re: Multiple players from same machine, outlawed on Bronco?
Date: 7 Jan 93 16:29:15 GMT
Organization: U of Wisconsin-Madison College of Engineering

In article <1993Jan7.083034.17362@alijku05.edvz.uni-linz.ac.at> siegl@risc.uni-linz.ac.at (Kurt Siegl) writes:
>In article <1993Jan5.191047.21390@wuecl.wustl.edu>, qarl@wuecl.wustl.edu (Karl Stiefvater) writes:
>> >>Bronco does not appear to allow more than one player from a single machine.
>> >>I assume this policy is meant to discourage tmode scumming... BUT...
>> 
>> A reasonable compromise might be: raise the number of players per machine
>> from 1 to 3.  This would still discourage tmode scums (they'd need three
>
>A save solution would be only a restriction on the DISPLAY.
>

There allready is a restriction on display- 1 client per X-display.

-Chris
Organization: Doctoral student, Mathematics, Carnegie Mellon, Pittsburgh, PA