[04:41] Join: DRATSAD joined #corewars [06:15] * Metcalf is going to Newark County Show this morning [07:51] MSG: Quit: OO< [08:01] MSG: Quit: Leaving [14:58] i need one (1) bvowk right now [15:21] MSG: Ping timeout: 245 seconds [15:21] Join: Metcalf joined #corewars [15:25] Join: OoS joined #corewars [15:27] MSG: Ping timeout: 245 seconds [15:44] MSG: Ping timeout: 245 seconds [15:45] Join: OoS joined #corewars [15:55] MSG: Ping timeout: 245 seconds [16:47] Join: OoS joined #corewars [16:51] MSG: Ping timeout: 245 seconds [16:57] Join: OoS joined #corewars [17:27] MSG: Ping timeout: 245 seconds [17:27] Join: OoS joined #corewars [17:34] MSG: Ping timeout: 245 seconds [17:35] Join: OoS joined #corewars [17:44] Join: Lazareth joined #corewars [17:48] MSG: Ping timeout: 245 seconds [17:49] Join: OoS joined #corewars [17:49] hi Lazareth [17:50] Hiya [17:51] Hi [17:51] I'm new to corewars, just found the channel =P [17:52] I'm still trying to succesfully wrap my head around how a program evolves sequentially. [17:53] (I know how, but getting used to it to a point where I can make code without constantly rechecking what effect it will have is not yet achieved) [17:54] thatll take just time and practise [17:56] *nod* meanwhile I'm getting up to speed with the basics. No point in reinventing the wheel before making the car. [17:57] I reckon the community is small? Given how hard this irc channel was to find and the number of people in here [17:58] weve been in a decline for quite some time, most of the former coders didnt have anymore time after leaving whatever school they were attending [17:59] and new members dont come at same pace (considering ordinary computer-gamer nowadays, not a surprise) [18:00] hah, coincidence. I'm wasting time before my exams. And well, gamers nowadays want "wow" and graphics. Thus far my view of corewar is that of "continually evolving chess". [18:01] you invent the pieces to beat the pieces =P [18:06] That's an neat description of Corewar :-) [18:07] The IRC channel should be a bit easier to find [18:07] It's linked from the front page of Koth and Pizza [18:08] Well, I did find it, didn't I; and now I'm officially braindead after trying to digest the basic 3-pt imp-ring and how it functions... [18:08] doesnt your page and .info have one too? [18:09] I don't think I'm linking from the front page, just from the discussion page [18:10] Lazareth: you might want to postpone imp-rings for a while, because while the idea is simple, it has enough strange concepts to put one in a state of.. i guess you know already [18:10] *nod* [18:11] Anyway, I'm kinda left with the feeling that it is easy (*cough*, relatively) to make a program tuned to kill another program of a certain "type", but it is close to impossible to make one that fare well against a broader "audience"? [18:11] true [18:13] wouldn't it become meaningless to then, say, battle it out against another person, each with a single warrior, without anything been known beforehand? Doesn't it come down to who picked what type? (in the rock-paper-scissor analogue, doesn't it mean that this is exactly what you're doing?) [18:14] That's why I don't like single elimination tournaments [18:14] However, we normally play round-robin with each warrior fighting 20 others and taking an average score [18:15] okay... that kinda rules out doing this for a closed-circle hobby [18:15] woah, that would require, well, a lot of warriors xD [18:16] we use 'hill's, were people send warriors, and where they fight against eachother, survivors staying on the hill and losers being pushed off [18:16] which is why there can be a month without any activity and a day with a dozen submissions [18:17] warriors performance is rated with a) how well it does against the other warriors currently on the hill and b) how long as it been on hill [18:17] My current level is this: the most complicated thing I've thus far made is a program I call "Format C" [18:17] DAT #0, #CORESIZE [18:17] start MOV -1, <-1 [18:17] SNE @-2, #6 [18:17] ADD #-6, -3 [18:17] JMP -3 [18:17] END start [18:17] basically overwriting everything backwards with DAT, jumping over itself and repeating it over >.> compared to what I've read thus far, this is kinda useless ^^; [18:17] argh, it got split [18:18] OoS: do you remember how long Porch Swing was on Pizza? I have the memory of it having over 200 points, but falling after just one week? [18:20] what is a "hyper-perfect gate"? [18:20] Lazareth: well, theres a couple things that could be improved in it, even without throwing it straight away to trashcan.. [18:21] Lazareth: ... you are reading source of Aeka? [18:21] perfect gate is something that manipulates a single instruction each cycle run [18:22] for example, mov bomb, gate | jmp -1 makes one manipulation every two cycles, not one per one [18:22] Not reading source of Aeka no, (I kinda get confused reading src with little beginner-oriented explaination) [18:22] but for a perfect gate, wouldn't the program have to be designed to ONLY be a gate? [18:23] doesnt have to be [18:24] but how do you gain the extra tempo then? You only get one move per cycle and if you got multiply processes they alternate between who is in a cycle. Or have I misunderstood how the queue works? [18:24] example of a 'hyper-perfect gate' would be the d-clear which has a perfect gate, while still wiping the core at same time [18:24] o.o how does it get to execute more than one instruction at a time? [18:26] you cant [18:27] but think of the following warrior [18:27] mov bomb, ...oh. So you exploit that you can predecremate [18:28] wait [18:28] what do you use the "|" for? [18:28] pre-decrement and post-increment can be used to change instruction, which are enough to damage an imp [18:29] because i am too lazy to press enter and divide small warriors on multiple lines [18:29] *nod* fair [18:30] I see the idea... I'll just have to get used to it. Doesn't exactly provide view-friendly code when you make one instruction do two different "jobs" =P [18:32] what exactly does a "scanner" do - or in case of laziness, is the a link to a basic example? [18:33] now, the 'hyper-perfect' is just a hyperbole, since its kinda hard for gate to be better than 'perfect'. I asked about Aeka's source because its only place i remember that wording used [18:33] at start of a round, everything not a warrior is a dat $0, $0 [18:34] thus we can deduct that everything not a dat $0, $0 is probably an opponent, and worth attacking [18:34] Mizcu: are you sure that was Porch Swing? [18:34] OoS: couldve been just ordinary Swing too [18:34] so you cmp`(seq)? But wouldn't that take the same time, if not longer, than just dropping a bomb? And what if you simply "spot" yourself? [18:36] Lazareth: the two "classic" scanning engines are comparing (cmp or seq or sne, 'f-scanning') and searching for non-zeroes (eg using jmz, 'b-scanning') [18:36] let us assume the following comparement [18:36] to throw a bomb, you need a mov, add, and jmp. Thats one bomb per three instruction. [18:37] add/jmz makes one check per two instructions [18:37] add/seq/jmp makes two checks per three instructions [18:37] so you work 3/2 faster than the opponent and switch to bombing when you get there? [18:38] with that oversimplified comparison, scanning is atleast as efficient as bombing [18:38] problem with scanners is that they easily become very big, and there is the problem of decoys [18:38] MSG: Ping timeout: 245 seconds [18:39] Join: DRATSAD joined #corewars [18:40] can't you make the bombing a one bomb per two instruction by adding a decrement or increment to the bombing routine and use the b-field of the "original" DAT? Of course you will eventually kill yourself with no safety measure, but still [18:40] thats why the comparison is skewed for the scanner, and i said 'oversimplified' [18:40] okie [18:41] Well, it does get my mind working, which is the point :) thanks [18:41] Since I'm a beginner, oversimplified is "complex" to me =P [18:42] Join: OoS joined #corewars [18:43] you also had the question of "what if you spot yourself?" [18:43] that is the curse of scanners, and has a number of different ways to deal with [18:45] number of scanners use a a simple check to see where the spotting has been done, and ignore if its not in proper range [18:45] The only one I can think of right now is the same I used for the bombing routine of the Format C warrior, where it "jumps over" the point where it is located itself. [18:46] Yay, I won a ladder on Ebay! [18:46] o.o [18:46] Now reach higher! [18:46] while some do it intentionally, using it as a check to see that there has been ehough scans, and to switch into an end-game tactic [18:46] Lazareth: or lower! (it's a caving ladder) [18:47] Lazareth: you are quite close with the 'jump over' term, but lets ignore the details for now [18:48] okay, I'll read around, do some exam work in a while and then "experiment" if I got leftover time. Of course, all while lurking =P [18:50] Lazareth: in your format-program, that sne-check is not necessary, you can check for self-hitting without it, though it might mean moving the add-part out of the main loop. [18:50] I [18:51] I'll try to figure out how to do that when I got time then. Good training. [18:55] ...I can't help but thinking about the gate thing. What if the imp moves backwards? It would make the imp slower because it wouldn't be a "pure" MOV routine, but wouldn't it stomp gates? [18:56] imps dont move backwards by nature, so its not a concern [18:57] fair [18:58] backwards moving imp requires support-instructions, and even then it would be either so slow that its not a concern, or the support-instructions make it a non-imp [18:58] MSG: Ping timeout: 245 seconds [18:59] Join: OoS joined #corewars [19:02] I see that, it would be like swimming against the current. The thought popped because of the "one-wayness" of the gate. [19:03] MSG: Ping timeout: 245 seconds [19:46] is there a way to alter the +- of a number? I'm trying to have a B-field being decrement, but for another operand I want the absolute number of that B-field. [19:47] please rephrase [19:49] I'm using the B-field of an OpCode to determine how far to move another instruction forward, but at the same time I'm using an OpCode to decrement that field. The idea I'm currently working on "bombs" forward with "MOV 0, 1" to turn opponents into imps, and at the same time creating a perfect gate behind the program. In other words I'm trying to couple a perfect gate with a perfect bombing. [19:51] and the problem is? [19:55] The b-field I'm using is where the gate will be, but that one needs to be decremented for it to work (making the MOV 0, 1 -> MOV 0, 0) but at the same time, for lack of b-fields, I'm wanting to use it for moving the "MOV"-bombing routine forward. The problem here is, that they're literally running in different directions. [19:55] I was thinking if there where a way for the "MOV"-routing indirectly pointing to the b-field to inverse the number [19:55] without losing tempo [19:55] what happens to an imp when its b-field is incremented by 1? [19:56] ...oh, then I'll just make the gap one wider so it won't die while overwriting my program [19:57] you dont need to decrement and increment to have an effective gate, two of either will work [19:57] Some solutions seems easy when pointed out >.> yeah the imp will copy one too long forward, and thus proceed into an empty field [19:57] however, this will create a case where only every second instruction is overwritten with an imp [19:58] this is not really a problem, but there are some circumstances where it it can be an issue (eg. when not overwriting with an imp) [19:58] it currently looks like this: MOV 2, @-3 | start JMP -1, >-4 | MOV 0, 1 [19:59] good enough [19:59] I'll try and run it against Format C, to see (no pun intended) how it works out. [20:00] i expect you to have defined a number in the @-3 -instruction [20:00] otherwise youll get a really short run [20:01] ...whoops, forgot to add a routine for it to jump over itself. I impified myself [20:01] Uh, not really. I'm assuming a DAT #0, #0. That's why I'm starting at JMP -1, >-4 [20:01] so it turns into a DAT #0, #1 before I use the b-field [20:02] (such imp/gate -warriors dont work very well on ordinary settings, there are multiple issues. However they do work in low-maxprocess conditions) [20:02] it worked rather well, except that I was faster than the other process meaning I ran over and impified myself before the gate had any effect. [20:03] so the gate worked until just the moment where it was needed >.> [20:05] I'm just messing around with concepts to improve myself at this early stage, so for practise purposes my current problem is to add a way to jump over myself without losing tempo [20:05] if that is possibly at all [20:05] yes, by all means keep doing so [20:06] heck, just about every beginner thinks about such warriors early on [20:06] hah [20:07] Well, I thought the concept "cool" from a magic-the-gathering Black Deck perspective. The program is dubbed "Impify and Kill" for that reason. Idea is quite simply to turn the enemy into imps, that turn enemies into imps, etc etc etc until they all smash into my back entrance guarded by a gate to kill imps. [20:08] A simple stone program should probably work out better by just DATTING away [20:11] argh, why isn't there an opposite to DJN, increment and jump? [20:12] jmp -3, >somewhere [20:13] oh, I meant "increment and jump if result is zero" [20:13] DJN is decrement and jump if result is not zero [20:13] and I meant increment and jump if result is not zero in the previous line =P [20:14] i guess that would count as "unnecessary extras" as it can be broken down into add/jm* [20:15] I don't know, DJN is one instruction, the other would be two [20:15] and right now I'm trying to stay within the boundaries of a perfect gate while maintaining a perfect carpet routine. Kinda harsh requirements, but fun to try, if possible. [20:16] right now I can't think of how to add a routine that makes sure I don't carpet myself without either making the carpet routine half-speed or the gate half-speed [20:16] that would require some thinking outside the box, and code that works only in '94 [20:17] Right now I'm working with everything except P-space [20:19] how long have you worked with redcode, few days? only today? [20:19] Only today [20:19] well, installed it yesterday but never got around to do anything with it [20:21] i need to wrap my head around this for a while [20:21] hm? rephrase [20:22] i am thinking if its even possible to wipe with imps, while preventing a self-hit, and holding a perfect gate [20:23] i have done the first two, but third is a challenge [20:24] the third is what I'm working on [20:25] but I wouldn't complain if you found a solution =P I'm intrigued myself [20:26] well, the fact that i cant give a solution right-away doubles or triples the intrigue value of a success [20:26] I'm imagine trying to construct something where it only just lags when it about to hit itself, changing routine just for a long enough time to readjust the b-field to jump over the program and then switch back into perfect gate/imp wipe mode [20:27] *it is [20:28] something with the "skip" OpCode or similiar... but I can't make it fit without losing time hopping an instruction [20:28] *OpCodes [20:29] first problem is that should the wiping stop when an imp hits the gate, or is a 95% compulsory [20:30] 95% compulsory? [20:31] and imp can infect an opponent, and run to gate before the wiping is complete [20:31] yeah [20:32] so one could open up a margin of error by stopping the wiping before the whole core is filled [20:33] the big challenge is that the effectivity of an imp depends on your opponent [20:33] I just can't see how to fit in a routine to either check how long the wiping has progressed or simply check if something has appeared outside the gate [20:33] a modern paper wont even notice a couple imp-infections, while a scanner will be FUBARed by a single hit [20:34] Well, the process itself isn't "riding" the imp wiping, so an enemy gate would be useless [20:34] of course a replicator would fuck things up... [20:34] you can use a djn as a simple counter [20:34] djn.b loop, #7800 [20:34] how do I fit it in without leaving the gate instruction or the wipe instruction for a second? [20:35] ...okay, that had some aspects I haven't seen before. ".b" and "loop"? [20:36] loop is name i just pulled off as an example [20:36] oh, a "label"? [20:36] yes [20:36] .b is a modifier, something that was added in '94 standard [20:37] the problem I'm having is not making the counter, but having it run without taking up space in the queue [20:37] i had a solution thatwouldve used the counter as a gate, but it had the problem of stopping at the first imp hitting the gate [20:37] ...yeah I'm looking at the instruction modifiers now. Didn't notice they existed. That opens up some possibilities I haven't thought of. [20:38] in '88, the behaviour of an instruction depended partially on what the source and target instructions were [20:38] ok [20:39] that was understandably a big problem, and some things that seemed obvious became hard, illogical or impossible [20:39] ok [20:39] eg. exchanging a and b-fields of an instruction [20:39] I'll just make some modifications, found something in my "code" that could be optimized by using a postincrement in another field... [20:40] I was using the JMP routine to change how much to move the MOV by, while I could just use the MOV that moved the MOV itself to both move it and alter the number for the next reiteration. [20:41] djn.b in this case would mean "decrease the number in b-field, and jump if non-zero", the behaviour that it had in '88 [20:42] ok [20:42] right now I'm using that field to find out how much to move the MOV by... Of course I could always just make it wipe backwards [20:43] because of compatibility reasons, the pre-compiler gives "best guesses" (88 -compatible) if modifiers or addressing modes are missing [20:44] when I MOV 3, <-3, am I using the address to move relative to the address 3 down from MOV, or am I moving 3 down from the address at -3? [20:44] (or just doesnt bother if '88 -only mode is set) [20:44] that would depend on the value of b-field in -3 [20:44] if that made sense [20:45] if the value is, say, 0 (so it would be -1 because of the predecrement) would I move the instruction at address 3 relative to MOV to the address -1 relative to where the b-field is, where the MOV is or where the instruction being moved is? [20:46] relative to the mov, not the address moved [20:46] or, the value in b-field, to be exact [20:46] so MOV 3, <-3 would become MOV 3, -1 and move the instruction up before it? [20:47] it would become MOV 3, <(-3)-1 [20:47] ...now I'm confused [20:47] oh yeah [20:47] and its ten to midnight here, lemme rephrase [20:48] which, if the address is 0, would be MOV 3, -1 [20:48] the b-field at the address [20:48] -3, of course... [20:48] mov 3, <-3 looks at -3 for the place where to move the +3 [20:49] -3 contains a 0, which is by the predecrement turned into a -1 [20:49] and then moves it relative to itself, right= [20:49] *? [20:49] and so the final moving is done to the value at which (-3) points to [20:50] huh? [20:50] I didn't get that quite clearly [20:51] visual aid would make this so much easier.. [20:51] indeed. Anyway, I'm testing how it is set up now in debug mode, that should explain it to me [20:51] simplification: [20:51] sub #1, place [20:51] mov 3, @place [20:52] It works as intended now, no need for further explaination :) [20:52] you must be studying at a uni? [20:52] I just made it wipe backwards. Anything hit by the "imp-ray" will then start moving in the opposite direction if successfully imped [20:52] No, not really [20:53] Not yet [20:53] I'm having my exams now, graduating from what we call a "gymnasium" from where I'm from. Afterwards I'll apply to study math at a local university. [20:53] you are learning about twice as fast as the previous guy i was teaching [20:54] I consider this great fun. Thus far most of what I've done ends up running backwards, don't ask =P [20:55] And my most complicated thing I have (that imp/gate thing I'm working on) is currently... 5 lines long [20:56] right now I'm working a start-delay into it that will (hopefully) end up making it faster at the end. Sacrificing a "first round" for a smoother overall play [20:57] well, the hardest thing in redcode to understand are the addressing modes, and the concept of a pointer (which is common to all programming) [20:57] pointer? [20:57] http://en.wikipedia.org/wiki/Pointer_(programming) [20:57] yay, wiki wiki [20:58] oh [20:58] yeah [20:58] and with the added flavor of the pointer being relative to whatever askes for it [20:58] in redcode [21:01] DJN.b 4 will check if address 4 relative to itself is zero after decrementing it, and if it is not zero it will jump, correct? [21:01] to the b-field that I haven't included here [21:02] a-field containt the place to jump, b-field the place or thing to decrement [21:03] thanks [21:03] fatal error otherwise xD [21:05] ...and I just realized that instead of making boot instructions that sets values that I want to use for counting I could just make those addresses part of the program with preset values... shees. [21:08] MOVE IMP, yes [21:09] wonderful. I began to tire of altering numbers as I added and removed instructions >.> [21:13] ...And it officially became rubbish. I think I'll cool my brain and start from stretch. [21:14] is there a forum besides the IRC channel here? [21:15] someone created a forum that no-one ever used [21:15] you can use the newsgroup as one http://groups.google.com/group/rec.games.corewar/topics?lnk=gschg [21:15] okay... so how do the community communicate? Or is it just a slow day? I don't assume, despite decline, that we've down to around 9. [21:16] and everything on this channel is logged, so you can just drop a question and check the logs [21:16] how do I access the logs? [21:16] there hasnt been any community-wide communications recently, but if one needs to catch as many coders as possible, that would be the newsgroups [21:16] www.koth.org/irc-logs/ [21:17] I'll bookmark that then [21:22] Part: Lazareth left #corewars [21:23] Join: Lazareth joined #corewars [21:39] Part: Lazareth left #corewars [22:24] MSG: Read error: Connection reset by peer [22:38] Join: DRATSAD joined #corewars [22:40] Join: Lazareth joined #corewars [23:05] MSG: Quit: Leaving. [23:08] now i got stuck reading old logs.. and i refound a paper i had under works, and it still scores.. interesting. Bad, but had interesting properties. [23:25] --> zz