[00:33:56] --> Kirben has joined #Exult
[01:31:35] <-- fingolfin has left IRC (Client Exiting)
[04:09:53] --> A3D has joined #Exult
[04:10:35] <-- A3D has left IRC (Kirben)
[05:22:30] --> A3D has joined #Exult
[06:33:53] <-- Kirben has left IRC (System Meltdown)
[06:35:20] <-- A3D has left IRC (Read error to A3D[co3007967-a.brasd1.vic.optushome.com.au]: Connection reset by peer)
[10:12:36] --> wjp has joined #Exult
[11:00:51] --> Kirben has joined #Exult
[11:19:22] <wjp> hi Travis
[11:20:26] --> fingolfin has joined #Exult
[11:20:33] <wjp> hey Max
[11:20:35] <fingolfin> hi
[11:21:05] <fingolfin> so, jeff applied some fixes to the new rendering? hm, good ;) maybe we still can release till wednesday...
[11:26:34] <Kirben> Hi
[11:26:59] <fingolfin> hi Kirben
[11:28:26] <wjp> hmm, wednesday? sounds good
[11:30:06] <fingolfin> I hope so
[11:31:10] <fingolfin> I talked with Sam Latinga... funny... I had gotten the recent version of SDL_mixer some days ago, and I wondered if it was a good idea to add other midi drivers besides timidity to it, natives ones. Yesterday he did exactly this, a win native driver, and I probably will contribute one for QuickTime ;)
[11:31:30] <fingolfin> s/latinga/lantinga/
[11:32:13] <wjp> nice :-)
[11:32:39] * wjp read the conversation with Sam, btw
[11:38:39] <fingolfin> oookkkk, sorry ,)
[11:38:51] <wjp> np :-)
[11:39:09] <fingolfin> anyway, my work on getting SDL working using a Makefile on OS X is going smooth now, too I had my first succesful running test app today at 3 AM ;)
[11:39:27] <fingolfin> if it all works out, soon many many SDL apps can support OS X out of the box
[11:39:53] <wjp> excellent
[11:46:02] <wjp> what were the main problems with getting it to work in OS X?
[11:55:26] <fingolfin> oh I have it working for a long time already
[11:55:34] <fingolfin> the problem is that it is not using makefiles
[11:56:03] <fingolfin> one has to create a ProjectBuilder project, add all files, etc. etc. and you still need to run ./confgiure for the config.h file
[11:56:41] <fingolfin> one more project to keep in sync is bad; also, one has to use the GUI to build the app; and every app has that wants to run on OS X has tohave such a project file
[11:57:10] <fingolfin> the idea is to add some M4 macros to SDL, and rewrite parts of the SDL configure.in, so that one can add make fules for OS X target
[11:57:31] <fingolfin> some catches: the OS X native code uses Objective C which requires a little trick in the SDL configure.in
[11:57:41] <fingolfin> however, the apps configure.in stays clear of that
[11:58:17] <fingolfin> you also need to ship one additional file with each app, Info.plist.in ; one still has to modify the configure.in script, but only some very simple stuff (most of which should be covered by a M4 macros soon)
[11:58:27] <fingolfin> and you need at least one additional rule in the maste Makefile.am
[11:58:32] <fingolfin> but still that isnīt that much
[11:58:45] <fingolfin> btw, why are we not using the sdl.m4 to check for SDL properly?
[11:59:14] <wjp> because nobody took the trouble to include it :-)
[12:00:15] <fingolfin> he ;)
[12:00:41] <fingolfin> it sits in $PREFIX/share/aclocal/sdl.m4 for me, and I guess we could just copy it to our aclocal.m4 or so?
[12:00:57] <fingolfin> or can one #include somehow? donīt know to much about m4 (yet)
[12:02:33] <wjp> hmm, including should be possible I think
[12:02:53] <fingolfin> of course, do *not* hard code something like /usr/local/share/aclocal/sdl.m4
[12:03:01] <wjp> obviously
[12:03:02] <fingolfin> because for me $PREFIX is /sw not /usr/local ;)
[12:03:22] <fingolfin> maybe they were clever and there is a way to specify "include this file from my aclocal dir"
[12:03:30] <fingolfin> cause there are many more files in there, e.g. from iconv
[12:03:56] <wjp> I think there's a chance it automatically searches those for tests
[12:04:15] <wjp> take a look at the configure.in from the SDL test dir
[12:05:32] <fingolfin> ah yeah right; maybe we should just trial & error ;)
[12:06:26] <wjp> hehe, I see I had this idea earlier... comment from configure.in:
[12:06:30] <wjp> dnl This needs improving. Maybe steal it from the configure.in for the
[12:06:31] <wjp> dnl SDL test programs?
[12:24:18] <fingolfin> ;)
[12:25:03] * wjp is just visiting the new Eriadain website
[12:25:16] <wjp> they use shockwave flash for buttons... ugh...
[12:25:39] <wjp> you can't even reach the main site without flash
[12:25:54] <fingolfin> eek
[12:40:14] --- fingolfin is now known as Fingolfin|phone
[12:46:23] --- Fingolfin|phone is now known as Fingolfin
[13:12:18] * wjp is taking a look at the Gwani quest bug
[13:12:55] <wjp> it seems the problem has to do with object flag 0x1e
[13:14:08] <wjp> yes, looks like we don't load & save it
[13:14:21] <Fingolfin> hm
[13:14:31] <wjp> it seems to be used as a 'special' flag
[13:14:32] <Fingolfin> do we only save some object flags? why not all?
[13:14:59] <wjp> goblin king uses it to keep track if you've already talked to him
[13:15:07] <wjp> Neyobi uses it as a 'sick' flag
[13:15:27] <wjp> Iolo/Dupre/Shamino seem to be using it as a 'possessed by bane' flag, etc...
[13:15:41] <wjp> I don't know why we don't save them all. It surprised me too
[13:15:55] <wjp> the whole actor-saving stuff is kind of a mess
[13:16:42] <wjp> our read & write functions are 200 lines each :-)
[13:16:52] <Fingolfin> maybe save them all and try what happens ;) or we ask on the ML if there isa good reason not to save all
[13:16:59] <Fingolfin> hm ;)
[13:19:31] <wjp> hmm, boomerangs and spears are drawn on top of gumps
[13:19:49] <Fingolfin> hmpf, should gumps be on top of anythin else?
[13:20:01] <wjp> I think so
[13:20:25] <Fingolfin> do you know by chance what size the windows type DWORD has? signed? 16/32 bit?
[13:20:30] <Fingolfin> oh got it
[13:20:32] <Fingolfin> unsigned 32
[13:44:29] <wjp> ok, flag 0x1e for Neyobi is set in the sequence of usecode at the beginning
[13:48:42] --> Colourless has joined #Exult
[13:48:53] <Colourless> hi
[13:50:44] <wjp> hi
[13:51:16] <wjp> we've got another couple of object flags we probably need to save...
[13:52:22] <wjp> oh wait, one of those is already saved :-)
[13:52:27] <wjp> just flag 0x1e then
[13:52:34] <Colourless> it is?
[13:53:14] <wjp> the other one is 0x1c, but that one is 'met'
[13:53:30] <Colourless> only used by npcs
[13:53:41] <Colourless> what does 0x1e do?
[13:53:42] <wjp> flag 0x1e seems to be used as a 'spare' flag
[13:53:46] <wjp> (only for NPCs too, btw)
[13:53:54] <wjp> Neyobi uses it as a 'sick' flag
[13:54:07] <Colourless> odd
[13:54:16] <wjp> Pomdirgun uses it to determine if you've already talked to him before fighting, etc...
[13:54:27] <Colourless> i would have though they might have used a usecode flag or something, but I guess not
[13:54:28] <wjp> Iolo/Shamino/Dupre as a 'possessed by bane' flag
[13:54:48] <Colourless> there is lots of room for adding extra flags. Want me to add it?
[13:55:05] <wjp> yeah, please
[13:55:29] <Colourless> ok, will do
[13:55:59] <Colourless> ah, screwit, i'll just save the lot of them :)
[13:56:07] <wjp> hmm, who disabled the save game menu in the SI intro sequence?
[13:56:30] <Colourless> max
[13:56:40] <Colourless> he disabled most key presses
[13:56:56] <Colourless> been annoying me too (i just haven't said anything yet_
[13:57:16] <Fingolfin> hum?
[13:57:49] <Fingolfin> I wanted to disable key presses while dont_move/dont_render is set
[13:58:05] <Fingolfin> but I donīt get, what is "save game menu" in the SI intro sequence?!?
[13:58:10] <Fingolfin> oh wait, sure ;)
[13:58:18] * Fingolfin was confused and thought about the game intro movie
[13:58:36] <Fingolfin> hm, i guess we should allow not only quit but also gamemenu/savemenu
[13:58:54] <wjp> but maybe only allowing loading a game
[13:58:56] <Fingolfin> easy enough to fix, moment
[13:59:10] <Fingolfin> yeah, that is easy to do, too
[14:01:16] <Fingolfin> hm, I should add a flag I guess, indicating whether an action is allowed or not during dont_move
[14:04:16] <-- Kirben has left IRC (System Meltdown)
[14:06:23] <Fingolfin> I will also allow screenshots; I added a flag during_dont_move to struct Action
[14:06:39] <Colourless> i've decided to just to do the really simple, save all of the flags and reload all of them on restore for NPCs. :)
[14:06:51] <Colourless> It shouldn't matter what the flag numbers are and what they do now. :)
[14:06:53] <Fingolfin> good!
[14:07:03] <Fingolfin> should I allow res change during dont_move?!?
[14:07:18] <Fingolfin> maybe why not..
[14:07:37] <Fingolfin> everything that doesnīt affect the game play directly should be OK, no? like going fullscreen
[14:08:14] <Colourless> yeah
[14:08:18] <Colourless> i would say so
[14:09:06] <Fingolfin> Iīll just set it like I think it should be, and if anybody dislikes it, it is easy enough to change ;)
[14:10:24] <wjp> hey, D2 1.09 is going to be applied in a few hours it seems
[14:10:38] <Fingolfin> I wonder what it will bring...
[14:10:48] * wjp waves bye-bye to his sorc ;-)
[14:12:12] <Fingolfin> hehehe
[14:21:34] <Fingolfin> boy this Newfile_gump code is a little bit messy ;)
[14:22:01] <Colourless> which part :)
[14:23:58] <Fingolfin> uhm, nm, but I think for future projects a bit more OOP would be nice ; like having edit fields that know themselves how to handle events, instead of doing all key handling in the parent gump
[14:24:20] <Colourless> the other save gump actually does that
[14:24:42] <Fingolfin> he hm ;)
[14:24:53] <Colourless> kind of anyway
[14:24:54] <Fingolfin> ok, I figured that I should set want_save to false
[14:24:55] <Fingolfin> but
[14:25:15] <Fingolfin> will this also stop the user from editing file names? it doesnīt hurt but would be irritating IMHO
[14:25:16] <Fingolfin> hrm
[14:25:19] <Colourless> the gump tells the field what characters to add
[14:25:53] <Fingolfin> well, maybe if we had used a nice SDL C++ wrapper
[14:25:55] <Colourless> don't restrict saving
[14:26:08] <Fingolfin> and then using a proper event handler chaing
[14:26:27] <Fingolfin> Colourless: hm? you mean one should be able to save during a dont_move scene?
[14:26:35] <Colourless> yes
[14:26:47] <wjp> that's asking for trouble I think
[14:26:59] <Colourless> it's asking for trouble for only 1 reason :)
[14:27:33] <Fingolfin> maybe only allow it if in cheat mode?
[14:27:48] <Colourless> that's because the 'Usecode_script' that is usually executed during dont_move times isn't saved
[14:27:57] <Colourless> that is a bug
[14:28:20] <Fingolfin> btw, we should a) have some way to disable a button (hiding them is not so good in some cases), and then b) uses that to disable the "Quit to Menu" button - it will only confuse people
[14:28:22] <Colourless> actually, it is supposed to be saved now isn't it?
[14:28:29] <Fingolfin> unless somebody wants to implement Quit To Menu now
[14:28:55] <Colourless> can someone give me a reason why the saving should be disabled when dont_move is set?
[14:28:58] <Fingolfin> heck, I will allow saving then, less work for me anyway, we can change it later
[14:29:31] <Fingolfin> because in the past these save games were screwed up easily, but if you say it is fixed ;)
[14:31:09] <Colourless> think of it this way. The reason they were getting problems can still effect games that are save when not during dont_move
[14:31:55] * Colourless scratches his head
[14:31:58] <Colourless> &occbits
[14:32:04] <Fingolfin> well... maybe then we should then disable saving completly? ;)
[14:32:18] <Fingolfin> "play through U7 in one go or give up" ;)
[14:32:18] <Colourless> um, can somebody tell me why that would be done
[14:32:21] <Colourless> hehe
[14:32:32] <Fingolfin> Colourless: no idea... Iīd use occbits, but well
[14:33:21] <Colourless> yeah, me too
[14:44:52] <Colourless> as you are playing around with the dont_move stuff, do you mind changing Mouse::set_speed_cursor() to use the hand cursor when in dont_move mode?
[14:44:54] <Fingolfin> oh btw just commited keys.cc
[14:45:02] <Colourless> :)
[14:45:07] <Fingolfin> Colourless: np, why not
[14:45:17] <Fingolfin> Colourless: what else do we need to change for dont_move`
[14:45:51] <Colourless> i can't think of anything
[14:52:12] <Fingolfin> good! neither can I; then we would have finished this essentially!
[14:52:35] <Fingolfin> hm, I wonder whether all gumps are closed when we enter dont_move mode?
[14:53:03] <Colourless> no gumps should be drawn in dont_move mode
[14:53:25] <Colourless> at least, that's my opinion
[14:53:29] <Fingolfin> exactly, so when entering it all open ones should be closed, right?
[14:53:32] <Colourless> that include the status bars
[14:53:48] <Fingolfin> and I think we donīt do that ATM... hmm
[14:54:07] <Fingolfin> we would want to close all gumps, including status/faces; but faces should reappear afterwards Iīd say
[14:54:51] <Colourless> well, when creating thet status bars i made it so they don't close on close_all_gumps
[14:55:38] <Colourless> i think that rendering of the gumps should just be prevented
[14:55:59] <Fingolfin> ok!
[14:56:36] <wjp> can you still click on items to identify them during dont_move?
[14:56:51] <Colourless> either do it in the gump_manager or in game_window
[14:57:42] <Colourless> you may also want to set the entire screen dirty when going into dont_move mode
[14:58:32] <Fingolfin> that is already done I think
[14:58:37] <Fingolfin> in intrinsic.cc
[14:58:42] --- Fingolfin is now known as Fingolfin|bbl
[14:58:49] <Fingolfin|bbl> gotta go for half an hour or so
[14:59:53] <wjp> k, see you later
[15:00:53] <Colourless> k
[15:31:39] --- Fingolfin|bbl is now known as Fingolfin
[15:31:40] <Fingolfin> funny
[15:31:49] <wjp> wb
[15:31:50] <Fingolfin> exult suddenly crashes for me, after I did a cvs update
[15:31:52] <Fingolfin> thx
[15:31:55] <Colourless> wb
[15:32:13] <wjp> crashes when?
[15:32:45] <Fingolfin> Npc_actor::step calls Game_object::distance on an illegal object pointer
[15:33:22] <Colourless> considering that you were the only person to commit in the last 7 hours.... :)
[15:33:46] <Fingolfin> uhm, my last co before this was 20 hours ago
[15:34:06] <Fingolfin> and the only two changes I made were to keys.cc, which I am 100% sure is not the reason, as it worked fine before my cvs update
[15:34:14] <Colourless> :)
[15:34:17] <Fingolfin> and now it crashes right aways when i do journey onwards, always
[15:34:35] <Fingolfin> seems gwin->get_camera_actor() returns a bogus value, weird
[15:34:57] <Colourless> any idea when it is occuring?
[15:35:40] <Colourless> as in what part of the restore process?
[15:35:43] <Fingolfin> well, i joruney onward in SI; and it is to a fresh game, that is I just yesterday did "Start new game" w/o saving, so it starts at the very start ;)
[15:35:50] <Fingolfin> after the restore it seems
[15:35:59] <Fingolfin> in Timer_queue::actiovate
[15:36:18] <Fingolfin> (copy&paste doesnīt work very well in this xchat, grrr)
[15:36:51] <Colourless> no problems here
[15:36:53] <Fingolfin> actors.cc, l 3387
[15:37:00] <Fingolfin> there it crashes
[15:37:09] <Fingolfin> I will undo my changes to mouse.cc, maybe they screw up things
[15:37:28] <Fingolfin> althoug I donīt see how...
[15:37:34] <Fingolfin> although even
[15:37:38] <Colourless> what did you change to mouse.cc?
[15:37:54] <Colourless> i can't imagine it would be much
[15:40:24] <Fingolfin> it wasnīt much, and I canīt believe it should be problem; in fact I fixed a potential problem; (where set_shape0 could be called with a bad argument)
[15:40:52] <Fingolfin> still, this is the only change I made recently (keys.cc canīt be the problem as it worked before and there is even less a way it could be related, as long as I am not pressing any keys)
[15:41:14] <Colourless> tried a full rebuild?
[15:42:26] <Fingolfin> nope, that I will do after this test run with old mouse.cc
[15:42:45] <Fingolfin> although I doubt it would help
[15:43:09] <Fingolfin> still crashes
[15:43:17] <Colourless> wjp: i committed my changes for the flag saving and restoring
[15:43:26] <wjp> great! thanks
[15:43:39] <wjp> now we can tell people they need to start a new game to fix the Gwani bug ;-)
[15:44:00] * Fingolfin now does a full rebuild (with old mouse.cc, new one being kept in cold storage for now ;)
[15:44:23] <Fingolfin> wjp: better than telling them there is nothing they can do at all
[15:44:56] <Fingolfin> how about a special cheat that allows you to set flags? so they can fix up their screwed save games (the brave ones at least)
[15:45:46] <Colourless> i could modify the NPC flag editor to allow numerical flag modifying
[15:46:02] <Colourless> i already allow usecode flags to be modifed like that
[15:47:42] <wjp> what is that 'ID' in the NPC flags screen, btw?
[15:47:57] <Colourless> it's used for things like guards
[15:48:34] <Colourless> allows for 1 usecode function to have different effects depending on the ID value
[15:48:42] <wjp> I see
[15:49:05] <Colourless> i've also noticed it gets changes my usecode on the party members sometimes
[15:49:53] <wjp> strange
[15:49:58] <Colourless> for instance from memory Shamino's ID gets set to 2 when he gets teleported away in the teleport storm. that changes his conversation
[15:50:23] <Colourless> it gets set back to 0 after you've spoken to hi,
[15:50:25] <Colourless> him
[15:50:28] <wjp> guess they needed some extra storage
[15:50:51] <Colourless> BG has it as well. But i don't think it was used as much
[15:52:34] <Colourless> SI is kind of like that though. It seems to just do more with the engine that BG does.
[15:52:45] <Colourless> s/that/than/
[15:53:41] <wjp> yeah
[15:56:55] <wjp> Colourless: Neyobi bug is indeed fixed
[15:57:07] <Colourless> ok good :)
[16:01:22] <Fingolfin> gotta go again to greet my uncle, and have some chat with him & gransparents, and to acquire some food, too ;)
[16:01:37] --- Fingolfin is now known as Fingolfin|away
[16:01:37] <Fingolfin|away> (still compiles, btw)
[16:01:52] <Colourless> cya
[16:17:17] <Colourless> looks like my change might also fix the tattoo bug (might)
[16:44:11] <-- exultbot has left IRC (signing off...)
[16:45:58] --> exultbot has joined #exult
[16:47:31] --> wjp has joined #exult
[16:56:41] <wjp> argh
[16:57:57] <wjp> someone decided to prevent dropping items on NPCs by removing the "volume = 0 means infinite" part
[16:58:16] <Colourless> :)
[16:58:31] <wjp> which breaks hollow trees, ships holds, etc...
[16:58:40] <Colourless> so, are you going to check back though the logs to see who did it?
[16:58:50] <wjp> hehe :-)
[17:00:16] <wjp> Jeff, 27 days ago
[17:01:45] <wjp> so, now I need to fix dropping items on NPCs again
[17:02:25] <Colourless> if (npc_num > 0 && !in_party) return failed;
[17:02:37] <wjp> hmm, already seems to be fixed
[17:02:40] <Colourless> of course, that is just pseudo code :)
[17:02:52] <wjp> can't drop things on dogs & guards
[17:03:05] <Colourless> file?
[17:03:20] <wjp> dunno, I'm just trying it in-game
[17:03:28] --> freedman has joined #Exult
[17:03:34] <freedman> Hello!
[17:03:39] <wjp> Jeff! It's all your fault! ;-)
[17:03:45] <wjp> hi :-)
[17:03:47] <Colourless> hi
[17:03:49] <freedman> Looking through logs...
[17:03:57] <freedman> Wb
[17:03:59] <Colourless> wjp: i'm sure you know which file you modified :)
[17:04:10] <wjp> oh, contain.cc
[17:04:24] <freedman> There was a reason I changed that code about volum=0...
[17:04:38] <wjp> there was a "Note: NPCs have 0 volume" comment there
[17:04:44] <freedman> It fixed something, but I can't remember now.
[17:04:51] <wjp> I replaced it with a "volume 0 means infinite" comment ;-)
[17:05:14] <freedman> :-) But I guess we should allow dropping on party members...
[17:05:23] <wjp> that still works
[17:05:36] <freedman> But logs were broken by this?
[17:05:52] <wjp> the bug report was about hollow trees
[17:06:19] <wjp> but ship's holds should have had the same problem, and possibly barrels too
[17:06:24] <freedman> Yes. Okay, now I remember. It fixed the bug where you could put things in the SI urn (which you can't open).
[17:06:40] <wjp> oh, I see
[17:06:44] <Colourless> i'm guessing that the reason is because the method is virtual
[17:07:37] <Colourless> is the urn classed as a container game object though?
[17:07:50] <freedman> The question: Does vol==0 really mean 0 or infinite? We need an inspiration:-)
[17:07:57] <Colourless> it doesn't make much sense for anything else but container game objects to allow for things to be added
[17:08:04] <freedman> Colourless: Yes, and that was the cause of the bug.
[17:08:07] <wjp> I'm pretty sure it's infinite
[17:08:43] <freedman> The urn in your backpack has a 12-byte 'container' entry.
[17:09:00] <Colourless> could it be that we were/are got an error where the the shapenum of urn in SI is a container in BG and Exult then thinks that the urn is a container?
[17:09:30] <freedman> No, it starts out with a 12-byte entry in SI.
[17:09:46] <freedman> Maybe we just have to check for it as a special case.
[17:09:51] <Colourless> which urn though?
[17:10:00] <Colourless> is it only the urn that iolo has?
[17:10:10] <freedman> Yes, I think so.
[17:10:27] <Colourless> ok then.
[17:10:33] * Colourless loads exult
[17:10:56] <freedman> wjp: Is the bedroll fixed?
[17:11:00] <wjp> uh oh... segfault when Flicken opens the gate
[17:11:24] <wjp> freedman: yeah, I changed the return values of execute_(delayed_)usecode_array to true
[17:11:49] <freedman> Thanks! I was afraid it was that path_run_usecode() stuff again.
[17:12:09] <wjp> haven't committed it yet, though
[17:13:09] <wjp> strange...
[17:13:18] <freedman> ?
[17:13:24] <wjp> that segfault
[17:13:40] <freedman> Hope it isn't the renderer:-)
[17:14:16] <wjp> hmm, this time it did work
[17:14:33] <wjp> but now it segfaulted after reloading
[17:14:36] <freedman> In a way, that's even worse...
[17:15:47] <wjp> and now I get a different segfault there
[17:15:50] <wjp> oh joy
[17:16:14] <wjp> both of them are somewhere behind Usecode_script::handle_event though
[17:16:31] <Colourless> hmm, wasn't fingolfin getting a problem there too?
[17:17:00] <freedman> There was a crash in that a week ago because of an unhanded opcode.
[17:17:14] <freedman> ^handed^handled
[17:17:39] <wjp> it crashes on setting the frame of shape 276 (crossbeam)
[17:17:44] <wjp> (to a valid framenum, btw)
[17:18:04] <freedman> Where's the crash?
[17:18:11] <wjp> malloc
[17:18:14] <wjp> :-)
[17:18:21] <wjp> Shape::read (this=0x845ec80, shapes1=0x845df78,
[17:18:21] <wjp> shapenum=276, framenum=2, shapes2=0x0, count1=1124, count2=0)
[17:18:21] <wjp> at ../../exult/shapes/vgafile.cc:686
[17:18:33] <wjp> Shape::get (this=0x845ec80, shapes=0x845df78, shnum=276,
[17:18:33] <wjp> frnum=2, shapes2=0x0, count1=1124, count2=0)
[17:18:33] <wjp> at ../../exult/shapes/vgafile.h:128
[17:18:38] <wjp> Vga_file::get_shape (this=0x40538484, shapenum=276,
[17:18:38] <wjp> framenum=2) at ../../exult/shapes/vgafile.h:189
[17:18:44] <wjp> Game_window::get_shape (this=0x40538008, shapenum=276,
[17:18:45] <wjp> framenum=2) at ../../exult/gamewin.h:355
[17:18:50] <wjp> Usecode_internal::set_item_frame (this=0x82026f8,
[17:18:50] <wjp> item=0x8688388, frame=2, check_empty=0)
[17:19:04] <wjp> (and then 8 more...)
[17:19:14] --- wjp is now known as wjp|dinner
[17:19:21] <wjp|dinner> bbl
[17:19:26] <freedman> Bye
[17:23:50] <Colourless> i wonder if the urn problem was/is because we are incorrectly making the urn a container because shape_class says it's a container
[17:24:24] --- Fingolfin|away is now known as Fingolfin
[17:24:52] <Fingolfin> oh, hi jeff
[17:25:16] <Colourless> wb
[17:25:21] <Fingolfin> thx
[17:25:37] <Fingolfin> ok, now I can rerun exult to see if I still get the crash after full rebuild
[17:27:55] <Fingolfin> phew, no crash anymore! now my mouse.cc code back into place...
[17:27:56] <freedman> Hi Max.
[17:31:26] --- wjp|dinner is now known as wjp
[17:32:46] <Fingolfin> wb wjp
[17:32:50] <wjp> thx
[17:33:02] <Fingolfin> wonderful, mouse hack works, too. dunno why this crash happened, but the complete rebuild helped
[17:33:16] <wjp> maybe I should try a full rebuild too
[17:33:24] <Fingolfin> now I need to fix the fade_in for the SI intro
[17:33:29] <Fingolfin> wjp: ;)
[17:33:30] <wjp> Shape_frame *frame = new Shape_frame(); <-- segfaulting in that line is not good :-)
[17:34:09] <Colourless> general memory corruption
[17:34:19] * wjp nods
[17:35:03] <Fingolfin> wjp: did you mean that clicking on stuff while in dont_move should *not* show a text or something?!?
[17:35:11] <Fingolfin> wjp: I remember you said something about this
[17:35:26] <wjp> Fingolfin: oh right... that...
[17:35:47] <wjp> Fingolfin: I meant if you don't render the gumps, you should also ignore them when clicking on stuff
[17:35:51] <Fingolfin> wjp: in any case, clicking on something produces text while in dont_move; and I donīt see this as bad, or is it?!?! well, maybe it is
[17:35:57] <Fingolfin> oohh ok
[17:36:11] <Fingolfin> now I remember, dont render gumps, that was the other thing I wanted to do ;)
[17:37:12] * wjp wants pch
[17:37:52] <Fingolfin> ;) on classic MacOS, I have three build targets: debug, debug+pch, release+pch
[17:38:17] * wjp has 3 too: debug, release, profile
[17:38:27] <wjp> but no pch.. *sob*
[17:38:42] <Fingolfin> hm, I wanted to do a profile target recently, but I hit a compiler bug doing so *sigh*
[17:39:09] <Fingolfin> but with pch, a full recompile takes me less than 90 secs in debug build: release build takes longer of course
[17:39:26] <wjp> 90 secs? not bad at all
[17:39:30] <Fingolfin> nope ;)
[17:39:44] <Fingolfin> not rendering gumps: I only need to change two places in gamerend.cc, I think...
[17:40:08] <Fingolfin> gump_manager really was a good idea
[17:40:28] <Colourless> heh, it needed to be done
[17:42:05] <wjp> ok, compile done
[17:42:10] <wjp> now let's see if it still crashes
[17:42:33] <Fingolfin> ok, this is enough now, I am going to add a bool dont_move() method to game_window
[17:42:44] --- Fingolfin is now known as Fingolfin|phone
[17:42:46] <wjp> uh oh
[17:44:40] <Colourless> complete rebuild of exult takes me about 1 min 40
[17:46:50] <freedman> With msvc?
[17:46:56] <Colourless> yeah
[17:47:15] <freedman> Erg. Takes me about a minute just to link.
[17:47:51] <freedman> Did you get my email about the flags?
[17:47:57] <Colourless> yeah i did
[17:48:19] <freedman> It was just another 'inspiration':-)
[17:48:38] <Colourless> odd that
[17:50:05] <-- freedman has left #Exult
[18:07:43] --- Fingolfin|phone is now known as Fingolfin
[18:08:55] <Fingolfin> neat, I see you closed three bugs in the last couple of hours ;)
[18:09:42] <wjp> I've got 2 more fixed in my local version too
[18:14:22] <Fingolfin> good to hear!
[18:40:08] <-- Colourless has left IRC (Ping timeout for Colourless[220.127.116.11])
[18:41:31] --> Colourless has joined #Exult
[19:08:28] --- Fingolfin is now known as Fingolfin|dinner
[19:31:23] --- Fingolfin|dinner is now known as Fingolfin
[19:31:30] <wjp> wb
[19:31:35] <Fingolfin> thx
[19:36:27] <Fingolfin> gosh, seems we have to put up a new weekly update to the webpage, already sombody complaining in the forum
[19:36:48] <wjp> well... if we're going to release this week...
[19:36:52] <Fingolfin> ah an willem answered
[19:36:56] <Fingolfin> wjp: forget it!
[19:37:06] <Fingolfin> I wouldnīt take weekly update to serious
[19:39:25] <wjp> argh! that pseudo-random crash when opening the Monitor portcullis is really annoying me
[19:44:05] <Fingolfin> hm?
[19:44:31] <wjp> whenever I have Flicken open the gate, I get memory corruption, causing a crash sooner or later
[19:44:34] <wjp> (usually sooner)
[19:44:52] <Fingolfin> bad
[19:45:03] <wjp> crashes are usually in delete or new...
[19:45:10] <Fingolfin> guess I should run that on MacOS classic, sometimes I catch problems earlier there (i.e. closer to the source)
[19:45:16] <Fingolfin> hm
[19:48:07] * wjp notices a "delete this; // hope this is safe"
[19:49:35] <Fingolfin> well, this doesnīt have to be bad
[19:49:49] <wjp> yeah, but it could be
[19:51:04] <wjp> looking at tqueue.cc it doesn't appear to be a problem
[20:23:09] <Fingolfin> my patch that disabled rendering of gumps during dont_move works fine, but one problem remains, just as you foretold: clicking on gumps - I will disable that, too, then ;)
[20:28:58] <wjp> :-)
[20:29:48] <wjp> I don't get this crash... I'm just happily stepping through the program and then suddenly *boom*
[20:30:22] <wjp> again in malloc
[20:32:14] <Fingolfin> :/
[20:32:24] <Fingolfin> ok, when in dont_move mode, then I should disable *all* mouse actions I guess
[20:32:34] <Fingolfin> no double click, no single click, no dragging
[20:33:24] <chimera|wookin> Fingolfin!! wjp!@!
[20:33:50] <wjp> hey Matt
[20:33:56] <Fingolfin> chimera|wookin: !!!!!
[20:39:02] <wjp> Fingolfin: 1.09 is available, btw
[20:39:27] <Fingolfin> wjp: funny, in exact this second I was going to diablo2.de and clicked on the link to the Changelog ;)
[20:39:36] <wjp> :-)
[20:39:48] <wjp> hmm, only the firewall skill has been adjusted for sorcs
[20:39:50] <wjp> strange
[20:40:03] <chimera|wookin> curse blizzard!
[20:40:14] <Fingolfin> gold sharing removed! ahahaa!
[20:40:19] <wjp> uh oh
[20:40:36] <wjp> time to stick some skillpoints in looting ;-)
[20:40:53] <chimera|wookin> why are they ruining everything about the game?
[20:40:55] <wjp> telekinesis can no longer pick up 'real' items
[20:40:58] <chimera|wookin> well it doesn't matter, I stopped playing long ago
[20:41:06] <wjp> (only gold, potions, arrows, scrolls)
[20:42:15] <wjp> ah, max. sell price is higher
[20:42:37] <wjp> higher chances to get rares when gambling! woohoo!
[20:43:03] <wjp> lol: * Duriel now always drops a Town Portal scroll in addition to his regular drop.
[20:43:04] <Fingolfin> and you can again get set & uniques!
[20:43:08] <Fingolfin> although very rare
[20:43:17] <Fingolfin> yeah, could be trapped with him dead
[20:43:52] <chimera|wookin> oh they let you gamble uniques again?
[20:43:58] <chimera|wookin> well isn't that generous of them *grumble*
[20:44:26] <Fingolfin> gosh this list is long
[20:45:47] <-- chimera|wookin has left IRC (So many rubes in this world who need to be dealt with ... and I don't have time to do the dealing. http://www.rubecity.com)
[20:46:30] <wjp> yeah, very long
[20:46:49] <wjp> * Enabled "add socket" Horadric Cube recipe.
[20:46:49] <wjp> ??
[20:49:39] <wjp> * Rare Jewels are now capped at a maximum of four affixes... *sob* ;-)
[20:51:18] <Fingolfin> he
[20:55:05] <Fingolfin> greee "Exult - A windows Ultima VII engine." from the home page of the 3d U7 remake project
[20:55:07] <Fingolfin> bah
[20:55:33] <wjp> ARGH
[20:55:43] * wjp kill -9's them
[20:56:07] <Fingolfin> ;)
[20:56:24] <Fingolfin> their HP is crappy anyway, wonder if they will do more than talk
[20:56:30] <Fingolfin> and *they* are win only!
[20:56:47] <Fingolfin> but lazarus HP is looking cool !long time since i last checked it out, the intro movie is cool
[20:56:47] <wjp> what's the url?
[20:57:11] <Fingolfin> http://www.shadowlords.f2s.com/u7/links.html
[20:57:30] <Fingolfin> lazarus URL -> exult links section
[20:57:31] <wjp> oh right, that sounds familiar
[20:59:47] <Fingolfin> I will email them to change it
[21:10:47] <wjp> hehe, they have a "usecode decoder" position open
[21:13:54] <wjp> oh, another project with no programmers currently
[21:14:30] <Fingolfin> LOL
[21:15:23] <wjp> they have 2 level designers, one musician, two 3d animation artists, one modeller, and one web designer. (in only 4 persons ;-) )
[21:17:45] <wjp> hmm, the project lead's email is "email@example.com". That sounds awfully familiar
[21:18:36] <Colourless> that is familiar
[21:20:52] <Fingolfin> it is? not to me
[21:21:29] <Fingolfin> btw, I get a EXC_BAD_ACCESS exception when I quit exult, in exult.cc, when we call "delete gwin;"
[21:22:33] <Fingolfin> the gwin destructor deletes the gump manage, which then tries to close all gumps, which in turn call the paint method of the game window
[21:22:33] <wjp> oops
[21:22:49] <wjp> Fingolfin: http://exult.sourceforge.net/forum/read.php?f=1&i=1002&t=1002
[21:22:59] <Colourless> um, why would it attempt to call paint?
[21:23:08] <Colourless> which gump is trying to paint?
[21:23:11] <Fingolfin> simple
[21:23:16] <Colourless> the Gump_mananger itself>
[21:23:21] <Fingolfin> look at the last line of close_all_gumps
[21:23:29] <Fingolfin> the fix is simple, too, I believe
[21:23:43] <Colourless> you could probably comment out the line
[21:23:46] <Fingolfin> we call close_all_gumps as the first action in the Game_window destructor
[21:24:50] <Colourless> ideally, it should only be necessary to set the screen dirty, instead of re painting it
[21:24:54] <Fingolfin> now I want to find out why the fades in the SI intro are wrong
[21:26:09] <wjp> let me guess, right after the fades you get a palette-flash?
[21:26:19] <Fingolfin> oh, seems I didnīt work on the SI intro yet, that explains maybe what I see here ;)
[21:26:30] <Fingolfin> yeah - but the intro doesnīt do any fades as it should
[21:26:37] <Fingolfin> at the end of it, it should fade out, and clear the screen
[21:26:46] <Colourless> yes it does!
[21:26:50] <Colourless> :)
[21:26:53] <Fingolfin> and stop all audio
[21:26:55] <Fingolfin> it does?
[21:27:08] <Colourless> it should fade
[21:27:14] <Fingolfin> there is only one call to fade_out in sigame.cc
[21:27:19] <Colourless> it was a real pain in the ass to get it to fade put as well
[21:27:21] <Fingolfin> and that is in show_journey_failed
[21:27:34] <Fingolfin> I know a fix, no worries, i am working on that know ;)
[21:27:36] <Fingolfin> s/know/now
[21:27:37] <Fingolfin> arg!
[21:28:40] <Colourless> the fading isn't done by calling the fade functions. i
[21:30:19] <Colourless> the flic decoder is used to fade the si intro because (at least before this was true) the fade_functions didn't use the palette set by the flic decoder
[21:30:22] <Fingolfin> ryan: for now, i am only talking about a fade out at the end of the si intro, which is *not* done ATM, I think
[21:30:47] <Colourless> at the end of the last scene?
[21:32:41] <Fingolfin> well, when you press a button to skip the intro - it does fade out, then shows again the last image, but with wrong palette
[21:33:52] <Fingolfin> ugh
[21:33:54] <wjp> an alternate fix would be to stop palette->apply from repainting in some cases
[21:34:01] <Fingolfin> there is a return being used instead of a throw, I see
[21:37:06] <-- Colourless has left IRC (time to go)
[21:39:21] <wjp> in fact, I think palette->apply should almost never repaint the screen
[21:47:01] --> chimera|wookin has joined #exult
[22:14:55] <wjp> ok... fixed resurrecting Gwenno
[22:15:13] <wjp> now I'll go and put in a hack which will make it work without starting a new game :-)
[22:16:55] <Fingolfin> he ;)
[22:17:11] <Fingolfin> and so far my checkins today didnīt break anything... weird
[22:18:47] <wjp> :-)
[22:19:57] <wjp> ok, my turn to commit
[22:20:53] <chimera|wookin> I'm surprised that 'jessica' or whatever her name was got to the banes already
[22:20:54] <wjp> now I just need to check out that urn thing
[22:21:07] <wjp> jessica/lisa/something-else, yes :-)
[22:21:11] <wjp> rebecca I think
[22:25:49] <wjp> lol: this savegame is near a dinner-table, and I already get "Mmmmm..." and "Gulp..." comments while the plasma is still showing
[22:26:39] <Fingolfin> ups ;)
[22:27:00] <chimera|wookin> hehe
[22:27:01] <chimera|wookin> plasma!
[22:27:11] * Fingolfin tests wjpīs commit
[22:27:53] <wjp> this urn stuff is funny
[22:27:57] <chimera|wookin> school starting again *unhappy frown*
[22:28:16] <wjp> the urn shape (914) is a container
[22:28:35] * wjp mumbles something about school not starting until 10 september ;-)
[22:28:42] <chimera|wookin> grrr
[22:31:12] <Fingolfin> wjp: around that time I will write my first "Vordiplom"
[22:31:22] <Fingolfin> and lectures start at the end of september
[22:31:23] <Fingolfin> ;)
[22:31:29] <wjp> :-)
[22:31:36] <Fingolfin> but there is a two week course beforehand...
[22:31:44] <Fingolfin> "Introduction to Matlab" !!!
[22:31:45] <Fingolfin> grmbl
[22:32:03] <wjp> hehe :-)
[22:32:07] <Fingolfin> I wonder how long and thing they will stretch the matter to fill two weeks with it
[22:32:11] <Fingolfin> s/thing/thin
[22:32:25] * wjp takes the easy way out with the urn bug and just submits a bug report ;-)
[22:32:38] <chimera|wookin> yeah.. make freedman deal with ithehe
[22:32:52] <Fingolfin> heheheh
[22:32:52] <wjp> I assigned it to myself, though...
[22:32:58] <chimera|wookin> oh
[22:33:13] <Fingolfin> wjp: you are to nice for this world, ts ts
[22:33:29] * Fingolfin suddenly has an idea cross his mind...
[22:33:36] <Fingolfin> wjp: oh forget what I said, it is all fine
[22:33:50] <wjp> uh oh
[22:33:56] * wjp sets mode +paranoid
[22:34:01] * Fingolfin just thought that he might inspire wjp to be mean and start assignin bugs to him, which would be fatal for the success of exult
[22:34:56] <wjp> who is "him"?
[22:35:11] <chimera|wookin> Fingolfin
[22:35:12] <chimera|wookin> I believe
[22:35:33] <Fingolfin> I think that you will never find out ;)
[22:35:35] <Fingolfin> ?seen dominus
[22:35:35] <exultbot> dominus left IRC around Sat Aug 18 18:06:11 2001 (GMT) (Read error to Dominus[stu1ir200-100-173.ras.tesion.net]: EOF from client)
[22:35:53] <chimera|wookin> dominus has been negligent in his duties and has been a thorn in my side for far too long
[22:36:14] <chimera|wookin> I wonder how he would fair in the world of Pagan?
[22:36:24] <Fingolfin> he ;)
[22:36:57] <wjp> committed infinite-volume-container fix
[22:38:23] <wjp> hmm, Holzfaeller = lumberjack?
[22:38:50] <chimera|wookin> holzkopf?
[22:39:27] <chimera|wookin> ?seen sly
[22:39:27] <exultbot> I haven't seen sly lately
[22:39:35] <chimera|wookin> ?seen sty
[22:39:35] <exultbot> I haven't seen sty lately
[22:39:40] <chimera|wookin> where the devil is that guy
[22:39:43] <chimera|wookin> ?seen colourless
[22:39:43] <exultbot> colourless left IRC around Mon Aug 20 21:37:06 2001 (GMT) (time to go)
[22:40:37] <Fingolfin> wjp: right, why?
[22:40:47] <wjp> name of a savegame someone submitted
[22:41:13] <wjp> "Suche nach Holzfaeller"
[22:41:29] <chimera|wookin> I bet it was that guy who has been posting a lot lately
[22:42:12] <Fingolfin> hehe
[22:42:30] <wjp> I'm not taking that bet :-)
[22:43:49] <wjp> hmm... Dominik's savegame numbers are already in the 50's
[22:43:56] <wjp> he saves too often :-)
[22:43:59] <chimera|wookin> hehehe
[22:44:06] <chimera|wookin> he is meticulous (sp?)
[22:49:30] <wjp> I should go to bed
[22:49:33] <wjp> goodnight
[22:49:54] <chimera|wookin> good night!
[22:50:01] <-- wjp has left IRC ([x]chat)