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

Archive Today Yesterday Tomorrow
GemRB homepage

[00:26:59] <-- cubathy has left IRC (Ping timeout: 258 seconds)
[02:10:25] <-- raevol has left IRC (Quit: Leaving.)
[06:14:18] --> Gekz has joined #GemRb
[06:40:27] --> cubathy has joined #GemRb
[06:43:47] --> lynxlynxlynx has joined #GemRb
[06:43:48] --- ChanServ gives channel operator status to lynxlynxlynx
[06:53:47] <lynxlynxlynx> nice, plenty of new re work on the forum
[06:59:19] <-- |Cable| has left IRC (Remote host closed the connection)
[06:59:54] <-- cubathy has left IRC (Ping timeout: 258 seconds)
[08:00:08] <fuzzie> bah, bg2 :(
[08:18:27] --> edheldil has joined #GemRb
[08:18:28] --- ChanServ gives channel operator status to edheldil
[10:24:49] <pupnik_> that gemrb homepage is EXCELLENT.
[10:24:54] <pupnik_> 1) what am I?
[10:25:00] <pupnik_> 2) links to more information
[10:25:09] <pupnik_> and fits in a page
[10:25:42] <pupnik_> congrats on release lynxlynxlynx
[10:26:22] <Lightkey> a new release? o_O
[10:26:27] <Lightkey> how did I miss it
[10:30:48] <pupnik_> :)
[10:31:26] --- pupnik_ is now known as pupnik
[10:56:34] <Gekz> pupnik: what homepage?
[10:58:52] <pupnik> gemrb.sf.net
[10:59:10] <pupnik> i love a homepage where it takes my eyes just 1/3 of a second to find the info i need
[10:59:24] <pupnik> (link to the forum)
[10:59:42] <Gekz> lok
[11:14:17] --> budlust has joined #GemRb
[11:15:34] <-- budlust has left IRC (Remote host closed the connection)
[11:16:10] --> budlust has joined #GemRb
[11:17:45] <-- budlust has left IRC (Remote host closed the connection)
[11:18:16] --> budlust has joined #GemRb
[11:20:05] <-- budlust has left IRC (Remote host closed the connection)
[11:22:08] --> budlust has joined #GemRb
[11:24:40] <-- budlust has left IRC (Remote host closed the connection)
[11:25:10] --> budlust has joined #GemRb
[11:47:13] <-- budlust has left IRC (Remote host closed the connection)
[12:29:32] --> Maighstir_laptop has joined #GemRb
[13:41:02] <lynxlynxlynx> :)
[13:47:56] <fuzzie> hoorah for lynx.
[14:30:24] --> barra_library has joined #GemRb
[14:43:25] --> budlust has joined #GemRb
[15:12:15] <-- budlust has left IRC (Ping timeout: 260 seconds)
[15:38:53] <-- Gekz has left IRC (Changing host)
[15:38:53] --> Gekz has joined #GemRb
[15:41:32] <lynxlynxlynx> too bad pst doesn't run here
[16:11:45] <-- tomprince_loki has left IRC (Ping timeout: 265 seconds)
[16:19:14] <-- Gekz has left IRC (Quit: This computer has gone to sleep)
[17:00:00] <-- edheldil has left IRC (Ping timeout: 248 seconds)
[17:02:28] --> |Cable| has joined #GemRb
[17:02:45] --> tomprince_loki has joined #GemRb
[17:09:21] <-- Maighstir_laptop has left IRC (Quit: Maighstir_laptop)
[17:36:16] --> Maighstir_laptop has joined #GemRb
[17:38:46] <CIA-23> GemRB: 03lynxlupodian * rf16c9073d747 10gemrb/gemrb/GUIScripts/pst/GUIREC.py: pst::guirec: removed needless comments - most are now in tables
[17:38:48] <CIA-23> GemRB: 03lynxlupodian * rb538fc5c806c 10gemrb/TODO: removed stale TODO entries
[17:38:50] <CIA-23> GemRB: 03lynxlupodian * r23112d7ed400 10gemrb/gemrb/ (6 files in 4 dirs): added wisdom (xp) bonus handling
[17:45:24] <-- barra_library has left IRC (Quit: Verlassend)
[17:48:05] <tomprince_loki> lynxlynxlynx: Do you want, me to push the first 4 commits on the guicallback branch, once I get them cleaned up? Also, should I do a s/SetEvent/SetEventByName/ first, to make it clear the different behavior?
[17:48:15] <tomprince_loki> I'll probably get to it saturday.
[17:48:56] <tomprince_loki> And I'll also see if I can get a prototype ListBox wired up on top of it.
[17:51:57] <lynxlynxlynx> ask me when the cleanup is done
[17:52:35] <lynxlynxlynx> re rename: wasn't it already basically a SetEventByName?
[17:53:25] <lynxlynxlynx> and what did i forget with tags? I created 3 yesterday >>
[17:54:01] <tomprince_loki> That is what it is now. The thought was, change the name of the current behavior to SetEventByName, and have the new behaviour, taking a python callable as SetEvent.
[17:54:13] <lynxlynxlynx> (but no mail)
[17:54:20] <tomprince_loki> You didn't push them or something.
[17:54:58] <lynxlynxlynx> how did you push this one?
[17:55:30] <lynxlynxlynx> re rename: sounds good
[17:55:41] <tomprince_loki> git tag v0.6.1 sha1-hash; git push sf-ssh v0.6.1
[17:55:58] <lynxlynxlynx> ah, separately
[17:56:29] <tomprince_loki> I think it push tag *objects* automatically. So if you do 'git tag -a' or 'git tag -s'.
[17:57:02] <tomprince_loki> But not just tags that point directly at a commit.
[17:57:48] <lynxlynxlynx> they were made with -a
[17:58:35] <lynxlynxlynx> anyway, back on topic, when you're done, run through fuzzie again too if you want some proper feedback
[17:59:03] <tomprince_loki> :)
[17:59:25] <tomprince_loki> Yes, that is where to go to get review.
[17:59:46] --> raevol has joined #GemRb
[18:00:58] <tomprince_loki> Although I was asking more about the overall behavior, rather than the specifics.
[18:01:20] --> cubathy has joined #GemRb
[18:02:09] <lynxlynxlynx> overall i like it, since the callbacks are currently one of the blockers for tighter code sharing
[18:17:56] <lynxlynxlynx> and i got a nice idea for a playthrough with added promotional value
[18:18:45] <lynxlynxlynx> play something that isn't pst, but use the wisdom xp bonus and a cleric with sorcerer-like spellbook (both trivial changes in gemrb data)
[18:19:26] <lynxlynxlynx> and maybe a monk kit for a sidekick
[19:07:18] --> qubodup has joined #GemRb
[19:07:23] <qubodup> hello
[19:07:41] <lynxlynxlynx> oj
[19:07:42] <qubodup> so who's working on a Gemrb game? :D
[19:08:25] <lynxlynxlynx> nobody yet, but there is some demo progress
[19:08:44] <qubodup> how do you [he, she, they] do it?
[19:09:04] <qubodup> oh wait, i should check the forum before asking stuupid questions
[19:09:16] <lynxlynxlynx> the first step is to get all the minimal required data for gemrb to run
[19:09:23] <lynxlynxlynx> no need, it's a good question
[19:09:30] <qubodup> I don't know how the data 'can run'..
[19:09:34] <lynxlynxlynx> it should go on the wiki
[19:09:44] <qubodup> lynxlynxlynx: you mean first step 'find media'?
[19:09:52] <lynxlynxlynx> yes and no
[19:09:57] <qubodup> or 'convert media to format gemrb can dig'?
[19:10:22] <qubodup> also 'kick all n00bs and 1337talkers like qubodup'
[19:10:23] <lynxlynxlynx> first, we do have a truly minimal free dataset included in the tree, so the basics are known
[19:10:31] <qubodup> sorry. i'm silly today
[19:10:40] <qubodup> truly free sounds good
[19:10:45] <lynxlynxlynx> but it basically has no gui or other important stuff
[19:10:54] <qubodup> i see...
[19:10:59] <lynxlynxlynx> Maighstir_laptop is working on the demo iirc
[19:11:07] <lynxlynxlynx> some of the media and formats are tricky
[19:11:28] <lynxlynxlynx> the custom formats are mostly understood and can all be generated
[19:11:48] <lynxlynxlynx> things like avatar animations will take a lot of work though
[19:12:13] <lynxlynxlynx> when the time comes, i think it is best to use free models and write an exporter from lets say blender
[19:13:40] <lynxlynxlynx> basically there's a bunch of tricky files to create
[19:18:50] <tomprince_loki> And there is a willingness to add support for other data formats. Most of the support for doing it is there, just not the plugins.
[19:19:32] <tomprince_loki> Not for something like blender, but something the blender can export to directly, probably.
[19:19:41] <lynxlynxlynx> there are good existing tools to manipulate the custom formats
[19:20:22] <lynxlynxlynx> freedroidrpg also does their models in that fashion
[19:20:45] <lynxlynxlynx> basse models them in blender and then they get exported in all the needed angles and frames
[19:20:56] <fuzzie> re above: there's no doubt callbacks are a good thing, right?
[19:22:24] <lynxlynxlynx> i don't know a better way to keep the two systems in sync, but i'm not the it engineer here ;)
[19:24:11] <fuzzie> and i'm not sure whether SetEventByName is necessary but in the absence of someone going through and patching things up, it seems an excellent stepping stone
[19:24:40] <fuzzie> but i will look through the patches again tonight
[19:24:53] <tomprince_loki> No, I don't think it should stay around, but as you say, I think it is good to keep the functions separate.
[19:25:14] <fuzzie> :)
[19:25:54] <tomprince_loki> Re: guiscirpts, if there are any other things that you would like to be able to do from python, or different ways to interact with python, let me know, and I will see if I can make it happen.
[19:27:41] <lynxlynxlynx> the obvious thing is passing parameters to callback functions
[19:28:02] <tomprince_loki> One thing I saw, looking through GUIScript.cpp, I would like to move Setup*Icons and friends mostly to python, and partly to C++. Although I am not sure where to make the split.
[19:28:05] <lynxlynxlynx> i think you managed to do that just by using a lambda in that listbox patch?
[19:28:24] <fuzzie> yes, i mentioned before that an awful lot of the GUI stuff seemed like it belonged in python
[19:29:04] <fuzzie> but it seems best done after refactoring, since otherwise you end up with so many copies of the code
[19:29:04] <tomprince_loki> Well, if you know when you are calling SetEvent, what you want passed, the lambda will do it.
[19:29:30] <tomprince_loki> Yes, certainly, if it goes to python, it does so refactored.
[19:29:47] <fuzzie> well, i mean, after refactoring the callers :-)
[19:29:59] <tomprince_loki> That probably makes sense, too.
[19:31:28] <tomprince_loki> You can also set it up to pass stuff from C++ to python callbacks.
[19:32:14] <tomprince_loki> Although I wasn't sure what the interface should be. This easiest is just to have a bunch of functions on Callback, that pass different apramaters, since python is duck-typed.
[19:32:26] <fuzzie> that certainly makes sense for the single-use SetVarAssoc stuff, if that's what you mean
[19:32:44] <fuzzie> otherwise i'm not sure what you'd want to pass from C++ to callbacks, atm
[19:33:04] <tomprince_loki> Scrollbar position?
[19:33:11] <fuzzie> well, i mean, those are all integers, no?
[19:33:22] <tomprince_loki> Yes.
[19:33:38] <fuzzie> so you can get away with not worrying very much about the API, i meant :)
[19:34:40] <fuzzie> do you have an opinion on how to do keybindings?
[19:34:54] <fuzzie> i would really like to get it done, but it is really 90% a decision on the design and 10% trivial coding
[19:35:04] <tomprince_loki> Well, but that would mean having a ::call() and ::call(int). Which is fine an easy, and suggest what the rest of the api will be.
[19:35:12] <tomprince_loki> s/will/would/
[19:35:33] <fuzzie> well, that sounds like a very practical API :)
[19:35:35] <tomprince_loki> I haven't thought about keybindings at all.
[19:36:07] <tomprince_loki> BindKey(key_sym, callback)?
[19:36:16] <tomprince_loki> That would be the trivialest thing.
[19:36:26] <fuzzie> that was my first attempt
[19:36:41] <tomprince_loki> Any issues?
[19:36:48] <fuzzie> but is BindKey a C++ or Python function? :)
[19:37:11] <tomprince_loki> C++
[19:37:13] <fuzzie> if it's python, then it has to be able to read+write the bindings from the ini
[19:37:25] <lynxlynxlynx> and get sdl events
[19:37:43] <fuzzie> if it's C++, then how does it work out which callback, and how does it handle changes?
[19:37:53] <fuzzie> and in either case, how do tooltips etc work?
[19:38:31] <tomprince_loki> Well, my thought was python does GemRB.BindKey(key_sym, callback).
[19:38:55] <lynxlynxlynx> tooltips for inventory/etc icons are prefixed with the shortcut key in case you didn't know that
[19:38:56] <tomprince_loki> I hadn't thought about tooltips.
[19:39:04] <fuzzie> well, my thought is why bother having a complicated C++ side in that case, when you can just hand python the key_sym for every keypress
[19:39:11] <fuzzie> http://fuzzie.org/nfs/gemrb/keymap/ is all the ini files, btw
[19:39:32] <fuzzie> but tooltips is where i am stuck :(
[19:39:47] <fuzzie> i mean, it's not hard to implement *something*, i just don't know how it should be done
[19:40:07] <fuzzie> and so i would appreciate new input :)
[19:40:37] <fuzzie> (my thinking is that would let us get rid of half these ridiculous hard-coded callbacks from the core..)
[19:41:58] <fuzzie> and now i shall hit refresh on this exam results page some more
[19:43:46] <tomprince_loki> Thnking out loud ->
[19:43:55] <fuzzie> oh, important context to the above which might not be obvious: guiscripts need to be able to change the key bindings
[19:44:04] <fuzzie> i keep forgetting that bg2 etc force you to a silly external app for that
[19:44:30] <tomprince_loki> BindCommand('Keympap.ini command name', callback)
[19:44:45] <tomprince_loki> BindKey(key_sym, command_name)
[19:45:02] <tomprince_loki> SetEvent(event type, command_name) ?
[19:46:21] <tomprince_loki> Does that make sense?
[19:47:33] <fuzzie> not really :)
[19:47:41] <fuzzie> i mean, in the sense that i don't understand how it would work
[19:47:45] <lynxlynxlynx> we'll also need a reverse of BindKey for the tooltip
[19:48:24] <tomprince_loki> Well, that was just the interface, I'm not sure what it would look like under the covers.
[19:49:21] <fuzzie> grr, i guess we really need to do that GUI move into python *before* this, though
[19:49:42] <fuzzie> otherwise python has no view on half the buttons
[19:50:42] <fuzzie> but i think tomprince's idea is that SetEvent would be more of a SetCommand, which would handle the tooltips and the callback by looking them up by command?
[19:50:58] <tomprince_loki> Yes.
[19:51:22] <tomprince_loki> That is probably a better name for it anyway.
[19:51:57] <pupnik> MyPaint author gives lecture on extending Python with C/C++ for speed http://river-valley.tv/extending-python-for-speed/
[19:52:08] <fuzzie> and the python side would handle the ini read+writing?
[19:52:20] <pupnik> seems like he's going from a python-centric view though, not useful here
[19:52:27] <tomprince_loki> Also, do we want to do the Command -> callback binding at SetCommand time, or at callback time.
[19:53:06] <fuzzie> well, that is just a detail along the lines of SetEventByName vs SetEvent?
[19:53:13] <fuzzie> i would not worry about it yet
[19:53:38] <lynxlynxlynx> pupnik: python is not a speed limit here
[19:53:55] <pupnik> yeah sorry for the noise
[19:55:22] <tomprince_loki> Sort of along the lines of SetEventByName, except that the name space isn't tied to the namespace of the currently running main script.
[19:56:13] <fuzzie> so you could do some SetCurrentKeybindingsModule?
[19:56:28] <fuzzie> i'm not sure what'd be best for that, but it is i hope an implementation detail :)
[19:56:35] <tomprince_loki> Yes.
[19:58:05] <tomprince_loki> I guess we want all the keybindings to have names?
[19:58:32] <fuzzie> well, we want to read old keymap.ini files
[19:58:50] <fuzzie> and so that gives a pretty natural name for everything
[19:58:55] <-- pupnik has left IRC (Quit: Reconnecting)
[19:58:57] --> pupnik_ has joined #GemRb
[19:58:57] <tomprince_loki> Of couse. But do they have all the keybindings that there are?
[19:59:18] <fuzzie> well, i'm sure people can think of more :-) but to me it makes sense to just add new names for those
[19:59:29] <lynxlynxlynx> yep
[19:59:39] <lynxlynxlynx> new spell shortcuts or localisations
[20:00:23] <tomprince_loki> Thining about it some more, the real problem with SetEventByName is that it intereferes with the python namespace, not that it is by name. (Not suggesting that we don't also want to be able to bind to objects.)
[20:01:30] <fuzzie> well, the python modules are a 'natural' table
[20:01:55] <fuzzie> so it seems silly to add an extra level of indirection, unless there's a good reason for it
[20:02:49] <tomprince_loki> I am just saying that the module we picked is the wrong module -> we should use a dedicated one.
[20:03:05] <fuzzie> not sure what you mean
[20:03:26] <fuzzie> i mean, my only thought is: i don't want the python side to have to go through loops because the C++ side is picky
[20:03:46] <fuzzie> e.g. forcing everything to be in a dedicated module, or forcing the python side to provide all the callbacks manually
[20:03:57] <fuzzie> erm, through hoops is the expression, i guess.
[20:05:38] <fuzzie> but if it really ends up better like that, i can't object
[20:06:15] <fuzzie> as long as it's the python side being tidied up and then the C++ side catching up, rather than C++ design decisions forcing things on the python side
[20:07:49] <tomprince_loki> The issue, as I see it, is that we need to make all the symbols we want to call, visible in whatever module was last loaded by GUIScript::LoadScript, which means a) that we need to import everything into that script (with from blah import commands) rather than just doing something in the module where they are declared, b) it polutes the namespace of that module.
[20:08:13] <fuzzie> yes, the current design is also not so good
[20:08:16] <fuzzie> i agree with that
[20:10:01] <fuzzie> i'm just not convinced it's any better with a dedicated module
[20:10:20] <fuzzie> and am hoping there's some nice design that everyone has overlooked
[20:11:40] <fuzzie> or at least that we can make keybindings work and get half the problem out of the way forever
[20:15:19] <fuzzie> can i make cmake build me a useful out-of-build tree somehow?
[20:15:36] <tomprince_loki> Perhaps using python decorators? We do need to do some name translation anyway, since the keybindindings have ' ' and :.
[20:15:37] <fuzzie> atm it insists on creating an override/ directory, which means i can't just symlink the real override/ directory in
[20:15:59] <fuzzie> well, the majority of the keybindings should be automatically generated
[20:16:06] <fuzzie> all the spells, for example
[20:16:15] <fuzzie> so i don't know how that would work out
[20:17:40] <lynxlynxlynx> why do you want to symlink the other one in?
[20:17:58] <fuzzie> well, maybe there is a better way?
[20:18:00] <fuzzie> i just want to run gemrb
[20:18:05] <fuzzie> and setting GemRBOverridePath seems to not work
[20:18:24] <lynxlynxlynx> i don't need to set it to run gemrb from the out-of-tree build
[20:18:35] <fuzzie> well, how do you do it?
[20:19:08] <lynxlynxlynx> i've only set GemRBPath and PluginsPath
[20:19:38] <lynxlynxlynx> i run it from the build dir itself
[20:19:42] <fuzzie> hm, i guess it's ignoring GemRBPath :|
[20:19:51] <fuzzie> i expect i am doing something stupid, let me look
[20:20:02] <lynxlynxlynx> works from outside too
[20:20:52] <tomprince_loki> Although, we could probably make ADD_GEMRB_OVERRIDE smart enough to look in override/dir, and not need any cmake files in the subdirectories.
[20:21:16] <fuzzie> well, i was just doing something stupid, apparently
[20:21:23] <fuzzie> deleted the config file, copied a new one
[20:21:48] <fuzzie> "GUIScriptsPath=./" in the GemRB.cfg.sample also a little confusing :p
[20:25:35] <tomprince_loki> Am I the only developer that runs from an installed version?
[20:25:51] <lynxlynxlynx> i run it when doing releases
[20:26:03] <lynxlynxlynx> or testing build system changes
[20:26:06] <fuzzie> i think someone doing python patches did so
[20:26:23] <fuzzie> good thing too, no-one noticed that half the files in override/ weren't being installed
[20:26:32] <fuzzie> although apparently not enough to fix it for iwd too :)
[20:26:50] <lynxlynxlynx> i think we just copied the how stuff over later
[20:27:02] <fuzzie> but it's a pretty silly extra step in general
[20:27:09] <lynxlynxlynx> since we don't care how the projectiles worked in the original if they need overrides
[20:27:12] <fuzzie> i mean, if you're refactoring then often you only care about whether it built, fair enough
[20:27:40] <fuzzie> but needing to install when bugfixing with make/test/make/test cycles is just annoying
[20:27:44] <lynxlynxlynx> stale pyc are caught by testing too
[20:28:55] <tomprince_loki> I just use 'make -kj4 install'.
[20:29:22] <tomprince_loki> Although I have got hit with moved GUIScripts just doing that.
[20:29:36] <fuzzie> you don't find that's a lot slower than without the install?
[20:30:37] <tomprince_loki> Not significantly.
[20:32:06] <fuzzie> i also wonder if i can make cmake realise it doesn't actually have to re-link every single .so file
[20:33:33] <tomprince_loki> lynxlynxlynx: You install all the doxygen latex files.
[20:34:01] <tomprince_loki> Which makes it take a bunch longer now. :)
[20:34:52] <lynxlynxlynx> only if you generate them
[20:35:23] <lynxlynxlynx> (which i never do, so i can't notice)
[20:38:35] <tomprince_loki> A cold-cache make install takes ~7s (without doxygen). Not significant.
[20:38:54] <fuzzie> huh.
[20:39:01] <fuzzie> obviously your computer hates you a lot less than mine does.
[20:39:56] <lynxlynxlynx> multiple make jobs help
[20:51:06] <tomprince_loki> Even on my atom 'make -j2 install' takes ~4s wall clock.
[20:51:50] <fuzzie> it takes a noticable amount of time here
[20:52:10] <fuzzie> not even a strange filesystem, ext3 on a hard disk
[20:52:29] <fuzzie> if it works so well then obviously something is wrong here, thanks, i'll take a look
[20:53:30] <Maighstir_laptop> Question: How does radiobuttons work? The "Chose Gender" ones, specifically. I thought clicking one would change it to its selected state (in my case, frame 3 in the cycle), but it choses frame 2 for some reason even if both "selected" and "disabled" are set to "3".
[20:53:52] <tomprince_loki> Are you using cmake? autotools is noticably slower here, since it wants to relink everything, and does the install in series.
[20:54:55] <fuzzie> yes, trying out cmake
[20:55:00] <fuzzie> autotools is *ridiculously* slow installing
[20:55:11] <tomprince_loki> And that is obviously just the time of 'make install' after doing a full 'make'.
[20:55:51] <lynxlynxlynx> Maighstir_laptop: check if another state is being set
[20:56:04] <Maighstir_laptop> no state is set to 2
[20:56:33] <lynxlynxlynx> show us the script
[20:58:03] <tomprince_loki> Maighstir_laptop: Have you seen the log for the past ~2h? It seems like there will likely be quite the overhaul of the GUIScript code in the next few weeks.
[20:58:56] <fuzzie> well, maybe not so much soon which would be relevant to completely new scripts
[20:58:58] --- pupnik_ is now known as pupnik
[20:59:04] <Maighstir_laptop> http://pastebin.com/ZsquQcdy - I tried to interpret the bg1 script, so there may very well be some error
[21:01:16] <Maighstir_laptop> unpressed=0, pressed=1, selected=disabled=3, yet it choses 2 (I set both to the same to test, disabled should be 2)
[21:01:53] <Maighstir_laptop> also, I believe DLTCEP has disabled and selected backwards
[21:03:46] <fuzzie> it has them internally as unpressed, pressed, selected, disabled, which matches IESDP
[21:04:29] <lynxlynxlynx> oh, no overrides
[21:05:31] <fuzzie> you do have 4 frames in your cycle?
[21:05:35] <Maighstir_laptop> yes
[21:06:05] <fuzzie> hmm
[21:06:09] <fuzzie> what's your gemrb.ini like?
[21:06:36] <fuzzie> it sounds like you might have a IgnoreButtonFrames = 1 in there
[21:07:02] <Maighstir_laptop> thanks, that was it
[21:07:11] <fuzzie> hoorah :)
[21:07:27] <Maighstir_laptop> I think I just copied it from an existing game, not knowing what it does
[21:07:37] <Maighstir_laptop> or something
[21:07:48] <fuzzie> the source code says "//ignorebuttonframes is a terrible hack"
[21:08:04] <lynxlynxlynx> did you try using GemRB.SetButtonSprites?
[21:08:07] <fuzzie> but no further explanation
[21:08:11] <Maighstir_laptop> that makes it use hard-coded numbers?
[21:08:22] <fuzzie> it makes it use hard-coded numbers for cycles of size 4
[21:08:25] <Maighstir_laptop> lynxlynxlynx: no, what's that do?
[21:08:33] <fuzzie> no idea *why*
[21:08:45] <lynxlynxlynx> you could reorder them for testing, but i see the cause was already found
[21:09:44] <Maighstir_laptop> is there a reason the console window takes about 30 seconds to close after calling GemRB.Quit(), when the Gui window closes instantly?
[21:11:52] <fuzzie> but it does eventually close?
[21:11:57] <Maighstir_laptop> yes
[21:12:29] <tomprince_loki> Does it close quicker if you set KeepCache=1 in gemrb.cfg?
[21:12:58] <CIA-23> GemRB: 03lynxlupodian * rd8f7bf187b28 10gemrb/gemrb/override/bg2/clskills.2da: bg2/clskills.2da: fixed column alignment
[21:13:00] <CIA-23> GemRB: 03lynxlupodian * r25977e24bcd6 10gemrb/gemrb/docs/en/GUIScript/GetAbilityBonus.txt: GetAbilityBonus.txt: documented the other possible inputs
[21:13:11] <fuzzie> ouch
[21:13:36] <fuzzie> the cache DelTree is in the destructor?
[21:13:53] <fuzzie> what on earth?
[21:14:16] <tomprince_loki> Where else would it be?
[21:14:28] <fuzzie> somewhere where it doesn't delete my home directory if CachePath is baqd
[21:15:46] <tomprince_loki> I see what you mean.
[21:15:57] <Maighstir_laptop> no, it doesn't, takes about the same time
[21:16:29] <fuzzie> i was the last person to touch that code too, i can't believe i didn't see that
[21:16:36] <pupnik> :)
[21:17:09] <fuzzie> but i see there's a "//Don't delete the root filesystem :)" in there, at least :p
[21:18:42] <tomprince_loki> So we should CachePath[0] = '\0' in the StupidityDetector == true case?
[21:18:47] <fuzzie> but again the question about whether i can make cmake not attempt to re-link everything
[21:19:24] <lynxlynxlynx> no idea
[21:19:34] <fuzzie> i mean, just curious if anyone knows
[21:19:52] <tomprince_loki> Here, it just edits the runtime path.
[21:20:33] <fuzzie> tomprince_loki: i would be worried about someone adding clever logic in LoadConfig somewhere
[21:20:40] <fuzzie> and it missing the StupidityDetector
[21:20:42] <fuzzie> edits the runtime path?
[21:25:27] <tomprince_loki> Look in the cmake documentation for mention of rpath. I seem to recall fiddling with it, but if I can recall correctly, it seems like it was deciding that it was fast enough to just change the rpath in binary, that ignored the options I passed it.
[21:26:21] <fuzzie> sorry
[21:26:33] <fuzzie> i mean, if i touch e.g. core/Interface.cpp, it will relink all the .so files
[21:26:51] <fuzzie> it doesn't seem influenced by fiddling with the rpath, unless i again do something stupid
[21:27:39] <tomprince_loki> Ah, thats what you mean. That is isn't relinking on install.
[21:27:51] <fuzzie> no, just relinking at all :)
[21:28:16] <fuzzie> looking at immediate "how can i make cmake as fast as autotools?" issues before looking at the make install
[21:29:13] <tomprince_loki> I don't know if you can, without changing the build system. The plugins are linked agains core, so we can use -Wl,--no-undefined, to catch plugin load failures at build rather than run time.
[21:29:43] <fuzzie> well, i have no problem with sabotaging the build system :)
[21:30:07] <fuzzie> so i'll look at that
[21:31:00] <tomprince_loki> You should just need to get rid of gemrb_core in TARGET_LINK_LIBRARIES in ADD_GEMRB_PLUGIN, and remove the -Wl,--no-undefined.
[21:32:28] <tomprince_loki> I seem to recall that cmake+install was noticably faster than make+install.
[21:32:53] <tomprince_loki> Although, now that I think about it, I think I hacked the autotools stuff to do -Wl,--no-undefined.
[21:33:33] * tomprince_loki goes home
[21:38:11] <-- tomprince_loki has left IRC (Ping timeout: 260 seconds)
[21:48:18] --> budlust has joined #GemRb
[21:52:28] <-- budlust has left IRC (Remote host closed the connection)
[21:59:13] --> pupnik_ has joined #GemRb
[22:00:16] <tomprince> fuzzie: Quick fix without touching the build: make -c core
[22:03:22] <-- pupnik has left IRC (Ping timeout: 264 seconds)
[22:06:05] <fuzzie> that means i have to think about what component i'm touching, is all :)
[22:06:22] <tomprince> :)
[22:44:05] --> tomprince_loki has joined #GemRb
[22:47:37] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:50:16] <Maighstir_laptop> Forgive my continued newbie-ness, but how do I tell cmake on Linux (Ubuntu) where the C++ compiler is? it finds the C compiler, but complains about "CMAKE_CXX_COMPILER" not being set.
[22:50:47] --- pupnik_ is now known as pupnik
[22:51:33] <tomprince_loki> What does 'which g++' give you?
[22:52:29] <Maighstir_laptop> nothing... I thought it was installed with gcc?
[22:52:52] <Maighstir_laptop> thanks
[22:53:21] <Maighstir_laptop> solved
[22:54:42] <tomprince_loki> It is part of gcc, and it is the same source package, but apperntly ubuntu has separte binary packages. C++ is too heavy for some people, and most people don't want fortran or ada or gcj.
[22:56:08] <fuzzie> i think the package drags along the relevant libstdc++-dev and etc, which makes it a bit heavier, especially when you're installing a whole range of different versions
[22:57:39] <-- cubathy has left IRC (Remote host closed the connection)
[23:51:54] --> budlust has joined #GemRb