#pentagram@irc.freenode.net logs for 4 Sep 2004 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage


[00:31:47] <-- Fingolfin has left IRC ("42")
[01:42:06] --- sbx|afk is now known as sbx
[01:55:54] --> Sheng_Gradilla has joined #pentagram
[01:55:58] <Sheng_Gradilla> :)
[04:40:18] * Sheng_Gradilla is away: No estoy
[07:59:52] --> Colourless has joined #Pentagram
[08:00:02] --- ChanServ gives channel operator status to Colourless
[09:39:30] <-- Sectus has left IRC ("Leaving")
[11:31:13] * Sheng_Gradilla is back (gone 06:50:52)
[11:39:37] <-- Sheng_Gradilla has left IRC ("Terminando cliente")
[11:59:43] --> wjp_ has joined #pentagram
[12:01:57] --> Fingolfin has joined #pentagram
[12:01:57] --- ChanServ gives channel operator status to Fingolfin
[12:54:57] <wjp_> to get back to killing processes on map change: any processes belonging to map items are automatically killed already when the map is unloaded
[12:55:20] <Colourless> and?
[12:55:45] <wjp_> the processes not killed automatically at that point are those belonging to NPCs and their inventory
[12:56:00] <wjp_> in World::switchMap we currently kill those anyway, btw
[12:56:11] <wjp_> and then there are processes which don't belong to any item
[12:56:25] <wjp_> which we keep alive on map change
[12:56:55] <wjp_> so to keep that blackrock process at the end alive, we have to keep at least processes belong to avatar's inventory
[12:57:05] <Colourless> yes
[12:57:28] <wjp_> processes belonging to other NPCs and their inventories should most likely be shot
[12:58:06] <wjp_> although it would be interesting to determine that criterium
[12:58:31] <wjp_> s/ium/ion/
[12:58:48] <wjp_> (funny that dutch has the latin variant of that word and english the greek one :-) )
[13:00:12] <Colourless> heh
[13:01:10] <-- Fingolfin has left IRC ("42")
[13:02:36] <wjp_> hm, this is also interesting
[13:02:50] <wjp_> that blackrock process sets its process type to 1
[13:04:10] <wjp_> which is strange since most usecode processes have types in the 0x200
[13:05:07] <Colourless> might be speical meaning
[13:05:13] <Colourless> persistent or somethin
[13:05:21] <wjp_> other processes with type 1 seem to be in class SINKING, MORDEABE, LOGBOOK, NEC1
[13:05:27] <wjp_> (and probably others)
[13:05:41] <wjp_> those are things that kill you or teleport you
[13:05:48] <wjp_> so I think that's probably it
[13:06:01] <Colourless> interesting
[13:06:21] * wjp_ hmmms
[13:06:32] <wjp_> a long time ago we decided to keep processes with item_num == 0 around
[13:06:43] <wjp_> I wonder if those cases would also be caught by type != 1
[13:09:11] <wjp_> hehe, we noted that type != 1 before there :-)
[13:09:20] <wjp_> but chose to go with the item_num == 0 criterion :-)
[13:09:23] <wjp_> http://www.math.leidenuniv.nl/~wpalenst/pentagramlog.php?log=20Jun2003
[13:09:32] <wjp_> (19:26)
[13:10:01] <Colourless> hehe
[13:10:07] <Colourless> ok then... why was it not implemented?
[13:10:25] <wjp_> well, item_num != 0 covered that case just as well
[13:10:48] <wjp_> and we probably didn't do anything with process types at that point yet, so we didn't realize that 1 wasn't a common type
[13:10:59] <wjp_> (at least I didn't)
[13:15:37] <Colourless> hehe
[13:15:38] <Colourless> [22:19:13] <Dominus> let's release Pentagram 1.0 in about two years
[13:15:47] <Colourless> i think we can do it
[13:17:31] <wjp_> hm, 20 Jun 2005? possible
[13:19:23] <wjp_> well, unsurprisingly that fixed that problem after killing a titan
[13:20:14] <-- Kirben has left IRC (Read error: 54 (Connection reset by peer))
[13:20:42] <wjp_> although it does seem to be a bit overenthusiastic in killing our own internal processes :-)
[13:21:23] <wjp_> (avatarMoverProcess got toasted)
[13:24:12] <wjp_> I guess I should go over all of them to see if their type should be 1
[13:26:02] <wjp_> AvatarMoverProcess and TeleportToEggProcess are probably the only ones, luckily
[13:26:16] <wjp_> or maybe MusicProcess too?
[13:54:53] <wjp_> ugh; I'm getting weird crashes in the pyros summoning scene now
[14:05:16] <wjp_> ah, that might be totally unrelated to this
[14:05:35] <wjp_> the fade intrinsics sometimes delete a process
[14:05:43] <wjp_> that's not kind of bad :-)
[14:05:46] <wjp_> s/not//
[14:18:21] <wjp_> ok, finally committed every change in my local copy
[14:19:17] <wjp_> now, it's the 4th again, so time to update the homepage
[14:19:34] <wjp_> shall I mention the fact that I finished U8? :-)
[14:19:55] <wjp_> maybe not... it might create unrealistic expectations
[14:20:14] <DarkeZzz> Bad idea. We'll have people who can't hack the engine to fix their way around problems, trying it. *grin*
[14:30:59] <wjp_> unfortunately I can't seem to get into SF's shell server to update the news :/
[14:33:33] <Colourless> yay for sf
[14:47:24] --- sbx is now known as sbx|afk
[16:44:39] <wjp_> Colourless: any objections to always anchoring ItemRelativeGumps to the root container in the GameMapGump?
[16:44:58] <Colourless> no
[16:44:59] <wjp_> this would prevent child-container gumps from moving when moving a parent gump
[16:51:00] <wjp_> oh, umm.. that would not be desirable for BarkGumps
[16:51:15] <Colourless> hm. true
[16:52:15] <wjp_> virtual function defaulting to the current behaviour and override it for ContainerGump?
[16:53:31] <Colourless> sounds fine to me
[17:12:52] --- sbx|afk is now known as sbx
[17:30:51] <wjp_> hm, it's probably about time to fix invisibility
[17:31:09] <wjp_> invisible items should really be invisible, not translucent
[17:31:24] <wjp_> (it spoils all kinds of special effects :-) )
[17:31:26] <Colourless> not hard... just skip rendering invis items
[17:32:19] <wjp_> would you do that before adding them to the itemsorter or just before painting them?
[17:32:38] <Colourless> adding
[17:32:54] <wjp_> ok, so that should be at the same place as where we skip SI_EDITOR items
[17:33:25] <Colourless> hmm
[17:33:38] <Colourless> dragging items... need a specific flag for trans painting
[17:33:54] <wjp_> indeed
[17:34:23] <wjp_> extended flag?
[17:34:30] <Colourless> probably
[17:45:07] <wjp_> ok, that should take care of that
[18:04:57] --> Sectus has joined #pentagram
[18:05:57] <wjp_> Colourless: do you have the time to talk about audio a bit?
[18:11:13] <Colourless> sure a bit
[18:13:50] <wjp_> part of the problem is that I don't have that much experience with audio stuff.. :-)
[18:13:55] <wjp_> (I've been trying to avoid it mostly :-) )
[18:14:19] <Colourless> hmm well... i probably should do it
[18:14:31] <wjp_> I would have absolutely no objections to that :-)
[18:14:36] <Colourless> just been a bit... distracted
[18:14:48] <Colourless> thouigh i do really have a lot of time
[18:16:20] <wjp_> what are you spending it on currently?
[18:16:50] <Colourless> nwn... STILL
[18:16:59] <wjp_> :-)
[18:17:23] <wjp_> quite tempting to try multiplayer NWN myself sometime... :-)
[18:19:26] <Colourless> don't....
[18:21:58] <wjp_> from what I understand we'd need a mixer, things to mix, and a way to output the result
[18:22:10] <Colourless> hmm.. yes that is the usual way
[18:22:35] <wjp_> would libraries like SDL_mixer or SDL_sound help?
[18:23:08] <Colourless> don't know much about SDL_sound
[18:23:12] <wjp_> SDL_mixer is probably too limited
[18:23:19] <Colourless> sdl_mixer isn't really what we want
[18:23:32] <Colourless> especially if we are doing the decompression ourself of the samples
[18:23:36] <wjp_> SDL_sound had a fairly interesting-looking set of specs for SDL_sound 2
[18:24:16] <wjp_> (but that's not done yet)
[18:25:32] <wjp_> http://twomix.devolution.com/pipermail/sdl/2004-July/064209.html
[18:26:19] <wjp_> but I can't really judge if it's useful or not
[18:29:40] <Colourless> sounds sound useful for us
[18:40:01] <Colourless> doesn't sound use useful for us really
[18:40:40] <Colourless> my god... my typing is worse than normal
[18:45:12] --> Sheng_Gradilla has joined #pentagram
[18:45:14] <Sheng_Gradilla> :)
[18:46:11] <Colourless> idon't even get what sdl_sound is supposed to do...
[18:47:03] <wjp_> from what I can tell SDL_sound 1 is mostly a decoder for various formats while SDL_sound 2 aims to be a full mixer
[18:47:26] <wjp_> but 2 appears to be still in the planning stage
[18:51:50] <wjp_> so it's probably not useful for us (at least not in the near future)
[19:22:52] --> Fingolfin has joined #pentagram
[19:22:52] --- ChanServ gives channel operator status to Fingolfin
[19:51:35] <-- wjp_ has left IRC ("bbl")
[19:52:17] --> Fl00der has joined #pentagram
[19:54:06] --> wjp_ has joined #pentagram
[20:54:02] <-- wjp_ has left IRC ("leaving")
[20:56:37] <-- Colourless has left IRC ("casts improved invisibility")
[21:51:32] <-- Fingolfin has left IRC ("42")
[22:05:08] <-- Fl00der has left IRC ()
[22:37:50] --> Kirben has joined #pentagram
[22:37:50] --- ChanServ gives channel operator status to Kirben
[23:03:04] --- sbx is now known as sbx|afk
[23:25:47] <-- Sheng_Gradilla has left IRC ("bbl")