#pentagram@irc.freenode.net logs for 14 Mar 2005 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage

[00:14:00] * megawatt thinks the SimplePoolNode structure should have a nextFree pointer and a list of free nodes could be easily managed that way... problems arise for isFull and isEmpty though
[00:15:21] <megawatt> perhaps keeping the count around still?
[02:28:21] <-- megawatt has left IRC (Read error: 60 (Operation timed out))
[02:28:26] --> megawatt has joined #pentagram
[03:02:31] <megawatt> watt
[03:03:03] <megawatt> ummm... yeah... my irc client must be doing something weird
[04:54:42] <-- Kirben has left IRC ("System Meltdown")
[05:05:13] --> Kirben has joined #pentagram
[05:05:13] --- ChanServ gives channel operator status to Kirben
[05:11:47] <-- megawatt has left IRC (Read error: 110 (Connection timed out))
[06:11:10] --> Colourless has joined #Pentagram
[06:11:10] --- ChanServ gives channel operator status to Colourless
[06:49:46] <Colourless> you know, could just us an IDMan to handle allocation of memory blocks from the pool
[10:16:40] <wjp> how much faster is this new allocation stuff?
[10:17:00] <wjp> I assume somebody profiled on a large number of allocations before committing it?
[10:17:09] <wjp> s/on/it on/
[10:40:24] --> Fl00der has joined #pentagram
[10:48:29] <Colourless> wjp, no idea
[10:56:49] <Colourless> considering the complexities of malloc, i would really have a hard time thinking it would be slower
[11:21:12] <Colourless> that pathfinder infinite loop is really beginning to annoy me
[11:21:46] <Colourless> so willem, you are saying it's caused by the item being deleted as it moves out of the fast area?
[11:23:56] <Colourless> let see...
[11:24:13] --- Colourless is now known as Cless|HeadInCode
[12:06:19] <wjp> oh, that's still broken?
[12:07:08] <Cless|HeadInCode> yes
[12:07:33] <wjp> it might be that the pathfinder doesn't handle being outside of the fastarea properly
[12:07:54] <wjp> hypothesis:
[12:08:23] <wjp> for some reason, the pathfinder returns on some kind of failure. This wakes up a process waiting for the pathfinder, which then immediately continues running
[12:08:46] <wjp> which might then spawn another pathfinder
[12:17:49] <wjp> hm, but the pathfinder doesn't terminate on !FASTAREA
[12:19:17] <wjp> although it's quite likely it will fail to find a path
[13:41:32] <-- Kirben has left IRC ("System Meltdown")
[13:59:49] <Cless|HeadInCode> hmm... this is most troubling... there is an item in the fast are with ObjID -1 and it's vtable is Object::'vftable'
[14:03:33] <Cless|HeadInCode> hmm.. crashed again, a combat process trying to run for a deleted item...
[14:03:36] <wjp> vf?
[14:03:46] <Cless|HeadInCode> vf = virtual function
[14:03:48] <Cless|HeadInCode> i'm guessing
[14:34:58] <Cless|HeadInCode> hmm... i think i caused those problems...
[14:35:31] <Cless|HeadInCode> reverting code back made the problems disappear
[14:41:40] * Cless|HeadInCode snots comparing the sizes of the exult and pentagram exes
[14:41:47] <Cless|HeadInCode> exult 1.8 mb, pentagram 2.0 mb
[14:44:24] <wjp> pentagram is bigger? wow
[14:44:33] <Cless|HeadInCode> yeah
[14:44:46] <wjp> exult 21 vs pentagram 25 here
[14:44:55] <wjp> (with debugging symbols obviously :-) )
[14:45:19] <Cless|HeadInCode> i seem to have fixed the pathfinder problem... i think
[14:45:42] <Cless|HeadInCode> i made an ItemDestroyProcess (that looks remarkably similar to the ActorDeleteProcess)
[14:46:00] <Cless|HeadInCode> pretty much it just defers all 'destroy' calls
[14:46:03] <wjp> yes... I was considering that for the fastarea stuff as well
[14:47:58] <wjp> but how exactly does that fix the infinitely looping pathfinder?
[14:48:22] <Cless|HeadInCode> you know i really don't know
[14:48:24] <wjp> (you'll have to forgive me if I'm a bit slow... I'm still ill :/ )
[14:48:36] <Cless|HeadInCode> :-)
[14:50:13] * Cless|HeadInCode does some more testing on 'old' code
[14:50:32] <wjp> would be interesting to confirm my hypothesis
[14:51:08] <wjp> making the various 'failed to find path' error messages different would already help a bit
[14:51:26] <wjp> (so that we can at least see if it fails in the constructor on in run)
[14:52:22] <Cless|HeadInCode> i was actually intending to break execution during a loop to see if anything was obvious
[14:58:00] <Cless|HeadInCode> well there is 1 problem with the current code
[14:58:06] <Cless|HeadInCode> it's not actually deleting actors
[14:58:24] <wjp> not until map change, no
[14:58:58] <wjp> although I'm now wondering if they're actually deleted then
[14:58:59] <Cless|HeadInCode> that is intentional behaviour?
[14:59:58] <wjp> somewhat; not necessarily the right behaviour, though
[15:02:32] <Cless|HeadInCode> considering the eggs get reset on fastarea i don' think it's the right behaviour
[15:07:56] --> megawatt has joined #pentagram
[15:10:13] <megawatt> wjp: The allocation code has yet to be profiled. Sorry, I ran out of time to do so. I plan on setting aside some more time this week to write some console commands to torture test the allocators and check the speed vs. malloc/free
[15:16:14] <Cless|HeadInCode> yeah managed to get a loop in debug mode :-)
[15:21:14] <Cless|HeadInCode> what is happening is this
[15:22:06] <Cless|HeadInCode> i have no idea..
[15:24:21] <Cless|HeadInCode> ok..
[15:24:23] <Cless|HeadInCode> this is what happens
[15:24:36] <Cless|HeadInCode> pathinder runs and finds a path
[15:24:52] <Cless|HeadInCode> this causes an actoranimproc proc to be created
[15:25:04] <Cless|HeadInCode> the pathfinder then waits for the actoranimproc
[15:25:19] <Cless|HeadInCode> the actoranimproc runs and fails because the actor is not in the fast area
[15:25:30] <Cless|HeadInCode> the pathfinder proc restarts
[15:25:40] <Cless|HeadInCode> and so on...
[15:26:34] <wjp> peculiar
[15:27:01] <wjp> oh, oops
[15:27:08] * wjp hits self
[15:27:40] <wjp> remember my comment from 3 hours ago: hm, but the pathfinder doesn't terminate on !FASTAREA
[15:27:46] <wjp> I didn't commit that...
[15:28:18] <wjp> I have a 'if (!(actor->getFlags() & Item::FLG_FASTAREA)) return false;' near the top of PathfinderProcess::run here
[15:28:35] <Cless|HeadInCode> oh
[15:28:40] <Cless|HeadInCode> that might explain it
[15:34:00] <wjp> I wonder why I didn't commit that
[15:34:22] <wjp> either I got distracted or something else was broken
[15:42:49] <wjp> hm, judging by the irc logs I got distracted by a bug in idMan
[15:48:14] <Cless|HeadInCode> i'm going to change the actor behaviour too. I think actors should be destroyed when leaving fast area
[15:48:24] <Cless|HeadInCode> IF they are fast area only
[15:48:32] <Cless|HeadInCode> doesn't really make sense otherwise
[15:58:27] --> Colourless has joined #Pentagram
[15:58:43] --- ChanServ gives channel operator status to Colourless
[15:59:50] <Colourless> so willem are you going to commit that? or should i just put it in myself
[16:09:57] <wjp> I'll commit it
[16:11:59] <wjp> done
[16:14:07] <Colourless> thanks
[16:14:46] <Colourless> i'm pondering... do i get rid of ActorDeleteProcess and potentially break some save games
[16:15:24] <Colourless> or do i leave it in for now
[16:15:30] <wjp> add a loader for "DeleteActorProcess" that 'accidentally' creates a DestroyItemProcess :-)
[16:15:55] <Colourless> yes i was considering that
[16:17:19] <-- Cless|HeadInCode has left IRC (Read error: 110 (Connection timed out))
[17:16:18] --> Fingolfin has joined #pentagram
[17:16:18] --- ChanServ gives channel operator status to Fingolfin
[17:38:23] <Colourless> hmm... defered destruction of items seems to have some problems... doors wont open anymore
[17:39:35] <Colourless> need to change my code..
[18:09:52] <megawatt> doors... sigh... they break way too often
[18:11:34] <-- Fl00der has left IRC ()
[18:14:30] <wjp> that they do
[18:14:47] <wjp> especially the double variety
[18:17:06] <Colourless> hmm
[18:19:44] <Colourless> i made the minimap gump savable... but after loading a savegame with a minimap gump saved, pentagrm will crash when unloading
[18:21:09] <Colourless> which is really really strange
[18:27:32] <Colourless> uh
[18:27:37] <Colourless> i see what the problem is
[18:27:51] <Colourless> the load game constructor must call Gump()
[18:28:00] <Colourless> otherwise bad things happen.
[18:29:11] <wjp> indeed
[18:29:16] <wjp> the other constructors do too much
[18:36:24] <wjp> I've considered adding a 'fake' argument of a special type to the 'load' constructor to prevent confusion
[18:41:02] <Colourless> yeah
[18:41:06] <Colourless> might be a good idea
[18:50:10] <Colourless> so do you want me to do a website update?
[18:50:37] <Colourless> was thnking of mentioning the minimap and putting up a screenshot
[18:51:26] <wjp> go for it :-)
[18:51:46] <Colourless> not the 15th yes though... well is for me, but you know what i mean
[18:51:52] <wjp> good enough :-)
[19:18:54] <-- Fingolfin has left IRC ("42")
[19:30:06] <wjp> hm
[19:30:23] <wjp> did you flag the png's as binary?
[19:34:30] <Colourless> no
[19:34:45] <Colourless> fixing it all up now
[19:35:27] <Colourless> there much better
[19:57:17] <megawatt> ah.. excellent news indeed
[19:58:56] <megawatt> the minimap screen shot kind of reminds me a nethack for some odd reason.
[19:59:19] <megawatt> s/a/of/
[20:00:04] <megawatt> probably make a neat tileset for it.
[20:01:10] <-- Chetic has left IRC (Read error: 145 (Connection timed out))
[20:02:56] <Colourless> how so?
[20:11:58] --> Chetic has joined #pentagram
[20:24:05] <megawatt> ? how so to wich?
[20:24:11] <megawatt> *which
[20:25:24] <Colourless> probably make a neat tileset for it.
[20:25:31] <Colourless> how so... and why
[20:29:49] <megawatt> Referring to the "tiles" as shown by the minimap... I guess there already exist tileset for nethack that look similiar to that, I dunno.
[20:31:21] <megawatt> could do something insane and bizarre using u8 graphics in nethack... hehe... evil.
[20:31:37] <megawatt> but let's not be too crazy.
[20:32:19] <Colourless> the tiling is nothing special
[21:11:08] <Colourless> later
[21:11:14] <-- Colourless has left IRC ("casts improved invisibility")
[21:31:15] <-- megawatt has left IRC ("Chatzilla 0.9.67 [Firefox 1.0/20041107]")
[22:38:15] --> Kirben has joined #pentagram
[22:38:15] --- ChanServ gives channel operator status to Kirben