Log for #openttdcoop.devzone on 19th February 2012:
Times are UTC Toggle Colours
00:26:06  <Brot6> SuperLib - Revision 47:95244fa2a8e1: Add: CanWalkToTile(...) (Zuu) @
00:26:06  <Brot6> SuperLib - Revision 48:f5727a8a7adc: Allow more sub libraries to be translated to NoGo (Zuu) @
00:26:06  <Brot6> SuperLib - Revision 49:f6616fd8ab79: Version 21 (20 was screwed up as some bugs was found after u... (Zuu) @
00:41:24  <Brot6> Tutorial - Revision 53:63f9a1d93bd8: Generalized and moved tile walker to SuperLib (Zuu) @
01:14:26  <Brot6> SuperLib - Revision 50:6f1c61bde582: Document: If no cargo is passed to BuildAirportInTown, the a... (Zuu) @
01:14:26  <Brot6> SuperLib - Revision 51:48ac54a324bb: Initial implementation of Airport.BuildAirportForIndustry (n... (Zuu) @
01:30:13  *** JVassie has quit IRC
01:38:58  *** Zuu has quit IRC
05:44:10  *** andythenorth has joined #openttdcoop.devzone
07:37:31  <Brot6> BANDIT - Revision 283:459263060d50: Codechange: generator provides bulk load cargos in correct sp... (andythenorth) @
07:43:04  *** andythenorth has quit IRC
07:54:04  *** andythenorth has joined #openttdcoop.devzone
08:10:13  <Brot6> BANDIT - Revision 284:ba417c07f097: Codechange: minor refactor of method name (andythenorth) @
08:31:44  <Brot6> BANDIT - Revision 285:885461fae039: Codechange: use the variation id in filenames (andythenorth) @
08:48:17  <Brot6> BANDIT - Revision 286:cc0fcb25c20b: Codechange: generator handles colour variations (andythenorth) @
09:44:37  *** Zuu has joined #openttdcoop.devzone
10:03:55  *** andythenorth has quit IRC
11:19:13  *** LordAro has joined #openttdcoop.devzone
11:36:31  *** JVassie has joined #openttdcoop.devzone
12:03:09  *** andythenorth has joined #openttdcoop.devzone
12:17:57  <Brot6> Dutch Trains 2.0 - Revision 199:3d888b2af950: Feature: finish NS 6400 (issue #2951, issue #3345) (foobar) @
12:17:57  <Brot6> Dutch Trains 2.0 - Revision 200:cfa6135d9069: Feature: finish G1206 (issue #2951, issue #3345) (foobar) @
12:17:57  <Brot6> Dutch Trains 2.0 - Revision 201:d081345823f0: Feature: finish ACTS6700 (issue #2951, issue #3345) (foobar) @
12:17:59  <Brot6> Dutch Trains 2.0 - Revision 202:20489c29278a: Feature: finish HLR 77 (issue #3345) (foobar) @
12:18:03  <Brot6> Dutch Trains 2.0 - Revision 203:fcb6d39cfc5e: Feature: finish RN 232 (issue #3345) (foobar) @
12:40:18  *** frosch123 has joined #openttdcoop.devzone
12:53:08  <Brot6> Dutch Trains 2.0 - Revision 204:720a241d653f: Feature: finish G2000 (issue #2951, issue #3345) (foobar) @
12:53:08  <Brot6> Dutch Trains 2.0 - Revision 205:b3f28aff6ec0: Feature: finish Class66 (issue #2951, issue #3345) (foobar) @
12:53:08  <Brot6> Dutch Trains 2.0 - Revision 206:5fe1edabdfae: Feature: finish ACTS5800 (issue #2951, issue #3345) (foobar) @
12:53:10  <Brot6> Dutch Trains 2.0 - Revision 207:1edd8d775b04: Feature: finish G400B (issue #3345) (foobar) @
13:10:21  <Brot6> BANDIT - Revision 287:228c8624fbea: Codechange: cleanup redundant / silly code from gestalt (andythenorth) @
13:30:30  *** ODM has joined #openttdcoop.devzone
13:32:03  <Brot6> Dutch Trains 2.0 - Revision 208:1723f6d6c431: Change: only keep diesel and electric engines (foobar) @
13:32:03  <Brot6> Dutch Trains 2.0 - Revision 209:c837818bc296: Docs: prepare for release (foobar) @
13:32:03  <Brot6> Dutch Trains 2.0 - Revision 210:cb10c76959d5: Release: trialrelease-1 (foobar) @
13:36:57  <Brot6> BANDIT - Revision 288:841c125569f0: Codechange: disambiguate render method name (andythenorth) @
13:38:13  <Brot6> dutchtrains: update from  to trialrelease-1 done -
14:04:52  <Brot6> Central European Train Set - Revision 634:6f4fe8086fc9: ÖBB diesel engines (Eddi) @
14:04:52  <Brot6> Central European Train Set - Revision 635:04f1cbf9ae06: issue a warning when number of articulate... (Eddi) @
14:04:52  <Brot6> Central European Train Set - Revision 636:6f3c935db87a: internally rename kkStB to StEG (Eddi) @
14:04:52  <Brot6> Central European Train Set - Revision 637:eca59682bb1c: initial (incomplete) list of StEG/kkStB e... (Eddi) @
14:06:57  *** Zuu has quit IRC
14:09:40  <Ammler> Rubidium: if you make RC, would be nice, if you could call it "rc" instead, so it is > than beta
14:11:17  <Ammler> 1.2.0-beta4 is newer than 1.2.0-RC1  -   1.2.0-beta4 is older than 1.2.0-rc1
14:14:43  <Brot6> cets: update from r633 to r637 done (973 warnings) -
14:16:13  <Rubidium> Ammler: I hope you mean the text in the .spec as I don't fancy changing it anywhere else
14:16:28  <Brot6> Central European Train Set - Revision 638:8f0d9517a3f1: tender for ÖBB 214 (Eddi) @
14:16:28  <Brot6> Central European Train Set - Revision 639:7a5339d15451: typo (Eddi) @
14:16:29  <Ammler> of course not
14:16:40  <Rubidium> but there it's even 1.2.beta4
14:16:55  <Ammler> you do update the spec?
14:17:14  <Rubidium> which is even stupider as 0 < b ;)
14:17:14  <Ammler> hmm, yes you do :-)
14:17:47  <Rubidium> Ammler: only if I know what to change, but that's not clear and I regularly forget the naming scheme of the rpm
14:17:58  <Ammler> 1.2.rc1 is older than 1.2.0
14:18:28  <Ammler> 1.2.0-rc1 is newer than 1.2.0
14:18:39  <Ammler> is that different in Debian?
14:19:17  <Rubidium> ~ orders before nothing, and nothing orders before -
14:19:29  <Rubidium> so 1.2.0~RC3 < 1.2.0 < 1.2.0-1
14:19:49  <Ammler> that is not "-"
14:20:00  <Ammler> so you cheat like me :-)
14:20:33  <Ammler> and debian isn't case sensitive?
14:20:33  <Rubidium> except that 1.2.0 < 1.2.1~RC1 < 1.2.1
14:20:39  <Rubidium> Ammler: no clue ;)
14:20:42  <Rubidium> probably not
14:21:16  <Ammler> afaik, rpm plans to invent "~" too
14:21:45  <Ammler> but not really important as you usually don't pack testing releases
14:22:16  <Rubidium> we usually do ;)
14:22:46  <Ammler> in rpm, you do then
14:23:19  <Rubidium> that's really ugly, and $noob could assume it's a RC of 1.2.0
14:23:46  <Rubidium> alternatively you *could* use OpenTTD's full version
14:23:51  <Ammler> well, but confiusing noob is preferable than confusing rpm
14:23:57  <Rubidium>
14:24:30  <Ammler> there is NO "-" :-P
14:25:05  <Ammler> I guess, fedora cheats the testing to the release tag
14:25:10  <Rubidium> then ;)
14:25:46  <Ammler> but then you confuse also non-noobs
14:25:59  <Ammler> as rc1 should be there, imo
14:26:52  <Ammler> anyway, I have two tags in the spec, one for rpm, the other to grap the source (srcver)
14:26:58  <Brot6> cets: update from r637 to r639 done (973 warnings) -
14:28:40  <Ammler> also I found a way to solve the fedora lack of recommends, but there is no real need to submit the spec again, right?
14:29:41  <Ammler> I basically merged packages openttd and openttd-gui
14:40:01  <Rubidium> I don't know what the spec is used for / who uses it, so can't answer that
14:40:27  <Rubidium> if you want the version numbers to be right I'd like some documentation about how to name the different things. Preferably as a patch to the spec
14:41:55  <Ammler> if someone uses it, then it would be as example/template only anyway
14:42:47  <Ammler> I don't use it myself either, I use the suse spec as developing version and submit final versions to openttd
14:44:58  <Ammler> you do not really need to update the version
14:45:49  <Ammler> it might be even better not to, except you update other things too, that way, someone would see, with which version it worked
14:46:17  *** andythenorth has quit IRC
14:47:03  <Ammler> I also removed all the distro hacks and added those on project itself
14:47:16  <Ammler> like the rhel kernel
14:47:56  <Ammler> as such things depends where the rpm is built
16:07:24  *** Zuu has joined #openttdcoop.devzone
16:09:15  <Brot6> NewGRF build framework - Bug #3706 (New): "caching" behaviour on nml error (foobar) @
16:21:56  *** andythenorth has joined #openttdcoop.devzone
17:00:21  <Brot6> Dutch Trains 2.0 - Revision 211:1fb1b97b6811: Feature: finish GVB M1M2 (issue #2951, issue #3345) (foobar) @
17:00:21  <Brot6> Dutch Trains 2.0 - Revision 212:6b3c93e6290f: Feature: finish GVB S1S2 (issue #2951, issue #3345) (foobar) @
17:00:21  <Brot6> Dutch Trains 2.0 - Revision 213:93a85a2bd8e5: Feature: finish GVB M4S3 (issue #2951, issue #3345) (foobar) @
17:00:25  <Brot6> Dutch Trains 2.0 - Revision 214:3dcefae279a2: Feature: finish GVB M5M6 (issue #3345) (foobar) @
17:02:45  <Brot6> Central European Train Set - Revision 640:26c34df727c9: some austrian freight engines, add DRG 42... (Eddi) @
17:13:00  <Brot6> cets: update from r639 to r640 done (979 warnings) -
17:24:40  <Brot6> bandit: update from r278 to r288 done (1 warnings) -
17:31:54  <Brot6> cets: update from r633 to r640 done (979 warnings) -
17:32:08  <Brot6> NewGRF build framework - Bug #3706: "caching" behaviour on nml error (foobar) @
17:33:39  <Brot6> dutchtrains: update from r198 to r214 done (360 warnings) -
17:43:02  *** LordAro has quit IRC
17:57:42  <Brot6> BANDIT - interesting.png (andythenorth) @
18:01:36  *** LordAro has joined #openttdcoop.devzone
19:09:47  <Brot6> Dutch Trains 2.0 - Support #3632: list of vehicles to be drawn (Voyager1) @
19:30:22  <Yexo> good evening
19:30:52  <Yexo> planetmaker: did I read correctly you needed my input on something?
19:33:08  <Rubidium> Yexo: in short openttd RC1 depends on opengfx release which depends on a nml release
19:33:30  <Rubidium> some train tunnel sprite thing (action 5)
19:33:36  <Yexo> that one commit?
19:33:59  <planetmaker> Yexo: yes, about whether that single commit is enough or you want anything else backported
19:34:20  <planetmaker> otherwise I'd just add a brief changelog and release that
19:34:30  <planetmaker> and subsequently the same for OpenGFX
19:34:51  <Yexo> r1813 would be nice
19:35:10  <Yexo> and r1812
19:35:24  <Yexo> that's all
19:35:29  <Yexo> I can do that now if you want?
19:35:33  * Rubidium agrees ;)
19:35:46  <planetmaker> yes, please :-)
19:43:33  <Ammler> you guys know in the meantime, if debian or fedora call it nml or python-nml?
19:43:41  <Ammler> or still no release there?
19:45:02  <Brot6> NewGRF Meta Language - Revision 1827:5f2c23ef5e1f: Release: 0.2.3 (yexo) @
19:45:02  <Brot6> NewGRF Meta Language - Revision 1828:f833892598df: Added tag 0.2.3 for changeset 5f2c23ef5e1f (yexo) @
19:45:15  <Rubidium> Ammler:
19:45:20  <Webster> Title: #651217 - ITP: nml -- NewGRF Meta Language compiler - Debian Bug report logs (at
19:46:49  <Ammler> Rubidium: does this mean, the "name" is a bug?
19:46:58  <Ammler> dont't get that ticket :-)
19:47:09  <Rubidium> ITP = "intent to package"
19:47:15  <Yexo> it means it's not yet packaged, but the name will be "nml"
19:47:39  <Rubidium> which means someone intents to create a package with that name and metadata
19:48:05  <Rubidium> and then basically all developers see that ticket so they can act when things might go wrong
19:48:13  <Ammler> well then, if debian plans to package it as nml, I keep it too
19:48:15  <Rubidium> such as creating the same package twice
19:48:54  <Ammler> as it is a independend tool anyway, not really a python lib
19:50:39  <Rubidium> planetmaker: what'd be the ETA for OpenGFX?
19:51:03  <frosch123> Ammler: you can also consider openttd-nml :p
19:51:25  <planetmaker> Rubidium: I'm preparing the changelog and having a look at readme + credits file
19:51:39  <Ammler> frosch123: not really
19:51:48  <planetmaker> so I'd say within ... maybe two hours. Depends a bit on NML :-)
19:51:55  <frosch123> ok, grfcodec is not called openttd-grfcodec either
19:52:07  <Yexo> planetmaker: nml was done 5 minutes ago ;)
19:52:08  <Ammler> I once did that with grfcodec, wasn't liked :-)
19:52:13  <planetmaker> Oh, missed that. Thx, Yexo
19:53:08  <Brot6> nml: update from 0.2.2 to 0.2.3 done -
19:53:42  <Brot6> OpenGFX - Revision 921:96f04c4e4877: Update: Changelog, documentation and credits updated for rel... (planetmaker) @
19:54:39  <planetmaker> building locally now to give it a quick check for sanity
19:55:13  <Ammler> check also the openttd log please and maybe recommend the debug level
19:55:14  <Rubidium> check danish ;)
19:55:36  <Rubidium> and 1.1.x
19:55:47  <Rubidium> and trunk (or branches/1.2)
19:56:13  <planetmaker> that ^
19:57:28  <Ammler> hmm, that could make test hard, if openttd depends on opengfx and opengfx on openttd :-)
19:57:57  <planetmaker> openttd depends not on opengfx, but recommends it. And OpenGFX definitely doesn't depend on OpenTTD
19:58:05  <planetmaker> though it's pointless without
19:58:11  <Ammler> it for _test_
19:58:18  <planetmaker> but libXYZ is also pointless if not used anywhere
19:58:38  <Ammler> does*
20:01:40  <planetmaker> it's called circular dependency :-P
20:08:44  <Yexo> Rubidium: in, there is this line:
20:08:46  <Yexo> +                self._byte_count -= 3
20:08:55  <Yexo> after this: +                self.print_dword(self.sprite_num, data)
20:09:01  <Yexo> with comments about ignoring that
20:09:05  <Yexo> is that 3 a typo for 4?
20:09:55  <Yexo> or is that for the compression byte?
20:11:14  <planetmaker> great, Danish is ok in both trunk and 1.1.5
20:11:33  <Rubidium> Yexo: there was a size += (type != 0xFF), which is what (I think) is cancelling out the -= 4 there
20:11:50  <Rubidium> or the other one that does _byte_count -= 1
20:11:52  <Yexo> ok
20:12:17  <Rubidium> the spriteid got 2 bytes bigger, so I just increased both numbers by 2 without much thinking
20:13:08  <Brot6> OpenGFX - Revision 922:b23d4b585b7a: Added tag 0.4.3 for changeset 96f04c4e4877 (planetmaker) @
20:16:19  <Yexo> Rubidium: unless I miss anything, you didn't write any code yet to split the grf in a data and a sprite section, right?
20:16:41  <Rubidium> Yexo: I did; that's most of the diff
20:16:58  <Rubidium> Yexo: check "wb"
20:17:14  <Yexo> oops :(
20:17:16  <Rubidium> it writes bytes to a different buffer
20:17:21  <Yexo> too quick reading :(
20:18:47  <Brot6> OpenGFX - Revision 924:44341223930e: Update: Changelog, documentation and credits updated for rel... (planetmaker) @
20:27:57  <planetmaker> hm...
20:30:48  <planetmaker> I should have ported the railsprites to 0.4...
20:32:51  <Rubidium> I still don't see 0.4.3 binaries, so there's still time isn't there? ;)
20:33:49  <Ammler> building opengfx needs around 30 mins
20:33:55  <planetmaker> the CF still compiles. I could re-tag as 0.4.3, but not sure
20:34:03  <planetmaker> I hate double tags
20:34:15  <Yexo> make it 0.4.4 and just skip 0.4.3
20:34:23  <Rubidium> then abort the CF and do 0.4.4
20:34:30  <Ammler> lol
20:35:33  <Ammler> reuse a tag is possible as it uses the hash
20:35:53  <planetmaker> I know. I guess we can do that
20:37:02  <Rubidium> so OpenGFX release already takes roughly as long as OpenTTD release
20:37:17  <planetmaker> yes
20:37:44  <Ammler> I would say, it at least three times
20:38:08  <Ammler> also depends on gimp
20:38:44  <planetmaker> that really kills the build time
20:38:50  <Brot6> OpenGFX - Revision 925:063d0c818826: Feature: Add support for tunnel overlay sprites. (code: mich... (planetmaker) @
20:38:50  <Brot6> OpenGFX - Revision 926:843f3dd03d87: Fix (r915): Actually use the proper y-offsets into the graph... (planetmaker) @
20:38:50  <Brot6> OpenGFX - Revision 927:ef65cb1e6935: Added tag 0.4.3 for changeset 843f3dd03d87 (planetmaker) @
20:39:27  <Ammler> not sure, if it is worth to define gimp as build require
20:39:38  <Ammler> specially as we distribute the pngs
20:39:56  <planetmaker> it will get worse, if we also depend on blender ;-)
20:41:15  <Rubidium> why? Can't blender run next to gimp?
20:41:47  <planetmaker> yes, sure it can. But it will have more to do than gimp
20:41:53  <Brot6> opengfx: update from 0.4.2 to 0.4.3 done -
20:42:04  <planetmaker> it'll have to generate the sprites for several zoom levels :-)
20:42:24  <Rubidium> maybe blender is better with multiple instances
20:42:58  <Rubidium> ofcourse blender uses hardware accelerations (*cough*)
20:45:47  <planetmaker> yeah :-P
20:46:00  <planetmaker> I haven't dwelled deeply on that so far, though
20:46:41  <Rubidium> not that hardware accereleration is likely to yield anything on a server without GPU
20:48:17  <planetmaker> yeah
20:52:58  <Brot6> OpenGFX - Bug #3707 (New): DevZone compile failed (compiler) @
20:58:09  <planetmaker> great :-(
20:59:08  <frosch123> smooth release :)
20:59:41  <Yexo> good reason to make 0.4.4 and include the railsprites
20:59:55  <planetmaker> well, that was the re-build with the re-tag, Yexo
21:00:03  <planetmaker> but... wrong palette of that file
21:00:05  <Rubidium> the rail sprite caused the failure ;)
21:00:24  <Rubidium> though OpenTTD release is slow as well... publishing takes already 13 minutes
21:00:27  <Yexo> ah
21:01:10  <Yexo> Rubidium: wanted to commit your patch, but it failed my usage test: compile ogfx-trains and use it in openttd
21:01:19  <Yexo> openttd complains about an unexpected sprite
21:01:48  <Rubidium> is there an empty real sprite?
21:01:56  <Yexo> not at that place
21:02:15  <Rubidium> sound?
21:02:24  <Yexo> nope, nothing special
21:02:29  <Rubidium> sprite wider than 256 pixels?
21:02:39  <Rubidium> does it work without the patch?
21:02:57  <Yexo> <- it complains about sprite 33
21:03:44  <Rubidium> that doesn't look like something I changed
21:05:18  <Yexo> I agree, but without your patch it works and with your patch applied to nml it does not
21:05:36  <Rubidium> what does grfcodec -d make of it?
21:05:49  <Yexo> I haven't been able to find the problem so far
21:05:53  <Rubidium> and if you do grfcodec -e, does that create a different grf?
21:08:05  <Yexo> Unknown zoom level 40 for sprite 33 <- from grfcodec -d
21:08:48  <Yexo> grfcodec -e creates a different file
21:10:00  <Yexo> the one encoded by grfcodec loads fine
21:11:45  <Rubidium> that'd imply that a realsprite is written
21:20:12  <Yexo> there are some bytes missing from the output
21:20:54  <Rubidium> due to 00 termination?
21:20:59  <Yexo> 32 * 9 09 00 04 0D \dx4E4E5246 01  <- nfo output from nml (and verified by reading grf file from nml in hex editor)
21:21:22  <Yexo>  32 * 9	 09 00 04 "FRNN" 01 09 <- read back by grfcodec
21:22:01  <Yexo> the 0D doesn't end up in the grf written by nml
21:22:14  <Rubidium> windows newline
21:22:53  <Rubidium> \r
21:23:09  <Rubidium> so either appending goes wrong, or writing to the file
21:26:57  <planetmaker> something's... odd... <-- any idea?
21:27:20  <Rubidium> wrong version of nml?
21:27:50  <planetmaker> hm...
21:28:07  <planetmaker> ah, damn, yes
21:28:10  <planetmaker> but locally
21:33:22  <Yexo> print_bytex was the culprint most likely :)
21:33:33  <Rubidium> why?
21:33:49  <Yexo> it already had 2 arguments, the second one was used
21:34:01  <Yexo> you added an extra argument in between but didn't update any places that called the function
21:34:25  <Yexo> so it was now called with a value meant for "pretty_print" that got interpreted as "data"
21:35:21  <Rubidium> so swapping the params and fixing the calls in output_grf would help
21:35:29  <Yexo> that's what I'm doing now :)
21:36:17  <Yexo> actually there shouldn't be any calls in output_grf, it should always be print_byte() there
21:36:56  <Rubidium> well, there are some in output_grf
21:37:15  <Yexo> "shouldn't" != "aren't" :p
21:37:23  <Yexo> I changed those just now
21:38:47  <Yexo> still a difference in filesize between nml and grfcoded, although it does load now
21:39:26  <Rubidium> did you grfcodec -e -g2 ?
21:39:30  <Yexo> yep
21:40:04  <Rubidium> that's probably the cropping or so
21:40:07  <Rubidium> oh...
21:40:11  <Rubidium> compression algorithm
21:40:14  <Yexo> yep
21:40:33  <Rubidium> grfcodec -d the nml grf and then encoding it again yields the same file
21:42:22  <Brot6> Dutch Trains 2.0 - Revision 215:a46db966308d: Feature: finish RET type M (issue #3345) (foobar) @
21:42:22  <Brot6> Dutch Trains 2.0 - Revision 216:2ff9b4f96b9d: Feature: finish RET type B (issue #3345) (foobar) @
21:42:22  <Brot6> Dutch Trains 2.0 - Revision 217:ac8632be1d71: Feature: finish RET type T (issue #2951, issue #3345) (foobar) @
21:42:24  <Brot6> Dutch Trains 2.0 - Revision 218:c690acf3bc55: Feature: finish RET type R (issue #2951, issue #3345) (foobar) @
21:42:51  <Yexo> Offset too large in sprite 176! <- still not completely correct
21:43:31  <Rubidium> shoot
21:44:30  <Rubidium> is that the nml or the nfo that you compiled?
21:45:04  <Rubidium> although, the nfo output would still be nfo7
21:45:10  <Yexo> that's output from grfcodec -d when decoding the grf encoded by nml
21:45:44  <Rubidium> I'm not getting that
21:48:12  <Rubidium> is what I applied on top of the nml_gc2 diff
21:49:21  <Yexo> that's what I have too
21:51:24  <Brot6> BROS (Python Script) - Bug #3708 (New): Upload Code (Leanden) @
21:51:26  <Rubidium> are you sure it's exactly that and not some small typo?
21:51:43  <Yexo> no, I'll reapply the patch and those changes
21:52:02  <Rubidium> which grfcodec do you use?
21:52:22  <Yexo> r897
21:52:54  <Brot6> BROS (Python Script) - Bug #3708 (Assigned): Upload Code (Leanden) @
21:52:54  <Brot6> BROS (Python Script) - Bug #3708 (Assigned): Upload Code (Leanden) @
21:55:45  <Yexo> apparently I did have another change to my nml files
21:56:03  <Yexo> still 1k filesize difference, but no errors on decoding from grfcodec anymore
21:56:27  <Rubidium> but that file size difference can easily be explained by the encoding, can't it?
21:56:35  <Yexo> yep
21:56:36  <Rubidium> in that case, just force both to use the same compression
21:56:56  <Yexo> 10k difference actually, but 306k vs 316k is easily explained by compression
21:58:53  <Yexo> hmm, only way I could think of was "-u" for both programs, but than the difference becomes much bigger (429k for nml vs 510k for grfcodec)
21:59:47  <Rubidium> but nml tries both compression algorithms and choses the best
22:00:14  <Rubidium> whereas grfcodec just uses the one specified
22:01:00  <Rubidium> but what's better to compare is the decoded spritesheets + decoded nfo of both encoded grfs
22:01:31  <Yexo> you're right. I thought -u would disable all compression, but there is still the difference of tile compression vs sprite compression
22:01:36  <Yexo> -u only disables lz77
22:01:40  <Brot6> OpenGFX - Revision 928:ab2f4a234336: Fix (r925): Backporting involves changing the palette from D... (planetmaker) @
22:01:40  <Brot6> OpenGFX - Revision 929:de4381807ea5: Added tag 0.4.3 for changeset ab2f4a234336 (planetmaker) @
22:02:25  *** JVassie has quit IRC
22:03:32  <Yexo> now I do get the "Offset too large" error again
22:04:04  *** andythenorth has quit IRC
22:04:07  <Rubidium> wdf
22:04:33  <Yexo> that was with the -u flag, without -u I get "Not enough input data for decompression of sprite 3183"
22:04:34  *** frosch123 has quit IRC
22:04:38  <Yexo> something is going really wrong :(
22:05:22  <Yexo> something for tomorrow
22:05:26  <Yexo> good night everyone
22:05:40  <Rubidium> night Yexo
22:06:13  <planetmaker> g'night Yexo
22:13:45  *** ODM has quit IRC
22:26:32  <Brot6> Britrains (Python Script) - Bug #3708 (Assigned): Upload Code (Leanden) @
22:26:32  <Brot6> Britrains (Python Script) - Bug #3708 (Assigned): Upload Code (Leanden) @
22:31:48  <Brot6> opengfx: update from 0.4.3 to 0.4.3 done -
22:34:19  <Rubidium> planetmaker: is that the one?
22:36:29  <planetmaker> yes
22:36:40  <planetmaker> should be
22:36:57  <planetmaker> but I'll check
22:41:46  <planetmaker> yes, that's the one. It has the right version
22:41:55  <planetmaker> I'll upload it to banananannanananananananaas
22:44:30  <planetmaker> deed done, Rubidium
22:44:39  <planetmaker> finally one has to say
22:47:34  <Rubidium> also used it for the installers now
22:47:59  <planetmaker> nice
23:02:02  *** LordAro has quit IRC
23:33:19  *** KenjiE20 has quit IRC
23:34:28  *** KenjiE20 has joined #openttdcoop.devzone

Powered by YARRSTE version: svn-trunk