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 #include /***************************************/ /* */ /* 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, 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, 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: 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 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, 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 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: 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, 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, /* 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 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> <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 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 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