HDTenEightyP/NetNews huggingface dataset:
From: deragon@JETHRO.CS.NYU.EDU (John Deragon)
Newsgroups: alt.games.gb
Subject: Re: Serious bug fix
Date: 24 Dec 1992 22:11:51 -0600
Organization: UTexas Mail-to-News Gateway
NNTP-Posting-Host: cs.utexas.edu


In article <1992Dec24.233506.28199@nwnexus.WA.COM> ninja@halcyon.com (Jonathan R
oy) writes: >
bls@sector7g.Eng.Sun.COM (Brian Scearce) writes>>



>> - Seriously, the game will be unstable until you reach a point where
>> - it's more interesting to fix non-lethal bugs than to add cool new
>> - features.  And that'll probably never happen.

	Well, I am at the point now where I am *not* adding any new
code, (well, at least not any new *features*)  I agree with you completely
that most people are happy just slapping new coats of paint (features) onto
and old house (GB).  I personally would *much* rather be doing new development
then renovation.  Where I used to work, we would have to draw straws to see
who would renovate old code, and who would get to do new development.

	I am at the point now where GB has been around long enough that I see
no-one wants to renovate, so I kinda started doing it myself. 

> (Seeker being one of them) to form a group of programmers to move GB
> coding ahead.

>> - There may be *older* versions of the game that get completely
>> - debugged and stabilized, but nobody'll want to play them because
>> - they lack the latest and greatest.  C'est la joue.

	Well, I am working with the 5.2 code.   And it is not like there
is a patch or new release of GB every week.  Jeeze...

>I was going to keep things quiet for a few more months, but I couldn't
>resist replying to your message. :) Work _IS_ being done daily, and
>you'll see GB stable within 6 months. Hopefully it'll get a large,

	Wow... talk about loose lips.... *grin*  I think ninja need to be
taught how to keep his lips closed....  "Vee have wayz to keep zee lips
shut, dear ninza!, Vee have our wayz!" 


	Sigh... (I dont t hink the newsgroup has seen so much traffic in
quite some time!

	Seeker.
From: koffleva@darkwing.uoregon.edu (A Ghost Walking in the Shadows)
Newsgroups: alt.games.gb
Subject: Re: tac command
Date: 31 Dec 1992 08:39:36 GMT
Organization: University of Oregon Network Services
Distribution: alt
NNTP-Posting-Host: darkwing.uoregon.edu

In article <23129@venera.isi.edu> rlewis@venera.isi.edu (Roger Lewis) writes:
>
>By the way, is there a setting that allows that buffer to be larger?
>
>Is <output flushed> a message that is generated by the client or the
>server?

The <Output Flushed> is SERVER generated. Not client generated.
It is technically possible to overflow gbII's buffer, but it would
lock up the client since it would be stuck in a read call.

The server-client protocol calls for every line to be newline
terminated and at present has kept lines to less than 1024 bytes.
Except for map/orbit data but the client handles these differently
so as to avoid any problems.

The server should write() the output to the person's file descriptor
instead of putting the <Output Flushed>. I've just never taken the
time to fix this.
>


Newsgroups: alt.games.gb
From: ddickey@aspen34.cray.com (Dan A. Dickey)
Subject: Re: Serious Bug fix....
Originator: ddickey@aspen34
Organization: Cray Research, Inc.
Date: 23 Dec 92 09:01:29 CST


In article <15215.2b37e39a@ohstpy.mps.ohio-state.edu>, vancleef@ohstpy.mps.ohio-state.edu writes:
> In article <1992Dec22.184322.8933@nwnexus.WA.COM>, ninja@halcyon.com (Jonathan Roy) writes:
> >  - Thanks for Valheru (ninja@halcyon.com) for pointing this one out
> > 
> > Sure thing. :) Since I can't code, yet, reporting bugs is the best
> > I can do. :D
> > 
> > Great job on your coding so far! We'll stir up new interest yet!
> > 
> > -- 
> >   F F  Jonathan Roy, Vice President, Free Access Foundation.    GEnie: J.ROY18
> 
> I thought that the way I did the do_shiplist() and inlist() stuff was pretty
> slick! It allowed the programmer to put in stuff like 'rep CDes' or 
> 'stock cd #1234' etc.
> 
> Take that stuff out and you really have something that stinks :) With my
> code you can do 'load p fc' as opposed to loading 1000 pods by hand. Give me
> a break please :)
> 
> -Garrett

The 'load p c' vs. hundreds of 'load #xyz c' is a fantastic
improvement.  Without it, metas would be unplayable.
(Unless of course, you have some "smart" interface that will handle
 it all for you).
In either case, it was a huge win when it appeared...
	-Hydra
-- 
---------
Dan A. Dickey      ddickey@cray.com
From: rlewis@isi.edu (Roger Lewis)
Newsgroups: alt.games.gb
Subject: tac command
Date: 30 Dec 92 07:09:39 GMT
Reply-To: rlewis@venera.isi.edu (Roger Lewis)
Distribution: alt
Organization: USC-Information Sciences Institute


If I'm at a stellar scope and type: tac d
why does the server insist on giving me tac reports for all the planets 
in the system in addition to the tac for the destroyers?  I find this
a bit annoying, particularly since I'd like to do one big "tac d" at
universal scope and detect anything I can blow up WITHOUT getting an
<output flushed> message due to all the planetary tactical reports
filling up the (client's?) buffer.

By the way, is there a setting that allows that buffer to be larger?

Is <output flushed> a message that is generated by the client or the
server?
From: deragon@JETHRO.CS.NYU.EDU (John Deragon)
Newsgroups: alt.games.gb
Subject: Serious Bug fix....
Date: 22 Dec 1992 03:35:47 -0600
Organization: UTexas Mail-to-News Gateway
NNTP-Posting-Host: cs.utexas.edu


	The following is a context diff patch for the file shlmisc.c
It corrects a SERIOUS bug in the current GB version (GB5.2).  


	OVERVIEW:

	If you scrap a ship, it will kill the ship (ie: set the alive flag 
to false), but it will not remove it from the linked list until an 
update occurs.  Therefore, the dead ship will remain around, if you scrap
the same ship again, it will get a list of the ships via do_shiplist
and the now dead ship will still exist in the list.  This totally screws
things up, and you will end up scrapping whatever ship the nextship 
struct member points to. 


	FIX:

	Basically, this is a serious bug.  I seriously recommend patching
your shlmisc.c file if you have it.  It is basically a two line fix


	do_shiplist(...) 
	
		if (!(*s)->alive))
			return 0;

	but I did some additional formatting in that function for clarity.
This is only a temporary fix, I plan to clean this whole shiplist crap
up ALOT.  This way is pretty stupid.  

	Thanks for Valheru (ninja@halcyon.com) for pointing this one out


	-- Seeker	

-------------- BEGIN CONTEXT DIFF -------------

*** shlmisc.c   Tue Dec 22 03:45:17 1992
--- old/shlmisc.c       Tue Dec 22 03:41:15 1992
***************
*** 333,348 ****
  int do_shiplist(shiptype **s, int *nextshipno)
  {
      int shipno;

!     if (!(shipno = *nextshipno))
!               return 0;
!
!     if (!getship(s, shipno))  /* allocate memory, free in loop */
!               return 0;
!
!       if (!(*s)->alive)) /* this prevents it from returning a dead ship */
!               return 0;      /* ie: try to scrap a dead ship   JPD          */
!
      *nextshipno = (*s)->nextship;
      return shipno;
  }
--- 333,343 ----
  int do_shiplist(shiptype **s, int *nextshipno)
  {
      int shipno;
+     if(!(shipno = *nextshipno))
+       return 0;

!     if(!getship(s, shipno))   /* allocate memory, free in loop */
!       return 0;
      *nextshipno = (*s)->nextship;
      return shipno;
  }
Newsgroups: alt.games.gb
From: fxmar@acad3.alaska.edu
Subject: Source needed.
Organization: University of Alaska Fairbanks
Date: Wed, 30 Dec 1992 02:14:13 GMT

        I need the source code for gb.  Please send me an ftp site.

thanks,

-mark
Newsgroups: alt.games.gb
From: ninja@halcyon.com (Jonathan Roy)
Subject: Re: Serious bug fix & GBDT/FAF
Organization: The 23:00 News and Mail Service
Date: Thu, 24 Dec 1992 23:35:06 GMT

 - > Maybe in a few months when GB is at a state of stability [...]
 
 - (chuckle)
 
 - Humanity Version 2.3 the All-Knowing predicts for 1993 that the game
 - will continue to be unstable during the course of the year.  You
 - read it here first.
 
Well, you are wrong... Sorry. :D
 
 - Seriously, the game will be unstable until you reach a point where
 - it's more interesting to fix non-lethal bugs than to add cool new
 - features.  And that'll probably never happen.
 
It's already happened... I've gotten a lowly band of people together
(Seeker being one of them) to form a group of programmers to move GB
coding ahead.
 
 - There may be *older* versions of the game that get completely
 - debugged and stabilized, but nobody'll want to play them because
 - they lack the latest and greatest.  C'est la joue.
 
5.2 is the basis for GBDT .1a... Eventually to be 1.0 once all the new
code is finished and reasonably debugged. If you want to get in on the
ground floor, join Seeker's new game. It uses the new database code,
which is extremly anti-corrupt proof, and is over 30% faster than the
old code.
 
I was going to keep things quiet for a few more months, but I couldn't
resist replying to your message. :) Work _IS_ being done daily, and
you'll see GB stable within 6 months. Hopefully it'll get a large,
strong player base, and move up there to the level Empire is at.
 
--
 
Ok, so who are these people? Well, we're going to withhold any real
"announcement" for a while longer... Basicly, the FAF is going to run a
year-round GB server, starting with a Sun IPX. This will be running as
early as mid-January, but probably not until mid-February. The FAF
systems themselves may not be online until March or so, but we hope to
have GB up and running ASAP. 
 
With the new dedicated system, we'll have multiple games all year, an
archive site, etc. Other basic plans are for a telnet accessable
racegen and client. I can't really go into more detail quite yet.
You are welcome to email me with any specific questions, however.
 
-- 
  F F  Jonathan Roy, of the Free Access Foundation    Email: ninja@halcyon.com
   A   Mail faf@halcyon.com for information, or FTP to halcyon.com:  /pub/faf/
  F F  Valheru, of the Galactic Bloodshed Development Team      GEnie: J.ROY18
 "Everything that has transpired has done so according to my design." - _RotJ_
From: deragon@JETHRO.CS.NYU.EDU (John Deragon)
Newsgroups: alt.games.gb
Subject: Duh!
Date: 22 Dec 1992 03:49:44 -0600
Organization: UTexas Mail-to-News Gateway
NNTP-Posting-Host: cs.utexas.edu



	Sorry bout that... I posted the wrong context diff in the previous
message.  (it is 4am after all!)


	This is the correct one!
		-- Seeker

----- BEGIN (CORRECT) CONTEXT DIFF -----

*** shlmisc.c	Tue Dec 22 04:42:20 1992
--- oldshlmisc.c	Tue Dec 22 04:42:13 1992
***************
*** 333,348 ****
  int do_shiplist(shiptype **s, int *nextshipno)
  {
      int shipno;
  
!     if (!(shipno = *nextshipno))
! 		return 0;
! 
!     if (!getship(s, shipno))	/* allocate memory, free in loop */
! 		return 0;
! 
! 	if (!(*s)->alive) /* this prevents it from returning a dead ship */
! 		return 0;      /* ie: try to scrap a dead ship   JPD          */
! 
      *nextshipno = (*s)->nextship;
      return shipno;
  }
--- 333,343 ----
  int do_shiplist(shiptype **s, int *nextshipno)
  {
      int shipno;
+     if(!(shipno = *nextshipno))
+ 	return 0;
  
!     if(!getship(s, shipno))	/* allocate memory, free in loop */
! 	return 0;
      *nextshipno = (*s)->nextship;
      return shipno;
  }
From: deragon@HARPO.CS.NYU.EDU (John Deragon)
Newsgroups: alt.games.gb
Subject: ftp site needed
Date: 31 Dec 1992 18:57:43 -0600
Organization: UTexas Mail-to-News Gateway
NNTP-Posting-Host: cs.utexas.edu


	I have a new version of GB (based upon GB5.2) that has numerous bug
fixes, and a few server changes, and I am in need of a site that I can
post it to, so that interested people can easily retrieve it.  Does anyone 
ave a site that I can post a 350K compressed tar archive to, and also 
post updates to?  

	If you do have one, or know of one, please send me mail at 
'deragon@jethro.nyu.edu'.  

	Also,  if anyone has the HAP code, please drop me a line, as I would
like to get the autoload and threshload code from it.


-----
John Deragon		   deragon@cs.nyu.edu | deragon@jethro.cs.nyu.edu
-----
From: bls@sector7g.Eng.Sun.COM (Brian Scearce)
Newsgroups: alt.games.gb
Subject: Re: Serious bug fix
Date: 24 Dec 1992 22:22:38 GMT
Organization: Sun Microsystems, Inc.
Distribution: world
Reply-To: bls@sector7g.Eng.Sun.COM
NNTP-Posting-Host: sector7g

In article AA20631@JETHRO.CS.NYU.EDU, deragon@JETHRO.CS.NYU.EDU (John Deragon) writes:
> Maybe in a few months when GB is at a state of stability [...]

(chuckle)

Humanity Version 2.3 the All-Knowing predicts for 1993 that the game
will continue to be unstable during the course of the year.  You read
it here first.

Seriously, the game will be unstable until you reach a point where it's
more interesting to fix non-lethal bugs than to add cool new features.
And that'll probably never happen.

There may be *older* versions of the game that get completely debugged
and stabilized, but nobody'll want to play them because they lack the
latest and greatest.  C'est la joue.

---
Brian Scearce                                           bls@sector7g.eng.sun.com
              The above does not necessarily represent Sun policy.
                  "You can't fit the truth on a t-shirt, man."
                                 "That'd fit."

Newsgroups: alt.games.gb
From: ninja@halcyon.com (Jonathan Roy)
Subject: Re: Serious Bug fix....
Organization: The 23:00 News and Mail Service
Date: Thu, 24 Dec 1992 05:19:01 GMT


 - With my code you can do 'load p fc' as opposed to loading 1000 pods
 - by hand. Give me a break please :)
 
Well, in the most recent 5.2 you've released, "load p fc" doesn't
work.

It simply loads fuel. Haven't tried the other commands since I don't
have enough ships to try... Is that a new command you have only in
your own version? (5.3?)
 
-- 
  F F  Jonathan Roy, of the Free Access Foundation    Email: ninja@halcyon.com
   A   Mail faf@halcyon.com for information, or FTP to halcyon.com:  /pub/faf/
  F F  Valheru, of the Galactic Bloodshed Development Team      GEnie: J.ROY18
 "Everything that has transpired has done so according to my design." - _RotJ_
From: starride@silver.ksu.ksu.edu (David Chase)
Newsgroups: alt.games.gb
Subject: Re: Surface temperatures (errata)
Date: 29 Dec 1992 02:36:15 -0600
Organization: Kansas State University
NNTP-Posting-Host: silver.ksu.ksu.edu

	Sounds alot like SimEarth to me. Surface temperature, material reflectability, atmosphereic depth, and of course population and the like.

	Just my two cents worth. (at least thats how much I value it)


		David Chase



Newsgroups: alt.games.gb
From: ninja@halcyon.com (Jonathan Roy)
Subject: Re: Serious Bug fix....
Organization: The 23:00 News and Mail Service
Date: Thu, 24 Dec 1992 16:53:19 GMT

 - My stuff is done on the server, and only one command needs to be
 - sent, instead of 200. It is, in fact, the most efficient way to do
 - it.
 
Yes, I'm aware of that, but how much stuff should go in the server?
Should all of gbII go in there? It's more efficient in that there's
only one copy of it needed, and all the players don't use up 200-400K
of space to run it...
 
Seeker's code allows multiple builds at once, but I don't use it. Even
if I build 200 pods very fast, and even if "load p cf" worked, it's
still be a pain to order them to seperate destinations. I'd either
need
to use a client for loop, if they were sequentially numbered, order do
it by hand. When I do:
 
repeat 50 /bup 1,1 5 /Ando
repeat 50 /bup 1,1 4 /Spic
repeat 50 /bup 1,1 6 /Herm
 
It does it all for me... And it's just not that slow. :) Oh well.
Everyone has their own ideas, and that's what makes games like this so
fun to play. :D It's better to debug what exists, however, than to
keep adding new code.
 

-- 
  F F  Jonathan Roy, of the Free Access Foundation    Email: ninja@halcyon.com
   A   Mail faf@halcyon.com for information, or FTP to halcyon.com:  /pub/faf/
  F F  Valheru, of the Galactic Bloodshed Development Team      GEnie: J.ROY18
 "Everything that has transpired has done so according to my design." - _RotJ_
From: cfodor@sdcc13.ucsd.edu (Hi.)
Newsgroups: alt.games.gb
Subject: Re: Serious Bug fix....
Date: 24 Dec 92 16:24:14 GMT
Organization: University of California, San Diego

In article <15225.2b392069@ohstpy.mps.ohio-state.edu> vancleef@ohstpy.mps.ohio-state.edu writes:
>In article <1992Dec23.172334.19507@nwnexus.WA.COM>, ninja@halcyon.com (Jonathan Roy) writes:

>> [Use repeat]

GVC responds:

> [repeat sends 200 packets as opposed to 1 packet doing it all
>  which is wasteful of packets.]

Yes, but then all the other players have to wait for that command
to finish before theirs get processed which gets annoying.  GB is
an entire waste of packets anyways so who are we kidding?  We could
save millions more packets by cleaning up news and tact if we were
worried about packets... :)

Some macros I have do the following:

build the pod, load it with an individual amount of fuel for its
destination, load a dude into it, launch it, name it (just for fun,
and always based on its ship number and destination of coure), and 
sends it on its merry way.  

By making these things parameters to a macro and using the repeat
command I can make multiple pods with different destinations which
I couldn't currently do otherwise.   Is this more wasteful of
processing power?  Sure it is.  But there is one thing we have
forgotten to mention... Like sex, until you have done:

repeat 200 /bup YourSys 3 

(build 200 pods, named "YourSys<ShipNo>", load them with 3 fuel and
send them on their merry way... this does not affect pods already 
built... I could do repeat 200 /bup NextDoor 1 next without
affecting the pods I've already built.)

And watched it working you don't know how it feels... :)  (Side
note:  Sex is way better so if you've got to choose one or the other
pass up on the macros. )

Could you implement this on the server?  Sure you could!
load p f 3 and launch p and ord p dest /XXX is getting there... 
but the client is still far more powerful because that is it's 
primary purpose... to help format commands sent to the 
server.  The server programmer has to deal with the database, 
and buggy commands not to mention whiny players, and system 
administrators.  Don't burden yourself with extra work when
we've got the laws of a universe to mold!

My thoughts on this subject are finished.

--------------------------------------------------------------
Chris Fodor                           cfodor@UCSD.edu
Disclaimer:  Why am I posting here when I have 800+ articles
left in alt.sex?????
--------------------------------------------------------------
Newsgroups: alt.games.gb
From: matrix@sol.acs.unt.edu (Goodman Byron)
Subject: GB
Summary: Is there a GB server up anywhere?
Keywords: game
Organization: University of North Texas
Date: Wed, 30 Dec 1992 19:17:23 GMT

Is there a game of GB going on.  If so please leave me mail giving me
tha address.  

One other thing, anyone know if there is PC version of the client
software?
From: vancleef@ohstpy.mps.ohio-state.edu
Newsgroups: alt.games.gb
Subject: Surface temperatures (errata)
Date: 27 Dec 92 05:14:01 EST
Organization: The Ohio State University, Department of Physics

I forgot to mention that the discontinuity of the blackbody function
at the surface is what is know as the (negative) adiabatic lapse rate.
This causes a rapid decrease of the atmospheric temprature near the
surface upwards (for the earth it is about -6K/km).

-Garrett
From: koffleva@darkwing.uoregon.edu (A Ghost Walking in the Shadows)
Newsgroups: alt.games.gb
Subject: Re: Serious bug fix
Date: 25 Dec 92 05:19:46 GMT
Organization: University of Oregon Network Services
NNTP-Posting-Host: darkwing.uoregon.edu

>	Sigh... (I dont t hink the newsgroup has seen so much traffic in
>quite some time!

WHAT??!?!?!? THIS IS A NEWSGROUP?????????????

And I thought it was a figment of my imagination.

>
>	Seeker.
>

Evan (aka, Keeshans)
Newsgroups: alt.games.gb
From: ninja@halcyon.com (Jonathan Roy)
Subject: Re: Serious Bug fix....
Organization: The 23:00 News and Mail Service
Date: Wed, 23 Dec 1992 17:23:34 GMT

 - P.S. - Now...if someone could just get around to modifying the build
 - command to handle something like 'build 200 p 0,0' !!

You mean,

repeat 200 build p 0,0

?

THere's no need to add something to the server that the client already
does. Sure, if you telnet in you can't do that, but almost everyone
there is uses gbII or Feep's IBMish client. (It is Feep, isn't it?)

THere's a limit to how much stuff should be moved from the client to
the server. Gotta keep the server size down and all... Like, there's
no reason to move opttech from the client to the server. It'd just
use up memory, and slow things down for everyone when one player
ran it.

The only thing I"d like to see moved to the server from gbII is the
formatting of maps. Maybe not even highlighting, but just the
ability to format maps correctly. THis would make GB playable
via telnet, or at least far more than it is now.

-- 
  F F  Jonathan Roy, of the Free Access Foundation    Email: ninja@halcyon.com
   A   Mail faf@halcyon.com for information, or FTP to halcyon.com:  /pub/faf/
  F F  Valheru, of the Galactic Bloodshed Development Team      GEnie: J.ROY18
 "Everything that has transpired has done so according to my design." - _RotJ_
From: d89magni@odalix.ida.liu.se (Magnus Nilsson)
Newsgroups: alt.games.gb
Subject: Re: Surface temperatures (text)
Date: 29 Dec 92 00:31:00 GMT
Organization: CIS Dept, Univ of Linkoping, Sweden

When I was playing Traveller (The roleplaying game) I had a rulebook
named "scouts" that had quite neat formulaes for calculating 
temperature. Using the guidelines in that book might be a good
idea.

Magnus.
Newsgroups: alt.games.gb,rec.games.misc
From: logan@torag.guild.org (Scott I. Logan)
Subject: dial-in GB starting in Toronto
Date: Thu, 24 Dec 92 01:53:49 GMT
Organization: Unix Hackers Anonymous
Followup-To: poster
Distribution: tor

Since I don't have access to the "real" Internet yet, I'm planning to start a
GB game on the Sun I have at home.  (Playing against myself is, as you can
imagine, a little boring.)

My Sun has two dial-in lines and is up 24 hours.  I'm in Don Mills, so if
that's a local call for you and you're interesting in playing, drop me a note.
I'm planning on a reasonably slow-paced game, with one or two updates a day max
(after the first few, anyway).  I've got the latest source from scam, and I
have documentation on-line for those who need it.

For those people outside the Toronto area who are reading this... sorry!
"Distribution"s aren't what they used to be (and never were :-).

	- Scott

Scott Logan                                                   logan@guild.org
Torag Communication Systems, Toronto, Ontario           ...!uunet!torag!logan
From: vancleef@ohstpy.mps.ohio-state.edu
Newsgroups: alt.games.gb
Subject: Re: Serious Bug fix....
Date: 24 Dec 92 02:28:57 EST
Organization: The Ohio State University, Department of Physics

In article <1992Dec23.172334.19507@nwnexus.WA.COM>, ninja@halcyon.com (Jonathan Roy) writes:
>  - P.S. - Now...if someone could just get around to modifying the build
>  - command to handle something like 'build 200 p 0,0' !!
> 
> You mean,
> 
> repeat 200 bui
> Well, think about what it is you are actually doing. When you tell your
client to repeat the command 200 times, 200 packets are sent over the
network, and this bogs down the server. My stuff is done on the server,
and only one command needs to be sent, instead of 200. It is, in fact,
the most efficient way to do it.

-Garrett

> -- 
>   F F  Jonathan Roy, of the Free Access Foundation    Email: ninja@halcyon.com
>    A   Mail faf@halcyon.com for information, or FTP to halcyon.com:  /pub/faf/
>   F F  Valheru, of the Galactic Bloodshed Development Team      GEnie: J.ROY18
>  "Everything that has transpired has done so according to my design." - _RotJ_
Newsgroups: alt.games.lynx