#gemrb@irc.freenode.net logs for 23 Mar 2010 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:11:00] <-- Enverex has left IRC (Remote host closed the connection)
[00:15:02] --> ratpor has joined #GemRb
[00:22:43] <-- Maighstir_laptop has left IRC (Quit: Maighstir_laptop)
[00:29:31] --> _pickle has joined #GemRb
[01:57:45] <-- _pickle has left IRC (Remote host closed the connection)
[03:06:16] --> raevol has joined #GemRb
[03:55:51] --> Gekz_ has joined #GemRb
[04:18:37] <-- Gekz_ has left IRC (Quit: This computer has gone to sleep)
[05:29:16] <-- ratpor has left IRC (Quit: Get used to disappointment.)
[05:41:31] <-- raevol has left IRC (Quit: Leaving.)
[05:50:48] --> Gekz_ has joined #GemRb
[05:57:16] <Genraznx> hello Gekz
[05:57:20] <Genraznx> are you a master lurker?
[05:57:22] <Genraznx> or a noob lurker
[05:59:06] <Gekz_> I've been here longer than you
[05:59:08] <Gekz_> lol
[05:59:12] <Gekz_> and I dont lurk
[05:59:15] <Gekz_> I distract
[06:40:49] --> Brendan__ has joined #GemRb
[06:40:55] <-- Gekz has left IRC (Read error: Connection reset by peer)
[06:51:53] --> Gekz has joined #GemRb
[06:52:04] <-- Brendan__ has left IRC (Read error: Connection reset by peer)
[06:55:32] <-- Gekz_ has left IRC (Quit: This computer has gone to sleep)
[07:21:00] <Genraznx> curious how intact is the AI scripting in GemRB?
[07:21:00] --> Nomad010 has joined #GemRb
[07:23:10] <Genraznx> Hi
[08:27:18] <Edheldil> Lightkey: Cowardly I am not. Pray state your intent, sir
[08:32:14] <Genraznx> Ed how intact is the ai scripting and stuff
[08:32:21] <Genraznx> and how hard would it be to input new spells and such?
[08:38:22] <-- Nomad010 has left IRC (Ping timeout: 265 seconds)
[08:46:56] <Edheldil> what do you mean with "intact" ?
[08:47:08] <Genraznx> Im not too sure myself I suppose
[08:47:16] <Genraznx> but scripting AI and such wouldnt be hard?
[08:47:21] <Genraznx> or is it just the same as in the original games
[08:50:41] --> Gekz_ has joined #GemRb
[08:50:41] <-- Gekz has left IRC (Read error: Connection reset by peer)
[09:01:01] <Edheldil> it's the same
[09:01:18] <Edheldil> but you might extend spell effects with a plugin
[09:01:42] --> lynxlynxlynx has joined #GemRb
[09:01:42] --- ChanServ gives channel operator status to lynxlynxlynx
[09:01:56] <Genraznx> I see
[09:02:03] <Genraznx> How is this for a idea
[09:02:06] <Genraznx> Cult of the Bovine
[09:02:14] <Genraznx> People who dress up a cow and worship it
[09:02:23] <Genraznx> and allowed to interact with said cow
[09:02:27] <Genraznx> and all it will saw is moo
[09:02:37] <Genraznx> If you attempt to try and kill said cow it will rape you with magic
[09:02:51] <Genraznx> "In the divine words of our lods. 'moo'"
[09:03:01] <Genraznx> lord rather
[09:06:28] <Edheldil> do as you wish :)
[09:07:56] <Genraznx> But yeah
[09:08:03] <Genraznx> I think I got the plot more narrowed
[09:08:05] <Genraznx> which is good
[09:33:11] <-- Gekz_ has left IRC (Read error: No route to host)
[09:33:40] --> Gekz_ has joined #GemRb
[09:43:03] --> barra_library has joined #GemRb
[09:51:16] <Edheldil> does anybody have (E)BNF grammar for BAF (uncompiled BCS) files ?
[09:51:18] <-- |Cable| has left IRC (Remote host closed the connection)
[09:51:45] <Edheldil> or any formal definition of the language
[09:53:35] <lynxlynxlynx> i think the weidu compiler is not complete, but the dltcep one works, so you can check there
[09:53:51] <lynxlynxlynx> it won't be a formal definition though
[09:54:50] <Edheldil> dltcep one works a bit strange, I have problems make it do what I need, but maybe it improved
[09:55:15] <Edheldil> but I would MUCH prefer formal definition than sources
[09:55:52] <Edheldil> I wioll probably write one and post it to g3 for comments
[09:59:17] <lynxlynxlynx> hmm, or was it the other way round
[10:01:18] <Edheldil> ?
[10:01:50] <lynxlynxlynx> weidu good, dltcep bad
[10:01:55] <Edheldil> I do not know weidu
[10:02:08] <Edheldil> I was always scared by ocaml
[10:02:43] <Edheldil> or lazy to install it, since I do not like or use mods much
[10:04:04] <lynxlynxlynx> you don't need to install it
[10:04:23] <lynxlynxlynx> either it's a compiled language or the interpreter is small and bundled
[10:04:36] <Edheldil> I would need to install ocaml to tinker with weidu
[10:05:09] <Edheldil> but maybe it would be easy to glean the grammar from sources
[10:05:21] <fuzzie> compiling weidu is fairly difficult anyway, in my experience :/
[10:45:32] --> kettuz has joined #GemRb
[11:46:36] <Lightkey> Edheldil: Pray? :-P
[11:49:59] <-- barra_library has left IRC (Read error: Connection reset by peer)
[11:51:03] <Lightkey> Edheldil: anyway, have you ever played Dračí Historie? ScummVM is in need of a tester before 1.1.0 gets released
[11:51:15] <Lightkey> (this week)
[11:51:25] <Lightkey> gtg, sorry
[11:57:39] <Edheldil> Lightkey: never, as far as I can remember, but I could try
[12:00:48] --> Gekz has joined #GemRb
[12:00:55] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[13:13:42] <-- kettuz has left IRC (Quit: Leaving)
[13:31:10] <tomprince> Genraznx: Right now, GemRB only supports the original scripting language. But there is nothing preventing another from being added. In the long run, it would probably be a good thing, since it would decrease the coupling between the original scripting language and the rest of the system.
[13:34:01] <fuzzie> tomprince: oh, hi. are the build system changes in your patches necessary?
[13:34:51] <tomprince> Depends on what you mean be necessary.
[13:35:33] <fuzzie> most specifically i was looking at the LT_INIT, but was also wondering if the rest could go in a seperate commit.
[13:39:17] <tomprince> There needs to be at least some change to the build, since alot of files get removed. (You are talking about the first commit?)
[13:39:41] <fuzzie> yes, sorry.
[13:41:22] <tomprince> It has been awhile since I looked at any of the code. But I don't think any of the rest is necessary.
[13:44:28] --> Nomad010 has joined #GemRb
[13:44:41] <fuzzie> I honestly don't understand the autoconf magic, and so am a bit nervous about making too many changes at once when none of the people building it on odd platforms have been around for a while.
[13:45:45] <tomprince> Well, the metasources is qt specific, so useless.
[13:47:22] <tomprince> I beleive all_includes is empty.
[13:47:25] <fuzzie> but, for example, the FXOpcodes file has '-sahred' as a flag, so I wonder if that doesn't build or whether the flag is unnecessary :)
[13:47:37] <wjp> what was the link to that git repo again?
[13:47:51] <fuzzie> wjp: http://repo.or.cz/w/gemrb.git
[13:48:24] <wjp> 85df0bf30eaefede61fbc281ab62dca78cda665c ?
[13:49:12] <wjp> ah, you actually meant '-sahred' including the typo :-)
[13:49:15] <fuzzie> my thought is to apply first the doxygen change (harmless), then everything except the build system changes, then prod people like Avenger to make sure it still builds.
[13:50:03] <fuzzie> and then the "The Great Rename" commit on top of that.
[13:50:05] <tomprince> Well, we need shared libraries, since we dlopen all the modules.
[13:50:17] <wjp> -module might already take care of that though
[13:50:24] <wjp> "Creates a library that can be dlopened"
[13:50:29] <fuzzie> but it's not quite so trivial, because the patches in tomprince's repository don't update cmake, and the VC++ files will need fixing up too.
[13:51:09] <fuzzie> and then after that, the build system changes, and then apply 'The Great Rename', again with all the cmake/VC++ changes required.
[13:51:42] <fuzzie> and then the same for most of the rest, i guess.
[13:52:12] <tomprince> Probably, except that libtool has some sort of support for linking in modules statically, and the using it libltdl library to simulate dlopen.
[13:52:29] <fuzzie> i didn't actually try building this stuff, it failed for me at LT_INIT, so i thought i'd ask.
[13:52:50] <wjp> no LT_INIT here either
[13:53:08] <wjp> (centos 5.4)
[13:53:33] <tomprince> Well, i only have the docs for the most libtool 2.2.6b, so that is what I was basing my changes on.
[13:53:36] <fuzzie> it's new in libtool 2.2.6, i think, absent in a lot of embedded stuff too.
[13:54:11] <tomprince> The LDFLAGS changes are from http://www.flameeyes.eu/autotools-mythbuster/libtool/index.html#libtool.plugins.dlopen
[13:54:29] <fuzzie> aha :)
[13:54:44] <fuzzie> the changes certainly make a lot of sense!
[13:55:01] <wjp> fuzzie: did you try without that configure.ac LT_INIT hunk?
[13:55:02] <fuzzie> and while you're removing all this junk from the plugin system, it makes perfect sense to fix the rest.
[13:55:06] <Genraznx> Curious how hard would it be to add in new spell effects and the like?
[13:55:27] <fuzzie> wjp: not yet, because at that point I got nervous about my lack of a Windows machine to test the rest of the build changes with.
[13:55:49] <wjp> I should try when I get back home
[13:55:55] <tomprince> AC_PROG_LIBTOOL would be needed without LT_INIT
[13:56:18] <fuzzie> hence my thought that splitting it into a "change the code, remove files in automake+cmake files" commit and then a "fix up automake" commit might be a cleverer idea.
[13:56:19] <wjp> currently there are AC_LIBTOOL_DLOPEN and AC_PROG_LIBTOOL
[13:56:32] <fuzzie> i would be grateful for someone testing it :)
[13:56:59] <fuzzie> i feel terrible having such large amounts of work sitting unmerged, even if there's not exactly any work in the gemrb tree recently
[13:57:32] <tomprince> Don't need AC_LIBTOOL_DLOPEN, since we assume that a posix system has dlopen, and we don't use any of the libtool wrappers for it.
[13:58:07] <fuzzie> Not required on Windows?
[13:58:15] <fuzzie> Genraznx: I think it depends what kind of spell effects.
[13:58:25] <tomprince> Note: I don't really have much experience with autoconf stuff, but have been teaching my self as I go.
[13:59:06] <fuzzie> gemrb tries hard to make all the spells and effects and animations easily modifiable..
[13:59:18] <fuzzie> but for a few things it might be necessary for someone to change the code.
[13:59:26] <tomprince> No, windows use LoadLibrary instead of dlopen: see core/PluginMgr.cpp
[14:00:12] <tomprince> Genraznx, have a look at the Opcode plugins probably, for spell effects.
[14:00:40] <fuzzie> while I'm thinking, changing RTLD_GLOBAL to RTLD_LOCAL works fine? the comment makes me nervous :)
[14:01:14] <fuzzie> (and should be removed if it's really not necessary any more)
[14:01:30] <wjp> yes, that comment together with the new code is really confusing :-)
[14:03:34] <wjp> This was the relevant report, by the way:
[14:03:42] <wjp> 18:04 < Fyorl> I'm getting this traceback:
[14:03:42] <wjp> 18:05 < Fyorl> [GUIScript]: Loading Script GUICG7...Traceback (most recent call last):
[14:03:46] <wjp> 18:05 < Fyorl> File "/usr/local/share/gemrb/GUIScripts/tob/GUICG7.py", line 22, in ?
[14:03:49] <wjp> 18:05 < Fyorl> import GemRB, math
[14:03:51] <wjp> 18:05 < Fyorl> ImportError: /usr/lib/python2.4/lib-dynload/mathmodule.so: undefined symbol: PyExc_OverflowError
[14:05:05] <wjp> if I read that right it was triggered by an 'import math' in a GUIScript
[14:05:11] <fuzzie> yes
[14:05:22] <fuzzie> we're all probably using python with the math module built-in
[14:07:14] <tomprince> Mine seems not to be.
[14:07:43] <fuzzie> so worth testing, at least. could remove the use of the math module entirely, but might trip us up elsewhere.
[14:07:55] <tomprince> I seem to recalling look to find out if RTLD_LOCAL applies recursively, but I can't recall what I found.
[14:08:09] <wjp> RTLD_LOCAL is a default setting, by the way
[14:08:23] <fuzzie> wjp: making it explicit is no bad thing, though.
[14:08:28] <wjp> true
[14:08:42] <wjp> but the recursiveness is automatic as it's the default
[14:09:03] <tomprince> The reason I left the comment, is because it didn't fail for me, but I wasn't sure if it was an issue on a different platform.
[14:09:21] <fuzzie> but anyway, an 'import unicodedata' (for example) from the console should show if it fails or not.
[14:09:31] <tomprince> the recursiveness of the open, or the recursiveness of RTLD_LOCAL being applied to shared libraries.
[14:10:21] <tomprince> The reason I switched to RTLD_LOCAL, is that for our purposes, the libraries only export three functions, all the same, and we only grab them via dlsym.
[14:13:08] <wjp> right, but the issue is with symbols exported by dependencies I believe
[14:14:36] <lynxlynxlynx> btw, i don't think it would be hard to fix up cmake, most of it uses globbing to find files
[14:14:50] <lynxlynxlynx> i can handle this later
[14:14:57] <tomprince> Exactly. I don't know if RTLD_LOCAL applies to dependencies. I vaguely recalling reading that it doesn't.
[14:15:06] <tomprince> Do people use cmake?
[14:15:12] <fuzzie> "warning: remote HEAD refers to nonexistent ref, unable to checkout." is not the friendliest result of a clone :)
[14:15:34] <fuzzie> took me 30 seconds to re-work out the "git checkout origin/plugins" thing.
[14:15:45] <fuzzie> and, yes, people use cmake.
[14:15:50] <wjp> RTLD_LOCAL is the default. The question is if RTLD_GLOBAL applies recursively. (And I'm fairly sure the fact that it fixed things implies that it is recursive)
[14:16:19] <tomprince> It doesn't make sense to have two build systems.
[14:16:38] <tomprince> I don't really have a preference, other than the fact that I have been using autoconf.
[14:16:47] <fuzzie> I think the problem is that no-one was maintaining the autoconf system.
[14:17:16] <lynxlynxlynx> it was easier to build mac and win packages with cmake
[14:17:38] <fuzzie> I think it's possible to make the autoconf stuff work on Windows, but it completely fails on OS X.
[14:18:00] <tomprince> I think I have got autoconf to work on mingw anyway.
[14:18:04] <fuzzie> I don't know if you can make useful OS X builds at all with autoconf. I have not managed it for other projects.
[14:18:25] <tomprince> It is probably possible to make autoconf work on OS X, it is BSD underneath, afterall.
[14:18:41] * wjp thought we actually had 3 or 4 build systems :-) (MSVC)
[14:18:59] <tomprince> I don't have access to a machine to test on, but if someone had one and was willing to debug, I would be willing to fix it for OSX.
[14:19:11] <fuzzie> I think you can make it work for a specific OS X system, but it links directly against libraries, so the resulting binary is not very helpful.
[14:19:11] <tomprince> Well, MSVC is maintained in a seprate repo.
[14:20:17] <fuzzie> But to be fair, my other attempts at building things for OS X have depended on varied boost libraries, it might be simpler given we're not depending on anything 'alien'.
[14:24:29] <tomprince> posix specifies that the default of RTLD_* is unspecified.
[14:25:26] <wjp> ah
[14:25:32] <tomprince> Anyway, I need to go. I'll be back later.
[14:26:23] <tomprince> And I read the logs, so you can just leave a question here for me.
[14:26:26] <fuzzie> thanks again!
[14:26:33] <tomprince> No problem.
[14:26:53] <fuzzie> my kingdom for an automatic run of 'plugins-prepare.sh', too.
[14:27:10] <fuzzie> Oh, that doesn't work in tomprince's tree, it seems.
[14:27:18] <fuzzie> better fix that.
[14:27:33] <tomprince> I never tested that, I just install every time. :)
[14:27:46] <fuzzie> just needs lib*.so changed to *.so in the script :)
[14:28:19] <fuzzie> I can certainly import python modules with that RTLD_LOCAL change and python 2.6.
[14:29:18] <Edheldil> I will have to try that repo, I am certainly for simplyfying plugin interface
[14:29:42] <fuzzie> Ah, it breaks.
[14:29:48] <fuzzie> ImportError: /usr/lib/python2.6/lib-dynload/bz2.so: undefined symbol: PyExc_ValueError
[14:30:37] <fuzzie> perhaps should add a reproduction recipe to the comment :)
[14:31:10] <fuzzie> Edheldil: it is very simplified, definitely worth merging imo.
[14:31:48] <fuzzie> http://repo.or.cz/w/gemrb.git/commitdiff/85df0bf30eaefede61fbc281ab62dca78cda665c is the big change, you can see how a lot of boilerplate just disappears.
[14:34:24] <Edheldil> yeah, I looked already, although I did not try to understand plugindef.h yet
[14:34:37] <Edheldil> how one clones the repo? error: File 0000000000000000000000000000000000000000 (http://repo.or.cz/w/gemrb.git/objects/00/00000000000000000000000000000000000000) corrupt
[14:34:41] <fuzzie> but given my discoveries so far, i would like to commit it bit by bit :-)
[14:35:06] <fuzzie> the clone url is on the front page; try git://repo.or.cz/gemrb.git
[14:35:06] <lynxlynxlynx> wjp: the cmake has a msvc generator. Not sure how good that is though
[14:35:29] <fuzzie> (and then "git checkout origin/plugins" once it's cloned)
[14:36:58] <Edheldil> thx
[14:37:18] <fuzzie> i would of course be delighted if someone else would like to test/merge it all :)
[14:39:04] <Edheldil> hehe
[14:39:30] <Edheldil> missing master is a bit unintuitive
[14:41:59] <fuzzie> it seems that oldest commit should be fairly harmless without the build changes and the RTLD_LOCAL change, although i am not sure about the other changes to the plugin loader (does it handle duplicates correctly?), nor if it will work on Windows, nor about GetFile.
[14:47:02] <Edheldil> what other changes? I did not get it
[14:47:37] <fuzzie> I guess you could probably move the GetFile changes to another commit..
[14:48:32] <Edheldil> where's GetFile change?
[14:49:16] <fuzzie> search for it in the webpage with the diff? it is a new function, but it is not used by anything in that commit.
[14:50:36] <fuzzie> by 'the other changes' I mean the PluginMgr changes. i don't see what happens when you have two plugins for a single function.
[14:52:11] <fuzzie> I suppose the 'Register' function returns false in that case. It would be nice for the output to make that clearer.
[14:52:37] <fuzzie> Those are my thoughts, anyway. I look only at 85df0bf30eaefede61fbc281ab62dca78cda665c.
[14:54:54] --> tomprince_loki has joined #GemRb
[14:56:07] <fuzzie> The sound driver fails for me if I build the tree as-is, but that's just the library rename, I guess.
[14:57:47] <fuzzie> And now I have to go back to working, bbiab.
[14:59:35] <-- tomprince_loki has left IRC (Quit: tomprince_loki)
[15:00:08] --> tomprince_loki has joined #GemRb
[15:02:07] <tomprince_loki> I thought I had moved the GetFile change. I guess not.
[15:02:39] <Edheldil> segfaults for me with my TC game unlike the version I develop with, but I have to check what is the status after I update from SVN
[15:05:07] <tomprince_loki> Do you know where it is segfaulting?
[15:07:38] <tomprince_loki> One thing that my cause the segfault is missing modules. There isn't a whole lot of checking to make sure that the modules gemrb expects to be loaded actually are. And with the rename of all the modules, it will segfault if it tries to use it.
[15:07:54] <tomprince_loki> That should be fixed at somepoint, but the original worked that way as well.
[15:14:37] <tomprince_loki> fuzzie: I wasn't particulary good at keeping logging output up to date.
[15:19:34] <Edheldil> [KEYImporter]: Searching for startpos.2da...[Override]
[15:19:34] <Edheldil> Program received signal SIGSEGV, Segmentation fault.
[15:19:34] <Edheldil> 0x001adb58 in Game::InitActorPos (this=0x82b87c8, actor=0x8329748) at Game.cpp:342
[15:19:34] <Edheldil> 342 const char *xpos = start->QueryField(mode[playmode],"XPOS");
[15:19:48] <Edheldil> but I guess I am missing some file
[15:20:55] <Edheldil> it crashes in SVN too, so it's not your patch related
[15:23:18] <tomprince_loki> That is commit r743[56]. You need the file start.2da.
[15:23:30] <tomprince_loki> Which is from a patch of mine that got applied.
[15:23:53] <tomprince_loki> http://repo.or.cz/w/gemrb.git/commit/f342e4cbf7fcec1a5d47bd3ec0c23e04c0b3401d and its parent.
[15:25:37] <tomprince_loki> It is a layer of indirection for startpos.2da, to avoid hardcoding of knowledge of what row/column to look for.
[15:35:23] <fuzzie> need to add an error check, i guess.
[15:46:46] <tomprince_loki> There are quite a few places where we need are checks like that.
[15:46:56] <fuzzie> i have a todo list with "check for missing 2da files" on it.
[15:47:09] <tomprince_loki> :)
[15:47:17] <fuzzie> but whenever I sit down to look at gemrb code, it seems a bit silly to make fixes when all your code is still not merged.
[15:47:17] <Edheldil> yes, that would definitely help
[15:49:07] <Edheldil> ok, start.2da helped, thanks
[15:49:16] <tomprince_loki> I didn't mean to stall development because of a large code drop.
[15:49:36] <Edheldil> I am really looking forward the plugin changes, hehe
[15:51:37] <tomprince_loki> I haven't changed most of the plugins to use the new resource stuff. It isn't that hard to do. Mostly I haven't since there is only one plugin of each of the other types.
[15:52:25] <tomprince_loki> If someone is making a game directly for GemRB, it would probably make sense to make some more stuff go through there.
[15:52:50] <Edheldil> hmm?
[15:53:08] <fuzzie> With the Bitmap changes, that is perhaps not a bad idea.
[15:53:13] --> cfchris6 has joined #GemRb
[15:53:32] <tomprince_loki> One think that I would like to do eventually, if it doesn't have to big of a performance hit is split up KEYImporter, so that knowledge of chitin.key isn't tied to the loading of files from the filesystem.
[15:53:56] <tomprince_loki> fuzzie: ?
[15:53:57] <fuzzie> Do you think there would be any performance impact to that?
[15:54:14] <fuzzie> tomprince_loki: Well, I mean, your code uses 'Bitmap' for the performance-sensitive image code.
[15:54:50] <fuzzie> So I don't have to worry any more about different image formats causing even worse performance there.
[15:55:18] <cfchris6> where is the appropriate place to report bugs in a guiscript?
[15:55:44] <fuzzie> cfchris6: here :-) or the bugtracker on sourceforge. but if it's about PS:T, that code needs a rewrite.
[15:55:46] <tomprince_loki> Well, there would be an indirection hit, but whether it would be noticiable is a differnt question.
[15:56:11] <fuzzie> But I mean, surely KEYImporter is only called at *load* time, no?
[15:56:32] <tomprince_loki> Yes, so it would only be when files are loaded, and disk access probably dominates.
[15:56:40] <tomprince_loki> That is why I don't think it will be a problem.
[15:56:52] <fuzzie> I would really hope it is a cost not worth even worrying about :)
[15:57:14] <tomprince_loki> The nice thing is that would allow thing like having a zip importer for GemRB specific games. Or an iso importer.
[15:58:00] <fuzzie> I know that the scummvm people have avoided that for fears of it making piracy a bit too trivial.
[15:59:41] <cfchris6> is bg1 tosc supported btw? (asking because for "throne of bhaal" there is an extra gametype which isn't there for tosc)
[16:00:18] <fuzzie> yes.
[16:00:47] <cfchris6> http://paste.pocoo.org/show/192912/ <- this is the traceback, happens when I selected spells for a mage and click ok
[16:00:52] <fuzzie> I'm not sure if plain bg1 works, in fact.
[16:00:55] <cfchris6> on char creation
[16:01:00] <lynxlynxlynx> cfchris6: how old gemrb?
[16:01:04] <cfchris6> 0.6
[16:01:06] <lynxlynxlynx> ok
[16:01:32] <fuzzie> the code is still there in svn.
[16:01:49] <lynxlynxlynx> yes, this is the refactored stuff
[16:02:30] <lynxlynxlynx> maybe the wrong function got used
[16:02:46] <lynxlynxlynx> just looking at grep, there's another next: def next(self):
[16:02:56] <fuzzie> that should be safely inside a class
[16:03:25] <cfchris6> I grepped through the stuff around the gui scripts but I could not find the next() which needs a parameter...
[16:03:50] <fuzzie> it is the built-in python function next().
[16:04:08] <fuzzie> because LUSpellSelection doesn't import bg1's CharGenCommon.
[16:04:33] <lynxlynxlynx> mhm
[16:04:44] <cfchris6> hehe, at least now I have proven I don't know much about python :>
[16:04:51] <fuzzie> I would guess the obvious fix would be for it to do so; just add an 'import next from CharGenCommon' on the line above the 'next()', perhaps.
[16:05:19] <fuzzie> although others would know better than me :)
[16:07:22] <cfchris6> not sure if having an import all the way down there is a good thing. however it works, so thank you very much for your prompt help.
[16:07:49] <fuzzie> thankyou for the bug report!
[16:10:19] <Edheldil> any reason not to put the import to other imports_
[16:10:26] <Edheldil> ?
[16:11:05] <tomprince_loki> Well, that file is used in more that bg1, bg2 which are the only ones that have CharGenCommon.py
[16:11:18] <tomprince_loki> The issue is that only bg1 and bg2 uses that script during chargen, and only bg1 takes the branch where next is called.
[16:13:56] <tomprince_loki> Long term, it would probably be better to define an api for LUSpellSelection, and stick to that.
[16:14:08] <tomprince_loki> Probably true for most of the GUIScript.
[16:17:50] <cfchris6> not sure if that is a bug as I haven't played bg for a long time: When I click on npcs to talk with them, my char goes towards them, but stops at a distance where talking is not possible yet. If I click beside the npc and then talk, it succeeds.
[16:19:14] <fuzzie> The bg1 chargen is an experimental rewrite contributed by someone.
[16:19:44] <fuzzie> It is a much simpler design, but I don't think we've quite ironed out all the bugs yet.
[16:20:02] <fuzzie> So ideally we'd eventually rewrite everything in the same way, and hence have that as the API.
[16:20:22] <fuzzie> Obviously LUSpellSelection directly checking for bg2 like that is not a wonderful plan..
[16:20:39] <fuzzie> cfchris6: That is a bug.
[16:21:47] <tomprince_loki> I think that is a good idea.
[16:22:38] <tomprince_loki> Also, like a suggested before, I think it would be good to have a more complete C++ <-> Python interface, that is closer to the C++ side interface.
[16:23:16] <fuzzie> It would make sense as preperation work to moving more code to the python side.
[16:24:46] <fuzzie> But then it leads to the mess about *how* to make the interface manageable..
[16:26:52] <fuzzie> I am unhappy about all the logic in GUIScript/ right now, especially all of the UI hard-coding in there for things like the action bar.
[16:28:37] <fuzzie> But it's one of these things like the keybindings that I am reluctant to touch because everyone has different ideas about how it should work.
[16:29:35] <lynxlynxlynx> who has different ideas about keybindings?
[16:30:06] <fuzzie> you, me, zefklop, Edheldil and Avenger :)
[16:30:32] <tomprince_loki> What are the different ideas?
[16:30:42] <fuzzie> I would like to just hand keystrokes to the GUIScript side and have all of the work done in python.
[16:31:41] <fuzzie> Although the keymap.ini lookup is perhaps easier done on the C++ side.
[16:32:18] <tomprince_loki> Well, that is one reason I wanted to have the python bindings generated, so that that was no logner true.
[16:32:19] <fuzzie> But there were arguments for, example, a 2DA file which maps the keymap.ini names to python functions.
[16:33:27] <fuzzie> I think it really all belongs on the python side, especially considering that the PS:T GUI has a built-in editor, so it's going to need the information anyway.
[16:34:00] <tomprince_loki> I think that one reasonable way to approach design, is to figure out how one would implement if we didn't have the "legacy" bioware games to implement.
[16:34:24] <tomprince_loki> Not to ignore them, but structure the code so that the knowlege isn't in the core at all.
[16:34:57] <tomprince_loki> Which would suggest to me putting in python.
[16:35:16] <fuzzie> I think the trouble is that if you make that a high priority, you spend so much time working on flexible interfaces that nothing ever works :)
[16:35:42] <tomprince_loki> And then, it would be reasonable to use a 2DA to map keymap.ini names to functions, at least if they aren't consistent across games.
[16:36:00] <tomprince_loki> Well, enough works now, that I can worry about making things orthogonal. :)
[16:36:09] <fuzzie> http://log.usecode.org/gemrblog.php?log=5Aug2009
[16:36:26] <fuzzie> Starting about half way through.
[16:37:54] <tomprince_loki> And I am not suggesting building all the flexible interfaces upfront, simply keeping that in mind, and trying to structure things in a way that makes it easier to add the flexible structures later.
[16:40:06] <tomprince_loki> And I suspect that if too much thought had been spent on abstract design, then GemRB wouldn't be where it is today.
[16:41:36] <tomprince_loki> GemRB has mostly just worked for me. So I have the luxury of trying to clean up the architecture. :)
[16:42:43] <Edheldil> hehe, doom of many OSS projects - extensive precoding stage :)
[16:43:17] <fuzzie> The keymap thing is frustrating because it would be quite an improvement if only a design could be agreed on.
[16:44:12] <fuzzie> It's been mentioned by several Nxxx users in the last couple of months.
[16:45:40] <tomprince_loki> Well, I don't think the code is in a state where the "right" design can be implemented yet, so it might make sense to implement it as hack for now, if it is holding up adoption.
[16:45:44] --> raevol has joined #GemRb
[16:45:52] <fuzzie> Although I suppose given how quiet development is right now, there's no problem just committing .. yes, as you say.
[16:47:56] <Edheldil> well, (if it matters) I am ok with any variant that is flexible and not a performance hit
[16:48:55] <fuzzie> Another problem with GemRB is that any time you suggest writing anything in python, everyone worries about performance :)
[16:49:55] <fuzzie> Although I have forgotten where all the performance problems are. I do wish there were better profiling tools..
[16:50:38] <tomprince_loki> Well, I did some profiling with the new perf command in linux, and the only thing of any impact was the SDL code.
[16:50:52] <tomprince_loki> Although, I don't know how accurate that is.
[16:50:58] <tomprince_loki> And it is a rather powerful machine.
[16:53:44] <fuzzie> The code used to spend a lot of time poking at some of the things which are now Bitmaps in your code.
[16:57:40] <tomprince_loki> Well, that is an example of abstraction paying off in runtime. Since I had absolutly no intention of that being an optimisation, simple an OOP correctness issue. :)
[16:58:03] <fuzzie> Although I profiled it on non-x86, so there could have been other issues there, I don't know.
[16:58:44] <fuzzie> A quick run of oprofile now on an x86 machine, with your changes, is indeed showing everything paling into insignificance compared to the SDL bits.
[16:59:53] <tomprince_loki> It would be nice to be able to get rid of all the preprocessor magic that goes into SDLVideoDriver.inl
[17:00:35] <tomprince_loki> I have made several attempts at it, but it rather hairy.
[17:01:32] <fuzzie> It does rather a lot of weird things I don't understand, and the obvious simplifications all make it even slower.
[17:01:44] <Edheldil> since you did not profile the key-handlers-in-python patch, it's hard to say what would be the effect of having left arrow in python. But if you think it's ok, go for it
[17:02:01] <fuzzie> Edheldil: I was, admittedly, not thinking of letting python handle that :)
[17:02:28] <tomprince_loki> With the amount time spent in SDL, I don't think that doing all the keyhandling in Python is much of hit.
[17:02:34] <Edheldil> hehe, ok
[17:02:48] --> Maighstir_laptop has joined #GemRb
[17:03:10] <fuzzie> An OpenGL implementation of the video driver would be the best solution, if it's possible to avoid doing all the work in software.
[17:03:24] <tomprince_loki> fuzzie: the problem that trying to get understandable code that worked out of SDLVideoDriver.inl is hard.
[17:03:40] <tomprince_loki> no matter how slow.
[17:03:59] <tomprince_loki> Once that is done, optimizing and opengl port probably wouldn't be to hard.
[17:04:07] <tomprince_loki> The trick is getting *right*.
[17:04:14] <tomprince_loki> At least, that is my guess.
[17:04:24] <fuzzie> Well, I just tried switching all the #ifdef messes for 'if' statements, at some point.
[17:06:13] <fuzzie> Well, and '?' constructs.
[17:06:23] <tomprince_loki> I could switch some them, and still get it to work. But some #defines are gaurded by #ifs, and ....
[17:06:46] <fuzzie> Well, all the hard work is in the preprocessor macros :(
[17:06:51] <tomprince_loki> And then i wanted to change the defines to const where I could, and ...
[17:07:12] <tomprince_loki> The code would always run, but not always with the right colors and stuff.
[17:08:00] <tomprince_loki> And, the other thing I didn't know, is how bit-perfect the code is, and wants to be with regards to the original engine.
[17:08:28] <tomprince_loki> Wheteher we care about things like rounding the blending off by one errors and such like.
[17:08:53] --> barra_desktop has joined #GemRb
[17:09:08] <tomprince_loki> Because if we care, then that perhaps makes it hard to get hardware acceleration.
[17:09:53] <fuzzie> I would not think anyone is going to notice.
[17:11:39] <tomprince_loki> The other thing that I tried to is to split up the Sprite object into the two diffrent types, or unify them into one.
[17:12:31] <Edheldil> can't decide? :)
[17:12:44] <fuzzie> Well, all the complexity is for BAM files, right?
[17:12:59] <tomprince_loki> Yes.
[17:13:09] <tomprince_loki> Edheldil: No, I can't.
[17:13:13] <tomprince_loki> Either would work for me.
[17:13:56] <tomprince_loki> But, I don't like having Sprite2D in core, but implemented almost entirely by calling into SDL.
[17:14:43] <fuzzie> Ideally you would presumably want Sprite2D in core, and then an internal driver-specific object inside it?
[17:15:07] <tomprince_loki> Exactly.
[17:15:44] <tomprince_loki> And since we have that, and have 2 implementations already, I thought split them into 2.
[17:15:51] <fuzzie> Doesn't seem like it would be too hard to do.
[17:15:59] <tomprince_loki> But, I would much rather not have the two code paths for blitting.
[17:16:52] <fuzzie> Well, in any case, you're going to want "blit this directly" and "blit with effects" paths?
[17:18:04] <tomprince_loki> I don't know. That would probably make sense from an optimization standpoint.
[17:19:11] <tomprince_loki> But, on the other hand, I might make more sense to have more than two code paths, since I think most of the combinations that are implemented aren't actually used.
[17:19:39] <fuzzie> no?
[17:19:46] <tomprince_loki> And the tricky thing is that some of the combinations are implemented, and some aren't, some probably some that are don't work.
[17:20:38] <tomprince_loki> Well, it has been a couple of months since I looked at the code in any detail.
[17:22:17] <fuzzie> Well, I know that the non-BAM path is pretty flaky in what it supports, but I think most of it is unused.
[17:22:47] <tomprince_loki> Yes, that does seem to be what I recall.
[17:22:58] <fuzzie> I really don't know anything about the code whatsoever, though.
[17:25:22] <fuzzie> I know that we flip/mirror BAM sprites an awful lot; we could cache those if it would help, but I imagine not.
[17:26:26] <Edheldil> so the worst hit is blit?
[17:27:08] <tomprince_loki> I don't have any of the data I gathered, but as far as I can rember, that is about the only hit that isn't in the noise.
[17:28:01] <tomprince_loki> Flipping sprites ahead of time would help cut down on code paths.
[17:28:28] <tomprince_loki> And treating sprite covers as sperate sprites might do the same. I don't know if that is feasable or sensible though.
[17:29:10] <Edheldil> the question if it's a relevant hit ... because the screen gets blitted several times pers second, but what is important is responsivity, I would think
[17:29:54] <fuzzie> In the profile I just did, blitting is the majority. Audio is also in there, and the map exploration code (unaligned accesses, perhaps?).
[17:30:19] <fuzzie> But it was not a very scientific test.
[17:30:24] <-- tomprince_loki has left IRC (Quit: tomprince_loki)
[17:30:58] --> tomprince_loki has joined #GemRb
[17:32:15] <Edheldil> bye, ppl, see you later, perhaps
[17:32:36] <tomprince_loki> Well, it is fast enough for me, I am more interested in understable code, than fast.
[17:32:44] <Edheldil> the last question... what about the transition to Git? The last time it seemed that everybody is ok with that
[17:33:07] <tomprince_loki> Well, I have a repository set up...
[17:33:07] <Edheldil> premature optimization is the root of all evil :)
[17:33:36] <tomprince_loki> Exactly. I think that that has happened. Now I need to try and unoptimize to understand it. :)
[17:33:42] <Edheldil> I know, but I would prefer at SF :)
[17:34:10] <tomprince_loki> That would make sense ... but I can't set anything up there.
[17:35:21] <tomprince_loki> fuzzie: ?
[17:36:09] <tomprince_loki> If we did, it would probably make sense to re-import, with proper author/commiter info. and possibly without git-svn-ids.
[17:36:12] <Edheldil> I can switch Git on right now
[17:36:32] <Edheldil> sure, I do not want to lose history
[17:36:47] <fuzzie> I think someone has to walk Avenger through it.
[17:40:14] <Edheldil> ok, git enabled. Now to do the import :)
[17:40:25] <Edheldil> bye for now ...
[17:40:35] <tomprince_loki> http://pastebin.ca/1850549 is the list of people who have commited.
[17:41:01] <tomprince_loki> To have a nice looking import, we'd need some sort of information and address from them.
[17:41:31] <Edheldil> yep
[17:42:07] <Edheldil> it in AUTHORS file
[17:42:12] <Edheldil> later
[17:42:22] <tomprince_loki> later.
[17:43:05] <tomprince_loki> Although, do people nat there sf address, or something else?
[17:46:11] <tomprince_loki> And, missing dragonmeat, hrk, idstewart, uid33071.
[17:46:54] --> Gekz_ has joined #GemRb
[17:47:08] <tomprince_loki> I'll run the import whenever (every|any)body wants it done, and push it up.
[17:48:56] <tomprince_loki> I'd probably also cleanup that commit message and author of the patches of mine that have been commited, any other cleanups that people want done.
[17:49:14] <tomprince_loki> Anyway, I'm off.
[17:50:01] <-- tomprince_loki has left #GemRb
[17:50:23] <-- Gekz has left IRC (Ping timeout: 246 seconds)
[17:51:03] --> tomprince_loki has joined #GemRb
[17:58:06] --> kettuz has joined #GemRb
[18:02:12] <-- tomprince_loki has left IRC (Ping timeout: 252 seconds)
[18:11:05] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[18:11:21] --> Gekz_ has joined #GemRb
[18:26:55] <-- Nomad010 has left IRC (Ping timeout: 260 seconds)
[19:03:03] <-- kettuz has left IRC (Quit: Leaving)
[19:10:04] --- barra_desktop is now known as barraAway
[19:15:59] --> |Cable| has joined #GemRb
[19:18:02] --> Edheldil_ has joined #GemRb
[19:19:16] <Edheldil_> lo
[19:30:23] <Lightkey> good thing I upped my buffer again
[19:35:39] <Lightkey> Edheldil_: http://wiki.scummvm.org/index.php/Release_Testing read that
[19:35:59] <Lightkey> http://www.ucw.cz/draci-historie/index.html the game you can download here
[20:13:25] --> tomprince_loki has joined #GemRb
[20:14:48] <Lightkey> loki?
[20:19:37] <tomprince_loki> Computer name.
[20:20:50] <tomprince_loki> Took me a few minutes to realise you were talking to me. :)
[20:22:34] <Lightkey> is that box such a bad boy? ;p
[20:23:51] <tomprince_loki> No.
[20:23:59] <tomprince_loki> It just travels a lot.
[20:26:43] --> ratpor has joined #GemRb
[20:28:52] <fuzzie> lynxlynxlynx: can i persuade you to look into that next() fix, given the import fixed it?
[20:29:16] <lynxlynxlynx> i can't look into it, but i can add the import (to the top)
[20:29:26] <lynxlynxlynx> don't have bg1 installed to test
[20:29:48] <fuzzie> well, that is not going to work
[20:30:11] <lynxlynxlynx> don't tell me, another circle
[20:30:29] <fuzzie> no, but the module doesn't exist everywhere
[20:30:43] <tomprince_loki> well, we could conditionalize on bg1 for now.
[20:30:57] <lynxlynxlynx> indeed
[20:31:21] <lynxlynxlynx> each gametype has a different chargen system
[20:31:24] <fuzzie> that sounds fine, or just ignoring the missing-module exception.
[20:31:41] <lynxlynxlynx> we've only just scratched the surface at uniting them
[20:31:42] <fuzzie> my fix would be to put the import above the next(), so i'm sure that disqualifies me
[20:31:56] <lynxlynxlynx> that's a bit more ugly
[20:32:11] <tomprince_loki> Well, the call to next itself is ugly right now.
[20:32:16] <lynxlynxlynx> you don't put #includes in the middle of files either ;)
[20:32:51] <tomprince_loki> How about a comment that it is ahck until there is a proper interface to LUSpellSelection?
[20:32:58] <fuzzie> lynxlynxlynx: look at SDLVideoDriver.cpp ;p
[20:32:59] <tomprince_loki> s/ahck/hack/
[20:33:29] --> barra_away has joined #GemRb
[20:33:41] <fuzzie> but i am also missing bg1 here, so i can't test.
[20:33:49] <fuzzie> can later, if needed.
[20:34:11] <lynxlynxlynx> don't worry, it's just two lines ... heh heh
[20:34:19] * lynxlynxlynx forgets the colon after the if
[20:36:47] <tomprince_loki> I think it might be better to put the import right at the next: it is ugly, but is obviously ugly.
[20:36:52] <-- barraAway has left IRC (Ping timeout: 276 seconds)
[20:38:07] <tomprince_loki> And also has the advantage that it doesn't expose symbols needlessly.
[20:38:24] <fuzzie> i think the guiscripts have lost the symbols game a while ago :)
[20:39:00] <fuzzie> and presumably eventually the correct fix will involve a global import..
[20:40:24] <tomprince_loki> Well, I think we all agree that all the proposed solutions are hack, and I think that hack that obviously so is better than one that isnt.
[20:41:10] <lynxlynxlynx> that than what
[20:41:35] <tomprince_loki> A hack that isn't obviously a hack.
[20:42:02] <lynxlynxlynx> ah
[20:42:13] <tomprince_loki> I think the correct fix is to make the python side more objectfied (the C++ side as well: see Interface).
[20:42:58] <fuzzie> We ended up preferring the next() function design to passing around objects, I think.
[20:43:25] <fuzzie> (it's just a wrapper which calls next() on the character generation manager.)
[20:44:46] <tomprince_loki> Well, I haven't really looked at the GUIScripts at all.
[20:48:14] <fuzzie> I think it's not too bad, on the GUI/callback front.
[20:48:20] <tomprince_loki> One solution is to pass the continuation to LUSpellSelection directly, rather than calling some magic function in the environment.
[20:49:45] <fuzzie> Would make sense.
[20:50:02] <fuzzie> There are so many bigger issues, though. :)
[20:50:42] <fuzzie> Oh, I guess callbacks are still strings, which is a really silly idea.
[20:50:55] <fuzzie> Should really be passing python objects around.
[20:51:11] <tomprince_loki> Something that would be more complicated from C++ <-> Python interface standpoint would be to have LUSpellSelection act like a function that returned when it was done. That would involve running GUI and stuff during a Python call which would involve threads, or suspending the python call.
[20:51:28] <tomprince_loki> It might end up with cleaner GUI code though.
[20:52:09] <fuzzie> Do you think so?
[20:52:25] <tomprince_loki> Yes, well, absrtracted wrappers of python objects yes.
[20:52:31] <fuzzie> I mean, the callback model is nothing specific to gemrb.
[20:53:05] <tomprince_loki> So that we can support other scripting languages. Not that I am proposing that we do, but so that we can treat the plugins as if they were actually plugable.
[20:53:08] <fuzzie> How would you handle a button press if you had the python interpreter still running? If statements?
[20:53:11] <tomprince_loki> Which mostly they are yet.
[20:53:22] <lynxlynxlynx> triage
[20:53:33] <tomprince_loki> s/are/aren't/
[20:53:44] <fuzzie> I mean, there's nothing to prohibit using a callback model with any scripting language.
[20:54:44] <tomprince_loki> Either threads :(, or something like pythons yield.
[20:55:39] <fuzzie> I think the idea of the language being pluggable is great, but the idea of using a completely different GUI model to any mainstream GUI toolkit seems like it would simply be counterproductive.
[20:56:16] <tomprince_loki> The idea would be that at some point in the function implementing LUSpellSelection would say effectively, go run the gui I setup and tell me when you are done.
[20:56:22] <fuzzie> You'd be imposing a design which could be optionally implemented on the language side anyway.
[20:57:32] <tomprince_loki> Well, all these ideas are right off the top of my head. I don't know the python side well enought to know if they are actually sensible.
[20:57:45] <tomprince_loki> I am just throwing them out there to generate discussion.
[20:57:54] <fuzzie> Well, they just belong on the python side, if anywhere :)
[20:58:30] <fuzzie> I think the scripting engine is one of the only pluggable parts of the engine, although it should really be using some kind of private pointer type for callbacks.
[20:59:57] <lynxlynxlynx> i wonder why iwd didn't complain, it uses that function too
[21:00:06] <fuzzie> lynxlynxlynx: not for chargen, I think?
[21:00:17] <tomprince_loki> Also, with my patches, the sound+graphics.
[21:00:22] <lynxlynxlynx> yes, only for levelup
[21:00:30] <lynxlynxlynx> maybe i just haven't tried it yet
[21:00:39] <lynxlynxlynx> oh, its ifdefed
[21:01:32] <fuzzie> The scripting engine that would be nice to replace is the game scripting, which is not a plugin.
[21:01:41] <tomprince_loki> And I think the KeyImporter is essentially plugable.
[21:02:12] <tomprince_loki> fuzzie: Yes very much so. The implementation is tied very much to closely to the core right now.
[21:02:13] <fuzzie> And it is, as such systems tend to be, rather intimately intertwined with the core code, unfortunately.
[21:02:51] <fuzzie> It is the kind of thing where you change a single variable out-of-order to the original engine and you can no longer complete the game..
[21:03:43] <tomprince_loki> I think that it could probably be made into a plugin. It would take a lot of work, but it is on my todo list.
[21:04:05] <fuzzie> Well, beware that making it a plugin would probably result in touching huge amounts of the code in Core/.
[21:04:16] <tomprince_loki> The trick is finding the right abstractions for it.
[21:04:45] <fuzzie> And a further problem is that it is not complete, of course..
[21:05:00] <fuzzie> So not only do you have to find the right abstractions, but also anticipate the rest of the requirements.
[21:05:07] <tomprince_loki> What is missing?
[21:05:09] <lynxlynxlynx> yeah, can't you do something more beneficial? :)
[21:06:02] <fuzzie> well, making the scripting language switchable would probably be the biggest step towards making gemrb usable for actual third-party projects.
[21:06:07] <tomprince_loki> It would be nice if there were some automated tests.
[21:06:13] <fuzzie> but Avenger gave up on it a long time ago.
[21:06:52] <fuzzie> but I think almost all my work on gemrb has been simply fixing scripting/engine interaction issues.
[21:07:46] <lynxlynxlynx> only for third-party non-ie projects
[21:08:09] <lynxlynxlynx> our (target) userbase are mainly the ie modders
[21:08:18] <fuzzie> making sure that scripts are run in the right places, that functions do the right thing at the right time in relation to the scripting, and that they make sure to only change state at those times.
[21:08:47] <tomprince_loki> Well, most of my changes have been with an toward 3rd party stuff.
[21:09:33] <fuzzie> getting it right is probably an impossible task. certainly without reliable tests which would run in the original engine too.
[21:09:51] <tomprince_loki> Some of it for IE modders, like the TIZ stuff. Although, that format wasn't designed for in-game use, and there does seem to be a hit at load time.
[21:10:09] <fuzzie> and on "what is missing": the scripting synchronisation system is entirely missing.
[21:10:29] <CIA-43> gemrb: 03lynxlupodian * r7494 10/gemrb/trunk/gemrb/GUIScripts/LUSpellSelection.py: SpellsDonePress: only call next() in bg1
[21:10:59] <fuzzie> i have bits of it in the form of a message queueing system in my local tree.
[21:11:34] <fuzzie> certainly nothing which wouldn't be impossible to abstract.
[21:11:50] <fuzzie> but it would add yet more complexity.
[21:12:13] <lynxlynxlynx> annoying stuff
[21:12:32] <tomprince_loki> I would guess that a message queue would be something the would probably want to be in core, and then the plugins would register to listen for specific events.
[21:13:58] <tomprince_loki> Because I could for see people wanting to use multiple scriping languages. Particularily IE modder who are willing to target GemRB. They would have all the legacy scripts, but would be able to code new stuff in a sane language.
[21:14:14] <fuzzie> I *don't* think you'd have much luck abstracting it like that.
[21:14:50] <tomprince_loki> If you can abstract it at all, you should be able to abstract it like that, I think.
[21:15:03] <tomprince_loki> I haven't really looked at what would be involved yet though.
[21:15:07] <fuzzie> There's all kinds of messy per-object state necessary, all of which random scripts modify.
[21:15:08] <-- cfchris6 has left IRC (Ping timeout: 246 seconds)
[21:15:15] <fuzzie> As in, scripting-specific state.
[21:16:00] <fuzzie> So you have scripts poking object state in a specific way and expecting any scripts to react sometimes to within a fra me.
[21:16:42] <fuzzie> You could handle it case-by-case and build a very complex system, I guess, but it seems you would have much more luck simply encapsulating the whole thing and only allowing the single language per process.
[21:16:49] --> cfchris6 has joined #GemRb
[21:17:28] <fuzzie> But I am still labouring under the illusion there might be some interest in building something new with this, I guess, and PARPG is likely attracting anyone who would be interested, reimplementing a limited version of what gemrb already does..
[21:17:49] <fuzzie> I am rambling. :| Sorry.
[21:18:54] <tomprince_loki> There is the IE modding community. Which is still very active. Right now we don't have all that much that is a definite win over the original engine, with new bugs to boot. They have actually had quite a bit of success expanding the original engine with code patches.
[21:19:13] <tomprince_loki> But, if we had something like a sane scripting language, that could interact with the original one say ...
[21:19:20] <tomprince_loki> That might be a big enough win.
[21:22:15] <fuzzie> a nice dream :)
[21:24:54] <tomprince_loki> I have to have some reason for cleaning up gemrb. :)
[21:26:16] <tomprince_loki> Anyway, once all the code is nicely architeichted, we could port parpg to gemrb. :)
[21:26:43] <fuzzie> hehe, i am sometimes tempted.
[21:27:20] <tomprince_loki> Then create a portal in the BigWorldProject to PARPG, for much craziness.
[21:27:25] <tomprince_loki> :P
[21:27:38] <fuzzie> in that sense i am more interested in adding an isometric renderer to gemrb.
[21:28:03] <fuzzie> which is the other thing the random non-IE people seem to consistently wish for.
[21:29:21] <tomprince_loki> So, back to where we started :) we need to clean up SDLDriver.
[21:35:14] <ratpor> Adding renderer allready ? That was fairly early.
[21:36:07] <ratpor> Thought the plan was to work out most of the IE games first, but could see the temptation.
[21:36:34] <fuzzie> well, that is why I haven't done so :)
[21:36:50] <tomprince_loki> ? no, just that the current rendering code isn't very easy to understand. If we want a hope of adding any other rendering, we need a understandable render.
[21:37:32] <tomprince_loki> As far as I can tell, most of the games, except perhaps IWD2/PsT mostly work.
[21:37:44] <fuzzie> I just want a way to play Planescape: Torment on my phone, really. :) Haven't had much luck persuading others of the priority of this important task.
[21:38:04] <tomprince_loki> And, my plan is directly to support other games, although there has been someone around the last couple of days asking about that.
[21:38:35] <tomprince_loki> Just cleaning up the code in such a way that supporting other games becomes somewhat straightforward.
[21:41:51] <tomprince_loki> fuzzie: I'd like to be able to play PsT too. I just don't know the intracacies of the original engine to be much use in that regard. And the GemRB code is straightforward enough for my taste to learn from yet. Hence, my cleaning. :)
[21:43:46] <lynxlynxlynx> you can bug me to fix the levelup stuff this summer, it's the only game left
[21:44:16] <fuzzie> I'm not sure if anyone knows how the levelup stuff works.
[21:44:40] <lynxlynxlynx> tno is a crippled multiclassed char
[21:44:55] <lynxlynxlynx> others are straightforward
[21:45:07] <fuzzie> Well, I think the others are simply the same as bg1.
[21:45:16] <lynxlynxlynx> yes
[21:45:30] <fuzzie> But TNO seems to have all kinds of special-cases.
[21:45:48] <tomprince_loki> I would think that tno is closer to dual-class. (well, triple)
[21:45:53] <lynxlynxlynx> there's a famous bug tied to that mc thing -> tno keeps the base thac0 of a fighter even in other classes
[21:46:10] <fuzzie> yes, there was a lot of yelling when the fixpack people fixed it :)
[21:46:16] <lynxlynxlynx> quinn fixed that, but a furious debate followed about developer intent
[21:46:21] <lynxlynxlynx> :)
[21:46:28] <fuzzie> i did not follow it very well.
[21:46:37] <lynxlynxlynx> i followed the one on sorcerers
[21:46:41] <fuzzie> but i do keep an eye on the engine changes in the fixpack, because i would like to duplicate them.
[21:47:08] <fuzzie> well, most of them. not, for instance, the secret door hack.
[21:47:24] <fuzzie> but i'm sure there is a better way to do that in gemrb.
[21:47:45] <fuzzie> (there is only one secret door in PS:T, so the fixpack simply makes all secret doors depend on a scripting variable.)
[21:49:37] <tomprince_loki> Well, it would be good if we could support all of the engine hacks.
[21:50:53] <fuzzie> we've had reasonable luck so far by just adding new engine features and then shipping (for instance) an override script file which activates one as necessary.
[21:52:00] <ratpor> Well, dunno about the TNO using fighter thac0 was intended or not, but it did get quite silly.
[21:52:15] <CIA-43> gemrb: 03fuzzie * r7495 10/gemrb/trunk/Doxyfile: update doxyfile (patch from tomprince)
[21:52:34] <tomprince_loki> Should push those to weidu, so that all the mods can work easily on GemRB.
[21:52:36] <fuzzie> ok, i appear to have fudged git-svn into working on this macine, hooray.
[21:52:58] <ratpor> And yeah, I belive TNO actually worked as a adnd 2e dual classing system was mostly suppossed to work (so it's actually in some ways closer to the original material than bg1 etc). Save that he did get a couple of small tweaks (Normally I belive you where not able to return to a class)
[21:54:00] <tomprince_loki> Well, that is what you get when you are an immortal amnesiac who has lived thousands+ lives. :)
[21:54:10] <tomprince_loki> You tend to be exceptional. :p
[21:54:34] <ratpor> To be honest, I think he would have been better represented as a true multiclass F/T/W, would have been much less frustrating for me to play as well :)
[21:56:00] <tomprince_loki> Well, we can implement that.
[21:56:24] <fuzzie> you'd probably want it to be a mod.
[21:56:33] <ratpor> To be frank, that is one of the main reasons I've been following GemRB, becose I know that eventually I can change the class of TNO ;)
[21:56:34] <fuzzie> you'd want to change quite a bunch of scripting too.
[22:02:01] <fuzzie> wjp: around?
[22:04:06] <lynxlynxlynx> i'm looking forward to a 10 person party :)
[22:04:16] <lynxlynxlynx> higher levels are overrated
[22:04:26] <ratpor> Hahaha
[22:05:29] <tomprince_loki> I suspect that that would actually end up unbalanced in your favor.
[22:06:06] <lynxlynxlynx> Maighstir_laptop: awesome
[22:06:25] <lynxlynxlynx> tomprince_loki: me too, but there are already mods that decrease the xp gain
[22:06:47] <ratpor> I think it woudl depend upon the game.
[22:06:53] <fuzzie> i am very surprised no-one has done that yet.
[22:07:08] <ratpor> BG1 it would be way to powerfull, imagine all the bow archers you could have on the team :)
[22:07:32] <lynxlynxlynx> with so little hp
[22:07:35] <fuzzie> We only actually support 8 players, I guess.
[22:07:46] <fuzzie> Easily enough fixed though :)
[22:07:47] <tomprince_loki> ?
[22:08:03] <ratpor> IWD2 as well, as the xp system makes it work. While PST probablly not so much, becose of the less xp per character.
[22:08:15] <fuzzie> I mean, sorry, 8 party members.
[22:08:29] <fuzzie> and it's not as if you're really *short* of XP in P:ST. :)
[22:08:30] <tomprince_loki> Do we hard code that somewhere?
[22:08:41] <lynxlynxlynx> guiscripts at 6, but that's easy to change
[22:08:49] <fuzzie> yes, the scripting language stops at 'player8'.
[22:08:53] <ratpor> fuzzie: Not arguing that, but you would probablly grind a bit to get anyone but TNO to usefull levels.
[22:09:14] <lynxlynxlynx> game scripts have only up to 6, so definitely some regex magic would be needed to fix them up
[22:10:29] <tomprince_loki> Do many of the gamescipts actually care about particular players beyond the first, or do the just iterate over all of them?
[22:10:36] <fuzzie> they just iterate over all of them.
[22:10:49] <-- barra_away has left IRC (Quit: Verlassend)
[22:11:10] <fuzzie> unfortunately it's not quite so easy to auto-fix that, because a lot of the time there's increasing coordinates etc involved.
[22:11:33] <lynxlynxlynx> fuzzie: i disagree
[22:11:45] <fuzzie> i'm sure it would be trivial to write a script which patched the scripts, but it's not quite just a regex.
[22:12:10] <lynxlynxlynx> do you think the pcs would get stuck or would the cd move them apart?
[22:12:14] <fuzzie> or i don't think so, anyway :) maybe i only see the complicated scripts, since they're the annoying ones.
[22:12:31] <lynxlynxlynx> of course it is more than the regex, you also have to de- and recompile everything
[22:12:49] <tomprince_loki> Well, weidu makes that relatively straightforward.
[22:13:05] <fuzzie> the scripting files are plain text.
[22:13:12] <lynxlynxlynx> http://ops-area.net/annat/GemRB/logo04-2versions.svg :D
[22:13:23] <lynxlynxlynx> cogs for avenger
[22:13:36] <tomprince_loki> nice.
[22:13:42] <fuzzie> that is great :)
[22:14:05] <lynxlynxlynx> wjp, Edheldil_: you two also like the first one here: http://ops-area.net/annat/GemRB/logo04-2versions.svg ?
[22:14:15] <lynxlynxlynx> i'd like to get this over with ;)
[22:14:29] <Maighstir_laptop> Always happy to help :-)
[22:17:36] <lynxlynxlynx> surprising amount of people here today too :)
[22:18:20] <Maighstir_laptop> not to mention activity
[22:18:51] <tomprince_loki> fuzzie: (and everybody) is the consensus to move to git?
[22:19:18] <lynxlynxlynx> there always was, there's only the question of our dear project lead and windows
[22:19:46] <fuzzie> yes, but the timing is limited by someone teaching Avenger how to get it all working, since he *does* write almost all the code :)
[22:20:05] <lynxlynxlynx> git-svn isn't that bad
[22:20:16] <lynxlynxlynx> except at release time -.-
[22:25:46] <wjp> lynxlynxlynx: while I see the appropriateness of the gear, I think I prefer the second one. No real objections to the first one either though
[22:26:24] <lynxlynxlynx> ok
[22:26:27] <fuzzie> the first gear in the forum post seemed a bit better.
[22:26:34] <tomprince_loki> I was just wondering about getting my patches in. Not really a big deal, but easier to get proper attribution with git. So if the switch was going to happen in the near future, it might make more sense to switch before rather than after.
[22:26:39] <tomprince_loki> Mostly selfish. :)
[22:26:54] <fuzzie> well, i hope we can just edit the repository during the move?
[22:27:43] <tomprince_loki> Yes, no problem with that.
[22:28:53] <fuzzie> i am simply using git-svn on this end, but obviously it loses that information on the dcommit..
[22:29:45] <tomprince_loki> Doesn't really bother me, just saves the hassle of having to add the (patch from tomprince) every time.
[22:30:21] <fuzzie> there's no way for me to add some kind of info git-svn can parse?
[22:30:41] <tomprince_loki> And I am not trying to hold up the merging of my code. :)
[22:31:02] <fuzzie> the manpage mentions '--use-log-author'
[22:31:18] <fuzzie> so if you could give me an appropriate 'From:' line?
[22:31:41] <tomprince_loki> Just that there is a git repo on sf now.
[22:32:10] <fuzzie> can we make it two-way sync with svn automatically, perhaps?
[22:32:12] <tomprince_loki> There is the --add-author-from
[22:33:42] <tomprince_loki> There are some projects that do that. I don't have any experience with it though.
[22:34:19] <lynxlynxlynx> sounds iffy
[22:34:56] <tomprince_loki> I think most that do that are one way.
[22:35:36] <lynxlynxlynx> does anyone remember if the time button in pst also had a tooltip?
[22:35:54] <ratpor> from memory nope.
[22:36:37] <ratpor> double checked, it displays the clock
[22:36:53] <lynxlynxlynx> just the clock or also the days?
[22:36:59] <lynxlynxlynx> i'll go find the strref
[22:37:26] <ratpor> just clock
[22:37:29] <ratpor> in green text :p
[22:37:31] <lynxlynxlynx> format?
[22:37:42] <ratpor> hh:mm AM/PM
[22:37:53] <lynxlynxlynx> AM/PM?? gah
[22:38:22] <lynxlynxlynx> indeed
[22:38:27] <lynxlynxlynx> <CLOCK_HOUR>:<CLOCK_MINUTE> <CLOCK_AMPM>
[22:38:50] --> Enverex has joined #GemRb
[22:38:51] <lynxlynxlynx> is this real time or game time btw?
[22:38:52] * ratpor is waiting for lynxlynxlynx to state hes adding a 24H system under options for PST
[22:38:56] <ratpor> gametime
[22:39:01] <lynxlynxlynx> good
[22:46:23] <-- Enverex has left IRC (Remote host closed the connection)
[22:49:17] <lynxlynxlynx> ok, have it working
[22:53:18] <fuzzie> ok, the plugin delay still doesn't work
[22:54:46] <lynxlynxlynx> my minutes don't pass either
[22:55:17] <tomprince_loki> fuzzie: Does it not work, or do you have the wrong plugin name?
[22:55:21] <lynxlynxlynx> btw, do you know why SetGamedaysAndHourToken mods with 7200 instead of 3600?
[22:56:37] <fuzzie> um
[22:58:00] <fuzzie> why 3600?
[22:58:23] <lynxlynxlynx> seconds in an hour?
[22:58:48] <fuzzie> i think there are 300 seconds in an IE hour, *24 = 7200
[22:59:06] <lynxlynxlynx> ah ok
[22:59:15] <lynxlynxlynx> it divides by 300 later :)
[23:01:18] <fuzzie> i think i broke plugin delay by applying an earlier patch
[23:03:02] <fuzzie> ok, maybe it never worked like this.
[23:03:15] <fuzzie> never mind.
[23:05:11] <tomprince_loki> How broke? As far as I know it always worked by first loading all plugins that aren't delayed, then all that are delayed.
[23:05:44] <fuzzie> i was running it from the wrong tree, i am an idiot sometimes :)
[23:05:52] <tomprince_loki> :)
[23:13:41] <fuzzie> Hum, git-svn is really not so clever about renames.
[23:14:40] <Genraznx> Nice to see the chat being so active
[23:14:57] <lynxlynxlynx> you should've been here last year
[23:15:01] <fuzzie> i know you worked out the 'svn mv' thing, but then i have to use svn for the whole commit, bla.
[23:19:48] <lynxlynxlynx> meh, it's already tommorow
[23:20:22] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:21:58] <tomprince_loki> .... (another reason to switch to git).
[23:22:00] * tomprince_loki hides.
[23:24:22] <Genraznx> http://i.somethingawful.com/u/garbageday/photoshop_phriday/2010_03_19/Matt_Cruea_01.jpg
[23:38:29] <tomprince_loki> So what is the feeling about exposing more or less the full C++ interface to Python. I know there is issues with dependencies, but beyond that.
[23:39:48] <fuzzie> I think the C++ side is possibly quite badly designed for that.
[23:40:03] <fuzzie> The GUIScript functions do a lot of hand-holding right now.
[23:40:59] <fuzzie> http://fuzzie.org/nfs/gemrb/0001-Rework-plugin-interface-to-Core.txt is my rewritten commit.
[23:41:34] <tomprince_loki> Yes, but I am working on the C++ side. And we can push alot of the handholding either to C++ or Python, rather than in the glue code.
[23:44:18] <fuzzie> Oh, I forgot to fix the spelling mistake.
[23:44:38] <tomprince_loki> You seem to be missing plugindefs.h
[23:45:54] <fuzzie> oops. stupid mistake, modified it slightly (to fix a path).
[23:47:04] <tomprince_loki> spelling mistake in PluginMgr registration failure.
[23:47:14] <fuzzie> hit refresh :)
[23:48:24] <fuzzie> (unless I am missing another?)
[23:52:52] <tomprince_loki> The diff against the old diff looks sane.
[23:53:41] <tomprince_loki> I didn't look at the build system changes (or lack of changes).
[23:54:01] <tomprince_loki> Are you planning on adding those changes back as a seperate commit?
[23:54:15] <fuzzie> Yes, once someone has checked them on weirder platforms.
[23:54:29] <fuzzie> I'd just like to get the rest committed now, since I don't see how they can break anything.
[23:54:39] <tomprince_loki> Yes.
[23:54:50] <tomprince_loki> What weired platforms do we care about?
[23:55:24] <Maighstir_laptop> anything with a compiler?
[23:55:31] <Maighstir_laptop> :-P
[23:55:46] <fuzzie> I think the autoconf thing honestly only works on Linux and Windows.
[23:56:14] <fuzzie> So just mingw and the N810, I guess, and I can't see why it would fail on the latter.
[23:56:15] <tomprince_loki> I think that I got autoconf to work under wine/mingw.
[23:56:30] <tomprince_loki> Been awhile though.
[23:56:34] <fuzzie> But it's easy to seperate from this commit.
[23:56:58] <tomprince_loki> Yes.
[23:57:18] <tomprince_loki> I agree with that.
[23:59:22] <fuzzie> svn is still committing. :)