#pentagram@irc.freenode.net logs for 23 Jun 2004 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage


[04:11:26] --> pr0p4g4nd4 has joined #pentagram
[04:20:12] <-- pr0p4g4nd4 has left #pentagram ()
[07:41:06] --> Sectus has joined #pentagram
[07:44:48] --> TzarSectus has joined #pentagram
[07:54:43] --> TzarTzarSectus has joined #pentagram
[08:04:43] <-- Sectus has left IRC (Read error: 110 (Connection timed out))
[08:12:43] <-- TzarSectus has left IRC (Read error: 110 (Connection timed out))
[08:47:46] --> TzarSectus has joined #pentagram
[09:04:27] --> Sectus has joined #pentagram
[09:05:46] <-- TzarTzarSectus has left IRC (Read error: 110 (Connection timed out))
[09:07:15] --> TzarTzarSectus has joined #pentagram
[09:11:22] <-- TzarSectus has left IRC (Read error: 60 (Operation timed out))
[09:14:17] <-- Sectus has left IRC (Read error: 60 (Operation timed out))
[09:16:58] --> GNomeH has joined #pentagram
[09:26:15] --> TzarSectus has joined #pentagram
[09:42:22] --> Sectus has joined #pentagram
[09:46:00] <-- TzarTzarSectus has left IRC (Read error: 110 (Connection timed out))
[09:47:52] <-- TzarSectus has left IRC (Read error: 60 (Operation timed out))
[10:04:16] --> watt has joined #pentagram
[10:04:54] --- ChanServ gives channel operator status to watt
[10:22:18] --> TzarSectus has joined #pentagram
[10:28:06] --> TzarTzarSectus has joined #pentagram
[10:29:48] <-- TzarTzarSectus has left IRC (Read error: 54 (Connection reset by peer))
[10:30:50] <-- Sectus has left IRC (Read error: 60 (Operation timed out))
[10:35:09] --> Sectus has joined #pentagram
[10:37:02] <watt> wjp: It's safe to assume that if I'm not on the channel, then the server isn't running.
[10:37:34] <watt> either in windows or gone of a short trip.
[10:38:01] * watt grumbles.... font tag.... really should be handled by css....
[10:44:05] --> TzarTzarSectus has joined #pentagram
[10:46:44] <-- TzarSectus has left IRC (Read error: 110 (Connection timed out))
[10:56:10] <-- sbx has left IRC ()
[11:00:33] <-- Sectus has left IRC (Read error: 110 (Connection timed out))
[11:05:40] <-- TzarTzarSectus has left IRC (Read error: 110 (Connection timed out))
[11:20:03] <-- GingerNinja has left IRC (Read error: 104 (Connection reset by peer))
[11:31:16] <-- Darke has left IRC ("Inficio-Infeci-Infectum")
[11:39:28] <wjp> watt: yeah, I figured as much
[11:39:42] <wjp> good thing web is in cvs now :-)
[11:53:26] --> Sectus has joined #pentagram
[12:09:29] --> Darke has joined #pentagram
[12:26:58] --> GingerNinja has joined #pentagram
[13:32:19] --> TzarSectus has joined #pentagram
[13:38:06] <-- GingerNinja has left IRC (Read error: 54 (Connection reset by peer))
[13:39:43] --> GingerNinja has joined #pentagram
[13:51:02] <-- Sectus has left IRC (Read error: 110 (Connection timed out))
[13:53:59] <-- TzarSectus has left IRC ("Leaving")
[14:44:22] <-- GNomeH has left IRC (leguin.freenode.net irc.freenode.net)
[14:44:22] <-- Darke has left IRC (leguin.freenode.net irc.freenode.net)
[14:44:22] <-- GingerNinja has left IRC (leguin.freenode.net irc.freenode.net)
[14:44:22] <-- watt has left IRC (leguin.freenode.net irc.freenode.net)
[14:44:22] <-- eldron has left IRC (leguin.freenode.net irc.freenode.net)
[14:45:24] --> Darke has joined #pentagram
[14:50:15] --> GNomeH has joined #pentagram
[14:51:43] --> watt has joined #pentagram
[14:51:43] --> GingerNinja has joined #pentagram
[14:51:43] --> eldron has joined #pentagram
[14:53:28] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[14:58:05] <-- Darke has left IRC (leguin.freenode.net irc.freenode.net)
[14:59:32] --> Darke has joined #pentagram
[15:00:39] <-- watt has left IRC (leguin.freenode.net irc.freenode.net)
[15:00:39] <-- GingerNinja has left IRC (leguin.freenode.net irc.freenode.net)
[15:00:39] <-- eldron has left IRC (leguin.freenode.net irc.freenode.net)
[15:02:06] --> watt has joined #pentagram
[15:02:06] --> GingerNinja has joined #pentagram
[15:02:06] --> eldron has joined #pentagram
[15:27:12] <wjp> hm, I temporarily have access to a quad amd64 machine, but pentagram doesn't really want to run on it
[15:35:35] <wjp> interesting
[15:36:04] <wjp> it seems to get confused when using the same va_list twice in the Console::vPrintf functions
[15:37:21] <wjp> but that may be because that's not allowed in the way we use it
[15:37:42] * wjp starts reading the va_start manpage _again_
[15:41:28] * wjp hmms
[15:43:19] <wjp> ok, I think this fixed it
[15:45:38] <wjp> Colourless: (if you read this,) could you check if Console.cpp still works in windows after my changes?
[15:58:22] <wjp> ok, it starts now but segfaults around where it should start painting the world
[16:00:52] <wjp> line = -1786615436... hmmm... :-)
[16:03:59] <wjp> hm, no, that must be gdb
[16:12:13] <wjp> something here is really confused
[16:14:51] <wjp> it would appear that pointer arithmetic is going horribly wrong when computing off_pixels
[16:15:16] <wjp> it's not sign extending it should be sign extending, I would say
[16:15:29] <wjp> s/extending/extending something/
[16:17:51] <-- eldron has left IRC (Read error: 110 (Connection timed out))
[16:19:34] <wjp> ok, adding a bunch of (long)'s to all the pointer arithmetic statements in the .inl makes it work
[16:20:29] <wjp> conversation with Devon works fine
[16:21:51] <wjp> the problem seems to be the 'pitch*line' things
[16:21:59] <wjp> pitch is a uint32
[16:22:21] <wjp> line a sint32
[16:23:18] <wjp> instead of a slightly negative value it seems to be producing a positive value close to 2^32
[16:25:36] <wjp> multiplying a negative int32 with a uint32 or a uint64 seems to produce positive results
[16:26:03] <wjp> let's see if I can find the official integer promotion rules somewhere
[16:30:18] <wjp> I see... in ANSI C, when multiplying uint32 with sint32, the sint32 is 'promoted' to uint32
[16:30:27] <wjp> (if I read this correctly, that is)
[16:30:53] <wjp> and that of course totally screws up our pointer arithmetic in this case
[16:31:37] <wjp> the 'easiest' way to fix it would probably be making 'pitch' have the same size as a poiner
[16:31:40] <wjp> s/poiner/pointer/
[16:31:51] <wjp> s/have//
[16:36:29] <wjp> bug report submitted about this for now; no time to fix it right away
[17:43:13] <-- GNomeH has left IRC ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
[18:38:49] <wjp> heh, not bad... that quad amd64 compiles pentagram in 54 seconds (without PCH)
[18:43:11] <wjp> pity I can't test right now if everything works
[18:47:20] <watt> think I'm gonna take a stab at the actor turning....
[18:49:57] <wjp> if you mean anim 33/34, that's most likely only for the avatar
[18:50:11] <wjp> so I'd just put it in the avatarmover
[18:52:00] <watt> okie.. guess I'll play with that for a little while then
[18:55:12] * wjp hmms
[18:55:35] <wjp> did you change the turning code as it is currently in the non-combat movement handler?
[18:55:54] <wjp> or did I?
[18:57:08] <wjp> I think commit 1.11-1.12 changed this behaviour
[19:01:54] <wjp> turning in combat mode seems to work properly, btw
[19:16:08] --> wattquark has joined #pentagram
[19:17:09] --- wattquark is now known as watt_at_quark
[19:20:05] <watt_at_quark> err.... it works in combat correctly?
[19:20:39] <wjp> well, it turns immediately when you press the right mouse button
[19:20:47] <wjp> not sure if it uses the right anims; I'd have to check
[19:21:48] <watt_at_quark> right, but it shouldn't be facing all the directions between the begin and end yet
[19:23:28] <watt_at_quark> though I can't test that at the moment.... ssh session for coding remotely :-)
[19:23:38] <wjp> should be fairly easy to add that to combat mode, though
[19:23:46] <wjp> just turn one step and return
[19:23:56] <wjp> it should continue turning the next frame automatically
[19:25:13] <watt_at_quark> hmmm.... what do you mean?
[19:25:42] <wjp> just play a single one-step turn animation when you need to turn
[19:26:00] <wjp> then it'll realize it needs to turn further the next frame
[19:26:07] <wjp> (as long as you still have the mouse down)
[19:27:35] <watt_at_quark> only until handled occurs... then it skips the whole turning and moves in the mouse direction
[19:28:13] <wjp> why?
[19:28:35] <watt_at_quark> and handled occurs at the double click timeout in the mover
[19:28:37] <wjp> (or rather: if so, the turn check is wrong)
[19:29:59] <watt_at_quark> besides... as a side note, the original would continue turning to the direction you click even if the mouse button is released....
[19:30:23] <wjp> hm, I don't think that's desirable
[19:30:48] <wjp> OTOH, maybe it is
[19:31:28] <wjp> yeah, it probably is what we want...
[19:31:35] --> Sectus has joined #pentagram
[19:32:01] <watt_at_quark> I think it should be, I'd assume if the user clicks in a direction, they'd want the avatar to move in that direction regaurdless of the time of the click
[19:32:19] <wjp> what would happen if you move the mouse while keeping right down?
[19:32:31] <wjp> finish current turn (if applicable) and then start a new turn?
[19:32:38] <watt_at_quark> hmm.. good question
[19:32:53] <watt_at_quark> I'll have to try it.
[19:32:57] <wjp> although it probably doesn't matter which one it is, as long as the 'end' result is the same
[19:34:01] <wjp> so we could schedule a bunch of animations at once
[19:34:36] <wjp> or keep a 'currentTargetDirection' or something in avatarmover which keeps track of which direction we're currently turning to, if any
[19:34:46] <watt_at_quark> That's why I suggested trying it in the anim process.... a quick rotating turn if you weren't already facing the right direction for all actors.. although the anim for the turn differs for actors and combat
[19:35:08] <wjp> I think AnimProcess should really just play an animation
[19:35:20] <watt_at_quark> hmm.
[19:35:49] <watt_at_quark> Well, I'm for the scheduling of multiple anims.
[19:36:07] <wjp> or maybe a TurnAnimProcess
[19:36:15] <watt_at_quark> maybe...
[19:37:14] <watt_at_quark> It would probably be cleanest in the creation of an entirely new process.
[19:39:55] <wjp> although I think we should only do that if we'll need it in more places
[19:40:11] <watt_at_quark> we will... I'm sure of that.
[19:40:46] <watt_at_quark> pathfinding is probably going to want to use it
[19:40:59] <wjp> I'd have to look at that
[19:41:18] <wjp> normally people wouldn't stop walking to turn
[19:42:07] <watt_at_quark> unless they decide to turn in the opposite direction
[19:42:27] <wjp> a pathfinder shouldn't produce paths like that :-)
[19:42:51] <wjp> and the turns of the patrolling guards are coded in usecode
[19:43:13] <wjp> (instead of letting the pathfinder take care of that)
[19:43:26] <watt_at_quark> true.. but it might start a in direction that is opposite to the currect one.. hmm
[19:43:33] <wjp> yeah, that's the guard case
[19:43:53] <watt_at_quark> hardcoded... yikes
[19:44:05] <wjp> well, hardcoded in usecode :-)
[19:44:39] <wjp> and not really 'hardcoded'; I seem to remember there's a utility function that turns an actor to a given direction
[19:44:49] <watt> ah
[19:45:05] <wjp> maybe we should call that ;-)
[19:45:28] <watt> .......
[19:47:07] <watt> I'm thinking that function probably doesn't allow us to specify which anim to use... but then again maybe it's intelligent enough to figure that out based on the actor and their flags.
[19:48:17] <wjp> always use 33/34, I'd say
[19:48:51] <wjp> but I don't know if they did that
[19:49:01] <wjp> I don't really want to search through usecode to find it again :-)
[19:50:54] <watt> ah. but the turn anim is combat_stand while in combat
[19:51:11] <wjp> hm, combat; yes, good point
[19:52:26] <watt> it appear to follow location of the initial click on the turn, finish and proceed to face the next location of the mouse if you move the mouse while turning
[19:53:06] <wjp> ok
[19:53:46] <watt> so, it would just continue making completed TurnAnimProcesses until avatar faces the direction of the mouse.
[19:54:27] <wjp> I'd probably make turnToDirection a member of AvatarMoverProcess for now
[19:54:48] <wjp> fairly clean and easy to refactor into a separate process if warranted
[19:54:51] <watt> that's reasonable I guess.
[20:00:53] <watt_at_quark> I guess all it will really need a a function of the mover is the new direction as a parameter... the rest can be accessed though MainActor
[20:01:11] <watt_at_quark> s/a/as/
[20:07:27] * wjp nods
[20:08:15] <wjp> and then it should spawn a bunch of actoranimprocesses and make them wait for eachother and then finally wait for the last one itself
[20:37:02] --> TzarSectus has joined #pentagram
[20:37:19] <wjp> well, looks like we got through to the quarter finals :-)
[20:40:40] --> GNomeH has joined #pentagram
[20:44:08] <-- watt_at_quark has left #pentagram ()
[20:55:40] <-- Sectus has left IRC (Read error: 110 (Connection timed out))
[21:03:52] --> TzarTzarSectus has joined #pentagram
[21:08:49] <-- TzarTzarSectus has left IRC ("Leaving")
[21:08:57] --> Sectus has joined #pentagram
[21:12:24] <-- TzarSectus has left IRC (Read error: 60 (Operation timed out))
[21:46:08] --> TzarSectus has joined #pentagram
[21:54:17] <-- GNomeH has left IRC (Read error: 54 (Connection reset by peer))
[21:54:41] <-- Sectus has left IRC (Read error: 60 (Operation timed out))
[21:54:45] <wjp> watt: still around?
[21:55:25] --> GNomeH has joined #pentagram
[22:05:04] --> TzarTzarSectus has joined #pentagram
[22:08:32] <-- TzarTzarSectus has left IRC (Client Quit)
[22:12:25] --> Kirben has joined #pentagram
[22:12:25] --- ChanServ gives channel operator status to Kirben
[22:12:59] <-- GNomeH has left IRC (Read error: 60 (Operation timed out))
[22:13:04] <wjp> watt, Colourless: I wrote a status-update-in-need-of-polishing for the new news page
[22:13:08] <wjp> http://www.math.leidenuniv.nl/~wpalenst/pentagram/web/
[22:13:19] <wjp> also removed the history button for now, as we have no old news items yet
[22:13:36] <-- TzarSectus has left IRC (Read error: 60 (Operation timed out))
[22:14:40] <wjp> hm, maybe putting the date above the news item would be a better use of screen space
[22:14:58] <wjp> ah well, time to go for now; night
[22:44:49] --> GNomeH has joined #pentagram