#gemrb@irc.freenode.net logs for 19 Oct 2016 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[01:28:47] --> xrogaan has joined #gemrb
[01:49:05] <-- Dominus has left IRC (Ping timeout: 256 seconds)
[01:50:34] --> Dominus has joined #gemrb
[01:50:34] <-- Dominus has left IRC (Changing host)
[01:50:34] --> Dominus has joined #gemrb
[07:00:45] <-- edheldil has left IRC (Remote host closed the connection)
[07:02:03] --> edheldil has joined #gemrb
[07:02:03] --- ChanServ gives channel operator status to edheldil
[07:07:08] --> GeneralDuke has joined #gemrb
[07:43:14] --> lynxlynxlynx has joined #gemrb
[07:43:26] <-- lynxlynxlynx has left IRC (Changing host)
[07:43:26] --> lynxlynxlynx has joined #gemrb
[07:43:26] --- ChanServ gives channel operator status to lynxlynxlynx
[15:31:35] <-- GeneralDuke has left IRC (Quit: GeneralDuke)
[16:04:26] <-- heirecka has left IRC (Quit: Bye)
[18:24:26] --> heirecka has joined #gemrb
[18:29:08] --> miartad has joined #gemrb
[18:29:12] <miartad> wassup
[18:29:45] * miartad is compiling gemrb and very much interested in what progress was made since last time i checked!
[18:37:27] <lynxlynxlynx> ojla
[18:37:46] <lynxlynxlynx> bigger stuff is in NEWS
[18:46:59] <miartad> how do I disable game override path
[18:47:12] <miartad> noob questions incomming
[18:48:06] <miartad> http://paste.fedoraproject.org/455832/76902895
[18:48:09] <Pepelka> #455832 • Fedora Project Pastebin
[18:48:10] <Pepelka> »Fedora Sticky Notes is a feature-rich, yet lightweight paste utility«
[18:49:09] <lynxlynxlynx> you don't need to, the game will suffer if it's not found
[18:49:20] <miartad> oh i see
[18:49:27] <lynxlynxlynx> we don't support ees yet (only partially) though
[18:49:47] <lynxlynxlynx> so my guess would be they have a different layout or it's actually Override
[18:50:57] <miartad> yes on linux steam version of game it is called chitin.key
[18:50:58] <lynxlynxlynx> you could toggle case sensitivity in the config, but what will really bite you is where we actually bail out
[18:51:19] <lynxlynxlynx> for improved i18n support, they moved dialog.tlk
[18:52:05] <miartad> I enabled case sensitivity but it is looking for Chitin.key there is only chitin.key
[18:52:49] <lynxlynxlynx> you're on linux, so you need to disable it for us to look at all the variants
[18:55:03] <miartad> [ResourceManager/WARNING]: Invalid path given: /home/adam/.steam/steam/steamapps/common/Baldur\'s\ Gate\ II\ Enhanced\ Edition/chitin.key
[18:55:06] <miartad> hmm file is there
[18:55:12] <miartad> is guess this is because of spaces maye
[18:55:14] <miartad> is guess this is because of spaces maybe
[18:55:32] <lynxlynxlynx> oh
[18:55:38] <lynxlynxlynx> you don't need to escape the spaces
[18:55:50] <lynxlynxlynx> nothing, the path is taken as-is
[18:56:56] <miartad> yes I tried both ways now that Im thinking about it it may be " ' "
[18:57:09] <miartad> moved directory to "BG2" and that let me go forward
[19:02:02] <lynxlynxlynx> ' should be fine too, i'm using it in one of the config without issue
[19:03:07] <miartad> symlinked dialog tlk, now stuck @ [Core/FATAL]: Unable to load font resource: NUMBER2 for ResRef NUMBER2 (check fonts.2da)
[19:04:26] <lynxlynxlynx> they probably switched to ttf
[19:04:39] <lynxlynxlynx> you can edit fonts.2da and try NUMBER
[19:05:07] <lynxlynxlynx> i'd change NUMBER3 too
[19:05:20] <miartad> what does that mean?
[19:05:34] <miartad> there is "fonts.bif"
[19:05:39] <miartad> in data folder
[19:06:24] <lynxlynxlynx> gemrb/unhardcoded/fonts.2da
[19:06:27] <miartad> yes
[19:06:48] <miartad> so set need_palate to 1 for those?
[19:06:55] <lynxlynxlynx> no idea
[19:07:07] <-- FutureSuture has left IRC (Read error: Connection reset by peer)
[19:07:11] <lynxlynxlynx> i have never checked what's inside
[19:07:30] <lynxlynxlynx> if fonts.bif contains ttf fonts, just renaming the rows would be a good start
[19:10:48] <miartad> wow just removed the fonts that got me to a point where gemrb complains about actions and triggers
[19:10:54] <miartad> didnt know all this is taken from data
[19:11:40] <lynxlynxlynx> but just warnings, right?
[19:11:46] <miartad> yes
[19:11:57] <miartad> I think ultimately there is another problem
[19:12:24] <miartad> there are some errors but they seem harmless
[19:12:35] <miartad> RuntimeError: Control (ID: 0) was not found!
[19:12:42] <miartad> this one looks like fatal one
[19:12:42] <lynxlynxlynx> yep
[19:13:00] <lynxlynxlynx> it proves that they didn't include the old gui files
[19:13:27] <miartad> [CHUImporter/ERROR]: Cannot Load Button Images, skipping control
[19:13:29] <miartad> like that
[19:13:36] <miartad> maybe there are hidden somewhere?
[19:13:42] <miartad> or they are remastered
[19:14:26] <lynxlynxlynx> they reimplemented the gui to obviate the need for widescreen mod and to make life easier on android/ios
[19:16:24] <miartad> so that means those images are there but maybe in different format or in different place?
[19:18:34] <lynxlynxlynx> the structure linking them changed and yes, some are different too
[19:18:55] <lynxlynxlynx> they changed the MOS file format
[19:19:26] <lynxlynxlynx> and there's a new compressed tile format too
[19:19:59] <miartad> and its closed source I assume
[19:20:47] <lynxlynxlynx> the latter is PVRZ, which i think isn't; in any case it's pretty well understood and dltcep already has code for it
[19:21:01] <lynxlynxlynx> adding another plugin to gemrb for that wouldn't be that hard
[19:22:34] <miartad> where can I read about the linking structure chitin key and stuff like that?
[19:23:01] <miartad> i assume chitin key is used to link data assets?
[19:23:13] <lynxlynxlynx> go to gemrb.org
[19:23:23] <lynxlynxlynx> in the sidebar the link to IESDP now points to the updated one
[19:23:40] <lynxlynxlynx> you can find such info in the File formats pages
[19:26:08] <miartad> oh my god, how did they do it
[19:26:50] <miartad> I reverse engineered part of early starbound invertory file but took me hours and would never do such thing again
[19:26:52] <miartad> :D
[19:28:48] <lynxlynxlynx> it took years and it's still going on
[19:29:17] <lynxlynxlynx> luckily for the ee changes, the modders had enough influence for the new headers to be posted
[19:38:35] <miartad> data/GUIIcon.bif,data/GUIMosc.bif,data/GUIFont.bif,data/GUIDesc.bif,data/GUIBam.bif,data/GUICHUI.bif,data/25GuiBam.bif,data/25GuiMos.bif,data/25GuiDes.bif
[19:38:39] <miartad> I guess these are new?
[19:38:47] <miartad> this is in chitin.key
[19:43:04] <lynxlynxlynx> guimosc sounds familiar
[19:45:57] <miartad> oh so you need to decompress these big files and then they can contain bitmaps or another assets
[19:46:05] <miartad> big = bif
[19:46:56] <lynxlynxlynx> yes, you can use weidu to extract everything
[19:47:10] <lynxlynxlynx> what are you looking for?
[19:47:48] <miartad> I would just like gemrb to work with data from enhanced edition since thats only game version I have atm
[19:48:44] <lynxlynxlynx> that could be quite an effort
[19:48:59] <lynxlynxlynx> pvrz files can be converted to normal mos/mosc
[19:49:29] <lynxlynxlynx> i don't know if all the files that use them care about the type
[19:49:51] <miartad> by pvrz you mean BIFC V1.0 (compressed)? because I cant see any *.pvrz
[19:50:41] <miartad> there are pvrz only in language overrides
[19:50:42] <lynxlynxlynx> ah, it's not on the list
[19:51:11] <miartad> yes but even in game's directory there are no pvrz files, only some in language overrides
[19:51:16] <lynxlynxlynx> duckduckgo gives me a pull request to nearinfinity as the first hit :D
[19:51:27] <lynxlynxlynx> they're in the biffs
[19:51:34] <miartad> oh
[19:51:48] <miartad> duckduckgo still lives :)
[19:56:31] <lynxlynxlynx> looks like the pvr format is public
[19:56:53] <lynxlynxlynx> the issue uses a dead link though
[19:57:14] <miartad> http://cdn.imgtec.com/sdk-documentation/PVR+File+Format.Specification.pdf ?
[19:57:16] <miartad> could it be?
[19:57:16] <lynxlynxlynx> the commit itself tells everything about the structure, but i'm sure the gemrb version would be shorter
[19:58:00] <lynxlynxlynx> yes, that's it
[19:58:13] <miartad> so pvrz its that just compressed with zlib
[19:59:16] <lynxlynxlynx> yes
[19:59:54] <lynxlynxlynx> 0x0 has the uncompressed size and the data starts at 0x4
[20:02:24] <miartad> so there is no compressed size anymore?
[20:03:46] <lynxlynxlynx> it's the filesize - 4
[20:03:52] <lynxlynxlynx> but yeah, not stored
[20:04:08] <lynxlynxlynx> doesn't even have a signature
[20:04:13] <miartad> so there is only one pvrz per bif?
[20:04:35] <lynxlynxlynx> i don't think there's any limit
[20:04:45] <lynxlynxlynx> bif files are just optionally compressed archives
[20:05:03] <lynxlynxlynx> pvr(z) is more closely related to mos(c)
[20:05:32] <miartad> yes but if you have multiple pvrz per bif then bif needs to contain compressed size also
[20:05:41] <miartad> how would you know where another pvrz starts if it didnt
[20:06:33] <lynxlynxlynx> ah, but that's in the bif entry itself
[20:06:38] <miartad> yes
[20:06:44] <lynxlynxlynx> it's index
[20:07:17] <lynxlynxlynx> the file entry struct mentioned in the docs
[20:08:07] <miartad> oh i see now, so you need to uncompress bifc to get biff and then you have multiple prvz
[20:09:33] <lynxlynxlynx> multiple whatever
[20:09:50] <lynxlynxlynx> we handle bifs fine already, ees didn't change them
[20:09:54] <miartad> much compression
[20:18:35] --> Eli2| has joined #gemrb
[20:21:48] <-- Eli2_ has left IRC (Ping timeout: 260 seconds)
[20:56:09] <miartad> seems like data/25GuiMos.bif contains MOS V2 and that one cant be red by gemrb yet
[20:56:33] <miartad> not even near infinity that i downloaded can read those mos
[21:02:01] <lynxlynxlynx> the format is known though
[21:02:14] <lynxlynxlynx> once pvrz can be handled, mos v2 is trivial
[21:02:32] <lynxlynxlynx> similarly bam v2
[21:05:36] <miartad> 25GuiMos.bif claims to be BIFFV1 but it uses 8 bytes for "Type of this resource"
[21:05:49] <miartad> that does not correspond to what is written on modder database
[21:05:59] <miartad> strange
[21:06:43] <miartad> its says it has "MOS V2" types of resource but on modder page it says it should use only 2 bytes to identify resource type
[21:07:05] <miartad> strange
[21:08:18] --> FutureSuture has joined #gemrb
[21:08:54] <lynxlynxlynx> it says 2 words not 2 bytes
[21:09:09] <lynxlynxlynx> ah no
[21:11:08] <lynxlynxlynx> it could be a magic number
[21:11:18] <lynxlynxlynx> i'll check our importer
[21:13:56] <miartad> even offset to file entries is 06c4 that doesnt make sense since there is first MOSV2 right after that block of data
[21:14:26] <miartad> and thats on 24th byte
[21:14:36] <miartad> co no chance for offset of 6c4
[21:15:27] <miartad> http://paste.fedoraproject.org/455911/91174014
[21:15:29] <Pepelka> #455911 • Fedora Project Pastebin
[21:15:30] <Pepelka> »Fedora Sticky Notes is a feature-rich, yet lightweight paste utility«
[21:15:31] <miartad> if you are interested
[21:15:36] <miartad> thats 25GuiMos.bif
[21:15:50] <miartad> but I dont think its biff v1 as it claims
[21:20:10] <lynxlynxlynx> it has the right signature
[21:20:35] <miartad> 0x0010 this is where it starts to be different
[21:20:45] <miartad> up to that point header matches
[21:21:20] <miartad> 0x10 should be offset to file entries and thats 06c4
[21:21:38] <miartad> that file doesnt even contain that amount of data
[21:24:05] <lynxlynxlynx> hmpf, weidu doesn't want to enumerate it for me
[21:25:07] <lynxlynxlynx> ah, case
[21:25:47] <lynxlynxlynx> only 8 mos files, like your dump suggested
[21:26:09] <miartad> weidu is some kind of viewer?
[21:26:16] <miartad> i m playing with near infinity
[21:26:21] <lynxlynxlynx> the modding tool
[21:27:38] <lynxlynxlynx> i forgot about iesh, that has a better dump
[21:30:35] <lynxlynxlynx> looking at the old bif, that one has a sane offset
[21:31:47] <lynxlynxlynx> so it seems they did change the format slightly
[21:32:00] <lynxlynxlynx> 0x6c4 is the file size
[21:32:26] <miartad> yes looking at this bif starting from 0x10, c4 - unknown, 06 -> offset from this position to start of MOS file
[21:32:40] <miartad> then 6 empty bytes
[21:32:44] <miartad> and first MOS begins
[21:33:04] <miartad> I smell something fishy about this bif file :)
[21:37:04] <miartad> I dont think 6c4 is file size...
[21:37:16] <lynxlynxlynx> all the ones seem that way (sample of 3)
[21:37:23] <lynxlynxlynx> it's off only by 4
[21:39:49] <miartad> ok just looked at another bif and my theory doesnt make sense, seems like header is always 24 bytes and after that data starts
[21:40:17] <miartad> or im interpreting the offset wrong
[21:44:44] <lynxlynxlynx> nothing interesting on the forum, but i did find threads for pvr and pvrz, cleaner than the spec
[22:17:56] <lynxlynxlynx> well, ni doesn't do anything special, so huh
[22:20:40] <lynxlynxlynx> the java interface it uses for seeking would catch any such nonsense
[22:34:45] <lynxlynxlynx> i'm sure it's something trivial
[22:35:41] <lynxlynxlynx> it didn't do anything special, but in this case using modulo filesize and advancing for that amount is the same as just continuing to read, offset 0
[22:35:48] <lynxlynxlynx> but zzz
[22:39:04] <-- miartad has left IRC (Remote host closed the connection)
[22:40:24] <-- lynxlynxlynx has left IRC (Ping timeout: 260 seconds)