From news-rocq.inria.fr!jussieu.fr!math.ohio-state.edu!howland.erols.net!ix.netcom.com!tor-nn1.netcom.ca!torfree!bx880 Fri May 2 10:18:40 1997 Article: 7516 of rec.games.corewar Newsgroups: rec.games.corewar Path: news-rocq.inria.fr!jussieu.fr!math.ohio-state.edu!howland.erols.net!ix.netcom.com!tor-nn1.netcom.ca!torfree!bx880 From: bx880@torfree.net (Ian Sutton) Subject: Re: LP Message-ID: Organization: Toronto Free-Net X-Newsreader: TIN [version 1.2 PL2] Date: Thu, 1 May 1997 09:06:03 GMT Lines: 204 John K. Lewis wrote: >I'm encouraged by some interesting results on the Limited Process hill. >Firstly, the nubmer of ties is much lower than the "Pro" hill. This >is good because it was the intention of the limited process hill. >[even if this was intended for the *multi-warrior* hill]. It looks >like the hill is active and many of the programmers on the pro hill >are also here. (what are the rest of you waiting for?) > >Another interesting thing is that number one has over 50% wins. I don't >remember seeing anything like this on the pro hill. I'm not saying it >never happened, but I just don't remember it happening. I wonder if >this will continue. > >So Ian Sutton, what is Limb Rending Incisors? How does it work. Why >are you using jmp 0 instead of spl 0? (there is the off chance you >might slow your opponent down, right?) Are the vamped processes doing a >clear with jmp 0? > >Philip Kendall's paper could not exist on the pro hill. It's a single >process paper. (I wonder how mice would do on the lp) It's encouraging >to see this old technology coming back. Glad you posted John. Somebody had to get the ball rolling. The LP hill certainly opens up a wealth of new strategies and LRI is another example of a program which would be absolutely murdered (is there a way to be slightly murdered?) on the Draft hill. There is a simple reason for this: spls cannot be used to create enumerable processes so they must be used more carefully. Take a regular d-clear for example, which does not work too well in LP. gate dat 0,0 ... start spl #0, #0 mov bomb, >gate djn.f -1, >gate bomb dat 0, 20 If you start at the spl, then once the clear has amassed 8 processes the spl will fall through without creating another process and you will be left with a fairly vulnerable clear. Change the djn line to -2, and it will be more robust, but slowed. Now take a paper, perhaps with a clear after the copying phase. If you hit it with a spl and the paper has the maximum amout of processes, then it work exactly as a nop. Not exactly a devastating bomb! You will have the same effect against a bomber with 8 processes. So what is a good bomb? Whack enemy code with a jmp 0, and it is now completely disabled, allowing the vamp pit clear to sweep up the mess. OK, some more specifics. LRI has 4 main components and no its not a Pspacer. A great thing about LP is that you can basically have as many different parts as you like, all working in symphony. You don't have to worry about scanners, because if you have 8 processes, the worst that can happen is that you will be marginally/massively slowed down, even if wiped with a long carpet! Anyway here they are: 1. The main bomber. This baby bombs alternately with jmps to the pit, and the aforementioned jmp 0. Eventually this bomber will itself be vamped into the pit with (I hope) the enemy. 5 processes are in use here. I found out that to keep code working with no spl and multiple processes, you need 1 more process than will be executed in the loop. Just keep splitting to the start of the loop 5 times, and it will work as if it only had 1 process. The bombing is mod 2/3 which took me forever to get working but seems effective. 2. The pit. If you examine the code below you will see that the pit itself jumps back to the spl, so that as soon as an enemy process has been killed with a dat, another process immediately goes into the clear, thus speeding it up and making the clear more effective. Slavers are nice in LP. 3. A forward clear (myclear). Since the pit eventually destroys itself, we obviously need code elsewhere so that we will survive its demise. Works in conjunction with the sneak (see below). 4. The Sneak. The above worked, but I was still having trouble with stuff like multiple core clears (Juggernaut, Hopefully Indestructible etc.) Took me a while to solve this one, but suddenly it dawned on me. Boot away a fast backwards clear. Then if my main code gets hurt and starts malfunctioning, this clear will delete it and will then be clearing very rapidly backwards at full speed. Groovy! Of course if the main code is working, then this guy will be sacrificed for the cause. Such is war 8) I rambled on a bit so here's the code. Regards, Ian Sutton ----------------------------------------------------------------------- ;redcode-lp ;name Limb Rending Incisors ;author Ian Sutton ;kill Limb Rending Incisors ;strategy Vampire ;strategy Vamp enemy into the pit or stun him with JMP 0, then dual clear ;strategy v1.5 Fixed a few bugs ;assert CORESIZE == 8000 ; All these numbers are the same. ; If you think I'm going to spend another hour+ to get it working again ; with different numbers then you've got a screw loose! step equ 15 stfang equ (stcode-7981+step*3) sboot equ (main+2541) org start ; --The Sneak-- ; This is backwards clear which will be booted away main dat 0, 0 sneak mov bomb, pclear hit1 jmp pit, pclear ; --------- dat 0, 0 dat 0, 0 dat 0, 0 dat 0, 0 hit2 dat 0, 0 dat 0, 0 dat 0, 0 pclear dat 0, 50 dat 0, 0 hit3 dat 0, 0 dat 0, 0 dat 0, 0 dat 0, 0 jbomb jmp #0, #0 hit4 dat 0, 0 ; --Bomber-- stcode inc spl #-step, step dat 0,0 vamp add inc, fang pfang mov fang, @fang ; drop fang mov jbomb, *fang ; drop jmp bomb jmp vamp, @pfang ; My memory's hazy about this line ; a jmp vamp, 0 should work exactly the same dat 0, 0 ; --Clear-- ; works with the same ptr as the pit for a fast clear (max 200% c with enemy) myclear mov dbomb, >pclear jmp myclear, pclear hit5 dat 0,0 dbomb dat 0, 50 dat 0, 0 dat 0, 0 fang jmp pit-stfang, stfang