[00:24] Join: myndzi joined #corewars [00:27] MSG: Ping timeout: 245 seconds [02:11] well that's kind of disappointing [02:11] shows the value of qscans though i guess [02:12] but still cobbling something together that beats all my other entries is like :( [08:52] Join: fiveop joined #corewars [10:46] qscans are useful only if opponents are large [10:47] opponents with qscans are large [10:47] test scores kinda like oneshot-clear [10:48] fiveop: and how many of them are at the beginner-hill? (well, crack has one..) [10:52] dunno [15:31] i forget what a oneshot is [15:31] but that's pretty much it; i just wanted to try and get a qscan working [15:32] next i get to work on optimizing it up to "modern" standards hehe [15:32] with q^4s and the like, i notice there are less positions scanned [15:33] due to how they work of course [15:33] but you could still double it up i think [15:33] i don't think anyone bothers though, is there a reason for this? [17:12] it is a limitation caused by the lessning reaction-speed [17:13] old qscan can easily take double the time between succesful scan and the actual attack [17:15] reaction-speed is generally more important that the actual amount of locations scanned, especially when nearly all warriors have a qscan in them [17:15] well, 1 cycle of improved speed is more important than one pair of locations [17:16] results may vary [17:36] oh sure, i totally agree [17:36] but i mean, you could just put the equivalent of two q^4s back to back [17:37] and not really lose any speed (other than the time invested in the longer scanning run) [17:37] and it didn't seem like anyone bothers [21:49] who was it that was talking about unrolling bomb loops in papers? [21:49] papercut mk. 2 is something like that [21:49] i think it spends too much process time bombing now [21:49] since it's 7 instructions long [21:49] which gives it 7 mov instructions [21:49] it kills itself a lot :P [22:01] hmm [22:02] spl @0, step | mov }-1, >-1 | mov }-2, >-2 allows you to halve the processes [22:20] er wat [22:20] you can see the codes? [22:21] that wouldn't do the same thing, at any rate [22:21] havent seen the source, so i make assumptions [22:22] ah [22:24] it's not quie what i meant, i don't remember who was talking about the 'compression' thing [22:24] i'll describe in a bit [22:25] the idea of creating a carpet of bombing instructions [22:26] kinda hard to do, but with paper-cooperating mov/add is should be possible [22:28] well, that too would be a bit hard [22:29] that's what i did [22:30] here's working source if you want [22:30] http://www.nomorepasting.com/getpaste.php?pasteid=19547 [22:30] i think i can ditch the add [22:30] but haven't gotten that far yet [22:31] and i was thinking about maybe instead of falling off the end, end it in a jmp and unroll the bombing instructions over the rest of the code before the jmp [22:32] mul.ab step+1, *step+1 [22:35] er, not quite [22:35] that add is what synchs the movs to use the same pointer [22:35] but the movs need to be sequential of course [22:36] why would you want to use the same pointer? [22:36] so that they don't bomb on top of each other or something? [22:36] it winds up like [22:36] mov.i ?, <-7 [22:36] mov.i ?, <-8 [22:36] mov.i ?, <-9 [22:36] mov.i ?, <-10 [22:36] etc [22:36] more of a clear really [22:36] why is seven instructions with one pointer better that mov/jmp or mov/mov/djn? [22:37] ? [22:37] i cant see a reason myself [22:37] the bomb pointer [22:37] oh i think i see what you mean with the mul now [22:37] you're right that would be useful [22:38] but no, i was just playing with the idea whoever it was set up in the first place [22:38] i realized i could sync the movs, which was the problem he was having(?) in a similar way to how bolo operates [22:38] well, (s?)he shalt have interesting read on this talk [22:38] so i put it together and tried it [22:39] i think the mul is nicer, it doesn't have to bomb in a line and there's probably more chances of not bombing itself [22:39] i'll see if i can get that in along with the other change, maybe i can reuse one of the poiners in one of the spls then [22:43] scuse me, i think the trouble was syncing the mov instructions without extra code [22:43] which maybe i can do this way, i'm not sure [22:43] that's what i meant by getting rid of the add [22:47] i dont really like that spl step2, -2 , i have to say [22:49] my head is getting woozy, "improvement" obviously didnt work after checking it on notepad [23:34] MSG: Quit: humhum