IRC logs for #opendune on OFTC at 2009-11-17
            
00:00:32 <SmatZ> you can even use
00:00:46 <SmatZ> void f(int a, int b, uint[2] xy)
00:00:48 <SmatZ> or
00:00:53 <SmatZ> void f(int a, int b, uint *x, uint *y)
00:01:05 <Xaroth> I miss my ref keyword from C# :P
00:01:16 <SmatZ> arrays are always passed by pointer
00:01:49 <SmatZ> no references = readable code :)
00:02:22 <Xaroth> heh
00:02:39 <Xaroth> well the keyword makes it a bit readable as it's a clear indicator
00:02:40 <glx> ho nice a typo broke it indeed
00:02:44 <SmatZ> or better: references => worse readable code
00:02:54 <Xaroth> but at the same time, it doesn't :P
00:03:05 <SmatZ> if you have (in C++)
00:03:15 <SmatZ> void f(int a, int b, int &d)
00:03:28 <SmatZ> and you modify "d" somewhere inside the function
00:03:36 <SmatZ> the caller will have its variable modified
00:03:49 <SmatZ> one can easily overlook that when modifying f() later
00:04:01 <Xaroth> true
00:05:09 * Xaroth crosses fingers
00:05:24 <SmatZ> :-)
00:06:15 <Xaroth> glx
00:06:17 <Xaroth> I think
00:06:17 <Xaroth> emu_push(emu_get_memory16(emu_ds, emu_bx, 0x2E5E));
00:06:17 <Xaroth> emu_push(emu_get_memory16(emu_ds, emu_bx, 0x2E5C));
00:06:25 <Xaroth> are also related to x/y coords
00:06:36 <glx> looks like a 32bit value
00:06:42 <Xaroth> 0C3A, search for AddTileDiff
00:08:12 <DorpsGek> SVN: glx (r501) -Fix (r500): a little mistake in a comment can lead to big compile failure
00:08:18 <Xaroth> woop
00:08:20 <Xaroth> r501
00:08:34 <glx> just a missing emu_ in an @name comment
00:08:56 <glx> => decompiler uses wrong name
00:09:00 <glx> => compile fails
00:12:37 <Xaroth> Good thing a LOT of code is called during savegame load :P
03:59:58 *** glx has quit IRC
08:20:47 <Xaroth> morning
08:21:47 <boekabart> morning
09:23:21 <TrueBrain> Xaroth: Distance really gets 2 tile32 as params ...
09:23:27 <TrueBrain> there is nothing else I can say about it
09:23:44 <TrueBrain> 6 + 8 is the first tile32, A + C is the second tile32
09:24:11 <TrueBrain> and as with every tile32, the first 16 bits is the x, the second 16bit is the y, but that are just internal details
09:26:43 <TrueBrain> "trust me, I'm a doctor"
09:27:40 <TrueBrain> Xaroth: and you never answered my question :(
09:31:31 <DorpsGek> SVN: truebrain (r502) [JIT] -Fix: one more problem found by planetmaker
09:32:50 <TrueBrain> that was a very large problem :p
09:33:36 <Xaroth> TrueBrain: what question?
09:33:50 <TrueBrain> [22:15] <TrueBrain> Xaroth: outstanding question: what to do with windtraps < 50%. The GUI shows production against current health, internal power calculation is capped at 50%
09:34:07 <Xaroth> i'd say follow gui
09:34:15 <Xaroth> less hp == less generated
09:34:32 <DorpsGek> SVN: truebrain (r503) -Update (r502): update decompiled code
09:35:26 <Xaroth> but I can see where they are comming from
09:35:43 <Xaroth> bit help for the player
09:35:48 <Xaroth> like many other 'balancing' they did
09:35:56 <Xaroth> they probably thought it'd be too hard for them
09:36:22 <Xaroth> <@TrueBrain> and as with every tile32, the first 16 bits is the x, the second 16bit is the y, but that are just internal details << what about the offset on tile32?
09:36:28 <TrueBrain> what about it?
09:36:59 <Xaroth> well the high bits actually hold the coordinates
09:37:39 <Xaroth> meaning that distance checking x1 vs x2 will be a distance of 256
09:37:45 <Xaroth> (top of my head)
09:37:48 <DorpsGek> SVN: truebrain (r504) -Add: Windtraps with a HP of below 50% still produced 50% power, despite what the GUI is telling you. Silly.
09:37:52 <Xaroth> plus any difference in the offsets
09:37:59 <TrueBrain> yes ... so?
09:38:09 <TrueBrain> what is your point here? :)
09:38:45 <Xaroth> that i don't think it's a tile32
09:38:47 <Xaroth> but a different structure
09:38:50 <Xaroth> struct, even
09:38:58 <TrueBrain> I am very sure it is a tile32, but feel free to proof me wrong :)
09:39:19 <TrueBrain> or you want me to proof me right? :p
09:40:14 <TrueBrain> as it is very simple: Unit and Structure both have at 0xA a tile32 (this I can proof, but read structure.c or unit.c to see for yourself)
09:40:31 <TrueBrain> 1A34.c, line 4272-4274
09:40:40 <TrueBrain> so again I tell you: both parameters are a tile32
09:40:46 <TrueBrain> :p :p
09:41:00 <TrueBrain> it also makes a lot of sense btw, for various of reasons
09:42:23 <Xaroth> then i wonder how the hell this thing has remained working :P
09:42:40 <TrueBrain> how do you use distance?
09:42:45 <TrueBrain> as absolute measure?
09:42:50 <TrueBrain> no; you use it as relative measure
09:42:55 <TrueBrain> so the true value doesn't really matter
09:43:30 <Xaroth> ah, no, i see what happened, it still did the same processing
09:43:32 <TrueBrain> besides, if you read 4x uint16, you still get the px + ox
09:43:43 <Xaroth> yeh
09:43:45 <TrueBrain> if you would have added 1 printf, you immediatly would have seen I was right
09:43:50 <TrueBrain> (mwhahahahaha)
09:44:11 <Xaroth> that would work if printf wouldn't hang the console/app :P
09:44:20 <TrueBrain> use mingw
09:45:21 <Xaroth> it's 'doable' to actually just do result = from + to; right?
09:45:32 <Xaroth> or is that too dirty :P
09:45:43 <Xaroth> doing addTileDiff
09:45:49 <TrueBrain> you have to do the x and y, and the divide
09:45:55 <TrueBrain> so I don't see how that would work
09:46:05 <Xaroth> different function atm
09:46:24 <TrueBrain> sorry, you made that very unclear :p
09:46:33 <Xaroth> yes, i know
09:46:52 <TrueBrain> tile32 result; result.s.x = from.s.x + to.s.x;
09:46:58 <TrueBrain> seems the most logic solution
09:48:09 <TrueBrain> of course you can do: result.tile = from.tile + to.tile, but that just seems wrong
09:48:11 <TrueBrain> very wrong
09:48:16 <Xaroth> yeh :P
10:28:44 <Xaroth> downside to this, I can't test the changes ... damned rdp
10:29:04 <Xaroth> 3 named functions left :o
10:29:35 <TrueBrain> pam pam
10:33:32 <Xaroth> DorpsGek: learn & operand!
10:36:30 <TrueBrain> are you losing it? :P
10:36:58 <Xaroth> losing what? :P
10:37:04 <TrueBrain> your mind? :p
10:37:16 <TrueBrain> money?
10:37:16 <Xaroth> that assumes I had one to begin with :P
10:37:57 <Xaroth> wait a minute, I got vc# on this rig
10:44:50 <Xaroth> emu_andw(&emu_ax, 0xFF00);
10:44:50 <Xaroth> emu_addw(&emu_ax, 0x80);
10:44:55 <Xaroth> emu_al = 0x80?
10:45:22 <TrueBrain> and as it is most likely a tile32, tile.whatwasit.ox = 0x80
10:45:31 <Xaroth> exactly
10:45:33 <Xaroth> i thought I was going mad
10:45:35 <Xaroth> but i wasn't..
10:45:41 <TrueBrain> you still are
10:45:58 <Xaroth> so i'm not going :)
10:46:14 <Xaroth> coding through rdp sucks arse btw.
10:46:16 <Xaroth> but it works
10:47:21 <TrueBrain> ghehe
10:47:26 <TrueBrain> maybe you should be doing your real work? :p
10:47:40 <Xaroth> nope, waiting for customer to reply
10:47:53 <TrueBrain> you really are a single-state machine, aren't you? :)
10:47:56 <Xaroth> and lunch soon, so starting on new stuff is useless.
10:48:11 <Xaroth> if I don't stick to one thing at a time neither will get done properly :)
10:50:30 <Xaroth> ugh, right, pointers
10:50:31 <Xaroth> gah
10:50:41 <Xaroth> too used to tile.something.something ...
10:51:11 <Xaroth> but with a pointer you obviously do tile->something.something
10:51:16 <Xaroth> took me 2 minutes -_-
10:51:35 <TrueBrain> poor boy
10:51:49 <Xaroth> meh :P
10:51:57 <Xaroth> @return comments not needed on voids right?
10:52:10 <TrueBrain> depends .. you want to return what with a void?
10:52:35 <Xaroth> nothing is being returned
10:52:42 <TrueBrain> so why do you ask? :)
10:53:01 <Xaroth> saves me having to change it later during the next proofreading session :)
10:54:56 <Xaroth> do parameters to a fucntion always get assigned 2 bytes?
10:55:09 <TrueBrain> your question is vague
10:55:38 <Xaroth> PackXY, it's getting the 2nd arg as uint8, the first as uint16
10:55:46 <Xaroth> while they are most obviously, x and y.
10:56:19 <TrueBrain> huh? Why is one uint8, the other uint16?
10:56:37 <Xaroth> hang on
10:56:40 <Xaroth> nevermind
10:56:44 <Xaroth> that was rdp being a twat
10:57:09 <Xaroth> long live relogin
10:57:43 <Xaroth> noticed it was emu_sss
10:58:03 <Xaroth> it retrieved a bit of display data from the other file, and overlapped that
10:58:12 <Xaroth> only.. 1 character to the left
10:59:21 <Xaroth> right, two more in 0F3F
11:03:34 <TrueBrain> pampampam
11:04:03 <Xaroth> http://devs.opendune.org/~xaroth/patches/new_tile_patch.patch
11:04:15 <Xaroth> time to go see when we go lucnh
11:04:21 <TrueBrain> enjoy
11:04:52 <TrueBrain> emu_Tile_GetPackX vs Tile_GetPackedX
11:04:53 <Xaroth> if I keep going by this rate tile.* will actually get done at some point :P
11:05:30 <Xaroth> we discussed that one last time as well :P
11:05:43 <TrueBrain> yes, you said you would rename them to GetPacked
11:05:47 <TrueBrain> now I read GetPack :p
11:05:56 <Xaroth> yes, didn't rename the emu_
11:06:02 <TrueBrain> bad Xaroth :p
11:06:15 <Xaroth> I had this feeling, that if I would just randomly rename stuff, that it wouldn't build anymore :P
11:06:16 <TrueBrain> I btw think Tile_Center should not be done by reference .. not sure ...
11:06:26 <TrueBrain> mass rename!!! :p
11:07:10 <Xaroth> heh, anyways, i was checking when there would be food
11:07:14 <Xaroth> keep the comments comming :)
11:08:16 <TrueBrain> no, Tile_Center is fine like this
11:08:20 <TrueBrain> we will see in time how useful it is :)
11:08:43 <TrueBrain> s/coordinates/tile/
11:09:22 <TrueBrain> The Origin <- you read too much Darwin
11:09:47 <TrueBrain> Tile_GetDistance <- please obey coding style
11:11:18 <TrueBrain> k, about all your emu functions, please add a few newlines:
11:11:32 <TrueBrain> make a block where ss+sp is read into local variables
11:11:37 <TrueBrain> make a block where the true C function is called
11:11:44 <TrueBrain> make a black where you put the result in emu_ variables again
11:12:02 <TrueBrain> http://paste.openttd.org/218192
11:12:06 <TrueBrain> not like the first, but like the second
11:12:19 <TrueBrain> then align the '=' of the first block
11:12:32 <TrueBrain> http://paste.openttd.org/218193
11:12:34 <TrueBrain> like that
11:12:38 <TrueBrain> I noticed that increases readability a lot
11:14:14 <TrueBrain> oh, and in GetDistance, please use '/ 2' over '>> 1' .. this in general in all OpenDUNE coding
11:14:22 <TrueBrain> any sane compiler makes it >> 1, but / 2 is more readable for humans :)
11:14:48 <TrueBrain> (as in this case that is what you mean, divide by 2, not shift right by 1 :))
11:15:09 <TrueBrain> one nitpick thingy: below Tile_GetY() function, is a double newline :p
11:16:02 <TrueBrain> well, that is about it :p
11:20:51 <TrueBrain> about the shifts, >> 6 of course should remain >> 6, as here you really mean the bitshift, not any divide
12:13:42 <Xaroth> <@TrueBrain> The Origin <- you read too much Darwin << better than murphy, no? :P
12:15:13 <Xaroth> TrueBrain: re: Tile_GetDistance , seeing they are single-lines, no { } or leave { } for readability
12:24:08 <TrueBrain> first of all, it is useless to have a if () { return } else { return }
12:24:12 <TrueBrain> if () { return } return
12:24:14 <TrueBrain> is sufficient
12:24:33 <TrueBrain> second, you have lack of spaces in if (), you have too many newlines in {} usage .. read the wiki page :p
12:24:52 <TrueBrain> and also on that same wiki page, with an else, always {}
12:24:58 <TrueBrain> I do not write those pages for nothing :p
12:32:16 <Xaroth> thar we go
12:32:18 <Xaroth> time for the last two
12:37:12 * boekabart eats a Whopper...
12:51:39 <TrueBrain> I WANT ONE TOO!
12:51:41 <TrueBrain> GIMME ONE! NOW!
12:51:51 <TrueBrain> no? :'(
12:55:51 *** glx has joined #openDune
12:55:51 *** ChanServ sets mode: +v glx
12:56:38 <glx> hello
12:59:54 <TrueBrain> morning glx :)
13:06:20 <TrueBrain> so what will I do today?
13:06:22 <Xaroth> http://www.youtube.com/watch?v=jEjUAnPc2VA
13:15:22 <TrueBrain> I like my Structure_CalculatePowerAndCredit :)
13:15:39 <TrueBrain> and I think I found what displays the text in the scroll thngy
13:15:40 <TrueBrain> not sure ..
13:15:54 <TrueBrain> but I think 'f__10E4_09AB_0031_5E8E' displays it
13:16:02 <TrueBrain> and 'f__0FCB_005F_001C_FDC4' prepares it or something
13:16:13 <TrueBrain> the latter fetches it from the language file or something
13:17:38 <TrueBrain> which means there should be an offset table at the beginning of language files
13:21:53 <Xaroth> :o
13:25:34 <TrueBrain> but any requests? No? :)
13:28:43 <Xaroth> well
13:28:46 <Xaroth> ... no
13:32:02 <TrueBrain> I don't understand variable_09 ... it is 0xFF for human players, and 1 << houseID for all other players
13:32:25 <boekabart> Xaroth: omg cool video
13:32:28 <Xaroth> :)
13:33:05 <boekabart> even better enjoying with twister fries! :P sorry TrueBrain, pulling your leg
13:33:14 <Xaroth> oi
13:33:18 <TrueBrain> GIVE MY LEG BACK!
13:33:19 <Xaroth> gimme those!
13:35:11 <TrueBrain> Xaroth: do you already know what f__0F3F_0104_0013_C3B8 does?
13:35:25 <Xaroth> not looked at unnamed functions, so no
13:35:44 <TrueBrain> oh, get the distance between position
13:35:48 <TrueBrain> (ignoring offset)
13:36:11 <Xaroth> :o sarw
13:36:40 <Xaroth> sounds like a sick pirate call
13:36:45 <Xaroth> sssARRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRWWW
13:38:29 <SmatZ> you ok?
13:38:52 <Xaroth> Have I ever been? :P
13:39:04 <SmatZ> :)
13:39:10 <Xaroth> on a brighter note, I've still got 10 vacation days
13:39:17 <Xaroth> 4 for the days between xmas and newyear
13:39:24 <Xaroth> 6 left for planning
13:39:35 <planetmaker> someone please remind me tomorrow to upload a crash.bin and an error :-)
13:39:58 <Xaroth> planetmaker: tomorrow you should upload a crash.bin and an error
13:40:04 <planetmaker> :-P
13:40:47 <planetmaker> ok... maybe a bit more recent then ;-)
13:40:57 <TrueBrain> okay, what can this function do .. (I will describe it now :p)
13:41:08 <TrueBrain> it has 2 structures as parameter, or 1 structure and 1 unit, not sure
13:41:34 <TrueBrain> it checks if variable_09 has the house bit set for the structure/unit inside the structure, where, as said, players have that value as 0xFF, AIs only their house
13:41:37 <TrueBrain> when it is set, it aborts
13:42:03 <planetmaker> and did I tell that I like the Ordos? It's so nice to turn traitor a devestator and explode it. Sooo convenient ;-)
13:42:11 <TrueBrain> if not, it fetches 2 variables from StructureInfo, calculates the distance between the structure and structure/unit, and it divides those 2 values
13:42:22 <Xaroth> TrueBrain: targeting?
13:42:43 <Xaroth> if friendly, abort, else check distance? :o
13:42:52 <TrueBrain> how does it detect friendly?
13:43:00 <boekabart> smile and check reaction
13:43:11 <TrueBrain> lol @ boekabart
13:43:20 <planetmaker> haha :-)
13:43:23 <Xaroth> sorry, coke almost over my keyboard
13:43:27 * Xaroth shakes fist @ boekabart
13:43:34 <TrueBrain> AI structure: 00000010 <- for houseID 1
13:43:39 <TrueBrain> Human structure: 11111111
13:44:56 <Xaroth> hm
13:47:36 * boekabart wonders why the 'called from:' comments never have function names
13:48:15 <TrueBrain> because they are never on a function name
13:48:17 <TrueBrain> always somewhere inside
13:48:22 <TrueBrain> but it is a bit out-dated now :)
13:49:59 <boekabart> I understand that, still if the function it's called from has a name, might shed some light sometimes
13:50:14 <TrueBrain> then you will need some syntax like: function_name+12
13:50:20 <TrueBrain> which is not a lot more readable :)
13:50:31 <TrueBrain> as I said, the Called From is out-dated. It was needed when there were tons of small functions
13:50:41 <TrueBrain> now a simple search in your code should show all instances, which is much more useful :)
13:53:28 <Xaroth> right, PackXY done, i think
13:53:32 <Xaroth> one more to go
13:53:45 <Xaroth> then just unnamed stuff
13:53:59 <TrueBrain> I have a function which scans the whole map with a structure-layout ...
13:54:10 <TrueBrain> sometimes I wonder if it is a good idea to look at a function and try to figure out what it does
13:54:13 <TrueBrain> as this is just plain weird :p
13:59:44 <TrueBrain> lol, if I read this correct, the fact Harkonnen can't build 'Thopters is a hack :p
13:59:54 <TrueBrain> the Upgrade button is hacked out :p
14:00:06 <Xaroth> lol
14:08:21 <TrueBrain> http://www.dumpert.nl/mediabase/30825/02a4811b/astrid_kersenboom_pwned.html
14:10:29 <TrueBrain> if I read this function correct, the game really checks if you are able to build a structure somewhere before allowing it to be build
14:10:51 <Xaroth> haha
14:11:09 <Xaroth> @ that vid then
14:11:18 <TrueBrain> (it is fake btw, but still)
14:11:34 <Xaroth> and @ second, does that mean, that if there's no 3x3 square available, the game won't let you build a 3x3 building?
14:22:11 <TrueBrain> I guess
14:22:13 <TrueBrain> going to test that now
14:24:01 <TrueBrain> okay ... I see no difference :p
14:26:41 <TrueBrain> absolutely no clue what it does :p
14:29:11 <DorpsGek> SVN: truebrain (r505) -Add: named one more function
14:41:07 <SmatZ> I thought structures on slabs are degrading because of wind with sand, age and such :)
14:41:50 <TrueBrain> then why do scenario buildings not degrade? :)
14:41:59 <TrueBrain> (the ones you get at the start of a mission)
14:42:12 <SmatZ> they are SPECIAL
14:42:14 <SmatZ> :)
14:42:18 <TrueBrain> haha :)
14:42:20 <TrueBrain> k :)
14:42:57 <SmatZ> you should have been reviewer of DUNE2 code
14:43:01 <SmatZ> before it was released
14:43:22 <TrueBrain> well, only reviewing wouldn't have helped :p
14:43:27 <TrueBrain> but it is messy code, that is for sure :)
14:43:30 <SmatZ> :)
14:44:16 <SmatZ> gotta love you guys, for opendune :)
14:44:42 <TrueBrain> now start helping us :p
14:44:57 <SmatZ> I love myself already :)
14:45:16 <SmatZ> but well... I know if I started helping you, I would spend too much time with that
14:45:23 <SmatZ> I would love doing it :)
14:45:27 <SmatZ> but I can't now :(
14:45:33 <TrueBrain> too bad :)
14:45:36 <TrueBrain> we could hav eused your help :)
14:45:44 <SmatZ> don't tell me that :-D
14:46:04 <TrueBrain> I just did :)
14:46:34 <TrueBrain> omg .. cs__15C2.c, around line 1100 ... now that is a massive switch
14:47:58 <TrueBrain> what ever it is, it controls all movement and stuff
14:48:26 <Xaroth> ~O_O
14:48:37 <SmatZ> :_)
14:48:38 <SmatZ> -
14:53:16 <TrueBrain> I can only guess it is part of the script engine ..
14:55:43 <Xaroth> SmatZ: how can you love yourself, if you only love those who help with opendune ;) ;)
14:55:55 <TrueBrain> nice :)
14:56:14 <glx> I don't see where -C and -E are set
14:56:36 <TrueBrain> glx: in what function?
14:56:56 <glx> cs:ip used by the massive switch
14:57:14 <glx> it's a local variable of the function
14:57:47 <TrueBrain> emu_get_memory16(emu_ss, emu_bp, -0xC) = emu_ax;
14:57:49 <TrueBrain> emu_get_memory16(emu_ss, emu_bp, -0xE) = emu_dx;
14:57:50 <TrueBrain> a few lines higher
14:58:06 <glx> ha rigth :)
14:58:14 <TrueBrain> k, it is script related for sure :)
14:58:33 <TrueBrain> f__0972_0C04_0037_B310 <- set the build-animation-sprite of a structure
14:58:38 <TrueBrain> naming this will be a bitch
14:58:58 <glx> there's a lot of indirection to get the address :)
14:59:24 <TrueBrain> yes, a lot
14:59:30 <SmatZ> :)
14:59:40 <glx> ,...emu_lfp(&emu_es, &emu_bx, &emu_get_memory16(emu_ss, emu_bp, 0x6));
14:59:40 <glx> ,...emu_lfp(&emu_es, &emu_bx, &emu_get_memory16(emu_es, emu_bx, 0x4));
14:59:40 <TrueBrain> I assume at 0x6 is the 'script engine' of a unit/structure/whatever
14:59:55 <TrueBrain> the first 3 entries in that are csip32s
15:00:15 <TrueBrain> so I guess the 0x4 points to either 'structure' or 'unit' functions
15:00:28 <glx> then there's at least 2 other indirections after that
15:00:33 <TrueBrain> yup
15:01:03 <TrueBrain> yes, when printing the 0x4, it is either 3918 or 3902
15:01:30 <TrueBrain> both already identified
15:01:56 <TrueBrain> ah, yes, the shit I couldn't place
15:02:47 <TrueBrain> then at 3918/3902 + 0x10 is read a csip32
15:03:20 <TrueBrain> and this is the table of functions
15:03:28 <glx> seems so
15:03:55 <glx> hmm a pointer to an array
15:03:56 <TrueBrain> 353F:33B6
15:03:58 <TrueBrain> 353F:6168
15:03:59 <TrueBrain> one of the two values
15:05:20 <TrueBrain> there can't be more than 256 entries in both tables
15:06:31 <TrueBrain> there are 25 entries in the table, if I count correctly, for 33B6
15:07:06 <TrueBrain> 64 for the other
15:07:20 <glx> max 8C = (35E8 - 33B6)/4
15:08:52 <glx> and max 0x60 for 6168
15:09:09 <TrueBrain> I looked in the memory ;)
15:09:32 <glx> yeah looking in memory gives more precise range ;)
15:10:25 <TrueBrain> @calc 0x33B6 + 100
15:10:25 <DorpsGek> TrueBrain: 13338
15:10:28 <TrueBrain> @base 10 16 13338
15:10:28 <DorpsGek> TrueBrain: 341A
15:13:45 <TrueBrain> I really wonder why they are so far apart in the memory
15:13:47 <TrueBrain> but okay :)
15:14:18 <glx> I stopped trying to understand the logic behind memory locations ;)
15:16:37 <TrueBrain> sounds like a good plan ;)
15:16:46 <TrueBrain> I guessed the struct is 20 big ..
15:17:32 <TrueBrain> 22 even
15:17:40 <TrueBrain> as that is the space between them :p
15:17:47 <TrueBrain> (3902 and 3918)
15:18:28 <DorpsGek> SVN: truebrain (r506) -Add: figured out a few variables related to the scripting engine
15:21:49 <TrueBrain> hmm .. if I read this correctly, every unit has his 'script' inside its own struct
15:21:53 <TrueBrain> so it is cloned, so to say ..
15:22:02 <TrueBrain> dunno where it is loaded, so hard to say, but it is a bit weird
15:23:34 <glx> oh the begining of Unit_Free() is duplicated 3 times it seems :)
15:23:58 <TrueBrain> hmm .. the first 'big' switch is limited 0..18 (including) but I only have 17 entries in the switch, meaning there are still 2 left ...
15:24:08 <TrueBrain> glx: how do you mean?
15:24:21 <glx> ,...emu_ax = 0x3902;
15:24:22 <glx> ,...emu_push(emu_ax);
15:24:22 <glx> ,...emu_ax = emu_get_memory16(emu_ss, emu_bp, 0x6);
15:24:22 <glx> ,...emu_addw(&emu_ax, 0x12);
15:24:22 <glx> ,...emu_push(emu_get_memory16(emu_ss, emu_bp, 0x8));
15:24:23 <glx> ,...emu_push(emu_ax);
15:24:23 <glx> ,...emu_push(emu_cs); emu_push(0x116C); emu_cs = 0x15C2; f__15C2_0395_0044_304E();
15:24:29 <glx> in 3 different location
15:24:56 <glx> .,.../* XXX -- No idea */
15:24:56 <glx> ,...emu_push(0x353F); emu_push(0x3902); /* XXX -- g_global->variable_3902 */
15:24:56 <glx> ,...emu_push(address.s.cs); emu_push(address.s.ip + 0x12);
15:24:56 <glx> ,...emu_push(emu_cs); emu_push(0x0580); emu_cs = 0x15C2; f__15C2_0395_0044_304E();
15:25:02 <glx> same as above
15:25:06 <TrueBrain> yup :)
15:25:13 <TrueBrain> it release the script engine or something I guess
15:25:33 <TrueBrain> euh
15:25:35 <TrueBrain> release = runs
15:25:51 <glx> and even more fun there is
15:25:51 <TrueBrain> no, releases :p
15:25:52 <glx> ,...emu_push(emu_get_memory16(emu_ss, emu_bp, 0x8));
15:25:52 <glx> ,...emu_push(emu_get_memory16(emu_ss, emu_bp, 0x6));
15:25:52 <glx> ,...emu_push(emu_cs); emu_push(0x117A); emu_cs = 0x0FE4; emu_Unit_Free();
15:25:53 <TrueBrain> ghehe :)
15:25:59 <glx> right after one of them
15:26:11 <TrueBrain> we all established the code sucks :)
15:26:23 <TrueBrain> sometimes things are set 3 or 4 times :p
15:26:26 <TrueBrain> 'just to be sure' :p
15:27:00 <TrueBrain> oh, it 'resets' the engine
15:27:07 <glx> yes and sometimes it's really hard to find where something is set
15:27:41 <TrueBrain> okay, I am very sure it is the script stuff now :)
15:27:48 <TrueBrain> now the size of that blob ...
15:27:56 <TrueBrain> I see a 0x34, so at least 0x34 in size
15:28:27 <TrueBrain> how are we going to do this ... script.h, with a struct ScriptEngine? And include this in structure.h and unit.h?
15:29:32 <glx> there's a 0x58 at 6268
15:29:57 <glx> ,...emu_lfp(&emu_es, &emu_bx, &emu_get_memory16(emu_ds, 0x00, 0x6268));
15:29:58 <glx> ,...emu_get_memory8(emu_es, emu_bx, 0x58) = 0x0;
15:30:16 <TrueBrain> at 6268 is somethng else, I guess a pointer to the real structure
15:30:27 <glx> a big structure :)
15:30:35 <TrueBrain> no, Strcuture
15:30:37 <TrueBrain> :p
15:30:50 <TrueBrain> oh, that is 0x58 in size, so that would be invalid too :p
15:31:00 <TrueBrain> how ever, not inside the script engine thingy :)
15:31:12 <TrueBrain> but do you think it is a good idea to include script.h in structure.h?
15:31:21 <TrueBrain> I don't like includes in header, but I don't see another way to do this clean :(
15:31:46 <glx> header mess can be fixed later I think
15:31:55 <TrueBrain> it never will ;)
15:32:47 <TrueBrain> 'Script' or 'ScriptEngine' or 'ScriptInstance', or?
15:33:35 <planetmaker> ScriptEngine ;-)
15:33:47 * planetmaker now officially functions as the voice from the off ;-)
15:39:29 <TrueBrain> ;)
15:41:34 <TrueBrain> now, can I write 'emu_push(scsip.s.cs); emu_push(scsip.s.ip + 0x12);' in a nicer way .. hmm .. no :p
15:46:35 <DorpsGek> SVN: truebrain (r507) -Add: ScriptEngine, and some references to it
15:46:42 <TrueBrain> there we go :)
15:48:31 <TrueBrain> lol, f__15C2_03D9_0011_D202() ALSO resets the engine ...
15:48:36 <TrueBrain> for structures I count 3 resets already :p
15:48:48 <TrueBrain> twice manual, and one time via a subfunction
15:49:41 <glx> just 'to be sure' ;)
15:50:23 <TrueBrain> I 'think' that in the first variable it loads the script to execute
15:50:47 <TrueBrain> but it is a double indirection again, so a bit tricky to read :p
16:06:16 <TrueBrain> hmmm ... one part tells me that ScriptEngine+0x8 is a 32bit value, other parts tell me it is not ...
16:14:40 <TrueBrain> there really are parts where it is used as a 32bit, and parts where it is used as a 16bit + 2x 8bit ...
16:21:31 <DorpsGek> SVN: truebrain (r508) -Add: more work on Scripts: function naming, variable naming, and the like
16:26:38 <DorpsGek> SVN: truebrain (r509) -Fix (r508): forgot to rerun the decompiler
16:27:01 <TrueBrain> named 4 out of 6 functions .. not a bad score I say
16:29:40 <TrueBrain> okay .. planetmaker, I need you again: when you build a structure, it first shows the 'in progress of building' structure, then it shows the structure, then it goes back to the other again, and it blinks like that a few times, before it shows the structure
16:29:53 <TrueBrain> also, when you build a unit, it shows some animation or something
16:29:57 <TrueBrain> how to name a variable which controls that?
16:31:57 <glx> hmm 8434 is pointer to a struct with houseID at offset 8
16:32:17 <TrueBrain> both unit and structure have that
16:34:24 <TrueBrain> emu_Script_Structure_ChangeVariable54
16:34:27 <TrueBrain> clear enough?
16:34:39 <glx> yes :)
16:35:07 <TrueBrain> I can write stories about what it does exactly, but I guess that has to be done at a later stage :p
16:35:32 <TrueBrain> cool, scripts have a small storage, a stack most likely
16:35:45 <DorpsGek> SVN: truebrain (r510) -Add: named the first script function, to show naming-scheme
16:36:22 <TrueBrain> 75 functions to identify and name ...
16:36:36 <TrueBrain> hmm .. 25 + 64 = 89 .. so 14 functions are not called
16:39:30 <TrueBrain> glx: 8434 btw is the current structure handled by the script
16:39:33 <glx> probably structure
16:39:39 <glx> yes 2C94
16:40:02 <TrueBrain> and I think at 8430 is the pointer to the script engine at use
16:41:15 <TrueBrain> ah, no, 8430 is the StructureInfo
16:42:20 <glx> hmm there's no 0x60 long struct
16:42:52 <glx> ,...emu_lfp(&emu_es, &emu_bx, &emu_get_memory16(emu_ds, 0x00, 0x8434));
16:42:53 <glx> ,...emu_al = emu_get_memory8(emu_es, emu_bx, 0x2);
16:42:53 <glx> ,...emu_ax = (int8)emu_al;
16:42:53 <glx> ,...emu_dx = 0x60;
16:42:53 <glx> ,...emu_imuluw(&emu_ax, emu_dx);
16:42:53 <glx> ,...emu_addw(&emu_ax, 0xA);
16:42:55 <glx> ,...emu_get_memory16(emu_ds, 0x00, 0x8432) = 0x2C94;
16:42:55 <glx> ,...emu_get_memory16(emu_ds, 0x00, 0x8430) = emu_ax;
16:43:27 <glx> so 2C94 is an array of 0x60 long struct
16:44:00 <glx> ok I'm stupid :)
16:44:11 <glx> StructureInfo is 0x60
16:45:38 <TrueBrain> ;)
16:45:48 <glx> so 8430 is csip to StructureInfo->variable_0A
16:46:09 <TrueBrain> no
16:46:12 <TrueBrain> it is StructureInfo
16:46:20 <TrueBrain> don't ask, but StructureInfo starts at 2C94:A
16:46:32 <glx> ok it's silly :)
16:46:50 <glx> and not documented in global.h ;)
16:47:06 <TrueBrain> indeed
16:47:42 <DorpsGek> SVN: truebrain (r511) -Fix: document 2C94 offset correctly
16:48:00 <DorpsGek> SVN: truebrain (r512) -Add: named one more script function
16:48:26 <TrueBrain> what is only odd in my opinion, is that 8430 and stuff is only set in one funciton in 0972, yet all script functions use it ..
16:49:23 <TrueBrain> I think 6124 is the same for Units btw
16:49:46 <TrueBrain> or 6268
16:50:14 <glx> 8434 is also copied to 394E
16:50:43 <TrueBrain> 6268 is used in cs__176C, and 6124 in cs__16C5
16:51:16 <glx> then house csip is in 394A
16:51:19 <TrueBrain> 176C is units .. 16C5 is an unknown for me :)
16:51:50 <TrueBrain> okay ... the values are just before the function-array :)
16:52:45 <TrueBrain> well .. not always true :p
16:53:29 <glx> would be too easy ;)
16:53:44 <TrueBrain> 394E is used in 0EDB
16:53:48 <TrueBrain> which seems a more general thing
16:54:34 <TrueBrain> I guess it will be a while before we find out what all those script functions do :p
16:54:39 <TrueBrain> but I am happy we found out where it happens :)
16:57:25 <glx> emu_si = emu_get_memory16(emu_ds, emu_bx, 0x3800); <-- that's in the middle of the donotuse_houseInfo :)
16:57:59 <TrueBrain> yup, so you have to calculate the offset yourself, and use g_houseInfo ;)
17:09:34 <glx> houseinfo@8
17:09:49 <glx> so I don't know what it is for now
17:10:16 <glx> maybe a counter
17:15:13 <TrueBrain> time will tell :)
17:16:51 <glx> there's an inc(si) later that's why I think it's a counter
17:17:42 <TrueBrain> I think I will start C-ifying Script_Run ..
17:19:28 <TrueBrain> glx: did you name the things like 8434 already?
17:19:50 <glx> no
17:20:17 <glx> I'm just reading without modifying global.h :)
17:20:31 <TrueBrain> k :
17:20:32 <TrueBrain> )
17:20:46 <TrueBrain> some things are just weird ... take this script function to remove fog
17:20:54 <TrueBrain> I would assume you could, from the script, tell where and how much
17:21:17 <TrueBrain> it turns out that is not true .. it always removes the fog around the top-left location and in a predefined radius (by the StructureInfo)
17:22:56 <glx> ,...emu_lfp(&emu_es, &emu_bx, &emu_get_memory16(emu_ds, 0x00, 0x8434));
17:22:57 <glx> ,...emu_cmpb(&emu_get_memory8(emu_es, emu_bx, 0x8), 0x2);
17:22:57 <glx> ,...if (emu_get_memory8(emu_es, emu_bx, 0x8) == 0x2) {
17:22:57 <glx> ,...,...emu_lfp(&emu_es, &emu_bx, &emu_get_memory16(emu_ds, 0x00, 0x8434));
17:22:57 <glx> ,...,...emu_cmpb(&emu_get_memory8(emu_es, emu_bx, 0x2), 0x4);
17:22:57 <glx> ,...,...if (emu_get_memory8(emu_es, emu_bx, 0x2) == 0x4) {
17:22:59 <glx> ,...,...,...emu_lfp(&emu_es, &emu_bx, &emu_get_memory16(emu_ds, 0x00, 0x8434));
17:22:59 <glx> ,...,...,...emu_cmpb(&emu_get_memory8(emu_es, emu_bx, 0x4E), 0x2);
17:23:01 <glx> ,...,...,...if (emu_get_memory8(emu_es, emu_bx, 0x4E) == 0x2) {
17:23:01 <glx> ,...,...,...,...emu_lfp(&emu_es, &emu_bx, &emu_get_memory16(emu_ds, 0x00, 0x8434));
17:23:03 <glx> ,...,...,...,...emu_get_memory8(emu_es, emu_bx, 0x4E) = 0x3;
17:23:03 <glx> ,...,...,...}
17:23:05 <glx> ,...,...}
17:23:05 <glx> ,...}
17:23:11 <glx> ordos heavy upgrade ?
17:23:36 <glx> house 2 type 4 if level 2, level = 3
17:23:43 <TrueBrain> yes, lvl2 of goes directly to lvl3
17:24:57 <glx> but I still don't get exactly what is done in 0972 :)
17:25:21 <TrueBrain> general structure functions
17:25:25 <TrueBrain> some scripts, some gameloop
17:25:34 <TrueBrain> the 0007 appears to be the gameloop
17:26:45 <TrueBrain> I am even sure of it ;)
17:27:24 <glx> StructureInfo@10 value, StructureInfo@16 percent
17:27:33 <TrueBrain> lol! Another stupid thing ... cs__0972.c:297, checks if the scenarioPreview is active (remember, it is av ariable that is only read, just written once at startup)
17:27:43 <TrueBrain> it does this check INSIDE the loop over all structures
17:27:47 <TrueBrain> and then skips the structure
17:27:54 <TrueBrain> that is like: for () { continue; }
17:29:12 <TrueBrain> btw, glx, 394E is shared with 176C .. for what ever reason :p
17:29:50 <TrueBrain> glx: I have no idea what you tried to say
17:29:59 <TrueBrain> Structure+0x50 is btw a general timer
17:31:07 <glx> I'm just reading cs_0972.c:447 and later
17:32:07 <TrueBrain> the Palace code is very special :p
17:32:28 <glx> but function_names.txt don't tell exact args for valuetopercent and percenttovalue ;)
17:32:39 <TrueBrain> oh ... when you read it, you will know :p
17:33:04 <TrueBrain> V2P is like: p1 * 256 / p2
17:33:11 <TrueBrain> P2V is like: p1 * p2 / 256
17:34:29 <glx> anyway it passes V2P result to P2V
17:34:34 <Xaroth> wonder what the retention rate is for news.kpnplanet :o
17:34:49 <TrueBrain> I have a usenet with 400 days, so I don't care :p
17:35:01 <Xaroth> :o
17:35:04 <Xaroth> giev? :p
17:35:17 <TrueBrain> www.xsnews.nl
17:36:40 <Xaroth> o_O I take it the abonnementen are better than the block accounts
17:37:01 <TrueBrain> just take the 5 days for free
17:37:09 <TrueBrain> but yes, of course Block accounts are more expensive
17:37:23 <TrueBrain> for the rest I wouldn't know, I take the largest possible account there
17:37:44 <Xaroth> yeh, i only have 8mbit down, so i'll just stick with the 5mbit :)
17:37:56 <TrueBrain> I have 100mbit, so yeah .. :p
17:38:02 <Xaroth> bastid :P
17:38:08 <Xaroth> I want ftth in uithoorn :/
17:38:38 <TrueBrain> now sssttt, we are doing big work here :p
17:38:47 <Xaroth> wait what? :o
17:38:49 <Xaroth> what'd i miss
17:38:54 <TrueBrain> clearly, a lot :p
17:39:05 <Xaroth> clearly
17:39:21 <TrueBrain> glx: f__0972_0A72_000D_024E <- I expected much of such functions, but there are not as many as I expected :)
17:39:56 <glx> it's an accessor :)
17:40:12 <TrueBrain> yes, one would expect tons of those to make scripts usable
17:40:21 <TrueBrain> but .. there are only very few of those .. if not the only one :p
17:41:29 <TrueBrain> glx: how to call the first function? Structure_GameLoop? Structure_RunTick? Structure_Run?
17:43:42 <glx> emu_GameLoop_Structure
17:43:47 <glx> to be consistent
17:44:04 <glx> as it's called from emu_GameLoop_Main
17:47:05 <glx> f__176C_010B_002F_7FAE <-- emu_GameLoop_Unit
17:48:06 <glx> f__16C5_0009_0023_21B3 <-- emu_GameLoop_AirUnit I think
17:51:07 <glx> f__1391_000A_0035_2CB6 <-- emu_GameLoop_House
17:51:22 <TrueBrain> so remove the 'I think' part, and name them ;)
17:51:25 <glx> all this based on FindFirst/FindNext presence
17:51:30 <TrueBrain> I am going to do 0972_0007 now
17:52:02 <glx> and being called from emu_GameLoop_Main
17:52:38 <TrueBrain> I expect to be busy with this a few _days_ :)
17:52:54 <glx> it's not a small function yes
17:53:03 <Xaroth> well, kpnplanet's news server seems to work :o
17:53:14 <TrueBrain> not only that, but also the endless documentation, and creating variables, and shit :p
17:54:58 <TrueBrain> glx: can you confirm something for me? We marked 76B0 as csip32, but I think it is a regular uint32
17:55:23 <TrueBrain> emu_bx = emu_get_memory16(emu_ds, 0x00, 0x76B2);
17:55:25 <TrueBrain> emu_cx = emu_get_memory16(emu_ds, 0x00, 0x76B0);
17:55:26 <TrueBrain> emu_addw(&emu_cx, emu_ax);
17:55:28 <TrueBrain> emu_adcw(&emu_bx, emu_dx);
17:55:29 <TrueBrain> nevermind, found it myself ;)
17:57:12 <glx> looks like uint32 indeed yes :)
18:00:21 <glx> http://glx.dnsalias.net:8080/opendune/functions.diff
18:01:48 <DorpsGek> SVN: truebrain (r513) -Add: name 4 functions (glx)
18:02:47 <glx> hmm 76B0 is a tick_counter I'd say
18:03:46 <TrueBrain> yp
18:10:11 <TrueBrain> pfff .. mind breaking, those if-statements at the begin of this function
18:10:15 <TrueBrain> glx:
18:10:17 <TrueBrain> if (g_global->variable_341A >= g_global->variable_76B0) goto l__00BD;
18:10:19 <TrueBrain> if (g_global->campaignID <= 1) goto l__00BD;
18:10:31 <TrueBrain> sorry glx, didn't want to say your name .. stupid konversation adds it when hitting alt+tab :(
18:15:20 <glx> and they use similar stuff for other GameLoops too
18:15:36 <glx> just the checked variables are different
18:16:00 <TrueBrain> what the fuck ...
18:16:02 <TrueBrain> emu_push(0);
18:16:04 <TrueBrain> emu_push(0x5460);
18:16:05 <TrueBrain> emu_push(0x1518);
18:16:07 <TrueBrain> emu_push(0x2A30);
18:16:08 <TrueBrain> emu_push(emu_cs); emu_push(0x00A5); emu_cs = 0x07C9; f__07C9_000F_0050_9278();
18:16:10 <TrueBrain> .... what?! :p
18:16:19 <Xaroth> o_O
18:16:31 <glx> call with constant
18:17:15 <glx> done for other with different constants :)
18:19:12 <TrueBrain> I think it calculates when the 'next time to call'
18:19:18 <TrueBrain> maybe depending on GameSpeed or what ever
18:19:53 <TrueBrain> @base 16 10 3c
18:19:53 <DorpsGek> TrueBrain: 60
18:19:53 <glx> but only for Structure and Unit
18:21:01 <TrueBrain> which would suggest AirUnits don't move faster in different speed modes?
18:21:11 <TrueBrain> although I am still not 100% sure AirUnits are in fact Air Units :p
18:22:36 <TrueBrain> ah, I think the 2nd value is 'normal' speed, 3rd 'fast' and 4th 'slow'
18:23:15 <TrueBrain> hmm .. no .. more like unused / max / min / normal (in reversed param order)
18:31:46 <TrueBrain> we should not forget to remove entries from function_names.txt when they are in src/ :)
18:32:07 <glx> true :)
18:32:20 <glx> and be sure to use the correct @name ;)
18:32:21 <TrueBrain> okay, I clearly did something wrong .. buildings no longer build :p
18:32:27 <TrueBrain> that too .. that too ;)
18:36:35 <TrueBrain> one of the vars seems to start with the value '1048592'
18:36:38 <TrueBrain> which is way out of bound :(
18:40:19 <TrueBrain> f__07C9_000F_0050_9278 returns 16:16 (dx:ax)
18:40:22 <TrueBrain> which doesn't make sense ...
18:41:27 <TrueBrain> oops .. yes .. of course .. lol
18:48:40 <TrueBrain> structureCurrent a good name for 8434?
18:54:08 <glx> yes
18:54:25 <glx> it's the result of FindFirst/FindNext
18:54:43 <TrueBrain> no idea how to name the clone at 394E, but okay
18:54:51 <TrueBrain> @calc 0x39EA - 0x3952
18:54:51 <DorpsGek> TrueBrain: 152
18:54:53 <TrueBrain> @base 10 16 152
18:54:53 <DorpsGek> TrueBrain: 98
18:55:56 <glx> 6124 is then airUnitCurrent :)
18:57:26 <glx> 394A houseCurrent
19:00:51 <TrueBrain> okay ... first lines are getting there :p
19:02:02 <TrueBrain> countDown a good name?
19:02:09 <TrueBrain> Structure.countDown that is
19:04:02 <glx> 6268 unitCurrent
19:05:25 <TrueBrain> @base 16 2 a
19:05:25 <DorpsGek> TrueBrain: 1010
19:06:40 <TrueBrain> glx: you write down all the non-structure related ones?
19:07:15 <glx> written here only for now :)
19:09:25 <TrueBrain> but is countDown a good name for a general ticker?
19:10:39 <TrueBrain> in the first campaign structures don't degrade :p
19:14:25 <tneo> is it a normal ingame restriction that I can't build more windtraps?
19:14:37 <TrueBrain> at a certain points you can't build anything :p
19:14:44 <TrueBrain> most noticable in campaign 9
19:14:50 <TrueBrain> first destroy a few buildings of the enemy
19:14:57 <tneo> a ok
19:15:02 <TrueBrain> you can only have 70 structures on a map in total
19:15:22 <TrueBrain> @calc 0x3800 - 0x37F8
19:15:22 <DorpsGek> TrueBrain: 8
19:23:06 <TrueBrain> @calc 0x392e + 0x16
19:23:06 <DorpsGek> TrueBrain: 14660
19:23:09 <TrueBrain> @base 10 16 14660
19:23:09 <DorpsGek> TrueBrain: 3944
19:25:01 <TrueBrain> 250 lines down in the function .. lalala
19:27:50 <TrueBrain> one timer is there special for the palace, one special for degrading buildings .. that is a bit unexpected for me :)
19:33:55 <TrueBrain> @calc 0x100 - 0xfb
19:33:55 <DorpsGek> TrueBrain: 5
19:44:44 <TrueBrain> @base 16 10 64
19:44:44 <DorpsGek> TrueBrain: 100
19:46:37 <TrueBrain> k, uncovered the upgrading of buildings completely
19:46:39 <TrueBrain> lovely code
19:58:42 <TrueBrain> @calc 300 / 73
19:58:42 <DorpsGek> TrueBrain: 4.1095890411
19:58:47 <TrueBrain> @calc 300 / 72.5
19:58:47 <DorpsGek> TrueBrain: 4.13793103448
19:58:49 <TrueBrain> hmm ..
20:00:14 <TrueBrain> can any of you see how much it cost to repair a windtrap from 50% to 100% in the first campaign?
20:00:20 <TrueBrain> I modified that routine, and need to validate :)
20:02:42 <SmatZ> TrueBrain: about 394
20:02:47 <SmatZ> errr 294
20:02:59 <TrueBrain> euh, building it already cost 300 credits
20:03:07 <TrueBrain> so I doubt repairing it for 50% would cost the same :s
20:03:24 <SmatZ> it does
20:03:31 <SmatZ> start = 1000 credits
20:03:31 <TrueBrain> then I completely misread the routine :s
20:03:46 <SmatZ> built windtrap (without slabs) => 699 credits
20:03:55 <SmatZ> repaired it => 405 credits
20:04:57 <SmatZ> what routine?
20:05:30 <TrueBrain> the one handling repairs :)
20:06:03 <TrueBrain> SmatZ: are you sure sure? As how ever I calculate, I can't get a value close to 300 out of it :s
20:06:40 <TrueBrain> it should cost around 42 credits ...
20:06:56 <SmatZ> I am very sure
20:07:12 <TrueBrain> what revision?
20:07:36 <SmatZ> hmm the one I have
20:07:42 <SmatZ> I mean, original dune2
20:07:50 <TrueBrain> ah .. 1.07eu?
20:08:01 <SmatZ> guess not :)
20:08:12 <TrueBrain> when you start it, it is in the bottom right corner
20:08:54 <SmatZ> hmm there is nothing there
20:08:57 <TrueBrain> 1.00
20:09:02 <TrueBrain> so there it cost even more ... wow ..
20:09:15 <TrueBrain> and how :p
20:09:17 <TrueBrain> haha
20:09:41 <SmatZ> :)
20:09:47 <SmatZ> good it will be cheaper
20:09:53 <SmatZ> it's incredibly expensive
20:09:53 <TrueBrain> yeah ...
20:10:52 <SmatZ> oh, yes, 1.0 ... it's almost invisible
20:11:16 <TrueBrain> k .. now it cost 68 credits .. still wrong .. hmm ..
20:16:18 <TrueBrain> 200 hitpoints .. 300 cost for structure .. we calculate how much it cost to repair 2 hitpoints
20:16:25 <TrueBrain> so ... 3 credits, right?
20:17:04 <TrueBrain> @calc 2 * 256 / 200
20:17:04 <DorpsGek> TrueBrain: 2.56
20:17:12 <TrueBrain> @calc 2 * 300 / 256
20:17:12 <DorpsGek> TrueBrain: 2.34375
20:19:48 <glx> you're near l__0326 ?
20:20:00 <TrueBrain> yes
20:20:38 <glx> that explains the P2V(V2P())
20:21:03 <glx> so 0x16 is cost ?
20:21:09 <TrueBrain> yes
20:21:25 <TrueBrain> but I don't get why my code differs from the old code ... it looks identical :(
20:22:22 <TrueBrain> ah, some slightly wrong logic :)
20:22:36 <TrueBrain> did you know that AIs in campaign 1 and 2 repair their buildings slower than in later? :p
20:23:13 <TrueBrain> yes, 42 credits :)
20:23:23 <TrueBrain> now my enhanced routine .. there :)
20:23:54 <TrueBrain> SmatZ: tnx btw, it is nice to know they rebalanced that in 1.07 :)
20:23:59 <SmatZ> :-)
20:27:44 <TrueBrain> and another dead piece of code ...
20:28:02 <TrueBrain> when there is a repair-structure, it has some code for something ... dunno ... it is never called :p
20:28:11 <SmatZ> :-D
20:33:17 <TrueBrain> oh well, fixed it up nevertheless :)
20:36:16 <tneo> we need autosave :-P
20:38:50 <TrueBrain> the later in the campaigns, the sooner the AI starts repairing structures :)
20:39:05 <TrueBrain> @base 16 10 5f
20:39:05 <DorpsGek> TrueBrain: 95
20:40:46 <TrueBrain> glx: can you confirm something for me? from -l__048E:
20:41:00 <TrueBrain> if (emu_ax == emu_get_memory16(emu_ds, 0x00, 0x3A38)) goto l__04BD; <- if not AI, skip the next part
20:41:21 <TrueBrain> then it calculates an emu_ax value based on campaignID (38B2), and checks if it is lower than emu_si
20:41:31 <TrueBrain> but .. when it is ... it puts the same value in emu_ax AGAIN?!
20:42:00 <tneo> TrueBrain, how can I know what the latest r is ?
20:42:07 <TrueBrain> 'svn info'
20:42:54 <tneo> ok and how can I know which r I have atm?
20:43:06 <TrueBrain> svn info :)
20:43:15 <tneo> ahh
20:43:17 <tneo> ok
20:43:20 <TrueBrain> euh, no, not true
20:43:29 <TrueBrain> svn info svn://svn.opendune.org
20:43:36 <TrueBrain> or svn info -r HEAD
20:44:20 <tneo> deploy crashed program
20:44:40 <tneo> will that be fixed when I update to latest r ?
20:44:45 <TrueBrain> possible
20:44:48 <TrueBrain> most likely not :)
20:44:55 <TrueBrain> so send the your crash.bin ;)
20:44:55 <tneo> mantis?
20:45:53 <TrueBrain> sure
20:46:29 <TrueBrain> ah, no, it is not when it is going to repair, it is how fast it builds units :)
20:47:12 <TrueBrain> only in the last campaign it is at full speed
20:47:13 <DorpsGek> Bugs: http://bugs.opendune.org/view.php?id=11 :: Bug Created :: Deployed Base Deployement Vehicle and program crashed
20:47:15 <TrueBrain> the rest it is slowed down
20:47:34 <TrueBrain> tneo: it won't be today I add the code for it, so for now I suggest not to use it ;)
20:48:32 <tneo> huh?
20:48:42 <TrueBrain> that I won't be handling the bug report today
20:48:46 <tneo> oh
20:48:47 <TrueBrain> but tomorrow or something
20:48:48 <tneo> that is ok
20:48:53 <tneo> no worries :-)
20:50:21 <TrueBrain> @base 16 10 D
20:50:21 <DorpsGek> TrueBrain: 13
20:51:41 <glx> TrueBrain: it cap it
20:52:00 <TrueBrain> glx: but there really is twice the same calculation there, not?
20:53:22 <glx> hmm yes but then it put ax in si
20:53:39 <TrueBrain> yes. but the value is already in ax, so the extra calculation is completely useless
20:53:43 <TrueBrain> but okay, tnx, all I wanted to know :)
20:53:45 <glx> it's a case of recalc to be sure
20:53:50 <SmatZ> hehe
20:54:32 <glx> maybe there's another goto l__04B0
20:54:59 <glx> hmm there's not
20:58:06 <TrueBrain> haha, I think I made a miscalculation somewhere .... ;)
20:58:22 <SmatZ> repairing is cheap now :) it almost makes no sense to build slabs
20:58:36 <TrueBrain> SmatZ: and therefor OpenDUNE now don;t degrade buildings when build on slabs
20:58:40 <TrueBrain> to give them sense again :)
20:58:51 <SmatZ> ah, yeah :)
21:00:28 <SmatZ> hmm it seems to have deadlocked
21:00:36 <TrueBrain> happens
21:00:39 <SmatZ> just after starting first mission
21:00:40 <SmatZ> ok
21:00:47 <TrueBrain> it shouldn't
21:00:49 <TrueBrain> but it happens :)
21:00:52 <SmatZ> hehe
21:00:59 <TrueBrain> never in a way we can repeat it
21:01:25 <SmatZ> again :(
21:01:34 <TrueBrain> then it is odd :)
21:03:39 <SmatZ> is loading of dune2 games supposed to work?
21:03:45 <TrueBrain> yes
21:03:45 <SmatZ> Program Termination: jumped to 433B:04E6, which is not decompiled.
21:03:50 <TrueBrain> possible older games give a crash
21:03:58 <TrueBrain> but then I suggest you upload the crashlog (or the savegame ;))
21:04:12 <SmatZ> true, it's from dune2 1.0
21:04:22 <TrueBrain> so please upload the savegame at bugs.opendune.org :)
21:05:34 <SmatZ> in 1.07 it gives warning about "Original savegames are not supported in this version" :(
21:05:43 <TrueBrain> :'(
21:08:50 <SmatZ> do you need crash.bin as well, or is savegame + crash message enough?
21:09:00 <TrueBrain> savegame in this case is sufficient
21:09:15 <SmatZ> ok :)
21:10:20 <TrueBrain> I see no mistake in my buildCost calculations, yet it doesn't work :(
21:11:25 <DorpsGek> Bugs: http://bugs.opendune.org/view.php?id=12 :: Bug Created :: crash when loading Dune2 1.00 savegame
21:11:31 <SmatZ> :-(
21:11:39 <TrueBrain> ah, there :)
21:11:43 <TrueBrain> and tnx SmatZ :) Will look at it tomorrow
21:11:48 <SmatZ> thank you, TrueBrain :)
21:12:16 <glx> it just needs to load the savegame in JIT ;)
21:12:47 <TrueBrain> I think I still broke something ... now when a building finishes, the game crashes :p
21:12:51 <TrueBrain> with a jump to 0000:0000 :p
21:13:07 <SmatZ> looks null
21:13:21 <glx> hmm 0000:0000 is the result of FindNext when there's no next
21:15:17 <glx> do you know the origin of the call ?
21:16:04 <TrueBrain> of course, that is printed ;)
21:16:18 <Xaroth> SmatZ: are 1.00 savegames loadable in the -normal- 1.07?
21:16:37 <SmatZ> Xaroth: sadly, no
21:16:37 <glx> Xaroth: [22:05:40] <Sma.tZ> in 1.07 it gives warning about "Original savegames are not supported in this version" :(
21:17:18 <Xaroth> i thought as such, i recall reading a post by MrFlibble ( hrr hrr @ tb ) about it
21:18:58 <TrueBrain> k, fixed and working ... good night all :)
21:19:35 <Xaroth> nn TrueBrain
21:20:06 <TrueBrain> about half-way through that function, found all kind of interesting shit :)
21:20:52 <glx> should be the same for the other 4 :)
21:20:58 <glx> (or 3)
21:48:10 <DorpsGek> Bugs: http://bugs.opendune.org/view.php?id=13 :: Bug Created :: Random crash with log
22:12:27 <Xaroth> hm, I -think- my Tile_* changes are 'working' o_O
22:30:44 <planetmaker> it's not quite tomorrow, but well:
22:30:46 <planetmaker> http://www.openttdcoop.org/files/pm/crash01.bin
22:31:06 <planetmaker> Program Termination: jumped to 43B5:0566, which is not decompiled.
22:31:08 <planetmaker> The jump was triggered at decompiled/cs__B520.c:716
22:31:09 <planetmaker> The jump appears to originate from B520:0566.
22:31:24 <planetmaker> (r499)
23:04:45 <Xaroth> gah, made it crash without a console open
23:05:01 <planetmaker> hm, just got another crash
23:05:23 <planetmaker> Program Termination: jumped to 348B:0034, which is not decompiled.
23:05:24 <planetmaker> The jump was triggered at decompiled/cs__1A34.c:3671
23:05:26 <planetmaker> The jump appears to originate from 1A34:1D61.
23:05:54 <planetmaker> http://www.openttdcoop.org/files/pm/crash02.bin