There are several further ways to achieve self-replication and/or include uncommon features into a paper. Some of these ideas will be discussed below:

4.1 Cooperative Paper:

A cooperative paper is a paper which knows at all time the relative distance to a fixed position in the core, where it comes from or where it will replicate. This can be easily done for a programm with just a single process, but is much harder to realize if there is a decent number of parallel processes.

What kind of strategies could be made with it? Well, one example was already discussed in chapter 3.5, creating a stone-like bombing pattern.

Now let's have a look to the following code:

;redcode-94nop
;name Cooperative Paper #1

stone  <-- the stone is here

  .
  .
  .

pGo    spl    1
       spl    1

silk1  spl    @0,           <pStep1
       mov    }-1,          >-1
       sub.a  #(pStep1/4),  Go+pStep1
Go     jmp    stone,        }CoreColor

This is an example, where processes are pushed onto a fixed location in the core. In this case it would be the first instruction of a stone. So, how it works? There are two things one must do. The first thing is to substract the distance between two copies from the son which is already in progress to be copied. In this case it would be pStep1 instructions away. Due to the fact that the sub instruction will be executed several times one must divide pStep1 by the number of processes which are used. In this case it must be divided by 4. But keep in mind that there are some limitations. The sub instruction must be always the third instruction and the pointer which will be substracted in its copy must always be on the last instruction of the paper. Otherwise the paper won't be able to hand-off the right value to its copy.

That was just an example of how a stone/paper also could be done. But it isn't limited to boost just a stone. Also possible would be using a core-clear or an imp-launcher or something completely different. The first published versions of cooperative papers are Christian Schmidt's CrazyPaper and Iron Intention

4.2 'Kline-style' Paper:

Below are two examples of 'Kline-style' papers. The first were used in P. Kline's SnooPy. The second was published some times ago by P. Kline on r.g.c.
Both are working very well against imps and should be nice components for p-spacer.

Example 1:

slPaper  spl   wimp
         spl   1 ,{1000
         spl   1 ,{2000
         spl   1 ,{3000
p1s      mov   p1b,>8              
p1c      mov   <p1s,<p1n      
p1n      spl   @p1n,>-1356
         mov   p1b,<p1n
         mov   p1b,<-1000
         mov   p1b,>200
         jmn.f @0,>p1s
p1b      dat   <2667,<5334

Example 2:

pGo    spl   1 ,      >1100 
       mov   -1 ,     0 
       mov   -1 ,     0 
       spl   1 ,      >4100
 
       mov   >b1 ,    }b1 
       spl   r1+4000 ,>c1 
       djn.f r1 ,     <2100 

b1     dat   p1+4000 ,p1 
p1     spl   1 ,      0 
       mov   d1 ,     >a 
       mov   d1 ,     >b 
       mov   d1 ,     >c 
r1     mov   >p1 ,    >c1 
       mov   <c1 ,    {c1 
       djn   2 ,      #6 
c1     mov.x #x ,     #y 
       jmz   *c1 ,    *c1 
d1     dat   <5334 ,  <2667

4.3 Shrinking Paper:

That sounds at the first glance quite strange. The difference is in the second instruction. It self-replicate the paper starting with the dat-instruction right ahead of the code. If you keep in mind the order of execution during the self-replication of a normal paper one can see that the first execution of the copied paper ends in a dat, because there is at this time no instruction copied to this cell. This means, that every copy of the paper loses one of its paralell processes. The 'backbone' (the first silk-pair which copies the whole paper) will die after some few self-replications. Well, one can ask for the reason to do so. The idea behind was that a scanner will find simplest the large code of the 'backbone' and not the smaller self-replicating fractions of the paper. By eliminating the 'backbone' right at the beginning of a battle the chance should increase that the scanner will find the paper too late. Below is Shrinking Paper as an example:

;redcode-94nop
;name Shrinking Paper (part of it!!)
;author Christian Schmidt

spec  spl    pStep1, <pStep1-1
      mov.i  }-2,    >-1
silk1 spl    @0,     <pStep2
      mov.i  }-1,    >-1
silk2 spl    @0,     <pStep3
      mov.i  }-1,    >-1
bomb  mov.i  #1,     <1
cc    djn    -2,     <-22-pStep1
      dat    0,      0
      dat    0,      0

pGo   spl 2
      spl 2
      spl 1
      mov.i  -1,     #0

      mov    {cc+2,  {pBo1
pBo1  spl    cc+2000
      mov    <cc+2,  {pBo2
pBo2  jmp    cc+6000

4.4 'Moore-style' Paper:

David Moore has recently published a new kind of replicator which splits before copying:

spl  2
spl  1
spl  1

pNext   spl   4200,  {pThis
        mov  }pThis, }pNext
        mov   pDat,  >5200
pThis   mov pNext+6, }pNext
        jmz.f pNext, *pThis
pDat    dat  <2667,  <5334

This looks at the first glance a bit strange. pNext splits to the location where the next copy of the paper will appear soon. The b-field of pNext decrements the a-field of pThis. After the spl is executed six times the a-field of pThis points now to pNext:

pThis   mov pNext, }pNext

This is neccessary because the mov instruction uses now pThis' a-field as a source for copying the paper to its destination. But that means on the other hand that pThis will appear in the copied code while it was already incremented 3 times:

pThis   mov pNext+3, }pNext

But that isn't a problem because the spl of the copied code was already executed 3 times and will decrement pThis only further 3 times, which leads to:

pThis   mov pNext, }pNext

in the copy.

But keep in mind that this works only if pThis is the 4th instruction in the 6-line/6-process paper. For a 8-line/8-process paper it must be located as 5th instruction like:

spl  1
spl  1
spl  1

pNext   spl   4200,  {pThis
        mov  }pThis, }pNext
        mov   pDat,  >5200
        mov   pDat,  >2345
pThis   mov pNext+8, }pNext
        mov   pDat,  >3456
        jmz.f pNext, *pThis
pDat    dat  <2667,  <5334

With an 8-line paper it would be also possible to include a 'normal' silk, as shown below:

       spl    1
       spl    1
       spl    1

silk1  spl    pStep1,   {ptr1
       mov    }ptr1,    }silk1
silk2  spl    @0,       <pStep2
       mov    }-1,      >-1
ptr1   mov    silk1+8,  }silk1
pBmb   mov    pDat,     >bStep1
       jmz.f  silk1,    *ptr1
pDat   dat    <2667,    <5334

The advantage is that it nicley kill several coreclear paper and heavily optimized anti-imp papers. On the other side one must say that it is quite vulnerable against all kind of scanner.

4.5 'Evolved-style' Paper:

This kind of paper often appears during evolving of warriors with evolving programms. The main difference compared to 'normal' papers is, that the 'evolved-style' paper doesn't use a fixed number of paralell processes. It grows processes using a spl #0 instruction.
Below are some simplified examples showing some possible variations. Usually this code follows a bunch of bombing instructions and further spl-instructions.

Example 1:

      mov.i  {bStep1, {bStep2     ;bombing
      spl    #0
      mov.i  }-3,     }1
      spl    >pStep1
      mov.i  }-5,     }-1
         .
         .
         .

Example 2:

      spl    #0
      mov.i  }-2,     }1
      spl    {pStep1
      mov.i  }-4,     }-1
         .
         .
         .

Example 3:

      spl     #0
      spl     pStep1
      mov.i   }-2,     }-1
      mov.i   }bStep1, >bStep2  ;bombing
      mov.i   }-4,     }-3
         .
         .
         .

The 'evolved-style' papers behave different compared to 'normal' papers. Because they are able to kill 'normal' paper, especially on small coresizes. On the other hand they are quite weak against scanner, because the self-replication isn't the fastest one. They also just tie against imps.
The first known sucessfull 'evolved-style' paper appeared on the 94tiny hill.

Due to the above described behaviour it should be a very interesting approach combining an 'evolved-style' paper with a stone. Overcoming the weakness against scanner. Another approach would be the use of anti-imp bombs gaining the killing power against imps

Well, this field isn't well discovered so far. I am sure that we'll see in the future some surprisingly good warriors of that field.