#pentagram@irc.freenode.net logs for 30 Jun 2003 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage

[00:28:57] <-- Dark-Star has left IRC ()
[02:48:54] --> Cashman has joined #pentagram
[02:49:05] * Cashman has a question for wjp/dark-star
[02:49:30] <Cashman> I read the logs, what do I have to change to get partial crusader support? does it kinda work dark-star/wjp??
[02:49:33] <Cashman> hmm
[02:50:34] <Cashman> if its a signed/unsigned issue, can the detector etc. be changed easily to handle this? and still run u8
[02:50:51] <Cashman> I see colourless has entered somemore no regret instrinics
[02:51:02] <-- Cashman has left IRC (Client Quit)
[02:58:05] --> Kirben has joined #pentagram
[02:58:05] --- ChanServ gives channel operator status to Kirben
[07:16:44] --> wjp has joined #pentagram
[07:16:44] --- ChanServ gives channel operator status to wjp
[07:45:58] <wjp> Cashman: there is no partial crusader support at all
[07:46:13] <wjp> signed/unsigned issue has already been fixed. That was really just a minor buglet
[08:20:14] --> Kirben2 has joined #pentagram
[08:21:00] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[08:49:19] --> Cashman has joined #pentagram
[08:50:24] * Cashman will see what new fps he gets in pentagram, getting a new video card tomorrow or the next day
[08:51:28] <Cashman> wjp do you know what dark-star was trying to do with crusader in pentagram?? I mean there would be no way of displaying cru maps without a majour hack right!
[08:51:41] <Cashman> I do now realise there is no support at all!
[08:59:03] <wjp> dark-star entered crusader into his config file anyway
[08:59:11] <wjp> and the gamedetector got 'confused' because it wasn't U8
[08:59:31] <Cashman> ok
[09:12:19] <Cashman> whats happening? nice to see earth quakes etc.
[09:13:25] --- wjp is now known as wjp|work
[09:13:38] <wjp|work> I've been working on the savegame system a bit
[09:13:59] <Cashman> I see, nice
[09:14:51] <Cashman> I read the logs, sounds like both a challenging and great feature to add
[09:15:12] <wjp|work> it's a rather necessary feature :-)
[09:15:20] <Cashman> by great feature I mean how flexible you plan to make it
[09:15:23] <Cashman> yip I see
[09:17:27] <Cashman> oh I keep meaning to ask, you havn't forgotten about animator animation (puppets) have you? I remember there was animation in the face of npcs
[09:19:37] <wjp|work> submit a bug report if you want to make sure :-)
[09:19:44] <Cashman> hehe I just realised you just started work not too long ago, I'll bother you some othertime wjp
[09:19:45] <Cashman> ok
[09:19:51] <Cashman> hehe get the activity up! lol
[09:20:01] <wjp|work> I started work 2 hours ago, in fact :-)
[09:20:14] <Cashman> ok
[09:20:53] <Cashman> I'm in NZ next to aus so time zones are very diff
[09:21:06] <Cashman> I think I've dicussed that before though hehe
[09:21:18] --- Cashman is now known as Cash|Away
[09:25:02] <-- Cash|Away has left IRC ()
[14:25:35] --> Colourless has joined #Pentagram
[14:25:38] --- ChanServ gives channel operator status to Colourless
[14:29:38] <Colourless> hi
[14:40:27] <wjp|work> hi
[14:45:17] <wjp|work> I've got some basic saving framework in place at home
[14:45:27] <wjp|work> not saving much yet, though :-)
[14:45:39] <Colourless> :-)
[14:45:53] <wjp|work> mostly the order of processes in the process list :-)
[14:46:05] <wjp|work> savegames are going to be pretty huge, btw
[14:46:16] <Colourless> I've got some basic midi framework here.. surprise surprise.. as if everyone didn't know from my defines :-)
[14:46:33] <wjp|work> I'm guessing about 2Mb uncompressed
[14:47:18] <Colourless> the original games savegames were about 400k
[14:47:23] <wjp|work> yes
[14:48:05] <Colourless> of course they didn't have to worry about such things as platform portability, and sane ways to store and restore data
[14:48:26] <wjp|work> we'll just have to compress everything to manageable sizes :-)
[14:48:59] <Colourless> saving vtable pointers to disk.... yes, it's an easy way to ensure that the correct class gets restored, but gee, it just has a 'few' wee problems :-)
[14:49:29] <wjp|work> oh yes, I seem to remember their QA department loved having all savegames invalidated with every new build :-)
[14:51:56] <Colourless> music.flx entry 1 is most interesting. It contains data in it how to transition between each of the songs.... I 'sort' of know how it was meant to work, but honestly, i don't have much of an idea.
[14:52:40] <Colourless> s/1/0/
[14:53:59] <Colourless> the format is kind of like this "song_to.xmi song_from.xmi 1 1 1 1 1 1 1 1" where the 1s are a some indicator of how to transition. It appears that there are as many numbers as there are bars in the song.
[14:54:38] <Colourless> Now, it 'would' probably be fairly easy to understand IF there was only numbers... but of course, it's more complex than that. Some of the numbers have ! in front of them, which just utterly confuses me :-)
[14:55:09] <Colourless> examples:
[14:55:12] <Colourless> execute.xmi docks.xmi 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8
[14:55:15] <Colourless> docks.xmi tenebrae.xmi !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1 !1
[14:55:32] <Colourless> combat.xmi air.xmi 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
[14:55:43] <Colourless> running.xmi combat.xmi 0 0 0 0 0 0 0 0 0 0
[14:56:48] <wjp|work> um, how interesting :-)
[14:57:15] <Colourless> my guess is 0 means instant change. :-)
[14:57:18] <wjp|work> ! could be a 'not' (whatever that would mean here), or maybe a 'force'
[14:58:25] <wjp|work> I wonder what kind of transitions there would be...
[14:58:38] <wjp|work> fades? waiting x seconds while not starting any new notes?
[14:58:47] <Colourless> fades as far as I know
[15:01:02] <Colourless> hmm interesting
[15:01:15] <Colourless> i just played around with the u8 just then with music on
[15:01:44] <Colourless> going from tenebrae to docks instantly stops tenebrae, but fades into docks
[15:02:04] <Colourless> and going from dock to tenebrae fades out docks and then isntantly starts playing tenebrae
[15:02:29] <-- Kirben2 has left IRC (Read error: 54 (Connection reset by peer))
[15:02:31] <wjp|work> how does the tenebrae.xmi docks.xmi line look?
[15:02:38] <Colourless> tenebrae.xmi docks.xmi 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
[15:02:58] <Colourless> i'll try some others
[15:03:27] <wjp|work> so 0 would mean: fade out, start instantly
[15:03:48] <wjp|work> a ! might mean stop instantly
[15:04:02] <wjp|work> with 1 indicating a fade-in or something
[15:04:05] <wjp|work> (purely guessing of course)
[15:04:40] <wjp|work> does it start playing combat music immediately when you switch to combat mode?
[15:05:29] <wjp|work> hm, time to go home; I'll bbl
[15:05:31] <-- wjp|work has left IRC ("bbl")
[15:27:25] <Colourless> before i said it was
[15:27:29] <Colourless> song_to.xmi song_from.xmi
[15:27:42] <Colourless> but it actually looks like it's the other way round. so it's
[15:27:55] <Colourless> song_from.xmi song_to.xmi numbers
[15:31:55] --> wjp has joined #pentagram
[15:31:55] --- ChanServ gives channel operator status to wjp
[15:32:13] <wjp> back :-)
[15:32:33] <Colourless> wb
[15:34:31] <Colourless> it's time to modify a data file to see what happens
[15:38:47] <wjp> that's always fun :-)
[15:39:39] <Colourless> setting tenebrae to dock to 1 made the fade in made it slow. setting it to 9 made it quick
[15:40:22] <wjp> the '!' inverts which one fades?
[15:41:54] <Colourless> actually more specifically, setting it to 1 makes there be a really really long pause
[15:42:11] <Colourless> i changes combat.xmi to running.xmi to all 1s
[15:42:24] <Colourless> there was a huge lenght of silence
[15:42:38] <Colourless> s/lenght/length/
[15:43:37] <Colourless> what i also noticed was that when changing between areas it would advance the songs along to their 'next' section. Its possible the fade in's are actually part of the song, and the ! means fade out. I'm not entirely sure, but it would 'seem' to make sense
[15:47:07] <Colourless> yes i'm pretty sure that is how it works
[15:48:41] <Colourless> i'm guessing also that the times are calculated by some number divided by the number specified
[15:51:02] <wjp> which tracks are there that aren't triggered by music-eggs?
[15:51:29] <wjp> combat? running? spells?
[15:51:35] <Colourless> combat, death, running, all the titan music
[15:51:48] <wjp> some are usecode-triggered I guess?
[15:51:52] <Colourless> yes
[15:52:02] <Colourless> quotes obviously isn't :-)
[15:52:16] <Colourless> intro, falling, theme
[15:52:17] <wjp> does it revert to the previous song after playing special songs?
[15:52:34] <wjp> hm, trans.xmi?
[15:52:34] <Colourless> no
[15:52:41] <wjp> transition?
[15:53:01] <Colourless> yes. i guess that signals that transitions are beginning
[15:53:42] <wjp> wow, there are actually some transitions where the numbers aren't all equal :-)
[15:54:19] <Colourless> yeah air
[15:55:34] <Colourless> hmm, looking closely at the xmidi files, there are a number of different XMIDI contollers that i hadn't previously noticed
[15:55:54] <Colourless> in particular some XMIDI_CONTROLLER_CALLBACK_TRIG and XMIDI_CONTROLLER_SEQ_BRANCH_INDEX events
[15:56:11] <Colourless> i'm guessing they are being used to mark where sections of the song begin and end
[15:57:50] <Colourless> the data for the callback triggers is the bar it's at
[15:58:18] <Colourless> it calls them... gasp... every bar
[15:59:54] <Colourless> info about these lines:
[15:59:55] <Colourless> intro.xmi 1 10 5
[16:01:42] <Colourless> [song filename] [index of song in flex (cast to int)] [number of bars = number of numbers in transition lines] [bar of repeat start, 1 based, 0 if doesn't repeat]
[16:03:07] <Colourless> well, that's one mystery solved now :-)
[16:44:39] <wjp> objid, shape, frame, x, y, z, flags, q, npcnum, mapnum, extendedflags, gump, gravitypid, glob_next... that's 40 bytes
[16:44:54] <wjp> add some header stuff, and we're at 50-60 bytes
[16:44:56] <wjp> (per item)
[16:45:02] <wjp> multiple by 30000...
[16:45:06] <wjp> s/ple/ply/
[16:45:28] <Colourless> thats.. quite a bit :-)
[16:45:36] <wjp> yes :-)
[16:45:56] <wjp> main cause is of course in-glob items
[16:50:45] <wjp> we could consider un-expanding globeggs when they leave the fastarea
[16:50:45] <Colourless> yes, we could
[16:50:45] <wjp> IIRC, we'd have about 4K-5K objects then
[16:50:45] <Colourless> also we could use something 'else' to store glob_next
[16:50:45] <wjp> which put objects at ~300K
[16:50:45] <wjp> wouldn't save that much
[16:50:45] <Colourless> such as q, which shouldn't be used by glob items
[16:50:45] <Colourless> yes i know, but every bit counts :-)
[16:50:45] <wjp> store x,y,z as uint16?
[16:50:45] <Colourless> also, gravitypid could be set but the process
[16:50:45] <Colourless> yes uint16
[16:50:45] <wjp> gravitypid, gump can be reconstructed
[16:50:45] <wjp> would save 12 bytes per item in total
[16:50:45] <Colourless> gump... will be interesting. would need to be a 2 pass operation cause the gump could be restored before the item
[16:50:45] <wjp> yeah
[16:50:45] <Colourless> but it's not hard. just have an operation such as gumps->findOwner()
[16:50:48] <Colourless> or some such with a better function name :-)
[16:51:18] <wjp> we'd still be stuck with over 1Mb of object data
[16:51:47] <wjp> I wonder how well it can be compressed
[16:52:24] <Colourless> pretty well, i would think, if we make sure that we zero out all the unused stuff
[16:54:55] <wjp> glob_next is totally unused currently, btw
[16:55:24] <wjp> (since the contents are cleared by just not saving them :-) )
[16:57:35] <wjp> hm, only about 960Kb when 'saving' at the start
[16:57:42] <wjp> (only the items, currently)
[16:58:04] <wjp> gzip makes it 168Kb
[16:58:14] <Colourless> not bad :-)
[16:58:36] <wjp> bzip2: 140Kb
[16:59:02] <wjp> rar: 125Kb
[16:59:02] <Colourless> better, but not a commonly used format on all systems
[16:59:04] <wjp> going down :-)
[16:59:33] <wjp> zip is the same as gzip
[16:59:53] <Colourless> well, you'd think so since they are the same compression algorithm :-)
[17:01:49] <wjp> that might just explain it :-)
[17:03:33] <wjp> it'll probably get a bit bigger because I didn't add full headers to the items yet, and of course other things need to be saved too
[17:03:49] <wjp> other maps will probably be the largest part of that
[17:04:09] <wjp> (U8's nonfixed.dat is already 200K... *shudder*)
[17:04:32] <Colourless> ours will probably be around 300
[17:04:48] <wjp> anyway, zipped it shouldn't be a problem
[17:05:10] <wjp> btw, the 'Savegame' and 'SavegameWriter' class I'm writing should be easily subclassable to support zipped savegames
[17:05:31] <wjp> s/class/classes/
[17:40:24] <wjp> bbl, dinner
[17:40:30] <Colourless> k
[18:14:01] <wjp> back
[18:14:07] <Colourless> wb
[18:33:01] <wjp> modifying Object.h is painful :-)
[18:33:20] <Colourless> oh, it's not that bad, you don't quite have to recompile everything :-)
[18:33:41] <wjp> no, there must be, oh, 2 files that don't need recompiling? :-)
[18:34:19] <wjp> (2 or 3 directories, I guess)
[18:34:31] <Colourless> if you want those 2 files to need to be recompiled, just add Object.h into pent_include.h
[18:35:09] <wjp> for PCH that would be a pretty good idea, actually :-)
[18:44:26] <wjp> hmm.. interesting
[18:44:40] <Colourless> yes?
[18:44:41] <wjp> Kernel pulls is UCMachine now :-)
[18:44:58] <wjp> s/is/in/
[18:45:00] <Colourless> why?
[18:45:14] <wjp> Kernel saves Object, Object calls usecode... :-)
[18:45:46] <wjp> hm, it pulls in UCProcess, to be exact
[18:46:04] <wjp> ...which pulls in UCMachine
[18:47:51] <wjp> can be avoided by making the save function virtual
[18:49:09] <wjp> (which it wasn't because the non-virtual one did "writeheader(); savedata();", and the latter would be virtual)
[19:06:15] * wjp hmmms... equipment
[19:06:37] <wjp> I would like to store it as contents in a Container... but... :-)
[19:07:06] <Colourless> we can
[19:07:14] <wjp> yeah, just need to be careful
[19:07:31] <Colourless> who says that sill intrinsic that is meant to access the equip has to work the same
[19:07:43] <Colourless> as the original
[19:08:14] <Colourless> we could even do things as silly as store the equip items at the gump coors (0,0) to (6,0) or whatever :-)
[19:08:31] <wjp> interesting idea :-)
[19:08:51] <wjp> (of course it isn't necessary, as that info is already in the ShapeInfo anyway)
[19:09:01] <Colourless> yeah
[19:09:03] <wjp> ah well, I'll hack something up :-)
[19:09:13] <wjp> guess the CanAddItem() function will have to become virtual
[19:09:46] * wjp wonders if he added all actor attributes already
[19:10:04] <wjp> str, dex, int, hp, mana, lastanim, lastdir, actorflags
[19:10:16] <wjp> did we document npcdata anywhere? :-)
[19:10:25] <Colourless> hey, if you haven't, remember it doesn't matter if you break savegames, if you haven't committed the code yet
[19:10:30] <Colourless> hmm, no
[19:12:17] <wjp> I'm constantly breaking my own savegames here :-)
[19:12:25] <Colourless> ooh, wow, a 'permanent' sprite in the cemetary... i moved over a fireshroom and left the map before the explosion animation finished... so the process that controls it got terminated and the item stayed
[19:12:40] <wjp> oops :-)
[19:12:43] * Colourless adds make sprites not in map items to his list
[19:13:24] <Colourless> ah well, the original game (with usecode created item) did similar
[19:13:37] <Colourless> i had a permanent fire ball in Daemon
[19:13:59] <Colourless> 's crag once
[19:14:55] <wjp> Usecode classes should have destructors ;-)
[19:15:05] * wjp takes that back before he gives Darke any ideas :-)
[19:15:11] <Colourless> hehe, to late
[19:15:20] <Colourless> darke an i already discussed such things once
[19:15:36] <Colourless> we also thought about how to give usecode classes member variables
[19:16:08] <Colourless> if i'm not mistaken FLG_DISPOSABLE should act the same as EXT_NOTINMAP
[19:16:27] <wjp> sounds like it, yes
[19:16:57] <Colourless> perhaps we should 'migrate' everything over to FLG_DISPOSABLE since it already exists
[19:17:15] <wjp> ok by me
[19:22:26] <wjp> can hitpoints be negative?
[19:22:39] <Colourless> no idea
[19:22:48] <Colourless> i don't think so
[19:23:04] <Colourless> but it never hurts to use signed :-)
[19:23:22] <wjp> mana?
[19:23:57] <wjp> should always be >= 0, I guess
[19:24:10] <Colourless> void Npc::setMana(word mana)
[19:24:23] <Colourless> void Npc::setHp(ubyte hp)
[19:24:25] <wjp> k
[19:24:27] <wjp> signed, then :-)
[19:24:42] <Colourless> byte Npc::getStr()
[19:24:59] <Colourless> i think you can work out how to get those sorts of things
[19:25:03] <wjp> hm, that's exactly the opposite of what I would've guessed
[19:25:29] <Colourless> does that surprise you though?
[19:25:31] <Colourless> :-)
[19:26:52] <wjp> right, so sint16 str,dex,int,mana; uint16 hp...
[19:28:19] <Colourless> allignment stuff
[19:28:35] <wjp> ah, yes
[19:28:56] <Colourless> and all the various npc flags
[19:29:01] <wjp> there was an alignment and an enemy-alignment, right?
[19:29:10] <Colourless> looks like it
[19:29:18] <wjp> I put those in uint32 actorflags
[19:29:22] <Colourless> activity
[19:29:47] <Colourless> which is like one off 3 things
[19:30:09] <Colourless> of course that's a process and i don't know if it should be stored in the npc structure
[19:33:34] <wjp> the alignments sound like some kind of 'factions'... people with the same alignment are allies, and you can have another 'faction' as your (current) enemy
[19:34:48] <Colourless> yes
[19:34:57] <Colourless> might also use bit masks or something
[19:35:19] <Colourless> but i don't think that's likely
[19:35:22] <wjp> will have to check usecode, I guess
[19:35:25] <wjp> (not that it really matters)
[19:40:16] <wjp> setTarget/getTarget... so need to store a current target too, I guess
[19:41:38] <Colourless> i think i'm going to be off now
[19:41:53] <wjp> k, night
[19:41:56] <Colourless> cya
[19:42:01] <-- Colourless has left IRC ("casts invisibility")
[20:44:13] <DarkeZzz> (member variables) IIRC, we discussed somehow allowing people to create their own variables and accessing them through Item::getQ/setQ equlivants a while back. IIRC, it was something like storing an array of pointers of 'N' size (the same size as the number of user defined member variables of the class of that particular item), of any particular type. This would, of course, have required both constructors and destructors to make sure things a
[20:44:13] <DarkeZzz> re sane, and to ensure we properly free strings and lists and such. *grin*
[20:45:15] <wjp> morning
[20:46:10] <DarkeZzz> Morning.
[20:46:17] <wjp> hardly, but thanks ;-)
[20:46:28] <DarkeZzz> (Or the particular equilivant in your timezone anyway. *grin*)
[20:48:16] <wjp> saving is really annoying to implement :-)
[20:50:19] <DarkeZzz> I can guess that. Better you then me anyway. *grin*
[20:52:26] <wjp> the amount of upgraded packages in gentoo is kind of disturbing
[20:52:40] <wjp> (the last week or so, that is)
[20:59:19] <DarkeZzz> Yes, I saw that too.
[21:00:41] <wjp> slashdot had a story about gentoo that contained something that looked like an explanation
[21:00:45] <DarkeZzz> They've been trying to get into a pattern of lock->test->release for a while (trying) to make gentoo a bit more stable, rather then trickling packages out at a steady rate.
[21:01:22] * DarkeZzz earperks and quickly checks. Hasn't looked at /. in a couple of days actually. *grin*
[21:01:29] <wjp> about the fork
[21:06:09] * DarkeZzz ugs. Too. Long. To. Read. This. Early. In. Morning.
[21:06:32] <wjp> too long to read. period. :-)
[21:06:42] <wjp> interesting read, though
[21:56:40] <-- wjp has left IRC ("Zzzz...")
[22:50:38] --> DraX has joined #pentagram
[22:56:55] <-- DraX has left IRC ("bye? ..(sph)")