#gemrb@irc.freenode.net logs for 9 Jun 2010 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[02:03:29] --> budlust has joined #GemRb
[03:29:27] <-- budlust has left IRC (Ping timeout: 276 seconds)
[05:23:48] --> raevol has joined #GemRb
[05:35:46] --> budlust has joined #GemRb
[06:20:45] --- xrogaan_ is now known as xrogaan
[07:00:27] <-- raevol has left IRC (Quit: Leaving.)
[07:06:40] --> Maighstir|work has joined #GemRb
[07:44:15] <-- Gekz has left IRC (Read error: Connection reset by peer)
[07:44:22] --> lynxlynxlynx has joined #GemRb
[07:44:22] --- ChanServ gives channel operator status to lynxlynxlynx
[07:45:32] --> Gekz has joined #GemRb
[07:50:14] <edheldil> hello
[07:51:51] <-- Maighstir|work has left IRC (Quit: Page closed)
[07:58:32] <lynxlynxlynx> gmornin
[08:09:55] <-- Gekz has left IRC (Read error: Connection reset by peer)
[08:10:14] --> Gekz has joined #GemRb
[08:44:34] <-- |Cable| has left IRC (Remote host closed the connection)
[08:56:52] <-- Gekz has left IRC (Read error: Connection reset by peer)
[08:57:21] --> Gekz has joined #GemRb
[09:56:24] --> pupnik_ has joined #GemRb
[09:59:27] <-- pupnik has left IRC (Ping timeout: 240 seconds)
[10:12:33] <-- Gekz has left IRC (Read error: Connection reset by peer)
[10:12:54] --> Gekz has joined #GemRb
[11:58:07] <CIA-23> GemRB: 03lynxlupodian * r50718288b532 10gemrb/gemrb/override/bg2/spscorch.pro: spscorch.pro: set PSF_IGNORE_CENTER so the caster is immune
[13:14:03] --> Maighstir_laptop has joined #GemRb
[13:19:36] <Maighstir_laptop> What does the values in script.2da define?
[13:21:28] <edheldil> Maighstir_laptop: some details about BCS/BAF scripts
[13:21:46] <edheldil> i.e. objects in pst and in bg2 are different
[13:22:44] <Maighstir_laptop> Ah, so creating a new dataset, how would I determine how that file should look?
[13:23:13] <fuzzie> it represents what can be matched by a script
[13:23:36] <-- budlust has left IRC (Remote host closed the connection)
[13:23:49] --> budlust has joined #GemRb
[13:24:14] <fuzzie> eg, '[PC]' checks if the first field is a PC in the existing games, because the first field specified in script.2da is 'ea', which is where that's stored
[13:24:37] <fuzzie> so it depends what kind of fields you're going to want to match from your scripts :)
[13:27:29] <edheldil> also in depends on what game engine you want to be compatible with
[13:30:50] <-- budlust has left IRC (Ping timeout: 258 seconds)
[13:31:13] <tomprince> LLVM/Apple just released a new debugger yesterday :)
[13:31:16] --> budlust has joined #GemRb
[13:31:57] <Maighstir_laptop> Thanks fuzzie, edheldil... I'll have to mess around with it. There have been a load of changes between the move to git and me managing to compile it again, so my tiny dataset no longer runs (partially because of that file missing).
[13:34:02] <edheldil> is it anything you will want to share?
[13:34:49] <fuzzie> tomprince: they certainly needed one
[13:35:20] --> barra_library has joined #GemRb
[13:35:38] <wjp> cool
[13:35:46] <wjp> gdb definitely needs some competition
[13:35:50] <Maighstir_laptop> not anytime soon, barely beginning
[13:35:53] <fuzzie> it was getting pretty old having to run Apple's gdb in gdb itself to work out how Apple had broken it this time
[13:36:18] <fuzzie> although doesn't look like it's useful quite yet :)
[13:36:22] <-- budlust has left IRC (Ping timeout: 264 seconds)
[13:37:40] <Maighstir_laptop> that is, its not ready for sharing anytime soon
[13:37:47] <tomprince> No. But it seems to be improving at the same rate as the rest of llvm stuff.
[13:41:31] <wjp> llvm's klee sounds very interesting too
[13:44:24] <tomprince> Maighstir_laptop: If you have an indepdent data set, even if it does *nothing*, that would be useful. That would allow us to have some way of checking that gemrb at least starts.
[13:44:53] <fuzzie> you can do that with spectacularly little in the way of files :)
[13:46:26] <tomprince> I would guess about a dozen or so.
[13:46:57] <Maighstir_laptop> So far that's just what it does, and quits... a screen with 4 buttons, 3 of which do nothing, and one that quits the application... well, that's what it should do, when it starts at all. Progress is slow.
[13:47:19] <Maighstir_laptop> that's what it did back on svn code
[13:48:07] <Maighstir_laptop> if that's what you need, sure I can do that.
[13:48:33] <tomprince> Yes, that would be useful.
[13:49:25] <tomprince> Although I'd probably even have a version that just quits in the start script, so I can throw it at my builtbot.
[13:49:44] <lynxlynxlynx> test1 doesn't work anymore?
[13:54:35] <tomprince> I think some of the GUIScripts are broken. But in addtion to that, I think it still depends on having a regular dataset, for things like chitin.key, dialog.tlk, mpalette.bmp, cursors.bam, and probably others.
[13:57:00] <tomprince> I actually started to create an absolutely minimal dataset (using vi :)) but got busy with other stuff.
[13:59:11] <lynxlynxlynx> depends on what everything you want to test
[14:00:26] <tomprince> Well, the first step is gettin a dataset that can run Interface::Init to completion.
[14:01:44] <edheldil> I have (or had) that minimal dataset (before I added to it a bit)
[14:02:16] <edheldil> mine was based on pst
[14:03:24] <tomprince> My thought was for an indepedently created one, so that we could put it in tree.
[14:04:46] <edheldil> That's what I am talking about. I just did not get to replacing all the needed files (mainly FOGOWAR, CURSOR and some bitmap font)
[14:07:43] <tomprince> Well, for my initial purposes, I just need blank versions of those...
[14:08:27] <edheldil> at http://www.eowyn.cz/gemrb/testgame.lst is a list of files (sans the gemrb-specific ones, which were mostly copied from ps:t)
[14:09:20] <edheldil> files lifted from ps:t are in big caps, except of AR*.*, which I created myself
[14:10:26] <edheldil> but dltcep just can't preserve case :(
[14:20:38] <CIA-23> GemRB: 03lynxlupodian * r3cd7343321ea 10gemrb/gemrb/core/ (Actions.cpp Actor.cpp Interface.cpp Interface.h): added HasStringReference to simplify such checks
[14:23:45] <CIA-23> GemRB: 03lynxlupodian * r2d4964c64784 10gemrb/gemrb/plugins/AREImporter/AREImporter.cpp: missed one candidate for HasStringReference
[14:29:37] <-- barra_library has left IRC (Read error: Connection reset by peer)
[14:52:37] --> budlust has joined #GemRb
[14:53:50] <-- Gekz has left IRC (Changing host)
[14:53:50] --> Gekz has joined #GemRb
[14:57:24] <-- budlust has left IRC (Ping timeout: 252 seconds)
[15:12:42] <tomprince> http://hermes.hocat.ca:4010/builders/cmake%20clang%2B%2B/builds/62/steps/shell/logs/stdio
[15:24:52] <edheldil> is this your minimal dataset?
[15:26:45] <lynxlynxlynx> it's already committed
[15:30:08] <tomprince> Yes.
[15:36:55] <CIA-23> GemRB: 03lynxlupodian * rc0e4247b844a 10gemrb/NEWS: NEWS update
[15:37:17] <lynxlynxlynx> i guess cia doesn't like you :P
[15:39:02] <fuzzie> that gemrb.ini isn't minimal, is it?
[15:39:23] <tomprince> No, probably not.
[15:40:08] <fuzzie> ok. just wondering.
[15:40:40] <lynxlynxlynx> strmod.2da and similar shouldn't be needed either
[15:41:15] <tomprince> They are.
[15:41:37] <tomprince> At least, it won't start without them.
[15:41:37] <lynxlynxlynx> looks like only GetStrengthBonus depends on this one
[15:41:41] <fuzzie> i talked about this before
[15:42:16] <fuzzie> if you don't have the table, it will just read garbage
[15:42:49] <fuzzie> imo it should be fixed so it only malloc()s as-needed and then it can just check if the pointer is NULL and return zero bonuses etc
[15:43:58] <fuzzie> or ideally we shouldn't have D&D magic in the core at all :(
[15:49:30] <tomprince> That will be a major project.
[15:49:39] <Gekz> majorly major
[15:50:25] <fuzzie> well, as previously mumbled about, i think it might be an impossible project, too much magic scattered everywhere
[15:51:14] <fuzzie> scient said that PS:T just has hacks everywhere to tweak TNO's bonuses/etc, not looking forward to trying to make that work
[15:52:03] <fuzzie> although i think he has an IDA file for all that code, so at least the reversing shouldn't be too bad
[15:52:30] <tomprince> I think it isn't impossible.
[15:52:43] <fuzzie> well, it depends how far you go, i think
[15:53:09] <fuzzie> bonuses and things shouldn't be too hard imo, just call into python in a bunch of places in Actor.cpp etc, but there's D&D assumptions baked into effects, etc
[15:54:37] <tomprince> Well, there are things about spell immunities an resitance.
[15:54:40] <fuzzie> but i guess someone dedicated could think about moving more things into data files, etc.
[15:55:32] <tomprince> And I think it would be entirely reasonable to demand separate FX plugins.
[15:56:39] <tomprince> Although, perhaps a number of effects and actions could be turned into templates of some kind.
[15:56:57] <tomprince> I'm think of things that behave essentially the same, except that they key off different stats.
[15:57:25] <edheldil> but the stat names are hardwired now
[15:57:29] <fuzzie> those are, however, not the interesting ones :-)
[15:58:03] --> raevol has joined #GemRb
[15:58:19] <tomprince> No. But the ones that are D&D specific, are D&D specific ... :p
[15:58:22] <fuzzie> but the effects are still rather incomplete in a lot of cases, so that is a long-term thing
[15:58:52] <tomprince> 'course
[15:59:23] <fuzzie> but anything to bring down the line count is good, i guess :)
[16:02:58] <edheldil> what about moving the definition of skill consts (like STR, PICKPOCKET, etc) to a dnd specific header file, included by the relevant fx plugins?
[16:04:16] <lynxlynxlynx> that by itself would solve nothing
[16:04:16] <edheldil> so that you could replace it with another gamesystem-specific one
[16:04:50] <edheldil> it would be a step do deentangle dnd rules from gemrb
[16:06:22] <Gekz> random points in irc wont solve it
[16:06:31] <Gekz> what you need to do is audit the code for anything that needs to be moved
[16:06:36] <Gekz> then decide on it on a case by case basis
[16:06:36] <fuzzie> http://gemrb.sourceforge.net/wiki/doku.php?id=developers:fuzzie is my thoughts for July, while i am thinking
[16:06:42] <Gekz> and place it onto a master plan
[16:06:45] <Gekz> then attack it
[16:06:52] <fuzzie> although i imagine i might be beaten to some of that
[16:07:57] <Gekz> isnt random walk a random decision by the npc to move
[16:08:04] <Gekz> in a direction of random choosing
[16:08:06] <edheldil> that's the best I can muster my strength and time for :-P
[16:08:07] <fuzzie> nope
[16:08:10] <fuzzie> that would be nice
[16:08:27] <Gekz> there is nothing that controls npc movement like that?
[16:08:28] <Gekz> ok
[16:08:32] <fuzzie> but it's more a blocking action which moves occasionally in a very complicated direction involving centering around a point based on some magic algorithm
[16:08:53] <Gekz> lolk
[16:10:38] --> budlust has joined #GemRb
[16:11:51] <lynxlynxlynx> fuzzie: quite a list
[16:17:00] <-- raevol has left IRC (Quit: Leaving.)
[16:17:32] <lynxlynxlynx> what do you actors think? should we still do a release in a week or two or postpone it?
[16:18:00] <lynxlynxlynx> i'm in favour of the first, since i like the release early and often principle
[16:30:08] <-- budlust has left IRC (Ping timeout: 265 seconds)
[16:35:46] <lynxlynxlynx> tomprince: http://pastebin.com/GxxBRZFQ should be using Pos instead, right?
[16:35:49] <fuzzie> as a 0.6.1?
[16:36:01] <lynxlynxlynx> yes
[16:36:12] <fuzzie> that sounds fine
[16:37:14] <tomprince> Yes.
[16:49:08] --- Dark-Star|away is now known as Dark-Star
[17:49:35] <lynxlynxlynx> bleh
[17:52:04] --> budlust has joined #GemRb
[17:52:30] <CIA-23> GemRB: 03lynxlupodian * r8b048dfa7308 10gemrb/gemrb/GUIScripts/ (bg1/GUISAVE.py iwd/GUISAVE.py iwd2/GUISAVE.py): iwd, bg1: fixed save game overwriting
[17:57:28] <-- budlust has left IRC (Ping timeout: 276 seconds)
[18:24:27] --> |Cable| has joined #GemRb
[18:57:33] --> anji has joined #GemRb
[19:28:58] --> tomprince_loki has joined #GemRb
[19:33:10] --> cubathy has joined #GemRb
[19:49:55] --> budlust has joined #GemRb
[20:04:37] <tomprince_loki> This is my vague thought on a listbox design
[20:04:40] <tomprince_loki> http://pastebin.com/pE5F1ybM
[20:05:51] <tomprince_loki> Which depends on wiring up callbacks as true python objects.
[20:07:18] <lynxlynxlynx> row['Protraits']
[20:08:15] <lynxlynxlynx> nice hack with the lambdas
[20:08:58] <tomprince_loki> Just partial application ... :)
[20:12:27] <fuzzie> well, on the python side, clarity would be nice
[20:12:34] <fuzzie> not that the lambdas aren't clear
[20:12:42] <fuzzie> just automatic reaction to 'nice hack' :)
[20:13:33] <fuzzie> but e.g. i wouldn't want to see the map() in code likely to be modded
[20:14:40] <fuzzie> but i guess you don't really provide enough code there to tell
[20:15:14] <fuzzie> e.g. are you just planning to sabotage VarAssoc entirely?
[20:16:47] <tomprince_loki> I think that most uses could be done away with eventually, probably.
[20:17:05] <tomprince_loki> I wasn't going to touch it at this point.
[20:17:32] <fuzzie> well, the SetEvent() doesn't work unless you change the behaviour in some way there
[20:18:13] <tomprince_loki> For the scrollbar? Yes.
[20:18:51] <fuzzie> oh, i just realised ypu
[20:18:58] <fuzzie> you're passing *whole SaveGame objects* back to python
[20:19:13] <tomprince_loki> Yes.
[20:19:15] <fuzzie> that is not really very nice
[20:19:48] <tomprince_loki> Why not?
[20:19:53] <fuzzie> it's slower
[20:19:56] <fuzzie> i'd been wondering why
[20:20:20] <fuzzie> well, maybe this isn't the culprit
[20:20:36] <fuzzie> opening the save screen has become a lot slower for me recently
[20:20:50] <fuzzie> but the old code must surely have been stat()ing too
[20:21:11] <fuzzie> do you know if you added anything which isn't in the old code?
[20:22:23] <tomprince_loki> It is reading the game date of all the games. That might do it.
[20:24:37] <fuzzie> ok. let me poke rthrough blame before i say more stupid things.
[20:25:23] <tomprince_loki> Does this help : http://pastebin.com/77VVx8sp
[20:27:37] <fuzzie> just commenting it out entirely helps, so i expect so
[20:29:17] <fuzzie> that ParseGameDate function is, well, um
[20:29:43] <tomprince_loki> Yes :)
[20:29:54] <fuzzie> as usual, i have no words
[20:30:49] <fuzzie> that seems to work, thankyou
[20:31:12] <tomprince_loki> Well, don't look at me *grin* I just copied it from GUIScripts.
[20:31:51] <fuzzie> i would never think that you would be responsible for such code :-)
[20:32:16] <fuzzie> the listbox design seems clever, btw
[20:33:25] <fuzzie> although i wonder if it would be neater to use an object rather than a dict?
[20:34:14] <tomprince_loki> Maybe.
[20:34:55] <tomprince_loki> I thought about that, but am not sure. Certainly the code that uses it will be nicer.
[20:35:14] <fuzzie> well, i'm only looking at the specific case you presented here
[20:36:04] <fuzzie> also i guess replace the range(PARTY_SIZE) with iteration, but that is a nitpick..
[20:36:24] <fuzzie> i'm sure it'll be much nicer than what we have now in any case
[20:36:41] <tomprince_loki> On the other hand, there should only ever be one place that creates an object/dict of the given type.
[20:39:12] <fuzzie> just thinking of more obvious things, i guess you want a manual refresh() on there too, to cope with changes?
[20:39:48] <fuzzie> i mean, i am not being coherent
[20:40:25] <fuzzie> i will shut up and see :)
[20:41:43] <tomprince_loki> A manual refresh?
[20:41:58] <fuzzie> i mean, the refresh() is 'public API', right?
[20:42:40] <fuzzie> so that the listbox can be updated to cope with e.g. new spells being picked, and buttons needing to be enabled/disabled
[20:43:05] <fuzzie> so you can see why i shut up, because the answer is surely 'well, yes, obviously' :)
[20:43:29] <fuzzie> it's just not called in the constructor in your prototype, which confused me
[20:44:28] <tomprince_loki> That is simply because I haven't wired up the C++ side to take python callbacks, so I haven't actually run the code. :)
[20:44:41] <fuzzie> sure, there is an obvious typo too :P
[20:44:49] <fuzzie> i appreciate seeing the prototype
[20:45:37] <fuzzie> if you would like another challenge after you are done with your long long list, CloseOtherWindow is the bane of my existance
[20:46:01] <tomprince_loki> GetGameDate is const -> add mutable to GameDate?
[20:46:04] <fuzzie> and it doesn't even work properly
[20:47:14] <fuzzie> i just removed the const :) but that would make sense
[20:47:28] <fuzzie> it doesn't modify it, just one-time generation
[20:49:28] <tomprince_loki> Or many times, if it fails :(
[20:50:12] <fuzzie> i was going to say that your code looks sane enough that it would only be called once in a typical case
[20:50:22] <fuzzie> but of course actually it is not so ideal
[20:50:29] <tomprince_loki> Or should we have a default value, if it fails to parse?
[20:50:43] <tomprince_loki> Even just " " would work.
[20:50:54] <fuzzie> well, to me, "ERROR" would make the most sense
[20:51:21] <fuzzie> but you can probably see that i am the kind of coder who puts assert() everywhere, i want to know when things fail :)
[20:51:29] <fuzzie> if it would make more sense to suppress the failure, " " seems fine
[20:53:12] <tomprince_loki> I went with ERROR.
[20:54:26] <CIA-23> GemRB: 03tom.prince * r79c538a4539c 10gemrb/gemrb/core/ (SaveGameIterator.cpp SaveGameIterator.h):
[20:54:26] <CIA-23> GemRB: SaveGame: Only parse game date on request.
[20:54:26] <CIA-23> GemRB: This fixes a slow down reported by fuzzie.
[20:54:26] <CIA-23> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[20:54:33] <fuzzie> ^.^
[20:54:35] <fuzzie> thanks again
[20:54:52] <tomprince_loki> No problem.
[20:55:35] <tomprince_loki> I do most of my dev on fairly new tirple core, so I am unlikely to run into performance problems often.
[20:58:04] <lynxlynxlynx> i'm on an old athlon and i didn't notice the slowdown >>
[20:58:45] <fuzzie> i have spent the last 6 months on a 1.6ghz atom
[20:59:01] <fuzzie> it is amazingly, amazingly slow
[21:00:10] <fuzzie> but it is also spectacularly convenient, especially since sometimes i can't carry very much
[21:00:35] <fuzzie> but i'm sure you all heard the theories about how developers should be forced to use ancient machines :)
[21:00:47] <tomprince_loki> Yes, my laptop is an atom.
[21:01:13] <fuzzie> am very grateful that distcc exists, though.
[21:01:31] <tomprince_loki> Which is why I will often ssh in to my desktop to do development, cause the compile time is too high for me. :)
[21:02:54] <fuzzie> yes, i would not wish atom compile times on anyone :)
[21:04:32] <tomprince_loki> And 160G is nowhere near enough space....
[21:04:35] * tomprince_loki *grins*
[21:05:12] <lynxlynxlynx> my hz are almost the same, but it's not a good comparison with different arches in play
[21:05:17] <fuzzie> ah, well, we have a shared disk here :)
[21:06:05] <fuzzie> a 1.6ghz 32-bit Sempron is depressingly faster
[21:06:15] <fuzzie> i don't know how that compares to an older Athlon though
[21:06:54] <fuzzie> i think actually, the gemrb game data is taking up more space on this laptop disk than anything else
[21:07:44] <lynxlynxlynx> especially when you have some extra installs for playing
[21:08:10] <fuzzie> this is why my wishes about modding being a bit less invasive
[21:09:30] <lynxlynxlynx> we can improve this easier in gemrb
[21:09:41] <tomprince_loki> So what should we use as a path seperator?
[21:09:58] <fuzzie> isn't it required to be platform-specific?
[21:10:08] <fuzzie> or do i misunderstand?
[21:10:12] <tomprince_loki> : for unix, ; for win32?
[21:10:29] <fuzzie> oh, for lists :) that seems standard, i think?
[21:10:52] <tomprince_loki> So platform specific then?
[21:10:58] <tomprince_loki> And yes, it does seem standard.
[21:15:14] <Lightkey> +1
[21:15:49] <Lightkey> 900 MHz MIPS is not cutting it, either :-(
[21:18:15] <Lightkey> especially considering the abysmal running time of under two hours
[21:30:26] <tomprince_loki> http://hermes.hocat.ca:4010/builders/cmake%20g%2B%2B-4.4.3%20incremental/builds/29/steps/git/logs/patch ?
[21:36:01] <-- cubathy has left IRC (Ping timeout: 264 seconds)
[21:36:34] <-- budlust has left IRC (Remote host closed the connection)
[21:36:54] --> budlust has joined #GemRb
[21:38:01] <tomprince_loki> Also, I'd like to go through and sort all the header includes.
[21:38:29] --- Dark-Star is now known as Dark-Star|away
[21:40:37] <lynxlynxlynx> expecting someone to object? ;)
[21:41:22] <tomprince_loki> Not really.
[21:42:18] <tomprince_loki> The order I was thinking, FooBar.h (for FooBar.cpp), include files from plugin, include files from includes, include files from core, each sorted in ascii order.
[21:42:50] <tomprince_loki> Followed by system includes.
[21:43:32] <-- budlust has left IRC (Ping timeout: 245 seconds)
[21:43:35] <lynxlynxlynx> the displaytext is a good candidate to move into another file - some places have to include core just for these
[21:43:49] <lynxlynxlynx> *displaytext bunch
[22:06:15] --> budlust has joined #GemRb
[22:15:02] <fuzzie> yes, no objections on either of those
[22:19:27] <-- tomprince_loki has left IRC (Ping timeout: 258 seconds)
[22:22:01] <-- budlust has left IRC (Ping timeout: 276 seconds)
[22:42:45] <lynxlynxlynx> 3 files changed, 0 insertions(+), 1132 deletions(-) :D
[22:42:57] <-- anji has left IRC (Quit: ZNC)
[22:47:51] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:51:27] --> anji has joined #GemRb
[23:06:52] <tomprince> :)
[23:14:53] <-- Maighstir_laptop has left #GemRb