[08:07] Join: fiveop joined #corewars [16:40] overnight found me a neat step size [16:40] it rocks the hell out of my dwarf now [16:40] :P [16:40] except one fight where it turned it into an imp [16:40] lol [16:43] i begin to see where the paper scissors stone analogy comes into play :) [16:43] except that i haven't really written anything good enough to not get beaten by any of them [17:14] i was wondering what might happen if i conveniently overwrote previous copies, i think this must be happening [17:14] have to study it later though [17:15] evitable: lot of papers do that [17:15] for ex. Return of the papers [17:15] yeah [17:16] to what effect? [17:16] without having done much testing, id say copies older than two generations [17:18] i mean, what do they get out of doing it [17:18] er, let me clarify [17:18] when i said overwriting, i meant executing previous code [17:18] since it falls off the end basically [17:18] but also i can see how killing off previous processes could be a good thing in some cases too [17:19] ah, the behaviour works best with coreclear-papers where papers basically get stuck in an attack-loop [17:19] because after N generations, the coreclears have so many processes that they overwhelm the new papers copying [17:20] so killing old papers helps holds a balance of movement and attacking [17:20] i was fascinated by the paper-spawned imp ring thing hehe [17:20] ah, neat [17:21] they have the general problem of being more neutral than the Swiss [17:21] paper spawned imp rings? [17:22] well, you generally dont use just one paper to launch and imp-ring [17:22] and -> an [17:23] well, may as a support for more agressive paper [17:23] i meant .. what was it, a core warrior article i think [17:23] where the idea was to choose a step size for the papers that would result in spawning imp rings [17:24] yes, "fugitive style" [17:24] but not only placement, process timing was important too [17:24] i just thought it was a neat thing [17:25] have you read Fizmo's paper-article? [17:26] http://www.corewar.info/lexicon/paper.htm see right side [17:28] i don't think so [17:29] but i will :) [20:45] lol [20:45] i was wondering at some bizarre behavior [20:45] now i realize what you meant by the step2, -2 [20:56] MSG: Quit: humhum [21:17] Join: sh0ne joined #corewars [21:18] Hello [21:21] hi [21:41] lol fixing that bug doesn't really change the score any [21:41] maybe it'll change the score range with respects to step size though [21:45] (not likely) [21:45] i bet better code would help! [21:47] MSG: Quit: Leaving [22:06] do papers usually have a low kill rate or do mine just suck? :) [22:06] what are you fighting against? [22:07] papers are not really known for slaughtering their opponents, and stone/imps have gotten very resilient to papers [22:07] benchmark [22:07] wilkies? [22:09] ya [22:11] wilkies isnt that hard to paper, two stones out of the 4 were already old when published [22:13] but id need to see the paper in action to say what is the biggest problem [22:24] hmm, just gave me an idea.. [22:26] well it's another "just for the hell of it" type thing [22:26] so i don't expect it to do well [22:26] but 10% kills seemed low anyway [22:27] http://www.nomorepasting.com/getpaste.php?pasteid=19602 [22:27] here's a current one [22:27] er, my clipboard editor fails [22:27] oh well [22:28] ack [22:28] and didn't copy all the code [22:28] 1sec [22:28] http://www.nomorepasting.com/getpaste.php?pasteid=19603 [22:28] there [22:30] 107, thats not bad by any means [22:31] but it could use just little more copying [22:38] oh, maybe not wilkies benchmark then [22:38] i don't actually know how many there are or what they are named ;P [22:38] how does one become resistant against papers anyway? [22:38] you either get bombed or copied over [22:38] imps [22:38] i can't really think of much to do about that [22:38] oh [22:38] i thought you meant the code was resistant [22:38] like djn-proofing stuff [22:39] hehe [22:44] adding one more silk and rising processes to 9 improves scores, but not how i'd like them to [22:44] before i fixed the second spl, there was a step set that made it get mad processes [22:44] i didn't track down why yet [22:45] 4002 [22:45] if i could get rid of the sub, wouldn't that have the same effect as increasing the time spent copying slightly? [22:46] not really [22:47] well, less cycles spent on something else [22:47] yes [22:48] but i guess it doesn't matter, what matters is spending time copying before the attack [22:48] as far as the balance goes [22:48] between attack/spread [22:49] ill go back to what i was experimenting on [22:53] though this is a little bit of challenge.. [22:55] that's what makes it fun! [23:37] hmm, either i got it not to work, or there is something im missing [23:38] after 10 version that scored meh, now i have one that behaves really well [23:49] huh [23:50] well there is a number that should be a constant [23:50] the @7 [23:50] changing the number of procs would affect that [23:53] i'd like to reverse that sequence if i could [23:53] i'm not sure i can though [23:53] hmmm, i do have one idea [23:54] just confusing myself [23:54] i'd have to change the pointer to where to lay down the movs to some other instruction [23:55] aha [23:56] i can make them all constant at least [23:56] mov xxx, it does do that [23:57] mov.i 2, {2 [23:57] it's the @7 i'd like to change, so they all use the same bomb [23:57] not really necessary unless i want to play with it more [23:57] no, i mean something like mov {2, <9 [23:58] or even mov }2, <9 (though i dunno if it'd work) [23:58] that'd make it reverse sequential.. biggest number last? [23:58] anyway [23:58] i originally had the sub line so i could modify both fields of the mov [23:58] but that won't work out [23:58] however i don't need sub the way it's in there now [23:58] i can do [23:58] add #7, step1+1 [23:59] er, add.ab [23:59] and use the a field as the pointer [23:59] it will become 1 before the add is executed [23:59] i think :)