IRC logs for #opendune on OFTC at 2009-11-22
⏴ go to previous day
00:27:34 <DorpsGek> SVN: glx (r560) -Fix (r534): stuff ordered was never delivered to starport
01:26:19 <DorpsGek> SVN: glx (r561) -Add: figured out a few variables
11:17:57 <TrueBrain> StarPort never allows more than 10 units to be available
11:37:44 <TrueBrain> damn, glx made a lot of tiny mistakes, which have devistating consequences :(
12:01:09 <TrueBrain> like every N ticks you lost all your money :p
13:26:53 <TrueBrain> good morning glx :)
13:27:01 <TrueBrain> I have some good news for you, and some bad news .. what you want first? :)
13:35:07 <TrueBrain> I found a few more issues with GameLoop_House, so I walked over the whole function; you made a few minor mistakes, which had some pretty nasty effects ;)
13:35:18 <TrueBrain> example, you had a max() what should have been a min(), causing you to lose your money every N ticks :p
13:35:41 <TrueBrain> either way, I hopefully fixed most of it, and I wanted to ask you to walk it over to see if I didn't make a silly mistake :)
13:36:09 <TrueBrain> there is a lot of other junk in there too, I have been fixing a few thingies all around the place
13:36:36 <TrueBrain> (and naming and renaming variables and stuff)
13:37:18 <TrueBrain> one relative important thing: Unit_Get_ByMemory always returns a valid pointer, so checking afterwards if it is NULL is useless ;)
13:44:13 <glx> -,...,...,...ucsip.s.ip = g_global->unitStartPos.s.ip + u->index * sizeof(u);
13:44:13 <glx> +,...,...,...ucsip.s.ip = g_global->unitStartPos.s.ip + u->index * sizeof(Unit);
13:44:41 <glx> it's a search and replace error ;)
13:44:52 <TrueBrain> yeah .. and one of big consequents ;)
13:45:15 <TrueBrain> the most annoying one was where you switched the 'if' and 'else' case of starport new stuff thingy :p
13:45:28 <TrueBrain> if it wasn't -1, it was made 1, and else ++ (which made it 0, not-available)
13:45:36 <TrueBrain> so my starport no longer worked :p
13:46:58 <glx> ha yes, I had some problems with tests
13:50:03 <TrueBrain> either way, any comments on my patch?
13:58:13 <glx> -,...,...if (h == NULL) return;
13:58:13 <glx> +,...,...if (h == NULL) break;
13:58:33 <glx> not needed as now you fix the location of the latest test ;)
13:58:49 <TrueBrain> true; still, if someone adds something at the bottom, it won't be called ;) So this is more 'nice' :)
14:00:18 <glx> indeed I made some mistakes :)
14:01:23 <glx> I had a quick look at f__1A34_21E0_001A_547E
14:01:33 <glx> it does something about harvesters
14:01:42 <glx> and some strange things too
14:03:31 <glx> like calling emu_Structure_GetLinkedUnit() for structures and units and checking result->type == 0x10
14:04:09 <glx> when called for structures it's ok, result is a unit and 0x10 is a harvester, but for units it's not good I think
14:22:42 <glx> ho for units it loops over carryalls, so checking for linked 0x10 works
14:26:38 <TrueBrain> I renamed the linked stuff to LinkedID, as it can be a structure or a unit :p
14:26:46 <TrueBrain> when things are in carry-alls, units carry a unit in their LinkedID :)
14:27:06 <DorpsGek> SVN: truebrain (r562) -Fix: various of fixes in GameLoop_House(), small code changes and a bit of code police
14:27:26 <TrueBrain> only ... it is a bit guessing what type is in the unit :p
14:28:05 <glx> well for this function I know it ;)
14:28:46 <glx> so it seems return true if a structure has linked harvester or a carryall has linked harvester or ???
14:28:54 <glx> that's what I have for now
14:30:33 <glx> not enough to name it yet
14:30:57 <glx> as GameLoop_House doesn't care about the return value
14:37:52 <glx> yeah I know what f__0FE4_0333_000F_2B73() does \o/
14:48:42 *** Alberth has joined #openDune
14:50:26 <Alberth> TrueBrain: great stuff you are writing in the forum, I really love reading it. Too bad I have little time atm to look at the code.
14:51:36 <TrueBrain> Alberth: np, and tnx ;)
14:52:38 <TrueBrain> bah, just repaireed a bike .. my hands are very dirty now :(
14:53:18 <TrueBrain> okay ... what next .. hmm ..
14:53:26 <Alberth> and so is your keyboard now :)
14:53:31 <TrueBrain> yeah ... who cares :p
14:53:44 <TrueBrain> I wonder ... split script functions per category, or not?
14:54:06 <TrueBrain> (so script_structure.c, script_unit.c, ...
14:55:55 <TrueBrain> omg ... some functions really abuse where scripts are in relevance to the struct it comes from (Structure, Unit, ..)
14:56:27 <Alberth> sounds like the old widget system :p
14:56:46 <TrueBrain> but how to solve that in nice C ...
14:57:57 <TrueBrain> as, stupid enough, 'scriptDelay' is not inside the script engine
15:04:07 <TrueBrain> any suggestions, anyone? :)
15:05:56 <TrueBrain> *(((uint16 *)script) - 1) = delay;
15:09:23 <TrueBrain> don't forget a newline in unit.c ;)
15:09:24 <glx> if it's the goto l__0396 or the emu_ax = 1
15:09:40 <TrueBrain> I will check for you in a sec :)
15:09:57 <glx> other where easy to guess ;)
15:10:08 <TrueBrain> a bit of coding style: please do not assign the value to 'u' directly, but delay it one line (I know it sounds silly, but it really improves readability :p)
15:13:44 <TrueBrain> first missing jump goes to 36C, which is the begin of the line of the next missing jump
15:13:52 <TrueBrain> well, the 'cmp' before it
15:14:21 <TrueBrain> the 37F missing jump is the cmp before the next missing jump too
15:14:35 <TrueBrain> the 391 is a jump to emu_ax = 1
15:14:56 <glx> ok I got it correct for all :)
15:16:42 <glx> my guessing skills are very good sometimes ;)
15:18:22 <TrueBrain> check out emu_Unit_GetHouseID()
15:18:26 <TrueBrain> there is a reason it is a wrapper :)
15:18:38 <TrueBrain> in this case it should not matter
15:20:38 <TrueBrain> Function is a bit weird btw, it just checks if there is any unit of that type and house which is on the map :p
15:20:49 <TrueBrain> oh, in that case the GetHouseID wrapper is important I guess :)
15:21:07 <TrueBrain> I would name it like: Unit_IsTypeOnMap
15:21:14 <glx> there's no gap in unitArray so no possible NULL
15:21:22 <TrueBrain> just check the wrapper :)
15:21:26 <TrueBrain> really .. just do so ;)
15:26:11 <TrueBrain> looks fine to me :)
15:26:53 <DorpsGek> SVN: glx (r563) -Add: named and C-ified one more function
15:27:42 <DorpsGek> SVN: truebrain (r564) -Add: C-ify the first script function, to outline how it can be done
15:27:55 <TrueBrain> stupid enough, 'delay' is not '0' for all types :s
15:28:34 <DorpsGek> SVN: truebrain (r565) -Fix (r564): forgot to remove define from header
15:29:53 <glx> some progress for f__1A34_21E0_001A_547E: return true if a structure has linked harvester or a carryall has linked harvester or an harvester is on the map or ???
15:30:09 <TrueBrain> sounds reasonable so far :p
15:30:26 <glx> then it does something with the first refinery
15:30:27 <TrueBrain> remember you get a free new harvester when yours is destroyed
15:31:00 <Alberth> the last one you own, I think
15:31:15 <glx> looks exactly like that :)
15:31:16 <TrueBrain> hmm .. it does explain one thing .. when I deviate an enemy harvester, he gets a new one, and ends up with 2 :p
15:31:34 <Alberth> yes, even Dune 2K has that :)
15:31:45 <TrueBrain> nasty way to help your enemy :p
15:31:52 <TrueBrain> never played dune2k :(
15:32:36 <glx> and "Harvester is heading to refinery" is displayed at one moment
15:32:53 <glx> so clearly get a new harvester if none left
15:33:35 <Alberth> TrueBrain: you shouldn't play with such nasty weapons :p
15:33:43 <DorpsGek> SVN: truebrain (r566) -Codechange: rename a variable to comply with coding style
15:34:13 <TrueBrain> glx: then we can debate if it is a bug or not, that if your harvester gets deviated you should get a new one or not ;)
15:34:44 <glx> well if it's deviated, you don't have harvester left
15:35:34 <TrueBrain> f__2BB4_0004_0027_DC1D <- rand()?
15:35:39 <TrueBrain> glx: but only for a short moment
15:36:13 <TrueBrain> I also suspected f__2537_000C_001C_86CB() of being a random function
15:36:19 <TrueBrain> randRange() in fact
15:36:28 <Alberth> so what happens when the enemy sells/destroys that harvester?
15:36:50 <TrueBrain> you can't sell it, but only at that point you no longer have a harvester :)
15:38:36 <TrueBrain> okay, that was no english
15:38:39 <TrueBrain> 1) you can't seel it
15:38:47 <TrueBrain> 2) when it gets destroyed, only then you get a new one
15:39:36 <TrueBrain> both functions have to be some kind of randomizer
15:39:42 <TrueBrain> the first giving a value between 0 and 255
15:39:52 <TrueBrain> the second between the two ranges .. but they are both not related to eachother in any way
15:39:58 <TrueBrain> and use completely different algorithms
15:40:30 <Alberth> to make them independent of each other or because they implemented it twice :)
15:40:53 <TrueBrain> possible one is a standard borland library function
15:40:56 <TrueBrain> and the other is defined by them
15:43:04 <glx> oh var 76A2 is mapSeed from scenario
15:43:56 <TrueBrain> so it indeed is a custom random generator :)
15:44:11 <TrueBrain> the complexity of it is too much for me for this day, so I will just leave it as it is :p
15:46:29 <TrueBrain> emu_ax * script->stack[script->stackPointer] / 256;
15:46:39 <TrueBrain> in other words: get a random value with a max
15:52:46 <TrueBrain> some functions I understand what they do, but I have no clue what they do :p
15:55:02 *** ChanServ sets mode: +o Xaroth
15:57:42 <TrueBrain> take for example 'f__0EDB_0006_002F_CECA'. It reads from the script code a value, then it pushes 3 more values from the script stack, then it runs a sprintf over it
15:57:53 <TrueBrain> and then I think it displays this string to the user
16:13:39 <TrueBrain> okay, for scripts a unitid/structureid gets some high bits set to seperate them
16:14:21 <TrueBrain> the unit-script has a function which gets the distance from a unit/structure to currentStructure
16:14:35 <TrueBrain> I guess there are scripts which set that value ..
16:17:20 <glx> hmm how to name f__1A34_21E0_001A_547E
16:17:48 <TrueBrain> HarvesterGiveNewWhenNoLongerHaveOne :p
16:18:11 <glx> and why does it return a bool when the only caller doesn't care about the result
16:18:20 <TrueBrain> EnsureHarvesterAvailable
16:19:06 <glx> they really didn't have code police checker ;)
16:21:17 <glx> hmm I'll go for House_EnsureHarvesterAvailable then
16:29:30 <TrueBrain> hmmm .... this function is failing asserts (for good reason)
16:33:26 <DorpsGek> SVN: truebrain (r567) -Add: a few more Script_General functions, and fixed a few wrongly named functions
16:33:57 <TrueBrain> turned out at 394E is either a structure or unit, depending on the game loop ;)
16:34:28 <TrueBrain> k .. this works .. so the rest of the script functions are 'simple' things to do :)
16:34:44 <TrueBrain> mostly as they have a single caller :)
16:36:56 <Xaroth> <+glx> hmm I'll go for House_EnsureHarvesterAvailable then << sounds good
16:37:15 <Xaroth> and the return value is quite useful at some point i bet :P
16:37:26 <TrueBrain> how much do you want to bet on it
16:37:49 <Xaroth> but as i said, at some point :P
16:38:35 <TrueBrain> Xaroth: you got me request to add usernames to reports like above?
16:39:04 <Xaroth> k, i'll make a note on it
16:39:09 <Xaroth> and see what I can do tonight
16:39:22 <Xaroth> at my grandpa's atm, was his birthday last week so paying a visit etc
16:39:49 <TrueBrain> well, if I can give priority to your tasks, I rather have you finishing tile.c ;) It becomes more and more annoying touse the emulated layer :p
16:39:54 <TrueBrain> concratz :) And enjoy ;)
16:40:26 <Xaroth> think I only need one more named function, but I'm sure I can upload
16:40:33 <Xaroth> and add that one at a later point
16:44:00 <Xaroth> will be back from my phone at some point probably :)
16:47:16 <TrueBrain> MrFlibble did a nice job on updating the scenarios
16:50:57 <glx> return value is inconsistent
16:53:35 <glx> of House_EnsureHarvesterAvailable
16:53:46 <TrueBrain> ah; if it is not used, just ignore :)
16:57:44 <glx> hmm svn up shows a "A", but it miss a "U" ;)
16:58:39 <TrueBrain> k, I now made a seperate Developers Blog subforum
16:58:43 <TrueBrain> where normal users can't post, but can reply
17:01:53 <glx> src/script_general.c: In function 'Script_General_GetDistance':
17:01:54 <glx> src/script_general.c:74: erreur: 'Unit' undeclared (first use in this function)
17:02:23 <TrueBrain> stupid Netbeans does not always change the mtime of files ...
17:02:59 <DorpsGek> SVN: truebrain (r568) -Fix (r567): missing includes
17:03:00 <glx> and my previous comment was about missing generate run ;)
17:03:58 <DorpsGek> SVN: truebrain (r569) -Fix (r567): a script failed to be triggered on my working copy .. I wonder if it would have helped if I executed it
17:05:36 <TrueBrain> I have a script which makes everything how it should be
17:05:40 <TrueBrain> but ... I do need to execute it :p
17:33:55 <TrueBrain> if (s->type == STRUCTURE_HEAVY_VEHICLE) continue; <- ==? Not =!? (didn't check the asm)
17:34:27 <glx> -,...emu_cmpb(&emu_get_memory8(emu_es, emu_bx, 0x2), 0x4);
17:34:27 <glx> -,...if (emu_get_memory8(emu_es, emu_bx, 0x2) == 0x4) goto l__2234;
17:34:42 <TrueBrain> depends on where that goto goes to :p
17:35:00 <TrueBrain> even more as a CY has in his LinkedID a structure
17:36:11 <TrueBrain> the rest looks sane, just that piece not ..
17:37:46 <TrueBrain> means that making a rocket turret would result in no new harvester
17:41:00 <TrueBrain> it would make sense if the value was '8'
17:42:03 <TrueBrain> someone should confirm that I guess :)
17:42:20 <TrueBrain> but that is very difficult ...
17:43:01 <glx> that or StructureType is buggy :)
17:43:17 <TrueBrain> doubtful, as I already added code which handles CY :)
17:46:32 <TrueBrain> but this also means that you get a new harvester while you are making one
17:47:11 <TrueBrain> which is, in any possible way, odd
17:48:11 <glx> well that confirm a possible bug :)
17:48:44 <glx> <@TrueBrain> but this also means that you get a new harvester while you are making one
17:49:20 <glx> because the check skips heavy vehicle factory
17:49:28 <TrueBrain> that was why I said that
17:50:29 <glx> added a XXX: on this line
17:50:55 <TrueBrain> while building a rocket turrent, I still get a new harvester
17:51:48 <TrueBrain> by just doing so :)
17:52:27 <TrueBrain> k, when I am building a harvester it is not giving me a new one
17:59:28 <TrueBrain> it really doesn't make sense ...
18:00:05 <TrueBrain> when I add printfs, it clearly shows it shouldn't be working :p
18:01:21 <glx> well it tries to get a unit
18:01:49 <TrueBrain> yes, but structures and units are aligned for most part
18:02:15 <glx> Structure_GetLinkedUnit calls emu_Unit_Get_ByIndex
18:02:34 <glx> so it won't return a structure I guess
18:03:06 <glx> but it can return a random unit
18:04:08 <glx> well the unit with the same ID as the current structure being built
18:05:02 <TrueBrain> okay, confirmed; when you are building a harvester it still brings a new one
18:05:29 <TrueBrain> so, correct code would be now:
18:05:30 <TrueBrain> if (!g_dune2_enhanced && s->type == STRUCTURE_HEAVY_VEHICLE) continue;
18:05:37 <TrueBrain> if (g_dune2_enhanced && s->type == STRUCTURE_CONSTRUCTION_YARD) continue;
18:05:59 <TrueBrain> and a comment like /* ENHANCEMENT -- Dune2 checked the wrong typed to skip. LinkedID is a structure for a Construction Yard */
18:06:06 <TrueBrain> and don't forget to add an entry in enhancement.txt
18:09:49 <TrueBrain> a very stupid bug ..
18:13:45 <TrueBrain> "wrong typed to skip." <- hiih, you don't have to copy my spelling errors :p
18:14:03 <glx> yes I saw it after the diff, already fixed
18:14:25 <TrueBrain> I am going to blog this :p
18:20:00 <glx> btw I think it doesn't check if you ordered a harvester via starport
18:20:14 <TrueBrain> it loops all the vehicles ;)
18:20:31 <TrueBrain> oh, only the carry-alls
18:20:34 <TrueBrain> no, you are absolutely right
18:20:49 <TrueBrain> well, it depends on how exact IsTypeOnMap is
18:20:59 <TrueBrain> the vehicles created to bring in via starport are really there
18:21:23 <TrueBrain> and not flagged with 0x0004
18:21:27 <TrueBrain> so that most likely detects it
18:21:49 <DorpsGek> SVN: glx (r570) -Add: named and C-ified one more function
18:54:27 <DorpsGek> SVN: truebrain (r571) -Fix (r570): remove the @define line to make the decompiler happy
19:01:42 <Alberth> (05:59:58 PM) TrueBrain: where normal users can't post, but can reply <-- Confirmed: "You can reply to topics in this forum", in particular, no new posts, no edit of my posts, and no attachments (and no delete, but an other forum also does not allow that so I guess that is expected :p )
19:01:44 <Xaroth> TrueBrain: I see you made a devblog forum :P
19:36:59 <TrueBrain> yeah, you weren;t doing it :p :p
19:42:24 <glx> Xaroth: how is your emu_Tile C-ification?
19:44:13 <Xaroth> glx: not where my focus is atm, which is the missus
19:44:44 <TrueBrain> what does the missus have what we dont?
19:45:03 <Xaroth> I mean.. what more do you want?
20:31:22 * TrueBrain buys glx a faster upload
20:31:53 <glx> I could stop the torrents too
20:32:14 <glx> they use ~30% of the bandwidth
20:33:29 <TrueBrain> the JIT really can't resume anymore :p Ghehe :)
20:33:43 <TrueBrain> well, it can do enough
20:33:47 <TrueBrain> but then it goes start acting WEIRD
20:34:54 <DorpsGek> SVN: truebrain (r572) [JIT] -Add: mapped another 5 functions (crash-bins provided by glx)
20:35:04 <DorpsGek> SVN: truebrain (r573) -Update (r572): update decompiled code
20:36:49 <glx> hmm 2 crash.bin unhandled ?
20:37:32 <glx> weird there's still 2 unresolved calls
20:38:58 <TrueBrain> Lines todo: 102,446/110,952
20:38:59 <TrueBrain> Functions todo: 883/1066
20:40:34 <TrueBrain> it is FROM 2419 TO 24DA
20:41:25 <TrueBrain> and your crash.bin is for TO 2419
20:43:29 <TrueBrain> or at least, it appears that way .. as when I run it, it really tells me it is there :p
20:44:26 <TrueBrain> nah, I can do that for you :)
20:46:06 <TrueBrain> if I know how to trigger the function :p
20:46:23 <glx> starport delivery for example :)
20:47:34 <TrueBrain> k, you can make them, I can't get the darn function called :p
20:53:19 <DorpsGek> SVN: truebrain (r574) [JIT] -Add: mapped another 4 functions (crash-bins provided by glx)
20:53:36 <DorpsGek> SVN: truebrain (r575) -Update (r574): update decompiled code
21:02:52 <Xaroth> some warnings in emu_structure.c and house.c regarding uint16 to uint8
21:03:23 <TrueBrain> solve them, or give more info, or go back to the missus :p
21:03:46 <glx> most are related to houseID
21:04:05 <glx> and we know they are safe ;)
21:04:50 <TrueBrain> hmm .. there is a small chance the "insufficient spice storage" is correct where it is ... although still odd
21:05:33 <TrueBrain> no, it is never correct :p GameLoop_Structure is called before it, setting that variable :p
21:05:45 <TrueBrain> so who ever owns the last structure is fucked :p
21:06:11 <DorpsGek> SVN: glx (r576) -Codechange: some simplification and usage of enum values
21:06:47 <TrueBrain> usage of enums, and you intrudoce a magic 0x8000 ;)
21:07:35 <TrueBrain> I know 0x8000 means STRUCTURE when attached to an ID
21:07:37 <TrueBrain> mostly used in scripts
21:07:49 <TrueBrain> I believe 0x4000 and 0x2000 are in use too
21:08:22 <glx> it's the destination of the "delivered" unit
21:08:42 <TrueBrain> the structureID, yes
21:08:51 <TrueBrain> and the 0x8000 marker is so it knows later on it was a structure, not a unit
21:08:55 <TrueBrain> or at least, for scripts :)
21:10:19 <DorpsGek> SVN: truebrain (r577) -Add: credit capping is done outside the house-loop in Dune2, allowing you to store more credits than you should be able to.
21:10:30 <glx> ,...,...,...,...emu_push(0);
21:10:30 <glx> ,...,...,...,...emu_push(UNIT_HARVESTER);
21:10:30 <glx> ,...,...,...,...emu_push(h->index);
21:10:30 <glx> ,...,...,...,...emu_push(emu_cs); emu_push(0x07E6); emu_cs = 0x1A34; f__1A34_232C_0011_B7DE();
21:10:40 <glx> destination is 0 for this harvester
21:10:50 <glx> probably a special meaning
21:11:01 <TrueBrain> I guess, as I was only talking about the 0x8000 mask ;)
21:11:09 <TrueBrain> which 167E functions use/set/get
21:11:27 <tneo> TrueBrain, did you change anything? with the current r I still get the "info" messages about concrete in level 3
21:11:42 <TrueBrain> you mean those grey thingies?
21:11:59 <TrueBrain> as far as I am aware, we didn't touch that code ...
21:12:07 <TrueBrain> I also hav eno idea what code triggers then, so I can't be sure :p
21:12:14 <TrueBrain> you should get them only once ..
21:12:26 <TrueBrain> (if you have hints disabled and enable them later, you get them where ever you are)
21:13:29 <tneo> hints are enabled and have been ever since, but I now notice this behavior in level 3
21:14:03 <TrueBrain> glx: '0' is a special value yes
21:15:13 <Xaroth> any comments before i commit?
21:15:56 <TrueBrain> emu_ax = Tile_IsValid(tile) ? 0x1 : 0x0; <- remove the '0x' part
21:16:07 <Xaroth> you were the one who told me to use 0x :P
21:16:15 <TrueBrain> sometimes, yes, sometimes, no
21:16:20 <TrueBrain> now your job is to figure out which one where
21:16:59 <TrueBrain> so upload a new patch :p
21:17:55 <TrueBrain> + if (distance_x > distance_y) { return distance_x + (distance_y >> 1); }
21:17:59 <TrueBrain> after a { comes a \n
21:18:06 <TrueBrain> so pick one .. remove the {}, or add the \n
21:18:11 <TrueBrain> not this weird combo of uglyness :p
21:18:25 <TrueBrain> and change >> 1 to / 2 please :)
21:19:07 <TrueBrain> if you say done, make sure you uploaded a new patch too :p Ghehe :)
21:19:27 <TrueBrain> I read done, I hit F5, see no change, think: huh? :p :p
21:19:39 <Xaroth> hence the 'refresh' :)
21:19:44 <TrueBrain> Xaroth: okay, I was in fact more suggesting to remove the {}
21:19:54 <TrueBrain> and that you change one >> 1 to a /2 .. that is just weird :)
21:20:08 <Xaroth> yeh, noticed that after i upped it
21:21:06 <TrueBrain> "12 bit packed coordinate struct."
21:21:11 <TrueBrain> "12 bits packed tile."
21:21:20 <TrueBrain> "packed 12 bit tile information"
21:21:33 <TrueBrain> 20 lines, 3 ways to say the same thing :) I somehow dislike such inconsistancies :)
21:21:49 <TrueBrain> for sure it should be plural, as 12 is not one :)
21:22:12 <TrueBrain> I would go for the "12 bits packed tile", but any construct is fine by me, as long as they are the same :)
21:22:47 <TrueBrain> "Adds two coordinates together." <- Adds two tiles together
21:24:07 <TrueBrain> tneo: was it maybe the first time you build concrete?
21:24:39 <tneo> every building is giving those hints
21:25:35 <Xaroth> [@TrueBrain]: for sure it should be plural, as 12 is not one :) << then why do people call it a 16-bit processor, or a 64-bit os ;)
21:26:05 <TrueBrain> and at least they are consistant :p
21:26:24 <Xaroth> anyways, any more remarks?
21:26:29 <Xaroth> i'm redoing the coments where possible
21:26:48 <TrueBrain> the rest looks okay, but please upload when you are done :)
21:27:22 <Xaroth> * Packs a 32 bits tile struct into a 12 bits packed format. << makes sense? or should I really lay off the dope?
21:27:51 <TrueBrain> you used yourself that the most, and it makes the most sense in my opinion
21:28:03 <glx> don't forget to remove then from function_names.txt
21:29:32 <TrueBrain> tneo: I can reproduce that problem, so confirmed ... now we need to figure out WHY it happens :s
21:31:04 <Xaroth> even removed them from function_names as glx requested
21:31:26 <Xaroth> because if that requires even more work, i'll continue tomorrow, seeing the missus is getting annoyed i'm spending too much time behind the pc
21:31:32 <Xaroth> or its good enough, and i can commit :)
21:31:41 <TrueBrain> so what can we do to keep you here any longer ... ;)
21:31:57 <Xaroth> i feel even more loved now :P
21:32:11 <tneo> no need for mantis then?
21:32:28 <TrueBrain> I am out of ideas Xaroth, so I guess it is fine :p
21:32:31 <TrueBrain> tneo: nope, working on it now :)
21:32:35 <Xaroth> ideas to keep me here? :P
21:32:51 <TrueBrain> tneo: but it is a bit slow going, as I need to reply O1 every attempt :p
21:32:55 <TrueBrain> Xaroth: yeah .. so just commit it :p
21:33:04 <Xaroth> btw, what prop to use for the $Id$ stuff?
21:33:31 <TrueBrain> svn:eol-style native
21:34:01 <glx> right I never set them (autoprops power) :)
21:34:46 <glx> once it's commited I'll fix src/*.c using them
21:34:46 <Xaroth> -Add: C-ified multiple Tile-related functions
21:34:56 <Xaroth> er.. smart move.. wrong input screen
21:34:59 <TrueBrain> Xaroth: you have to type that in your commiter :p
21:35:09 <TrueBrain> glx: k, then I won't ;)
21:35:41 <Xaroth> gah, pre-commit hook is bitching o_O
21:35:51 <TrueBrain> no, it is telling you you made mistakes :p
21:36:17 <glx> there's no setting to remove trailing whitespaces
21:36:27 <TrueBrain> be happy the pre-commit tells you EXACTLY what lines are in error
21:36:45 <TrueBrain> neither in Netbeans, yet I rarely make a mistake with it :p
21:37:14 <glx> I'm usually careful with that, but sometimes I just miss one :)
21:37:32 <TrueBrain> that happens to all of us :) Hence the precommit checker ;)
21:37:53 <DorpsGek> SVN: xaroth (r578) -Add: C-ified multiple Tile-related functions
21:38:26 <Xaroth> DorpsGek actually out-notified tortoisesvn :o
21:38:35 <Xaroth> anyways, off to bed now
21:39:16 <TrueBrain> say hi to the boobs \9\9\9\9\9\9 missus
21:43:33 <TrueBrain> glx: enjoy rewriting a few of those statements :) Should make a lot much more readable :)
21:50:38 <TrueBrain> tneo: I had to check, but DOSBox does it too
21:55:31 <DorpsGek> SVN: truebrain (r579) -Update: sort the include headers in decompiled/decompiled.h
22:02:14 <TrueBrain> ah, so I am not the only one :p
22:02:53 <TrueBrain> you added ScriptEngine to airunit.h :p
22:03:05 <DorpsGek> SVN: truebrain (r580) -Fix (r579): now missing include for airunit.h
22:08:20 <TrueBrain> glx: I assume you also take care of the abs() warning in tile.c? :)
22:11:18 <DorpsGek> SVN: truebrain (r581) -Add: finally decided to name Structure+0x54 'animation', as that is what it seems to do. Added Script_Structure_GetAnimation while at it
22:11:25 <TrueBrain> oeh, that is fast .. let me read :)
22:13:24 <TrueBrain> does it also work? :)
22:13:59 <TrueBrain> nope, that works only for OpenTTD :p
22:19:10 <glx> read, re-read, checked, re-checked, it should work
22:20:06 <TrueBrain> did you test it? :)
22:20:25 <TrueBrain> starting a new campaign will immediatly show you if it contains a flaw :)
22:20:55 <TrueBrain> well, I was refering to the scenario load code :p
22:21:05 <TrueBrain> so you mean your patch doesn't work?
22:24:27 <TrueBrain> code looks fine .. so I guess you need to check every blob one by one :s
22:25:10 <glx> would mean Xar.oth code is broken
22:25:58 <TrueBrain> I will help you look in a sec .. I have one more patch in the piep
22:27:02 <DorpsGek> SVN: truebrain (r582) -Add: C-ified Script_Structure_NoOperation() (yes, it does nothing)
22:29:40 <TrueBrain> your patch seems to work correct here ..
22:30:51 <glx> with gcc my savegame runs fine
22:31:01 <glx> maybe MSVC does something wrong
22:31:21 <TrueBrain> not such shit again :(
22:32:08 <glx> oh we have 3 lifes to complete a mission?
22:32:24 <TrueBrain> carry-alls do not appear
22:35:44 <TrueBrain> without your patch it just APPEARS
22:36:28 <glx> hmm MSVC builds just closes magically :/
22:37:42 <TrueBrain> k, it is that certain commit that is in error
22:38:23 <TrueBrain> that one person that went to bed after committing it :p
22:39:24 <glx> oh MSVC generates crash.bin indeed
22:47:42 <glx> hmm emu_Tile_GetPosXY() is not exactly the same
22:47:59 <TrueBrain> it should be 'good enough'
22:48:40 <TrueBrain> but lets see if that fixes the problem
22:55:31 <TrueBrain> now H1 has no units
22:56:41 <glx> oh I was not using latest version
22:57:39 <TrueBrain> ah, units are there, they just don't show :p
22:58:35 <TrueBrain> r582 introduces noop :p
22:59:01 <glx> but with gcc the games seems to work correctly
22:59:03 <TrueBrain> I have the idea GetX is in error .. not sure how yet
23:00:14 <TrueBrain> something very weird is going on :p
23:01:42 <glx> and MSVC crashes (crash.bin) during windtrap building
23:02:09 <TrueBrain> yes, something goes wrong ...
23:02:16 <TrueBrain> when I access tile.s.x, it is fine
23:02:23 <TrueBrain> when I access the same via Tile_GetX(tile)
23:02:29 <TrueBrain> but printf shows the same output
23:05:22 <TrueBrain> when I add additional printfs, it works again :)
23:07:10 <TrueBrain> and valgrind still refuses to work :p
23:08:50 <TrueBrain> what the .. are we missing :)
23:09:09 <glx> but the weird thing is MSVC triggers an unresolved jump while gcc works
23:09:24 <TrueBrain> other moment of interrupting
23:10:52 <glx> ok the triggered jump seems consistent, I can add a breakpoint just before it :)
23:12:35 <TrueBrain> only if you can do more work there, like checking what it has to do with Tile_ :)
23:14:21 <glx> there's clearly something related to Time_GetX and Tile_GetY ;)
23:14:51 <TrueBrain> they behave very odd ...
23:15:01 <TrueBrain> like they alter the data or something
23:16:54 <TrueBrain> problems are always in very very small corners, not?
23:17:09 <TrueBrain> and then I mean corners of about 4 bits
23:17:14 <TrueBrain> divided in 2 x 2 bits
23:17:37 <TrueBrain> fucking hell .. we could have spend ages trying to find this ...
23:18:38 <DorpsGek> SVN: truebrain (r583) -Fix (r578): avoid using uninitialized data, it rarely does what you want. While at it, play a bit of coding police in (emu_)tile.c
23:20:33 <DorpsGek> SVN: truebrain (r584) -Codechange (r583): save before commit (useless newline BE GONE! :p)
23:21:05 <TrueBrain> glx: it was something Xaroth could have no idea about, and we should know by hearth ;) 'tile32 tile' doesn't mean tile.tile == 0 ;)
23:21:16 <TrueBrain> in fact .. the chances are next to 0 that is the case :p
23:22:09 <DorpsGek> SVN: truebrain (r585) -Fix (r583): I was overprotected in one case
23:23:07 <TrueBrain> also btw completely explains the difference between gcc and MSVC :)
23:23:15 <TrueBrain> your patch works btw
23:23:46 <TrueBrain> and now I am off to bed :) Night!
23:39:53 <DorpsGek> SVN: glx (r586) -Codechange: replaced emu_Tile_XXX with Tile_XXX in C-ified code
continue to next day ⏵