Papers have basically no offensive power. They copy itself around the core and may overwrite the opponents code. It's a good strategy unless your opponent is just a simple stone (dwarf) which only dat-bomb and in/decrement the core. If such a stone contains additionally imps, the situation will be completely different. The paper must kill now, beside the stone, also the imps to get the victory. Otherwise the battle will end in a tie.

But there are also all those modern scanner (HSA, Willow, Claw, Zooom, Win etc.) and oneshots (CrazyShot, G2, Geist etc.) which will give a paper a really hard time to survive. Therefor the bombing is important to increase the chance for a lucky hit to kill or even wounding the scanner. But it has also another good effect, all the bombs the paper leaves in the core slowes down the scanner, because it spends time to wipe that 'useless' bombs. Also the oneshots will be entraped to start their core-clear in a 'dead' area of the core where it won't hit immediately or even early enough the paper. And finally if the paper battles against a stone/imp it increases its chance to kill not only the stone but also the imps.

2.1 The in/decrement inside the silk-engine:

A first approach to make the paper deadly against imps is the use of in/decrement in the spl-instruction of the silk-engine (see Chapter 2.4). The in/decrement before copying the papers code can kill imps. But the chance for such a lucky hit depends on how well the paper spread its copies. Usually it won't kill the imps not more than some few percents of all rounds. That is for sure not very satifying if the paper wins only about 1-5 times in a 100 rounds battle.

2.2 Additional Bombing Instructions:

For a further increase of the offensive power the paper must include special lines which don't deal with the self-replication but with some additional bombing of the core.

The most simple way of realizing this would be for example (as found for example in Timescape or Head or Tail) something like:

       mov.i    {bStep1, <bStep2

This instruction modifies 3 locations. First it decrements the locations bStep1 and bStep2 relative to the mov and then it moves what is found at bStep1-1 to the location bStep2-1. But remember that the paper is running with a decent number of parallel processes. That means, that the mov will executing more then just once. As long as the mov will be executed the location bStep2 away from it will be decremented and also will be used as a pointer for the bombs. This results in a linear (core-clear like) bombing, where the bomb-run is as long as parrallel processes are used (from bStep2-1 until bStep2-P).

2.3 The Bombs:

The mov could be also used to throw more specialized bomb which hurts the imp much more, like:

        mov.i   bomb,   >bStep2
           .
           .
bomb    dat.f   >2667,  >5334

This kind of bomb can be found for example in Pulp, Disincentive, Recycled Paper or CC Paper 2. The bomb in this example is commonly used against 3pt imps and is good against both, a- and b-driven imps. Much more deadly against imps are the following bomb used by nPaper II, Revenge of the Papers or Machines Will Rule:

aBomb   mov.i   #1,    {1

and

bBomb   mov.i   #1,    <1

This bomb can be nicly included into the paper, where they can copy itself as bombs. This will save one instruction in the paper. Another advantage is, that it can also good against djn streams and forward clears, as discussed below for cBomb. The only weak point is, that both are highly specific either against a-driven imp (mov.i #iStep, *0) as in the case for aBomb or against b-driven imp (mov.i #value, iStep) as for bBomb. That means, if a paper is using aBomb it will usually wins about 30% or more of the rounds if the opponent is using a-driven imps, but wins only about 5% if the opponent is using b-driven imps.

Another bomb less commonly used in modern papers is this simple one:

cBomb   dat     1,      1

This bomb is targeted against djn streams and forward clears, two forms of attack often used by paper enemies. The effect on streams is to make the process go ot of the loop, wasting time; the effect on forward clears is deadly, look at a simple forward clear

gate    dat     100,    1000    ;the clear is running 1000 cells away
....
clr     mov     bomb,   >gate   ;what's bomb don't matter, sure nothing with
jmp     clr                     ;a b-field of 1

If we hit the gate with cBomb the clear will begin running inside itself, till it reaches clr line and self destructs, very effective.

2.4 Embedded Coreclear:

To increase the linear bombing run of the paper it is possible to introduce a loop inside the paper as found for example in Benji's Revenge or CC Paper 2:

        mov.i   bomb,   <1
        jmp     -1,     <bStep
           .
bomb    dat.f   >2667,  >5334

The result is that every copy of the paper contains a simple core-clear which continuously wipe the core. This leads in a better core coverage but on the other hand it gives scanners also a better chance to slow down the paper by stunning all these numerous generated core-clears. A good idea in this case is to overwrite the own code which the paper left behind. If a scanner has stunned these codes the paper will overwrite it with the dat bomb and prevent itself for getting slowed down. Therefor a good starting point for the core-clear is essential. Instead of the jmp-instruction a

        djn    -1,     <bStep

can be used, which would give an additional djn-stream.

One can nicely combine this feature with the above discussed anti b-imp mov-bomb as found for example in Revenge of the Papers.

Interesting to mention is that better results are observed when the djn points to the mov of the silk-pair. Also the use of a djn.b -2, #value shows a significantly positive effect, as first observed in one of Vowk's evolved papers. The above mentioned improvements are also found in paper(paper(paper(clear))).

nothB spl    @nothB, <nstep1
      mov.i  }nothB, >nothB
bomb  mov.i  #1,     <1
cc    djn.b  -2,     #2335

2.5 Embedded Stone:

One could get a step farer than just embed a simple core-clear. Embedding a stone. Well, on the first glance it sounds quite easy to do this. Just put an add-instruction into the core-clear part of the papers code and that's it. But unfortunately it isn't that easy, because we are running in parallel processes. We must keep this in mind, because the add-instruction would execute P-times (P: number of paralell processes) in a raw followed by P executions of the mov-instructions in the above mentioned way. To let run a mov/add-instruction pair inside the paper in alternate order we must add an additional spl 2 in front of it, as seen in the example below.

0000         spl     1
0001         spl     1 
0002         mov     -1,     0
0003  silk1  spl.a   @0,     {pStep1
0004         mov.i   }-1,    >-1
0005         spl     2
0006         mov.i   bmb,    bStart
0007         add.ab  #bStep, -1    
0008  bPtr   jmp     -2,     <-2
0009  bmb    dat     >2667,  >5334

Using a spl 2 would lead into the following execution pairs (the executions of the copies and 0000-0004 are not shown for clarity):

7x 0005 (spl 2)

7x 0006 (mov)     /  0007 (add)  <---\
7x 0007 (add)     /  0008 (jmp -2)   |
7x 0008 (jmp -2)  /  0006 (mov)      |
\___________________________________/

The alternating mov/add pattern leads in a stone-like bombing pattern, while the jmp/mov-pattern makes due to the b-field of the jmp-instruction a linear wipe. The add/jmp-pattern in this case doesn't make any corecoloring. See also Minireturn of the Jedimp which contains a kind of imp-launcher/stone part inside the paper. Another more sophisticated way of generating a stone-like bombing pattern is to take advantage of the alternating execution order between the 'parents' and the 'children'. The bombing process would be spread over the copies of a paper instead of runing independantly in every copy. One could say that all paper cooperates with its 'parents' and 'children'. A cooperative paper. Below is the first published example using this technique, Paper Dreaming 2.

         spl   1
         spl   1
         spl   1
         
p1s      spl   @0,        >spacing
         mov   }p1s,      >p1s
p1k      mov   p1b,       >p1s+8-8*incr
         add   #incr,     @-1+spacing
         mov   p1b,       >p1s+80-7-8*incr
         sub   #incr+1,   @-1+spacing
         jmn.f @0,        {p1s
p1b      dat   <2667,     <5334

However, all of the above described ideas aren't effective enough against modern scanner and oneshots. The reason seems to be mainly a disadvantageous process allocation between self-replication and bombing. The bombing run is way too slow to trouble scanners. Therefore the first and most important step in developing a successful "silk-stone" is a good process allocation.

We can find a possible answer on a look to Minireturn of the Jedimp's code. It uses a spl #something right behind the spl/mov-silk to speed up the imp-launcher. One could do the same by using a dwarf instead of an imp-launcher. It will act then like a pure stone with a steady deceleration of the self-replication.

The first published warriors using a 6-line silk-dwarf are Christian Schmidt's He Bombs Alone, unheard-of and Venomouse Philtre:

        spl     2
        spl     1
        spl     1

silk1   spl     @0,             <pStep
        mov.i   }-1,            >-1
        spl     #sStep,         >-sStep
        mov     {sStep,         {-sStep+1
        add     -2,             -1
        djn.f   @0,             {-2

This silk-dwarf scores quite good against most carpet scanners but unlikely to 'normal' dwarfs it ties against other papers and stone/imps. It shows only weaknesses against oneshots and blur-style scanner.

Also other silk-dwarfs with different dwarf-components are possible.