#exult@irc.freenode.net logs for 31 Mar 2002 (GMT)

Archive Today Yesterday Tomorrow
Exult homepage


[00:08:02] * wjp has to go
[00:08:04] <wjp> night
[00:08:06] <-- wjp has left IRC ("[x]chat")
[00:30:35] --> bj0ern|W has joined #exult
[00:30:39] <bj0ern|W> hrm
[00:31:00] <-- Fingolfin has left IRC ("brb")
[00:32:51] --> Fingolfin has joined #exult
[00:34:30] <bj0ern|W> ahaa, it works
[00:50:59] <-- bj0ern has left IRC (Read error: 110 (Connection timed out))
[01:10:00] <-- bj0ern|W has left IRC (Read error: 110 (Connection timed out))
[01:48:20] --> Kirben has joined #exult
[01:48:20] --- ChanServ gives channel operator status to Kirben
[02:32:18] <-- Fingolfin has left IRC ("good night, folks")
[03:28:12] <-- MisterP has left IRC (Remote closed the connection)
[03:51:49] --> MisterP has joined #exult
[05:11:52] <-- MisterP has left IRC (Remote closed the connection)
[05:55:37] <-- Soul|SERV has left IRC ("Read error 54: Connection reset by queer")
[06:36:48] --> MisterP has joined #exult
[07:04:54] --- MisterP is now known as MrP[zZz]
[07:07:28] <-- MrP[zZz] has left #exult ("Client Exiting")
[10:29:06] --> wjp has joined #exult
[10:29:06] --- ChanServ gives channel operator status to wjp
[10:29:15] <wjp> hi
[10:30:46] <Darke> Hi.
[10:45:37] <Darke> Ok, a lot more fixing and I've got ucxt _almost_ working. For some reason it's finding a 0xC3 opcode in that file, but there's no opcode defined with that number. So I'm suspicious again if it's a problem with the file, or with my code, I don't suppose you could check the md5sum of your's against the copy I have?
[10:45:47] <Darke> b1d49e02ac74290c7f872ad37cf378a0 usecode.FR.book.new
[11:32:03] <wjp> same here
[11:32:07] <wjp> 3C?
[11:32:10] <wjp> uh, C3?
[11:32:23] * Darke nods. He's not sure where it comes from either.
[11:32:25] <wjp> not really an all-to-common byte in there. Only occurs a couple of times in ADDSI offsets
[11:32:53] <wjp> btw, answer to the question in your code: you miscalculate the code_size: it's funcsize - datasize - (4 + num_externs) * 2
[11:32:56] <wjp> (4 = #{ datasize, numargs, numvars, numexterns })
[11:33:09] <Darke> Hmm... maybe I haven't edited the ADDSI32 opcode correctly...
[11:33:39] <Darke> Thanks. I was actually just looking at that yesterday and wondering where I got the calculation from.
[11:34:38] <wjp> there's no C3's behind the only ADDSI32
[11:34:42] <wjp> (unless they're past the EOF)
[11:34:49] <wjp> if it's an extended function the code size is another 2 bytes shorter, I think
[11:42:47] <wjp> at what offset are you finding a C3, btw?
[11:48:57] <Darke> Code offset 0x728 I think.
[11:49:11] <wjp> that's past the EOF
[11:50:56] * Darke hmms... and throws a few assert(!f.eof())'s around. The should have been in there in the first place. Thanks.
[11:53:28] <wjp> EOF = End of Function, btw ;-)
[11:53:56] * Darke ahhs. No problem. He should have some end of files in there too though.
[11:53:58] <wjp> the function after 2C1 is 2C3, so the first byte of that function is a 0xC3
[11:55:14] <Darke> Eh? How does it get there though. It's halting at the start of a while loop where it's first test is to see if it's not past the end of the function... umm... perhaps there is a difference in the code size depending upon whether it's a ext32 function or not.
[11:55:31] <wjp> <wjp> if it's an extended function the code size is another 2 bytes shorter, I think
[11:55:57] * Darke noticed, thanks. <grin> He's coding it now to check.
[11:56:23] <wjp> (the difference is the length of the datasize field)
[12:04:28] --> sb-x has joined #exult
[12:04:39] <wjp> hi
[12:04:47] <Darke> Hi.
[12:05:29] <sb-x> hello
[12:07:27] * Darke blinkyblinks and can't _really_ believe that it worked.
[12:08:11] <sb-x> ucxt
[12:08:12] <sb-x> ?
[12:09:31] * Darke nods. With ext32 header and opcodes. But the output format needs a few minutes 'prettifying' it.
[12:11:23] <Darke> Just for reference, yes it is actually easier to modify the conf/ formatted file then the original 'table' format. Not sure why though.
[12:12:45] <sb-x> the info at the top seems out of date
[12:12:50] <sb-x> about columns and such
[12:12:55] <sb-x> commented with #
[12:15:07] <Darke> <nod> I was just fiddling with it before, trying to work out how to 'nicely' comment the file structure.
[12:16:52] --> Colourless has joined #Exult
[12:16:52] --- ChanServ gives channel operator status to Colourless
[12:17:00] <wjp> hi
[12:17:01] <Colourless> yo
[12:17:31] <Darke> Hi.
[12:19:58] <sb-x> hello
[12:26:17] <Darke> Incidentally, Hoppy Easter (or Day of Chocolate giving) to those in the appropriate timezones. <grin>
[12:26:49] <Colourless> talking about such things, why haven't you given me any eggs, rabbit?
[12:27:55] * sb-x gives Colourless a chocolate cream egg.
[12:28:38] <Colourless> hmmm
[12:28:43] <Darke> Here then: http://www.killfrog.com/00/bunny.html http://www.killfrog.com/01/bunny2.html <grin> They're both flash, and... umm... a little crude, but what else you you expect from killfrog.com. <grin>
[12:29:59] <Colourless> hmm, maybe later
[12:31:27] * Darke thinks they're a little childish, but others seem to like them, so... <shrug>
[12:32:53] <Kirben> poor bunny
[12:36:49] <Darke> "Poor bunny. Poor, poor bunny..." <deep-evil-laughter>
[12:37:24] * Darke evades thrown objects for that horrible thing that resembled a pun.
[12:42:23] <Colourless> could you evade a nuclear bomb?
[12:43:01] * wjp guesses Darke could probably evade the bomb. The following explosion would be a different matter ;-)
[12:43:25] <Darke> Colourless: Depends upon the detonation radius and how long I had until it exploded. <grin>
[12:46:31] * Darke hunts around for other Easter related urls he's acquired this year... hmm... there's this: http://www.non-sequitur.com/index.php3?inmonth=3&inday=31&inyear=2002&x=28&y=5 Though it's more 'Garfield' type surreality that amuses, rather then actually being funny. <grin>
[12:48:44] <wjp> :-)
[12:50:42] <Colourless> heh
[12:50:56] * Darke looks innocent. He's not carnivorous. He's certainly omnivorous though.
[12:51:13] <Colourless> hmm, well what about your friend?
[12:52:28] <Colourless> i wouldn't think a name of sharptooth would come about if the those teeth weren't used against, at least other rabbits ;-)
[12:52:50] * Darke is pretty sure all the bunnies he knows are omnivorous too. It's not good to have an unbalanced diet.
[12:53:05] <Darke> SharpTooth was named ironically. <grin>
[12:53:48] <Colourless> i see
[12:55:48] <sb-x> What would cause a C program error where 4 != 4?
[12:56:52] <Darke> It depends, I presume it's not a simple case of assert(4==4);?
[12:57:01] <Colourless> well, it's impossible to know unless i knew what the source looked like
[12:58:01] <sb-x> heh not again
[12:58:06] <sb-x> sorry it was a misplaced semicolon :P
[12:59:12] <Darke> sb-x: See! This is why I'm always so picky about tidying up the puncuation people keep throwing around this place! It always gets into odd places and causes annoyance. <grin>
[12:59:55] * sb-x gives Darke a semicolon.
[13:00:01] * Darke is in a weird mood tonight.
[13:00:13] * Darke crunches on the semicolon. Tasty!
[13:00:38] <Colourless> i prefer avoiding eating all types of colon's
[13:01:21] * wjp hands that apostrophe to Darke
[13:01:31] <Colourless> :-)
[13:01:50] <Colourless> IMO it looks better with that ' than without.
[13:02:37] --> bj0ern has joined #exult
[13:02:41] * sb-x ~'s.
[13:02:46] * Darke has nightmares about hemi-demi-semi-colons when he reads too much sheet music with such weird quavers.
[13:02:56] <wjp> hi
[13:02:58] <bj0ern> hi
[13:02:58] <sb-x> hi
[13:03:00] <Darke> Hi.
[13:03:15] <Colourless> hi
[13:03:20] <sb-x> hello
[13:03:53] * Darke captures sb-x's redundant 'hello' in a bottle for next time.
[13:10:55] * Darke wonders if there's a market demographic you could sell 'hello in a bottle' to. The terminally lazy? People who can't speak? Hmm...
[13:11:18] <sb-x> japan
[13:11:23] <Colourless> people who can't speek might not be too impressed
[13:12:35] <Darke> It might be good for tourists, bottle up stock phrases so they can use them without having to actually know them.
[13:12:51] <Colourless> yes, it could be useful for that
[13:15:02] <sb-x> i think they would buy it in japan
[13:15:11] <sb-x> native people even
[13:15:28] <Colourless> in japan they will by almost anything
[13:15:34] <Colourless> s/by/buy/
[13:16:19] <sb-x> especially if it is new and has flashy lights on it and big neon letters
[13:16:52] <Colourless> and it's got to be small though.... really really small
[13:17:04] * Darke nodnodnods. Agreed. He could quite happily see them purchasing it. <grin>
[13:17:20] <sb-x> when you press the button to make it talk it should spin around as well
[13:24:54] * wjp watches ucxt blow up on the initialization of the Configuration object
[13:25:59] * Darke blinks.
[13:26:32] <wjp> it doesn't seem to like my -ifile parameter
[13:27:10] <Darke> Hmm... give me a sec and I'll find the command line I used whilst testing.
[13:28:16] <Darke> This is what I used: `ucxt -iusecode.si.mod -vv -si 02C1` you probably want to get rid of the `-vv`.
[13:28:30] <wjp> -i?
[13:28:36] <wjp> ah...
[13:28:46] <wjp> -ifile = -i followed by file
[13:29:03] * wjp hits self
[13:29:04] <sb-x> that confused me too
[13:29:25] <wjp> it now segfaults while reading 0x96
[13:29:39] <-- bj0ern has left IRC (Read error: 110 (Connection timed out))
[13:29:40] <Darke> Suggestions as to how it might be better done are welcome. <grin>
[13:29:50] <sb-x> -i <file> :)
[13:29:56] * wjp agrees with sb-x
[13:30:30] <Darke> There's just so many ways of doing it to choose from. <grin> I think that method may be better.
[13:31:19] <sb-x> i have to go
[13:31:23] <sb-x> ill be back tomorrow
[13:31:24] * sb-x waves.
[13:31:25] <wjp> bye
[13:31:25] <-- sb-x has left IRC ("X-Chat [1.6.4]")
[13:31:26] <Darke> Night.
[13:32:21] <Darke> Hmm... it appears to work fine for me. Are you just running ucxt in the directory in the development tree? Or did you `make install` it?
[13:32:25] <wjp> 2C1 seems to work, but 0096 segfaults it
[13:32:39] * Darke blinks.
[13:34:38] --> royalsexy has joined #exult
[13:35:08] <Darke> wjp: Does it segfault whilst reading? Or half way through the output?
[13:35:23] <wjp> halfway
[13:35:36] <wjp> right after the "push itemref" at 0x12
[13:35:46] <wjp> in demunge_ocstring
[13:36:21] <wjp> can't tell you what line, since it's in an inlined string function
[13:37:02] <Darke> Got it. Is there two files in the ucxt/data directory one called u7siintrinsics.data and one u7bgintrinsics.data?
[13:37:20] <wjp> yes
[13:37:57] <wjp> where should it read these files from? exult data dir?
[13:38:54] <Darke> They should either be in the exult data dir, or you make a change to the .exult.cfg file to add a config/ucxt/root entry in it, pointing to the ucxt/data directory.
[13:39:27] <Darke> On a 'make install' the files are put in the 'proper' place. But in the dev tree they can't be found for some reason.
[13:39:46] <Darke> Or they should be put in the proper place anyway.
[13:40:29] <wjp> ok, works now
[13:41:03] <wjp> I had the config/ucxt/root entry, but it pointed to the data dir in the source tree. (not the build tree)
[13:41:20] * wjp doesn't build exult from his source tree, btw
[13:42:24] * Darke nods. Those two files are created with the head2data program from the exult headers, back when he was trying to make the thing more generic/portable. <grin>
[13:45:41] * royalsexy downloads linux so he can play exult in linux :P
[13:45:50] <wjp> lol
[13:45:56] <royalsexy> 'sup all :)
[13:45:59] <wjp> that's the spirit :-)
[13:46:04] <royalsexy> heh
[13:46:10] <royalsexy> i needed an update anyway
[13:46:11] <royalsexy> :)
[13:46:15] <Colourless> jeff's plan seems to be working
[13:46:39] <wjp> indeed :-)
[13:46:45] <royalsexy> is that the world domination plan?
[13:46:49] <royalsexy> oops
[13:46:52] * royalsexy shuts up
[13:47:02] <royalsexy> shouldn't have mentioned that one
[13:47:08] <wjp> the "convert world to Linux" plan, actually :-)
[13:47:09] <wjp> hehe :-)
[13:48:06] <royalsexy> ahh i was close :)
[13:48:25] <royalsexy> redhat 7.1 was shitting me so i'm going to try mandrake
[13:48:27] <royalsexy> <sigh>
[13:48:36] <royalsexy> and free bsd? omg thats ugly!
[13:48:42] <royalsexy> so
[13:49:09] <royalsexy> anything happening on the "everyone's favourite port" front?
[13:49:11] * Darke points at SuSE.
[13:49:24] <royalsexy> hrm
[13:49:31] <royalsexy> only 4% complete of mandrake
[13:49:37] <royalsexy> what the heck
[13:49:43] <royalsexy> is it good Darke?
[13:49:51] <wjp> 1.4Gb will take a while, no matter how fast your connection is :-)
[13:49:56] <royalsexy> packages and all that?
[13:49:59] <royalsexy> heheh
[13:50:02] <royalsexy> yeah i know
[13:50:03] <royalsexy> i'm on dialup
[13:50:14] <royalsexy> one iso takes about 2 days
[13:50:20] <royalsexy> :)
[13:50:24] <wjp> ouch
[13:50:34] <Darke> royalsexy: I quite like it. I've used Mandrake before, it's not too bad, and I really don't like Red Hat. <grin>
[13:50:48] * wjp is quite happy with RH
[13:51:24] <royalsexy> redhats package management was really annoying e
[13:51:25] <royalsexy> me
[13:51:42] <royalsexy> trying to figure out dependancies to download kde2
[13:51:43] <wjp> Mandrake uses the same system, doesn't it?
[13:51:45] <Darke> SuSE uses rpms too. It also quite annoys me.
[13:51:51] <royalsexy> hrm
[13:52:01] <royalsexy> mandrake does too doesn't it?
[13:52:07] <Darke> I think so.
[13:52:12] <royalsexy> been a few years since i last used mandrake
[13:52:21] <royalsexy> and they're grown in version number a lot since then :)
[13:52:28] <wjp> Mandrake is basically Redhat + extras
[13:52:34] <Darke> It's been a couple of years since I've used Mandrake too.
[13:52:36] * royalsexy nods
[13:52:40] <wjp> at least, it was around version 7
[13:52:52] <royalsexy> yeah thats what i last usecd
[13:53:09] * wjp switched from Mandrake 7 to RH 7
[13:53:37] * wjp didn't like Mandrake's installer destroying his partition table...
[13:53:51] <wjp> luckily RH's didn't do that :-)
[13:54:04] <royalsexy> yeah? mandrakes was quite friendly to my system
[13:54:04] <Darke> Ya. That's bad. <grin>
[13:54:35] <royalsexy> freebsd didn't even see most of my partions
[13:54:48] <royalsexy> ack
[13:54:51] * royalsexy learns to type
[13:55:00] <royalsexy> dunno whats with my typing tonight
[13:55:13] <royalsexy> too many channels open :)
[13:55:42] <wjp> "tonight" ? Australian?
[13:56:33] <royalsexy> yep
[13:56:42] <royalsexy> another one :)
[13:56:43] <wjp> ugh... another one ;-)
[13:56:50] <royalsexy> heheh
[13:57:01] <Darke> And also, by the looks of things, a fellow Brisbaneite. <grin>
[13:57:07] <royalsexy> yep
[13:57:09] * royalsexy waves
[13:57:19] * wjp wonders what it is with Exult and Australians
[13:57:26] <royalsexy> you in kelvins grove?
[13:57:29] <Colourless> you must know that all of Australia likes Exult
[13:57:32] * Darke wavies and guesses you can kind of tell where he is. <grin>
[13:57:35] <royalsexy> its just ultima7
[13:57:39] <Darke> royalsexy: Enoggera actually.
[13:57:50] <royalsexy> its the latest game over here :P
[13:57:54] <royalsexy> ahh cool
[13:57:58] <royalsexy> i'm in durack
[13:58:21] <royalsexy> man i remember the day that ultima8 came out in brisbane
[13:58:27] <royalsexy> that was such a disapointment
[13:58:48] <royalsexy> well not for about a week i guess
[13:58:55] <royalsexy> it was fun about that long
[13:59:10] * Darke can't remember the day any of the ultimas came out. <grin> He doesn't really remember much of a fuss about them at the time.
[13:59:42] <Colourless> my system was too slow for U8 so I never got far enough to hate it before giving up
[14:00:20] * wjp kind of liked U8
[14:00:29] <wjp> of course, it was the first Ultima I played
[14:00:35] <Colourless> many years later waiting of u9 later i finally played ad completed u8, and enjoyed it quite a bit... of course I was expecting like the worst gaming experience ever
[14:01:00] * Darke thought U8 looked cool. Despite the lack of extra party members. But his system could just barely run U7, so he never acquired it until recently.
[14:01:42] <royalsexy> heheh
[14:01:52] <royalsexy> i had a 486 33mhz!!!
[14:02:08] <royalsexy> with well hacked autoexec and config.sys for running ultimas
[14:02:13] <wjp> I think I played U8 on a dx2/66
[14:02:44] <Darke> royalsexy: Me too. <grin> The system lasted well for about 7 years or so until the motherboard fused.
[14:03:12] <Colourless> i tried on a 386 SX 40 with 4 mb ram... i later played it with at a Celeron 450A with lots of ram :-)
[14:03:31] <Colourless> s/at//
[14:04:29] <Colourless> saving and map changes were really really painful on the 386
[14:04:39] * Darke can imagine.
[14:04:49] <Colourless> i was playing it unpatched too... i didn't even know there was a patch :-)
[14:06:22] <wjp> same here :-)
[14:06:38] <wjp> all that jumping... *shudder*
[14:06:51] * wjp kind of got the hang of it after a while, though
[14:07:06] * Darke is so glad he never had to play it without a patch. One day he actually might get to play it with pentagram. <grin>
[14:07:19] <Colourless> i didn't get far enough to get to the really bad jumping parts but from memory I had pretty much worked out the jumping and knew when a jump was too far, and how to properly position a jump
[14:08:01] <wjp> yeah, they were just fixed distances/directions
[14:08:18] <Colourless> exactly
[14:08:22] <wjp> ...and then you got the 'air walk' spell, and you got to start over :-)
[14:08:52] <Colourless> i imagine at first pentagram is going to play as if it's unpatched :-)
[14:09:13] <wjp> yeah, that's the way the jumping animation is coded into anim.dat
[14:09:35] <wjp> that jumping was probably quite an ugly engine hack...
[14:09:44] <wjp> (that == patched)
[14:09:53] <Colourless> isn't that going to be fun for u8 players.... pentagram is going to have to be patched to support the u8 patch style jumping :-)
[14:10:43] <Colourless> i think it should be kept a toggle in the end... people should be able to choose the style
[14:10:51] <wjp> yeah, I agree
[14:14:00] <royalsexy> heh
[14:14:03] <royalsexy> pentagram?
[14:14:11] <royalsexy> the exult of u8 i take it?
[14:14:41] <Colourless> pentagram is an idea :-)
[14:15:15] <royalsexy> oh ok
[14:15:19] <royalsexy> good idea
[14:15:23] <royalsexy> u8 needs some work :)
[14:15:45] <royalsexy> i must say i like what you guys did with the paperdolls in u7
[14:15:52] <royalsexy> made them look like they do in si i mean
[14:16:01] <Colourless> it's more of a software engineering project than anything else at the moment. we do more discussing about what we need to do, rather than actual doing :-)
[14:16:17] <royalsexy> heheh
[14:16:19] <royalsexy> thats ok
[14:16:27] <royalsexy> all part of the project lifecyle
[14:16:53] <Colourless> call it learning from experience.... exult has been very much unplanned... and it shows in places :-)
[14:19:03] <royalsexy> hehehe
[14:19:09] <royalsexy> i haven't played far enough into it
[14:19:22] <royalsexy> but the map editting works good
[14:19:37] <royalsexy> though i can't get the gimp plugin to plug-in
[14:19:47] <royalsexy> :P
[14:20:07] <wjp> hm, shouldn't 'make install' do that?
[14:20:53] <royalsexy> i'm still on 0.96beta
[14:21:02] <royalsexy> and it didn't for me
[14:21:19] * wjp notices he has a /usr/local/bin/u7shp and a /usr/lib/gimp/1.2/plug-ins/u7shp
[14:21:23] <royalsexy> my linux is broken due to too much XP at the moment
[14:21:32] * wjp guesses one of those two shouldn't be there
[14:21:34] <royalsexy> so i can't tell right now
[14:21:41] <royalsexy> heh
[14:25:25] <wjp> *sigh*... now that the disassembly display is hyperlinked, I guess I should also add a 'back' button
[14:31:27] <Colourless> ??
[14:31:48] <wjp> (about the usecode debugger)
[14:32:10] <Colourless> oh
[14:32:34] <wjp> latest screenshot is http://www.math.leidenuniv.nl/~wpalenst/debugging5.png
[14:33:07] <wjp> if you imagine the offset and function operands to be blue you'll have the version I have now :-)
[14:36:37] <Colourless> until you can show embedded debugging info, and you have usecode with debugging info, your debugger is only *so* useful
[14:36:48] <wjp> I know
[14:37:07] <wjp> ucc will have to be heavily modified for that, though
[14:37:33] * Colourless has no idea how ucc works internalls
[14:37:42] * Colourless sighs
[14:37:48] <wjp> syntax-tree based
[14:38:26] <wjp> I'm planning to have the debugger show the actual source if that's available. (and also step through that line-by-line)
[14:38:53] <wjp> at the moment I'm mostly working on the back-end (the part in Exult itself) and working out some gtk stuff
[14:39:18] <Colourless> edit-and-continue ? :-)
[14:39:27] <wjp> maybe :-)
[14:39:36] <Colourless> that would actually be more of a feature of exult than the debugger
[14:39:49] <wjp> yeah
[14:40:00] <Colourless> all you'd really need to do would be to reload the usecode file
[14:40:09] <wjp> and adjust all stack frames
[14:40:23] <wjp> and that's an undefined operation in some cases
[14:40:32] <Colourless> that is if you were updating usecode while it was executing
[14:40:57] <wjp> reloading usecode while not in the interpreter is already supported
[14:41:06] <wjp> (exult-studio has a "reload usecode" menu item)
[14:41:35] <Colourless> hmmm, i obviously haven't used exult-studio since that was implemented... or just didn't notice it :-)
[14:41:57] <Colourless> of course being about to do it without running exult-studio would be useful
[14:42:26] <wjp> it's just a case of sending an "Exult_server::reload_usecode" message to exult
[14:43:10] <wjp> and reloading the usecode yourself too, of course
[14:59:09] * Darke notices that ucxt uses 50Meg of memory by the time it's decoded the entire SI USECODE file in both asm and ucs. I don't think we're going to be integrating it (even jokingly) with the debugger anytime soon. <grin>
[15:00:11] <wjp> how about having ucxt output (preprocess) something that the debugger could use?
[15:00:51] <wjp> so you would decompile the entire usecode file, store it in a usecode.src file somewhere, and have ucdebugger use it
[15:04:05] <Darke> As a very basic amount of information, currently `ucxt -fz -ac -uc 96` will output the source with basic 'Offset' comments relating to the offset to the position of the last opcode in the next line of code. This could technically easily be expanded to list all the offsets for the current line of code. Perhaps at the end of the line of code, rather then the line before it.
[15:04:36] <Darke> (just an example)
[15:04:37] <Darke> // Offset: 0005
[15:04:37] <Darke> if(!(event == 0x0001)) goto labelFunc0096_0038;
[15:04:37] <Darke> // Offset: 0010
[15:04:37] <Darke> if(!UI_get_item_flag(item, 0x000A)) goto labelFunc0096_001C;
[15:05:08] <Darke> If that helps make sense of my attempted informative description. <grin>
[15:05:13] <Colourless> actually i would think line before would be easier to parse
[15:05:44] <Colourless> of course that's just me :-)
[15:06:20] * Darke , surprisingly enough, thinks so too. <grin>
[15:10:47] <Darke> Just outputting asm for the entire SI USECODE takes 30MB by the time it's finished, 20MB just at the start. Just outputting ucs takes 44MB.
[15:11:22] * Darke is almost certain he's got a memory leak somewhere in here.
[15:11:38] <Colourless> fun Fun FUN!
[15:13:04] <Colourless> i had a 4k memory leak per frame in a program i wrote once. since the program ran at 60 fps the memory usage went up rather faster. after about 5 mins i was wondering why the program was paging to the disk like crazy, and then eventually crashing
[15:13:15] <Colourless> s/faster/fast/
[15:13:20] <Darke> I'm also using... probably close to twice as much space as necessary to store the opcodes as they're loaded from the file. I'm storing both the bytes themselves, then the interpreted 'values', and not flushing the bytes vector when I'm done with it.
[15:13:27] * Darke ouches. Nasty.
[15:14:00] <wjp> yow... machine almost died when I tried to memprof ucxt
[15:14:19] <wjp> memory usage looked like somewhere near 700Mb
[15:14:22] <Darke> memprof?
[15:14:34] <wjp> some kind of memory leak detector
[15:14:39] * Darke blinkies. That's _really_ not right. <grin>
[15:15:00] <wjp> I've seen memprof do that sort of thing before, though
[15:15:22] <Colourless> on exult? :-)
[15:15:29] <wjp> yeah :-)
[15:16:23] * wjp tries again
[15:16:26] <Colourless> well, exult doesn't have any memory leaks, at least not at the moment as far as I have been able to tell. memory usage usually hovers around 17 mb here
[15:16:38] <wjp> uh oh...
[15:17:19] * Darke earperks. 'uh oh's are usually _bad_ right?
[15:17:24] <wjp> yeah :-)
[15:17:49] <wjp> good thing VCs are usually pretty responsive even when nearly out of memory
[15:17:51] <wjp> :-)
[15:18:14] <Colourless> so what happened?
[15:18:17] * Darke snerks. Umm... yeah.
[15:18:27] <wjp> oh, memprof was sucking up all memory again
[15:18:27] <Colourless> did you go over a gig?
[15:18:37] <wjp> not sure, top wasn't responding at the time :-)
[15:19:25] <Darke> Hmm... I'm guessing that's a sign there is really not enough memory. <grin>
[15:19:44] <wjp> hm, when memprof finished running ucxt (without generating a leak report), half the memory usage bar is blue and the other half is yellow
[15:19:56] * wjp wonders what that means
[15:20:44] <wjp> probably that it didn't free half of its memory at the end
[15:21:32] --> bj0ern has joined #exult
[15:22:40] * wjp killed it at 510Mb this time
[15:22:48] <wjp> looks like memprof may have some leaks :-)
[15:23:22] <Colourless> run it on itself :-)
[15:23:46] --> Fingolfin has joined #exult
[15:23:53] <wjp> hi
[15:23:57] <wjp> and hi
[15:24:01] <Fingolfin> hi
[15:24:11] <Fingolfin> and hi ?
[15:24:13] --- ChanServ gives channel operator status to Fingolfin
[15:24:24] <wjp> bj0ern arrived just before you :-)
[15:24:47] <Fingolfin> ah =)
[15:24:49] <Colourless> hi
[15:25:16] <Darke> Hi, hi.
[15:25:29] * Fingolfin found out yesterday that coredumps can take a *lot* of disk space
[15:26:12] <Darke> wjp: (memprof) Looks like it. Either that or it just can't handle circular pointers.
[15:28:20] * Darke ponders something very evil, but it would probably work quite nicely to keep memory useage down somewhat.
[15:28:23] <wjp> it seems to work a lot better halfway through
[15:28:38] <wjp> there's hundreds of leaks of size 100 bytes
[15:29:25] <wjp> thousands, actually
[15:29:45] <Darke> That might be because of conf/, OTOP, it could be misdetecting the way I create setup my Goto sets.
[15:29:59] <wjp> it seems to be related to strstreams
[15:30:34] <wjp> there's also a few hundred 24 byte leaks. These are malloc-ed by XMLnode::xmlparse
[15:31:25] <wjp> of course, maybe these things really aren't memory leaks. I don't know if memprof works properly if you run it halfway through
[15:32:05] <wjp> when I run ucxt on only 2C1 the 100 byte entries disappear
[15:32:26] <wjp> there's still lots of 24 byte leaks, though
[15:32:52] * Darke might poke at XMLnode::xmlparse to see if he can find that leak.
[15:33:02] <wjp> oh, but that was because 2C1 doesn't exist in BG...
[15:33:11] <wjp> if I run it on 2C1 in SI the 100 byte leaks are back
[15:33:44] <wjp> they're allocated by strstreambuf. (indirectly by demunge_ocstring)
[15:34:49] * Darke blinks. Curious.
[15:35:31] <wjp> some of these may just be things that aren't deleted at the end. I don't know exactly how memprof works
[15:36:05] <wjp> hey, line numbers
[15:36:23] <wjp> they 24 byte leaks are from XMLEntity.cc, line 340
[15:36:26] <wjp> s/they/the/
[15:36:40] <wjp> the 100 byte leaks from ucfunc.cc:892
[15:37:45] <Darke> Hmm... can you tell me what's on the ucfunc.cc line? My one's probably different yours at the moment. <grin>
[15:37:49] <wjp> str << c
[15:37:56] <wjp> (the default: case)
[15:38:09] <wjp> ...which really doesn't make any sense
[15:38:18] <Darke> <nod> Same with me, and agreed makes no sense.
[15:39:59] <Darke> The XMLEntity one doesn't make sense either, since the pointer is pushed into a vector. And I _know_ that's deleted, since I put the code there myself, it wasn't previously and was really messing with ucxt. <grin>
[15:40:41] <wjp> the 100 byte leaks do make sense, actually
[15:41:07] <wjp> you probably should delete the output of demunge_ocstring after using it
[15:43:01] <Darke> Eh? Clear the strstream? Or am I missing something...
[15:43:41] * Darke looks at the clock. Probably his mind, he really should have been in bed an hour ago. Oh well... <grin>
[15:44:16] <wjp> hm, you return str.str(), which probably copies the string
[15:44:39] * wjp nods... yes, str() returns a std::string, not a std::string&
[15:44:54] <Colourless> bad bunny :-)
[15:45:06] <Darke> It shouldn't. It should only return a const char * to the data inside it. stringstream returns the std::strings.
[15:45:10] <wjp> ...but strings should be ref-counted and CoW
[15:45:27] <wjp> it's not a stringstream?
[15:45:34] <wjp> ah..
[15:45:36] <Darke> Nope a 'strstream'.
[15:46:29] <wjp> oh great... the implementation of strstreambuf::str() isn't in the header
[15:46:33] <Darke> It's a rather old bit of code where I couldn't get stringstream to actually work for me. <grin> I was considering converting it to use 'stringstream' if possible. But it's a case of if it's not broken...
[15:46:45] <wjp> it's broken ;-)
[15:47:56] <Darke> And it's always going to be broken with people with broken compilers/libraries anyway. <grin> I'm just seeing if I can find exactly how str() 'should' work, just a sec.
[15:48:21] <wjp> you have to delete the char* returned by str()
[15:48:41] <wjp> (according to Josuttis' "The C++ STL", anyway)
[15:49:13] <wjp> ugh... no, you can't delete it
[15:49:18] <wjp> but you do need to delete it
[15:49:45] <wjp> according to Josuttis you should do the following:
[15:49:52] <wjp> char *s = str.str();
[15:49:57] <wjp> str.freeze(false);
[15:49:59] <wjp> return s;
[15:50:34] * Darke reads the same thing from the same book and ooh, icks.
[15:50:56] <wjp> that fixed the leaks
[15:51:03] <Darke> That's going to make it even harder to have strstream/stringstream portable code.
[15:51:31] * wjp is still in favour of just distributing the sstream header with exult...
[15:51:41] * Darke is tempted.
[15:52:18] <wjp> of course, this current way of doing it (the freeze(false) thingie) deletes the memory before the data is used...
[15:52:43] <wjp> (since the strstream leaves scope on the return)
[15:53:11] <wjp> so you'd probably have to strcpy the string first, return that, and delete if after using it..
[15:53:17] <wjp> s/if/it/
[15:54:27] <Darke> How about: `str.freeze(false); string tstr(str.str()); return tstr;`?
[15:55:18] <wjp> that would work
[15:55:22] <Darke> If the function wasn't so cumbersome to call as it is, I'd just pass a std::string to it so it can populate it for me.
[15:55:32] <wjp> no, it wouldn't
[15:55:51] <wjp> "char *s = str.str(); str.freeze(false); string tstr(s); return tstr;" would
[15:56:17] <wjp> or "string tstr(str.str()); str.freeze(false); return tstr;" for that matter
[15:57:19] * Darke nods. That makes more sense. std::strstream makes _no_ sense.
[15:57:43] <wjp> ok, the blue bar is now a lot bigger compared to the yellow bar :-)
[15:57:53] * wjp really needs a legend for this thing :-)
[15:58:15] <wjp> ok, and leak report now actually works :-)
[15:58:33] * Darke snickers.
[15:58:47] <wjp> it now appears to be a fixed 5Mb leak
[15:58:55] <wjp> (doesn't grow while running)
[15:59:19] <Colourless> i guess that will also effect exult too
[15:59:23] <Colourless> and pentagram :-)
[15:59:38] <wjp> and exult_studio, and ucdebugger :-)
[15:59:49] <Darke> That sounds like it might be a problem with conf/ then. But I can't see how it _really_ is a problem in that XMLNode.cc:340.
[16:00:11] <wjp> could that vector be discarded sometimes?
[16:00:40] * wjp browses list of leaks
[16:00:42] <Darke> Only if something throws an exception.
[16:01:04] <wjp> there's also a 512 byte leak from xmlparse
[16:01:14] <wjp> (line 197)
[16:01:32] <wjp> a 6336 line leak from xmlparse line 338
[16:01:37] <wjp> s/line/byte/
[16:01:55] <wjp> 1024 bytes from xmlparse 197
[16:02:29] <wjp> and 2 times 24 bytes from Configuration.cc:253
[16:03:14] <wjp> "trim(content)" ?
[16:03:40] <wjp> oh, wait, the leak is in trim
[16:03:51] <wjp> line 221
[16:03:59] <wjp> argh.. no, line 221 in a string header :-)
[16:04:08] <Colourless> heh
[16:04:19] <Colourless> let me guess, it's not in malloc? :-(
[16:04:23] * wjp is beginning to hate inlines :-)
[16:04:23] <Colourless> :-) i mean
[16:04:34] <Darke> Ok. I know why with the Configuration.cc one. No destructor and it 'new's something.
[16:04:38] <Colourless> gee, i typed that shockingly
[16:04:57] <Colourless> i meant to type: let me guess, it's now in malloc? :-)
[16:05:19] <wjp> no, malloc is further up in the call stack :-)
[16:05:32] --> flurotube has joined #exult
[16:06:38] <Colourless> look wjp, another Australian :-)
[16:06:47] <Colourless> hi flurotube :-)
[16:06:47] <wjp> the same australian, I think :-)
[16:06:58] <wjp> he's cheating :-)
[16:07:00] <Darke> Just drop this into Configuration.h in the Configuration class, and two memory leaks should go away. <grin>
[16:07:01] <Darke> ~Configuration() { delete xmltree; };
[16:07:03] <Colourless> quite, the name's different
[16:07:06] <Fingolfin> eeek, an australian!
[16:07:13] <Colourless> s/quite/quiet/
[16:07:34] <Darke> BTW, we now know that XMLNode is 24 bytes in size. <grin>
[16:07:47] <wjp> :-)
[16:08:07] <wjp> Configuration.h... full rebuild... yay :-)
[16:08:21] <Darke> Actually, that'll get rid of all the memory leaks you were seeing.
[16:08:28] <Darke> All the 24 byte ones anyway.
[16:08:29] <Colourless> exploring the inner secrets of the implementation of c++ :-)
[16:08:37] <wjp> the 6336 one is interesting :-)
[16:08:53] <wjp> but might be the same problem
[16:08:56] <Darke> It wasn't deleting the root node of the entire tree properly. It only deleted it when 'cleared'. <grin>
[16:09:12] <wjp> hm, could it be the string part of a comment node?
[16:10:25] <flurotube> yep
[16:10:28] <flurotube> hrm
[16:11:28] * wjp runs ucxt again
[16:11:36] <Darke> BTW, the memory leak wasn't going to be so bad in exult or anything of the other programs. Nothing uses conf/ as extensively as ucxt does. <grin>
[16:11:45] <wjp> ok, 92 leaks left
[16:11:54] <wjp> uh, no...
[16:11:58] <wjp> zero leaks left
[16:12:01] <Darke> Anything interesting? Or are they all in trim?
[16:12:03] * Darke ooohs.
[16:12:06] * wjp should wait until the program actually finishes :-)
[16:12:10] <bj0ern> hehe
[16:12:13] <-- royalsexy has left IRC (Killed (NickServ (Ghost: flurotube!royalsexy@057.a.002.brs.iprimus.net.au)))
[16:12:25] --- flurotube is now known as royalsexy
[16:12:31] <royalsexy> heh
[16:12:40] <royalsexy> first time i've used ghost command :)
[16:13:01] <wjp> :-)
[16:13:16] <royalsexy> what a handy thing
[16:13:26] <Colourless> so what's the difference between ghost and recover&release?
[16:13:46] <wjp> recover&release?
[16:13:50] <Darke> Ok wjp. Time to run exult through it, or shall we start on some of the other programs first? <grin, duck>
[16:14:06] <Colourless> [1:44] -NickServ- RECOVER Kill another user who has taken your nick
[16:14:07] <Colourless> -
[16:14:07] <Colourless> [1:44] -NickServ- RELEASE Regain custody of your nick after RECOVER
[16:14:14] <royalsexy> oh
[16:14:15] <royalsexy> heh
[16:14:29] <royalsexy> try /msg nickserv help ghost
[16:14:31] <royalsexy> :)
[16:15:56] <wjp> exult has quite a lot of leaks
[16:16:10] <Colourless> yeah I know. recover and ghost seem to almost do the same thing
[16:16:57] <wjp> from: read_schedules, create_ireg_object (from Actor::read), read_npcs, set_schedule_type,
[16:17:36] <wjp> read_npcs appears in the call stack of almost every single one
[16:18:48] <wjp> in fact, all of them except a couple of 1 and 2 byte leaks from init_files()
[16:19:09] <wjp> (Shapes_vga_file::read_info(), line 142, specifically)
[16:19:59] <wjp> ...which is an Armor_info structure
[16:20:48] <wjp> or so it would seem, anyway
[16:20:56] <Darke> Which needs to be deleted at the end of the for loop. Any idea why it's 'new'ed?
[16:21:12] <Darke> Or why you couldn't put it outside the for loop?
[16:21:28] <wjp> the pointer is assigned to info[shapenum].armor
[16:21:41] <wjp> whatever class manages the info[] array should delete it
[16:21:53] * Darke ahhs and nods. He's asleep.
[16:22:32] <-- Kirben has left IRC ("System Meltdown")
[16:23:04] <wjp> ...which means it should be deleted in ~Shape_info
[16:24:18] <wjp> ok, that solved the 2 byte leaks... now on to the 64+ byte ones :-)
[16:24:36] <Darke> Yep. I'm guessing the entire *`_info *` series could be deleted.
[16:24:39] <royalsexy> i'm just installing cygwin, is there anything else i need to compile exult in windows?
[16:24:54] <royalsexy> oh
[16:24:56] <royalsexy> sdl?
[16:25:02] <wjp> cygwin? do we still support that?
[16:25:27] <Colourless> you don't need cygwin
[16:25:41] <Colourless> all you need is mingw32
[16:25:58] <royalsexy> mingw32?
[16:26:02] <royalsexy> never heard of it
[16:26:04] <Colourless> even when compilng by using the cygwin shell, you still need mingw32
[16:26:05] <wjp> gcc-for-windows
[16:26:19] <royalsexy> ok
[16:26:24] <royalsexy> i'll go hunt one down
[16:26:31] <Colourless> http://www.mingw.org/
[16:26:43] <royalsexy> heh
[16:26:44] <royalsexy> ta
[16:27:07] * Darke grumbles and needs to fall asleep now, despite the fact he's wide awake. <grin> "Night all."
[16:27:11] <wjp> night
[16:27:18] <Colourless> night
[16:27:27] <royalsexy> g'night Darke
[16:27:30] <-- Darke has left #exult ()
[16:27:32] <royalsexy> sleep well
[16:28:00] <wjp> there's two 1 byte memory leaks in the font loader, it seems
[16:29:01] <wjp> allocated on a 'buffer = new char[len];' type statement, so it's trying to init a font with a 1 byte buffer
[16:29:47] <Colourless> hmm sounds rather silly
[16:29:58] <wjp> yes
[16:37:02] <wjp> all the other leaks are through read_npcs
[16:37:18] <Colourless> how?
[16:37:36] <wjp> about every call from read_npcs seem to cause a few leaks :-)
[16:37:53] <wjp> read_schedules causes tons of 10 byte leaks
[16:38:10] <wjp> oh, no, most are actually bigger than 10 bytes
[16:38:48] <wjp> then there's a lot of 80 byte leaks from: Actor::read -> Game_map::read_ireg_object -> Game_map::create_ireg_object
[16:39:52] <wjp> that's the path used to get an actor's inventory, btw
[16:40:27] <wjp> and a lot of 344 byte entries from read_npcs itself
[16:40:37] <wjp> I'm guessing actors aren't deleted?
[16:41:30] <Colourless> not individually
[16:41:35] <Colourless> they are an array
[16:42:16] <Colourless> i'm not entirely sure, but i don't think the destructor is called for arrays
[16:42:51] <wjp> clear_world() resizes the arrays to 0
[16:43:15] <wjp> there's a comment there that claims the npcs have already been deleted
[16:43:46] <wjp> but I don't see where
[16:49:04] <wjp> some of them may have been deleted through the Map_chunk in objects[x][y]
[17:03:57] <Colourless> hmm.... is that 'all' opcode implemented....
[17:05:52] <Colourless> oh no, the chucksum check failed in the 'random' data that I passed to dcmp8 :-)
[17:06:03] <wjp> *grin*
[17:06:28] <wjp> so, what happens when you pass not-so-random data?
[17:06:35] <Colourless> no clue
[17:06:48] <Colourless> be really really really slow :-)
[17:07:07] <Colourless> after each instruction i print out what each register contains
[17:07:14] <wjp> what exactly do you do?
[17:07:30] <Colourless> why i emulate a x86 cpu
[17:07:54] <wjp> how nice...
[17:08:04] <wjp> hmm...
[17:08:24] <Colourless> yes?
[17:08:28] <wjp> what exactly do you mean by 'emulate', btw? Do you let the CPU execute the instructions?
[17:08:42] <wjp> or did you implement/borrow some kind of VM?
[17:09:07] <wjp> or a mix of the two?
[17:09:51] <Colourless> at the moment i use some asm code to do proper handling of the flags register, but other than that, it's a vm
[17:10:03] <wjp> cool
[17:10:56] --- wjp is now known as wjp|dinner
[17:10:58] <wjp|dinner> I'll bbl
[17:11:02] <Colourless> k
[17:37:45] <Colourless> ok, the checksum code works for proper data.... so at least I know those instructions work.... but it seems to crash elsewhere....
[17:42:49] <wjp|dinner> does the interpreter crash or does the interpreted code crash?
[17:42:50] --- wjp|dinner is now known as wjp
[17:43:07] <Colourless> the interpreter crashes
[17:43:29] <wjp> hmm, brb again
[17:44:18] <Colourless> ow, seems to be a stack issue.
[17:47:09] <Colourless> "pop bp" ended up poping 000F into the stack base pointer.... a rather incorrect value
[17:50:59] <Colourless> hmm, the stack pointer is out by a lot
[17:55:58] <-- bj0ern has left IRC (Read error: 110 (Connection timed out))
[17:57:24] --> bj0ern has joined #exult
[17:57:59] <wjp> b
[17:58:05] <Colourless> wb
[17:58:08] <wjp> thx
[18:10:18] --> bj0ern|W has joined #exult
[18:29:55] <-- bj0ern has left IRC (Read error: 110 (Connection timed out))
[18:47:16] <Colourless> ok, fixed the crash
[18:47:16] <-- bj0ern|W has left IRC (Read error: 104 (Connection reset by peer))
[18:47:26] <wjp> cool
[18:47:31] <wjp> how is it working now?
[18:47:51] <Colourless> just checking
[18:49:53] <royalsexy> hrm any idea where to find a "windrag.h" file?
[18:50:42] --> bj0ern has joined #exult
[18:50:45] <wjp> we have one in the exult source, it seems
[18:50:56] <royalsexy> is there?
[18:51:00] <Colourless> yeah
[18:51:05] <royalsexy> not in the release :)
[18:51:13] <royalsexy> i'll go download the latest then
[18:51:23] <Colourless> hmmm
[18:51:28] <wjp> getting it straight from CVS is probably best
[18:51:44] <wjp> it should probably be in an EXTRA_DIST somewhere
[18:52:06] * royalsexy nods i'll track it down
[18:52:20] <royalsexy> it wasn't in the tgz for 0.96 or 0.98
[18:52:30] <Colourless> it didn't exist with 0.96 :-)
[18:52:34] <wjp> that would be because it indeed wasn't in the EXTRA_DIST
[18:52:39] <royalsexy> oh heh
[18:52:46] <royalsexy> theres a precompiled binary :)
[18:52:50] <royalsexy> heh
[18:53:23] * royalsexy downloads that instead :)
[18:53:46] <royalsexy> its good to see that you guys are making leaps and bounds on this project :)
[18:59:10] <Colourless> hmm, not implementing IMUL properly might be a problem...
[19:07:17] <wjp> I would say so, yes :-)
[19:15:56] <royalsexy> c'ya later i'm off to bed
[19:16:02] <-- royalsexy has left IRC ("ZzZzZz")
[20:25:36] <Colourless> hmm, this *just* doesn't seem quite right :-) http://www.users.on.net/triforce/24.wav
[20:26:02] <wjp> sounds familiar :-)
[20:26:03] <Colourless> at least the 'noise' that can be heard seems to sound a little like the static that is obtained using sonarcx :-)
[20:35:42] <Colourless> time to go
[20:35:47] <-- Colourless has left IRC ("need sleep")
[20:44:17] <-- bj0ern has left IRC (Read error: 110 (Connection timed out))
[21:25:40] --> Dark-Star has joined #exult
[21:25:52] <wjp> hi
[21:25:59] <Dark-Star> Hi
[21:26:34] <Dark-Star> what are you doing at the moment? Still coding usecode debugger?
[21:26:46] <wjp> not much at the moment
[21:27:36] <Dark-Star> I finally managed to get pentagram running ;-)
[21:27:43] <Dark-Star> looks really good
[21:28:04] <Dark-Star> I saw no rendering problems (yet :-)
[21:28:20] <wjp> you didn't?
[21:29:00] <Dark-Star> no. are there any?
[21:29:04] <wjp> plenty
[21:29:24] <Dark-Star> oh really? then it must have been because there's no scaler implemented yet :)
[21:29:32] * wjp looks at his totally corrupted map display... oh right, I was working on that decompressor...
[21:29:41] <wjp> try map 40
[21:30:15] <Dark-Star> ok, I'll try, I just need to reboot into linux... gimme 5 minutes :-)
[21:30:20] <wjp> I _so_ screwed up that decompressing...
[21:30:27] * wjp sighs
[21:31:09] <-- Dark-Star has left IRC ("rebooting into linux")
[21:32:24] <wjp> http://www.math.leidenuniv.nl/~wpalenst/sigh.png
[21:36:10] --> Dark-Star has joined #exult
[21:36:16] <Dark-Star> ok I'm back
[21:36:37] <wjp> http://www.math.leidenuniv.nl/~wpalenst/sigh.png
[21:36:42] <Dark-Star> btw, what IRC client can you recommend on Linux?
[21:37:34] <wjp> xchat
[21:41:38] <Dark-Star> ok, that does really not look good :(
[21:41:56] <wjp> not really, no :-)
[21:42:08] <Fingolfin> you want a GUI IRC client?
[21:42:14] <wjp> most shapes are still recognizable, though :-)
[21:43:21] <Dark-Star> yes, at least the first frames... those unrecognizable dolls in the front are other frames, right?
[21:44:00] <Dark-Star> Fingolfin: Yes, I'm looking for something "nice" (I'm using ksirc right now and it just sucks :)
[21:44:22] <wjp> xchat is nice :-)
[21:44:24] <Fingolfin> the only IRC unix GUI irc client I like is xchat
[21:44:35] <Fingolfin> if you want a console one, take a look at irssi
[21:44:44] * wjp bottles one of those IRCs
[21:44:46] <Dark-Star> ok I'll give it a try... just need to check if it's on my SuSE CDs
[21:44:54] * wjp labels it "For Darke" and leaves it on the floor
[21:44:57] <Fingolfin> I bet it is
[21:45:04] <Fingolfin> hehe
[21:47:36] --> Dark-Star|test has joined #exult
[21:47:48] <Dark-Star|test> hey this looks really nice :)
[21:47:56] <wjp> 1.6.4? that one's ancient :-)
[21:48:10] <wjp> so's your kernel, btw ;-P
[21:48:15] <Fingolfin> if it works
[21:48:27] * Fingolfin looks around the net if he can find some exploits for 1.6.4 =)
[21:48:33] <Dark-Star|test> :-P
[21:48:39] <wjp> evil :-)
[21:48:50] <wjp> hm, now that you mention it...
[21:49:12] <Dark-Star|test> SuSE 8.0 will be out in about 1 week I think I can live with 1.6.4 until then :)
[21:49:39] <-- Dark-Star has left #exult ()
[21:49:56] --- Dark-Star|test is now known as Dark-Star
[21:51:30] * Dark-Star is checking an awful lot of options (compared to ksirc)
[21:51:38] <wjp> there's a remote command execution hole in it
[21:51:49] <wjp> in fact, that hole is in my version too
[21:52:10] <Dark-Star> oh, any way to disable it? by turning off some features or something?
[21:52:30] <wjp> don't think so
[21:55:25] <wjp> brb
[21:55:27] <-- wjp has left IRC ("[x]chat")
[21:55:39] --> wjp has joined #exult
[21:55:40] --- ChanServ gives channel operator status to wjp
[21:55:43] * wjp feels safer now
[21:56:20] <Dark-Star> wjp: I see the rendering errors in pentagram now...
[21:58:20] * wjp wonders what that 'tinting' option does
[21:58:40] <wjp> it appears to be something colour & transparency related, but I don't really see anything
[22:01:11] <Dark-Star> tinting?
[22:02:21] <wjp> ah, it seems this xchat wasn't compiled with support for it
[22:12:49] <-- Dark-Star has left IRC (capek.openprojects.net irc.openprojects.net)
[22:12:49] <-- Fingolfin has left IRC (capek.openprojects.net irc.openprojects.net)
[22:13:36] --> Dark-Star has joined #exult
[22:14:59] <-- Dark-Star has left IRC (capek.openprojects.net irc.openprojects.net)
[22:14:59] <-- matto has left IRC (capek.openprojects.net irc.openprojects.net)
[22:17:19] --> Dark-Star has joined #exult
[22:18:05] <Dark-Star> looks like we've survived :)
[22:18:48] <wjp> Fingolfin is MIA, though
[22:18:52] <-- Dark-Star has left IRC (Client Quit)
[22:19:23] --> Dark-Star has joined #exult
[22:19:38] <Dark-Star> Looks like the eu server is the only one left :)
[22:21:36] * Dark-Star eats an easter-egg
[22:21:55] * wjp is all out of those :-(
[22:22:19] <-- wjp has left IRC (capek.openprojects.net irc.openprojects.net)
[22:22:19] <-- Dark-Star has left IRC (capek.openprojects.net irc.openprojects.net)
[22:27:20] --> wjp has joined #exult
[22:33:15] <-- exultbot has left IRC (signing off...)
[22:43:20] --> exultbot has joined #exult
[22:43:20] --- Topic for #exult is: Exult v0.98 RC1 Now Available! Download it NOW! http://exult.sf.net
[22:43:20] --- Topic for #exult set by Colourless at Wed Mar 13 20:23:47 2002
[22:43:26] --> wjp has joined #exult
[22:43:42] --- ChanServ gives channel operator status to wjp
[22:43:47] <wjp> that's better :-)
[22:43:48] <-- wjp_ has left IRC ("[x]chat")
[22:44:14] <wjp> so, who was that wjp_ ? ;-)
[22:46:56] <Dark-Star> how does pentagram's animdisp work? can I change the movement direction somehow?
[22:48:54] <wjp> up/down change NPC
[22:49:07] <wjp> a/shift-a change animation number
[22:49:26] <wjp> d/shift-d change direction
[22:49:46] <wjp> it seems there's no longer any message to stdout when you press d/shift-d
[22:50:36] <Dark-Star> yep, that seemed to be my problem... I tried all keys and thought d does nothing
[22:51:00] <Dark-Star> s/shift-s does the same as a/shift-a?
[22:51:25] <wjp> hm, looks like it
[22:51:42] <wjp> shouldn't, though
[22:51:54] <wjp> ah, s skips empty animations
[22:52:18] <Dark-Star> ok
[22:53:02] <wjp> insert the line "repaint = true; " right before the 'break;' below 'case SDLK_d:' to make 'd' more verbose
[22:53:13] <wjp> (around line 140 in animdisp.cc)
[22:53:58] * wjp found another compression 'trick' in u8shapes
[22:55:30] <Fingolfin> so?
[22:55:48] <wjp> so I can hopefully get rid of some of the image corruption :-)
[22:56:18] <Dark-Star> why didn't they use lzw compression to compress the shapes?
[22:56:30] <wjp> something like that, yes
[22:56:34] <wjp> but that was the easy part :-)
[23:06:44] --> matto has joined #exult
[23:15:27] * Dark-Star is looking at u8's usecode...
[23:16:09] <Dark-Star> so the function names are stored in the usecode file? nice...
[23:16:20] * wjp nods
[23:17:43] <Dark-Star> but there seem to be a lot of unknown opcodes left...
[23:18:31] <wjp> nah, not really
[23:18:52] <wjp> most are arithmetic opcodes
[23:19:02] <wjp> we just haven't taken the time to figure out which is which
[23:21:44] <Dark-Star> so how do you know they're arithmetic operations and not something different?
[23:22:22] <wjp> staring at them long enough :-)
[23:24:02] <Fingolfin> <g>
[23:30:04] <wjp> wow, it's decoding at x-coordinate 82 in an image of width 62
[23:30:33] <Dark-Star> nah, that can't be correct I think ;-)
[23:32:22] --> kefka has joined #exult
[23:32:54] <wjp> it seems it's confused about where lines end...
[23:33:46] <Dark-Star> maybe it should wrap around at the right edge? into the next scanline?
[23:38:47] <wjp> it's probably just a bug in my code somewhere :/ (it's horribly convoluted by now)
[23:40:18] <Dark-Star> how do the "events" in u8 usecode work? As I understand it, "event 0" means single click and event 1 means double click...??
[23:40:42] <wjp> yes
[23:41:02] <wjp> every usecode function has an "event table" or something, which contains offsets into the code
[23:41:23] <wjp> it maps events to "subroutines" (or whatever they're called)
[23:41:48] <wjp> every usecode function consists of several subroutines. (varies from just one to dozens if not hundreds)
[23:42:13] <Dark-Star> is there a map / text file describing which event corresponds to what action?
[23:42:30] <wjp> no
[23:42:43] <wjp> basically because we haven't looked at what events mean yet
[23:46:03] <wjp> I think I wrote a couple of guesses down somewhere, but I can't find it
[23:46:28] <Dark-Star> looks like event 0 is single click, event 1 is double click and event 11 is attack.
[23:46:32] <wjp> ah, here
[23:46:37] <wjp> 11 hex? yes
[23:47:01] <wjp> 2 is probably timer-related, 4 seems to be called when an object is loaded
[23:47:30] <wjp> 6 could be when it is hit or stepped on by an object
[23:47:41] <wjp> 9 seems to be the reverse of 6
[23:47:50] <wjp> C looks like quantity-changed
[23:48:01] <wjp> F might be a proximity event
[23:48:10] <wjp> 13 has something to do with stealing
[23:48:31] <wjp> finally, 12 and 15 only exist for the Avatar, but I don't know what they do
[23:48:44] <wjp> s/finally, //
[23:49:00] <wjp> 5, 7, 8 and 10 I don't know anything about; and the rest are unused
[23:50:46] <Dark-Star> event 8 looks quite strange, does a lot of compares and jumps...
[23:51:01] <wjp> in which usecode function?
[23:51:22] <Dark-Star> I'm looking at devon (1026)
[23:51:39] <Dark-Star> pushes, calls and cmp's
[23:52:49] <wjp> that 0581:28F9 function gets the time of day (in periods)
[23:53:29] <wjp> it sure likes to call that function a lot :-)
[23:54:52] <wjp> the other function it calls (57C:133F) is a mystery to me
[23:55:00] <Dark-Star> where is that call to 0581:28f9 in your file? on what address? because it seems in the german version the offsets are different...
[23:55:19] <wjp> hmm
[23:55:41] <wjp> that function is called about 8 times from Devon's event 8
[23:55:56] <wjp> the 0581: part shouldn't depend on language, though
[23:56:16] <Dark-Star> yep, I have 0581:0ef8 a few times here...
[23:56:28] <wjp> event 8 is at offset FF for me, with the call at 121
[23:57:06] <Dark-Star> it's always followed by a "push int retval". it starts at offset FE and has the call at 120
[23:57:34] <wjp> ok, that's the one then
[23:58:03] <Dark-Star> so that is an intrinsic function then?
[23:58:14] <wjp> no
[23:58:36] <wjp> intrinsic functions are functions that are implemented in the engine itself, not in usecode
[23:58:55] <Dark-Star> so the "get time of day" is implemented in usecode?
[23:59:01] <wjp> intrinsics are called by the "calli" opcode
[23:59:09] <wjp> yes, but it calls an intrinsic
[23:59:20] <Dark-Star> ah ok
[23:59:49] <wjp> if you scroll up a few pages you'll see a lot of "calli ..... (display_text)" lines