IRC logs for #opendune on OFTC at 2009-12-07
⏴ go to previous day
00:00:01 <Xaroth> I would have called it f__ if it were opendune functions :)
00:00:26 <TrueBrain> fopen, fclose, fgets, fgetc, fread, fwrite
00:00:33 <TrueBrain> all you will ever need I guess .. ftell .. fseek ..
00:00:48 <TrueBrain> lseek is btw the name I believe, but okay, close enough
00:01:15 <TrueBrain> always open files with either "rb" or "wb"
00:01:22 <TrueBrain> never believe the \n \r conversion of any OS
00:01:38 <glx> even if 'b' is windows only ;)
00:03:23 <Xaroth> interesting read, still :)
00:04:04 <TrueBrain> k, now I will find my bed :) glx, if you don't forget to upload your patch to your dev-space, I will test it tomorrow :)
00:04:38 <TrueBrain> nice work btw glx, it is a nice function to C-ify :)
00:05:03 <glx> and not a very hard one :)
00:05:23 <Xaroth> [@glx]: and not a very hard one :) << that's up for debate :P
00:05:38 <TrueBrain> and it allows something cool at this stage: add 'opendune.cfg'. If not detected, convert dune.cfg to opendune.cfg. Make opendune.cfg a more sane format, and add tons of cool and fun stuff to it! :p
00:05:50 <glx> the conversion skips all the complexity of original code
00:05:53 <TrueBrain> in other words: it allows expension at this stage :) Like switching between 'enhanced' mode :p
00:05:59 <Xaroth> TrueBrain: we can even use xml! :P
00:06:23 <TrueBrain> if you can find sane arguments to use XML as configure storage format, the floor is yours
00:07:10 <TrueBrain> Xaroth: lua is: a) silly, b) overkill, c) complex, d) too slow, for simple configure data
00:07:12 <glx> as long as it's human readable I don't care ;)
00:07:21 <TrueBrain> then I suggest ini too ;)
00:07:23 <Xaroth> TrueBrain: not if the AI is also in lua :)
00:07:30 <TrueBrain> Xaroth: even more if the AI is lua
00:07:40 <glx> lua for config file is silly
00:08:05 <TrueBrain> then you can make parse errors in your configure data? :p
00:08:09 <TrueBrain> I mean .. come on! :)
00:08:33 <TrueBrain> question: should we keep it possible to play the game without mouse?
00:08:45 <glx> btw ini reader will be used for scenarios too ;)
00:08:47 <TrueBrain> question: should we keep it possible to play the game on low memory systems?
00:09:04 <TrueBrain> in other words: do we want to support 8086 machines?
00:09:15 <Xaroth> I'd personally vote no
00:09:27 <Xaroth> as keeping 8086 support will be a PITA to implement 'new' stuff
00:09:51 <TrueBrain> well, via a good modular system, that would be possible.. that is: the 'old' stuff works, the 'new' stuff requires more
00:10:02 <Xaroth> it's like backward compatibility going over the top
00:10:03 <TrueBrain> but I tend to agree that it is too much of a hussle for VERY VERY little gain
00:10:37 <TrueBrain> k .. we also need to start thinking about the language system .. gettext or something like OpenTTD, or what
00:10:40 <Xaroth> 8086 was so 20 years ago :P
00:11:07 <TrueBrain> that said, I think it is a good time as any other to start adding a sane configure format, which allows us to define a few things ourselves
00:11:11 <TrueBrain> like 'dune2_enhanced' :)
00:11:44 <TrueBrain> I even wouldn't care if every enhancement got its own entry in the ini :p
00:11:49 <Xaroth> separate section for that
00:11:58 <Xaroth> [dune] for 'normal' settings
00:12:04 <Xaroth> [dune_enhanced] for all the enhancements
00:12:33 <TrueBrain> Xaroth: I was more thinking like: [screen], which defines resolution and stuff (in the future of course), [sound], [general], ...
00:12:41 <TrueBrain> and maybe one [enhancement] or what ever :p
00:12:47 <Xaroth> but for now we don't really have much for that :P
00:12:56 <TrueBrain> glx: allocs can now be removed, not?
00:13:22 <Xaroth> so as a start we can keep it to two sections, then as the config list grows we can redesign it to a more neat (and sane) layout
00:13:40 <TrueBrain> Xaroth: k. Then the question is if we really want every enhancement to be togglable :p
00:13:46 <TrueBrain> implementing it is dead easy of course
00:13:58 <Xaroth> some will eventually be linked together as well
00:16:06 <glx> and MSVC warns about unsafe functions ;)
00:16:06 <TrueBrain> please add in decompiled/decompiled.h, as first include: #include "../src/config.h"
00:16:31 <Xaroth> MSVC should shut the hell up then :P
00:16:42 <TrueBrain> glx: you can use 'strncat'
00:17:30 <TrueBrain> at least you can add an assert which triggers when 'filename' is too big
00:17:43 <TrueBrain> (memory corruption or what ever)
00:18:17 <TrueBrain> Xaroth: I agree; although I once made the basics for such system, and showed that OpenTTD needed one more signal before it could do all ports
00:18:30 <glx> ,...assert(strlen(filename) < 13); <-- like that ?
00:18:58 <TrueBrain> glx: just to be 100% sure ;) Later on we make that more nice, and remove the 8.3 limit :p
00:19:18 <TrueBrain> but I see this function more as something that is used to port from the old system, to our new system
00:20:08 <glx> yes it's a good entry point to inject our stuff :)
00:20:20 <TrueBrain> * This is the layout of dune.cfg. <- maybe add something like 'after decoding it', or something more readable :)
00:21:39 <TrueBrain> either way, I was going to bed .. 20 minutes ago :)
00:21:45 <Xaroth> good night, TrueBrain :)
00:21:49 <TrueBrain> glx: your patch looks nice, given the few minor feedback I gave
00:24:00 <Xaroth> hm, f__B480_0000_0018_A09B does stuff with the config
00:24:16 <Xaroth> it reads variable_0000
00:24:38 <Xaroth> and it reduces it by 7 o_O
00:25:15 <glx> but I still don't know what's the purpose of variable_0000 ;)
00:25:58 <Xaroth> subtract 7, checks if > 5 o_O
00:27:14 <Xaroth> is it correct that emu_String_printf() doesn't .. print anything?
00:27:23 <Xaroth> (as such, being sprintf? )
00:29:01 <glx> "Unrecognized graphic mode!\r\n"
00:29:04 <Xaroth> /* 0181(29) */ PACK char string_0181[29]; /*!< "Unrecognized graphic mode!\r\n" NULL terminated. */
00:29:20 <Xaroth> so it defines the graphic mode
00:32:07 <glx> but we need some crash.bin to find more info :)
00:32:46 <Xaroth> mass searching for 0x98E1 doesn't yield all stuff related to conig
00:33:03 <glx> there's only 2 references in all source :)
00:33:17 <glx> but look above the printf ;)
00:34:35 <Xaroth> the unresolved call? :P
00:34:56 <glx> yes the jumps depend on 98E1 value :)
00:35:38 <Xaroth> more specifically, on the value of 0x98E1
00:36:04 <Xaroth> let me rephrase that one
00:36:11 <Xaroth> on the value of 98E1 + 0x3D0
00:36:35 <Xaroth> which is a long list of unknowns
00:38:03 <glx> it's an array in the code segment
00:39:41 <Xaroth> that whole segment confuses me :P
00:40:10 <Xaroth> I think we can trigger crash reports by changing that byte in the file
00:40:21 <Xaroth> up or down depending on its current value
00:40:42 <glx> yes but for that you need to decode, change, recode
00:41:05 <Xaroth> oooor abuse your patch :)
00:41:07 <glx> because the checksum must match
00:41:15 <Xaroth> aka, read config -> change value -> continue
00:41:32 <Xaroth> as in, change it after the check
00:44:08 <Xaroth> I see no occurance of 0x98E7 or 0x98E8 tho
00:47:26 <Xaroth> i should go sleep as well
00:48:45 <DorpsGek> SVN: glx (r681) -Add: C-ified Config_Read()
01:03:07 <glx> 01c4 01c4 01cc 01c4 01c4 01c4 <-- ok all variable_0000 value gives almost the same result
01:03:45 <glx> and 2 (0x98E1 = 9) is invalid
10:31:36 *** ChanServ sets mode: +v Yexo
12:53:09 *** ChanServ sets mode: +v Yexo_
13:08:51 <glx> TrueBrain: can you provide an unpactched decompiled version ?
13:09:09 <glx> I have an idea about why and how it fails :)
13:23:35 <glx> the cause of the need for patching is f__01F7_20B5_0076_64ED()
13:23:50 <glx> it doesn't really return, but jumps to return IP
13:24:09 <TrueBrain> okay, so you are talking about the function in patched.c?
13:24:22 <TrueBrain> sorry, you were a bit unclear about that ;)
13:24:27 <glx> I need an unpatched version to check my idea
13:24:45 <TrueBrain> the only 'patched' part about it is at the bottom, the check for a different cs
13:27:08 <glx> yes but it then calls f__01F7_022D_0003_9E5A which is normally not a call, but next instruction after the call returns ;)
13:27:26 <glx> and the unpatched version will be cleaner to test
13:27:38 <TrueBrain> and this is just a common way to capture cs:ip
13:29:29 <TrueBrain> the unpatched version is a mess
13:29:57 <glx> f__01F7_022D_0003_9E5A adds extra calls when it should be a jump
13:30:15 <TrueBrain> 22D does nothing special, it just jumps back to the begin of the function
13:31:51 <TrueBrain> and of course remove the patched files
13:33:28 <TrueBrain> 20B5 btw is fine, just the code is a bit weird
13:33:35 <TrueBrain> the pop(es) removes the IP
13:34:29 <TrueBrain> no, that is not true :p
13:34:56 <TrueBrain> the tailing code of 20B5 is wrong, because the decompiler doesn't handle wrongly rejumping of code
13:35:20 <TrueBrain> 20B5 is a bit like a farjump in C
13:35:50 <glx> yes just replace the switch by a return
13:36:02 <TrueBrain> that is not sufficient
13:36:04 <TrueBrain> the 'ip' really changes
13:36:08 <TrueBrain> so it doesn't return
13:36:13 <TrueBrain> which is the whole point of 'patched.c' ;)
13:38:01 <glx> it's a fake return, similar to pop(&emu_ip)
13:38:27 <glx> just the pop is done at the beginning
13:40:33 <glx> a nice anti-decompiler solution :)
13:42:16 <TrueBrain> no, anti-decompiler thingies look much different
13:42:32 <TrueBrain> this is more a sanity check, most likely differs on some CPU
13:42:40 <TrueBrain> but okay .. the problem in your patch now is the changing of emu_ip
13:43:06 <glx> it just pops emu_ip in a different way
13:43:19 <TrueBrain> ah, I should have looked at the top of the function earlier
13:43:31 <TrueBrain> as it is even much easier: it just wants to record the IP of the function caller
13:43:41 <TrueBrain> normally you can't access the IP :)
13:44:14 <glx> and recalling 0E1D just cause an extra pop to 0138 which is then the cause for the patch :)
13:45:25 <TrueBrain> either way, your patch of mine, both do the same
13:46:00 <glx> mine uses less functions ;)
13:46:20 <TrueBrain> but puts a much bigger function in patched.c :p
13:47:01 <TrueBrain> so I suggest you C-ify those functions :)
13:47:10 <TrueBrain> 21AB is 0x33 in bytesize
13:47:24 <TrueBrain> we now only have 0x4 in bytesize in patched.c
13:47:54 <TrueBrain> but really, if you figured out so much, why not C-ifying it? :)
13:48:00 <TrueBrain> 20B5 doesn't look too big?
13:48:54 <glx> right, and I know already a part of what it does (like check dos version)
13:48:57 <TrueBrain> mostly initializing ...
13:50:03 <TrueBrain> most unresolveds will never be called :p
13:50:50 <glx> and global variables are just "locals" indeed
13:51:53 <glx> this function really does weird thing, it should have been edited by hand ;)
13:52:52 <glx> and the funny part is there's a function inside the function (f__01F7_2148_0028_6CAC)
13:53:39 <glx> can't be something generated by a compiler, at least doesn't look like it :)
13:57:18 <glx> I'll still provide crash.bin to resolve jumps :)
13:59:42 <TrueBrain> btw, most of 01F7 comes from Borland itself
13:59:46 <TrueBrain> so a lot of custom written
13:59:49 <TrueBrain> directly in assembly
14:00:42 <glx> borland guys should have had some fun writting that :)
14:01:03 <TrueBrain> a one time job .. like my decompiler :p
14:01:21 <glx> yup, but your decompiler clearly doesn't like it :)
14:01:43 <TrueBrain> well .. when something breaks the normal ip-flow, it needs a bit more work
14:01:48 <TrueBrain> which I didn't feel like adding :p
14:02:01 <TrueBrain> either way, all functions which do not start with a push of bp, and bp = sp, were not C
14:05:27 <TrueBrain> k, I was writing a XUL application .. not really going anywhere :p
14:14:53 <DorpsGek> SVN: truebrain (r682) -Fix (r681): missing include
14:15:01 <TrueBrain> grr @ glx for not listening :p
14:15:22 <glx> I just missed one of your "many" comments ;)
14:15:54 <DorpsGek> SVN: truebrain (r683) [JIT] -Add: mapped another 3 functions (crash-bins provided by glx)
14:16:08 <DorpsGek> SVN: truebrain (r684) -Update (r683): update decompiled code
14:17:08 <glx> ,...emu_Error_Abnormal_Termination(); return;
14:20:44 <TrueBrain> I am suprised there is a return there :p
14:28:02 <glx> I can try to decipher it ;)
14:32:01 <TrueBrain> then I continue on my XUL applicatin
15:35:01 <glx> ok I'd say f__01F7_20B5_0076_64ED() is totally useless for us :)
15:39:51 <TrueBrain> I dont think you are wrong in that
15:40:20 <glx> it seems to copy args on the stack, but I don't know if it's used later
15:51:52 <TrueBrain> haha, did youmanual resolve that? :p
15:52:38 <TrueBrain> it is a clver way to allow debugging, and intercept video stuff
15:52:48 <TrueBrain> but okay .. you are sure the collected data is never used again?
15:53:24 <glx> but I can double check to be sure
15:53:34 <TrueBrain> 2 humans see more than one ;)
15:54:54 <TrueBrain> I guess 353F:007D has the dos version?
15:56:12 <TrueBrain> I only worry about the rep_movsb and stosb
15:57:39 <TrueBrain> it also sets the ss:sp in the ss:bp+0x0
15:59:19 <TrueBrain> but yes, it seems to be glue code so on exit it restores everything
16:00:06 <glx> hmm it stores some stuff in 0x6B-0x6F
16:00:46 <TrueBrain> either way, it looks heavily unused .. still I think we should keep it around for now
16:01:56 <TrueBrain> so either just leave it, or rewrite it .. it is a bit the same to me :)
16:05:39 <glx> rewriting useless stuff is well ... useless ;)
16:06:34 <TrueBrain> in general :) But it might help later on
16:09:30 <TrueBrain> but I guess 90% of 01F7 is not required to C-ify .. most are libc functions and shit
16:15:55 <glx> it's called only when the program terminates anyway, so no return is not a real problem :)
16:26:53 <TrueBrain> hahaha :) Fair enough ;)
16:27:00 <TrueBrain> I will stop looking at random 01F7 functions :p
16:27:42 <TrueBrain> lol: today I told my labpartner to go fuck himself, in a much nicer way of telling him that .. and a CC to my teaser and assistant of the course .. and now he comes back blaming me for not putting enough effort in contacting him
16:27:45 <TrueBrain> hahaha .. what an ass
16:36:19 <glx> yes all easy to name 01F7 functions are done now ;)
16:36:38 <glx> I used the random look method too
18:21:59 <TrueBrain> so .. what shall I do next .. hmm .. things to consider ...
18:32:43 <TrueBrain> and I openend the last cs and tried looking at it
18:32:45 <TrueBrain> something with IO :p
18:33:04 <TrueBrain> and then I got inside the overlay manager
18:33:23 <TrueBrain> which is also a piece which we hopefully never have to C-ify :p
18:33:35 <DorpsGek> SVN: glx (r685) -Add: named some variables in UnitInfo and StructureInfo
19:17:48 <DorpsGek> SVN: truebrain (r686) -Add: named a few functions which are related to the Overlay Manager
19:27:03 <TrueBrain> okay, randomly looking at shit turns out to be useless :p
19:27:15 <TrueBrain> or at least less useful
19:31:29 <TrueBrain> @base 10 16 [calc 0x8282 - 0x822c]
19:31:42 <TrueBrain> @base 10 16 [calc 0x8430 - (0x8282 + 14)]
19:49:00 <glx> I'm trying to find where *Info->wsa is used :)
19:49:26 <DorpsGek> SVN: truebrain (r687) -Add: found one more variable
19:50:32 <DorpsGek> SVN: truebrain (r688) [JIT] -Add: mapped another 6 functions (crash-bins provided by TrueBrain)
19:50:54 <DorpsGek> SVN: truebrain (r689) -Update (r688): update decompiled code
20:01:15 <TrueBrain> finally .. the magic key I was looking for was 'tab' :)
20:01:22 <TrueBrain> which we did not bind ;)
20:01:44 <TrueBrain> go to the next structure/unit you see on your screen
20:03:53 <TrueBrain> k .. the lack of shift makes it not 100% working :p
20:04:30 <DorpsGek> SVN: truebrain (r690) [LibEMU] -Add: bind 'tab' too
20:05:36 <DorpsGek> SVN: truebrain (r691) -Add: named one more function
20:05:53 <TrueBrain> it was annoying me :p
20:06:06 <TrueBrain> one remaining unknown function in 0642
20:09:06 <glx> oh msvc didn't notice the update :)
20:16:11 <TrueBrain> no idea what the remaining one does
20:20:33 <TrueBrain> it is some kind of animation .. palette animation?
20:20:42 <TrueBrain> as now things stay purple, if I disable the function
20:21:55 <TrueBrain> but at some places palette animation seems to work just fine
20:23:43 <TrueBrain> at least the 'repair' text is affected
20:23:46 <TrueBrain> and the windtraps ..
20:23:55 <TrueBrain> they are 'red' when you load a map, now they stay purple :p
20:24:30 <glx> because windtrap are blue for me usually :)
20:24:38 <TrueBrain> and look in the first frames
20:24:42 <TrueBrain> they are red for ALL houses
20:25:53 <TrueBrain> only when you just started the game btw
20:26:30 <TrueBrain> it is based on a timer ...
20:30:37 <TrueBrain> it also animates the place-structure cursor
20:31:09 <TrueBrain> which btw is not completely correct, in a fun way: it turns red/white next time it appears .. so when you move between impossible to build and possible to build, you can see a red where it is allowed :p :p
20:32:22 <DorpsGek> SVN: truebrain (r692) -Add: named one more function
20:34:25 <glx> and I'm still looking for ->wsa usage
20:36:02 <glx> it should be used somewhere
20:36:16 <TrueBrain> Info->wsa, in Mentat screens :)
20:53:28 <TrueBrain> /* 0054(2) */ PACK uint16 encodedIndex; /*!< An encoded index. */
20:53:32 <TrueBrain> lol .. but what does it do? :p
20:53:52 <TrueBrain> either 54 or 56 (also an encoded index :p :p) is the current 'target'
20:55:18 <TrueBrain> the other is where to move too
20:55:57 <TrueBrain> (Rocket) Turrets have in script->variables[2] the current target
21:02:09 <glx> ,...emu_push(emu_get_memory16(emu_es, 0x00, 0x55A));
21:02:29 <glx> nice direct access to default hitpoints of turrets
21:03:28 <TrueBrain> and I need to guess if 54 or 56 is the move value ...
21:08:09 <DorpsGek> SVN: truebrain (r693) -Add: named a few variables of Units and Teams
21:08:17 <TrueBrain> 54 was attack target, 56 was move target :)
21:10:40 <DorpsGek> SVN: truebrain (r694) -Add: named two functions related to adding and removing units from teams
21:10:50 <TrueBrain> Xaroth: 16BC, a file you can easily C-ify
21:11:13 <TrueBrain> just 120 lines long, and very self-explaining with the last few commits naming the variables for you :)
21:13:53 <glx> the unresolved jump is easy to solve too :)
21:14:15 <glx> it jumps to emu_xorw(&emu_ax, emu_ax)
21:14:16 <TrueBrain> hmm .. funny .. the variables[5] in scripts is not random
21:14:21 <TrueBrain> they are very predefined
21:14:44 <TrueBrain> variables[2] of units can contain a unit
21:15:04 <Xaroth> can, but doesn't always?
21:15:10 <TrueBrain> well, it can be 0 of course
21:15:20 <TrueBrain> and I am not 100% sure, or anything close to it, that it only contains that
21:15:21 <Xaroth> else i would have guessed target :P
21:15:40 <TrueBrain> for sure it contains either 0 or a valid index :p
21:15:47 <TrueBrain> target is already in the Unit struct
21:21:02 <TrueBrain> I might have been wrong, as '4D' also contains a 'move' position
21:26:02 <TrueBrain> but that might be only for the harvester
21:27:46 <Xaroth> still an unresolved jump in AddUnitToTeam()
21:28:05 <glx> Xaroth: it's an easy one :)
21:28:11 <glx> <@glx> it jumps to emu_xorw(&emu_ax, emu_ax)
21:28:12 <TrueBrain> [22:13] <glx> the unresolved jump is easy to solve too :)
21:28:13 <TrueBrain> [22:14] <TrueBrain> yup
21:28:15 <TrueBrain> [22:14] <glx> it jumps to emu_xorw(&emu_ax, emu_ax)
21:29:03 <glx> hmm ok g_global->variable_3782 is an array indeed
21:50:25 <DorpsGek> SVN: glx (r695) -Add: figured out a few variables
22:35:44 <Xaroth> AddUnitToTeam has 0x8 bytes worth of args
22:49:35 <glx> 16BC:0001:0018:AE47,...emu_Team_AddUnitToTeam,...# (unit_csip), add unit to team <-- incomplete ;)
22:50:58 <glx> it's (team_csip, unit_csip)
22:52:03 <Xaroth> how to actually retrieve the unit objects by their csip?
22:53:26 <Xaroth> you sure the first is team? (so i can safely assume it when cifying)
22:58:21 <Xaroth> ugh, yes, very easy functions
22:58:46 <Xaroth> emu_lfp(&emu_es, &emu_bx, &emu_get_memory16(emu_ss, emu_bp, 0xA));
22:58:46 <Xaroth> emu_lfp(&emu_es, &emu_si, &emu_get_memory16(emu_ss, emu_bp, 0x6));
22:58:46 <Xaroth> emu_al = emu_get_memory8(emu_es, emu_si, 0x0);
23:01:16 <Xaroth> I'm still confused as fook :P
23:01:36 <Xaroth> that part it loads the pointer to the unit first, stores the ES, loads pointer to team
23:04:18 <glx> u->team = t->index + 1 :)
23:06:17 <glx> return t->variable_08 - t->members
23:07:06 <Xaroth> I was having a lightbulb moment
23:07:12 <Xaroth> .. then you said exactly the same thing :P
23:08:08 <glx> of course at start you have if (t == NULL || u == NULL) return 0
23:08:20 <Xaroth> since I already had == 0
23:08:43 <glx> don't mix emu_ and pure C stuff :)
23:09:10 <glx> emu_ checks for ucsip == 0 and tcsip == 0
23:09:15 <Xaroth> no wait, yeh, nevermind
23:09:19 <Xaroth> i was checking on csips :P
23:09:42 <glx> then you get team* and unit*, then call pure C function
23:10:20 <glx> which will check for args validity too, but with NULL :)
23:10:34 <Xaroth> hm, we lack a Team_Get_ByMemory ?
23:11:06 <glx> it's where it should be :)
23:13:09 <glx> indeed these functions are very easy to convert :)
23:13:22 <Xaroth> you just need to look at it closely
23:33:56 <TrueBrain> well, we no longer do need to give it any thought
23:34:01 <TrueBrain> but that makes them perfect for you Xaroth :)
23:34:35 <TrueBrain> you have to start somewhere
23:34:49 <TrueBrain> glx: I can't load a patch in the JIT, so that is a bit problemetic .. I will try something tomorrow :)
23:35:10 <TrueBrain> My labpartner just gave me a lovely flame mail back in return to me telling him he is either on time next time, or I give up
23:35:18 <TrueBrain> so I am not reall yin the modd to do anything :p
23:35:53 <glx> well the diff can be used to generate successive crash.bin ;)
23:35:56 <TrueBrain> the pure C function should receive Team *t and Unit *u
23:36:11 <Xaroth> TrueBrain: minor details :)
23:36:29 <TrueBrain> please obey coding style
23:36:58 <Xaroth> I like the looks of the \n tho, when I'm trying to figure things out :P
23:37:14 <TrueBrain> Team *t - Team_Get_ByIndex(u->team - 1);
23:37:25 <TrueBrain> but keeping coding style immediatly, helps ...
23:37:29 <TrueBrain> like missing space there
23:37:46 <glx> and you can't declare variables in the middle :)
23:37:48 <TrueBrain> you keep on insisting your own coding style in your mockups
23:37:56 <TrueBrain> so I Think we are better of to wait for your non-mockups :p
23:38:35 <TrueBrain> ucsip == 0 is invalid, ucsip.csip == 0 would work
23:38:47 <TrueBrain> any compiler would tell you too ;)
23:39:18 <TrueBrain> and yes, those functions are that simple :p
23:40:19 <Xaroth> good, now to clean it up
23:41:29 <glx> return value of RemoveFromTeam is never used it seems
23:44:28 <TrueBrain> lets keep it for now, and later on review that .. who knows what new functions we uncover ;) :)
23:45:51 <TrueBrain> btw, I assumed var08 was something like 'size'
23:45:56 <TrueBrain> it does behave like that
23:46:36 <glx> but 2 usages are not enough to be sure
23:46:50 <TrueBrain> I had the same problem ;)
23:46:56 <TrueBrain> although 'members' was obvious with 1 usage :p
23:48:42 <glx> naming 0x379A was easy too
23:48:53 <glx> ,...if (emu_get_memory16(emu_ds, 0x00, 0x379A) == 0x0) goto l__042B;
23:49:20 <TrueBrain> you found the logging mechanism
23:49:33 <glx> yes and my diff enables it
23:51:16 <glx> 0x379E is also an on/off variable, but I can't determine for what
23:54:47 <TrueBrain> pff .. it keeps finding new shit
23:55:06 <glx> when 0x379E is not 0, something uses 0x60AE /*!< "Forced end." NULL terminated. */
23:57:43 <TrueBrain> log contains non-ascii shit
23:59:00 <TrueBrain> it even resolves entries in mouse handling
23:59:15 <Xaroth> makes sense, stops you from wasting all that memory space on descriptive log messages
continue to next day ⏵
