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

Archive Today Yesterday Tomorrow
GemRB homepage


[00:01:40] <Empiricist> http://paste.lisp.org/display/137529#5
[00:01:55] <Empiricist> New output!
[00:03:03] <brada> i dont see anythng new
[00:03:32] <Empiricist> [PluginLoader/WARNING]: Plugin Registration Failed! Perhaps a duplicate?
[00:03:42] <brada> thats irrelevant
[00:04:04] <brada> why does /Applications/gemrb.app/Contents/Plugins exist now?
[00:04:21] <brada> if anything you took a step backwards
[00:05:13] <Empiricist> You were suggesting that all of the ".so" files needed to be included in "/Plugins". Or that's what I thought you were implying.
[00:08:22] <Empiricist> Plugin Loading completed. Then it crashed with a Bus Error.
[00:08:54] <Empiricist> [Core]: Plugin Loading Complete...
[00:09:14] <Empiricist> Bus error
[00:11:53] <brada> bus error doesnt mean anything helpful
[00:12:15] <brada> and yes all the plugin sos need to be in your bundle
[00:12:23] <brada> *not*at /Applications/whatever
[00:12:31] <Empiricist> http://paste.lisp.org/display/137529#6
[00:12:57] <brada> see you are right back where you started lol
[00:13:49] <brada> you need to kill /Applications/gemrb.app
[00:14:03] <brada> put everything in your build gemrb.app
[00:15:40] <Empiricist> Ok. Done.
[00:16:29] <Empiricist> Now what? :)
[00:21:41] <brada> so in your build gemrb.app you should have the plugins and the guiscripts and the override and the unhardcoded directories
[00:24:03] <Empiricist> I have *created* the guiscripts, the override and the unhardcoded directories.
[00:24:38] <Empiricist> There is nothing in them.
[00:25:23] <brada> thats a huge probem
[00:25:55] <brada> they are at gemrb/gemrb
[00:26:04] <brada> copy them from there
[00:26:20] <brada> except the plugins folder
[00:26:33] <brada> that one is special and we alrady talked about what to do with it
[00:32:54] <Empiricist> Ok. In my /Users/jonn/programs/gemrb/build/gemrb/gemrb.app/Contents directory, I have: GUIScripts, Info.plist, MacOS, Plugins, Resources, override, and unhardcoded
[00:34:16] <Empiricist> Resources, override, and unhardcoded were copied directly from ~/programs/gemrb/gemrb/ directory.
[00:37:18] <brada> no
[00:37:43] <brada> GUIScripts, override, unhardcoded go in Contents/Resources
[00:37:53] <brada> and must not be empty
[00:38:11] <brada> by that i mean be the files from the repo
[00:38:25] <brada> plugins is wrong too
[00:38:52] <brada> in gemrb.app/Contents/PlugIns you need to put the so files for all the plugins
[00:39:01] <brada> sorry
[00:40:02] <brada> you can compare with the doenloaded version from SF if you are confused
[00:40:55] <Empiricist> I've got it, if the plugins direcory is spelled PlugIns.
[00:42:06] <brada> yes
[00:42:54] <Empiricist> *The other 3 folders that you mentoned are in the Resources folder. I'll check to see if they are empty.
[00:44:01] <Empiricist> None of them are empty.
[00:46:19] <brada> so you have a ton of python scripts in there?
[00:47:05] <Empiricist> I have.
[00:47:14] <brada> that should be all you need
[00:47:20] <Empiricist> http://paste.lisp.org/display/137529#7
[00:49:49] <Empiricist> GUIDefines.py definately exists.
[00:50:23] <brada> i see
[00:50:30] <brada> the cmake/config is wrong
[00:50:40] <brada> its looking in the wrong place
[00:50:52] <Empiricist> That's good news.
[00:50:54] <brada> if you move them to Contents/MacOS folder it should work
[00:51:03] <brada> so move the scripts
[00:51:05] <brada> and override
[00:51:09] <brada> and unhardcoded
[00:51:16] <brada> to Contents/MacOS
[00:51:21] <brada> ill look at the cmake
[00:51:26] <Empiricist> Musical directories is it?
[00:53:19] <brada> i dont know why your build is looking there
[00:53:35] <brada> the cmake doesnt define that afict
[00:54:11] <Empiricist> I'm dumbfounded.
[00:54:48] <Empiricist> It works. The whole thing. I got to the scene with Irenicus saying: "The child of Bhaal has awoken."
[00:55:04] <brada> yay
[00:55:05] <Empiricist> The crash that occured was self-induced.
[00:55:30] <Empiricist> Now, I think I understand everything that just happened here.
[00:55:33] <brada> still have no idea hwy your build is looking there
[00:55:40] <Empiricist> ... I hope.
[00:55:55] <Empiricist> Could be an issue with the cmake script.
[00:56:42] <Empiricist> You sir are fantastic. :)
[00:56:54] <brada> i dont see how it could be cmake tho
[00:57:06] <brada> i mean that does seem to be the only diff between the 2 builds
[00:57:14] <brada> i shall try a cmake build of my own
[00:58:04] <Empiricist> I think I can make a small python script to replicate the behaviors here.
[00:59:08] <Empiricist> But it should be possible to resolve all of these issues during the build process, right?
[01:01:26] <brada> what version of cmake do you have?
[01:02:06] <brada> im using 2.8
[01:02:07] <Empiricist> Oh... let's see.
[01:02:21] <brada> and it seems to build the complete bundle without make install
[01:02:22] <Empiricist> cmake version 2.8.9
[01:02:33] <brada> still building tho
[01:02:42] <Empiricist> Oh, mine didn't do the make install.
[01:03:06] <Empiricist> I ran it from the build folder.
[01:03:21] <brada> thats not what i mean
[01:03:33] <brada> i mean you shouldnt have had to manually copy the scripts to the bundle
[01:03:42] <brada> mine built fine. except for the plugins
[01:04:22] <Empiricist> I think I can wrap the whole thing in a python build script to circumvent this issue.
[01:05:06] <Empiricist> It'll speed things up for me.
[01:05:26] <Empiricist> But it would merely be a shameless hack for just about anyone else.
[01:05:53] <brada> it needs to be fixed at the cmake level
[01:06:07] <brada> i still dont understand why it behaves diffrently
[01:07:13] <Empiricist> About all that I know about cmake is that you can write a CMakeLists.txt script to act as a "configure" function to build the makefile, and cmake behaves more intelligently in general than most "configure" functions.
[01:08:08] <brada> no i mean i dont get why building with cmake is changing the *runtiime* behavior
[01:08:30] <brada> as in cmake build looks in Contents/MacOS for files
[01:16:02] <brada> this is probably an important tidbit missing from cmake: @loader_path/../Frameworks
[01:16:21] <brada> ^should be the runtime search path
[01:16:36] <Empiricist> Hmm...
[01:17:54] <Empiricist> Have you done anything with modding?
[01:18:00] <brada> no
[01:18:17] <brada> i assume you mean BG modding
[01:18:35] <Empiricist> Any modding was implied.
[01:23:19] <brada> well im sure ive modded something before
[01:23:24] <brada> not in a long while
[01:24:48] <Empiricist> Surprisingly. This build only works from the command line.
[01:25:12] <Empiricist> If I click on the application to activate it, it stops with the same GUIScripts problem.
[01:26:19] <brada> yeah the runtime is totally fubar from cmake build
[01:26:25] <brada> even tho it makes zero sense
[01:26:32] <brada> the SF download works fine
[01:27:10] <Empiricist> I'm testing a "sudo make install"
[01:27:17] <brada> wont help
[01:27:27] <Empiricist> Thought I'd try it.
[01:28:56] <Empiricist> Doesn't help.
[01:31:24] <Empiricist> Unfortunately I can't make heads or tails of this CocoaWrapper.
[01:32:54] <Empiricist> The answer to, "What is the difference between c++ and objective c?" is... enough to cause the c++ programmer problems.
[01:59:34] <brada> somehow CopyGemDataPath must behave diffrent when built with cmake
[01:59:38] <brada> tho i dont know why
[02:01:55] <brada> i also notice there is no GemrB menu in the cmake build o_O
[02:02:09] <brada> probably due to gemrb vs GemRB
[02:02:17] <Empiricist> There is in mine.
[02:02:33] <Empiricist> But perhaps you mean something different...
[02:05:23] <brada> i mean the menu next to the apple menu
[02:05:27] <brada> its there but nameless
[02:11:38] <Empiricist> http://paste.lisp.org/display/137529#8
[02:11:47] <brada> anyway the problem is that CopyGemDataPath gives a blank path in cmake build
[02:11:53] <brada> very mysterious
[02:12:13] <brada> dont waste your time on hacks
[02:12:19] <brada> ill fix it
[02:12:53] <brada> ha ha ha
[02:13:00] <brada> its sooo obvious now
[02:13:11] <brada> line 466 of VFS.cpp
[02:13:18] <brada> there is an #ifdef DATADIR
[02:13:27] <brada> and cmake defines that
[02:13:59] <Empiricist> I'll test your fix, if you'd like.
[02:15:04] <Empiricist> I really appreciate all of this.
[02:25:39] <Empiricist> Where is VFS.cpp?
[02:28:50] <brada> ill be back tomorrow
[02:28:54] <brada> going out fo the night
[02:28:59] <brada> this will be fixed tomorrow
[02:29:00] <-- brada has left IRC (Quit: brada)
[02:29:01] <Empiricist> Sounds good.
[02:29:39] <Empiricist> wjp: You have a real jewel in brada. :)
[03:14:22] <-- Empiricist has left IRC (Quit: Page closed)
[05:37:45] --> brada has joined #gemrb
[05:42:02] <-- brada has left IRC (Ping timeout: 245 seconds)
[05:51:17] --> brada has joined #gemrb
[05:51:20] <-- brada has left IRC (Remote host closed the connection)
[06:35:11] <-- edheldil has left IRC (Read error: Connection reset by peer)
[07:35:24] --> psch_ has joined #gemrb
[07:38:06] <-- psch has left IRC (Ping timeout: 276 seconds)
[08:15:46] --> fizzle has joined #gemrb
[09:54:47] --> Yoshimo has joined #gemrb
[13:52:49] --> lynxlynxlynx has joined #gemrb
[13:52:49] <-- lynxlynxlynx has left IRC (Changing host)
[13:52:49] --> lynxlynxlynx has joined #gemrb
[13:52:49] --- ChanServ gives channel operator status to lynxlynxlynx
[15:54:09] <-- Yoshimo has left IRC (Quit: Yoshimo)
[16:26:09] --> Empiricist has joined #gemrb
[16:26:19] <Empiricist> Hello.
[16:27:28] <Empiricist> Does anyone here know where the screen panning speed is defined in the source code?
[16:29:39] <Empiricist> The closest thing that I've found that might do that, so far is: Interface.cpp, mousescrollspeed...
[16:35:50] <Empiricist> Alright, I'll toggle that. If it's SDL that this puppy uses, then that 10 means 10pixels/time unit. And that's quite slow.
[16:36:19] <Empiricist> 10 pixels/frame?
[16:36:22] <Empiricist> Blah
[16:38:18] <lynxlynxlynx> it's configurable
[16:38:36] <lynxlynxlynx> keyboard/mouse scroll speed respectively
[16:46:10] <Empiricist> For the screen panning speed, would that be keyboard speed or mouse scroll speed?
[16:46:48] <Empiricist> Maybe I'll just quintuple both and see what that does...
[17:03:37] <Empiricist> Nothing.
[17:03:53] <Empiricist> It appears to do nothing. Is the core recompiling properly?
[17:06:57] <Empiricist> Nope.
[17:08:44] <Empiricist> How did the keyboard behave for the original ToB? Did it just 'hop'-around every time you pushed a directional key?
[17:11:17] <Empiricist> I can change that by included a concept of velocity and accelleration...
[17:11:23] <Empiricist> *including
[17:11:55] <Empiricist> Higher accelleration should mean: "It feels more responsive."
[17:18:18] <lynxlynxlynx> i don't know what you're doing, but it's clearly wrong
[17:18:24] <lynxlynxlynx> you can change the speed ingame even
[17:19:40] <Empiricist> I looked for that option.
[17:20:12] <Empiricist> Is it under graphics?
[17:20:24] <lynxlynxlynx> gameplay i guess
[17:21:00] <lynxlynxlynx> yeah
[17:21:31] <Empiricist> Yep.
[17:22:18] <Empiricist> There also appears to be a green tinge to all of the sprites and menus...
[17:24:00] <Empiricist> That would be why my changing the numbers didn't change anything. It was constantly going back to what the number was supposed set at in-game.
[17:29:18] <lynxlynxlynx> then you modified it at the wrong spot
[17:29:18] <Empiricist> Is it possible that the RGB palette was reversed to RBG?
[17:29:30] <lynxlynxlynx> sounds like a mac issue
[17:29:36] <Empiricist> Probably.
[17:29:59] <Empiricist> *probably true that I modified it at the wrong spot.
[17:31:04] <Empiricist> It's been a mac issue since Februrary, 2012
[17:31:21] <Empiricist> http://forums.gibberlings3.net/index.php?showtopic=24074
[17:31:23] <Pepelka> GUI and Sprites with yellow/green tint... - The Gibberlings Three Forums
[17:31:24] <Pepelka> »So I've been mucking about with the Mac version of GemRB and just managed to get it going with BGII:ToB. It runs so smooth, except for one odd th...«
[17:41:37] --- ermo^ is now known as ermo
[18:43:09] <lynxlynxlynx> ah, posterior sight
[18:51:18] <Empiricist> Opening a bag of holding causes the interface to freeze.
[18:57:42] <lynxlynxlynx> check the log, there should be a python error there
[18:58:32] <lynxlynxlynx> works here btw
[18:59:47] <Empiricist> I guess that linux has had a lot more work done with it. :)
[19:01:05] <Empiricist> Yep. File "GUIScripts/InventoryCommon.py", line 769, in OpenItemWindow
[19:01:33] <Empiricist> TypeError: 'NoneType' object has no attribute '__getitem__'
[19:02:08] <Empiricist> I think I can fix this.
[19:13:19] <lynxlynxlynx> it could depend on the stuff you have inside
[19:13:57] <lynxlynxlynx> but this sounds different
[19:14:54] <Empiricist> I just tried to add a print statement to the InventoryCommon.py script... now the GUIScripts is crashing.
[19:15:15] <Empiricist> Is it possible to change scripts In-Game?
[19:15:42] <Empiricist> Do I need to recompile every time I change a script? That would kind of defeat the purpose of scripting...
[19:20:12] <lynxlynxlynx> you can't reload guiscripts ingame
[19:20:25] <lynxlynxlynx> you managed to crash python??
[19:20:36] <Empiricist> No.
[19:20:42] <Empiricist> I don't think so.
[19:21:04] <lynxlynxlynx> are you sure of anything :S
[19:21:46] <Empiricist> You and I appear to be using different definitions of "crash". I don't know if those coincide. What do you mean when you say "crash"?
[19:22:01] <Empiricist> I just mean that the application doesn't run on launch.
[19:22:27] <Empiricist> Hence, the application "crashes".
[19:22:32] <lynxlynxlynx> catastrophic failure
[19:22:47] <Empiricist> As indicated by?
[19:22:50] <lynxlynxlynx> how you managed to cripple it by adding a python print is beyond me
[19:23:04] <lynxlynxlynx> sigsegv, abort or similar
[19:24:02] <Empiricist> No, this appears to be a simple data problem. Whether it's an issue with not loading an item, or an item not have an expected state... I don't know.
[19:24:18] <Empiricist> I should be able to add a print statement with this causing problems.
[19:24:43] <Empiricist> I don't know how the plugins interact with the main GUI.
[19:25:43] <Empiricist> To be honest, I don't really understand how python is interacting with the core either.
[19:26:21] <Empiricist> And I've never attempted to work on an opensource project like this before.
[19:26:33] <Empiricist> I want to learn the ropes.
[19:27:08] <lynxlynxlynx> the line number you posted is odd, but matches the error
[19:27:22] <lynxlynxlynx> something is not a dict when it is supposed to be
[19:27:35] <lynxlynxlynx> that usually happens with bad data, yes
[19:28:50] <lynxlynxlynx> the main gui can be affected by setting flags, which then take effect the next game loop (EF_PORTRAIT for example) or to some extent via internal global variables (like for settings)
[19:29:20] <lynxlynxlynx> the whole purpose of the guiscript plugin is to expose some of the core to python
[19:29:44] <lynxlynxlynx> which is then used a glue to give life to the data defined guis
[20:02:44] <Empiricist> This is really strange...
[20:02:55] <Empiricist> It's an issue with my setup.
[20:03:26] <Empiricist> I can only run the game from the unix executable in the appications folder.
[20:08:01] --> Yoshimo has joined #gemrb
[20:10:08] <lynxlynxlynx> reverting your changes doesn't fix it?
[20:10:23] <lynxlynxlynx> do macs have any paranoid security policies?
[20:15:19] <Empiricist> They might. I built a small workaround. It's dirty, though.
[20:16:43] <Empiricist> A little sh script in /usr/local/bin that saves the current directory to a variable. Moves to the directory with the unix executable. Runs the Executable. Then it moves back to the original directory.
[20:18:28] <-- Yoshimo has left IRC (Quit: Yoshimo)
[20:18:52] <lynxlynxlynx> the shell does that for you ($OLDPWD)
[20:19:14] <lynxlynxlynx> or implicitly by ~ cd gemrb; gemrb; cd -
[20:20:29] --> brada has joined #gemrb
[20:21:07] <brada> the green tint on graphics was fixed a long while ago
[20:21:23] <brada> so either the #define that controls it isnt set with cmake
[20:21:30] <brada> or 10.6 doesnt need it
[20:21:57] <Empiricist> I see.
[20:22:02] <brada> try setting TARGET_OS_MAC = 1
[20:22:16] <brada> that should be the compiler directive that controlls that iirc
[20:22:35] <brada> or save yurself a headache and use the precompiled binary...
[20:24:09] <brada> i did finally get this smake business to behave
[20:24:20] <brada> to i will need lynx to test/examine this patch
[20:24:34] <Empiricist> It's available on the github?
[20:25:15] <brada> no
[20:25:27] <brada> and im still strugling with the linker paths
[20:25:58] <brada> i need to link to @loader_path/../Frameworks, but cant figure out how to tell that to cmake
[20:27:28] <Empiricist> Well... I've been trying to track down an issue with a bag of holding where the interface freezes as soon as I try to open it.
[20:27:40] <brada> i dont get green buttons here so likely a 10.6 thing
[20:27:49] <brada> or some build snafu on your end
[20:28:58] <Empiricist> Well, the build that was generated by the buildbot works, until you try to open your items; then gemrb stops running.
[20:29:01] <brada> !line 44 of SpriteRenderer.inl if you want to play with it
[20:29:20] <Empiricist> Sprite renderer.
[20:29:29] <Empiricist> Thanks. :)
[20:30:09] <brada> if the buldbot version works without coloring issues then must be a build issue
[20:30:31] <Empiricist> Nope. The buildbot version has the coloring issue too.
[20:30:33] <brada> but i dont get it here so its a build issue with 10.6 or your setup specifically
[20:30:36] <brada> o
[20:30:54] <brada> then must be 10.6 uses RGB and not BGR
[20:31:14] <Empiricist> :O Yep.
[20:31:16] <brada> could be your SDL i guess
[20:31:23] <brada> what version of SDL?
[20:31:35] <Empiricist> 1.2... but I can check more directly...
[20:31:36] <brada> the build has 1.2.15 iirc
[20:32:58] <Empiricist> I have SDL 1.2.15.
[20:33:22] <brada> well
[20:33:26] <brada> this is not good
[20:33:35] <brada> we need to do this at runtime
[20:33:58] <brada> it may not even be 10.6 vs others but hardware dependant
[20:34:49] <Empiricist> RGB is the openGL standard, why would Apple use BGR?
[20:34:50] <brada> ill se what i cant do about dynamically getting those values
[20:35:17] <brada> what makes you say RGB is standard?
[20:35:44] <brada> this isnt opengl anyway
[20:36:19] <Empiricist> openGL is the business standard for 3D graphics, and it uses RGB
[20:36:41] <brada> i have never seen that anywhere in my travels
[20:37:26] <brada> moot anyway since we arent dealing with opengl
[20:38:05] <brada> and my cursory googling suggests you are wrong
[20:38:07] <brada> OpenGL prefers BGR format over RGB
[20:39:35] <Empiricist> Hmm.
[20:39:39] <brada> at least on mac
[20:39:50] <brada> im not going to read much into it atm
[20:40:03] <brada> but apparently something to do with BGR being faster
[20:40:24] <Empiricist> If that's the case, then it's a sensible reason to switch.
[20:40:26] <brada> may depend on ogl version, who knows.
[20:40:33] <brada> it doesnt matter for us anyway
[20:40:49] <Empiricist> Well, my computer is about 6 years out of date anyways.
[20:41:58] <brada> it shouldnt be too hard to get those shifts at run time
[20:42:07] <brada> should fix the problem once and for all
[20:43:31] <Empiricist> Where is SpriteRenderer.inl kept?
[20:47:28] <brada> in the SDLVideo directory iirc
[20:47:49] <brada> you need to reenable your search ;)
[20:48:32] <Empiricist> Yep.
[21:02:22] <brada> yay i think i got the rpath crap working
[21:05:43] <brada> problem being i still dont know how to assemble the bundle without running the install command
[21:22:13] <brada> success
[21:24:34] <Empiricist> Oh?
[21:26:16] <wjp> someday I should un-hardcode those pixel formats
[21:26:41] <brada> wjp: i will try to do it today
[21:26:47] <brada> after i fisish fighting cmake
[21:27:26] <wjp> it would probably be good to keep the most common ones hardcoded/special-cased
[21:27:38] <wjp> but have a generic fallback
[21:28:22] <wjp> at least I can imagine it making a significant difference on less powerful hardware
[21:28:42] <brada> couldnt we just dynamically get them at init once?
[21:28:51] <brada> wouldnt that still be jsut as fast?
[21:29:34] <lynxlynxlynx> but what about gpu hotplugging? :)
[21:29:35] <wjp> I would expect hardcoding them at compile time to be faster
[21:29:51] * wjp volunteers lynxlynxlynx to tackle that issue when it pops up ;-)
[21:29:59] <brada> i only ask why because im curious not cuz i doubt you
[21:30:24] <brada> because it doesnt have to load a variable?
[21:30:24] <wjp> because at compile time the compiler can turn them into shift-by-constant
[21:30:49] <wjp> or in the 32bpp case by byte-juggling instead of bit-juggling
[21:32:14] <wjp> of course to be sure we'd have to benchmark on the relevant hardware
[21:32:30] <wjp> I'm kind of curious how big any effect would be in any case
[21:33:12] <wjp> I should have some numbers lying around from my desktop hardware, but not here
[21:59:13] <-- fizzle has left #gemrb
[22:28:59] <brada> lynx: does this look harmless to the other builds: http://paste.debian.net/9427/
[22:29:00] <Pepelka> debian Pastezone
[22:37:59] <lynxlynxlynx> nothing fishy to my eyes
[22:38:13] <lynxlynxlynx> buildbot it away
[22:42:04] <brada> sweet
[22:43:27] <brada> Empirist: mac cmake should work now, or at least be closer
[22:46:27] <Empiricist> I'll try it.
[22:52:40] <Empiricist> Do you get an effect where the in-game text gets compressed and formatted strangely?
[22:55:28] <brada> no
[22:56:11] <Empiricist> Hmm.
[22:56:21] <Empiricist> Screen Resolution issue, perhaps.
[22:56:24] <brada> not with the information you gave anyway
[22:56:28] <brada> i doubt it
[22:56:39] <Empiricist> It's still building.
[22:56:41] <brada> can you be more specific?
[22:57:49] <Empiricist> Sure. Say you click on the character stat button on the gui... then you look on the right hand side with all of the text, and you have some text superimposed on top of other text.
[22:58:08] <Empiricist> The item descriptions do the same things.
[22:58:39] <brada> are you using a ttf font?
[22:59:25] <Empiricist> It's gone in the new git version. It just finished building.
[22:59:57] <brada> or it only happens after being "triggered"
[23:00:08] <brada> cuz nobody changed anything with the font system
[23:02:38] <Empiricist> Brilliant.
[23:02:43] <Empiricist> It works without a hitch.
[23:02:49] <Empiricist> No need to hack around.
[23:02:56] <Empiricist> You fixed it. :)
[23:03:35] <Empiricist> What is the best way to learn how the plugins interact with the core?
[23:05:42] <brada> probably PluginLoader.cpp
[23:05:57] <brada> or look at the specific plugin
[23:06:28] <brada> most are subclasses of abstract base classes that exist in core
[23:07:18] <Empiricist> ls
[23:08:14] <lynxlynxlynx> for an empiricist you believe a lot of what we say
[23:09:33] <lynxlynxlynx> brada: my build survived :)
[23:09:44] <brada> woot
[23:10:25] <lynxlynxlynx> almost got the big iwd2 problem fixed, but it's too late now
[23:10:35] <lynxlynxlynx> just have to find a proper way to disable actors tommorow
[23:10:45] <brada> cool
[23:11:11] <lynxlynxlynx> mhm
[23:12:59] <Empiricist> I didn't build the engine. I assume that you know what you are talking about until proven otherwise. :)
[23:13:45] <Empiricist> I'm sorry, I hadn't intended to annoy you.
[23:14:46] <lynxlynxlynx> you haven't.
[23:14:58] <lynxlynxlynx> not sure about brad though ;)
[23:15:22] <Empiricist> :)
[23:15:46] <brada> im just glad the problem is fixed :p
[23:16:01] <brada> you brought to light at least 3 issues
[23:16:06] <brada> so thats always good
[23:18:16] <Empiricist> I'd like to be able to see the issues then fix them, then bring the solution to light. :)
[23:27:25] <brada> you would have quite a bit of learning to do for that ;)
[23:27:44] <brada> IE and its formats alone take a long time to get a handle on
[23:27:50] <brada> plus all the diffrent languages
[23:28:18] <Empiricist> I can speak two of the main ones.
[23:28:23] <Empiricist> c++ and python
[23:28:52] <Empiricist> I'm kind of iffy on OOP.
[23:29:35] <Empiricist> So far I've only seen: c++, python, and objective c.
[23:29:49] <Empiricist> *used in gemrb
[23:30:48] <brada> cmake
[23:30:55] <brada> not a language per se
[23:31:12] <brada> then the internal scripting language
[23:31:26] <Empiricist> 2da?
[23:31:30] <brada> no
[23:31:35] <brada> IE script i guess :p
[23:31:51] <Empiricist> CLUAConsole?
[23:32:07] <brada> im sure that would use IE script
[23:32:13] <brada> we dont have that tho
[23:32:22] <brada> we have an equivalent that used python
[23:32:42] <brada> but IE script is still used by the games to control actions within the game
[23:32:51] <Empiricist> http://www.gemrb.org/wiki/doku.php?id=guiscript:console
[23:32:52] <Pepelka> guiscript:console [GemRB wiki]
[23:38:14] <brada> thats the one
[23:38:23] <brada> its all python
[23:39:14] <brada> im pretty sure you can do a ton more with our console than the original
[23:39:23] <brada> we have nice shortcuts too
[23:39:44] <brada> like mta("ARXXXX") instead of having to write out MoveToArea
[23:40:40] <Empiricist> How stable is gemrb on ubuntu?
[23:40:52] <brada> i assume gemrb is equally stable all around
[23:41:09] <brada> the only exceptins may be mobile platforms
[23:41:15] <brada> due to limited memory
[23:41:49] <Empiricist> Who knows the most about the inner workings of gemrb?
[23:42:04] <lynxlynxlynx> CLUAConsole used a stripped down lua
[23:42:48] <lynxlynxlynx> brada: also resrefs are case insensitive, so ar2000 works too
[23:42:51] <Empiricist> C*LUA*Console
[23:43:04] <brada> lynx: didnt know that
[23:43:13] <brada> is that true even on CS ffs?
[23:43:30] <lynxlynxlynx> hmm?
[23:43:46] <lynxlynxlynx> we're not missing out by not having it
[23:43:46] <brada> lynx is probably the most knowladgeable of the people that are here frequently
[23:45:15] <Empiricist> wjp seems to know quite a lot too.
[23:45:39] <brada> about the video stuff and c++ in general
[23:45:52] <brada> so really it depends on what you want to know
[23:46:49] <Empiricist> Are there any terrain, character, animation generators that come with the engine?
[23:47:14] <lynxlynxlynx> no
[23:47:24] <lynxlynxlynx> dltcep is kinda like that
[23:47:37] <Empiricist> What does dltcep do?
[23:47:49] <lynxlynxlynx> a whole lot
[23:48:08] <Empiricist> dragon lance total conversion editor pro
[23:49:36] <Empiricist> Does the dragonlance total conversion project have a pretty large following, or is it pretty much dead?
[23:50:11] <brada> its what they use for bgee so...
[23:50:11] <lynxlynxlynx> completely dead
[23:50:23] <brada> dead?
[23:50:28] <lynxlynxlynx> dltc
[23:50:29] <brada> you mean dragonlance?
[23:50:37] <lynxlynxlynx> the editor just retained the name
[23:50:40] <brada> yeah
[23:51:14] <Empiricist> It must have been used for the Glory of Istar mod
[23:53:16] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:54:22] <brada> its used for a lot of mods
[23:55:57] <Empiricist> If I am to alter any of the python script, would it be better to alter the script in the gemrb.app/Contents/Resources/GUIScripts?
[23:56:40] <Empiricist> Will the changes take effect immediately, or would it cause problems for some of the plugins?
[23:57:02] <Empiricist> Will I need to recompile the plugins every time I alter the python scripts?
[23:59:01] <brada> you dont need to recompile after editing python scripts