HDTenEightyP/NetNews huggingface dataset:
From: maniac@cleanhead.cs.unlv.edu (Eric J. Schwertfeger)
Subject: Re: KOTH Suggestion
Reply-To: maniac@cleanhead.cs.unlv.edu (Eric J. Schwertfeger)
Organization: UNLV Computer Science and Electrical Engineering
Date: Thu, 30 Jul 92 01:35:32 GMT

In article <kilroy.712426758@mik.uky.edu>, kilroy@mik.uky.edu (Paul S. Kilroy) writes:
) |>I've got a suggestion for the KOTH server.  We've got a ;kill line, 
) |>how about a ;test line, IE run the program, report the results,
) |>but DON'T update the standings (except for something that got ;kill'ed).
) |>

) Well, I'll have to go against you guys on this one...
) When I want to test constants and Bombs, I just run sevreal "test"
) versions against the programs on the current hill, on "my"
) machine(using the mars simulator you wrote scott :))..
) Almost all of the programs on the current hill are 
) posted to this group, I kinda think this idea will just slow
) everything down more...
) 

Paul, prior to J. Cisek's posting, I only had the code to *ONE* of the
current X-Hill entries (not counting my own).  If I had the source to
several of the X-Hill entries, I'd agree with you.  It would seem that
people aren't sharing the X-Hill code as much as they are the regular
hill.  I think part of the reason the X-Hill lags behind the regular
hill in development is that most of the micro implementations of 
CoreWar don't handle the X-Hill limitations and expansions.  I know that
half of my x-code won't run at home because of initializations like 
these

PTR	MOV	#6, #0
	
or 
	
	DJN	LOOP,#6

Sorry for getting sidetracked there :-)  Even counting J. Cisek's post,
I only have 10 X-hill warriors, and few of those are on the hill.  I've
got a program that skunks Spider almost every time, but looses to almost
everything else.  But that's because I can play against spider and watch
it battle.

Now, if ALL submitions to the hill were made public, then I wouldn't
have any reason to complain, in fact I'd like that better because then
I could watch the battles in progress, and figure out where my
programs are going wrong.

I really don't think it would slow things down much more, because
those test programs are getting submitted anyway.

-- 
Eric J. Schwertfeger, maniac@jimi.cs.unlv.edu
Newsgroups: rec.games.corewar
From: maniac@cleanhead.cs.unlv.edu (Eric J. Schwertfeger)
Subject: Re: KOTH Suggestion
Reply-To: maniac@cleanhead.cs.unlv.edu (Eric J. Schwertfeger)
Organization: UNLV Computer Science and Electrical Engineering
Date: Thu, 30 Jul 92 01:44:25 GMT

In article <1992Jul29.170426.28358@murdoch.acc.Virginia.EDU>, eric@Turing.ORG (Eric Prestemon) writes:
) >|In article <1992Jul29.033416.22238@unlv.edu> maniac@taj.cs.unlv.edu (Eric J. Schwertfeger) writes:
) >|>I've got a suggestion for the KOTH server.  We've got a ;kill line, 
) >|>how about a ;test line, IE run the program, report the results,
) >|>but DON'T update the standings (except for something that got ;kill'ed).
) >|>

) Speed is an a problem, but I think it's minor. The hill just isn't that busy,
) mainly because of how fast Bill has the program running (good job!).
) 
) 	Possibly another alternative to the ;test line functioning above is:
) ;kill Quebec
) means replace Quebec on the hill IF this program does better. This removes
) the need to send tests 1-11 to figure out what are the best constants. 
) 
) 	And as to people being able to test against the current fighters,
) the fact that there are so many ;name test's around leads me to 
) believe that we need to do something...
) 

Rather than changing the operation of the kill line, how about using
;update (patern), where at the end of the tourney, the hill kills all
programs matching patern except the highest one.

This still doesn't satisfy my desire for a test and report only function.
In the case of my recent probe glut on the X-Hill, it would have been
nice if all the probes had gone up against the same programs.  However,
since some programs got knocked off (due to incorrect killing, it would
seem), I had to go through and compute scores by hand for each of the
probes against the subset of programs that all probes played against.

Though posting of all entries to the hill and the ;update line would
satisfy my every desire (except for keeping my tricks secret :-).  

-- 
Eric J. Schwertfeger, maniac@jimi.cs.unlv.edu
From: eric@Turing.ORG (Eric Prestemon)
Newsgroups: rec.games.corewar
Subject: Re: KOTH Suggestion
Date: 29 Jul 92 17:04:26 GMT
Organization: The Turing Project, Charlottesville Virginia.

In article <kilroy.712426758@mik.uky.edu> kilroy@mik.uky.edu (Paul S. Kilroy) writes:
>In <1992Jul29.152718.10746@oucsace.cs.ohiou.edu> sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins) writes:
>
>|In article <1992Jul29.033416.22238@unlv.edu> maniac@taj.cs.unlv.edu (Eric J. Schwertfeger) writes:
>|>I've got a suggestion for the KOTH server.  We've got a ;kill line, 
>|>how about a ;test line, IE run the program, report the results,
>|>but DON'T update the standings (except for something that got ;kill'ed).
>|>
[stuff deleted]
>Well, I'll have to go against you guys on this one...
>When I want to test constants and Bombs, I just run sevreal "test"
>versions against the programs on the current hill, on "my"
>machine(using the mars simulator you wrote scott :))..
>Almost all of the programs on the current hill are 
>posted to this group, I kinda think this idea will just slow
>everything down more...

Speed is an a problem, but I think it's minor. The hill just isn't that busy,
mainly because of how fast Bill has the program running (good job!).

	Possibly another alternative to the ;test line functioning above is:
;kill Quebec
means replace Quebec on the hill IF this program does better. This removes
the need to send tests 1-11 to figure out what are the best constants. 

	And as to people being able to test against the current fighters,
the fact that there are so many ;name test's around leads me to 
believe that we need to do something...

Just my thoughts...Anyone see anything wrong with "replace if higher"?
I guess it would have to have a different name, because straight ;kill's
are useful sometimes...
-- 
Eric Prestemon (ecp2z@virginia.edu) 
"Jesus saves! Gretzky steals! Gretzky scores!"
Newsgroups: rec.games.corewar
From: keithf@pacifier.rain.com (Keith Furrow)
Subject: How to play, And Where? (probabaly a FAQ, But I don't see the FAQ))
Organization: Pacifier BBS
Distribution: na
Date: Wed, 29 Jul 1992 22:03:27 GMT


I have read about corewar alot, and have found it *VERY* interesting. How
does one send their programs to a server?  What exactly does the server do?
What format are the programs in (I'm assuming assembly).  And what are some
common sratageys?  Sorry if these are in the FAQ.. (If there is one) but I
haven't seen it yet..
 

Keith..

-- 
keithf@pacifier.rain.com
Newsgroups: rec.games.corewar
From: dak@vlsi.polymtl.ca (Pierre Baillargeon (Hiv91))
Subject: Re: A Redcode Instruction Idea
Organization: Ecole Polytechnique de Montreal
Date: Fri, 31 Jul 1992 00:02:42 GMT

maniac@cleanhead.cs.unlv.edu (Eric J. Schwertfeger) writes:
: I was just thinking about the one thing that inhibits most of
: my more complicated wariors, and it occured to me that what
: I want is a "Sleep" instruction.

  I'm all for this.  This seems like the right counter-balance to the spl
instruction.  Can't think of any offensive for it right now, but I'm sure
someone will... (oups... just thought of one :).

--
"Pis Bourassa qui est toujours la.  Y'a pas d'remede contre le SIDA" - French B
"This is a mad house !" - Rosencrantz
...........................................................dak@info.polymtl.ca
Newsgroups: rec.games.corewar
From: eric@Turing.ORG (Eric Prestemon)
Subject: Re: KotH suggestions
Organization: The Turing Project, Charlottesville Virginia.
Date: Thu, 30 Jul 1992 13:25:32 GMT

In article <1992Jul30.041652.1273@unlv.edu> maniac@taj.cs.unlv.edu (Eric J. Schwertfeger) writes:
>In article <1992Jul30.024344.286@cs.yale.edu>, hastings-matthew@CS.YALE.EDU (Matthew Hastings) writes:
>) Yes, I am in favor of a test line.  I dont like the hill changes that
>) occur with test programs.  Here is another idea though: only record
>) scores against programs currently on the hill (so challengers which
>) don't get on have no effect [this change would probably hurt Flash Paper 3.7,
[stuff deleted]
>I think that would be the best solution.  I had thought about that while I was
>off the net, but had forgotten.  The MAIN reason I thought that this would
>be an improvement is this
>
>	1) A new program, in order to make the hill, has to score high
>	against the best programs.
>
>	BUT
>
>	2) An old program increases it's score every time a buggy program
>	is submitted.  Or how about all the 0-line programs that are submitted
>	to kill a program or to peek at who is on the hill.  I'm pretty sure
>	these raise the scores of the programs on the hill.
>
	I was going to reply by mail, but since 2 people posted this
misconception, (which I have publicly stated also) I figure this should be 
posted. The scores of the hill are based only on the 21 fighters
that appear on the list. Long-lasting programs do not gain an advantage.
Trust me, I know. I have had programs stay between 18 and 20 for a long 
time. =) Their scores didn't go up as time went on (unfortunately).

-Eric
Chairman, Committee for a Kill-If-Higher Line.
-- 
Eric Prestemon (ecp2z@virginia.edu) 
"Jesus saves! Gretzky steals! Gretzky scores!"
From: sadkins@bigbird.cs.ohiou.edu (Scott W. Adkins)
Newsgroups: rec.games.corewar
Subject: Re: KOTH Suggestion
Date: 29 Jul 92 15:27:18 GMT
Organization: Ohio University CS Dept., Athens

In article <1992Jul29.033416.22238@unlv.edu> maniac@taj.cs.unlv.edu (Eric J. Schwertfeger) writes:
>I've got a suggestion for the KOTH server.  We've got a ;kill line, 
>how about a ;test line, IE run the program, report the results,
>but DON'T update the standings (except for something that got ;kill'ed).
>
>The reason I say this is because sometimes I'll want to play around with 
>constants or other minor variations on a program.  Without a large pool
>of contestants, and a lot of work, I can't run my tests without submitting
>them to the KOTH server, which will mess with the standings.
>
>As much as I hurt other programs submitting several probes, I hurt my 
>best-standing program on the x-hill as well, taking it from 4th to 11th.
>
>-- 
>Eric J. Schwertfeger, maniac@jimi.cs.unlv.edu

I fully agree with this and think this is a great idea!!! :-)  What do you say
Bill?  Want to give it a whirl?

Scott Adkins
sadkins@ohiou.edu
Newsgroups: rec.games.corewar
From: maniac@taj.cs.unlv.edu (Eric J. Schwertfeger)
Subject: KOTH Suggestion
Reply-To: maniac@taj.cs.unlv.edu (Eric J. Schwertfeger)
Organization: UNLV Computer Science and Electrical Engineering
Date: Wed, 29 Jul 92 03:34:16 GMT

I've got a suggestion for the KOTH server.  We've got a ;kill line, 
how about a ;test line, IE run the program, report the results,
but DON'T update the standings (except for something that got ;kill'ed).

The reason I say this is because sometimes I'll want to play around with 
constants or other minor variations on a program.  Without a large pool
of contestants, and a lot of work, I can't run my tests without submitting
them to the KOTH server, which will mess with the standings.

As much as I hurt other programs submitting several probes, I hurt my 
best-standing program on the x-hill as well, taking it from 4th to 11th.

-- 
Eric J. Schwertfeger, maniac@jimi.cs.unlv.edu
Newsgroups: rec.games.corewar
From: hastings-matthew@CS.YALE.EDU (Matthew Hastings)
Subject: IAASMR3-6
Organization: Yale University Computer Science Dept., New Haven, CT 06520-2158
Date: Mon, 27 Jul 1992 21:22:39 GMT

Here is IAASMR3, which is basically the same as all the others.
It's short for insert another appropriate stout mythological race (i.e.
dwarf, kobolod, gnome).  This is a way of core-clear I haven't seen seen 
elsewhere.  I also tried to make first pass SPL 0 in an attempt to beat
Flash Paper3.7.  Did not work.  Only 10 wins.  About 80 losses.
I got a KotH bug report too: the 0 length program used to kill IASSMRwhatever
had 0-100-0 against everybody except 1-99-0 against SNM.  Weird.
BTW, TestKappa, which I just killed, is an attempt to find out if the hill is
much more advanced than it was when i started writing redcode.  It is exactly
the same as raf, my first redcode program to be submitted to the hill.  It is
an exceptionally bad version of RotLD, it only clears about 40% of core before
wiping itelf out.  So SPL 0 programs should have a fun time.  Still made it on
the hill.  But only barely.  I think the real reason it got on is that there
arent many programs of its type on the hill (just Relentless right?) 
It does have a nice startup system:each "Living Dead (not really though)"
starts with an SPL ---, which starts a process off at next Living Dead.
And finally, if you go to 64 proc. count max:it will actually be a lot
tougher to write a paper program.  Flash Paper starts w/ about 64 processes
and keeps going.  Also it will be a lot easier to write a gunned program.
(and I think there is still a lot of room to write those now).q
;redcode
;name IAASMR3
;kill IAASMR
;author Matt Hastings
;strategy Self-splitting Stone bomber with two pass
;strategy core-clear; main-loop-overwriting DJN stream
;strategy resets core-clear location and pointer.
;strategy yeah, I'm working on it.
spl 0,2
dat #0,#12
start mov -1,6-12
mov -3,3+1-28
mov @28,<-28
spl 0,1
mov <1+28,0-28
add -3,@-2
djn -2,<-11
end start
From: fraserc@dcs.glasgow.ac.uk (Campbell Fraser)
Newsgroups: rec.games.corewar
Subject: No Mucking About
Keywords: KotH
Date: 28 Jul 92 09:12:45 GMT
Organization: Glasgow University Computing Science Dept.

With the hill about to go to a maximum of 64 processes, now seems a good time
to post "No Mucking About". A scanner which drops a largish bomb -
"spl 0/spl 0/spl 0/jmp -3". Destroys replicators but doesn't waste too much 
time bombing decoys against other warriors.

;redcode verbose
;name No Mucking About
;author Campbell Fraser

GAP     equ -98
GAP2    equ -49

CHECK   add INC, POS
POS     cmp -50, -1
        slt #14, POS
JB      jmp -3
        mov JB, @POS
        mov SB, <POS
        mov SB, <POS
        mov SB, <POS
        add AIM, POS
        jmn POS, CHECK
SB      spl 0
AIM     mov @GAP2, <(GAP2+3)
INC     dat #GAP, #GAP
-- 
Hi, I'm a .signature virus. Copy me to yours and then wipe all your files.
Campbell Fraser: fraserc@dcs.glasgow.ac.uk
Computing Science Department, University of Glasgow, Glasgow G12 8QQ
Newsgroups: rec.games.corewar
From: t-jcisek@microsoft.com (Julius Cisek)
Subject: The ;kill line
Date: 28 Jul 92 20:41:54 GMT
Organization: Microsoft Corporation


There is no excuse for not killing your programs.  If your kill line
doesn't work one time send in EMPTY programs with kill lines in them
instead of sending the same successful program over and over!

I can't believe Juggernaut 6.0 got knocked off because of this...

The ;kill line will NOT work from different accounts (how could it).
It would be nice if you all just submitted from one account.  Is it
really too much to ask?

Lastly, what is the point of a ;kill line if you specify a specific
version.  Use ;kill [generic name] instead.  There should be only one
copy of your programs on the hill.  And don't use successful programs
to try and get the other ones off.

This is really getting annoying.
-- 
Julius Andrew Cisek                ,_,
t-jcisek@microsoft.com   "Joy!"   /oo \  _.-.   "Quiet, you bloated
One Microsoft Way     //          <>__| /- O O       idiot!"
Redmond, WA 98052   \X/           |  U|    \|
From: AZNXS@ASUACAD.BITNET
Newsgroups: rec.games.corewar
Subject: Re: KOTH Suggestion
Date: 30 Jul 92 16:23:07 GMT
 <1992Jul29.152718.10746@oucsace.cs.ohiou.edu> <kilroy.712426758@mik.uky.edu>
 <1992Jul29.170426.28358@murdoch.acc.Virginia.EDU>
Organization: Arizona State University

1 vote for ;test
1 vote for the new ;kill  /* what do you think of the name ;kill+
Nandor.
Newsgroups: rec.games.corewar
From: maniac@cleanhead.cs.unlv.edu (Eric J. Schwertfeger)
Subject: A Redcode Instruction Idea
Reply-To: maniac@cleanhead.cs.unlv.edu (Eric J. Schwertfeger)
Organization: UNLV Computer Science and Electrical Engineering
Date: Thu, 30 Jul 92 02:07:48 GMT

I was just thinking about the one thing that inhibits most of
my more complicated wariors, and it occured to me that what
I want is a "Sleep" instruction.

In other words, if Proc A and Proc B are running, and Proc B
executes a SLEEP 100, Proc A would get 100% of the CPU time 
for the next 100 cycles.  IN this way, if you have a worker
proc and a supervisor proc, and the supervisor proc does its
thing periodically, then the supervisor could sleep, giving the 
worker more CPU time.

I know this suggestion will draw fire, and I'd like to discuss
any problems that might occur.

First, this might create "hiders", programs that do something like
this.

HIDE	SLEEP	-1
	JMP	HIDE

and leave one bomber out there.  The hider would still be vulnerable to
having it's code bombed, so when it wakes up, its dead.  This would mean
that in order to effectively combat these, you would either need a 
mod 2 bombing pattern, or after bombing is done, execute a core-clear.

Also, the time to sleep MUST be absolute clocks (ie, it is now
cycle 1012, wake me up at that plus 800, regardless of how many processes
are running).  The problem with saying "pass my next X clock cycles is that
someone would think of something like this.

START	SPL	HERE
	SLEEP	-1
	JMP	 START

The problem with this is, that if there are say 64 processes, and they are
sleeping for 8000 cycles, then it would take 256000 cycles for them all to
wake up, and by then the game would be over.

Using absolute cycle counts (or some other variations I won't go into here) 
eliminates this posibility, because every process will get a chance to
execute at least once every 8000 cycles, so if you clear core, everyone
will be dead within 8000 cycles (same as for a SPL 0, JMP -1 trap).

However, allowing sleeping processes to get more than one pass per cycle would
also be bad, because then you could have a program execute several sleep -1's
and you could expect that the only way it would get to the end is if the active
process died, causing the sleeping process to pass as many times as necessary to
wake up, which would be in the next cycle if you allowed it to continue passing
within the same cycle).

-- 
Eric J. Schwertfeger, maniac@jimi.cs.unlv.edu
Newsgroups: rec.games.corewar
From: maniac@taj.cs.unlv.edu (Eric J. Schwertfeger)
Subject: Re: KotH suggestions
Reply-To: maniac@taj.cs.unlv.edu (Eric J. Schwertfeger)
Organization: UNLV Computer Science and Electrical Engineering
Date: Thu, 30 Jul 92 04:16:52 GMT

In article <1992Jul30.024344.286@cs.yale.edu>, hastings-matthew@CS.YALE.EDU (Matthew Hastings) writes:
) Yes, I am in favor of a test line.  I dont like the hill changes that
) occur with test programs.  Here is another idea though: only record
) scores against programs currently on the hill (so challengers which
) don't get on have no effect [this change would probably hurt Flash Paper 3.7,
)  BTW]).  Also, permit a program to contain a ;kill line that ;kills itself.
) So... if you want to test, just kill yourself, and it doesn't count for
) other programs.

I think that would be the best solution.  I had thought about that while I was
off the net, but had forgotten.  The MAIN reason I thought that this would
be an improvement is this

	1) A new program, in order to make the hill, has to score high
	against the best programs.

	BUT

	2) An old program increases it's score every time a buggy program
	is submitted.  Or how about all the 0-line programs that are submitted
	to kill a program or to peek at who is on the hill.  I'm pretty sure
	these raise the scores of the programs on the hill.

Every time I submit a program now, I tweek the constants so the new version
will trounce the old version (pretty simple to do if you understand my
X-Hill programs).

I think this is a better solution that what I suggested, because it fixes
this problem as well as the "test program" problem.

I do think the kill-self line should be different, rather than just changing
the way the current kill command functions, because I've seen people
submit a newer program with the same name as the old one, and kill the old
one at the same time.

-- 
Eric J. Schwertfeger, maniac@jimi.cs.unlv.edu
Newsgroups: rec.games.corewar
From: hastings-matthew@CS.YALE.EDU (Matthew Hastings)
Subject: TestB
Organization: Yale University Computer Science Dept., New Haven, CT 06520-2158
Date: Wed, 22 Jul 1992 00:46:04 GMT

Here is TestB-I just killed it cause I don't like it.  It is
a bit of an obscure progrtam.  BTW, if it worked it was going to
have been called A B-scanner Darkly
;redcode verbose
;name TestB
;author Matt Hastings
mov #155-clear,clear-156
mov #-2,clear-155
add clear,1
mov <1,3
jmz -2,<1
mov sb,1801
jmp -4,0
sb spl 0,<-255
clear mov @155,<-155
jmp -1,<-1
Newsgroups: rec.games.corewar
From: advpel@xs0001.tuvie.at.uucp
Subject: Help needed
Organization: Gemeinde Wien, MD-ADV/Ma, Ref. EPS
Date: Wed, 29 Jul 1992 12:14:09 GMT

I've tried several times to submit my program RATCATCHER to KOTH
without any success or answer. So I give up and ask you: would someone
be so kind to submit my prog for me an tell me the results (my address
is 100% correct and reachable) ?
----------------snip-----------
;redcode verbose
;name ratcatcher
;author M.Pellmann
;strategy convert all to  mov 0 1 and kill it with djn
;
target3  dat  #0
target2  dat  #4000
target1  dat  #1000
target   dat  #-200
start    spl  send0
         spl  send1
pre     mov  b1,<target
        djn  pre,<target
        spl  loop1
        spl  loop2
        spl  loop3
        spl  send
        mov  #20,target
loop    djn  loop,<target
        jmp  loop
        dat  #0
        dat  #0
b1      dat  #0
loop1 	djn  loop1,<target1
        mov  dat1,target1
        jmp  loop1
        dat  #0
dat1    dat  #0
        dat  #0
loop2   djn  loop2,<target2
        mov  #0,target2
        jmp  loop2
        dat  #0
        dat  #0
        dat  #0
loop3   mov  dat,<target3
        djn  loop3,<target3
        add  #10,target3
        jmp  loop3
        dat  #0
        dat  #0
send    mov  knirps,20
        mov  #1,19
        mov  #1,19
        jmp  17
dat     dat  #-5
knirps  mov 0,1
        dat #0
send0   mov  knirps,70
        jmp  69
send1   mov  knirps,4000
        jmp  3999
        end  start
------------o<-----snip-------------

Thank you in advance

Michael Pellmann
pel@magwien.gv.at (or pel@xs0001.at)


Newsgroups: rec.games.corewar