HDTenEightyP/NetNews huggingface dataset:
From: foregone@stein.u.washington.edu (Carl Chavez)
Subject: Re: Battletech: The Great Debate.
Organization: University of Washington, Seattle
Date: Wed, 23 Dec 1992 00:30:17 GMT

In article <1992Dec21.100036.14136@midway.uchicago.edu> fks1@midway.uchicago.edu writes:

>btw, what is the shareware version? is it out for the mac? or just 
>ibm, sigh.
>
>Scaramouche
>-- 
>>>>----------------fks1@midway.uchicago.edu-------------------------<<<
>"Reality is the only word...that should always be in quotes." -MLW/TTKC
>"I am afraid , monsieur, you will have to kill me first and i have a
>   prejudice against being killed before nine o'clock."    -Scaramouche

There is Mechwar for the IBM, which I haven't seen yet; and there is
Mechforce for the Amiga, which is like the Solaris VII rules.

You know, the funny thing about Mechforce is that it's rules are very similar
to the Solaris VII rules, but Mechforce came out in 1988/1989!!!

Stephane, could you elaborate on the origin of the Solaris rules so we
can be sure that FASA didn't rip Ralph Reed off?


Newsgroups: rec.games.mecha
From: H8KI <H8KI@UNB.CA>
Subject: A small rules question
Organization: The University of New Brunswick
Date: Sat, 2 Jan 1993 01:44:14 GMT

 I've been playing battletech for quite a few years now, and have
always wondered about this one simple thing. How long is one round
of combat. This may seem simple, and is probably mentioned somewhere
in any one of the multitude of books from the Rules Of Warfare
onward, but I personnally have never been able to find it. Just
curious, don't mean to be ignorant or anything.
                                  Chris Baker
From: gt7804b@prism.gatech.EDU (Wayne Edward Sheppard)
Newsgroups: rec.games.corewar
Subject: Outlaw ImpRings? - There's a better way
Date: 30 Dec 92 22:22:51 GMT
Organization: Georgia Institute of Technology

I don't know about the rest of you, but these imprings has made
corewar boring.  But we shouldn't change the rules to fight them.
How about changing the core size.  8000 is too friendly for imps.
Do imprings work good when there are alot of points?  A coresize
of 9000 would make the smallest impring have 7 points.  Is this 
enough?  8400 core size would require 11 point rings.  

If an impring had more points, wouldn't it be easier to kill?



-- 
Wayne Edward Sheppard
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt7804b
Internet: gt7804b@prism.gatech.edu
From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins)
Newsgroups: rec.games.corewar
Subject: Something more about PCT instrution...
Date: 29 Dec 92 14:52:29 GMT
Organization: Ohio University CS Dept., Athens


Hmmm... think about this as well...

	dat #5, #5
	dat #0, #0
start	pct 0
	mov -3, <-1
	mov -4, <-2
	end start

Ok, the instruction if "start" is first protected, and will last for one
modification attempt.  Then the "mov -3, <-1" is executed.  Since there is
a predecrement in the B-Field and it is on a protected field, it will fail
and the protection is removed from the address "start".  This means that
the effective address of "<-1" turns out to be 0 instead of -1, had the
predecrement been successful.  Well, now the mov instructions is evaluated.
"mov -3, -1 (essentially)" (would have been "mov -3, -2 if predec was good)
then grabs the "dat #5, #5" and overwrites the "pct 0" instruction.  

So, what I am saying is this... you can first unprotect an instruction with
a predecrement or postincrement (yes, I have them too) and then overwrite
them with the same instruction.  Is this good?

(If you haven't notice, I do advocate the PCT instruction.  Give me a good
reason why not to have it... "Too powerful" is not a good execuse judging 
from the above example!)

Scott
-- 
         Scott W. Adkins           Internet: sadkins@ohiou.edu
         ~~~~~~~~~~~~~~~                     ak323@cleveland.freenet.edu
    Ohio University of Athens        Bitnet: adkins@ouaccvma.bitnet
From: starr-daniel@yale.edu (Daniel Starr)
Newsgroups: rec.games.corewar
Subject: Re: Outlaw ImpRings? - There's a better way
Date: 3 Jan 1993 01:27:41 -0500
Organization: Yale University Science & Engineering UNIX(tm), New Haven, CT 06520-2158
NNTP-Posting-Host: minerva.cis.yale.edu

In article <1993Jan2.170839.4347@vlsi.polymtl.ca> dak@shannon (Pierre Baillargeon) writes:
>Daniel Starr (starr-daniel@yale.edu) wrote:
>: In article <78903@hydra.gatech.EDU> gt7804b@prism.gatech.EDU (Wayne Edward Sheppard) writes:
>: > [deleted]
>: >
>: >If an impring had more points, wouldn't it be easier to kill?
>: >
>: Nope.  The nifty thing about an impring, after all, is that just like
>: a classic imp, each instruction prepares the very next one that executes.
>: As a result, no matter how many points there are, only one -- the one
>: about to execute -- is vulnerable to bombing/mutation at any given time.
>:
>: [deleted]
>
>  Well, a ring with more points has more vulnerable point and move slower.
Actually, no.  A single ring only has one vulnerable point:  the location
about to execute.  If you bomb any other location, it will be overwritten
before it's executed.  And all rings overwrite one location per cycle --
more points just mean those locations are spread out more.

-- 
--------------------------------------------------------------------
|Daniel Starr                | "Wait! Wait! Maybe THIS will work!" |
|dstarr@minerva.cis.yale.edu |                                     |
--------------------------------------------------------------------
From: dak@zuse (Pierre Baillargeon)
Newsgroups: rec.games.corewar
Subject: imperor
Date: 22 Dec 92 21:35:07 GMT
Organization: Ecole Polytechnique de Montreal
X-Newsreader: TIN [version 1.1 PL6]


A simple B-scanner, with a splat carpet bombing: spl <0,<6. After a while,
it switch to dat bombs.

;redcode
;name Imperor III 
;kill Imperor II
;strategy I:	terror of imps (not!).
;strategy II:	smaller.
;strategy III:	splat bomb.

top	mov bomb,sleep
reset	add #5,count
search	sub #2365,ptr
ptr	jmz search,0	; every 5 instr. must be zero.
	add #5,ptr
kill	mov sleep,<ptr
count	djn kill,#5
	djn reset,#500
	jmp top,0
bomb	dat #0,#0
sleep	spl <0,<6
		
	end search

--
"Pis Bourassa qui est toujours la.  Y'a pas d'remede contre le SIDA" - French B
...........................................................dak@info.polymtl.ca
Newsgroups: rec.games.corewar
From: news@news2.cis.umn.edu (Usenet News Administration)
Subject: Just a test post.  ***IGNORE***
Organization: University of Minnesota
Date: Sat, 2 Jan 1993 05:36:12 GMT

This article was probably generated by a buggy news reader.
From: wangsawm@prism.CS.ORST.EDU (W. Mintardjo)
Newsgroups: rec.games.corewar
Subject: Paratroops v1.2 (KotH's November-December 1992 warrior)
Date: 21 Dec 92 08:59:47 GMT
Article-I.D.: flop.1h4123INNese
Organization: CS Dept, Oregon State University
NNTP-Posting-Host: prism.cs.orst.edu


This is an Anti-IMP program. It works fine against stone and/or spiral program.
It also beats silent scanners that don't use decoys, colored bombs, djn trail,
etc (i.e No Mucking About, B-Scanners L.I.V, etc)

Against other scanners, vampires and papers, this program still needs major 
improvements.

Statistic result against spiral/stone programs:
Warrior          Win     Lose     Tie 
=====================================
It                54       38       8
Imprimis 3        57       25      18
+0 Stormbringer   63       27      10
Midnight          56       30      14
Impression v4     48       32      20

--- W. Mintardjo

;redcode 
;name Paratroops v1.2
;author W. Mintardjo

init    EQU incr+98
dist    EQU 47

step    DAT #98, #98
incr    ADD step, scan
scan    CMP init, init+dist
        SLT #last+dist, scan
        JMP incr
        MOV step, <scan
        DJN -1, #dist+3

launch  ADD #1600, ptr1
        MOV s4, @ptr1
        MOV s3, <ptr1
        MOV s2, <ptr1
ptr1    SPL @ptr1, s2+500
        MOV s1, <ptr1
        DJN launch, #5

s1      dat <-4,<-5
s2      spl 0,<-3
s3      mov -2,<-4
s4      jmp -1,<-5

last    END scan

PS: About line s1-s4, I believe Matt Hastings still has the other variation.

-- 
I wish I could update this message:
"This program posts news to thousands of machines throughout the entire
 civilized world.  Your message will cost the net hundreds if not thousands of
 dollars to send everywhere.  Please be sure you know what you are doing."
From: gt7804b@prism.gatech.EDU (Wayne Edward Sheppard)
Newsgroups: rec.games.corewar
Subject: Stuff
Date: 28 Dec 92 16:54:10 GMT
Organization: Georgia Institute of Technology

Here is some code that is kind of interesting.  The first is a three
line dwarf that goes to a coreclear when the add instruction is
decremented.

mov <-7,<3045
add #3044,-1
jmp -2,<-9

This next dwarf tries to full time imp stomp, but doesn't work good

	add #3046,@2
start	mov -5,<-5
	jmp -2,<-6



-- 
Wayne Edward Sheppard
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt7804b
Internet: gt7804b@prism.gatech.edu
From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins)
Newsgroups: rec.games.corewar
Subject: PCT instruction... a musing...
Date: 29 Dec 92 01:36:13 GMT
Organization: Ohio University CS Dept., Athens


Here is a thought... if the PCT instruction is implemented, it would 
protect that instruction from being overwritten for one attempted write
(in which afterwards it would go into the regular state again).  

The question is this... if you protect your own instructions, then should
that program still be allowed to overwrite the protected instructions, or
does the protection protect the instruction from everything, including the
process that protected that instruction in the first place?  

Incendentally, my Deluxe package is nearing the mark of its release.  I
still have to add the Write Limit in and finish the PCT instruction (which
will only take me a minute...).  I currently have the ANSI display (which
will work on both PC's and Unix), the Curses display and the Summary display
for the dumb terminals.  I will also add the PCTEXT display tonight which
will allow PC's to directly write to the display (oh, by the way, this 
version will work on the PC *and* Unix systems this time).  It will be
about a month from now before I get the XWindows and the PC Graphics displays
written, since school is starting up and I will once again have access to
that kind of stuff.

If I get enough requests, I will release version 2.0 without the XWindows
and the PC Graphics displays.  Version 2.1 would then contain the missing
displays.  This version is a major major improvement over the previous
release... now has working Equates, Full expression evaluation, supports
the '86, '88 and Extended/Experimental Standards, supports the PCT and
XCH instructions, lots of command line options, etc. etc.  This version
also works great on a PC... including an old XT with 640k  (runs easily 
in 128k).  Oh, did I mention that this version is TWICE as fast as the 
previous version?   (Still twice as slow as KotH, but I am getting there.)

Well, anyway... send me EMail on the above PCT instruction and on whether
you want me to release the Deluxe package the way it is now... without
the graphical displays...

Thanks, and keep on programming!!! ;-)
Scott
-- 
         Scott W. Adkins           Internet: sadkins@ohiou.edu
         ~~~~~~~~~~~~~~~                     ak323@cleveland.freenet.edu
    Ohio University of Athens        Bitnet: adkins@ouaccvma.bitnet
From: zimmer@marvin.or.uni-bonn.de (Carsten Zimmer)
Newsgroups: rec.games.corewar
Subject: corewar description
Date: 31 Dec 92 13:04:07 GMT
Organization: Research Institute for Discrete Mathematics, Bonn

hello,
were can I find a description of the 'corewar language' and and environment
to develop and test own programs?

	Carsten
From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins)
Newsgroups: rec.games.corewar
Subject: Newsgroup archives at soda...
Date: 2 Jan 93 01:40:45 GMT
Organization: Ohio University CS Dept., Athens

When does the archive at Soda get updated for this newsgroup?  I am in 
the process of updating my warrior library and will be collecting all
of the warriors ever posted to this newsgroup.  The last archive put 
at Soda was in March.  Who is in charge of this archive and when will
it get updated next?  

When I finish with my warrior library, I will be sure to announce it
and place it out on FTP.  It will be compatible with IBM PC's (this means
that I will have to truncate some filenames) and will all be very
organized.  I think I will have them sorted as follows:
    rec.games.corewar posting, valentine tournament, some of my own,
    various years of ICWS tournaments (all separated by year), and 
    finally the traditional warriors (dwarf, imp, etc).

My intention is to make these warriors easily accessable to my impending
release of the next version of Core Wars Deluxe.  The new version will
allow you to specify a list of paths (in a config file even) that will
guarentee you that if it could not find the given warrior in the current
directory, then it will search your warrior patch and use the first 
warrior it finds that matches what you supplied on the command line.
This will make it easier to sort your warriors when developing new ones
to test against the vast arsenal of what you have already collected.

Incedentally... there will be about 200 warriors in this collection. 
They will all be unmodified from the original posting.  The ones I 
have collected from other sources will be left unmodified by me, but
I cannot guarentee that they weren't modfied before I got them to 
begin with. 

If you would like to add *your* warriors to this library, just send 
Email to me and we will discuss them.   Send mail to sadkins@ohiou.edu.

Thanks.
Scott
-- 
         Scott W. Adkins           Internet: sadkins@ohiou.edu
         ~~~~~~~~~~~~~~~                     ak323@cleveland.freenet.edu
    Ohio University of Athens        Bitnet: adkins@ouaccvma.bitnet
Newsgroups: rec.games.corewar
Organization: Arizona State University
Date: Friday, 1 Jan 1993 16:07:42 MST
From: <AZNXS@ASUACAD.BITNET>
Newsgroups: rec.games.corewar
Subject: readme.txt about systems

I think it would be helpfull to have a readme.first file on soda in the
systems directory. So if you (the authors of the systems) send me the
description of your systems and I make up a file of them and upload it
to soda.
Nandor.          <aznxs@asuacad.bitnet>
From: starr-daniel@yale.edu (Daniel Starr)
Newsgroups: rec.games.corewar
Subject: Re: Outlaw ImpRings? - There's a better way
Date: 31 Dec 1992 06:16:17 -0500
Organization: Yale University Science & Engineering UNIX(tm), New Haven, CT 06520-2158
NNTP-Posting-Host: minerva.cis.yale.edu

In article <78903@hydra.gatech.EDU> gt7804b@prism.gatech.EDU (Wayne Edward Sheppard) writes:
>I don't know about the rest of you, but these imprings has made
>corewar boring.  But we shouldn't change the rules to fight them.
>How about changing the core size.  8000 is too friendly for imps.
>Do imprings work good when there are alot of points?  A coresize
>of 9000 would make the smallest impring have 7 points.  Is this 
>enough?  8400 core size would require 11 point rings.  
>
>If an impring had more points, wouldn't it be easier to kill?
>
Nope.  The nifty thing about an impring, after all, is that just like
a classic imp, each instruction prepares the very next one that executes.
As a result, no matter how many points there are, only one -- the one
about to execute -- is vulnerable to bombing/mutation at any given time.

But imprings aren't that hard to kill.  You just need to decrement a lot
in front of your program.  A program like this

spl 0, <-3
mov <-3,<-4
djn -1,<-5

will cause ANY impring or spiral to crash when it hits the line three above
the top.  (In point of fact, any program with an SPL 0 can't lose to an impring,
although it can tie, since an impring kills programs by subverting them and
letting them die when they outrun the slower ring into core.)
(This also illustrates the real advantage of "spirals" -- overlapping offset
rings:  each has its vulnerable instruction in a different place at any
given time, so a single djn stream can't hit both:  if it hits one, it
necessarily bypasses the other.)

Anyway, unless I'm overlooking something (comments, anyone?), the only
disadvantage of larger imprings is that they're messier to launch.

Speaking of launches, anyone found a simpler way than this? --

d EQU 8001/7
imp mov 0,d
start mov imp,100
spl 1
spl 1
spl 1
jmp <launch
jmp main-program
jmp start+100+d*6
jmp start+100+d*5
jmp start+100+d*4
jmp start+100+d*3
jmp start+100+d*2
jmp start+100+d*1
jmp start+100+d*0
launch  dat #0
...
main-program ...

For spirals, add a MOV imp,100+d at the top, an extra SPL 1, and precede
each of the normal JMP start+100+d*n statements with a JMP start+100+d*(n+1).
This creates two rings, the first always one instruction ahead of the second.

(I'm assuming here that I am correctly interpreting when Dan N. means by
spirals.  If I'm not, please enlighten me. (:  )

-- 
--------------------------------------------------------------------
|Daniel Starr                | "Wait! Wait! Maybe THIS will work!" |
|dstarr@minerva.cis.yale.edu |                                     |
--------------------------------------------------------------------
From: dak@shannon (Pierre Baillargeon)
Newsgroups: rec.games.corewar
Subject: Re: Outlaw ImpRings? - There's a better way
Date: 2 Jan 93 17:08:39 GMT
Organization: Ecole Polytechnique de Montreal
X-Newsreader: TIN [version 1.1 PL6]

Daniel Starr (starr-daniel@yale.edu) wrote:
: In article <78903@hydra.gatech.EDU> gt7804b@prism.gatech.EDU (Wayne Edward Sheppard) writes:
: > [deleted]
: >
: >If an impring had more points, wouldn't it be easier to kill?
: >
: Nope.  The nifty thing about an impring, after all, is that just like
: a classic imp, each instruction prepares the very next one that executes.
: As a result, no matter how many points there are, only one -- the one
: about to execute -- is vulnerable to bombing/mutation at any given time.
:
: [deleted]

  Well, a ring with more points has more vulnerable point and move slower.
Also, since most ring a multiprocessed (!?) one way to to throw them off-balance
is to increment the B operand (unfortunalty, normal hill preclude '>').  This
make the last processes bomb the firsts which eventually die.  Finally, more
processes means a longer vulnerable time at the beginning.

  A smaller launch method exist, but it is slower:

	spl 1
	spl 1
	spl inc
go	jmp @0,imp
inc	add #2667,go
	dat #0,#0
imp mov 0,2667

--
"Pis Bourassa qui est toujours la.  Y'a pas d'remede contre le SIDA" - French B
...........................................................dak@info.polymtl.ca
Lines: 10
Date: Mon, 21 Dec 92 11:31:53 MST
Newsgroups: rec.games.corewar
From: $dougn@sasb.byu.edu (Douglas R. Nebeker - MIS_SAS)
Subject: PC Robots ??
Organization: Brigham Young University


A few months ago I saw an announcement for some sort of PC Robots game.

If anyone knows anything about this, please drop me a line.

Thanks!!

____

Douglas R. Nebeker      Internet: $dougn@sasb.byu.edu
Newsgroups: rec.games.corewar
From: pk6811s@acad.drake.edu
Subject: Outlaw ImpRings? Nah!
Organization: Drake University, Des Moines, Iowa, USA
Date: Mon, 4 Jan 1993 03:10:34 GMT

>
>If an impring had more points, wouldn't it be easier to kill?
>

I have submitted several variations on seven-point imps with no success.
All the existing imps are three-pointers (yes?)

It's true that an imp-ring/spiral has only one vulnerable point at any
one time.  That point may not even be the one about to execute, since
multiple processes can be laid down over the same spiral and the loss
of one does not affect the execution of the others who pick up the slack.

The real vulnerable point of the imp is the most trailing point, which
is always in the same stream (until killed), and it is never protected.
It can be killed by a dat bomb, thus shortening the spiral by one.
Unfortunately the chances of killing even a short spiral by bombing the
trailing points one-by-one before you are overrun is minimal.
Stunners, scanners, and Vampires have better luck by stunning the
trailing point with a spl or spl-jmp bomb.  The stone in Imprimis
has some success by using an increment of dat #2667,nnnn; by decrementing
locations at 2667 intervals it can run down a slow-moving imp.

Gating is an effective defense against imps, but tends to make your
program one or two instructions longer and therefore more vulnerable.
Charon v8.0 does not use a gate but still wins the majority of its
battles with imps.  The secret is extended scanning with an increment
that scans N and N+2666/2667/2668 (pick one) within a few hundred
cycles of each other.  You do have to be careful to allow enough time
for core-clear and for the opponent's processes to all die, however.

I still believe what I said before, the modern imps are just stones with
a backup plan.  The stone probably does most of the killing and the imp
gives the tie in the rest of the cases.  The win percentages for Emerald
and Imprimis are nearly the same - one is a stone and the other is
a stone-imp.  Traditionally a replicator kills stones with no problem,
so another approach would be a replicator that can somehow kill imps.

It is important to protect as many of your instructions from decrements
as possible, since half the bombs of a mov <a,b stone are single decrements.

As for using some other core size, remember that a three-point imp
does not have to use (N+1)/3 as the increment.  (N*i+1)/3 works just
as well.  And changing the core size will affect ALL programs that
depend on optimal bombing/scanning patterns.

Imps are here to stay, just like stone, paper, and scissors.  We don't
need to outlaw them, just learn to live with them (or in spite of them!)
They do make life a little more complicated.

Paul Kline
pk6811s@acad.drake.edu
From: keulen@csu.murdoch.edu.au (Mike van Keulen)
Newsgroups: rec.games.rogue
Subject: Re: Another game
Date: 23 Dec 1992 18:54:42 GMT
NNTP-Posting-Host: possum.csu.murdoch.edu.au

dmika@charlie.usd.edu writes:

>I don't know where to find Rogue, but if you enjoy Rogue, you may want to
>try the game Moria.  It has basically the same premise, but gets a LOT
>more involved.  The FTP for Moria is FTP.CIS.KSU.EDU; pub/Games/Moria.  I
>started out playing Moria; switche d to Rogue for a while, and definitely
>like Moria better.  Whatever, have fun! 

Is there a PC version around?

Mike

--
****** Michael van Keulen ***** e-mail: keulen@possum.murdoch.edu.au *******
****** BES - Biology, Murdoch University, Murdoch WA 6150  AUSTRALIA *******
************************ "To Love is to _LIVE_!" ***************************
Newsgroups: rec.games.rogue