Article 1368 of rec.games.

corewar:
From: durham@cup.portal.com (Mark Allen Durham)
Newsgroups: rec.games.corewar
Subject: Best bombing step sizes
Message-ID: <67307@cup.portal.com>
Date: Wed, 7 Oct 92 03:52:50 PDT
Organization: The Portal System (TM)
Distribution: world
Lines: 240

I am posting some source code which may help some people determine "good"
step-sizes for bombing. This is only my second iteration on this program.
I plan to continue to improve its performance and expand its scope so that
it can handle multiple step-size scenarios too. My first thought is to
improve the search-for-the-appropriate-block-of-free-memory routine.

Until then, I need someone with some "heavy iron" (aka a fast computer) to
run this program with arguments of 8000 and 8000 for me, and then post or
email the results back to me. Otherwise, it could be 1993 before the
program finishes!

Thanks, and enjoy the program.

Mark A. Durham
MAD

--------------------------------------------------------------------------

/***************************************/
/* */
/* Modula Bomber */
/* */
/* Determines the step-size which will */
/* produce the minimum sum maximum */
/* contiguous bomb-free space. Helps */
/* determine optimum bombing strategy. */
/* */
/* Directions for use: */
/* After compiling and linking */
/* (ANSI C), enter: */
/* */
/* progname coresize bombs */
/* */
/* on the command line. "progname" */
/* is the name you give to the */
/* executable (example: mb), */
/* "coresize" is a number */
/* representing the size of the */
/* core (example: 8000), and */
/* "bombs" is the number of bombs */
/* to drop for each step-size */
/* (example: 100). */
/* */
/* Mark A. Durham */
/* October 4, 1992 */
/***************************************/

/***************************************/
/* */
/* Include Files */
/* */
/***************************************/

#include <stdio.h>
#include <stdlib.h>

/***************************************/
/* */
/* Structures */
/* */
/***************************************/

struct list { /* Excuse the mangling of terminology. */

int from; /* The idea is to keep a table of bomb */
int to; /* free areas linked together by both */
int size; /* starting location and size. The */
int last; /* "next" field doubles as a link for */
int next; /* unused elements of the table. */
int lastsize;
int nextsize;
};

/***************************************/
/* */
/* Global Variables */
/* */
/***************************************/

int FirstFree; /* Largest unbombed block of memory. */

/***************************************/
/* */
/* Functions */
/* */
/***************************************/

void delete( /* Deletes an element from the table. */

struct list *core,
int i
) {
core[core[i].lastsize].nextsize = core[i].nextsize;
core[core[i].last].next = core[i].next;
core[core[i].nextsize].lastsize = core[i].lastsize;
core[core[i].next].last = core[i].last;
core[i].next = FirstFree;
FirstFree = i;
}

void insert( /* Inserts a new element into the */

struct list *core, /* table. */
struct list *node
) {
int i;
int j;
 i = FirstFree;
FirstFree = core[i].next;
core[i].from = node->from;
core[i].to = node->to;
core[i].size = node->size;
for (j = 0; core[i].from > core[j].from; j = core[j].next);
core[i].next = j;
core[i].last = core[j].last;
core[j].last = i;
core[core[i].last].next = i;
for (j = 2; core[i].size < core[j].size; j = core[j].nextsize);
core[i].nextsize = j;
core[i].lastsize = core[j].lastsize;
core[j].lastsize = i;
core[core[i].lastsize].nextsize = i;
}

void hit( /* Bomb core. */

struct list *core,
int bomb
) {
int i;
struct list left;
struct list right;

for (i = 0; bomb > core[i].to; i = core[i].next); /* Find node. */

if (bomb >= core[i].from) {
left.from = core[i].from; /* node exists */
left.to = bomb - 1;
left.size = bomb - core[i].from;
right.from = bomb + 1;
right.to = core[i].to;
right.size = core[i].to - bomb;
delete(core,i);
if (left.size > 0) {
insert(core,&left);
};
if (right.size > 0) {
insert(core,&right);
};
};
}

void InitList( /* Initialize table for empty core. */

struct list *core,
int maxsize
) {
int i;

core[0].from = -1; /* core[0] is guaranteed to be smaller */

core[0].to = -1; /* than any other element and first in */
core[0].size = 0; /* the list. */
core[0].last = -1;
core[0].next = 1;
core[0].lastsize = 1;
core[0].nextsize = -1;
 core[1].from = 0; /* core[1] is the initially empty core */
core[1].to = (maxsize-1);
core[1].size = maxsize;
core[1].last = 0;
core[1].next = 2;
core[1].lastsize = 2;
core[1].nextsize = 0;
core[2].from = maxsize; /* core[2] is guaranteed to be larger */
core[2].to = 2*maxsize + 1;/* than any other element and last in */
core[2].size = maxsize + 1;/* the list. core[0] and core[2] both */
core[2].last = 1; /* greatly simplify deletion and */
core[2].next = -1; /* insertion by eliminating special */
core[2].lastsize = -1; /* cases. */
core[2].nextsize = 1;
for (i=3; i<(maxsize+1); i++) {
core[i].next = i+1; /* This initializes the free element */
}; /* list. */
core[(maxsize+1)].next = -1;
FirstFree = 3; /* FirstFree always indicates the */
} /* largest block of unbombed core. */

void main( /* Main program code. */

int argc,
char *argv[]
) {
int bomb; /* Location to bomb. */
struct list *core; /* Table of unbombed blocks of core. */
int done; /* Largest unbombed block of core when done. */
int i; /* Bomb counter. */
int freespacesum; /* Sum of largest unbombed core blocks.*/
int maxsize; /* core size. */
int mindone; /* "done" for minimum "freespacesum". */
int minfree; /* minimum "freespacesum". */
int minstep; /* step-size fo mimimum "freespacesum".*/
int stepsize; /* step-size for bombing counter. */
int totalbombs; /* total number of bombs for each step.*/

if (argc > 1) {
maxsize = atoi(argv[1]);
} else {
printf("Enter core size: ");
scanf("%d",&maxsize);
};
if (argc > 2) {
totalbombs = atoi(argv[2]);
} else {
totalbombs = maxsize;
};
core = (struct list *)calloc((maxsize+2),sizeof(struct list));
minfree = maxsize * maxsize;
minstep = 0;
for (stepsize = 1; stepsize < (maxsize/2); stepsize++) {
InitList(core,maxsize);
bomb = 0;
freespacesum = 0;
for (i = 0; i < totalbombs; i++) {
hit(core,bomb);
freespacesum += core[core[2].nextsize].size;
 bomb = (bomb + stepsize) % maxsize;
};
done = core[core[2].nextsize].size;
if (freespacesum < minfree) {
minfree = freespacesum;
minstep = stepsize;
mindone = done;
};
printf("%d\t%d\t%d\n",stepsize,done,freespacesum);
};
printf("\nMinimum free space = %d for step size %d\n",minfree,minstep);
printf("\tFree space remaining = %d\n\n",mindone);
free(core);
}

Article 1371 of rec.games.corewar:

From: gt7804b@prism.gatech.EDU (Wayne Edward Sheppard)
Newsgroups: rec.games.corewar
Subject: Decrement Protection
Message-ID: <70423@hydra.gatech.EDU>
Date: 8 Oct 92 12:26:10 GMT
Organization: Georgia Institute of Technology
Lines: 55

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.

;redcode verbose
;name SNAKE
;author WAYNE SHEPPARD
;strategy PITBOMBER
;strategy now with decrement protection
;strategy and extra redundancy
spl start ;hit here

start2 spl 0,pitbomb2 ;One of these three statments

mov @0,@pitbomb2 ;can be decremented and the
sub offset2,@-1 ;bombing goes on
jmp -2
dat #0,#0 ;hit here

dat #0,#0
pbdup2 jmp pit-3,3 ;duplicate pitbomb
pitbomb2 jmp pit-2,2
offset2 dat #-115,#115 ;If this is decremented, we are out of action
dat #0,#0 ;hit here

start spl 0,pitbomb ;making myself larger for scanners

mov @0,@pitbomb ;but helps against bombers
sub offset,@-1
jmp -2
 dat #0,#0 ;hit here

offset dat #115,#-115

dat #0,#start2 ;duplicate bomb
bomb dat #0,#start2
dat #0,#0
dat #0,#0 ;hit here

pbdup jmp pit+11,-11 ;duplicate pitbomb

pitbomb jmp pit+12,-12
pit mov @0,<bomb ;Even pit is protected decrement
spl -1 ;NOT spl 0
jmp pit ;hit here

--
Wayne Edward Sheppard
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt7804b
Internet: gt7804b@prism.gatech.edu

Article 1373 of rec.games.corewar:

Newsgroups: rec.games.corewar
From: pk6811s@acad.drake.edu
Subject: Re: Decrement Protection
Message-ID: <1992Oct8.141307.1@acad.drake.edu>
Lines: 46
Sender: news@dunix.drake.edu (USENET News System)
Nntp-Posting-Host: acad.drake.edu
Organization: Drake University, Des Moines, Iowa, USA
References: <70423@hydra.gatech.EDU>
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

Article 1375 of rec.games.corewar:

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

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

Article 1377 of rec.games.corewar:

Organization: Arizona State University
Date: Thursday, 8 Oct 1992 23:22:15 MST
From: <ASMQK@ASUACAD.BITNET>
Message-ID: <92282.232215ASMQK@ASUACAD.BITNET>
Newsgroups: rec.games.corewar
Subject: Re: Best bombing step sizes
Distribution: world
References: <67307@cup.portal.com>
Lines: 32

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

Article 1379 of rec.games.corewar:

Newsgroups: rec.games.corewar
From: pk6811s@acad.drake.edu
Subject: Re: Types of bombs
Message-ID: <1992Oct9.132426.1@acad.drake.edu>
Lines: 155
Sender: news@dunix.drake.edu (USENET News System)
Nntp-Posting-Host: acad.drake.edu
Organization: Drake University, Des Moines, Iowa, USA
References: <70624@hydra.gatech.EDU>
Date: Fri, 9 Oct 1992 19:24:26 GMT

In article <70624@hydra.gatech.EDU>, gt6525c@prism.gatech.EDU (Damon Gallaty)

writes:
(Parts of this note are taken from my article "stone.better.txt" on
soda.berkely.)

> 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
> . . .
>
> - Damon Gallaty
>

Ok Damon, good question that many new players ask. First, jmps to slave
pits or stun-bombs are needed to overcome replicating opponents, like
mice or 'paper'. If you only bomb with dat-zero, you'll lose 80 or 90%
of your battles against replicators, you just can't catch them all (at
the same time).

Example stun bombs:

-------
spl 0
-------
spl -1
-------
spl 0 <- recommend this one
jmp -1
-------
spl 0,8 <- sometimes fought off by paper
mov -1,<-1
-------
spl -1,0 <- sometimes reaches out and grabs you
mov -1,<-1 <- but good against paper-colonies
-------

(Another term is 'carpet bombing' where you lay down a series of spl 0's)

Second, decrements are a free extension of the bombing process, they

cost you nothing and hopefully give your opponent fits. Here's an example
of an old 'stone' type bomber:

;name Twill
;author Andy Pierce
offset dat #-5138,#5138
start spl 0,0
add offset,1
mov <0,0
jmp -2,0
end start

Now, just because it's old-fashioned, doesn't mean it's not effective. Twill
used to hang around the top of the hill most of the time, because it beat
up on all the scanners out there. Anyway, you'll note that Twill bombs
one location with a three-instruction loop - a real honest bomb that will
probably kill whatever is there. Also, by using the predecrement form
on the a-operand, Twill decrements another location. Thus Twill 'trashes'
two locations with three instructions. (If you didn't know before, the
add instruction adds both the a- and b-operands.)

The two important considerations for bombers are pattern and throw-weight.
Twill has a excellent pattern, checkering core rapidly then filling in
the blanks. Twill also has good throw weight, bombing one location
and decrementing one every three instructions, or 66% of c.

Now consider this fighter:

;redcode
;name Emerald
;author P.Kline
inc dat #-2045,#2045
emerald spl 0,100
stone mov <cnt+102-300,<cnt+100
add inc,stone
cnt djn stone,<-3799
end emerald

Emerald exhibits two improvements that give it greater throw-weight,

bombing one location and decrementing three every three instructions.
First, on the 'cnt' line, note the use of djn. Every time 'cnt' executes,
it decrements a new location, working backward from -3799. Charon v 7.0
and Flash Paper do the same thing.

Second, note the b-operand on the 'stone' line. It is predecremented

just like the a-operand. This gives the effect of decrementing a location,
then bombing wherever it then points. Line 'stone' decrements two locations
and bombs a third.

Emerald is the same size as Twill, but trashes four locations in 3 instructions.
Emerald trashes core at 133% of c, previously thought to be impossible.
But 133% is not the limit. If we expand Emerald like this:

;redcode
;name Emerald
;author P.Kline
inc dat #-2045,#2045
emerald spl 0,100
stone1 mov <a,<c
add inc,stone1
stone2 mov <c,<d
add inc,stone2
cnt djn stone1,<-3799
end emerald

we now have two mov instructions, each trashing three locations every time
through the loop - seven locations trashed with five instructions - for
a rate of 140% of c. In fact if we had an endless stream of mov/add
lines, the rate would be 150%, which is the limit using this technique.
Of course as Emerald gets larger it becomes much harder to protect it
from itself, and also makes it a bigger target for scanners.

Now consider another fighter:

;redcode
;name ExtraExtra
 ;author P.Kline
inc dat #0-4023,#4023
stone mov <1,<1+24
spl -1,<cnt-796
next add inc,stone
cnt djn stone,<-797
dat #100
dat #100
dat #100

ExtraExtra decrements both the a- and b-operands, and uses the djn instruction
just like Emerald, yet is different. The spl 0 instruction has been moved
below 'stone' and is changed to a spl -1. You have to observe this to see
the effect in action. There are growing bursts of mov/add instructions
alternating with bursts of spl/djn instructions. The result is longer and
longer bursts of mov/add instructions, trashing core at 150% of c. Eventually
the bursts become long enough that the entire core is checkered at 150% of c.
I also modified the spl to predecrement the same location as the djn, so
that it trashes every other location.

Another idea I have experimented with is using the djn stream to detect
a replicating opponent. The djn falls through when the location that's
decremented contains a "1" in the b-field. If you are a bomber, you are
going to lose against paper, no matter how fast you are, so give up
and do something different - like imping or mousing or anything!
As it turns out, most of the 'paper' style replicators have one instruction
with a "1" in the b-field. When the djn stream rides over this it falls
through to the next instruction, which is your plan-b. My program Encore
was able to change 85% losses against Note Paper to 50% ties using this
technique.

By-the-way, here's the 'secret-code':

stone = a bomber
paper = a replicator
scissors = a scanner, pit-trapper, or vampire

By experience we know that scissors beats paper beats stone beats scissors.
However, we are now seeing the emergence of successful dual-technique fighters.

Paul Kline
pk6811s@acad.drake.edu

Article 1380 of rec.games.corewar:

From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins)
Newsgroups: rec.games.corewar
Subject: Re: Types of bombs
Keywords: bomb
Message-ID: <1992Oct10.005417.3404@oucsace.cs.ohiou.edu>
Date: 10 Oct 92 00:54:17 GMT
References: <70624@hydra.gatech.EDU>
Sender: usenet@oucsace.cs.ohiou.edu (Network News Poster)
Organization: Ohio University CS Dept., Athens
Lines: 66

In article <70624@hydra.gatech.EDU> gt6525c@prism.gatech.EDU (Damon Gallaty)

writes:
>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?

I can think of a couple of reasons right off the bat... It is easy

enough to bomb somebody, and hope they die... but keep in mind, they
are also trying to survive. What the enemy programs do is split off
a bunch of processes that search for the enemy and also watch each
other's back. If one of them gets bomb, patch it up and maybe try
to find out where that bomb came from... So, what you want to do
as a programmer is to out-smart this strategy.

One way to do it is to bomb using SPL statements instead of DAT's

and then after a period of time of this type of bombing, switch over
to the DAT type bombs. If the enemy executes the SPL instruction,
then all of their processes, not just that one, will slow down...
This means that the processes can't watch each other's backs as
easily and as fast, and if they do detect a bomb, they can't react
to it as fast. This will give you time to bomb the rest of the
core and maybe squash all of the slow processes.

Another type of program is the vampire slave bombers. You would

bomb with JMP statements in hopes that the enemy will execute it and
jump to one of your home-made bombing routines. Since the enemy will
probably have lots of processes watching each others back, what would
be the perfect weapon but to have one of its own processes searching
and destroying its own brethren? And just as a safe guard, you would
put a SPL 0 or something in the bombing routine to slow the enemy
program down, the bombing process would pick up more speed as more
processes get captured, and the other processes would get slower and
slower, reacting very slowly to any pending attack.

Yet another type of stategy is the decrement type attack. The basic
idea here is to merely confuse the enemy program, and all of its
processes so that it cannot see an oncoming attack, or to throw off
the enemy attacks since you probably changed its bombing step and
bombing destinations... You would attempt to modify the enemy program
enough that it would just curl up and die on its own, without much
work on your side. Unfortunately, this style of attack doesn't work
very well, since you can confuse the enemy, but you could also by chance
make it easier for the enemy to find you... Now-a-days, people are
using decrements for other reasons as part of an attack strategy, and
not as *the* attack strategy.

Well, hope this helps. There are lots of reasons why a simple DAT type
bombing program will not do the job. The basic idea is that the enemy
knows you are looking for it. It may be looking for you, but it will
be watching its own back as well. You must find a way to stop the
whole enemy program at one time. Killing just one process is just like
stirring up a hornets nest. What would happen if you got them angry...
Stepping on one isn't the answer, but spraying them with Raid might be
in the long run... ;-)

Catch you later!

Scott Adkins
sadkins@ohiou.edu
--
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

Article 1385 of rec.games.corewar:

Newsgroups: rec.games.corewar
From: dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91))
Subject: Re: Scanner Ideas
Message-ID: <1992Oct9.030336.399@vlsi.polymtl.ca>
Sender: news@vlsi.polymtl.ca (USENET News System)
Organization: Ecole Polytechnique de Montreal
References: <1992Oct7.164836.1@acad.drake.edu>
Date: Fri, 9 Oct 1992 03:03:36 GMT
Lines: 57

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

Article 1395 of rec.games.corewar:

From: d91andiv@IDA.LiU.SE (Anders Ivner)
Newsgroups: rec.games.corewar
Subject: The IMProved imp.
Message-ID: <D91ANDIV.92Oct14184118@kol2.IDA.LiU.SE>
Date: 14 Oct 92 17:41:22 GMT
Sender: news@ida.liu.se
Distribution: rec
Organization: CIS Dept, University of Linkoping, Sweden
Lines: 87

As some of you have seen, my program "The IMPire strikes back" now
holds the first place on the KotH list in a firm grip. 170 pts gives
it an 18 pt margin to the 2nd place. (ok, so I needed to boast a bit :-)
And, yes it IS imp-based... I call it 'Cyclic imps'.
The following little example should give you an idea of what I mean:

;redcode
;name trident
;author Anders Ivner
;strategy Three imps are better than one :-)

start mov imp, imp-2667

spl imp-2667
spl imp+2667
imp mov 0, 2667
end start

(Note that 2667*3 = 8001)

The effect is a program that is only ONE instruction long, like the imp
AND it kills anything it runs into that has less than three processes.

Like this, however, it will only score something like 90-100 pts.
The secret is to put several layers of processes executing the same
instructions. Like this, the different "rings" support each other,
making it close to impossible to stop. It will recover completely
from any decrement hit, it may break loose from spl hits, and the
remaining rings will survive a dat hit undamaged.

The best setup I have found so far is using seven layers with nine
processes in each layer ( 9*889 also equals 8001 ):

;redcode
;name The IMPire strikes back
;author Anders Ivner
;strategy ...and 9*7 imps are even better...

start spl 1
spl 1
spl 1
spl 1
spl 1
mov -1, 0

jpt jmp <jpt, imp

jmp imp+889*8
jmp imp+889*7
jmp imp+889*6
jmp imp+889*5
jmp imp+889*4
jmp imp+889*3
jmp imp+889*2
jmp imp+889*1
jmp imp+889*0
jmp imp+889*8
jmp imp+889*7

;[ lots of similar lines deleted ]

jmp imp+889*6
jmp imp+889*5
jmp imp+889*4
jmp imp+889*3
jmp imp+889*2
jmp imp+889*1
jmp imp+889*0

imp mov 0, 889

end start

With this many layers the number of losses is reduced to 10%.

Two weak spots can be noted:

- There is a chance of being hit before the actual imp is started,
which limits the nr of processes to use.
- It can (in most cases) only tie replicators and self-splitting bombers,
since they will pretty soon grow more than 63 processes.

Alright... Now *DON'T* flood the hill with warriors that are merely
permutations of this one! Like using eight layers with seven imps
in each layer, or three layers with 21 imps each.
However, feel free to use it in combination with other strategies.
Anders
(I hope this will encourage more discussions on different techniques
and strategies in this newsgroup...)

Article 1402 of rec.games.corewar:

Newsgroups: rec.games.corewar
Subject: Impressive
Message-ID: <1992Oct18.095953.28262@wisipc.weizmann.ac.il>
From: Dan Nabutovsky
Date: Sun, 18 Oct 1992 09:59:53 GMT
Sender: fedimit@wisipc.weizmann.ac.il (Dan Nabutovsky)
Followup-To: d91andiv@und.ida.liu.se
Organization: Weizmann Institute of Science, Computation Center
Lines: 104

Here is Impressive, currently no.1 at the hill (195 points).

This is an Impire-like program with 2 important enchancements:

1. Process ring was replaced by a process spiral, which decreases

number of looses from 9% to 1% .

2. Dwarf added at the end, allowing to win self-splitting programs.

;redcode
;name Impressive
;author Dan Nabutovsky
;strategy Impossible + self-splitting dwarf

d EQU 2667
i EQU imp-1000
imp: mov 0,d

start: mov imp, i

spl 32
spl 16
spl 8
spl 4
spl 2
jmp i+d*0
jmp i+d*1
spl 2
jmp i+d*2
jmp i+d*3
spl 4
spl 2
jmp i+d*4
jmp i+d*5
spl 2
jmp i+d*6
jmp i+d*7
spl 8
spl 4
spl 2
jmp i+d*8
jmp i+d*0
spl 2
jmp i+d*1
jmp i+d*2
spl 4
spl 2
jmp i+d*3
jmp i+d*4
spl 2
jmp i+d*5
jmp i+d*6
spl 16
spl 8
spl 4
spl 2
jmp i+d*7
jmp i+d*8
spl 2
jmp i+d*0
jmp i+d*1
spl 4
spl 2
jmp i+d*2
jmp i+d*3
spl 2
jmp i+d*4
jmp i+d*5
spl 8
spl 4
spl 2
jmp i+d*6
jmp i+d*7
spl 2
jmp i+d*8
jmp i+d*0
spl 4
spl 2
jmp i+d*1
jmp i+d*2
spl 2
jmp i+d*3
jmp dwarf

DAT #0
DAT #0
DAT #0
DAT #0
DAT #0
DAT #0
DAT #0

MOV 7, <-7
incr: MOV 7, <-7
dwarf: SPL 0
loop: MOV <75, -74
ADD incr, loop
DJN loop, <4400
JMP -1

END start

----------------------------------------------
Dan Nabutovsky
fedimit@wiscon.weizmann.ac.il

Article 1407 of rec.games.corewar:

Newsgroups: rec.games.corewar
From: stst@vuse.vanderbilt.edu (Stefan Strack)
Subject: R.I.P. Sucker 4
Message-ID: <BwG5qw.77H@vuse.vanderbilt.edu>
Sender: news@vuse.vanderbilt.edu
Nntp-Posting-Host: necs
Organization: Vanderbilt University School of Engineering, Nashville, TN, USA
Date: Wed, 21 Oct 1992 01:06:32 GMT
Lines: 136

Cruely killed off at the, admittedly, ripe old age of 949, what follows
is the code to "Sucker 4". It's been so long since I wrote it that I
barely remember how it works :-). It is a simple self-splitting vampire;
changed constants at some launch code/decoy are the differences to
"Sucker 3", which (I believe) I posted a while back.

Cheers, Stefan

;redcode
;name Sucker 4
;author Stefan Strack
;strategy Self-splitting, pattern-bombing vampire
;strategy 2: with confusion
;strategy 3: much denser, mod-2 bomb-pattern; no spacer
;strategy 3.1: avoids prematurely dropping into clear-mode
;strategy 4: spacer/bootstrap; changed bomb increment; tracer-proof
;strategy Submitted: @date@

AWAY equ 4000 ;mirrors boot template

mark equ start+39

;------ bootstrap main bombing loop and slave pit without spacers
boot mov loop+2,@ptr1
mov loop+1,<ptr1
mov loop,<ptr1
mov start,<ptr1
mov jump,@ptr2
mov clear+2,<ptr2
mov clear+1,<ptr2
mov clear,<ptr2
jmp @ptr1

;------ boot copy pointers

ptr1 dat #loop+2+AWAY
ptr2 dat #jump+AWAY

;------ main bombing loop

start spl 0
loop mov jump,@jump
sub clear,jump
djn loop,<3203
;------ spacer
dat #1
dat #1
dat #1
dat #1

;------ core-clearing slave pit

clear mov 37,<-37
spl clear
jmp clear
jump jmp clear-mark,mark

;------ decoy
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
 dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1
dat #1

end boot

Article 1409 of rec.games.corewar:

From: wangsawm@prism.CS.ORST.EDU (Wangsawidjaja Mintardjo)
Newsgroups: rec.games.corewar
Subject: Protecting your warrior against IMPire
Message-ID: <1992Oct21.091154.29342@CS.ORST.EDU>
Date: 21 Oct 92 09:11:54 GMT
Sender: usenet@CS.ORST.EDU
Distribution: usa
Organization: Oregon State University, Computer Science Dept.
Lines: 161
Nntp-Posting-Host: prism.cs.orst.edu

Some of you probably have already noticed that two programs I submitted:
Beholder's Eye & Winter Werewolf suddenly entered KotH and competed with
IMPire programs for the #1 and #2 place. And YES, they are normal vampire
programs that defend themselves against IMPs. By average, they score
something like 70-15-15 against multi-layered IMPs.

The idea behind their success is quite simple:

- Since multi-layered IMPs advanced slowly, scanners/vampires would have
sufficient time to finish their own routines before dealing with IMPs.

So to say:
1. Normal routine
2. Core clear
3. IMPs gate

First and two are clear.

Third: IMPs gate. Ok, there might be a better word for this. What I mean
is to stop the IMPs while you are hopeless. And the secret? To use an
instruction which has been looong forgotten: Pre-Decremental DAT.
Does it ring a bell?

So, here we go:

First: Winter Werewolf.

;redcode
;name Winter Werewolf
;author W. Mintardjo
;strategy SPL/JMP bomber with 2 pass core-clear (SPL/DAT) + self-defense
;strategy against IMPs

step EQU 153

init EQU 152
n EQU (12*8)-2

DAT <-4-n, #0
m MOV -1, 0-n
JMP 2
snow SPL 0, <-3-step-n
main MOV hold, @3
MOV snow, <2
ADD #step, 1
JMP main, init ; Hit here
MOV @-4, <n
hold JMP -1, 1

END m

This originally was my Snowflake 2+. I added the first three instructions and
modified the SPL to make it works against IMPs. The changes however is not
too robust.

I would like to try to make things clear for everybody. So here I give a rather
lengthy description about what it does.

If everything works fine, Winter Werewolf would have four main routines:

1. Bombing core with mod 8 SPL/JMP.

2. Second routine happened after a bomb landed on line 'JMP main, init'
So, it transformed into:
DAT <-98, #0
...
main MOV hold, @3
MOV snow, <2
ADD #step, 1
SPL 0, <-97 ;changed. Main routine goes here
MOV @-4, <n ;n = 94
hold JMP -1, 1
...
 n SPL 0, <-250
JMP -1, 1
Winter Werewolf now fall into core-clear mode. But it uses SPL 0 instead
of DAT to stun any replicator process which is still functional. This
compromises the large interval of its bombing pattern.

3. When those SPLs reach line labeled n, it changes its pointer

So then:
a DAT <-98, #0
...
main SPL 0, <a ;a = -97. Line is changed
MOV snow, <2
ADD #step, 1
SPL 0, <-97 ;Main routine is still on here
MOV @-4, <n ;n = 94
hold JMP -1, 1
...
n SPL 0, <-97
Once more, it goes into core-clear mode. But this time, it uses a
Pre-Decremental DAT to kill all stunned processes.

4. At the last, it hits its own code becoming:

SPL 0, <-97
DAT <-98, #0

And you can see then that all what it does is to gate every incoming IMPs.

Now, come the fun part: Beholder's Eye

But before, I would like to mention something about the origin of this
program. Much thanks and credits should go to Matt Hastings. This is because the
code I use came from his 'B-Scanners live in vain'. I borrowed this program
because of its simplicity and changeability in design.

;redcode
;name Beholder's Eye v1.1
;author W. Mintardjo
;strategy Modified B-Scanners Live in Vain with IMPs immunity
;kill Beholder's Eye v1.1

step EQU 2234

init EQU -2

main ADD #step, 3

JMZ -1, @2
MOV jump, @1
MOV snow, <init
JMN -4, -4
snow SPL 0, <0
MOV 2, <-6
jump JMP -1, 0
DAT <-92 ,<-2

END main

To make this program IMPs proof, I might try the similar trick. But if I change
the SPL's B-Field, I wouldn't have mod 2 scanner which decrease this program
performance. It might be better to just leave the B-Field zero and find a way
to make that B-Field changed after scanning. So, here I use a double
Pre-Decremental DAT.

In core clear mode, when a DAT replaced JMP, all processes on this line
eventually die. In order to die, they have to execute that Pre-Decremental DAT.
I have found that for 8000 processes with coresize 8000, there would be
90 processes remaining on line JMP -1, 0. Then they have to execute that
DAT <?,<? which cause the SPL's B-Field to be decremented 90 times.
The SPL itself has already decremented itself once. So we would have

snow SPL 0, <-91

DAT <-92, <-2

The weakness of these programs is that they still lose to dwarf/ring combos.
But then, we go back to our previous philosophy where dwarf beats scanner.
To fight this kind of combinations, I've found that rotld-like program is
good against it.
Also, these programs are also more-likely beaten by fast IMPs or IMPs without
many layers. But these IMPs won't harm self-splitting bomber much.

Ok. I hope with this, there would be more warrior's variations on KotH.

--- W. Mintardjo

--
#include <sys/std/disclaimer.h>
/* Sender: W. Mintardjo (wangsawm@prism.cs.orst.edu) */
main()
{ printf(".sig? what's .sig?\n"); }

Article 1410 of rec.games.corewar:

Newsgroups: rec.games.corewar
From: pk6811s@acad.drake.edu
Subject: ring killers - and more
Message-ID: <1992Oct21.102041.1@acad.drake.edu>
Lines: 48
Sender: news@dunix.drake.edu (USENET News System)
Nntp-Posting-Host: acad.drake.edu
Organization: Drake University, Des Moines, Iowa, USA
Date: Wed, 21 Oct 1992 16:20:41 GMT

Looks like everyone has a solution to the imp-ring problem. Here's mine:

;redcode
;name Eclipse
;author P.Kline
;strategy bscan, ringkiller, clear
;strategy demo-only version
hold dat #0
ptr dat #stun
next add #2234,ptr
scan jmz next,@ptr ; scan for non-zero
slt #14,ptr ; check for me
jmp next,hold
inc mov @ptr,hold ; save whatever is pointed to
stun mov bomb,@ptr ; drop a stunner
 add hold,ptr ; bump pointer up the trail
cmp #-1,hold ; don't follow djn streams
jmn stun,@ptr ; follow the trail
djn next,#4 ; check for enough
bomb spl 0
mov 2,<-1
jmp -1
end next

Eclipse is based on a program I wrote a couple of years ago to destroy

pit-trappers, the kind that dropped 'jmp @0,trap' bombs. All you had to
do was add the b-field (trap) to your pointer and you had the location
of the trap, which also happened to be the location of the pit-trapper.
Unfortunately that style of snare was changed to jmp trap,coresize-trap,
and my Hunter program became useless.

First time I tried Hunter, it demolished IMPire with no problem,

so I streamlined it as above.

The current version of Eclipse (not shown) is also effective against

modern pit-trappers as well as RotlD2, and probably any other programs
that drop pointers to their position all over core. Unfortunately
it is a little too big in its present form, but it will be back Real Soon Now.

Eclipse is also effective against the kind of paper replicators that

form colonies - a result of not bumping the 'next' location after
each copy is made. Once it finds a small-number b-field, say '4' or '8',
it works its way through the colony, dropping stunners along the way.
Unfortunately Note Paper, Flash Paper, etc. aren't around anymore to
beat up on.

Paul Kline
pk6811s@acad.drake.edu

Article 1413 of rec.games.corewar:

Newsgroups: rec.games.corewar
From: maniac@unlv.edu (Eric J. Schwertfeger)
Subject: More Interesting X-Hill Discoveries (I'm Baaaack:-)
Message-ID: <1992Oct22.194125.9255@unlv.edu>
Sender: news@unlv.edu (News User)
Organization: Too many
Date: Thu, 22 Oct 92 19:41:25 GMT
Lines: 65

Well, I tried two new interesting ideas in Shotgun, and I plan on doing a
littl more work on it, but it doesn't seem to be the champion that
I thought it might be. So, I'm going to describe the new ideas,
and probably knock myself out of first again by giving one of you
a truly great idea (or at least a better use for these ideas :-)

Since the ideas only apply to the jumper, and everyone has seen
my core-clear routines several times, I'll only detail the jumper
here.

STEP EQU 240

OFFS EQU 10
INC EQU 30
JLAUNCH MOV CSRC,CSRC-STEP
 MOV CDST,CDST-STEP
SPL 1
SPL 1
SPL 1
JMP LOOP
BOMBS JMP -OFFS,TRAP+OFFS+STEP
JMP -OFFS-INC*1,TRAP+OFFS+INC*1
JMP -OFFS-INC*2,TRAP+OFFS+INC*2
JMP -OFFS-INC*3,TRAP+OFFS+INC*3
JMP -OFFS-INC*4,TRAP+OFFS+INC*4
JMP -OFFS-INC*5,TRAP+OFFS+INC*5
JMP -OFFS-INC*6,TRAP+OFFS+INC*6
JMP -OFFS-INC*7,TRAP+OFFS+INC*7
CSRC DAT 0,LAST+1+STEP
CDST DAT 0,LAST+1+STEP*2
LOOP MOV <CSRC-STEP,<CDST-STEP
MOV <CSRC-STEP,<CDST-STEP
MOV >0,@BOMBS
JMP LOOP+STEP
TRAP SPL 0,2
MOV -1,>-1
LAST DAT 0,0

The first and most evident idea was the use of a table of bombs, and
the MOV >0,@BOMBS instruction to deposit them. Since I like
multi-process programs, I've been looking for a way to use
interval bombing rather than carpet bombing when I have several
processes executing the same code. It is possible to do this by
having two routines running in parallel, but this was an interesting
and more flexible idea. Basically, the MOV >0,@BOMBS instruction
moves whatever is at bombs to whatever it points to, then increments
the B field. In parallel, this means that in 8 cycles, it will
take a table of 8 instructions, and blast them all into memory
wherever they belong.

The second idea, this one being quite applicable to (SPL 0;JMP) -1 bombers,
is the (SPL 0,2;MOV-1,>-1) trap. this trap will grow, and multiply
MUCH faster. I did a test on both, and after 2500 cycles, the standard
trap had trapped just over 1500 processes. My trap, on the other hand,
had trapped 2490 processes! It had only failed to split on 11 cycles.
The disadvantages are twofold. It relies on the B field, so you can't
use it for anything else, and it will grow, whereas the standard trap stays
in the same place. Also, for most programs, the difference in splitting
speed is only a minor issue. Against sigil or another fast replicator,
however, this speed difference makes a noticeable impact.

Last time I announced an X-hill discovery, I went from having 1st, 3rd, and
4th, to having 2nd, 5th, and 8th. I really hope this makes life on the
hill tougher again :-)
--
Eric J. Schwertfeger, maniac@cs.unlv.edu

Article 1417 of rec.games.corewar:

Newsgroups: rec.games.corewar
From: pk6811s@acad.drake.edu
Subject: No more IMPire - Lots more Rings
Message-ID: <1992Oct23.102715.1@acad.drake.edu>
Lines: 96
Sender: news@dunix.drake.edu (USENET News System)
Nntp-Posting-Host: acad.drake.edu
Organization: Drake University, Des Moines, Iowa, USA
Date: Fri, 23 Oct 1992 16:27:15 GMT

Yeah, Anders, we are learning to overcome rings, but only by making our
fighters a little bit longer, a little bit more complex, a little bit
less efficient, and therefore a good deal more vulnerable to attack. :-(
But rings are here to stay, and they can't be ignored as the last few
days on the Hill have proven.

IMPire suffered from too many ties, especially against replicators. The
problem was that as it rode over a replicator, it advanced faster than
the imp'd opponent, and created a trail of safe instructions to follow.
The simple addition of a dwarf or stone disturbs the trail, causing
the opponent to die.

--------------------------------------
Ring Sizes:

I first thought ring sizes were limited to a

handful of numbers - 3,7,9,18,21 - basically the small factors of 8001.
But factors of 16001, 24001, 32001, etc. should also work, the leading
point just has to end up one instruction in front of itself each
go-around. Here's a short program to find these:
for i=1 to 19
j=(8000*i)+1
print the factors of j
i
and here are the results:
#points dist
------ ------
3 2667
7 1143
9 889
11 5091
13 3077
17 2353
19 7579
21 381
27 2963
31 3871
33 1697
49 2449
53 2717
63 127
Only the smaller factors/points are shown, it would be a challenge to
successfully launch a 63+ point ring against a very fast opponent.

This kind of ring is equivalent to the imp-form:

mov 0,1

Another form is: (Dan pointed this out to me)

mov 0,2
mov 0,2

For this kind we need factors of 8002, 16002, etc., so here are some:
#points dist
------ ------
 2 4001
3 5334
6 2667
6 6667
7 2286
9 1778
11 2182
13 6154
14 1143
14 5143
17 4706
18 889
18 4889
19 7158
21 762
22 1091
22 5091
23 4174
26 3077
29 4138
33 3394
34 2353
37 1946
38 3579
42 381
46 2087
57 2386
58 2069
59 678
63 254

Actually there are lots of other factors, but they have separations greater
than 8000, making them unusable.

I publish these, not knowing just what they are good for, but to encourage
others to find some anomaly in launching; cooperation with stone, dwarf,
scanner, etc.; or bombing/searcing pattern that would make them attractive.
For example, a 2-point ring carries a reflection at 4000, making it
impervious to attack by an on-axis scanner.

Paul Kline
pk6811s@acad.drake.edu

Article 1428 of rec.games.corewar:

From: macaulay@ecr.mu.oz.au (Alex MacAulay)
Newsgroups: rec.games.corewar
Subject: Rings on the X-Hill
Message-ID: <9229922.4368@mulga.cs.mu.OZ.AU>
Date: 25 Oct 92 11:56:04 GMT
Sender: news@cs.mu.OZ.AU
Organization: Dept. Engineering Computer Resources, Melbourne Uni.
Lines: 57

Although IMPire is no longer on the regular Hill, it lives on in the

X-Hill. A few days after IMPire was posted, I sent off Impirex which was
just a copy of IMPire with a step size of 127, the only step I could find
that was suited to the 250 write limit, and 3 processes at each point.
I was hoping that the results would be even more spectacular than IMPire
due to the fact that to beat it, you not only need to hit a point immediately
before it executes, but you also needed to be within 250 locations of it at
the same time. Unfortunately it only made it about half-way up the hill. :-(
Although it had the lowest loss percentage (less than 20%) on the hill, it
tied almost every time with replicators. Unfortunately, you can't write a
simple stone for the X-Hill, so it may be difficult to convert these ties
into wins.

I recently replaced Impirex with Springer 1.0 which creates more and
more ring processes and has a different method of starting the rings up.
Although this method is slower, it does not need a massive, vulnerable jump
table. Has anyone found an even better way of doing this? The other thing to
note is that the 'top' imp in the ring is helped along by the main program
(so, strictly, it's not really a ring).

Here is Springer 1.1, which I have just sent off:

;redcode-x verbose
;name Springer 1.1
;author Alex MacAulay
;strategy A ring "replicator".
;strategy 1.1 - smaller

step equ 247

offset equ -126

start spl 0,>spread

helpimp mov imp,imp+offset+3
spl 1,>helpimp
spl 1
spl 1
spl 1
spl inc
spread jmp @spread,#imp+offset
inc add #step,spread
dat 0,0
imp mov 0,step

end start

If you would like to test this out but don't have post-increment, it still
works if you replace the three instructions from 'start' with:

start spl 0
add #1,spread
helpimp mov imp,imp+offset+3
add #1,helpimp
spl 1

--
Alex MacAulay (macaulay@ecr.mu.oz.au)

Article 1429 of rec.games.corewar:

Newsgroups: rec.games.corewar
From: macaulay@ecr.mu.oz.au (Alex MacAulay)
Subject: Re: overcoming mintardjo gates
Message-ID: <9230318.16607@mulga.cs.mu.OZ.AU>
Sender: news@cs.mu.OZ.AU
Organization: Computer Science, University of Melbourne, Australia
References: <1992Oct27.142931.1@acad.drake.edu> <BwttrB.AJ0@dcs.glasgow.ac.uk>
<1992Oct28.175143.7814@unlv.edu>
Date: Thu, 29 Oct 1992 07:54:34 GMT
Lines: 109

In article <1992Oct28.175143.7814@unlv.edu>, maniac@unlv.edu (Eric J. Schwertfeger)

requests:
> Could someone mail me source to x-hill Imp Ring programs?
> I'm getting clobbered by them, and want to test a few ideas
> of my own, but have nothing but the x-hill itself
> to test them on, since I don't want to take the time
> designing my own Imp Ring, especially because Mine would
> probably be far from the norm.

Well, the only x-rings I know of are Corona and Springer. I have already
posted Springer, so here is Corona. I've also modified Corona for the
standard hill (renamed as Nimbus) so I've included that as well.

Corona 1.1 is currently KotXH by about 30 points and does very well against
leapers. The fighters which it has most problems against are replicators
and fighters using standard imps as part of their attack (ie. Edge 1.1,
Longworm 1.2 and Trap 6). Against both of these types, Corona tends to tie
very often. It loses *very* rarely with W/L/T percentages of about 46/ 7/47!

;redcode-x verbose
;name Corona 1.1
;author Alex MacAulay
;strategy Creates a 63-point 2-process ring, waits, then sends out a
;strategy core-clear which kills off the ring and the subverted enemy.
;strategy 1.1 - Uses core-clear instead of jumper - better vs replicators.
;kill Corona

step equ 127

runup spl 1
spl 1
spl 1
spl 1
spl 1
mov -1,0
spl 1
spl inc
spread jmp @spread,#imp
inc add #step,spread ; need a dat after this instruction
dat 0,0

jstep equ step+4

jprocs equ 48
jbomb equ jptr
jfirst equ jptr
jlast equ jfrom

start spl runup

wait djn 0,#104
spl 1
mov -1,0
spl 1
 mov <from,<to
spl 1
from spl 1,#jlast+1
to spl 1,#jlast-jstep+1
mov jbomb,<clear
clear jmp jkill,#jlast+jprocs+1

jptr dat #jkill+jstep+250+1

jkill mov jbomb,<jptr-jstep
mov jbomb,<jptr-jstep
mov <jfrom-jstep,<jto-jstep
jto jmp jkill+jstep,#jfirst+jprocs+(2*jstep)
jfrom dat #jfirst+jprocs+jstep

imp mov 0,step

end start

The strategy I try to use in Nimbus is to subvert, but not necessarily kill,
the enemy using a ring then finish them off with a core-clear. The ring travels
reasonably fast through the core (approx. 16,000 cycles) but before it makes
it all the way round, a very fast splitting core-clear goes into action, which
effectively stops the ring even though it doesn't kill it. By finishing with
the ring fairly early, it should bypass most mintardjo gates. Like Corona,
Nimbus also tends to fail against replicators.

;redcode verbose
;name Nimbus 1.2
;author Alex MacAulay
;strategy Create a 63-point 2-process ring, wait, then clear core.
;strategy 1.2 - Core-clear unaffected by djn streams.
;kill Nimbus

step equ 127

start spl wait

spl 1
spl 1
spl 1
spl 1
spl 1
mov -1,0
spl 1
spl inc
spread jmp @spread,#imp
inc add #step,spread ; need a dat after this instruction
bomb dat <-5,<-6

wait djn 0,#step-35

cc mov bomb,<ptr
spl cc,<wait
ptr jmp cc,<cc

imp mov 0,step

end start
--
Alex MacAulay (macaulay@ecr.mu.oz.au)
Article 1430 of rec.games.corewar:
From: gt7804b@prism.gatech.EDU (Wayne Edward Sheppard)
Newsgroups: rec.games.corewar
Subject: PLASMA scanner->replicator
Message-ID: <73060@hydra.gatech.EDU>
Date: 29 Oct 92 22:33:33 GMT
Organization: Georgia Institute of Technology
Lines: 41

Hello everyone. I bet you all are wondering how a scanner-replicator

works. First of all, it is not doing both at the same time. It scans
until it finds something. That gets bombed thoroughly. Now it switches
to a replicator.

This allows me to have a small target area for other scanners. But
against bombers and imps, it doesn't take too long before I turn
into a replicator. Yhis allows me to kill most bombers and tie the
imps.

There is a lot of room for improvement. For example you could use
CMP scanning in the main scanning loop to find something quicker.

Here's the code:

;redcode verbose
;name PLASMA 4
;author Wayne Sheppard
;strategy Scanner-Replicator
;strategy Better killing Process
;kill PLASMA
bomb equ start-1 ;this should point to dat 0 , 0
start add #3039,loc ;best increment size
loc jmz start,-1
cmp #-1,@loc ;don't look at DJN trails
slt #100,loc ;program length
jmp start
mov bomb,@loc ;bomb whatever I found
cmp <loc,bomb ;is next location dat 0,0
jmp -2 ;bomb more of program

;Place your favorite replicator here

;I used the replicator from FlashPaper

--
Wayne Edward Sheppard
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt7804b
Internet: gt7804b@prism.gatech.edu

Article 1433 of rec.games.corewar:

Newsgroups: rec.games.corewar
Subject: Imp Rings vs Imp Spirals
Message-ID: <1992Oct29.172122.24038@wisipc.weizmann.ac.il>
From: fedimit@wisipc.weizmann.ac.il (Dan Nabutovsky)
Date: Thu, 29 Oct 1992 17:21:22 GMT
Organization: Weizmann Institute of Science, Computation Center
Lines: 44

A standard process ring looks like this:

d EQU 2667
imp MOV 0,d
SPL 1
SPL 1
SPL 1
SPL 1
JMP <16

JMP imp+2*d
JMP imp+d
JMP imp
JMP imp+2*d
JMP imp+d
JMP imp
...

If we replace it by a spiral:

...
JMP imp+2*d+1
JMP imp+d+1
JMP imp+1
JMP imp+2*d
JMP imp+d
JMP imp
JMP imp+2*d+1
JMP imp+d+1
JMP imp+1
JMP imp+2*d
JMP imp+d
JMP imp
...

it cannot be killed by any single bomb.

This technique (used by Impression) makes imp MUCH less vulnerable

to any kind of attack.

-------------------------------------------------------
Dan Nabutovsky fedimit@wisipc.weizmann.ac.il
-------------------------------------------------------

Article 1435 of rec.games.corewar:

Newsgroups: rec.games.corewar
From: pk6811s@acad.drake.edu
Subject: Re: Imp Rings vs Imp Spirals
Message-ID: <1992Oct30.085143.1@acad.drake.edu>
Lines: 24
Sender: news@dunix.drake.edu (USENET News System)
Nntp-Posting-Host: acad.drake.edu
Organization: Drake University, Des Moines, Iowa, USA
References: <1992Oct29.172122.24038@wisipc.weizmann.ac.il>
Date: Fri, 30 Oct 1992 14:51:43 GMT

> A standard process ring looks like this:

> ...
> If we replace it by a spiral:
> ...

The technique used by Nimbus also creates a spiral:

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

Fewer lines of code are required to launch the spiral, but it takes
a little longer (twice as long?). Also, it only puts one process at
each point of the spiral. Perhaps it is most useful when launching a
very large spiral (Nimbus = 63 points!), since you double the number
of points by adding one line of code - spl 1.

Paul Kline
pk6811s@acad.drake.edu