#pentagram@irc.freenode.net logs for 9 Feb 2004 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage


[00:22:20] --> Kirben has joined #pentagram
[00:22:20] --- ChanServ gives channel operator status to Kirben
[00:34:40] --> Thoth has joined #pentagram
[00:39:09] <-- shinji-kun has left IRC (Read error: 110 (Connection timed out))
[00:43:06] <watt> hmmm.. should I worry about quotes in the console combining multiple words into a single argument?
[01:14:18] --> Knight has joined #pentagram
[01:41:58] <Knight> anybody there?
[01:53:59] <watt> I'm here... I think
[02:22:02] <Knight> hehe
[02:55:11] <watt> wee.. simple patch posted for support of bind and exec.
[02:57:10] <watt> hmm.. crap.. the SDL keys use spaces in between words for some keys... that breaks argument handlings
[04:16:44] <-- Thoth has left IRC (Remote closed the connection)
[04:36:36] --> Colourless has joined #Pentagram
[04:36:36] --- ChanServ gives channel operator status to Colourless
[04:37:18] <Colourless> cfg file format would be best discussed on the mailing list, so i'm going to put my reply there
[04:37:30] <-- Colourless has left IRC (Client Quit)
[06:22:58] <-- watt has left IRC ("using sirc version 2.211+KSIRC/1.2.4")
[07:59:16] <-- Kirben has left IRC ("System Meltdown")
[08:04:04] <wjp> Knight: yes?
[08:10:21] --> Kirben has joined #pentagram
[08:10:21] --- ChanServ gives channel operator status to Kirben
[09:32:48] --> Cashman has joined #pentagram
[09:33:07] <Cashman> I cant agree more with dominus .cfg format, he can have my vote
[09:33:07] <Cashman> :-)
[09:33:26] <Cashman> how many votes does he have ?
[09:40:58] * Cashman downloads latest build
[09:45:20] <wjp> we're not really voting yet :-)
[09:48:37] <Cashman> ok
[09:49:04] <Cashman> hey well done with the console commands, even though it cant be much effort! I was wondering when u would after all this time put some in
[09:49:52] <wjp> well, we didn't handle keyboard input properly at all until quite recently
[09:50:56] <Cashman> yeah thats trye :-P
[09:51:44] <Cashman> hey is it worth reading up about the new dos box :-) I hear it runs slow, I wasnt gonna try it cause I currently not running a linux dist
[09:53:56] <Cashman> are default key bindings currently hacked into the source??
[09:54:17] <Cashman> opps sorry I found them
[09:54:23] <Cashman> \data :-)
[09:54:56] <Cashman> dominus's idea was to go ahead, would the key bindings go in his format?? like quake 2?
[09:55:21] <Cashman> I a little muddled from quickly flicking through that, dominus was that ur idea? - when u read this
[10:03:50] <Cashman> hope this isnt too much to ask, well its just a question I not trying to be impatient or rude
[10:04:20] <Cashman> what would it take to make a hack to even partially display the crusader maps - I not talking about anything further, no usecode support or anything
[10:04:58] <Cashman> TGWDS - I hear theres a bit of talk about them yet they aint supported, why dont u just make them TGW do support now
[10:05:57] * Cashman goes off to play ultima 8
[10:06:00] <-- Cashman has left IRC ()
[10:11:26] --> Cashman has joined #pentagram
[10:11:34] <Cashman> freenode host dosbox :-P nice
[10:15:16] <-- Cashman has left #pentagram ()
[10:16:24] --> Cashman has joined #pentagram
[10:16:55] <Cashman> so I guess u guys can run ultima8 under linux now, no need to worry about windows wif the win32 patch
[10:17:04] <Cashman> :-P nice! u having fun wjp?
[10:17:44] <-- Cashman has left #pentagram ()
[10:22:57] --> Cashman has joined #pentagram
[10:23:01] <-- Cashman has left #pentagram ()
[10:54:43] --> Colourless has joined #Pentagram
[10:54:43] --- ChanServ gives channel operator status to Colourless
[10:55:10] <Colourless> and actual greetings here :-)
[10:57:50] <Colourless> my configuration thoughts have been sent to pentagram-devel
[11:00:57] <wjp> hi
[11:00:59] <wjp> so I see
[11:02:22] <wjp> quite long, isn't it? :-)
[11:07:52] <Colourless> yeah it was :-)
[11:09:49] <wjp> currently at work, so it might take some time to get throught it :-)
[11:10:02] <wjp> s/throught/through/
[11:11:29] * Darke scratches head and admits he must favour the 'command' based config file approach. Simply because it results in less... well... repeated dumb questions and errors. Plus it's much easier to give a coherent error/help on. And almost trivial to describe. *grin*
[11:11:59] <Darke> It also favours cut&paste documentation more then .ini style does, I've found.
[11:12:17] <wjp> it also tends to create a mess :-)
[11:12:42] <Darke> We've encountered similar problems in the past with our xml files where you tell a user to put 'X' in section 'Y', and... they don't. *grin*
[11:13:13] <Darke> I've found .ini style makes more of a mess myself. *grin*
[11:13:34] <Darke> Simply because you end up having things seperated that should be grouped in the same area.
[11:13:42] <Darke> Like aliases and original bindings.
[11:14:36] <Darke> Command line does tend to make each command more redundant too... which is both a benifit on one paw and a pain on another.
[11:17:34] <Darke> And like it or not, I think far more people will be familiar editing console scripts (given that almost any game that looks vaguely like a fps, or runs on one of the engines written for it), then windows .ini files.
[11:17:48] <Colourless> actually, not true :-)
[11:17:53] <Colourless> unreal engine games use ini
[11:18:11] <wjp> ok, I finished the "configuration" setting
[11:18:15] <wjp> s/setting/section/
[11:18:18] <wjp> *sigh* :-)
[11:18:46] <wjp> I don't agree with the suggested config files and their roles
[11:19:08] <Colourless> you're suggestions?
[11:19:14] <Colourless> s/you're/your/
[11:19:17] <wjp> I would prefer if @home/pentagram.ini would override @data/pentagram.ini (and have the same root)
[11:19:34] <wjp> the idea being that @data/pentagram.ini might not be editable by the user
[11:19:54] <Colourless> ok
[11:20:27] <Colourless> that stuff doesn't really matter
[11:20:34] <Colourless> just my thoughts
[11:20:43] <Darke> 'Unfortunately', that's the only game I haven't had to fiddle with configuration files for. *grin* Though given the couple of DX:IW config files I just looked out, it really looks nothing like the .ini files I'm used to. *grin*
[11:21:55] * Darke seconds the @home overriding the @data. Nicer that way.
[11:23:13] * Darke resists suggesting we have user-configurable, config file types. *grin*
[11:26:18] <Colourless> overriding @data with @home makes sense. Just want to make sure certain settings are kept readonly
[11:27:24] <Colourless> this mostly matters for the he @data/game config files and if they can be overriden by @home/game versions
[11:27:30] * Darke ponders how a user would specify the configuration of a config file, without actually *using* a config file...
[11:27:36] <Colourless> i've got 2 @data/game files but you could do it with 1
[11:27:46] <Darke> Yup.
[11:29:04] <Colourless> there is a reason why i was thinking 2 game files was one of them might contain a whole heap of data that is totally unsuitable for the user to ovveride
[11:29:13] <wjp> I was wondering about sharing settings between various 'flavours' of u8
[11:29:27] <wjp> (u8english, u8german, u8french, ...)
[11:29:49] <Colourless> well, we could have a 'game base' config file that would be loaded by all
[11:30:15] <Darke> Some sort of include header?
[11:30:20] <Colourless> if we put things like gump layouts into config file (that would be widgit types and locations) then we may not want that stuff being saved in the user config file
[11:30:43] <wjp> hm, lunch; bbl
[11:36:37] <Colourless> an include header is one way
[11:37:40] <Colourless> or it could be in a separate config file. say @data/<gametype>/base.ini
[11:38:04] <Colourless> with extra config files being @data/<gametype>/<version_language>.ini
[11:38:11] <Colourless> or whatever
[11:38:29] <Colourless> s/base/common/
[11:45:36] <wjp> and back
[11:46:22] <wjp> not sure if a game is uniquely identified by <type,version,language>
[11:46:27] <wjp> (or should be)
[11:47:41] <wjp> (thinking along the lines of customized games, btw)
[11:49:39] <wjp> but that's probably something for later
[11:50:14] <Colourless> at least gametype is required
[11:50:27] <Colourless> version and language could be combined, if it is required
[11:50:42] <Colourless> they would become just a version
[11:51:01] <wjp> well, language is something I'd prefer to keep separate
[11:51:11] <Colourless> or, the game settings in say Pentagram.ini could actually just have listings for the config files to load
[11:51:31] <wjp> as long as they have sensible auto-detected defaults, that's fine by me
[11:56:40] <Colourless> game auto-detection is pretty much going to be mostly hardcoded into pentagram itself anyway
[11:57:08] <Colourless> all of the ultima8's at least seem to be fairly similar
[11:57:40] <Colourless> not sure about the crusaders, but i'm guessing no huge changes between versions either
[12:02:01] <Colourless> it's never going to something though that i think we could just put in a config file
[12:03:16] <Colourless> language is something that we need to consider. Should dialog box language be separate or linked to actual game language
[12:03:33] <Colourless> someone might have the english version of U8, but might want dialog boxes in another language
[12:08:44] <wjp> :-)
[12:08:57] <Colourless> usecode intrinsics are the 'problem' as far as crusader versions go. With u8 i don't think it would be an issue just using the same config files for all
[12:09:05] <wjp> I wouldn't make that impossible, but it should probably default to either english or the game language
[12:09:31] <wjp> are crusader intrinsics different between versions?
[12:09:39] <Colourless> looks like it
[12:10:12] <Colourless> haven't done any great look at it, but it seems like there was at least some reordering going on
[12:10:35] <wjp> hm, ah well
[12:11:09] <wjp> we'll probably just have a number of different intrinsic tables then
[12:11:26] <Colourless> intrinsic tables 'could' be written to text files
[12:11:53] <Colourless> need to look more at what is in the unkcoff.dat though. I noticed that for crusader a number of the intrinsics are listed multiple times
[12:12:45] <Colourless> they would be just the function names listed in the correct order
[12:13:12] <Colourless> now, if we do usecode conversion the table would purely be used to 'unlink' the intrinsics
[12:13:42] <Colourless> otherwise, Pentagarm would load that name table and would then generate the function pointer table
[12:16:41] * wjp is still not really happy with the whole conversion idea :-)
[12:17:23] <Colourless> at this stage, i don't care
[12:17:36] <Colourless> ask me another day, my opinion might be different
[12:18:01] <Colourless> the fact is, it probably isn't required. I modified shape loading so it wasn't
[12:18:07] <wjp> depends a bit on how integration of crusader turns out
[12:18:15] <Colourless> with audio it IS required though
[12:18:25] <wjp> yes, I agree about the audio
[12:18:30] * Colourless was forgetting about sonarc compression
[12:18:32] <wjp> and with compressed shapes too
[12:18:37] <Colourless> yes
[12:22:58] <wjp> what does the sonarc decompression require, btw?
[12:23:02] <wjp> original executable?
[12:23:12] <Colourless> yes\
[12:23:22] <wjp> does it accept any version of u8.exe?
[12:23:27] <Colourless> it should
[12:23:44] <wjp> does it look for a code signature or something?
[12:23:46] <Colourless> i've only tested 1.12, but in theory it should work with all
[12:23:49] <Colourless> yes
[12:24:01] <Colourless> looks for the copyright header
[12:24:11] * wjp nods; sounds ok
[12:24:12] <Colourless> which is directly after the code
[12:24:25] <wjp> how does crusader store its audio?
[12:24:38] <Colourless> uncompressed PCM
[12:24:43] <Colourless> with some headers
[12:24:51] <wjp> well, that sounds easy enough :-)
[12:25:26] <Colourless> haven't really looked at it too much
[12:25:48] <Colourless> crusader music of course isn't in a format we can directly play
[12:26:10] <Colourless> though i did commit code that would convert the amf files into mods
[12:26:38] <wjp> and mods are directly playable?
[12:26:49] <Colourless> by sdl mixer
[12:26:58] <wjp> good :-)
[12:30:09] <Colourless> not entirely sure how crusader handled it's music
[12:31:16] <Colourless> music was overrideable by entires in the .cfg file
[12:36:17] <Colourless> i have no idea if it was usecode controllable or not
[12:36:27] <wjp> one track per map?
[12:37:02] <Colourless> i don't know. I've never played it long enough with sound :-)
[12:37:18] <wjp> I never got past the first map in dosbox
[12:37:28] <wjp> it was a) slow b) suffering from stuck keys
[12:37:54] <wjp> (shooting is hard if you can't stop moving forward :-) )
[12:40:23] <Colourless> i'm sure it will be something that will figure out eventually
[12:40:37] * wjp pokes Darke
[12:40:41] <Colourless> s/will/we will/
[12:41:06] <Colourless> from the names of the filenames, it would appear one song per mission
[12:41:24] <Colourless> m01 through m16
[12:41:31] * Colourless is looking at regret
[12:41:39] <wjp> map = mission?
[12:41:50] <wjp> (or can missions span multiple maps?)
[12:41:56] <Colourless> however m16 has m16a, m16b and m16c
[12:42:05] <Colourless> map/mission same thing :-)
[12:42:13] <wjp> just checking :-)
[12:42:19] <Colourless> it 'might' be usecode controlled
[12:43:11] <Colourless> i have also noticed that the other files have their names listed in asylum.dll
[12:43:21] <wjp> ugh
[12:43:23] <Colourless> all of the files may have been accessed by an index
[12:44:49] <Colourless> s/asymlum.dll/regret.exe/
[12:46:02] <Colourless> so there 'might' be an intrinsic that can change the music, and the starting music for a map might still be egg controlled
[12:47:29] <Colourless> where it becomes 'fun' for pentagram is we would be wanting to support 2 different types of music. So this will either need to specify what type to play in the game config, or have some other way of determing the type
[12:48:00] <Colourless> I do not really want to support midi and mod music at the same time
[12:55:13] <wjp> I don't think that would be necessary :-)
[12:55:48] <wjp> either midi (for u8), mod (for crusader) or mp3/ogg (for either), I'd guess
[12:55:58] <Colourless> yeah
[12:57:21] * Darke delayedyips at the poke. Umm... music did change during the map, from memory, so I guess it would have been usecode controlled.
[12:59:53] <Colourless> well, it's something for 'another' time close to when Crusader isn't TGWDS anymore
[13:03:12] <Colourless> now what about comments on the rest of the email. Loopscripts in key bindings? yay or nay?
[13:07:33] * wjp hmms
[13:09:09] <Colourless> while it may initially seem a bit like overkill for loopscripts for a use command, they should allow for binding for specific fire spells
[13:09:46] <wjp> might as well
[13:10:03] <wjp> C syntax?
[13:10:49] <Colourless> i would guess as such. Though ideally, it should be consitant with whatever we would have in our own usecode compiler
[13:24:09] <Colourless> for things like using the spells, and spell scrolls we should probably setup Aliases for all of them ourselves
[13:24:32] <Colourless> and perhaps for potions too
[13:25:01] * wjp nods; won't hurt
[13:34:09] <-- Knight has left IRC (Read error: 104 (Connection reset by peer))
[13:40:43] <-- ragzter has left IRC (Remote closed the connection)
[13:50:02] <Colourless> I'm probably going to move console commands into the Console class rather than the ConsoleGump
[13:51:01] <Colourless> including "ConsoleGump.h" to add a console command will end up pulling in a huge heap of pentagram
[15:19:35] <Colourless> !!
[15:19:45] <wjp> yes?
[15:19:51] <Colourless> someone *cough*wjp*cough* used dynamic_cast!
[15:20:02] <wjp> I did?
[15:20:04] <Colourless> void BarkGump::NextText()
[15:20:05] <Colourless> {
[15:20:05] <Colourless> TextWidget *widget = dynamic_cast<TextWidget*>
[15:20:05] <Colourless> (GUIApp::get_instance()->getGump(textwidget));
[15:20:14] <wjp> yikes
[15:20:55] <Colourless> same in scroll gump too
[15:21:29] <wjp> fixed
[15:22:01] <wjp> I wonder how I managed to do that
[15:35:59] <-- Kirben has left IRC ("System Meltdown")
[15:48:19] <wjp> totally different thing: I was wondering if you should change our savegame system to look more like scummvm
[15:48:39] <wjp> instead of having manually written functions to do the saving and loading of each object,
[15:49:10] <wjp> ...give each class a list of things that need to be stored, and have a generic save/load function process that list
[15:49:44] <wjp> extra advantage would be that that list could be used for other things as well, such as dumping all info about an object to the console, or to SQL or something
[15:49:45] <Colourless> hmm... and then use offset to members?
[15:49:58] <wjp> depends on how exactly it's implemented
[15:50:14] <wjp> scummvm uses some macros which generate the offset, yes
[15:50:46] <Colourless> now you realize, it is technically abusing C pointers :-)
[15:51:04] <wjp> what a weird typo in that first line: s/you/we/
[15:51:24] <Colourless> since you cast 0 as the pointer to the class, and get a pointer to the member, and the cast that back to an int
[15:52:19] <Colourless> both systems have their advantages
[15:54:04] <Colourless> though i'm curious how exactly the scummvm system works with saving base classes
[15:54:18] <Colourless> do you have to explicitly tell it to save the base members too?
[15:59:06] <wjp> not sure
[15:59:12] <wjp> I actually don't even know if they have base classes
[15:59:46] <wjp> but if we do it, they should automatically handle base classes :-)
[16:00:30] <Colourless> not difficult to do
[16:01:00] <Colourless> i'm guessing they have an array that has a macro for the offset and then another value that specifies the type
[16:01:43] <Colourless> for a 'base' class you could make the offset a pointer to the base classes array, and make the value specify that it's a base class
[16:04:05] <Colourless> the one thing that the ScummVM way of doing things will be annoying with is special cases for certain classes
[16:04:29] <Colourless> for instances we would no longer be able to conditionally save certain values based on Item flags
[16:05:02] <Colourless> saving and 'idMan' object would become more difficult
[16:05:34] <Colourless> not impossible but your saving system would need to explicitly recognise the object as being an idMan
[16:12:36] <wjp> bbl
[17:03:44] <wjp> yes, we would lose flexibility
[17:03:56] <wjp> anyway, long-term plans :-)
[17:04:35] <wjp> the idea of exporting the world to SQL made me consider things like this a bit :-)
[17:04:52] <wjp> anyway, going home; bbl again
[17:27:50] <wjp> and back again :-)
[17:28:01] <Colourless> wb
[17:36:20] --> Dominus has joined #pentagram
[17:36:22] --- ChanServ gives channel operator status to Dominus
[17:59:52] --- Dominus is now known as Dominus|away
[18:06:29] * wjp is at 1/3rd of replying to the config email :-)
[18:17:48] <wjp> ...and sent it a few minutes ago
[18:18:00] <wjp> but the ML doesn't seem to be at its fastest today
[18:38:56] --- Dominus|away is now known as Dominus
[18:51:18] --> watt has joined #pentagram
[18:51:41] <watt> Hey all..
[18:51:47] <wjp> hi
[18:52:03] <Colourless> hi
[18:52:29] <Dominus> hi
[18:53:16] <watt> Colourless: I checked out you post on the mailing list (archives hehe)... I have to agree with you now.. you made quite a few valid points.
[18:55:36] <wjp> bbl, dinner
[18:56:35] <watt> And a thought on the args.. perhaps it would be best to have the args passed to the ConsoleFunctions as a list.... make the basic parsing occur in a single location, I mean.
[18:57:37] <Colourless> that isn't always useful though
[18:57:39] <watt> Quoted multiple word args would be nice.... :-)
[18:58:02] <Colourless> sometimes you do want just the args
[18:58:22] <Colourless> though might support both
[19:00:08] <watt> pass as both? (istring& args, std:list& arglist) ?? or separate methods?
[19:01:27] <Colourless> would have a vector :-)
[19:02:15] <Colourless> would probably have (std::vector<istring> argv, istring args)
[19:07:28] <watt> sounds good to me.
[19:18:28] <Colourless> wjp the "@data/somewhere/config.ini, @home/somewhere/config.ini" section is'nt making much sense
[19:19:33] <wjp> first part or second part?
[19:21:27] <wjp> They're what you called '@data/games/<game_type_ver_lang_path>/default.ini' and '@home/games/<game>/config.ini'
[19:22:05] * Dominus still didn't get the mail
[19:22:49] <wjp> neither did I, and I think Colourless didn't get it through the ML either
[19:23:11] <Dominus> ok
[19:25:23] <wjp> I didn't get my cvs mails from this afternoon either
[19:25:35] <wjp> (although I think those should just disappear entirely... *cough* :-) )
[19:25:48] <Dominus> ?
[19:26:00] * wjp doesn't want to talk about it ;-)
[19:26:02] <Colourless> The @data one should override the @home one.
[19:26:11] <Colourless> @data/pentagram.ini should
[19:26:14] <Colourless> be loaded read-only, and might in fact really be read-only to the user.
[19:26:31] <Colourless> shouldn't that be the @home one should override the @data one?
[19:26:41] <wjp> um, yes, it should
[19:26:55] <Colourless> and in that specific case you were not talking about Pentagram.cfg
[19:26:56] <wjp> oops :-)
[19:27:07] <wjp> blame it on copy-pasting :-)
[19:27:19] <Colourless> yes :-)
[19:28:20] <wjp> not sure what you should blame those swapped paths on, but I suggest Darke :-)
[19:29:31] <Colourless> :-)
[19:29:34] <Colourless> that damn bunny
[19:40:05] <Colourless> i've been reworking istring here. Changing it from using a different char_traits to instead be a subclass of basic_string. This allows conversions to and from std::string. At this stage it's not ready for committing since operator=() will return a std::string :-)
[19:40:46] <Colourless> any comparison using operators between a istring and a std::string will be case insensitive
[20:05:01] <-- Dominus has left IRC ("a pooka invited me for a drink")
[20:16:51] --> shinji-kun has joined #pentagram
[20:20:30] <Colourless> going
[20:20:32] <-- Colourless has left IRC ("casts invisibility")
[20:58:49] * Darke crawls out of bed and shifts blame back to wjp when he's not looking.
[21:28:33] <watt> Colourlesss: allowing istring to string conversion would be VERY nice... an ostream operator would help too.. the suggested versions I've always seen just convert to a string and output that.. I didn't like that idea much, hence no ostream op in the original istring
[21:43:43] <-- watt has left IRC ("using sirc version 2.211+KSIRC/1.3.9")