[00:44] Join: pkhuong joined #corewars [00:48] MSG: Ping timeout: 255 seconds [01:34] Join: Leniad joined #corewars [01:35] anyone here? [02:21] We Live! ;) [02:34] whoa [02:35] and it was less than an hour of waiting [03:35] MSG: Ping timeout: 255 seconds [03:57] Join: multimode joined #corewars [07:25] MSG: Read error: Operation timed out [07:28] Join: pak21 joined #corewars [08:11] Leniad, still there? [09:42] MSG: [12:41] Join: Mizcu joined #corewars [14:46] Join: Shilock joined #corewars [14:47] hi Shilock [14:55] Hey [15:03] Hmm. John, appear here, i have something to show you! [16:45] I shall sacrifice a two-headed sheep to summon the Johnmonster! [17:02] Part: Shilock left #corewars [17:02] Join: John joined #corewars [17:03] Part: John left #corewars [17:05] o_O [17:05] fake! [17:19] Join: Shilock joined #corewars [17:19] * Shilock continues his trek to learn and make newb warriors. [17:33] JMN.A tests the A field of the target line for it's zero-ness, right? [17:33] for non-zeroness [17:34] or however one wants to say it [17:36] awesome. [17:36] ...I have a 4 line streatch of code that basically copies everything above it and then move the process there. [17:36] I'm getting a hang of this. [17:40] Now lets adjust the copy point so I don't create to proccesses on different sides of the core that are effectivly scanning the same thing... [17:46] mm-m [17:48] I think my problem is I don't see how I can actually make things more efficient then they are... [17:48] unroll loops (only in some cases), combine instructions if possible [17:49] Well, its not that... its that I can't think of a single case in which making code more complex can make it better. [17:50] ...I mean, I see no reason to ever go past... say 20 lines. [17:50] most efficient warriors are dumb, which have some other way of intelligence in them [17:50] hmm? [17:50] 20 lines in a main warrior is horribly oversized [17:51] for example, some warriors which launch 3 components at start can kill some of their components if some result is not acquired early enough [17:51] or so that killing one component strenghtens other component which should be stronger against what most likely killed the one component [17:52] Well yeah, I kinda figured that... thats why I added 4 lines of code to my 9 line bot in order to duplicate it offset from the origonal by 90 degrees [17:53] when you check the warriors on koth, pretty much all of them are 100 lines [17:53] The scanning pattern I have would kill this second warrior just before it would kill the first. [17:53] How can that much code be a good thing? [17:54] that is because they have a) quickscan b) empty space between components to be less weaker against scanners c) to conceal what the warrior might be [17:54] c is no longer viable [17:54] what exactly is a quickscan? [17:54] it is an unrolled scan-loop [17:55] reaches excellent speed (2 scans per instruction run) for some cycles, but takes a lot of space and it is not loopable [17:56] it looks pretty much like: [17:56] Well lets see, my code loops and it checks ( on average ) 1 line per cycle [17:56] SNE, SEQ, JMP, SNE, SEQ, JMP I'd assume is their idea... [17:57] yes [17:57] the jmp instruction is something to extent of jmp decode, and the decoder uses the values of table to get the place where scan triggered [17:58] 1 line per cycle? [17:58] but doesn't that just mean that the targeting has to be 'hardcoded' using equations relative to coresize? [17:59] yes [17:59] but because the distances between warriors are randomized for each battle, that is not a problem [18:00] well mine just does SNE, SEQ, JMP, ADD.F, JMP [18:00] It uses a DAT to store targeting, which gets decremented during each of the scans and then dropped another 4 by the ADD. [18:00] but you have two instructions and only one add [18:01] are you using something like sne }1 >1? [18:01] Yeah, it scans two lines next to each other, then skips 4, and then scans the next 2... [18:01] i do not think that is very efficient [18:01] start: SNE SEQ Hmm... maybe I could give it two scanning patterns... [18:03] add.f inc, 3 [18:03] sne.i *2, @2 [18:03] add.f inc, 1 [18:03] sne.i step, step+hop [18:03] jmp -4 [18:04] hmm... nice... and inc I assume is just a DAT 4, 4 or something like that. [18:04] yes [18:05] http://www.corewar.co.uk/scanner.htm [18:05] Dude... does DAT just stand for DATa-file? [18:05] I'm using them more to store stuff then to actually kill... [18:06] it originally meant just DATa [18:06] but now its official meaning is "kill the process running instruction" or like [18:07] there is nothing wrong in storing stuff in DAT's, if you cant fit your numbers anywhere else [18:07] ...I'll use NOPs! [18:08] well, if you are overwritten by that storage of yours, you are screwed be the instruction dat or nop [18:10] Oh btw... how do I protect from self-scans without slowing down my code too much... [18:11] use slt -instruction [18:11] see rave.red for example [18:12] you can also makeyourself invisible in some cases, i think Agony and/or Agony II uses it [18:13] Oh duh... I use a copy code to create a second scanner... though it would slow the proccess down, I could just do the math so that the SNE's are looking at their mirrors. [18:14] Then the only thing of myself I could see would be that DAt-- which is pointless cause I use the same dat to attack with. [18:17] Well, thats awesome... I have my aim data on my first line, so the SLT is just that, mindistance... but it still slows down my code... [18:26] well, that just cant be avoided [18:28] What do you think I should shoot at them? [18:30] traditionally scanners throw spl 0's at first, and then wipe the core with dat's [18:30] You throw whatever you want [18:30] Right now I have it rigged so that my first 6 shots are SPL, then 6 mov #0, -1, then dats [18:30] thats awful lot of stuff [18:31] Well I can change the ammo easily enough [18:31] It just tosses lines at the bottum of my code while icrimenting. [18:31] And do realise that it uses 2 shots per detection. [18:32] well, there are two possibilities: thick (6-12 lines) spl-carpet, some other carpet, or an incendiary bomb [18:32] Well it really only firest one shot per detect. [18:33] incendiary bomb: spl #0, 2 | mov.i -1, >-1. Or spl #0, 8 mov -1, <-1 [18:34] uhg, I alwayts forget... open to the right is decrement? [18:35] yes [18:35] greater than is increment [18:35] y [18:35] I don't fully soo what those do... [18:36] if an incendiary bomb hits an opponent, then the opponent itself will make an carpet of spl's [18:36] but spl #0, 2 ; mov -1, <-1 makes sence. [18:36] Shilock: not long enough. [18:37] but you see, when opponent runs spl #0, it will start making new processes, and run the mov multiple times [18:37] hmm? wouldn't... oh duh... nevermind... I keep forgetting that decs are indirect. [18:39] you can also have the spl and mov apart from each other, but that doesnt mean it is always possible [18:40] RRight... I think I have some nice code now... [18:41] throwing just spl's isnt going to win the match.. [18:42] I throws a few... it'll incriment its ammo-count to the dats following its code eventually. [18:42] interesting idea [18:42] The first 8 things that set off the scanner will get an incidiary. [18:43] Well, 4 actually, they mirror immage. [18:43] ...and it won't fire at itself, so it could be more then that... [18:43] that is not much, but i guess its enough against Mice or Paperone [18:45] Well lets see how it doesn on beginner hill... [18:45] erm... Ok, time to dive through the compiled code... [18:46] i smell overengineering [18:47] ...nope... kinda typed the wrong thing once... [18:47] ...and then copied it to like 4 spots... [18:47] SNE, SLT, [18:48] you could just do a testrun on pmars or corewin to see what is wrong [18:49] I tried to get pmars to run... couldn't... where can I get corewin? [18:49] www.geocities.com/corewin2/ [18:49] are you using windows or unix? [18:50] windows [18:51] when you double-slicked the pmars.exe , it flashed a black screen and nothing happened? [18:51] pmars is an old program supposed to be run from command-line, not an point-n-click one [18:51] you have to start it from command-prompt [18:52] Corewin is a real treat to those that dont want to do things like in DOS [18:57] hmm, no responses? [19:03] I don't like the visualisation... [19:03] ...I don't think of the core as a box... [19:03] ...its a loop... a large massive circle. [19:03] Thats how I visualise it. [19:04] options -> circular [19:07] Well, I found another bug while doing that, so whoot. [19:08] Lol... I Ran a simulated 50 rounds of looker against one of my other cores.. [19:09] ...I get 80% winning, so I submit to the hill said warrior was on... [19:09] ...that was about the only winning run there... [19:09] most people have an benchmark of warriors to fight against when testing their code [19:09] lost to all 24 warriors not written by me... [19:10] however, putting first warriors against competitive benchmark is a crushing experience [19:11] answering will be a bit sporadic for a while, watching TV [19:49] back [19:54] Hmmm... odd [19:55] I sent you some code... its not working right and I can't see why. [19:55] ewww [19:55] The CoreWin display implies its skipping all except the third attack [19:56] So the SLTs are not resolving as they should... but the third one is... [19:57] you should use slt on the attacks [19:57] shouldnt [19:58] thats a horrible amount of overhead [19:58] Hmm... true, I could wire up something better... but for now, why is only the 3rd SLT ever evaluating as true. [19:58] take the * and @ off [19:58] Why? [19:59] because then they are reading the instruction where you are throwing the bomb [19:59] ... that would explain that... [19:59] while you need to read only the value [20:00] So what doI need then... SLT.B for the second two? [20:01] y [20:01] I need to check if the B-field of AIM is less then 50 [20:02] y [20:02] So avoid nuking myself... [20:02] To* [20:03] but you should make the check before bombing, not during bombing, as i say again [20:03] Ok, I'll do that, but how do i write the line? [20:04] well, if youd give me the code of the whole scanner part [20:04] ... aim holds two points... roughly half the core away from each other. [20:05] SLT aim, #50 makes sure the first value isn't self-destructive. [20:05] ...its what, SLT.B aim, #50 or SLT.AB aim, #50 to compair the B-field of aim with #50 [20:05] well, it becomes harder when the scan-positions are far away from each other [20:06] unless you use HSA-scan [20:06] which means? [20:07] add.f inc, ptr [20:07] jmn.f 3, @ptr [20:07] jmz.f -2, *ptr [20:07] mov.x ptr, ptr [20:08] however if is a tricky scan [20:09] because it needs some space-usage optimization, and no-one so far has been able to improve HSA from its original form [20:09] (HSA = He Scans Alone) [20:11] How does that pertain to my predicriment? [20:11] because when a process is below that mov.x , the b-field of ptr contains the location of the opponent [20:12] no needs to fuss with two fields [20:12] you could try slt.f something, aim [20:14] but is there a way to see if aim's B is less then #50? [20:14] SLT.ab? [20:14] slt.ab #50, aim [20:14] That would skil is aim's b is lower then 50? [20:14] skip* [20:14] actually, i dont know [20:15] i didnt think that much when giving the line [20:15] yes, it will do that [20:15] MSG: Ping timeout: 255 seconds [20:15] Uhg, I have to go to work... I'll get this baby working later tonight. [20:35] MSG: Ping timeout: 255 seconds [20:35] Join: pkhuong- joined #corewars [20:36] MSG: Client Quit [20:38] MSG: Ping timeout: 255 seconds