Idea: Exploiting the weakness of large warriors.

Here's an idea:

- fast coarse scan for large opponent
- back up 100 locations
- sequential scan for the first non-zero location
- sequentially bomb using both the found a- and b- values as indirect
pointers
- bomb the found code as well

Using the a- and b- values as indirect pointers will get at booted
code if those values were used as jmp or copy pointers.

Wait! That pretty well describes Shamu And it works very well
against some notable programs on the present hills. Reference:
http://groups.google.com/group/rec.games.corewar/browse_thread/thread/...a018942

Shamu and many other interesting programs can be found at:
http://www.ociw.edu/~birk/COREWAR/94/hill.html

P. Kline
 >> Stay informed about: Idea: Exploiting the weakness of large warriors. 

Ok,

Here is a further idea:

As soon as the boot program is found scan the parameters into p-space.

Then start bombing the locations in p-space.

This is to have a good copy of the parameters.

It's also a way to quickly load the enemy boot program into p-space before
it's overwritten.

A counter could be used as well to indicate when all locations in p-space
have been slightly carpet bombed.

Then if the enemy was not killed it was unsuccesfull, maybe not entire
program copied, then simply start a normal bomber.

Bye,
Skybuck.
 >> Stay informed about: Idea: Exploiting the weakness of large warriors. 

Wow, I just had a cool idea:

Since p-space remains valid between rounds the following could be done:

Focus on reading all parameters as good as possible into p-space the first
few rounds.

Then once the these have been acquired successfully, they no longer have to
be read in.

Then the only thing necessary to do is find the boot program.

Then carpet bombing can start immediatly as soon as location find.

Now only thing left to do is find the start and end of boot program
quicker/faster/more precise and perform better copies somehow before it's
overwritten.

Kinda interesting.

Bye,
Skybuck.
 >> Stay informed about: Idea: Exploiting the weakness of large warriors. 

Yeah and if combining the cloack technology with the boot program finder
technology.

Then the program finder can have more time pinpointing the exact location of
the boot program.

Only problem is pinpointing it requires more time, leave to few time to copy
it into p-space.

But multiple rounds could be used to try and load different sections into
p-space.

And simply stop scanning/loading when dat and spl 0 0 are encountered which
could indicated a bombed boot program.

Then later the rest of our program can be de-cloacked to perform it's
tasked.

Meanwhile during the first rounds after it's done scanning and can't copy
any further it just tries to bomb for as far as possible and then simply
enters end game bombing mode or so.

It should also delete all it's p-space instructions to prevent enemies from
messing with p-space.

However this won't prevent it, enemy p-space warriors might capture our
threads and execute bad p-space instructions so deleting p-space stuff will
have not too much affect on those enemy p-space warriors, but maybe still
smart to do just in case

Bye,
Skybuck.
 >> Stay informed about: Idea: Exploiting the weakness of large warriors. 

<pauldkline DeleteThis @aol.com> wrote in message
news:bf36396d-2f12-4011-82de-882c93949668@u10g2000prn.googlegroups.com...
> Here's an idea:
>
> - fast coarse scan for large opponent

I tried steps of +80, +127 and +129

> - back up 100 locations

Tried that.

> - sequential scan for the first non-zero location

Tried that.

> - sequentially bomb using both the found a- and b- values as indirect
> pointers

Tried that.

> - bomb the found code as well

Not really necessary except if incorrect program is found so it's safe to do
that as well.

> Using the a- and b- values as indirect pointers will get at booted
> code if those values were used as jmp or copy pointers.

Yup.

> Wait! That pretty well describes Shamu And it works very well
> against some notable programs on the present hills. Reference:

Hmm well what you describe I already tried that.

It doesn't work so well against RecycledBits.

The "coarse" scan or "rough scan" as I like to call it works well for
finding the boot program somewhere.
(Sometimes it might not work immediatly because of dat $0, $0 and spl $0, $0
located in the boot program of recycled bits)

Then the problem is with the step back 100 and proceed sequential scan.

That takes too long.

By that time RecycledBits will overwrite parts of it's boot program with spl
$0, $0

So something faster has to be used.

Also I don't know if shamu stores the enemy boot program in p-space but I
choose to do so, otherwise the boot program might be destroyed by our own
bombers, because some parameters might be small and therefore bomb the boot
program itself.

However a possible alternative solution might be to only bomb "large"
values.

Because only large values could be an indication of jumps and spawns outside
of the boot program.

At least this would work for RecycledBits... but what about other warriors
which might jump into the boot program itself ? Maybe that's unlikely ?

Anyway such a technique could be tried.

That solves a few problems:

1. Enemy boot program won't be bombed prematurely.

2. Our own p-space does not need to be used.

It has a drawback too:

3. My p-space technique might be re-used in subsequent rounds.

But then some method must be found to make sure the correct p-space values
were loaded from the enemy boot program.

Ofcourse the warrior could just take a risk, and just submit it multiple
times against a hill until it gets a really luck run against all
warriors.... might work, or maybe not

Ok, I'll check it out.

http://groups.google.com/group/rec.games.corewar/browse_thread/thread/...a018942> Shamu and many other interesting programs can be found at:> http://www.ociw.edu/~birk/COREWAR/94/hill.htmlBye, Skybuck.
 >> Stay informed about: Idea: Exploiting the weakness of large warriors. 

Yes I just had an idea how that might work.

The following information is stored into the p-space:

Enemy Parameter Value, Enemy Boot Program Offset
Enemy Parameter Value, Enemy Boot Program Offset
Enemy Parameter Value, Enemy Boot Program Offset
Enemy Parameter Value, Enemy Boot Program Offset
Enemy Parameter Value, Enemy Boot Program Offset
Enemy Parameter Value, Enemy Boot Program Offset

This way the program simply stores each value it finds at the p-space
location.

It doesn't know the offset yet, to it scans backwards or forwards whatever
until i thinks it find the end of the boot program.

Then it can figure out/calculate the appriorate offsets.

This allows the boot program finder to gather enemy boot program knowledge
during multiple rounds.

The boot program finder could store new information at a distant location in
p-space....
and then once it knows the correct offset copy the necessary information to
the final destination.

Yes I think that might work just fine.

Actually it doesn't even need the program offsets.

I can just store the information as follows:

P-Space:

Enemy Boot Program Parameter A
Enemy Boot Program Parameter A
Enemy Boot Program Parameter A
Enemy Boot Program Parameter A
Enemy Boot Program Parameter A
Enemy Boot Program Parameter A

up to 100

Enemy Boot Program Parameter B
Enemy Boot Program Parameter B
Enemy Boot Program Parameter B
Enemy Boot Program Parameter B
Enemy Boot Program Parameter B
Enemy Boot Program Parameter B

up to 100.

STORE NEW unsorted information:

New Parameter A
New Parameter A
New Parameter A
New Parameter A
New Parameter A

up to 100

New Parameter B
New Parameter B
New Parameter B
New Parameter B

up to 100

Then once it figures out the correct offset/boot program location it can
copy the new parameters to the correct position in p-space.

This way the boot program finder can build the enemy boot program parameters
partially, which is kinda/really nice =D

YES LOL.

And once it believes it has the entire enemy program that it doesn't need to
do this whole process and can just start bombing the enemy program right
away.

It could also store the maximum found length of the enemy program to modify
it's scan stepping for more precision. Otherwise if it's a small warrior it
might step over it with big steps.

So once it finds warriors fine tune the stepping...

Seems like cool idea.

Also use cloack technology to hide anything else.

Bye,
Skybuck.
 >> Stay informed about: Idea: Exploiting the weakness of large warriors. 

Yeah and before it starts the sorting of new information, it should first
bomb the found program in case it was the real enemy warrior, since that
information should not end up in the parameters.

Unless ofcourse it's a kind of self copieing warrior, maybe that kind of
information might be nice too but it's not part of the algorithm so it has
to be thrown out for now at least, unless extra information is stored as
well, like location or so... location+parameter = bomb location.

But I won't do that for now.

So to make sure only boot program ends up in p-space, bomb the boot program
in case it's not the boot program.

Hopefully then we will win before the "sorting" of new information begins

(It's not really sorting ofcourse, just copieing to correct offsets in p
space etc)

Bye,
Skybuck.
 >> Stay informed about: Idea: Exploiting the weakness of large warriors. 

Actually when it starts using the p-space information to bomb the enemy
program.

It can store it's information back into p-space as well.

For example the warrior can store the last known boming location.

This way the last known bombing location/offset/value/whatever will be known
on the next run.

So then the warrior can try that bombing location/offset/value/parameter
first !

That way it could immediatly destroy the enemy warrior once it found it's
boot program location.

Or it can accelerate itself on each subsequent round by simpling continueing
bombing where it left off on the previous round

Bye,
Skybuck.
 >> Stay informed about: Idea: Exploiting the weakness of large warriors. 

Hmm unfortunately it won't be so easy to use the p-space information on next
round.

I forgot the scan locations value in p-space are from an unknown offset from
the enemy boot program.

So that would need some major modifications

Oh well

Bye,
Skybuck.
 >> Stay informed about: Idea: Exploiting the weakness of large warriors. 

Well since little values are now no longer bombed, it doesn't make much
sense any more to store the parameters in p-space.

So instead the "possible pointers" could be bombed directly.

An alternative use of p-space might be to remember which value or maybe
which parameter a or b or maybe which offset was bombed last since this
could indicate the "real pointer" so it can quickly be tried on the next
run.

I will try to modify my program so it's more efficient and doesn't use
p-space anymore at least not for storing these parameters.

Bye,
Skybuck.
 >> Stay informed about: Idea: Exploiting the weakness of large warriors. 

>> - sequential scan for the first non-zero location
>Tried that.

This scans sequentially at 1.5c:

sne >ptr,>ptr
jmz.f -1,>ptr

It will put you within one location of the first non-zero in the
opponent, which is good enough.

P. Kline
 >> Stay informed about: Idea: Exploiting the weakness of large warriors.