[12:10:33] <-- Colourless has left IRC ("casts improved invisibility")
[13:00:39] <-- Kirben has left IRC ("System Meltdown")
[14:51:36] --> megawatt has joined #pentagram
[14:51:59] <megawatt> hiya.
[15:24:27] <wjp> hi
[15:31:04] <wjp> I've been looking at savegames from the original a bit this weekend
[15:31:40] <wjp> really amazing how they actually do memory dumps of objects including the vtable pointer
[15:32:18] <wjp> of course we can actually identify objects based on that vtable pointer :-)
[15:32:37] <wjp> (I use object in the C++ sense, by the way)
[15:37:51] <megawatt> so they were exploiting how the c++ libraries were handling objects? Doesn't the vtable address change for objects when a class' structure changes - variables and methods?
[15:38:15] <wjp> sure
[15:38:27] <wjp> so their savegames were invalidated by pretty much any recompile
[15:39:19] <wjp> the point of my exercise is that I'm planning to experiment with usecode process cascading failure a bit
[15:40:02] <wjp> doing a Kernel::resetRef on a process currently also kills the parent process of the target, but I'm fairly sure that behaviour is wrong
[15:40:36] <wjp> unfortunately the reason why I'm doing it this way is a problem with the death animations of Lithos and Pyros at the end of the game
[15:41:34] <wjp> fortunately the 'problem' animation is quite long, so it should be doable to get a savegame in the middle of it and analyze that
[15:42:11] <wjp> unfortunately, the maps with Lithos and Pyros on it are rather lengthy, and painful to play through in dosbox :-(
[15:43:43] <megawatt> ah.... I see... that's were it ties into the original savegame format.
[15:44:42] <megawatt> I've actually got to wonder if you are allowed to save in the middle of one of those scenes... never tried naturally
[15:44:56] <wjp> I think quicksave works
[15:45:11] <wjp> but you won't be able to opne the diary menu
[15:45:18] <wjp> s/opne/open/
[15:45:40] <wjp> I can recognize usecode processes in the original savegames, as well as the usecode class they're running in
[15:46:07] <wjp> oh, and the objid they belong to and their processtype
[15:46:40] <wjp> (did that by saving during some easy scripted sequences)
[15:48:03] <wjp> it's rather annoying...
[15:48:30] <wjp> I'm convinced that the bug with the freezing guard at the start indicated it shouldn't cascade
[15:48:53] <wjp> I'm also rather convinced that the bug with the titan death animation indicated it _should_ cascade
[15:48:58] <wjp> which is a problem :-)
[15:53:31] <wjp> but from a savegame in the middle of the guard sequence I'm tending towards not cascading
[15:54:08] <wjp> either that, or for some reason pathfinding animations are 'immune' to being killed in some way
[16:01:30] <wjp> maybe I should hack one of the teleporters to teleport straight to Lithos bypassing the realm of earth
[16:19:56] <megawatt> Parent processes recieve "signals" from children and can decide the right answer? I've seen that in practice with other apps.
[16:26:09] <wjp> but usecode doesn't have any such signal handlers
[16:26:55] <wjp> in any case hopefully a savegame from the middle of the titan death sequence will clear things up
[16:37:27] <megawatt> Thought you might mention something like that ;-) I'm not exactly in favor of hard-coded work-arounds in the engine to add something like that either, but I thought I'd throw it out there just in case.
[16:38:34] <wjp> it's definitely a possibility, though
[16:39:04] <wjp> it would be similar to the "or for some reason pathfinding animations are 'immune' to being killed in some way" thing
[16:40:36] <megawatt> Process flags like animation flags?
[16:41:10] <wjp> what do you mean?
[16:44:13] <megawatt> Like the AnimAction::AnimActionFlags - AAF_UNSTOPPABLE, but on processes
[16:45:24] <wjp> ah, I see
[16:45:59] <wjp> I hope it won't be necessary
[17:10:13] <megawatt> Did we ever find out what thos 8 bytes in the usecode objects were? I'd think the first 4 would be a pointer, index or ID of some kind (mostly due to the filesize being the next 4), but the 4 after that might cause some head scratching.
[17:32:45] <wjp> which 8 bytes?
[17:50:20] <megawatt> u8usecode.txt
[17:50:36] <megawatt> Structure of those usecode function files:
[17:50:47] <megawatt> 4 bytes unknown
[17:50:58] <megawatt> 4 bytes filesize
[17:51:11] <megawatt> 4 bytes unknown. Always seems to be a bit larger than filesize
[19:10:37] <wjp> hm, so there's one process of class LITHOS running in the original
[19:18:50] <wjp> and none of class ENDLITH
[19:19:05] <wjp> while if I disable cascading failure, pentagram leaves an ENDLITH process around
[19:35:41] <wjp> I really don't get this
[19:48:58] --> Fingolfin has joined #pentagram
[19:48:58] --- ChanServ gives channel operator status to Fingolfin
[19:49:19] <wjp> peculiar
[19:49:40] <wjp> an item search in Lithos' death usecode isn't finding any items
[19:49:53] <wjp> that might just cause the wrong behaviour
[19:49:56] <wjp> hi Max
[19:50:39] <Fingolfin> hi
[19:51:44] <wjp> gah
[19:51:55] <wjp> it's searching around an item in your inventory
[19:52:15] <wjp> I guess that means it should take move up to the topmost container before getting the world coordinates
[19:54:56] <Fingolfin> I wonder: Is there an U8 "map" out there? Similiar to the ones for U7 BG/SI (which one can create with the help of exult) ... ?
[19:55:05] <Fingolfin> or rather: Maps, one for each area of the game
[19:55:46] <wjp> right, that fixed it...
[19:56:00] <wjp> ARGH, that was a stupid bug
[19:56:25] <wjp> I spent _days_ on it altogether only to fix it after a bright idea within 10 minutes
[19:56:29] <wjp> ah well :-)
[19:56:40] <wjp> Fingolfin: not that I'm aware of
[19:56:40] <Fingolfin> wjp: congrats :-)
[19:57:30] <wjp> it should be possible to convince pentagram to create them
[20:00:26] * wjp sighs; lots of playtesting to be done again after such an invasive change
[20:01:10] <Fingolfin> what did you change? container handling?
[20:01:19] <wjp> no, process termination
[20:01:49] <wjp> which affects pretty much every script in U8 :-)
[20:04:06] <Fingolfin> aye
[20:09:10] <wjp> hm, also a small problem with Lithos' speech there
[20:23:57] <wjp> silly parser bug
[20:24:16] <wjp> was a good opportunity to use the parser utility functions I wrote a little while ago anyway :-)
[20:26:21] <wjp> now, let's see about map generation
[21:16:50] <megawatt> Didn't we try map generation before... something about the maps not being able to be directly stitched together due to overlay, but the individual maps worked well?
[21:22:54] <megawatt> wow! Queried google to see if I could find it in the logs.... ran into a discussion from 2002 with Darke when I was using the handle "Nuclear"
[21:23:24] <megawatt> and evidentally staying up until 2:00 AM.
[21:27:17] <wjp> which date?
[21:35:53] <megawatt> http://www.math.leidenuniv.nl/~wpalenst/exultlog.php?log=26Feb2002
[21:35:58] <megawatt> but it has nothing to do with map generation
[21:37:44] <wjp> hm, it probably won't be entirely trivial to get GameMapGUmp to display a full map
[21:38:41] <wjp> something like: create a huge GameMapGump, setup CurrentMap, put all chunks in the fastarea, set the camera on the center of the map, render
[21:40:37] <wjp> ...into a similarly huge RenderSurface
[21:41:58] <megawatt> MiniMapGump::generateWholeMap ;-)
[21:42:31] <megawatt> currentmap->setWholeMapFast();
[21:42:46] <megawatt> Not sure how to export that though
[21:43:05] <wjp> that's the "put all chunks in the fastarea" step
[21:46:51] <wjp> getting a nicely centered and cropped map automatically would be nice
[21:47:29] <wjp> maybe taking a bounding box around all GlobEggs in the map would be good enough
[22:01:33] --> Colourless has joined #Pentagram
[22:01:33] --- ChanServ gives channel operator status to Colourless
[22:05:04] --> Kirben has joined #pentagram
[22:05:04] --- ChanServ gives channel operator status to Kirben
[22:07:50] <wjp> hi Ryan, Travis
[22:10:41] <wjp> heh, 512Mb of RAM just isn't enough for experimenting with large images like this :-)
[22:13:45] <Colourless> :-)
[22:14:00] <Colourless> hacking big screenshots into pentagram?
[22:14:06] <wjp> yes
[22:14:28] <wjp> not going entirely as planned, though
[22:14:37] <Colourless> there is nothing stopping you from stitching together multiple screenshots
[22:15:13] <Colourless> but depends on if you can convince pentagram to do it of course
[22:15:13] <wjp> even a regular size automatically generated screenshot would be nice at this point :-)
[22:15:33] <wjp> it's currently just showing the tenebrae gate
[22:16:25] <Colourless> lets see...
[22:16:40] <Colourless> since we only want the GameMapGump making it a consolefunction of that is probably ideal
[22:17:22] <wjp> I have GameMapGump::dumpMap at the moment
[22:19:15] <Colourless> first step, set the entire map fast
[22:19:30] <Colourless> second step, make a texture render surface to render into
[22:20:11] <Colourless> the render surface will need to be of the correct size of course (matching the dimensions of the gamemapgumps parent)
[22:20:29] <wjp> current code: http://www.math.leidenuniv.nl/~wpalenst/dumpmap
[22:21:00] <Colourless> yep seems about right
[22:21:16] <Colourless> i'd move the camera process stuff into an innerloop when generating screenshots
[22:21:33] * Fingolfin stares impatiently on his pocket watch... hurry up folks, I ordered this map 2.5 hours ago and it *still* isn't done!
[22:21:36] <wjp> oh, I screwed up the dimensions
[22:21:37] <Colourless> might also be an idea to see if you can save the old camera process
[22:22:13] <wjp> Fingolfin: oh, sorry, you didn't check the 'ready today' checkbox on your order form
[22:22:25] <Fingolfin> *dang* I keep forgetting that <sigh>
[22:24:14] <Colourless> note that the render surface doesn't 'need' to be the same size as the gamemapgumps parent in reality, what it needs though is to be cropped to the right size and the 0,0 pixel set to point to the top left pixel of the cropped region
[22:25:05] <Colourless> ** note i just need to check on that
[22:25:56] <Colourless> and you probably should use Paint() not PaintThis()
[22:26:13] <wjp> true
[22:28:01] <Colourless> RenderSurface::SetClippingRect() and RenderSurface::GetOrigin() will probably be useful
[22:28:24] <Colourless> hmm if i'm right, you wont even need to bother with SetClippingRect()
[22:28:50] <Colourless> just using RenderSurface::SetOrigin() would be enough if you were using a single big rendersurface
[22:29:18] <wjp> should the origin be the center?
[22:29:18] <Colourless> since RenderSurface::Paint() will set its own clipping rect
[22:29:46] <Colourless> RenderSurface::paint() (really just Gump::paint() will auto shift the origin to the centre
[22:35:52] <wjp> ok, much better now
[22:36:28] <wjp> I now have a 1000x1000 (red/blue-inverted ;-) ) snapshot around the starting location
[22:38:07] <Colourless> ok... going to be tricky to get the palette right in a platform independant fashion
[22:38:50] <wjp> I'm most likely just reading the raw wrong
[22:39:14] <Colourless> probably playing with RenderSurface::format then forcing the palette to be set will get what you want
[22:39:34] <Colourless> make sure you save those values and then return everything back to normal after you're done :-)
[22:42:58] --- Colourless is now known as Cless|notHere
[22:43:00] <Cless|notHere> bbl
[22:43:08] <Cless|notHere> though you'd probably be in bed :-)
[22:44:26] * wjp looks at time
[22:44:27] <Fingolfin> hmm
[22:44:28] <wjp> yes :-)
[22:44:35] <Fingolfin> is it just me or is backspace not working in the pentagram console?
[22:44:56] <megawatt> I didn't do it
[22:45:26] <wjp> hm, such a quick denial... how suspicious
[22:45:40] <Fingolfin> indeed!
[22:45:49] <wjp> it's working here
[22:46:10] <wjp> so megawatt must've built in an insidious hack targetted solely at Mac OS X!
[22:46:24] <Fingolfin> anyway: I modified my key bindings to use Hash / # as an additional key to invoke ToggleConsole (since a backtick isn't easily produced on my german keyboard). I was wondering... how do I toggle off the console again? Do I really have to enter the full console toggle command again?
[22:46:35] <Fingolfin> hm, odd
[22:46:52] <Fingolfin> I verified that in ConsoleGump::OnKeyDown, key is indeed == SDLK_BACKSPACE when I press backspace
[22:46:58] <Fingolfin> so con.DeleteCommandBufferChars(-1); gets called
[22:47:31] <wjp> you should be able to close the console by pressing # again
[22:47:39] <Fingolfin> not so :-/
[22:47:42] <Fingolfin> it just inserts a #
[22:47:55] <wjp> hm, I thought Colourless fixed that a while ago
[22:48:14] <Fingolfin> maybe because I added it to u8bindings.ini, instead of using the options dialog
[22:48:33] <Fingolfin> nope
[22:48:35] <Fingolfin> still doesn't work
[22:48:55] <Fingolfin> oh and Console::DeleteCommandBufferChars is reached, and calls commandBuffer.erase(commandCursorPos, num);, with num == -1
[22:50:29] <megawatt> how strange.
[22:51:03] <Fingolfin> btw, arrow keys work
[22:51:22] <Fingolfin> so does delete (i.e. the key which removes the character to the right of the cursor)
[22:51:53] <Fingolfin> wjp: what GCC / StdC++ lib version do you use?
[22:52:07] <wjp> 3.3.6
[22:53:16] <wjp> gcc, that is
[22:54:44] <Fingolfin> I was wondering if calling gcc with a negative second parameter is allowed by the standard spec
[22:55:02] <Fingolfin> considering i am using gcc 4.0.1.. maybe this is a non-standard features and they removed it from the C++ lib
[22:55:11] <wjp> calling gcc?
[22:55:48] <Fingolfin> indeed: string::erase takes a size_type as second parameter, i.e. an unsigned int
[22:56:00] <Fingolfin> so pentagram is abusing a gcc extension, which is not present in gcc 4.x anymore
[22:56:12] <wjp> hm, where does it pass a negative size?
[22:56:22] <Fingolfin> string& erase(size_type pos = 0, size_type len = npos);
[22:57:26] <wjp> did you see the num = -num ?
[22:57:41] <Fingolfin> yeah I just noticed, my fault :-) still, something very strange is going on here.....
[22:57:52] <Fingolfin> consider this:
[22:58:04] <Fingolfin> my prompt reads: "abc", the cursor is between "b" and "c"
[22:58:09] <Fingolfin> I press first backspace:
[22:58:17] <Fingolfin> Console::DeleteCommandBufferChars(-1)
[22:58:17] <Fingolfin> commandCursorPos = 2, num = 1
[22:58:37] <Fingolfin> the second line is printed right before the
[22:58:39] <Fingolfin> commandBuffer.erase(commandCursorPos, num);
[22:58:39] <Fingolfin> now
[22:59:09] <Fingolfin> I then proceed to press (forward) delete, which works (i.e. removes the c), and the prompt now reads "ab"
[22:59:13] <Fingolfin> and I get this output:
[22:59:15] <Fingolfin> Console::DeleteCommandBufferChars(1)
[22:59:15] <Fingolfin> commandCursorPos = 2, num = 1
[22:59:30] <Fingolfin> wtf ?
[23:00:00] <wjp> what was commandCursorPos at the entry of DeleteCommandBufferChars?
[23:00:16] <Fingolfin> sec
[23:00:55] <Fingolfin> key = 8
[23:00:55] <Fingolfin> Console::DeleteCommandBufferChars(-1), commandCursorPos = 3
[23:00:55] <Fingolfin> commandCursorPos = 2, num = 1
[23:00:55] <Fingolfin> key = 127
[23:00:55] <Fingolfin> Console::DeleteCommandBufferChars(1), commandCursorPos = 2
[23:00:55] <Fingolfin> commandCursorPos = 2, num = 1
[23:02:31] <wjp> things are fishy here too
[23:02:50] <wjp> delete replaces the character behind the cursor with a space
[23:03:02] <wjp> (and moves the cursor forward)
[23:03:24] <wjp> typing abc, putting the cursor after the b and pressing backspace gives:
[23:03:24] <wjp> DeleteCommandBufferChars(-1), commandCursorPos=2
[23:03:24] <wjp> erase(1,1)
[23:03:27] <Fingolfin> hu? that doesn't happen here, "delete" seems to work
[23:03:32] <Fingolfin> as opposed to backspace
[23:03:33] <Fingolfin> hum
[23:03:55] <Fingolfin> but I thought -1 is only used when you press backspace?
[23:05:04] <wjp> it is; why?
[23:05:49] <Fingolfin> so when you said "delete" you meant "backspace" ?
[23:06:06] <wjp> the output I gave was for backspace
[23:06:25] <Fingolfin> indeed. I misread. ARGH
[23:06:34] <Fingolfin> sorry, I seem to be rather dense tonight :-(
[23:06:46] <wjp> hm, strange things are happening
[23:07:36] <wjp> typing abc, putting the cursor after the b and pressing delete claims commandCursorPos=3
[23:07:41] <Fingolfin> so... commandBuffer = "123", I am rightmost, press backspace, and I get
[23:07:42] <Fingolfin> Console::DeleteCommandBufferChars(-1), commandCursorPos = 4
[23:07:42] <Fingolfin> Old commandBuffer = 123
[23:07:42] <Fingolfin> erase(3,1)
[23:07:42] <Fingolfin> New commandBuffer = 123
[23:07:54] <wjp> even though doing exactly the same thing and then pressing backspace gives commandCursorPos=2
[23:07:56] <Fingolfin> and pressing delete, it says
[23:08:10] <Fingolfin> Console::DeleteCommandBufferChars(1), commandCursorPos = 3
[23:08:10] <Fingolfin> Old commandBuffer = 123
[23:08:10] <Fingolfin> erase(3,0)
[23:08:11] <Fingolfin> New commandBuffer = 123
[23:08:34] <Fingolfin> I am utterly confused, I must confess...
[23:08:48] <wjp> I don't understand the the commandCursorPos values are different
[23:08:59] <wjp> s/the the/why the/
[23:08:59] <Fingolfin> same here
[23:09:19] <Fingolfin> the question here is: where is commandCursorPos modified?
[23:09:24] <wjp> ah
[23:09:30] <wjp> OnTextInput
[23:10:02] <Fingolfin> uhh.. you mean both OnTextInput *and OnKeyDown try to handle the key???
[23:10:22] <Fingolfin> that would explain a lot =)
[23:12:32] <wjp> yes...
[23:15:08] <wjp> I think I'll file a bug report and handle it later
[23:15:22] <wjp> I should've gone to bed about an hour ago :-)
[23:17:04] <wjp> small status report on the map creation: at 1000x1000 it works fine
[23:17:17] <wjp> at 4000x4000 it somehow only shows a narrow strip around the city wall
[23:17:48] <Fingolfin> :-)
[23:18:05] <Fingolfin> well I guess I can give you a night off, honoring that work you've done there
[23:22:10] <wjp> I guess OnTextInput should handle all key input
[23:24:01] <wjp> I'm starting to have second thoughts about the distinction between OnTextInput and OnKeyDown again...
[23:24:17] <wjp> will have to think about it when I'm more awake :-)
[23:24:24] <wjp> good night
[23:27:04] <Fingolfin> night, Willem!