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

Archive Today Yesterday Tomorrow
GemRB homepage


[01:32:48] * pupnik dunnos
[01:48:17] <-- Gekz has left IRC (Read error: Connection reset by peer)
[01:50:19] --> Gekz has joined #GemRb
[03:44:21] --> raevol has joined #GemRb
[05:58:19] <-- raevol has left IRC (Read error: Connection reset by peer)
[06:22:58] --> puphome_ has joined #GemRb
[06:23:08] --> pupnik_ has joined #GemRb
[06:24:31] <-- puphome has left IRC (Read error: Operation timed out)
[06:26:23] <-- pupnik has left IRC (Ping timeout: 260 seconds)
[07:06:42] --> raevol has joined #GemRb
[07:07:26] --> lynxlynxlynx has joined #GemRb
[07:07:26] --- ChanServ gives channel operator status to lynxlynxlynx
[08:01:13] <-- Gekz has left IRC (Ping timeout: 252 seconds)
[08:02:58] --> Gekz has joined #GemRb
[08:07:23] <-- Gekz has left IRC (Read error: Connection reset by peer)
[08:08:16] --> Gekz has joined #GemRb
[08:25:39] <fuzzie> tomprince_loki: no, we should definitely not sort the actions on load
[08:25:52] <fuzzie> and i have talked about this on irc before :P
[08:26:08] <-- raevol has left IRC (Quit: Leaving.)
[08:26:59] <fuzzie> but it is probably about instants in dialogue, which does need some thought, but also a lot of work, and messaging needs fixing first
[08:27:09] <fuzzie> otherwise you break bg2 even further
[08:28:07] <fuzzie> ok, no, those actions are not instants
[08:29:54] <fuzzie> don't see why it wouldn't workthough
[08:30:50] <fuzzie> oh, right, because SetGlobal is an instant instant
[08:31:36] <fuzzie> but no, we should be handling them in order, because there are instants which can affect the queued scripts
[08:33:50] <fuzzie> damn, i just realised that the stupid dead-actor handling is yet another messaging bug
[08:41:34] <fuzzie> but the instants stuff also differs oddly between games, not sure how much devsin has said, but there are old threads about it.
[08:44:38] <fuzzie> am still resisting opening any of these binaries in IDA Pro, is an endless timesink.
[08:46:54] <fuzzie> oops, meeting is at 11 and not 11:15. *runs*
[08:48:52] <-- |Cable| has left IRC (Remote host closed the connection)
[09:25:26] <-- Gekz has left IRC (Read error: Connection reset by peer)
[09:26:09] --> Gekz has joined #GemRb
[10:07:54] <-- Gekz has left IRC (Read error: Connection reset by peer)
[10:14:16] --> Gekz has joined #GemRb
[10:32:29] <-- Gekz has left IRC (Read error: Connection reset by peer)
[10:32:55] --> Gekz has joined #GemRb
[10:42:58] <-- Gekz has left IRC (Read error: Connection reset by peer)
[10:43:21] --> Gekz has joined #GemRb
[11:19:40] <pupnik_> how much did that ebay pandora sell-for?
[11:19:42] <pupnik_> 580 pounds!!!!
[11:19:44] <pupnik_> http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=200479755785
[11:31:53] <-- tomprince_loki has left IRC (Ping timeout: 276 seconds)
[11:32:46] --> tomprince_loki has joined #GemRb
[11:42:42] <pupnik_> i keep wondering if tomprince_loki worked at loki games
[13:22:21] <tomprince> No.
[13:22:59] <pupnik_> ah k
[13:23:00] <pupnik_> ty
[13:23:14] <tomprince> loki is just the name of one of my computers.
[13:24:46] <-- Gekz has left IRC (Quit: Leaving)
[13:24:54] --> Gekz has joined #GemRb
[13:27:46] <pupnik_> $1000 bid for an openpandora. you seeing this nokia? http://cgi.ebay.com/Pandora-Handheld-One-first-OpenPandora-/320542763412?cmd=ViewItem&pt=Video_Games&hash=item4aa1d66994
[13:35:22] <Gekz> whut
[13:35:35] <Gekz> 26 bids?!
[13:36:42] --> anthiste has joined #GemRb
[13:37:22] <anthiste> hey guys, I'm having trouble with [KEYImporter]: Cannot open Chitin.key, any help please?
[13:37:42] <fuzzie> chitin.key is part of the game data
[13:37:52] <anthiste> fuzzie, the file exists an is readable
[13:38:08] <fuzzie> so maybe you don't have CaseSensitive=1 and it is not the right capitalisation
[13:38:15] <fuzzie> or maybe you have the wrong GamePath set
[13:38:34] <anthiste> CaseSensitive is 1, im pretty sure gamepath is correct
[13:38:53] <anthiste> I renamed CHITIN.KEY to chitin.key
[13:40:23] <tomprince> Are you using 0.6.0?
[13:40:28] <fuzzie> if you're using the latest code then it should show the path it's looking at in the line before that
[13:40:52] <fuzzie> i forget if 0.6.0 shows the paths anywhere
[13:41:06] <anthiste> [Core]: Initializing KEY Importer...[KEYImporter]: Opening /home/anthiste/.wine/drive_c/Program\ Files/Black\ Isle/Torment/chitin.key...[ERROR]
[13:41:06] <anthiste> [KEYImporter]: Cannot open Chitin.key
[13:41:06] <anthiste> [ERROR]
[13:41:25] <anthiste> /home/anthiste/.wine/drive_c/Program\ Files/Black\ Isle/Torment/chitin.key
[13:41:28] <anthiste> exists
[13:41:31] <anthiste> I just ls'ed it
[13:41:32] <fuzzie> the \s shouldn't be there
[13:41:53] <anthiste> k let me try
[13:41:54] <fuzzie> in the shell it'll work because it escapes the spaces, but it's probably not a valid path :)
[13:42:03] <anthiste> :) ty il have a look
[13:42:15] <fuzzie> maybe gemrb should make loud squawking sounds when you have escapes there
[13:43:26] <anthiste> yay
[13:43:28] <anthiste> [ResourceManager]: Searching for gemrb.ini...[ERROR]
[13:43:28] <anthiste> [ERROR]
[13:43:28] <anthiste> Cannot Load INI
[13:43:30] <anthiste> but il fix that
[13:43:36] <anthiste> thanks man
[13:43:54] <anthiste> I might right up a patch that checks for escapes quickly :)
[13:43:57] <fuzzie> that is probably the GemRBPath :)
[13:44:22] <fuzzie> that would probably be a good idea, check for "\ " or something
[13:44:58] <wjp> that shouldn't cause too many false positives I guess
[13:46:14] <fuzzie> that is admittedly assuming that there are no completely insane users
[13:46:34] <fuzzie> but i don't think that is entirely unreasonable
[13:48:03] <anthiste> fuzzie, you can just issue a warning "you have escape characters in your path, is this intentional"
[13:48:15] <anthiste> oh and where is gemrb.ini supposed to go?
[13:48:18] <fuzzie> i would prefer the loud squawking sounds :(
[13:48:37] <anthiste> i found /home/anthiste/gemrb/gemrb/override/pst/gemrb.ini
[13:48:40] <fuzzie> the gemrb.ini is in gemrb's override directory, which needs to be in the GemRBPath directory
[13:48:55] <fuzzie> so you want to set GemRBPath to /home/anthiste/gemrb/gemrb/ i guess :)
[13:48:59] <anthiste> GemRBPath = where exe is?
[13:49:09] <anthiste> im running from /opt/bin
[13:49:17] <anthiste> all other stuff is in /opt/*
[13:49:31] <anthiste> libs etc are found np
[13:49:37] <fuzzie> if you installed it, then it'll be in share/gemrb i think
[13:50:45] <anthiste> bleh I dunno where to paste the ini
[13:50:48] <tomprince> If you used make install, with gemrb from git, it should default to the right thing.
[13:51:08] <anthiste> GamePath=/home/anthiste/.wine/drive_c/Program Files/Black Isle/Torment
[13:51:12] <fuzzie> but you have to fix the config path, it won't work if you just copy the ini around
[13:51:15] <anthiste> ah
[13:51:43] <fuzzie> because the ini just points at more things
[13:53:40] <anthiste> GemRBPath=/opt/bin (thats where im running from), this right?
[13:54:00] <tomprince> /opt/share/gemrb
[13:55:12] <anthiste> and then place gemrb.ini in the same directory, ie /opt/bin?
[13:55:29] <wjp> no, don't move stuff to /opt/bin
[13:55:30] <lynxlynxlynx> gemrb.ini is already where it is supposed to be
[13:55:49] <tomprince> Are you using GemRB from git, and did you do make install?
[13:55:49] <wjp> the "where exe is" bit is wrong in general
[13:55:58] <anthiste> I might try reinstall
[13:56:03] <lynxlynxlynx> gemrb.ini files are our files, gemrb.cfg is the one for user configuration
[13:56:30] <anthiste> I used cmake to install, from the wiki it says
[13:56:52] <anthiste> ou can pass -DLAYOUT with “home” or “opt” to change the general layout and -DPREFIX to change the install path prefix
[13:57:15] <anthiste> so I'd cmake -DLAYOUT=/opt -DPREFIX=/opt ?
[13:57:50] <lynxlynxlynx> -DLAYOUT=opt
[13:58:09] <tomprince> If you did that, don't set the GemRB path in the cfg file.
[13:59:39] <anthiste> it worked :O
[13:59:41] <anthiste> guys
[13:59:47] <anthiste> this is some amazing softwaer
[14:00:02] * anthiste thanks developers
[14:01:20] <tomprince> We should really remove (GemRB|GUIScript|Plugin|GemRBOverride)Path from the sample configs.
[14:01:53] <lynxlynxlynx> i disagree, it is handy for distributors
[14:02:16] <anthiste> well I'll work on a patch, least I can do
[14:02:29] <tomprince> How is it handy for distributors.
[14:03:03] <tomprince> And I am not suggesting removing the options. At the very least make it clear that most people won't need them set.
[14:03:12] <fuzzie> because your hardcoded paths aren't good for everyone
[14:03:16] <lynxlynxlynx> they move the files in all kinds of wierd places and if they provide a default config, it needs to set these values for gemrb to start
[14:03:34] <lynxlynxlynx> # You probably do NOT want to specify this! #
[14:03:38] <fuzzie> but the lines in the config files should be commented out
[14:03:40] <-- puphome_ has left IRC (Quit: leaving)
[14:03:42] <lynxlynxlynx> it's hard to be clearer
[14:03:50] <fuzzie> as long as it works from the build dir by default
[14:04:46] <lynxlynxlynx> you need to set PluginsPath
[14:04:51] <fuzzie> and i guess the 'Cache Path' one should be higher up
[14:05:08] <tomprince> and save path.
[14:05:18] <fuzzie> why the save path?
[14:05:33] <lynxlynxlynx> GemRBPath too
[14:05:54] <tomprince> GemRBPath?
[14:06:59] <fuzzie> i think i disagree with both of those :P GemRBPath should be picked up from where the executable finds itself, or the current dir, and the save path is going to be where the game data is for almost everyone who actually uses gemrb, right?
[14:07:14] <tomprince> fuzzie: Why wouldn't the hardcoded paths work for distributors? Unless they split the GUIScripts from the GemRBOverride, they should just be able to specify the weird places.
[14:08:03] <fuzzie> tomprince: because you bake them into the executable, righT?
[14:08:09] <tomprince> And yes, being relocatable would be good.
[14:08:14] <fuzzie> so they don't work for any distribution system which doesn't hard-code the prefixes
[14:08:36] <fuzzie> at least, they didn't last time i tried
[14:08:51] <tomprince> True.
[14:09:17] <fuzzie> so basically it works only for the people who aren't going to fiddle with any of the paths anyway :)
[14:09:19] <-- Gekz has left IRC (Changing host)
[14:09:19] --> Gekz has joined #GemRb
[14:09:31] <tomprince> Well, most linux distributions do hard-code the prefix.
[14:09:36] <fuzzie> although i can't speak for maemo, which does weird weird things
[14:10:00] <fuzzie> most linux distributions only work on x86 where you can just run wine anyway, to be fair :P
[14:10:32] <Gekz> maemo does normal normal things
[14:10:40] <-- anthiste has left IRC (Quit: Leaving)
[14:10:48] <tomprince> What does weird things?
[14:10:54] <fuzzie> maemo
[14:11:15] <fuzzie> it splits the libraries out into some executable partition and then creates a bunch of unnecessary symlinks
[14:11:59] <tomprince> But the files don't move around once they are installed?
[14:12:02] <fuzzie> although i'm sure it is possible to get their packaging system to just make cmake put the libraries in the right place, it became uninteresting to me because it's going to get replaced anyway
[14:12:21] <fuzzie> sure, i'm going off on a tangent here, maemo already works fine
[14:12:45] <fuzzie> they just make sure things are symlinked into the right places
[14:13:23] <lynxlynxlynx> i was refering to what is currently needed to run from the build dir
[14:13:24] <tomprince> I think the only place that hardcoded paths wouldn't work if for binary distributions meant to be installed in your home directory, or some such.
[14:13:41] <fuzzie> lynxlynxlynx: ah.
[14:13:56] <fuzzie> tomprince: well, more to the point: binary distributions meant to be installed on removable media
[14:14:29] <fuzzie> you don't have huge hard drives for your internal storage
[14:14:42] <tomprince> True.
[14:15:38] <tomprince> Like I said, I don't think we should remove the options, just remove them from the sample config, since most people installing from source won't need them.
[14:16:18] <fuzzie> maybe "GemRB.cfg.sample" vs "GemRB.cfg.sample.dist"
[14:16:31] <fuzzie> but i agree with lynx that you shouldn't remove the examples entirely
[14:16:40] <fuzzie> and i think it is difficult to say which options to remove anyway
[14:16:44] <pupnik_> to make gemrb work well on pandora, support local paths for SD media
[14:17:01] <pupnik_> and N900 etc
[14:17:09] <fuzzie> i would consider the save path to be a confusing option which should also go, if you're going to simplify the files to the point where you don't think people will read "don't change this" comments
[14:17:32] <fuzzie> and almost all the other options too
[14:21:43] <fuzzie> annoying how the resolution one can't go
[14:23:25] <tomprince> Could we have a default for that in gemrb.ini?
[14:23:52] <fuzzie> no
[14:24:14] <fuzzie> because i think *most* gemrb users are using widescreen modded data, given the usual bug reports
[14:24:31] <fuzzie> at least a sizable amount
[14:25:04] <fuzzie> and there's no reliable way to get the resolution from the data
[14:26:16] <fuzzie> even if there was, the only sane default would be the tiny resolution everyone'd want to change at once
[14:26:35] <fuzzie> but i guess { game path, screen resolution } is a reasonable minimal set of config?
[14:26:39] <Gekz> fuzzie: cant you just code in the usual user error fail parts
[14:26:46] <Gekz> like "they fucked up, try default"
[14:27:18] <fuzzie> sure, but it'd be gemrb developer fail, really :)
[14:27:24] <tomprince> game type.
[14:27:44] <tomprince> Although it would be good to deduce that from the data, if possible.
[14:27:50] <fuzzie> well, you can auto-detect game type, i'm sure, even if we don't do it now
[14:28:36] <fuzzie> but then the CachePath is a problem, as usual: is there a sane default?
[14:28:57] <fuzzie> so far we worked out that ./Cache is no good, /tmp is no good and GemRBPath is no good
[14:29:06] <tomprince> Also, guienhancement and cheatkeys.
[14:29:17] <tomprince> $GamePath/Cache ?
[14:29:30] <fuzzie> but if you get rid of SavePath then yes, i guess you can assume GamePath is writable
[14:30:12] <fuzzie> and you want Fullscreen, i guess
[14:30:22] <fuzzie> i forget if Bpp was important anywhere
[14:32:31] <lynxlynxlynx> the sound stuff should be implemented in the games
[14:33:59] --> anthiste has joined #GemRb
[14:36:16] <anthiste> guys are weidu mods supported alongside gemrb?
[14:37:08] <tomprince> Yes.
[14:37:26] <anthiste> planescape runs fine, but the UI is scrambled and I cant see dialogue
[14:37:49] <anthiste> think any resolution-related weidu stuff can help, or is it probably a gemrb issue?
[14:39:11] <Gekz> I'd blame fuzzie
[14:39:22] <Gekz> she touches PsT inappropriately
[14:39:23] <Gekz> :P
[14:39:37] <tomprince> You can only set the resolution to something supported by the game data.
[14:39:53] <tomprince> So either something supported by the original game, or something using the widescreen mod.
[14:40:14] <anthiste> so I should run the widescreen-mod, set to 1600x900 and specifiy 1600x900 for gemrb as well?
[14:40:34] <tomprince> Yes.
[14:40:36] <anthiste> ahah
[14:40:57] <anthiste> must I install the UI-mod after widescreen or does gemrb take care of that?
[14:42:21] <tomprince> I don't know off the top of my head. It will probably mostly work without the ui-mod, but the easiest thing to do is simply try it.
[14:42:56] <anthiste> ty tomprince
[14:46:29] <lynxlynxlynx> what's the ui mod?
[14:48:04] <tomprince> Ghostdog's UI mod. I think it resizes a bunch of the mos files.
[14:48:08] <fuzzie> replaces the fonts/CHUs/etc with ones suited for the higher resolutions
[14:48:41] <fuzzie> it seemed to work fine with gemrb last time i tried
[14:53:03] <lynxlynxlynx> cool
[15:01:03] <tomprince> fuzzie: So the instants don't get evaluated first?
[15:18:00] <anthiste> [Core]: Initializing KEY Importer...[KEYImporter]: Opening /home/anthiste/.wine/drive_c/Program\ Files/Black Isle/Torment/chitin.key...(Backslashes detected in path. If you are running under linux, do not escape spaces in your GamePath) [ERROR]
[15:18:00] <anthiste> [KEYImporter]: Cannot open Chitin.key
[15:18:00] <anthiste> [ERROR]
[15:18:08] <anthiste> hows that? should I submit it?
[15:18:59] <Gekz> Backslashes detected in path. If you are running under linux, do not escape spaces in your GamePath
[15:19:08] <Gekz> Program\ Files
[15:19:15] <Gekz> McCough
[15:19:33] <anthiste> Gekz, I just coded that and added the backslash as a test?
[15:19:49] <Gekz> Oh.
[15:19:51] <anthiste> :P
[15:19:53] <Gekz> then I am a troll.
[15:27:32] <anthiste> is there any sort of system to share patches or can I pastebin it here?
[15:32:50] <tomprince_loki> Either put a fork on github, or post the patch somewhere.
[15:35:24] <lynxlynxlynx> pastebin is fine, as long as it supports a direct download
[15:35:51] <wjp> we also have a patch tracker on sourceforge
[15:37:08] <-- Gekz has left IRC (Read error: Connection reset by peer)
[15:37:43] --> Gekz has joined #GemRb
[15:40:31] <anthiste> http://pastebin.com/vnkx9z01
[15:43:55] <tomprince_loki> I wonder if that check would be better in ResolveFilePath?
[15:45:14] <tomprince_loki> That wouldn't catch people who put backslashes in the relative paths, but it would catch all the other paths from the config, and not have duplicates.
[15:45:22] <anthiste> well is resolvefilepath allowed to output warnings?
[15:45:29] <anthiste> or is it a plain helper functions
[15:45:55] <anthiste> or can anything anywhere display debug info if it needs to?
[15:47:09] <tomprince_loki> Right now, yes. Although cleaning up the output is on the todo list.
[15:48:06] <tomprince_loki> Anyway, the only place that calls ResolveFilePath is Interface::LoadConfig. And so output should be fine from it.
[15:51:40] <anthiste> hmm its a really simple patch, you guys gna do it or must I whip it up quick?
[16:00:09] <lynxlynxlynx> not me, busy
[16:22:36] <-- anthiste has left IRC (Remote host closed the connection)
[16:39:30] <-- Gekz has left IRC (Quit: This computer has gone to sleep)
[16:50:30] <fuzzie> tomprince: relative paths in what sense?
[16:50:56] <fuzzie> as long as you catch all the possibilities for GamePath it seems like it would be enough
[16:52:11] <fuzzie> and it seems that ResolveFilePath always gets called for that?
[17:00:43] <tomprince_loki> I meant the data and override settings that nobody should be touching.
[17:02:22] <tomprince_loki> Since those don't go through ResolveFilePath, and those are the only paths from the config which don't. I don't thinkit is an issue as I said, I was justing being pedantic. :)
[17:05:14] <fuzzie> ah, ok
[17:05:34] <fuzzie> just wondered if you meant things like "./gamedata/icewinddale" :)
[17:07:13] <tomprince_loki> No.
[17:27:22] --> anthiste has joined #GemRb
[17:30:57] <-- pupnik_ has left IRC (Ping timeout: 245 seconds)
[17:36:20] <-- anthiste has left IRC (Quit: Leaving)
[17:37:18] --> |Cable| has joined #GemRb
[19:21:12] --> kingron has joined #GemRb
[19:41:28] --> Maighstir has joined #GemRb
[20:17:10] <Maighstir> regarding the config paths, one that annoys me a bit is the save path, I would like to define the whole save path instead of being required to have <my_chosen_path>/save, because I may decide that a better file structure for me is <path_with_savegames_for_all_my_games>/baldursgate
[20:18:00] <Maighstir> also, "\" is common on Windows (though / can often be used as well), so don't rely on it being an escape character there
[20:19:23] <fuzzie> this is why it tests for "\ ", and not "\" :)
[20:20:43] <Maighstir> right, I only skimmed through the log quickly
[20:30:48] <tomprince_loki> Also, I didn't look to closely at the patch, but it should probably only say something if it doesn't find anything.
[20:31:10] <tomprince_loki> That is, if the file doesn't exist.
[20:42:03] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[20:56:13] <-- kingron has left IRC (Quit: Leaving)
[21:27:12] --> budlust has joined #GemRb
[21:30:26] --> grofit has joined #GemRb
[21:30:32] <grofit> oh wow lots of people in here
[21:31:16] <grofit> has anyone got a few mins spare to answer some questions about building gemrb on ubuntu?
[21:31:44] <wjp> we'll try :-)
[21:32:06] <grofit> lol bear with me then
[21:32:12] <grofit> first off ive never really used linux before
[21:32:36] * Lightkey gets the popcorn
[21:32:37] <grofit> so im sure that sends alarm bells ringing, but dont panic :D
[21:32:47] <grofit> ive got a clone from git
[21:32:56] --> pupnik has joined #GemRb
[21:33:09] <grofit> and it seems that all the libraries i need are all installed
[21:33:15] <grofit> *Seems* being the key word there
[21:33:25] <grofit> ive followed the tutorial
[21:33:42] <grofit> but whenever i try to run the autogen.sh it just gives errors
[21:33:47] <grofit> (which i can list if needed)
[21:34:24] <grofit> i was trying to get it all running in windows, but it seemed like a hassle trying to install lots of linux related libs, so i thought i would just install linux
[21:34:43] <grofit> anyway so im at a bit of a loss as to what to do
[21:34:54] <grofit> currently i just want to get it to build so i can see it working
[21:35:06] <wjp> most libraries will be split up into two packages in ubuntu: the library and a 'dev' package for the library
[21:35:16] <grofit> then want to see how hard it is to port over to Android (using NDK and android specific versions of Python etc)
[21:35:22] <grofit> but baby steps :D
[21:35:32] <Lightkey> grofit: http://pastebin.com/ if you want to paste something
[21:35:35] <grofit> yeah the dev ones seem to be installed for everything
[21:35:49] <wjp> what does autogen.sh complain about?
[21:36:05] <grofit> one moment
[21:36:36] <wjp> hm, aside to others if they're listening: is cmake the preferred build system already?
[21:37:06] <grofit> http://pastebin.com/raw.php?i=mMgzcKT8
[21:37:11] <grofit> sorry never used paste bin, that should work
[21:37:35] <fuzzie> wjp: yes, but i think most people are still using automake
[21:37:47] <grofit> i installed cmake in windows and it seemed to be ok once i set up VC10 native compiler, but then it wanted lots of other libs installed
[21:37:58] <wjp> that's an interesting list of error messages
[21:37:59] <Lightkey> grofit: btw the libraries are not "linux related", more like indie developer related :p
[21:38:08] <grofit> and as i use my windows install for ALOT of .net/windows development i didnt want to bastardise it too much
[21:38:21] <wjp> try 'bash autogen.sh' instead
[21:38:32] <grofit> ok one mo
[21:38:33] <fuzzie> do we depend on many weird libraries?
[21:38:49] <grofit> to me everything is weird, ive lived in a windows bubble for many years
[21:38:52] <fuzzie> SDL/OpenAL are pretty game developer specific i guess
[21:39:14] <Lightkey> come to think of it, only SDL is not widely used on Windows
[21:39:19] <grofit> ah is aclocal a library i need to get?
[21:39:36] <grofit> SDL/Python/OpenAL are all fine
[21:39:42] <grofit> they are easy to find the versions etc
[21:40:02] <grofit> its just the other things that confuse me
[21:40:05] <fuzzie> i'm just wondering if it wanted anything spectacularly weird on Windows :)
[21:40:09] <grofit> whole *make* thing :D
[21:40:19] <fuzzie> for Linux, you probably want to install 'cmake' and then follow the cmake instructions
[21:40:23] <Lightkey> like, Civilization IV is practically all done in Python
[21:40:36] <grofit> oh cool, not much of a python fan :(
[21:40:40] <wjp> yeah, cmake is probably easiest nowadays
[21:40:43] <fuzzie> yes, and OpenAL was obviously designed for Windows
[21:41:01] <wjp> (but for future reference: you'll need autoconf, automake, libtool for the non-cmake autogen.sh route)
[21:41:10] <Lightkey> fuzzie: by a Linux porting house
[21:41:14] <Lightkey> ;-)
[21:41:21] <wjp> (aclocal should be part of one those three packages, probably automake)
[21:41:43] <fuzzie> Lightkey: still :)
[21:41:44] <grofit> do i need a specific version of it?
[21:41:56] <fuzzie> poor Loki :(
[21:42:09] <wjp> hm, whichever version ubuntu has as default should probably be fine
[21:42:14] <fuzzie> the cmake in any ubuntu should be fine
[21:43:07] <grofit> ok let me get cmake
[21:43:13] <grofit> as i just had make and automake installed
[21:43:32] <grofit> has anyone started an Android port of this btw?
[21:43:42] <fuzzie> i don't think so
[21:44:16] <fuzzie> i looked into it enough to realise that the NDK doesn't come with much stuff
[21:44:31] <grofit> oh doesnt it :(
[21:45:05] <grofit> whats it missing *roughly*?
[21:45:23] <fuzzie> a C++ library, for a start
[21:45:44] <grofit> do you mean STL?
[21:45:47] <grofit> or am i missing something
[21:45:55] <fuzzie> and iostreams and etc
[21:46:00] <grofit> i thought you could just run C++ on it, maybe without any of the additional libs
[21:46:04] <grofit> ah
[21:46:08] <grofit> std
[21:46:42] <fuzzie> but i had a look at google and there are a lot of forum threads etc with instructions on how to use third-party libraries instead, and etc
[21:46:46] <grofit> is there no way to just make *stand in* methods for them (i could be talking outta my arse)
[21:46:53] <fuzzie> i just haven't found the time to look into it
[21:46:54] <grofit> oh cool so there is hope
[21:47:18] <grofit> i doubt i will get that far, as ive never developed on linux and not used the NDK :D
[21:47:46] <fuzzie> i'm not sure how dependant we are on STL
[21:48:24] <fuzzie> but the container classes are used all over, so it would probably be more work to try patching that up
[21:48:25] <grofit> on a side note
[21:48:37] <grofit> is the autogen.sh the first thing to get working?
[21:48:49] <grofit> or should i be running make.am or something before this
[21:49:02] <grofit> i was tempted to try and port it into mono
[21:49:05] <fuzzie> it is really easier to just follow the cmake instructions :)
[21:49:09] <grofit> saying that and doing it are 2 COMPLETELY different things
[21:49:13] <Maighstir> you either use autogen.sh OR cmake, not both
[21:49:15] <grofit> but i fancied a really challenging project
[21:49:28] <grofit> ah ok so what do i do for Cmake
[21:49:31] <grofit> its apparently installed
[21:49:34] <fuzzie> the trouble with building C++ into mono is that it's not very useful :(
[21:49:44] <grofit> no no i mean writing it in C#
[21:50:01] <fuzzie> oh, that is a fun project if you have a few years of unemployment, maybe :)
[21:50:01] <grofit> and just using unsafe areas with marshalling if needed
[21:50:07] <fuzzie> there are cmake instructions on the wiki, i think
[21:50:20] <fuzzie> which is probably better than asking me and getting wrong answers
[21:50:21] <grofit> most of the hard work is already done by you guys
[21:50:44] <wjp> it should be just 'cmake', 'make', right?
[21:51:33] <grofit> what do you guys use for the rendering? OGL?
[21:51:44] <grofit> lol sorry ignore me
[21:51:46] <grofit> SDL
[21:51:57] <grofit> which is OGL under the hood right?
[21:52:01] <fuzzie> opengl is probably much better for embedded platforms
[21:52:07] <wjp> no, we use software rendering currently
[21:52:41] <wjp> the upcoming sdl will likely support OpenGL as a 2D rendering backend, but not the 1.2.x series yet
[21:53:20] <wjp> opengl is one of those "if we have a spare month" projects on the todo list :-)
[21:54:32] <grofit> oh right
[21:54:46] <grofit> how many devs you got on the project?
[21:54:58] <grofit> OH OK progress
[21:55:00] <grofit> cmake .
[21:55:06] <tomprince> Probably cmake . -DCMAKE_INSTALL_PREFIX="/path/to/install"
[21:55:08] <grofit> gives me lots of wonderful stuff
[21:55:11] <fuzzie> i was surprised that paletted images were well-supported by opengl at all
[21:55:37] <grofit> its all just unsigned ints fudged into memory isnt it? surely it would be happy with that
[21:55:49] <grofit> i havent done much OGL for years and even then i was a student
[21:56:08] <fuzzie> well, it's byte indexes into a lookup table
[21:56:15] <fuzzie> not at all supported by modern high-end hardware
[21:56:46] <grofit> oh 8bit bmps
[21:56:55] <Lightkey> but that first problem with autogen.sh would mean it uses bashisms?
[21:56:57] <grofit> could you not just write a layer to convert it?
[21:57:16] <fuzzie> embedded devices can't afford the 4x increase in texture size
[21:57:21] <grofit> are all bg resources 8bit bmps?
[21:57:23] <grofit> sorry for all the questions
[21:57:25] <fuzzie> which is why paletted images are supported, i suppose
[21:57:45] <fuzzie> and no, there are full-colour images too :)
[21:57:52] <grofit> oh lovely :D
[21:58:03] <grofit> why would they be 4x larger?
[21:58:09] <wjp> int vs byte
[21:58:10] <grofit> oh you mean RGBA
[21:58:13] <wjp> yes
[21:58:24] <grofit> i wouldnt say it would be too much of a worry
[21:58:36] <grofit> but i dont know what sort of resource limitations the devices have
[21:58:40] <fuzzie> you'd be surprised :( it has been a problem on the iPhone, which just converts everything to ints
[21:59:00] <grofit> bugger
[21:59:19] <fuzzie> means you have to be much less lazy about clever texture loading
[21:59:33] <fuzzie> and gemrb is incredibly lazy at the moment :)
[21:59:41] <grofit> oh another side note
[21:59:53] <grofit> how did you guys go about making (at a high level) an open source version of infinity
[22:00:09] <wjp> our memory requirements are only a few orders of magnitude above the originals :-)
[22:00:09] <grofit> as you dont have access to infinity source right
[22:00:18] <Lightkey> it is well documented
[22:00:24] <grofit> it is?
[22:00:32] <wjp> up to a point
[22:00:40] <wjp> there's a very active modding community
[22:00:50] <Lightkey> by the modding community, yes
[22:00:58] <grofit> ah
[22:01:08] <Lightkey> well documented compared to other closed source engines ;-)
[22:01:08] <grofit> how do they get info on the engine
[22:01:17] <wjp> poke at it and see what happens, basically :-)
[22:01:19] <fuzzie> but the general technique is two-fold: either you examine the data files and try changing things and see what happens, or you just load the binary into a disassembler and start decoding the machine code.
[22:01:33] <tomprince> I seem to recall this coming up before, but have people tried to get access to the source?
[22:01:36] <grofit> oh wow must take forever
[22:01:38] <fuzzie> a lot of people did both of those to the infinity engine games.
[22:01:54] <fuzzie> tomprince: they have
[22:03:25] <fuzzie> i'm not sure what the response was, but i know it would require them to put enough work in to remove all the stuff they're not allowed to distribute (eg, under the D&D license)
[22:03:41] <fuzzie> and a lot of the remaining unknown stuff is in PS:T/IWD/IWD2 anyway
[22:03:51] <fuzzie> so i would not hold out a lot of hope
[22:05:15] <tomprince> I was just wondering, since I happen to be from Edmonton.
[22:05:39] <grofit> is pythonlibs seperate to python?
[22:05:50] <grofit> to me it looks like a load of env vars that its looking for
[22:05:51] <fuzzie> well, you could always try approaching them again
[22:06:00] <fuzzie> grofit: you have 'python-dev'?
[22:06:38] <grofit> i thought so, but looking through the list the one i have installed is
[22:06:41] <fuzzie> tomprince: i think some scummvm source grants were done on the basis of NDAs and heavy restrictions on what you could do..
[22:06:54] <grofit> python3.1-dev
[22:06:57] <fuzzie> wjp might know better if they have some kind of standard approach
[22:07:29] <fuzzie> you need plain 'python-dev', 3.1 is incompatible python3
[22:07:45] <grofit> python 2.6 dev ok?
[22:07:57] <grofit> it doesnt seem to have vanilla python :(
[22:08:07] <fuzzie> yes
[22:08:15] <grofit> ah ok getting it now
[22:08:57] <grofit> ah ok getting it now
[22:09:00] <grofit> oops
[22:09:14] <grofit> lol wrong window
[22:09:16] <fuzzie> oh, Avenger says the response is simply that Bioware as it currently exist doesn't have the source code
[22:09:19] <grofit> ok more progress brb
[22:09:32] <grofit> who has it? obsidian
[22:10:03] <fuzzie> which is something which seems to happen depressingly often
[22:10:58] <fuzzie> in any case i guess there are enough cases of public 'no' answers
[22:11:20] <fuzzie> so meh
[22:11:39] <tomprince> Well, I'll look into it again.
[22:14:35] <grofit> new copy and paste incoming
[22:15:05] <grofit> http://pastebin.com/raw.php?i=Zeqycikm
[22:15:09] <grofit> it gets further now
[22:16:55] <Maighstir> Sorry to interrupt... but why does GemRB try to load plugins from the path where I originally installed it (-DCMAKE_INSTALL_PREFIX + /plugins/) when that path doesn't even exist on the computer I copied it to? shouldn't it simply use ./plugins/ if nothing's specified in the cfg?
[22:17:54] <grofit> oh dogs misbehaving, i will probably pop on again tomorrow after work if i could hassle you guys some more the?
[22:18:03] <grofit> *then
[22:18:48] <tomprince> Maighstir: you could set -DPLUGIN_DIR=./Plugins, if that is the behaviour you want.
[22:19:37] <tomprince> The more common use case, or at least the imagined use case, is somebody installing into /usr, or /usr/local, in which case defaulting to the install directory is the most sensible.
[22:20:06] <tomprince> Although, we could change things so that we look for plugins in multiple paths.
[22:20:26] <fuzzie> that would probably be clever
[22:22:12] <tomprince> All it would need is mulitple calls to PluginMgr::LoadPlugins
[22:23:19] <-- grofit has left IRC (Ping timeout: 265 seconds)
[22:23:33] <Maighstir> I'm just thinking that someone (like me) could copy GemRB to another computer and not necessarily have it in the same path, so looking in ./plugins/ by default would work anywhere unless the plugin dir is specifically moved to another location relative to gemrb.
[22:24:22] --- Dark-Star is now known as Dark-Star|Zzz
[22:24:48] <tomprince> Well, there has been repeated talk of using paths relative to the binary, but nobody has tackled that yet.
[22:25:24] <fuzzie> it is unlikely i will find time to tackle anything before 29th june, my last exam
[22:25:53] <fuzzie> so all mumblings on my part come with that disclaimer
[22:25:59] <tomprince> I know for me, ./plugins probably would almost never work, since I just install gemrb into the path, and run it from wherever.
[22:27:28] <Maighstir> right, so that -DPLUGIN_DIR would just set it to <current active directory>/plugins? not <gemrb binary dir>/plugins
[22:32:41] <tomprince> Yes. If you are doing that, you might want to configure with -DCMAKE_INSTALL_PREFIX=. and the run make install DESTDIR=/path/to/install/to
[22:32:48] <tomprince> That should probably work (untested).
[22:34:29] <tomprince> Apprently cmake is too intelligent for that :(
[22:41:23] <tomprince> I think you will have to edit config.h with the paths you want.
[22:47:28] <-- budlust has left IRC (Quit: budlust)
[22:47:42] --> budlust has joined #GemRb
[22:48:02] <Maighstir> So distributing a build requires editing of more than GamePath, since the installation dir cannot be known... not that I am distributing it yet, but it's good to know if I were to make a binary package available.
[22:48:53] <tomprince_loki> Well, if you want to make a relocatable binary package available, yes.
[22:58:11] --> _pickle has joined #GemRb
[23:26:44] <tomprince_loki> Maighstir: If you are interested in adding relocation support, you should have a look at make_relative prefix from libiberty (part of gcc), and see if it is easy to extract.