IRC logs for #opendune on OFTC at 2009-09-14
⏴ go to previous day
06:13:48 *** TrueBrain_ has joined #openDune
07:25:22 *** Xaroth sets mode: +o TrueBrain_
08:05:25 <TrueBrain_> nsz: uploaded the file in the package :)
08:09:53 <nsz> stat about my txt functions
08:10:19 <TrueBrain_> 148 times the same function ;)
08:10:39 *** TrueBrain_ is now known as TrueBrain
08:10:49 <TrueBrain> I just wanted to run some kind of script which tells me if anything is missing
08:11:04 <TrueBrain> like when you have 0000 of length 000C, you know that the next should be 000C
08:11:23 <TrueBrain> there can be something on 0003, no problem, but at least something has to start at 000C :p
08:13:35 <TrueBrain> only .. how to do the math in bash ..
08:13:42 <TrueBrain> 'bc' doesn't know non-interactive? :s
08:27:31 <TrueBrain> missing quiet a bit
08:28:47 <TrueBrain> there are 9262 files
08:29:28 <TrueBrain> it misses about 1006 files
08:29:34 <TrueBrain> so .... really close :p
08:30:35 <TrueBrain> then it most likely misses tons of jumps, as he hasn't seen them, but most of them we can fix by just assigning them, as we know Dune2 doesn't do any weird tricks
08:30:43 <TrueBrain> so, about 10000 files ... 10000 small functions
08:31:04 <TrueBrain> managable, one would almost think :p
08:36:17 <TrueBrain> hmm , I think I made a few mistakes yesterday in my overlay work, so I guess I will need to start over a bit ...
08:36:31 <TrueBrain> it is hard to be sure you did everything, and didn't skip a function or what ever :p
08:37:19 <TrueBrain> as all I know now is that I removed a function, because it was unused, but that is silly, as it might become used later on :p
08:39:36 <TrueBrain> nsz: the only fuzzies where the ones as I pointed out? There were no others?
08:39:42 <TrueBrain> (I know I should record them in the txt too :p)
08:40:17 <nsz> there were quite a few fuzziness but every other address ended in 0002
08:41:35 <TrueBrain> hmm, compiling goes wrong ... that is bad ...
08:44:33 <TrueBrain> problem with dynamic cases is that it can be 99 times of the time to one thing, and one time to another .. like losing a battle. Or the last level.
08:45:56 <TrueBrain> I really really need to add sorting somehow :)
08:46:14 <TrueBrain> yes ... the resuling files are not really sorted :p
08:46:29 <TrueBrain> case 2: f__F438_04AC_0033_B40C(); return;
08:46:31 <TrueBrain> case 0: f__F438_0000_0019_C6A1(); return;
08:46:32 <TrueBrain> case 1: f__F438_0476_0030_36E0(); return;
08:46:34 <TrueBrain> case 3: f__F438_06F6_0012_D7A8(); return;
08:50:18 <TrueBrain> yippie, that seems to work for overlays
08:50:22 <TrueBrain> now the bigger structures ...
08:51:12 <TrueBrain> that is hard ... I 'hash' entries based on their ip, by doing ip % 1024
08:52:57 <TrueBrain> any suggestions to get a sorted list out of that anyway?
09:04:10 <TrueBrain> (I am already late :s)
10:11:53 *** ChanServ sets mode: +v Yexo
10:38:47 <TrueBrain> so ... where was I ...
10:44:02 <TrueBrain> okay, it turns out two overlays are 'confused'
10:44:18 <TrueBrain> they are equal, but for some reason have another crc .. most likely because it is a very small one ..
10:45:48 <TrueBrain> I know a better way to detect overlays for Dune2, but it means we need to do all the txt over :(
10:57:44 <TrueBrain> oh well :) They do work much better :)
10:59:23 <TrueBrain> as that solves a bunch of other detection problems too
10:59:30 <nsz> what else can go into the txt?
10:59:49 <nsz> you said thee is a better way
10:59:59 <nsz> i thought you put there extra meta data
11:00:08 <TrueBrain> I did base the overlay on the CRC of the first 0x80 bytes
11:00:13 <TrueBrain> this is not optimal
11:00:27 <TrueBrain> it turns out, the address of the overlay table is at byte -2 from the overlay
11:00:37 <TrueBrain> so I now used that value (orred with 0x8000)
11:00:58 <TrueBrain> which solved the problems of overlays which are smaller than 0x80 bytes :)
11:01:31 <TrueBrain> but as a downside, all txt you created are no longer valid :(
11:01:51 <nsz> no problem i only played one level :)
11:02:06 <nsz> it was a lng time since i played with dune
11:03:56 <TrueBrain> some games never get old ;)
11:05:11 <nsz> i guess the txt generation won't be a problem if the fans can get their hands on the tool..
11:05:12 <TrueBrain> okay, now I only have to solve the sorting inside a file ...
11:05:38 <nsz> i have tons of sorting algos laying around :)
11:05:55 <nsz> i guess that's not the problem though..
11:06:05 <TrueBrain> well, the tool only works on linux, which makes it a bit tricky ;)
11:06:18 <TrueBrain> no; as I said, the entries are ordered via a hash, based on ip % 1024
11:06:36 <TrueBrain> so function 1024 and 2048 are next to eachother
11:06:56 <nsz> but if the orig value is avail then you can sort it
11:07:46 <TrueBrain> means I need to create a seperate array or something
11:17:56 <TrueBrain> hmm .. not such an easy task :)
11:18:08 <TrueBrain> but okay ... my code is also a bit messy, with all those hashes and reverse lookups :)
11:18:35 <TrueBrain> I can also just increase the hash-size to 65536 :p
11:18:55 <TrueBrain> @calc 65536 * 16 - 1024 * 16
11:19:02 <TrueBrain> an increase of 1MB in memory usage :p
11:19:48 <nsz> this only matters in the jit right?
11:20:34 <nsz> jit makes txt, static analyser makes decompile/*.c ?
11:21:30 <TrueBrain> okay, that seems to work just fine
11:23:17 <TrueBrain> now the Called From entries ...
11:24:15 <nsz> you know the esoteric language with 'comefrom' statement
11:25:53 <nsz> it was a joke language to push the harmfulness of goto a step further
11:28:14 <TrueBrain> damn, I really made a mess of my internal structures :)
11:28:20 <TrueBrain> for (j = 0; j < JUMP_LIST_HASH_SIZE; j++) {
11:28:21 <TrueBrain> JumpList *jl = &_jumpList[j];
11:28:23 <TrueBrain> for (i = 0; i < jl->count; i++) {
11:28:24 <TrueBrain> for (k = 0; k < overlayList->count; k++) {
11:28:26 <TrueBrain> this can never be anything good :)
11:33:15 <TrueBrain> when you start you are not sure yet what you need to harvest
11:33:18 <TrueBrain> now it is just plain messy :p
11:33:39 <TrueBrain> duplication of data ... wrong way of lookups ... shit like that :)
11:33:50 <TrueBrain> but okay, it is still VERY fast, so I guess I shouldn't care :)
11:38:19 <Xaroth> I take it class gave you even more ideas on things :P
11:38:36 <TrueBrain> the only thing my class gave me was the need for a bed
11:38:52 <Xaroth> aren't classes really good to .. 'sleep in' ?
11:39:03 <TrueBrain> it is a class in human behavoir
11:39:12 <TrueBrain> how to create good GUIs
11:39:47 <TrueBrain> well, I am very good in GUIs in general, and so most of that class is really boring to me
11:40:11 <nsz> good in gui? i thought noone is good in guis ;)
11:40:17 <TrueBrain> it is an interesting class if you never realised any of the shit :)
11:40:31 <TrueBrain> well, designing a website falls under it too :p
11:41:21 <nsz> i'm against web site design (webless etc)
11:41:47 <TrueBrain> a good designed website will be valued by everyone
11:42:00 <TrueBrain> but I dislike the trend to make everything a webapplication
11:42:14 <nsz> you cannot design documents to be universal with respect to display medium
11:42:29 <nsz> the only thing you can do is to provide some minimal meta info
11:42:45 <TrueBrain> well, if you take openttd.org, it works on all browsers, including text-browsers
11:42:47 <nsz> and let the client side figure out what's the best way to view it
11:42:54 <TrueBrain> so for its target, it works :)
11:43:29 <TrueBrain> but yes, there should be a clear seperation between data and layout
11:43:40 <TrueBrain> the reason I love LaTeX :)
11:44:09 <TrueBrain> Templates alone doesn't cut it
11:44:11 <nsz> latex is probably not the best example
11:44:30 <nsz> it's complex and puts the complexity right into your content
11:44:52 <TrueBrain> the only complex part is when the layout turns out to be something you don't like ;)
11:44:57 <nsz> its so complex you cannot write your own latex renderer
11:44:57 <TrueBrain> and adding images, that is tricky :)
11:45:39 <TrueBrain> Xaroth: good websites view perfect without any CSS. The text on the page follows a logic flow from the header to the bottom
11:45:47 <nsz> it is useful for typesetting, but not for text markup or text structuring
11:46:01 <TrueBrain> LaTeX is not meant for any layout design :) The reason I love it ;)
11:46:08 <TrueBrain> it is just there for what it is: writing text
11:46:31 <TrueBrain> (sgml in general, I guess)
11:47:00 <nsz> non of them is really suitable for digital documents though
11:47:05 <TrueBrain> bah ... 'B' comes above '0' (signed compare)
11:47:13 <nsz> they all assume to be printed eventually
11:47:22 <TrueBrain> DocBook has some nice HTML outputs
11:47:49 <TrueBrain> can qsort do unsigned sorting ... hmm ...
11:48:13 <nsz> when in doubt use bubble sort
11:48:16 <TrueBrain> but its callback is signed int 32
11:48:51 <nsz> qsort should be able to sort any data
11:49:04 <nsz> the callback should give you pointers
11:49:18 <TrueBrain> compar returns type 'int'
11:50:13 <TrueBrain> so I just did: (cs << 16) + ip from the one minus the same of the other
11:50:22 <TrueBrain> but that is a 32bit value .. and so the 'B' came above the '0' :)
11:50:31 <TrueBrain> if (ajf->cs != bjf->cs) return ajf->cs - bjf->cs;
11:50:32 <TrueBrain> return ajf->ip - bjf->ip;
11:50:34 <TrueBrain> solves it, but it is less nice :p
11:53:13 <TrueBrain> easiest method: return ((afj->cs << 16) + afj->ip) - ((bfj->cs << 16) + bfj->ip)
11:53:23 <TrueBrain> but that is a unsigned value, which you give back as signed
11:53:35 <TrueBrain> as result, B0000000 comes above 00000000
11:53:59 <TrueBrain> it doesn't matter to what you cast it, it will remain like that
11:54:09 <TrueBrain> as B0000000 is seen as -4000000 or what is it
11:54:46 <TrueBrain> (as the return value is signed)
11:55:16 <TrueBrain> you can solve it by put it in a temp var and return -1, 0 or 1, based on the unsigned value, but that is just not as pretty :)
11:55:46 <TrueBrain> but okay, it is not important, I was just annoyed by it :p
11:56:32 <nsz> (afj->cs - bfj->cs) * 65536
11:57:26 <TrueBrain> nsz: think about it: if I have the to pairs B0000000 and 00000000. When comparing them, the return value should be >= 1, right? (assuming B0000000 is a)
11:57:57 <TrueBrain> what ever you do, what ever you cast, what ever you try, if you do: a - b, the value is (in the signed world) <= -1
11:58:18 <TrueBrain> (hence the B000 0000
11:59:00 <TrueBrain> check the Called From in the second function
11:59:07 <TrueBrain> from a CPU point of view this is very logic
11:59:21 <TrueBrain> but ... can I correct it, and should I correct it, to 'simulate' it comes from the first function
11:59:24 <TrueBrain> should I care, is the question ;)
12:02:04 <nsz> what's the problem with the come from?
12:03:25 <TrueBrain> the f__261F_004A_000E_FCC6(); is inserted by the analyse
12:03:39 <TrueBrain> in reality of course the code from 01F7 gives a return which makes it go directly to the second function
12:04:41 <TrueBrain> I can make the JIT correct for this and make it act like it came from the first function I guess
12:05:06 <nsz> oh so to revert tail calls
12:06:12 <TrueBrain> so what you see now is what the reality is, but it might be confusing
12:06:46 <nsz> no, in reality there is no 261f at the end of the first func
12:07:15 <TrueBrain> but the static version of course needs it, else the 01F7 needs to jump to the second function, which will make it a cmplete mess
12:07:45 <nsz> i see, then call from should be modified accordingly imho
12:08:05 <TrueBrain> let me see if I can make the JIT do that correction ...
12:09:35 <TrueBrain> now the 'From' address is equal to the function itself, but that is because it did 'came' from there :p
12:10:36 <TrueBrain> only the length and CRC is still from the old function :p
12:11:31 <nsz> i thought the comefrom is the caller function name, not calculated from an address
12:11:52 <nsz> what does the length mean then?
12:12:01 <TrueBrain> it is the caller, yes, but not in function, in instruction
12:12:21 <TrueBrain> the length now is just a residu, not anything sane :)
12:18:58 <TrueBrain> k, corrected the length and crc
12:19:34 <TrueBrain> well, it is still a bit weird I guess .. the cs:ip is from the real place, where length:crc is from the last function
12:20:47 <nsz> will you be able to use this data?
12:21:10 <TrueBrain> that is wha tI wonder about ;)
12:24:05 <TrueBrain> truth is, I don't know what else to put in there
12:24:49 <TrueBrain> I now made the 4A in the ComesFrom appear as 49
12:24:54 <TrueBrain> suggesting it comes from the former
12:25:03 <TrueBrain> you have shown in your stats that len:crc is not unique :)
12:25:23 <nsz> well those can be the same functions
12:25:35 <nsz> i havent checked the function bytecodes
12:25:46 <TrueBrain> ah, well, I can only hope my CRC is strong enough :)
12:25:50 <TrueBrain> but I am sure it has duplicates
12:25:59 <TrueBrain> (it is an xor + rol)
12:26:34 <TrueBrain> * Called From: 01F7:003F:0059:CF03
12:26:36 <TrueBrain> * Called From: 01F7:003F:004A:77E8
12:26:50 <TrueBrain> ghehe :) This happens if 2 functions overlap partly, and return at the same point
12:26:56 <TrueBrain> I guess it is clear enough
12:29:46 <TrueBrain> okay, new version uploaded ... now I need to create txt files again, and then I can start on the overlay manager again :)
12:31:26 <TrueBrain> and I really need a merge tool for txt files :)
12:32:10 <TrueBrain> when you and I run it both, it can be that I have a few extra entries here, and you a few extra there
12:32:17 <TrueBrain> the From lines are the important ones in the txt files ;)
12:32:29 <TrueBrain> that is what establishes the relation between code :)
12:34:13 <nsz> i guess i should remove my old txt/
12:34:35 <TrueBrain> but, on the positive side, this should be the last of the txt changes :)
12:35:09 <Xaroth> I have no idea what you're up to, but it sounds funkay :P
12:35:26 <TrueBrain> is it so hard to follow? :)
12:36:37 <TrueBrain> hmm .. one downside of patching functions, is that they are no longer auto-generated :p
12:36:54 <TrueBrain> but .. in this case that results in a less-optimal situation
12:38:17 <Xaroth> probably not that hard to follow
12:38:21 <Xaroth> but.. i'm also working :P
12:38:37 <Xaroth> well yeah, deadlines etc
12:39:02 <Xaroth> done enough for today, need one of the devs to help me tomorrow morning
12:39:04 <Xaroth> that should be enough.
12:39:21 <Xaroth> the things you do for coffee.. and I don't even drink coffee.....
12:40:54 <TrueBrain> hmm ... in the decompiled code there are still 'jmpn' ... which should never be there .. and I don't get how they got there :p
12:43:39 <nsz> you havent put the options cfg in the hg
12:44:01 <TrueBrain> nsz: it is in the new data package
12:44:09 <TrueBrain> (there are no dune files at all in the hg, I hope)
12:44:37 <TrueBrain> ALL jmpn (memory-based) go wrong
12:44:41 <TrueBrain> consistant, yes, but .. wtf?
12:49:07 <TrueBrain> okay .. I think I made a mistake when increasing the hash size or what ever ..
12:56:02 <TrueBrain> it keeps suprising me that I can run with the JIT, but that without the JIT it immediatly fails :p
12:56:31 <nsz> soo can i run the code now or wait for some fix?
12:57:09 <TrueBrain> if you update to the latest version, you should be fine
12:57:15 <TrueBrain> but of course I can never be 100% sure :(
12:57:21 <TrueBrain> as I do tend to make bugs :p
13:05:09 <TrueBrain> hmm .. I made a simple thingy that should skip entries that are duplicated because of the overlay
13:05:16 <TrueBrain> but now all switches contain just 1 entry :)
13:05:34 <Xaroth> * TrueBrain is now known as TrueBrainMeltdown ?
13:06:00 <TrueBrain> if (j > -1 && jl->entries[j].csip_from.cs == jl->entries[i].csip_from.cs && jl->entries[j].csip_from.ip == jl->entries[i].csip_from.ip) continue;
13:06:02 <TrueBrain> if (cs != 0x0 || ip != 0x0) j = i;
13:06:06 <TrueBrain> but I also fail to see what I did wrong :s
13:07:04 <TrueBrain> wait ... from .. hmm .. yes
13:08:30 <TrueBrain> there, segfaults again :)
13:08:47 <TrueBrain> so .. should I fix those first, or should I work on the overlay manager ... I guess we want to see something, so let me fix those first :)
13:09:34 <nsz> every time i replay the intro there are new functions
13:09:43 <TrueBrain> yeah, you noticed that too? :)
13:09:51 <TrueBrain> there is one pitfall there, and it is related to overlays
13:10:00 <TrueBrain> if the new instructions are between 3400 and 3600, they are bogus
13:10:07 <TrueBrain> it is just the overlay loaded at another location
13:10:29 <TrueBrain> (resulting in a different CRC)
13:10:45 <TrueBrain> I guess I should reset the CRC to 0, to avoid that
13:10:46 <nsz> crc is different as well>
13:11:04 <TrueBrain> well, other overlay, so the EA CS CS IP IP <- the CS CS in the jump is different
13:11:07 <TrueBrain> and that of course gives another CRC
13:11:28 <TrueBrain> (as in the memory is the real overlay .. for the static version I only store the fake one)
13:12:14 <TrueBrain> so if you only receive those, you should be safe
13:19:28 <Xaroth> dumpert, by default, is not 100% work safe
13:21:52 <TrueBrain> easy solution: add usleep
13:21:55 <TrueBrain> hard solution: find out what it does
13:22:30 <Xaroth> i'd say use the easy sollution to see what nasty things hide behind
13:22:57 <Xaroth> if it's all related issues, find out wh(at|y)
13:25:22 <TrueBrain> okay, now I am at the beautiful overlay problem, so I will bite myself into that for now :)
13:28:30 <TrueBrain> I guess I should also look how to load a C struct over a piece of memory :)
13:28:34 <TrueBrain> to ease up that transition :)
13:28:57 <TrueBrain> nsz: is there a general way to ensure no random spacing is done in a struct? (so attribute((pack))
13:29:06 <TrueBrain> (that you know of :p)
13:30:14 <nsz> no general solution in the standard
13:30:32 <nsz> you should use serialization if you want portable code
13:31:00 <nsz> for each struct a pack() and unpack()
13:31:32 <nsz> might need more memory, and might be slower then casting a struct pointer
13:31:35 <TrueBrain> well, what I plan to do is to make a struct which you attach to the memory
13:31:48 <TrueBrain> oh, you mean before and after using
13:31:53 <TrueBrain> I think that would be unmanagable
13:34:27 <TrueBrain> with C++ one could have used ctor and dtor to fix a few things :p
13:35:03 <nsz> i doubt the c++ standard sais anything about alignment
13:35:24 <TrueBrain> I said you could use the ctor and dtor to make that process of serialization easier
13:42:14 <TrueBrain> oh well :) Things for the future ;)
13:42:36 <TrueBrain> it is always to think about the stack in reverse
13:43:49 <TrueBrain> what I gather from this function is that it reserve 6 bytes on the stack, but it seems to only use 2 ...
14:16:05 <TrueBrain> hmm .. it seems I did something wrong, as it no longer works as it should :p
14:19:23 <Xaroth> it's working as intended!
14:19:26 <Xaroth> only the intensions were wrong
14:20:31 <TrueBrain> stupid auto-sign-extend :p
14:21:57 <TrueBrain> I do have that ingame sometimes, but that seemed related to mouse-movement
14:22:37 <nsz> i clicked randomly and moved the window
14:29:07 <Xaroth> OoooOOOoo nsz is using irssi
14:33:52 <Xaroth> can't wait for weekend :(
14:43:42 <TrueBrain> some things really don't make sense to me :s
14:49:48 <TrueBrain> /* Swap the bp value of the OverlayManagerInterruptCall with the flags of the interrupt caller */
14:49:50 <TrueBrain> emu_xchgw(&emu_get_memory16(emu_ss, emu_bp, -0x6), &emu_get_memory16(emu_ss, emu_bp, 0x0));
14:49:54 <TrueBrain> I checked it 3 times, it really does that :p
14:56:50 <TrueBrain> hmm .. some code really looks like ways to attach a debugger to the process and get some more stats from it :)
15:01:56 <nsz> hey, after the end of the first level, this guy asks me stupid questions
15:02:06 <TrueBrain> yup :) Told you, it is an uncracked version :)
15:02:11 <TrueBrain> I think I will keep it that way ;)
15:02:46 <nsz> ok then i have a new set of txts ;)
15:03:12 <TrueBrain> I first finish my overlay manager rewrite, then I will write a merge tool ;)
15:03:43 <TrueBrain> or you feel like writing that? Can be bash, perl, python, ... I don't care :p
15:04:03 <TrueBrain> awk .. that would make igor2 happy :p
15:04:23 <nsz> only the from part should be interesting?
15:04:32 <TrueBrain> the rest should be equal
15:04:47 <TrueBrain> it should just merge the From fields for all given cs:ip:len:crc pairs
15:04:55 <TrueBrain> maybe first show what it will merge, then an option to really do the merge :)
15:05:08 <TrueBrain> (now diffing is not important, but later on it might be useful)
15:16:35 <TrueBrain> the most fun job: guessing what bits mean ;)
15:18:20 <nsz> what should i do with overlay.txt?
15:19:15 <TrueBrain> it is a marker that the cs it is in, is in fact an overlay handler
15:22:33 <Xaroth> oooOooo more comments :o
15:26:45 <TrueBrain> lol, in my code I now need MUCH more comments than normal, because the code itself is not so self-explaining :p
15:28:48 <Xaroth> I thought I was going mad after reading some of those files -_-
15:29:39 <Xaroth> but yeh, ASM.. NOT my thing.
15:29:46 <TrueBrain> :) Neither it is mine
15:30:14 <TrueBrain> so I guess you need to find something else to m ake yourself useful :p
15:45:27 <Xaroth> i'll learn C sooner or later, don't worry
15:45:31 <Xaroth> hopefully sooner than later
15:52:50 <TrueBrain> bah, what to eat today ....
15:56:15 <TrueBrain> I still haven't found what pushed the 0x0 on the stack
16:48:29 <nsz> ok i've written the merge script
16:48:42 <nsz> bit dirty but should work
17:08:45 <TrueBrain> I unconvered a great portion of the overlay manager, but I am clueless why it makes those weird calls from time to time :'(
17:09:24 <Xaroth> if (rand()) call rand();
17:10:16 <nsz> that would be deterministic ;)
17:10:40 <nsz> at least on most libc implementations
17:10:53 <TrueBrain> first I thought it had to do when an overlay calls outside itself, so it is correctly loaded on return
17:11:04 <TrueBrain> rand() is 100% deterministic for this 16bit application :)
17:11:12 <TrueBrain> there is no /dev/random or /dev/urandom ;)
17:11:32 <TrueBrain> I believe it does a bit of randomizer by timing the first mouse input or something of the likes
17:12:29 <TrueBrain> the least they could have done was putting a bit of comments in the code! :p
17:15:46 <TrueBrain> nsz: I found two entries that give the same CRC :P
17:17:14 <TrueBrain> well, it was to answer your earlier question ;)
17:30:47 <nsz> hm this merge script is pretty slow here
17:39:40 <TrueBrain> but given it are text files, I didn't expect anything else
17:41:38 <Xaroth> I could whip up a C# thingie to merge if need be?
17:41:44 <Xaroth> means it can abuse my pc to merge
17:42:00 <TrueBrain> hmm . it segfaults over the merged txt files ...
17:42:35 <Xaroth> TrueBrain: no, but the rawr.xaroth.nl server -can- .. if i install mono on it ;)
17:43:05 <TrueBrain> Xaroth: that only becomes useful if we keep the txt collection we use there, that we can upload it and see what changed
17:43:11 <TrueBrain> but then I would suggest to use PHP, Python or Ruby
17:43:25 <TrueBrain> Xaroth: sorry, I know you are a C# fan, but it is not the tool for the job :)
17:43:35 <Xaroth> Just trying to be helpful
17:44:21 <TrueBrain> something is fishy ... hmm ..
17:44:40 <TrueBrain> it can only handle 255 entries ... who expected it needed more :s
17:45:42 <TrueBrain> wow, the static analyses is getting slow :p
17:48:39 <TrueBrain> txt/01F7/f__01F7_02C9_0001_0196.txt:From: 217E,0551,0017,FBD1
17:48:40 <TrueBrain> txt/01F7/f__01F7_02C9_0001_0196.txt:From: 217E,0551,0020,0368
17:48:46 <TrueBrain> same function, different length ..
17:49:53 <TrueBrain> nsz: tool runs nicely :)
17:50:19 <TrueBrain> nsz: just you increase my compile-times with a lot :p Tnx for that ;)
17:52:19 <nsz> i will upload a better version
17:52:22 <TrueBrain> I really should fix the CRC checksum for overlays .. this is annoying :p
17:52:42 <TrueBrain> it starts to add duplicated entries :(
17:57:26 <TrueBrain> fucking netbeans is crashing on the decompiled files :p
17:57:29 <TrueBrain> it is too much for him to handle :p
17:59:30 <TrueBrain> 1GB memory, 1 full core ...
17:59:34 <TrueBrain> woepliedoe! I LOVE JAVA!
18:11:36 <TrueBrain> 31seconds to compile dune2 :p
18:12:24 <TrueBrain> nice work nsz, it is a nice collection :)
18:16:42 <TrueBrain> on estimate, I miss about 1000 more functions :)
18:16:50 <TrueBrain> which is a nice number :)
18:20:07 <nsz> i tweaked the merge script it's a bit faster now, but still slow here..
18:20:25 <nsz> will upload it when the benchmark is finished
18:20:36 <TrueBrain> given it needs to analyze 10k of files, I am not suprised :)
18:20:51 <TrueBrain> via C it is only fast because all files are in the cache :)
18:21:28 <TrueBrain> funny side-note: it is faster to remove 10k files than to rewrite their content :p
18:21:38 <TrueBrain> I noticed that a few days ago :) Made my analyser MUCH faster :p
18:24:54 <nsz> ok updated the script and txt.tar.gz
18:25:28 <nsz> now it accepts 3 parameters
18:25:50 <nsz> hm maybe i should check that
18:39:20 <TrueBrain> argh, assembly can be so bitchy if you don't understnad the intensions of the writer :)
18:40:02 <TrueBrain> I have a function here, that either returns the total size of the overlay region, or the size between the first loaded entry and the end of the used region
18:41:05 <TrueBrain> emu_ax.x = emu_get_memory16(emu_es, 0x00, 0x10); // Current position overlay is loaded at
18:41:07 <TrueBrain> emu_subw(&emu_ax.x, emu_get_memory16(emu_ds, 0x00, 0x120)); // End of used overlay region
18:41:08 <TrueBrain> if (!emu_flags.cf) {
18:41:12 <TrueBrain> I have a hard time guessing what the if does in such cases :p
18:42:08 <TrueBrain> of course (default x86 assembly)
18:42:19 <TrueBrain> cmp is like sub, but without really doing the abstract
18:42:26 <TrueBrain> and cf is lower, so greater of equal
18:42:39 <TrueBrain> so if (ax >= memoryblabla)
18:42:51 <TrueBrain> so ... with the substract in mind, I guess: if (ax >= 0)
18:44:35 <TrueBrain> ( Xaroth, as you can see I too have a hard time processing assembly :p)
18:45:01 <Xaroth> I'm not the only one \o/
18:46:55 <nsz> you mean ax-memoryblabla >= 0 ?
18:46:58 <TrueBrain> well, if subw would be cmpw, it would be: if (ax >= memoryblabla)
18:47:12 <TrueBrain> but now the cmp is a sub, so ax is done - memoryblabla
18:48:49 <nsz> but it's enouhg if you do ;)
18:48:58 <TrueBrain> well, I am just guessing here
18:49:16 <TrueBrain> ax.x -= memoryblabla; if (ax >= 0)
18:49:19 <TrueBrain> I think the above code is
18:49:42 <nsz> isn't this in the x86 cpu manual?
18:49:52 <TrueBrain> how to translate this shit to C? :)
18:50:08 <nsz> no, what is the semantics of subw
18:50:14 <TrueBrain> I know exactly what each statement does, but it is tricky to make C out of it :)
18:50:20 <TrueBrain> I know when sub sets cf
18:50:23 <TrueBrain> just translating that back is hard
18:54:03 <nsz> if they are eq then there is no carry
18:54:04 <TrueBrain> cf means <, so !cf means >=
18:57:37 <TrueBrain> haha, now I understand why I couldn't figure it out ... I misunderstood a memory position :) I thought it indicated the END of the used overlay memory, but it indicates the BEGIN :p
18:58:52 *** ChanServ sets mode: +v Yexo_
18:59:28 <TrueBrain> hmm .. not even that .. it is just a weird value :p
19:04:37 <TrueBrain> but okay ... I was looking for those strange :0000 jumps :)
19:04:40 <TrueBrain> lets ignore the rest for now :p
19:09:39 <TrueBrain> nsz: I start to think you are right about serialization; I now have 'pointers' to the next element, but those are of course not valid ;) Via serialization that would be possible
19:13:43 <nsz> well serialization is a higher abstraction so as always it's more flexible, but slower and sometimes needs extra boilerplate
19:14:05 <TrueBrain> my biggest problem is how to keep it simple to write, and later on easy to remove
19:14:13 <TrueBrain> as in the end it of course doesn't have to link to real memory ;)
19:20:24 <TrueBrain> hmm .. in the code where I would expect it, I can't find where the stack is changed to a 0x0 :s
19:24:57 <nsz> oh btw when i wanted to erase the hall of fame the game exited
19:25:18 <TrueBrain> segfault? clean exit?
19:25:37 <TrueBrain> it is possible the DOS interrupt for delete file or what ever is not there :)
19:25:44 <TrueBrain> but it should tell you :)
19:27:11 <TrueBrain> 21:something most likely
19:27:29 <nsz> [EMU] [ INT21:41 ] Not Yet Implemented
19:27:44 <TrueBrain> delete file, yes :)
19:36:37 <TrueBrain> okay, if I read this correctly, such :0000 thingy is inserted every time an overlay calls a function outside its own overlay
19:41:32 <TrueBrain> well, not always .. hmm ..
19:51:42 <Xaroth> so, what did i miss :o
19:51:48 <TrueBrain> the whole world!!! :p
19:51:55 <TrueBrain> I just finally understood why a swap was where it was ....
19:52:12 <TrueBrain> I am still working on overlays, yes
19:53:12 <TrueBrain> I still have no real indication where the 0x0000 comes from :)
19:54:25 <Yexo> is your dune clone running already?
19:54:37 <TrueBrain> running, yes; running good, no :p
20:58:18 <TrueBrain> I am spoiled with C++ :p
21:01:46 <TrueBrain> overlayManagerAddToLinkedList
21:01:52 <TrueBrain> I am so creative with names! \o/
21:02:22 <TrueBrain> you sound like a parrot
21:07:12 <Xaroth> working on the overlay manager?
21:07:24 <TrueBrain> have I been doing anything else? :p
21:07:34 <TrueBrain> I need to fix this problem before it works .. so it is prio 1 :)
21:07:49 <TrueBrain> more what appears to be debug hooks ..
21:10:39 <TrueBrain> weirdly enough, 2 directly after eachother
21:11:00 <TrueBrain> oh, one at 0x82, the other at 0x84
21:13:44 <Xaroth> still confuzzled by all this asm code
21:15:06 <TrueBrain> same here .. same here ..
21:15:14 <TrueBrain> I was tracing this :0000 thing
21:15:19 <Xaroth> need to figure out a good IDE for all this as well :/
21:15:27 <TrueBrain> and I end up somewhere deep in the code, I never expected to come in the first place ..
21:15:36 <TrueBrain> netbeans kind of fails on this amount of files :p
21:15:53 <Xaroth> I have Geany installed on this, fuck knows how effective that'll be
21:16:59 <Xaroth> but i can ctrl+click on the f__ functions to 'continue' there
21:17:08 <TrueBrain> lovely features, not? :)
21:17:35 <Xaroth> I still love VC Studio.
21:18:15 <Xaroth> .. and i don't even know why
21:19:20 <Xaroth> the 'entrypoint' of the decompiled stuff is at f__01F7_0000_000C_7FBC right?
21:19:29 <TrueBrain> okay ..... what ever this :0000 shit is, it appears to be VERY deep :s
21:19:38 <TrueBrain> the start point is not so interesting
21:19:42 <TrueBrain> it is a default c loader
21:19:56 <TrueBrain> I think you can better begin at any B file
21:20:06 <TrueBrain> they work on their own .. and do something :p
21:20:15 <Xaroth> that's what I'm afraid of :P
21:20:20 <TrueBrain> netbeans has a 'calltree' feature, that is kind of useful :)
21:20:34 <Xaroth> I haven't even really figured out what all the emu_* vars actually 'do'.
21:20:43 <TrueBrain> the vars, nothing :)
21:20:49 <TrueBrain> ax, bx, cx, dx are 'general' registers
21:20:57 <TrueBrain> 'ds' and 'es' are segment registers
21:21:06 <TrueBrain> 'si' and 'di' their 'offset'
21:21:12 <TrueBrain> 'sp' and 'ss' are stack indicators
21:21:17 <TrueBrain> 'bp' is a 'backup' of sp
21:21:25 <TrueBrain> 'cs' and 'ip' is current instruction
21:21:33 <TrueBrain> and besides the last two, the rest can all be freely abused :)
21:21:46 <TrueBrain> assembly limits the usage of a few, that is why you sometimes see weird code, but that is all
21:22:14 <TrueBrain> oh, and [abcd]x have a low byte and high byte. the .x is 16bit, the .l is &0xFF of that and .h is the >>8 of that
21:22:15 <Xaroth> so *x are 'global' vars?
21:22:21 <Xaroth> and *s are 'local' vars
21:22:27 <Xaroth> local being the segment
21:22:29 <TrueBrain> the latter sur enot
21:22:42 <TrueBrain> please read up how 16bit CPUs work :p
21:22:51 <Xaroth> ... I don't want to die just yet?
21:22:53 <TrueBrain> segment:offset is how memory is called
21:23:06 <TrueBrain> in reality this gives the address: (segment << 4) + offset
21:23:12 <TrueBrain> this allows 20bit memory space (1M)
21:23:13 <Xaroth> unless you got a 16 bit CPU for dummies somewhere :P
21:23:53 <Xaroth> so ds << 4 + di && es << 4 + si ?
21:24:02 <TrueBrain> they are mostly used in pairs, yes
21:24:12 <TrueBrain> lods and stos for example do use them in pairs
21:24:26 <TrueBrain> btw, ds is paired with si, and es with di
21:24:33 <TrueBrain> ds:si <- source. es:di <- destination
21:24:50 <TrueBrain> emu_cmpws(&emu_get_memory16(emu_ds, 0x00, 0x128), 0x0); <- another common use of 'ds'
21:25:02 <TrueBrain> you can't have [abcd]x in the first parameter. It has to be a ?s type
21:28:50 <TrueBrain> I wonder if you have a log of all the fuzzy calls you have seen
21:30:54 <Xaroth> that thing in patched.c doesn't exist in any of the files o_O
21:31:23 <TrueBrain> hehe; the hg is btw old, but nevertheless, it is called exactly once :)
21:31:35 <TrueBrain> it replaces the f__ function
21:31:41 <TrueBrain> which of course is no longer there ;)
21:37:25 <Xaroth> right, emu_push adds something to the stack, emu_pop removes something from the stack
21:39:13 <TrueBrain> cmp does much more than just if equal
21:39:17 <TrueBrain> it does everything :)
21:39:24 <TrueBrain> in reality it is a sub, but without writing the value :p
21:43:04 <Xaroth> hah, long live vmware-toolbox
21:43:10 <Xaroth> copy paste support ftw :o
21:45:38 <Xaroth> mov is simply put "*arg0 = arg1"
21:45:46 <TrueBrain> without the *, and yes
21:46:13 <Xaroth> so it's a mem copy.. sorta
21:46:30 <TrueBrain> mov(&eax, 2) => eax = 2
21:48:41 <Xaroth> now to figure out the emu_flags
21:49:14 <TrueBrain> the most nastiest part of a CPU :)
21:51:08 <Xaroth> emu_orw(&emu_di, emu_di); if((emu_flags.sf != emu_flags.of)) << isn't that a crude way of isset() ?
21:52:40 <TrueBrain> sf != of means: less; just now I wonder for a moment what 'less' means .. as I also have 'below' :p
21:54:08 <TrueBrain> and 0 is less than 1 :p
21:55:33 <Xaroth> but, how can something be less than himself :P
21:55:44 <TrueBrain> well, the or(a, a) is used a lot in fact
21:55:48 <TrueBrain> mostly to check if it is empty
21:56:01 <TrueBrain> ah, below is unsigned, less is signed
21:56:55 <Xaroth> so it's an empty rather than an isset?
21:57:18 <TrueBrain> hmm .. this is a tiny bit more tricky
21:57:28 <TrueBrain> what it does is check if the first bit is set .. so if it is a negative value
21:57:41 <TrueBrain> after an or 'of' is always 0
21:57:50 <TrueBrain> 'sf' is the signed flag
21:58:01 <TrueBrain> they are only not equal when di was signed (so negative)
21:58:16 <TrueBrain> so: if (emu_di < 0)
21:58:21 <TrueBrain> if ((int16)emu_di < 0)
21:58:23 <TrueBrain> if I got it right ;)
22:03:36 <Xaroth> I'll add a comment then
22:03:42 <Xaroth> "if TB got it right :P"
22:03:48 <TrueBrain> comments in decompiled/ are lost
22:03:54 <TrueBrain> only things in src/ are kept
22:04:03 <Xaroth> I'm working in notepad, trying to convert it
22:04:15 <Xaroth> need to learn it somehow
22:04:26 <TrueBrain> identifying is 90% of the work
22:04:28 <TrueBrain> just so you know :)
22:05:19 <Xaroth> heh, i think i got this one now
22:05:57 <Xaroth> cmpws(get_memory(somewhere), 0x0); if(emu_flags.zf) << if "get_memory(somewhere) == 0"
22:09:09 <TrueBrain> why you commented out those pushes?
22:09:12 <TrueBrain> they seem very important to me :)
22:09:17 <Xaroth> so I ignored them mentally
22:09:36 <TrueBrain> I should make a coding style page soon :p
22:09:43 <Xaroth> comments get turned dark green, normal code is white
22:10:05 <TrueBrain> but yes, you got this right
22:10:08 <TrueBrain> now try to figure out what it does :p
22:10:12 <TrueBrain> (haha, no easy task :))
22:10:34 <Xaroth> I think it's better to first change it to more readable, before attempting to decypher it
22:10:37 <TrueBrain> and maybe revert the logic that those none-resolving trigger a return
22:10:45 <TrueBrain> then you can merge in the next function ;)
22:10:54 <TrueBrain> (sometimes you have to start a new function, sometimes you should merge them ...
22:10:58 <TrueBrain> not always to say when which what :p)
22:11:19 <TrueBrain> "begrijpend lezen" ++ :p
22:13:34 <Xaroth> still find it funny that those hundreds of files we have now, will some day (in the distant future) be something as semi-organised as ottd
22:14:03 <TrueBrain> dunno if it will ever happen :)
22:14:38 <TrueBrain> whoho, first for-loop :p
22:17:17 <Xaroth> the or zeroflag, is when both are zero?
22:17:55 <Xaroth> emu_movw(&emu_ax.x, emu_get_memory16(emu_ss, emu_bp, 0x8));
22:17:56 <Xaroth> emu_orw(&emu_ax.x, emu_get_memory16(emu_ss, emu_bp, 0xA));
22:18:26 <TrueBrain> ax = bla; ax &= otherbla
22:18:36 <TrueBrain> or: ax = bla & otherbla
22:18:44 <Xaroth> yeh,talking about the ZF :)
22:19:04 <TrueBrain> zero-flag is only set when the resulting valueis zero
22:19:33 <DorpsGek> Xaroth: Error: Something in there wasn't a valid number.
22:19:40 <DorpsGek> Xaroth: Error: invalid syntax (<string>, line 1)
22:19:46 <TrueBrain> or never looses value
22:20:04 <TrueBrain> if the bit is on at the one or at the other
22:20:11 <TrueBrain> so values always get bigger (unsigned-wise)
22:20:31 <Xaroth> so that orw plus the zf is basically an if-equals
22:21:17 <Xaroth> emu_orw(&emu_ax.x, emu_get_memory16(emu_ss, emu_bp, 0xA));
22:21:17 <Xaroth> if (emu_flags.zf) { f__B427_006D_0015_EB48(); return; }
22:21:19 <TrueBrain> either you are WAY too crypted, or you don't make sense :p
22:21:34 <TrueBrain> ax = bla; ax &= otherbla; if (ax == 0x0) {}
22:22:04 <Xaroth> [@TrueBrain]: or never looses value <
22:22:05 <TrueBrain> or, if you want to go crazy: if (bla == 0x0 || otherbla == 0x0) :p
22:22:26 <TrueBrain> a | b <- it can never lose a bit which was already active
22:22:28 <TrueBrain> that is what I meant
22:22:38 <TrueBrain> the result is always >= a and >= b
22:22:56 <TrueBrain> even C# has bit-operators! :p
22:22:58 <Xaroth> yeh, so a & b can only equal 0 if both are 0
22:23:05 <Xaroth> I hardly ever use bit operators
22:23:12 <TrueBrain> this is _or_ not _and_ ;)
22:23:18 <TrueBrain> but yes, with or, as I said
22:23:31 <Xaroth> ah wait, yes, i'm not making sense
22:24:21 <Xaroth> so if (emu_ax.x == 0 || emu_get_memory16() == 0)
22:24:46 <TrueBrain> why overcomplicate this situation?
22:24:51 <TrueBrain> just do what the assembly told you :p
22:25:06 <TrueBrain> that is what it says if I read it correctly ;)
22:25:45 <TrueBrain> and if you are 100% sure ax is never used, if (bla == 0 || otherbla == 0)
22:26:01 <TrueBrain> but not a mix of ax and bla/otherbla :p
22:26:17 <Xaroth> that's the point, at this point it's hard to tell :p
22:26:37 <TrueBrain> so don't make guesses, and be sure :)
22:26:43 <TrueBrain> (by leaving the value in ax :p
22:26:50 <TrueBrain> btw, of course you can also do: ax = bla | otherbla
22:27:18 <Xaroth> I rather have a line too many to keep things clear at this point :P
22:28:00 <Yexo> sorry to bump in, but: <@TrueBrain> and if you are 100% sure ax is never used, if (bla == 0 || otherbla == 0) <- that is different than the lines above
22:28:17 <Yexo> shoudln't it be "if (bla == 0 && otherbla == 0)" ?
22:28:19 <TrueBrain> no need to be sorry, and do tell :)
22:28:42 <TrueBrain> they both need to be zero, yes :)
22:29:00 <Xaroth> f__B427_046C_0004_07E2 is piss easy to decrypt...
22:29:27 <Xaroth> pop.. pop some more.. another pop and his pop brother, and yes.. another pop
22:29:52 <Xaroth> I'll treasure this one
22:31:54 <Xaroth> emu_movw(&emu_get_memory16(emu_ss, emu_bp, -0x2), emu_ax.x); << emu_set_memory works just as well i take it?
22:32:12 <TrueBrain> there is no emu_set_memory :p
22:32:22 <TrueBrain> just do what I told you: remove the emu_mov?
22:32:31 <TrueBrain> (oh, and remove the () :p
22:32:38 <TrueBrain> it works for ALL movs :p
22:39:48 <Xaroth> s/emu_cmpws(\([^)].*\)), 0x0);\n\t if (!emu_flags.zf)/if(\\1 != 0)
22:40:08 <TrueBrain> many of such things will be possible
22:40:12 <TrueBrain> but that is for the analyser
22:40:15 <TrueBrain> which I might add in the future ;)
22:40:25 <TrueBrain> just it doens't always hold
22:40:32 <TrueBrain> emu_shrw(&emu_cx.x, 0x1);
22:40:33 <TrueBrain> if (emu_flags.zf) { f__217E_0787_0003_020A(); return; }
22:40:35 <TrueBrain> if (emu_flags.cf) { goto loop1; }
22:40:37 <TrueBrain> 1 'compare', 2 result-checks
22:43:15 <TrueBrain> how it works it works ... but I found the code which puts back the right return-code for the weird overlay call :p
22:43:28 <TrueBrain> I am just completely clueless what it does :p
22:50:48 <TrueBrain> hmm .. it seems I finally found where that thingy gets inserted :)
22:51:25 <TrueBrain> just it now skips the Westwood stuff completely :p
22:51:54 <TrueBrain> so it is important for ... something :)
22:54:04 <TrueBrain> I thought it was happening randomly, but clearly it has a very predefined function
22:54:49 <TrueBrain> but I now just get the menu, which seems workable :p
22:55:17 <TrueBrain> just a stackoverflow over a few (read: a lot) of functions
22:59:22 <TrueBrain> okay, clearly a lot depends on this magic ..
22:59:42 <TrueBrain> oh well, tomorrow I will continue
22:59:44 <TrueBrain> now, I will find my bed
22:59:51 <Xaroth> almost done with a load of functions
23:00:12 <TrueBrain> send it to me when you are done :)
23:02:30 <TrueBrain> yeah ... coding style is needed :p
23:02:47 <TrueBrain> // not really much to decrypt here....
23:03:06 <TrueBrain> emu_bx.x = emu_bx.x << 1; // emu_bx.x = emu_di << 1;
23:03:13 <TrueBrain> as I said, assembly is limited
23:03:17 <Xaroth> hence why I put the comment behind it
23:03:25 <Xaroth> but for now leaving it on two lines
23:03:29 <TrueBrain> well, either write it like that, or remove the comment
23:03:29 <Xaroth> god knows what it might fuck up :P
23:03:44 <TrueBrain> I don't care about possibles, we need good working code :p
23:04:08 <TrueBrain> shit, you used the old code ...
23:04:23 <TrueBrain> xor(ax, ax) => ax = 0
23:04:28 <TrueBrain> (less CPU cycles, don't ask :))
23:04:40 <TrueBrain> if(emu_get_memory16(emu_ds, 0x00, 0x700A) = 0) <- AUCH! :p
23:05:03 <TrueBrain> emu_ax.x |= emu_ax.x; <- ghehe :)
23:05:20 <TrueBrain> it made me laugh :)
23:05:20 <Xaroth> not to mention a learning thing
23:05:50 <TrueBrain> emu_sp = emu_sp = 4 <- some are just fun :)
23:06:14 <Xaroth> amazed you didn't find your comment in that code yet
23:06:25 <TrueBrain> overall, nicely done :)
23:06:34 <TrueBrain> tomorrow I will talk you through a few basics about combining those functions
23:06:41 <TrueBrain> for that I will first upload new code for you :)
23:06:54 <TrueBrain> and maybe resolve the mov() shit, as it annoys me, that I have to type that over and over :p
23:06:55 <Xaroth> gimme a few hours worth of coding time to get the hang of this
23:07:03 <TrueBrain> all the time you need :)
23:07:19 <TrueBrain> but I now too much want to find my bed, to talk you through the next phase :)
23:07:24 <TrueBrain> we leave that for tomorrow ;)
23:07:30 <TrueBrain> you are getting there ;)
23:07:34 <Xaroth> long glad I'm becomming useful
23:07:47 <TrueBrain> the biggest challenge is understanding what does functions do
23:07:57 <TrueBrain> and that is like a big puzzle, alle rectangle and black
23:08:03 <TrueBrain> but with tiny tiny difference, and small hints
23:08:11 <TrueBrain> once you connect a few things, you see it grow more and more
23:08:37 <TrueBrain> currently I have NO idea what this overlay does :p
23:08:43 <Xaroth> well that's the turning point to 'useful' C code
23:09:07 <TrueBrain> okay, we need a website where we can put which memory address does what
23:09:10 <TrueBrain> or what we think it does :p
23:09:35 <TrueBrain> I figured out a few things for the overlay manager, but I guess all have stuff like that
23:09:57 <TrueBrain> okay, remind me I will need to explain 2 things to you: stack, and control flow :)
23:10:54 <Xaroth> considder post-it made :P
23:11:08 <TrueBrain> and I think I will make a small tool, looking glass so to say, which can show the assembly for a region, in case you wonder what the original was :) (I have that often enough :p)
23:11:25 <TrueBrain> btw, my p__ was a 'patched' indicator :p
23:11:38 <TrueBrain> I more often now just leave the f__ names, till I found the correct name for the function ;)
23:11:49 <TrueBrain> oh, so much to tell you ... haha .. be prepared for information overload :p
23:11:58 <Xaroth> We need to store this useful info somewhere tho :P
23:12:07 <TrueBrain> it sucks to have to type all this, makes it much harder
23:12:13 <TrueBrain> I will write a few wiki pages with info for you :p
23:12:52 <TrueBrain> k, stuff for tomorrow :p
23:13:00 <TrueBrain> was another good day ...
23:13:04 <TrueBrain> a few more of those, and we are done ;)
continue to next day ⏵
