#nuvie@irc.freenode.net logs for 11 Aug 2006 (GMT)

Archive Today Yesterday Tomorrow
Nuvie homepage


[00:20:14] <-- Kirben has left IRC ("System Meltdown")
[00:44:13] <sbx|afk> Yuv422 used to use BitchX.
[00:44:16] --- sbx|afk is now known as SB-X
[00:44:40] <SB-X> before he switched to an OSX irc client
[01:34:03] --> Kirben has joined #nuvie
[01:43:44] <servus> I don't like my software to have that much attitude. It's like if Clippy had a mohawk and gave me the finger. I wouldn't like that.
[02:00:45] <luteijn> I'm just to lazy to get rid of those annoying random messages...
[02:04:29] <-- luteijn has left IRC ("NULL")
[02:05:19] --> luteijn has joined #nuvie
[02:05:57] <luteijn> there, now it's always going to be the same annoying message (I think)
[02:24:32] <servus> Heh :)
[02:24:42] <servus> I didn't mean anything by it
[02:26:05] <luteijn> well those things annoy me too, just never enough to go into the default file and get rid of them ;)
[04:53:46] --> Kirben_ has joined #nuvie
[04:53:52] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[09:52:11] --> Yuv422 has joined #nuvie
[10:28:56] <SB-X> hey yuv
[10:29:22] <servus> It's harder to get people to alpha test a video game than you might think.
[10:59:30] <SB-X> I havn't thought about it.
[11:01:33] <servus> I wasn't referring to Nuvie. I have been able to reproduce the permanent-light-on-torch-pickup bug though
[11:05:32] <servus> Oh wow, the latest patch really broke things. If I try to "use" a lit torch in my hands, it says out of range, and when I click on it to unready it, it just says 'torch burned out', doesn't update my light level, and turns it into a grass tile in my hand.
[11:05:50] <servus> And I got a glibc memory error on exit
[11:07:02] <SB-X> I knew you weren't referring to Nuvie. :)
[11:07:51] <SB-X> im in XP now and cant test it yet
[11:10:33] <SB-X> the behavior you describe doesn't happen for me
[11:10:55] <SB-X> with the newest windows cvs snapshot
[11:11:41] <SB-X> maybe "the latest patch" was after that was updated
[11:14:24] <servus> I get two random walltiles when unequipping a lit torch. Segfault when I try to drop said random walltile.
[11:14:44] <servus> I just played with a completely clean cvs head and new saved game.
[11:14:49] <servus> I'll look into it tomorrow :)
[11:18:12] <SB-X> you don't have to do that
[11:18:28] <SB-X> that bug used to exist but we fixed it
[11:18:42] <SB-X> or a similiar one, i wonder if it was reintroduced recently
[11:24:29] <-- Yuv422 has left IRC (Read error: 110 (Connection timed out))
[11:26:41] --> Yuv422 has joined #nuvie
[11:34:56] <luteijn> maybe my messing with the in-inv, in-cont, equipped, on-map bit of Obj has broken things.
[11:36:18] <servus> You said that Nuvie was always crashing, and you didn't want to seem like a liar? *grins* Ohh that's mean. I'm kidding!
[11:38:15] <luteijn> older code seemed to be doing the right thing, but newer seemed to forget those are a 2 bit field, not bit vector. sometimes it wasn't 100% clear if it was meant to or in one more 1 or also mask out another. probably need to check load obj, or maybe the torch usecode?
[11:54:56] <luteijn> hmm I changed is-in-inventory() to check for the 01 pattern instead of x1 (and is_in_container checks 10, instead of 1x). added checks for 00 (is_on_map) and 11 (is_readied). torch usecode seems to use obj->is_iin_container() astest for 1 bit. I'll probably need to fix its logic.
[12:10:03] <SB-X> yes, that shouldnt be changed
[12:10:24] <SB-X> i knew that it would make more sense if the checks were exclusive, but that it would break things
[12:11:17] <SB-X> so I always just remember that "is_in_inventory()" means the INVENTORY bit is set, not that the object is in inventory
[12:12:31] <SB-X> i dont see where older code was doing the right thing; i always treated it the same
[12:13:08] <SB-X> so I'd prefer the functions stay what they were until we can go check every place that uses them
[12:28:47] <-- Kirben_ has left IRC (Read error: 110 (Connection timed out))
[12:30:34] <Yuv422> hey
[12:33:51] <Yuv422> the lower level operations in nuvie need careful testing
[12:35:30] --> sbx has joined #nuvie
[12:35:59] <sbx> Yuv422: yeah, I am in favor of making that change eventually, but we can't yet
[12:36:29] <-- SB-X has left IRC (Read error: 104 (Connection reset by peer))
[12:36:42] <sbx> the change to the obj pos functions
[12:36:44] --- sbx is now known as SB-X
[12:41:53] <-- Yuv422 has left IRC ()
[12:42:16] --> Yuv422 has joined #nuvie
[12:43:04] <Yuv422> chaning the low level obj handling will be a large task
[12:44:05] <Yuv422> changing
[12:53:10] <SB-X> all I got around to doing is adding an obj pos mask for those 2 bits inventory and container :)
[13:08:05] <Yuv422> I'm adding map wrapping to the blacking functions
[13:09:06] <-- Yuv422 has left IRC (Read error: 110 (Connection timed out))
[13:09:51] --> Yuv422 has joined #nuvie
[13:10:08] <Yuv422> damn IRC!
[13:38:51] <luteijn> it seemed to me that existing code was sometimes doing the wrong thing when manipulating the obj->status, so I added is_on_map() and is-readied() and got rid of most of the places where obj->status was being directly manipulated. also added on_map(), etc functions and use those instead of directly manipulating status-'flags'. Forgot / didn't get to replacing existing use of the is_... functions.
[13:39:43] <SB-X> its always doing the wrong thing
[13:40:37] <SB-X> adding is_on_map and is_readied and replacing direct access to obj->status to use those wont break anything, but changing is_in_inventory and is_in_container will
[13:46:18] <luteijn> yes, I didn't think it through enough, figured it would only add redundand checks, but really need to go through the existing use of the is-... functions and change to using the new ones depending on what is meant. it will make things clearer though.. so if the breakage isn't too bad I'd prefer going through code fixing it to us is_readied() instead of rolling back my changes..
[13:54:47] <-- Yuv422 has left IRC (Read error: 110 (Connection timed out))
[13:56:22] --> Yuv422 has joined #nuvie
[14:03:19] <SB-X> luteijn: you could revert to the old functions until you've gone through the rest of the code and fixed it
[14:16:29] <luteijn> yes, I'll do that.
[14:17:18] <-- Yuv422 has left #nuvie ()
[14:17:34] --> Yuv422 has joined #nuvie
[14:39:40] <SB-X> luteijn: ok thanks
[14:39:55] <SB-X> im going now
[14:39:56] <SB-X> cya
[14:42:27] --- SB-X is now known as sbx|afk
[14:53:42] <Yuv422> balloon saving and loading seems to be broken
[14:53:59] <Yuv422> well if you save while in the ballon you start off again outside
[14:54:03] <Yuv422> but invisible
[15:07:29] * Yuv422 lays some astro turf in the ocean to help with border wrapping
[15:42:39] <Yuv422> ok blacking is working with map wrapping
[15:42:47] <Yuv422> I'll do some more checking tomorrow
[15:42:51] <Yuv422> then I'll commit
[15:52:42] <wjp> hi Eric
[15:55:57] <Yuv422> hi wjp
[15:56:06] <Yuv422> How's it going?
[15:56:49] <wjp> pretty good; not much spare time for coding projects at the moment, though, unfortunately
[15:57:14] <wjp> it's good to see lots of activity on nuvie
[16:02:18] <Yuv422> yeah it's frustrating when you want to code but don't have the free time
[16:03:02] <Yuv422> moving the party over the map edge causes them to disappear
[16:03:20] <Yuv422> and lots of actor x searching for party
[16:03:26] <Yuv422> messages on stdout
[16:03:28] <Yuv422> :-)
[16:04:28] <Yuv422> time for bed
[16:04:36] <Yuv422> cya
[16:04:37] <wjp> good night
[16:04:55] <-- Yuv422 has left IRC ()
[18:52:39] <luteijn> I guess pathfinder wrappping will be next ;)
[19:49:01] <-- laxdragon has left IRC (Read error: 104 (Connection reset by peer))
[19:49:52] --> laxdragon has joined #nuvie
[22:52:29] <luteijn> Hopefully cleaned up the obj->status stuff.. I wonder, shouldn't 'Obj' be a proper class, instead of a public struct everything can scribble over..
[23:23:57] --> Kirben has joined #nuvie