HDTenEightyP/NetNews huggingface dataset:
From: PEPPER@stl550.span.nasa.gov
Newsgroups: rec.games.corewar
Subject: subscribe
Date: 7 Oct 92 16:49:38 GMT

subscribe
From: ag625@yfn.ysu.edu (George M. Gruschow)
Subject: Re: Interested in Corewars but ClueLess
Organization: Youngstown State University/Youngstown Free-Net
Date: Tue, 13 Oct 1992 21:50:48 GMT


What system are you running off of??? If a common PC system then
call any local BBS up, ask the public where to get a corewars
program for your system, and they will either point you to 
someone that might now, or tell you where to get one direct.

-- 
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
George Gruschow | ag625@yfn.ysu.edu| The genius without a clue...
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Organization: Arizona State University
Date: Thursday, 8 Oct 1992 23:22:15 MST
From: <ASMQK@ASUACAD.BITNET>
Newsgroups: rec.games.corewar
Subject: Re: Best bombing step sizes
Distribution: world

Asking for the parameter 8000 8000 suggest that the coresize on the
tournament is going to be 8000. Am I right?

I'm posting the "optima-type" constants. (just in case the de. is:
the constans 'a' that gives maximum average distans s(a) from the previously
bombed locations. For example s(4)=4.

coresize 8000:
            a          s(a)
mod 1       3039       5.17
mod 2       2234       9.45
mod 4       3044       17.11
mod 5       2365       21.13

In the less than 100 interval
            73         3.36
            98         6.50
            76         10.07
            95         12.57

Coresize 8192
mod 1       3455       5.10
mod 2       3438       9.51
mod 4       3164       10.07

less than 100

            71         3.44
            46         4.77
            76         10.07

Na'ndor Sieben
From: gt7804b@prism.gatech.EDU (Wayne Edward Sheppard)
Newsgroups: rec.games.corewar
Subject: WARNING :: Bug in CoreWarsDeluxe
Date: 13 Oct 92 21:45:08 GMT
Organization: Georgia Institute of Technology

I have just found a bug in CoreWarsDeluxe for the PC.  It involves
the MOV ADD and SUB commands when using predecrement in the B-field.
Here's how I found it:

	mov 2,<2
	jmp -1
	dat #1

What happens is when CWD reads the A field, it goes ahead and grabs
a copy of what it is going to move.  Then if the B field decrements
that same instruction, the mov works as normal except that it uses
the copy of the instruction that has not been decremented.

The same goes for the ADD and SUB commands.

Has anyone ran the test programs on CorewarsDeluxe or on KoTHPC?

-- 
Wayne Edward Sheppard
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt7804b
Internet: gt7804b@prism.gatech.edu
Newsgroups: rec.games.corewar
From: dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91))
Subject: Re: Scanner Ideas
Organization: Ecole Polytechnique de Montreal
Date: Fri, 9 Oct 1992 03:03:36 GMT

pk6811s@acad.drake.edu writes:
: I would be curious to know if anyone is using bombers modeled after 
: Emerald or ExtraExtra as described in my article 'stone.better.txt' on
: soda.berkely.
: 

Here's some program I wrote that used multiple bombs:

;redcode verbose
;name Confetti
;author Pierre Baillargeon
;strategy   v0.99:  Leave stuff everywhere.
;strategy   v1.00:  Fastest clear core.
;strategy   v1.10:  Copy ourselves away.
;strategy   v1.20:  Change step and kill method.
;strategy   v1.22:  One instruction smaller.
;strategy   v1.30:  Now affect 3 locations / 4 cycles.
;strategy   v2.00:  Start mod-5, decrement, end core-clear.
;strategy   v2.10:  Smaller.
;strategy   v2.20:  Self-splitting, mod-random, mutagenizing.
;kill Confetti


dist1	equ -15			; mod-5 but not 10
dist2	equ -70+1		; mod-10 but not 20

many	spl 0,<kill		; staying alive
kill	mov bomb1,@back+dist2	; decrement and bomb2
clear	mov bomb1,@kill		; decrement and bomb1 (mod-8)
mod	add #dist2,kill		; change location (mod-16)
back	djn kill,<1998		; redo if not zero: small protection

bomb1	dat #0,#dist1		; bombs are not moved away

	end many


;redcode verbose
;name Vent du mont Sharr
;author Pierre Dak Baillargeon
;strategy   v1.0:   YASB.
;strategy   v2.0:   Mutagenize memory.
;kill Vent du mont Sharr

dist    equ -6883

coma    spl coma,  <1      ; the poison
start   add #dist, coma+1  ; change location
kill    mov @kill, <coma   ; put ennemy in coma

        end coma


The last one is not a fast bomber, but has an interesting behavior.
--
"Pis Bourassa qui est toujours la.  Y'a pas d'remede contre le SIDA" - French B
...........................................................dak@info.polymtl.ca
From: tkimball@foghat.rutgers.edu (Timothy Kimball)
Newsgroups: rec.games.corewar
Subject: WinCore project
Keywords: need C source
Date: 12 Oct 92 23:27:56 GMT
Organization: Rutgers Univ., New Brunswick, N.J.


	Now that I am soon to find a C compiler, I am restarting my
efforts to port CoreWar to Microsoft Windows.  This project was
originally (sp?) to be done in Pascal, but I needed something to learn
C anyway.  

	Until I get the compiler and start tinkering, it would be
appreciated if I could get pseudocode for all the commands (new and
old) and for the forms of number handling (preferably new).  This
would speed up the programming/debugging time as I would have an idea
of what to write.

Thanks,
T. S. Kimball

no .sig, but will soon . . . .
From: durham@cup.portal.com (Mark Allen Durham)
Newsgroups: rec.games.corewar
Subject: RE: EBS Tournament
Date: Wed,  7 Oct 92 03:50:44 PDT
Organization: The Portal System (TM)
Distribution: world


The poll of "new tournament vs KotH" is running 2 to 1 in favor of running
a new tournament specifically for choosing EBS finalists to advance to the
ICWS annual tournament.  There is a little variance in specific suggestions
for how to handle the tournament, but nothing severe.

So, here is how the tournament will be run.  Entries should be sent to
"durham@cup.portal.com" before November 15, 1992.  I recommend that you
write very verbose comments so that there can be no mistaking your
intentions for the program.  Example:

; Program Name
; EBS 1992 Qualifying Tournament Entry
;
; Program's Author
; Program's Author's Email address
; I am (or am not) an ICWS member
;
; Detailed description of program
etc.

Remember, your program can only be up to 300 contiguous instructions in
length.  (Instructions, not lines.  You can have as many comments as you
wish.)  My assembler can handle any instruction format you throw at it,
but I prefer that you seperate operands by a comma.

I will accept up to two entries per person.  I will give preference to
advancing those entries from people who are NOT members of the ICWS or its
branch sections (other than the EBS).  Members of the ICWS can submit their
progams directly to Jon Newman before December 15th to enter them in the
ICWS tournament.  Reasons for entering the EBS tournament even though you
are a member of the ICWS include seeing how you stack up to the competition
prior to the tournament.

Last year we had fewer than the allowed ten entries.  I know we can do much
better this year.  The winner of the EBS tournament last year went on to
win the ICWS tournament.  I know we can repeat that success.

The format for the tournament will be a round-robin of several rounds, each
round with a randomly chosen separation.  The separation will be no smaller
than the largest submission in order to guarantee programs do not overlap.
The scoring will be the standard 3 points per win, 1 point per tie, and
0 points for a loss.  Some people have suggested weighting the results.  I
doubt that will be necessary or have any noticable effect.  In any case, I
am certain that all will consider the results of the tournament "fair".

Mark A. Durham
MAD
Organization: Arizona State University
Date: Friday, 16 Oct 1992 21:25:50 MST
From: <AZNXS@ASUACAD.BITNET>
Newsgroups: rec.games.corewar
Subject: EBS tournament question

What will be the scoring system on the EBS tournament on Nov. 15 ?
How many opponents, how many battle per opponents ? Or the system
used on the Valentine tournament?

Another question: How can I delete something from soda? I's like to
upload the new version of Mars88 and delete the old one.

Na'ndor Sieben
Newsgroups: rec.games.corewar
From: pk6811s@acad.drake.edu
Subject: Scanner Ideas
Organization: Drake University, Des Moines, Iowa, USA
Date: Wed, 7 Oct 1992 22:48:36 GMT

Well, looks like my prediction about multiple-tactic programs is coming true
with a vengeance.  Both my high-tech bombers, Emerald and ExtraExtra, were
driven off the hill, and Twill also.  More people are writing stone-paper
combinations successfully and venerable Flash Paper is showing definite
signs of age.  The unfortunate side effect of stone-paper combos is they
have driven off their friends the stones, thus allowing scanners to rule
the hill.

I would be curious to know if anyone is using bombers modeled after 
Emerald or ExtraExtra as described in my article 'stone.better.txt' on
soda.berkely.

Much as I hate to encourage scanners, they do seem to be in the limelight, 
and there are three ideas I would like to share.

First Idea:
----------

To make a cmp-scanner that does not use a fixed separation between 
the a- and b-fields, ala Charon and No Mucking About 
(and all the others I've seen).  This would look like:

next    add inc,scan
scan    cmp 0,0
        slt #11, scan
        jmp next
attack  mov bomb,@scan
        mov #scan2-scan,scan2
        sub scan,scan2
        mov bomb, @scan2
        jmp next
scan2   dat #0
inc     dat #1003,#0-1003
bomb    spl 0

If you follow this, you will see that the a and b operands of 'scan' will
always total 8000 (or zero), so subtracting b from zero gives a.  Actually
you subtract b from #scan2-scan to allow for the relative positions of 
scan and scan2.  Unfortunately, Core 1.1 for the Mac does not check for
negative operands with the SUB command (at least not for both operands),
so I can't get this to work reliably.

Second Idea:
------------

A multi-processing scanner, with a large number of syncronized processes.
One requirement for a scanner-replicator combo is that the scanner must
grow processes, or it will effectively cease to function as the replicators
multiply.  Here's part of one that I have:

ptr1     dat #-100
ptr2     dat #-100
bomb     spl 0
start    spl 1,<ptr1
         spl 1,<ptr1
         spl 1,<ptr1
         spl 1,<ptr1
         spl 1,<ptr1
         spl 1,<ptr1
scan     cmp <ptr1,<ptr2
         spl attack,<ptr1
return   jmp scan
attack   mov bomb,<ptr2
         end start

Try it.  It carpet bombs with a spl 0, using 64 processes.  A little slow,
but persistent.

Third Idea:
-----------

The other requirement for a scanner-replicator combo is a scanner that
ignores it's own replicators.  Here's how it might work.  Program scans
until it finds a likely location.  Then if that b-field is less than 
7985 (or some such high number) bomb it.  Now all you have to do is
create a replicator and scanner whose b-fields are all greater than 7985.
I have tested a couple of these, but they're not powerful enough yet.

Unfortunately, merging ideas 2 and 3 has so far defeated me.

--------

just some thoughts

Paul Kline
pk6811s@acad.drake.edu
Organization: Arizona State University
Date: Friday, 9 Oct 1992 22:52:35 MST
From: <AZNXS@ASUACAD.BITNET>
Newsgroups: rec.games.corewar
Subject: Re: Best bombing step sizes
Distribution: world

It's very interesting. The minimal maximum bomb free constans are
exactly the same as the "optima-type" constans. The question is why?
Is there any algebrist out there to give a proof that this is true for
any coresize?
This result can be used inthe problem: How to display a fractal?
More precisely in which order calculate the point of a fractal to
get an idea of the picture as fast as possible.
 ,
Nandor Sieben
Newsgroups: rec.games.corewar
From: c9036991@wombat.newcastle.edu.au (THE TIME HAS COME, THE WALRUS SAID, TO TALK OF MANY THINGS. OF SAILING BOATS AND SEALING WAX, OF CABBAGES AND KINGS)
Subject: Beginner
Organization: University of Newcastle, AUSTRALIA
Date: Wed, 14 Oct 1992 11:03:29 GMT


	Hi all ...

	Being a beginner at these things i was wondering if somone
	willing enough could tell me some books I could read so 
	I actually understand the redcode language.
	
	I think this would be a great help to me!
	
	I would also like to know which is the better to learn corewar
	on, I have koth from soda, and also core  (also from soda).

			Thanks in advance,
					  Mathew
-- 




	Wayne's World, Wayne's World, Party Time, Excellent!

        Party on Dudes! - Bill and Ted


		C9036991@wombat.newcastle.edu.au
		
			      OR

	            	C9036991@idiot.at.home
	
		Just call me Mathew or BG
	
Newsgroups: rec.games.corewar
From: gt7804b@prism.gatech.EDU (Wayne Edward Sheppard)
Newsgroups: rec.games.corewar
Subject: Re: WARNING :: Bug in CoreWarsDeluxe
Date: 14 Oct 92 01:57:55 GMT
Organization: Georgia Institute of Technology

>Now, what I am curious about is the fact that you have Core Wars Deluxe
>for the PC???  This is something I haven't heard about yet! :-)  Would
>you mind telling me where you got it (so I can get it), or if you did
>it yourself, I would be happy to hear more about it!  The next version
>........
>Scott Adkins
>sadkins@ohiou.edu  (You know, I bet you that my sig will appear after this,







Sorry, I meant CoreWarPro. I didn't mean to confuse anyone.


-- 
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: gt7804b@prism.gatech.EDU (Wayne Edward Sheppard)
Newsgroups: rec.games.corewar
Subject: More BUGS ???
Date: 15 Oct 92 17:01:59 GMT
Organization: Georgia Institute of Technology

I've got another question about the evaluations.  Is the A-mode treated
just like the B-mode?

EX:

MOV <1,4
DAT #1

If it is treated the same way, shouldn't DAT #1 be moved forward 4?

Or will DAT #0 be moved forward?
-- 
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: gt6525c@prism.gatech.EDU (Damon Gallaty)
Newsgroups: rec.games.corewar
Subject: Types of bombs
Keywords: bomb
Date: 9 Oct 92 14:38:32 GMT
Organization: Georgia Institute of Technology

I was just curious about people's ideas on bombing. If you're going to
bomb someone, why use decrementing, jmp's to slave pits, and such? WHy
not just bomb a typical DAT and destroy them right there? It seems
to me that keeping them alive longer just prolongs the battle and
gives them a slightly better chance to survive. The only use I see
for using anything but DAT's is perhaps for bombing someone's data
area with decrements, to try to make them destroy themselves. Perhaps
I am missing something. Anybody have any helpful insight on this?

- Damon Gallaty

-- 
"Have you ever danced with the Devil by the pale moonlight?
 I ask that of all my prey. I just like the sound of it..."  - the Joker
************************************************************************
Damon Gallaty                           E-mail: gt6525c@prism.gatech.edu
Newsgroups: rec.games.corewar
From: pk6811s@acad.drake.edu
Subject: Re: Decrement Protection
Organization: Drake University, Des Moines, Iowa, USA
Date: Thu, 8 Oct 1992 20:13:07 GMT

>
> Here is my program SNAKE.  All of my vampiric bombers kept taking
> a beating from this new class of bombers that claim to bomb
> the core at 150% of c.  But a decrement doesn't kill a program.
> I designed all of the B-fields so that if any one is decremented,
> the bombing routine keeps functioning.
> 
> I would really be interested in any other programs that use
> this tactic.

AhHa!  So that's why Snake does so well against my bombers.

I wondered if people would catch on to this.  It's easy to protect
against single decrements on b-fields.  Here's how I do it in Eclipse:
Lines marked ** function normally when decremented (once).

;redcode
;name Eclipse V2.0
;kill Eclipse
;author P.Kline
;strategy bscan, 2-dwarf, 1-dwarf
bomb2    mov -1,<0
ptr      mov bomb1,<1-131
next     add #121,@2         ; **
         jmz next,@ptr
         mov bomb2,@ptr
         jmn ptr,@-1         ; **
bomb1    spl 0,10            ; **
         mov cnt+1,<bomb1-2  ; **
         mov cnt+3,<bomb1-3  ; **
cnt      djn -1,@0           ; **  stays zero until decremented or executed
         end next

Here's another tip.  Don't put zeros in any b-fields in your code.
Since the bomber is doing:
    mov <a,<b
if a points to your zero-value, no problem, but if b does,
the location just ahead of it will be bombed.  Better to make it
something large.  This also applies to locations following your
code.  Better make them something other than zero too. 
Course that leaves you open to probing by b-scanners . . .

Unfortunately, all this anti-stone technology is only going to help scanners.

Paul Kline
pk6811s@acad.drake.edu
From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins)
Newsgroups: rec.games.corewar
Subject: Re: WARNING :: Bug in CoreWarsDeluxe
Date: 14 Oct 92 00:53:56 GMT
Organization: Ohio University CS Dept., Athens

In article <71121@hydra.gatech.EDU> gt7804b@prism.gatech.EDU (Wayne Edward Sheppard) writes:
>I have just found a bug in CoreWarsDeluxe for the PC.  It involves
>the MOV ADD and SUB commands when using predecrement in the B-field.
>

Since Bill already explained that this is not a bug, then I will leave
that alone.  :-)  This "feature" just comes from one of the many 
ambigious rules that came from the standards... maybe all of this will
be cleared up in the next release of standards. :-)

Now, what I am curious about is the fact that you have Core Wars Deluxe
for the PC???  This is something I haven't heard about yet! :-)  Would
you mind telling me where you got it (so I can get it), or if you did
it yourself, I would be happy to hear more about it!  The next version
of Core Wars Deluxe is still currently only half done (I have rewritten
all of the assembler parts, but haven't touched the MARS yet).  One of
the things that I am doing is developing the next version on both the 
IBM PC (in fact, using an XT for one, and a 486sx for another copy) and
the Unix system... So far everything is working perfectly and exactly the
same (including with memory usage)! :-)  

If anyone else is runnig any PC versions of the Core Wars Deluxe, please
let me know, I would be happy to hear about it... :-)

Scott Adkins
sadkins@ohiou.edu  (You know, I bet you that my sig will appear after this,
		    so, why did I provide my name and address?  Hmm....)

-- 
Don't forget to have a good day!  Some people never remember this.              -------------------------------------------------------------------------------      Scott W. Adkins                   Internet: sadkins@ohiou.edu             
     ~~~~~~~~~~~~~~~                             ak323@cleveland.freenet.edu     (Flame me, not the net!)                Bitnet: adkins@ouaccvma.bitnet         -------------------------------------------------------------------------------
                           Ohio University of Athens                                                    Home of the Great Hocking River
Newsgroups: rec.games.corewar
From: snh@Lise.Unit.NO (St}le Norman Halvorsen)
Subject: A simple (?) question.
Organization: Norwegian Institute of Technology
Date: Fri, 9 Oct 92 05:46:29 GMT

What is "stone" ?

Nowadays everybody keeps talking about it, but I've never seen 
the code for it, even though it seems to be quite basic...
Is it just another name for "Dwarf" or what ?

Code would be nice, but plain description is also OK.


Thank YOU for helping me out on this one.   ;-)


snh.
From: durham@cup.portal.com (Mark Allen Durham)
Newsgroups: rec.games.corewar
Subject: RE: Best Bombing Step Sizes
Date: Thu,  8 Oct 92 22:59:46 PDT
Organization: The Portal System (TM)
Distribution: world

Much thanks to Bas de Bakker and Pete Orelup for running my program and
sending back the results.  For the curious among you, the "best" step size
for bombing a core of 8000 elements 8000 times is:

   3039 or 3359

The sum of maximum bomb-free space is 101410 for each.  Unfortunately, 3039
and 8000 have no common divisors and 3359 is prime, therefore a bomber
using either of these step-sizes would necessarily bomb itself eventually.

Here are the best finishers for the next ten sizes of free space:

End Freespace     Step-size   Sum of Max Freespace
-------------     ----------  --------------------
      0            3039/3359        101410
      1            2234/3094        101856
      2              none
      3            3044/3364        111160
      4            2365/3315        114390
      5              none
      6              none
      7            2376/2936        133360
      8              none
      9            2430/2930        147380
      10             none

Mark A. Durham
MAD
durham@cup.portal.com
Newsgroups: rec.games.corewar
From: info301a4@cc.newcastle.edu.au (Your Average Ordinary Everyday Dude)
Subject: A Question of Copyright
Organization: University of Newcastle, AUSTRALIA
Date: Thu, 15 Oct 1992 22:49:51 GMT



	Hello, \

		I have a warrior that i call BUGGER because basically 
	its a BUGGERised version of about 3 or 4 other warriors that
	I have seen the code for.
		I was just wondering what the rules concerning copyright
	(if any) there is about my warrior. It just basically takes the best 
	(and most usefull) bits of the 4 programs, and combines them into
	one.
		I was most surprised when it managed to kill off XTC five
	times out of ten on KothPC (I think thats the correct program I
	was running)

	Also, I was wondering if there are any books that I could read
	to learn more about the programming side of things. Being a 
	Psychology student, we dont have much to do with programming, and
	to be honest most of the code used in the warrior goes right over
	the top of my head.

			Thanks,
				Mathew.