Log for #openttdcoop.devzone on 1st March 2012:
Times are UTC Toggle Colours
00:03:08  <Brot6> opengfx: update from r940 to r959 done -
00:06:42  <planetmaker> eh, did someone trigger that?
00:06:53  <planetmaker> or is the clock that wrong?
00:43:34  <Brot6> Central European Train Set - Revision 650:b24dfd54c72b: Codechange: Prepare for sprites with diff... (oberhuemer) @
00:52:24  <Brot6> Central European Train Set - Feature #3620: Use 32 bpp sprites (oberhuemer) @
00:53:54  <Brot6> Central European Train Set - Feature #3620: Use 32 bpp sprites (oberhuemer) @
00:57:37  <Brot6> cets: update from r647 to r650 done (187 warnings) -
01:32:24  <Brot6> Britrains (BROS based on CETS) - Revision 20:b78d9ebd63c8: Codechange: equivalent to CETS revisio... (oberhuemer) @
01:37:03  <Brot6> britrains: update from r15 to r20 done (2 warnings) -
02:18:09  <Brot6> Central European Train Set - Feature #3620: Use 32 bpp sprites (michi_cc) @
05:27:16  *** Brot6 has quit IRC
05:27:16  *** Brot6 has joined #openttdcoop.devzone
05:41:31  <Brot6> Japanese Tracks - Feature Request #3615: Use new track type label scheme (Snail) @
06:25:57  *** JVassie has joined #openttdcoop.devzone
06:39:22  *** Zuu has joined #openttdcoop.devzone
06:47:12  <Brot6> Japanese Tracks - Feature Request #3615: Use new track type label scheme (dandan) @
06:47:58  <Brot6> Japanese Tracks - Feature Request #3615: Use new track type label scheme (dandan) @
07:01:37  *** JVassie has quit IRC
07:09:10  *** andythenorth has joined #openttdcoop.devzone
07:12:42  *** Zuu has quit IRC
07:59:38  <Brot6> OpenGFX - Bug #3761 (Rejected): DevZone compile failed (compiler) @
07:59:38  <Brot6> OpenGFX - Bug #3761 (Rejected): DevZone compile failed (planetmaker) @
10:12:55  *** andythenorth has quit IRC
11:37:50  <Ammler> <Brot6> [01:03:07] opengfx: update from r940 to r959 done -
11:38:11  <Ammler> if you commit something and the last build was failing, it does build
11:38:36  <Ammler> planetmaker: that is so you can fix and check a compile issue immediately
11:38:59  <Ammler> that feature is up quite a long time already :-)
11:46:58  *** andythenorth has joined #openttdcoop.devzone
11:53:54  *** orudge` has joined #openttdcoop.devzone
11:54:52  <planetmaker> Ammler, yes... though I wondered... I guess the build time is just so long that I didn't relate it to my commit :-)
11:55:11  *** orudge` has quit IRC
11:57:34  <Ammler> debzone builds it twice
11:57:48  <Ammler> and only one thread
11:58:39  <planetmaker> yeah, I know. But I keep forgetting the long build time :-)
11:58:53  <planetmaker> especially as I try to avoid full rebuilds locally ;-)
11:59:04  <planetmaker> when just working on one feature
12:01:21  <andythenorth> how long does it take?
12:04:19  <planetmaker> half an hour
12:05:08  <andythenorth> ho
12:05:12  <andythenorth> long enough
12:05:41  <andythenorth> have you profiled it any?
12:06:06  <planetmaker> not recently. Though... what do you want to profile?
12:06:35  <planetmaker> it simply takes long for NML to build the single grfs.
12:07:01  <planetmaker> And if you require generation of all pngs which can be generated, add the time for gimp as well
12:08:16  <andythenorth> I was wondering how long the generation took
12:08:39  <andythenorth> also does nml build everything, or is it nml->nfo->grfcodec?
12:08:50  <planetmaker> nml builds everything
12:09:49  <andythenorth> have you tried the alternative route?  It was ~50% faster for BANDIT
12:10:12  <planetmaker> no, I haven't
12:11:26  <planetmaker> andythenorth, are you, btw, sure that the recycling depots miss the location code?
12:11:44  <andythenorth> I can't see it anywhere
12:11:45  <planetmaker> Did you check the source? Or do you just claim that it was missed?
12:12:17  <andythenorth> which do you think?
12:12:53  <planetmaker> I think there's no check for one-per-town in the code :-)
12:13:03  <planetmaker> for the recycling depot
12:13:10  <andythenorth> +1
12:14:21  <planetmaker> Strange, I have memories of adding something like that... must have been another industry then.
12:14:47  <andythenorth> you certainly fixed the production code for that industry
12:16:37  <andythenorth> I'll raise a ticket
12:19:32  <Brot6> FIRS Industry Replacement Set - Bug #3762 (New): Recycling Depot misses check for '1 per town' (andythenorth) @
12:25:46  <Hirundo> what part of nml is slow? gfx output?
12:27:13  <andythenorth> someone profiled it recently and found some points
12:27:24  <andythenorth> I'd be pure guessing if I tried to remember what though
12:27:28  <andythenorth> it was discussed in #openttd
12:28:16  <andythenorth> eddi was around at the time, he might remember...or alberth
12:29:05  <planetmaker> Hirundo, yes-ish. As for a baseset grf not much else is needed
12:30:23  <planetmaker> still, it's writing like 5k real sprites for ogfx1_base.grf
12:31:21  <Hirundo> If sprite compression (tile compr and lz77) takes much time, it might make sense to skip that for debug builds
12:32:54  <Hirundo> Analogous, if I'm messing with ottd source, I don't enable all optimizations either
12:35:01  <planetmaker> Might be. That'll need test. Not sure of the amount of influence of those options
12:37:21  <planetmaker> <-- other story. Sensible?
12:39:30  <planetmaker> hg ci -m "Codechange: Remove hysterical letters from grf file names"
12:41:56  * andythenorth wondered wtf those letters were for ;)
12:42:14  <andythenorth> did you fix your ottd btw?
12:45:00  <planetmaker> yes
12:45:32  <planetmaker> andythenorth, you really don't know the meaning of those letters? Check the filenames of the TTD base set
12:46:55  <andythenorth> trg1r.grf and such?
12:58:48  <planetmaker> yep
12:59:08  <planetmaker> it's the same letter as in those names
13:05:36  <Ammler> planetmaker: if nml does not want to add the grfid -m and we need grfcodec anyway, we could use also grfcodec
13:06:04  <Ammler> but the bottleneck is gimp though
13:06:49  <planetmaker> indeed.... that stops us building the 6 grfs in parallel
13:07:10  <Ammler> nml needs maybe 1 min
13:07:16  <Ammler> of those 15
13:07:25  <planetmaker> really?
13:07:41  <Ammler> really what?
13:09:05  <planetmaker> those time information
13:09:11  <Ammler> I just meant, using grfcodec instead nml gives us some seconds
13:09:27  <Ammler> which does not matter as the whole build time is 15mins
13:09:37  <andythenorth> what is gimp doing?  (I assume exporting layers or such?)
13:09:58  <Ammler> yes
13:10:01  <planetmaker> yep
13:10:10  <andythenorth> it can't run multiple gimp processes?
13:10:15  <andythenorth> or something?
13:10:20  <Ammler> I assume, it is like starting gimp everytime again per png
13:10:21  <planetmaker> gimp is buggy in that respect
13:10:43  <planetmaker> and it doesn't like to run several gimp instances on one computer
13:10:50  <andythenorth> multiple vms? :P
13:10:54  <planetmaker> it often works. But it can fail
13:11:07  <andythenorth> sftp the resulting pngs to a common folder?
13:11:10  <planetmaker> and failure is the more likely the more instances run in parallel
13:11:26  <Ammler> andythenorth: stay serious :-P
13:11:30  <planetmaker> ehm... that requires on VM per gimp instance, thus per generated png?
13:11:41  <andythenorth> Ammler: I am 50% serious
13:11:44  <Ammler> :-D
13:11:53  <andythenorth> it's a paralelisation problem?
13:12:04  <planetmaker> yes
13:12:11  <Ammler> yes, devzone forces one thread because of opengfx
13:12:25  <Ammler> hmm, since we know, what causes it, we could change that for the rest again
13:12:25  <planetmaker> gimp always uses a certain file in the tmp folder. Always the same. That collides randomly
13:12:45  <planetmaker> Ammler, it doesn't matter. Other grfs won't profit
13:12:57  <planetmaker> And those which use gimp will then fail, too
13:13:12  <Ammler> ah, it's not just opengfx
13:13:23  <planetmaker> it's gimp, yes
13:13:33  <Ammler> I mean, it's not just opengfx using gimp
13:13:37  * andythenorth explores
13:13:41  <planetmaker> and I guess before gimp 3.0 there's no help. Maybe not even then
13:13:53  <andythenorth> I think there's no answer in that link though :(
13:14:46  <andythenorth> ooh
13:14:47  <Webster> Title: jerem/psdparse - GitHub (at
13:14:49  <andythenorth> hmm
13:15:02  <andythenorth> might be useful to me, even if it fails for opengfx....
13:15:02  <Ammler> submitted openttd to factory today \o/
13:15:03  <andythenorth> let's see
13:15:12  <Ammler> I wonder how long this will take now
13:15:15  <andythenorth> "This utility parses and prints a description of various structures
13:15:16  <andythenorth> inside an Adobe Photoshop(TM) PSD format file.
13:15:16  <andythenorth> It can optionally extract raster layers and spot/alpha channels to PNG files."
13:15:26  <andythenorth> do you have gimp or psd format?
13:15:32  <Ammler> does it matter
13:15:50  <Ammler> we could save as psd if that would be required, afaik
13:16:59  <Ammler> but I would assume, that a python script which can handle psd, should also be able to handle xcf
13:17:49  <Ammler> anyway, if we find a replacement for gimp, it would be worth a try, imo
13:18:10  <andythenorth> also looks like PIL can access psd layers to some extent
13:18:11  <andythenorth>
13:18:12  <Webster> Title: [Image-SIG] Accessing Photoshop layers in PIL? (at
13:18:23  <andythenorth> maybe I'll try later
13:18:31  <andythenorth> sounds like gimp is limiting you :)
13:18:38  <Ammler> I guess, Yexo/pm already played around with that too
13:19:00  <andythenorth> I have 0% confidence I can solve it, but I can at least try
13:19:04  <Ammler> gimp is just slow, else there is no issue
13:19:44  <andythenorth> faster is better - makes testing esaier
13:19:52  <andythenorth> testing => higher quality result
13:19:56  <andythenorth> unlike my spelling above :P
13:20:19  <Ammler> well, thanks to Makefile, you don't need to build everything again
13:20:27  <Ammler> (on dev)
13:20:56  <andythenorth> well I have my own reasons for wanting to open layered psds with PIL, so I'll try
13:21:03  <Ammler> so the issue is just an issue on a building system where it does not matter
13:21:11  <andythenorth> and if it's useful you're welcome to take it ;)  Otherwise not ;)
13:21:18  <Ammler> but still, it would be nice to get a faster solution
13:37:16  <Brot6> BANDIT - Revision 324:4af00a8d986b: Codechange: move some things to a common file for gestalts (andythenorth) @
13:37:16  <Brot6> BANDIT - Revision 325:4fed95967762: Codechange: refactor handling of colours to draw, including p... (andythenorth) @
14:58:16  <Brot6> BANDIT - Revision 326:e6e9194baa24: Codechange: improved a comment (andythenorth) @
16:01:55  <Rubidium> planetmaker: to what extent are the rail graphics (going to be) constructed using gimp?
16:02:57  *** andythenorth has quit IRC
16:03:48  <Rubidium> so should I just cut up the rail/road tiles as they are, or are they going to be composited in some way any time soon? (mostly infra06/infra08)
17:18:32  *** Zuu has joined #openttdcoop.devzone
17:27:14  <Brot6> firs: update from r2710 to r2712 done (6 warnings) -
17:29:21  <Brot6> bandit: update from r293 to r326 done (1 warnings) -
17:30:58  *** andythenorth has joined #openttdcoop.devzone
17:34:59  <planetmaker> Rubidium, there exists already a gimp file... Let me look where
17:36:38  <planetmaker> there it is ogfx-landscape/src/gfx/infrastructure.xcf
17:37:24  <planetmaker> it's basically missing monorail
17:38:11  <planetmaker> the sprite templates are in ogfx-landscape/src/templates_sprites.pnml
17:38:26  <planetmaker> it's tmpl_infrastructure_road and tmpl_infrastructure_tracks
17:38:36  <Brot6> cets: update from r647 to r650 done (187 warnings) -
17:40:43  <planetmaker> I'm currently not 100% sure. The rail and maglev tracks *might* need some graphical fine-tuning. But...
17:40:51  <Brot6> dutchtrains: update from r222 to r272 done -
17:42:50  <Brot6> britrains: update from r3 to r20 done (2 warnings) -
17:44:37  <Brot6> ogfx-trains: rebuild of r296 done (70 warnings) (Diffsize: 29712) (DiffDiffsize: 3193) -
17:44:57  <planetmaker> 70 warnings, eh?
17:46:07  <planetmaker> aha. refittable_cargo_types
17:47:03  <Brot6> ogfx-industries: rebuild of r132 done (Diffsize: 127099) (DiffDiffsize: 844) -
17:47:52  <andythenorth> we think WTFPL is upwards compatible to GPL don't we?
17:48:07  <Brot6> OpenGFX+ Trains - Code Review #3763 (New): replace refittable_cargo_types (planetmaker) @
17:49:44  <Brot6> OpenGFX+ Trains - Code Review #3764 (New): replace shorten_vehicle (planetmaker) @
17:50:25  <Brot6> foobarstramtracks: rebuild of r23 done (Diffsize: 28769) (DiffDiffsize: 7505) -
17:58:56  <Ammler> andythenorth: no
17:59:03  <Ammler> wtf is wtf
17:59:46  <Ammler> it is fine for artists but not for a project
18:00:39  <Ammler> there is exact one license possible for devzone: gpl
18:00:46  <Brot6> OpenGFX+ Trains - Code Review #3764 (Closed): replace shorten_vehicle (planetmaker) @
18:00:46  <Brot6> OpenGFX+ Trains - Revision 297:a6d97320bac8: Fix #3764: Use the 'length' callback instead of the ... (planetmaker) @
18:00:46  <Brot6> OpenGFX+ Trains - Code Review #3764 (Closed): replace shorten_vehicle (planetmaker) @
18:01:09  <planetmaker> nah... I think we really should be a bit more open. Especially as GPL is not GPL
18:01:21  <Ammler> well v2 or v2+
18:01:23  *** frosch123 has joined #openttdcoop.devzone
18:01:23  <planetmaker> "community-friendly" should be our guide
18:01:34  <planetmaker> and our recommendation GPL v2+
18:01:48  <Ammler> yes, gpl is the only license which is community friendly
18:02:14  <planetmaker> what is bad about CC-BY? Or 3-clause BSD?
18:02:36  <Ammler> cc-by with source is gpl
18:02:54  <planetmaker> no, it's not
18:02:59  *** ODM has joined #openttdcoop.devzone
18:03:00  <Ammler> why not?
18:03:11  <Ammler> or what not?
18:03:12  <planetmaker> the difference is where you can use the code released under CC-BY
18:03:23  <planetmaker> which is: basically everywhere
18:03:41  <Ammler> so it is more open as gpl which means, it is fine
18:04:00  <planetmaker> same with the BSD-style
18:04:05  <Ammler> but it does not provide source so it isn't fine
18:04:23  <andythenorth> Ammler: I didn't ask about devzone though
18:04:23  <planetmaker> point is: if we host the project, the source is there: here
18:04:41  <andythenorth> I want to know if WTFPL stuff can be incorporated into a GPL project
18:04:43  <Ammler> andythenorth: as long as it is more open, it is good
18:04:46  <planetmaker> andythenorth, it can
18:04:47  <andythenorth> I think it can be
18:05:02  <andythenorth> *subject to sources also being released under WTFPL at same time
18:05:02  <Ammler> andythenorth: wtf is like public domain
18:05:24  <Ammler> it might be as much illegal as public domain in some countries :-)
18:05:26  <andythenorth> if the author doesn't put the sources out, it's tricky for GPL inclusion
18:05:37  <andythenorth> Ammler: no-one has proven the GPL is legal yet either AFAIK :P
18:05:57  <planetmaker> andythenorth, it's been proven to be successful in court.
18:06:07  <planetmaker> and... any license is legal...
18:06:15  <Ammler> :-)
18:06:43  <Brot6> rust: rebuild of r23 done (15 warnings) (Diffsize: 6813) (DiffDiffsize: 1110) -
18:06:54  <Ammler> well, how you call public domain in your country then, planetmaker?
18:07:22  <planetmaker> "gemeinfrei"
18:07:32  <Ammler> and it's legal?
18:07:37  <Ammler> I thought, it isn't
18:08:12  <andythenorth>
18:08:13  <Webster> Title: Will We Ever Have a GPL Test Case? (at
18:08:25  <planetmaker> there's some subtle differences. You cannot forfeit authorship here (which public domain does)
18:08:35  <Brot6> dutchtramset: rebuild of r113 done (21 warnings) (Diffsize: 20613) (DiffDiffsize: 3023) -
18:08:47  <Rubidium> planetmaker: so effort is better spent copying code from ogfx-landscape in that case, right?
18:08:55  <Ammler> andythenorth: if you read such things, please check date
18:08:59  <planetmaker> Rubidium, quite so, yes
18:09:09  <andythenorth> Ammler: I saw the date, I wondered if it's updated since then...
18:09:17  <Brot6> swisstowns: rebuild of r22 done (Diffsize: 51) (DiffDiffsize: 19) -
18:09:25  <planetmaker> it's basically all there. And I didn't yet transfer it simply on grounds of "it works"
18:09:59  <planetmaker> but nicer is to transfer it, no doubt :-)
18:10:21  <planetmaker> actually... even the png generation can be transferred...
18:10:23  <Ammler> planetmaker: the issue is that authors would like to use a more close license than more open as gpl
18:10:33  <Brot6> make-nml: compile of r0 still failed (#3730) -
18:10:40  <Ammler> that is what I meant with gpl only
18:11:07  <Brot6> metrotrackset: rebuild of r56 done (Diffsize: 7) (DiffDiffsize: 10) -
18:11:21  <andythenorth> other licenses are insufficiently restrictive :(
18:11:35  <andythenorth> GPL is sufficiently restrictive :)
18:12:24  <andythenorth> hmm
18:12:36  <andythenorth> there is GPL case law outside the US
18:12:56  <planetmaker> hm, Rubidium, seems ogfx+landscape does not yet generate the pngs from the xcf
18:13:25  <Rubidium> :(
18:13:49  <Rubidium> something for after dinner and telly
18:14:34  <planetmaker> though the pngs are clearly exported from that xcf. Thus the export file is missing basically
18:14:41  <Ammler> andythenorth: so if you do not care about license, what wtfpl basically means, you can as good use gpl
18:14:43  <Brot6> dutchroadfurniture: rebuild of r145 done (Diffsize: 165910) (DiffDiffsize: 2958) -
18:15:20  <Ammler> also the avantage is if someone forks your thins, he is forced to use gpl to
18:15:22  <Ammler> o
18:15:45  <Ammler> else he could fork and license it as nc or nd or whatever bad
18:15:49  *** Zuu has quit IRC
18:17:13  <planetmaker> oh, Rubidium, there are some important layers still missing in the infrastructure.xcf: The grid lines
18:17:27  <andythenorth> Ammler: that's what I mean by "sufficiently restrictive" ;)
18:18:42  <Ammler> but why you ask such a question, what disadvantage does gpl have?
18:18:57  <planetmaker> the grid lines would need import and adjustment from the landscape xcf which you already know
18:20:10  <Brot6> ogfx-rv: rebuild of r142 done (42 warnings) (Diffsize: 20398) (DiffDiffsize: 4000) -
18:22:12  <andythenorth> Ammler: I was just wondering whether to tell neko to use GPL or WTFPL
18:22:15  <andythenorth> I think GPL...
18:22:38  <andythenorth>
18:22:39  <Webster> Title: Transport Tycoon Forums View topic - [OTTD] NARS Plus (Unofficial addon set) (at
18:24:31  <Brot6> ogfx-landscape: rebuild of r110 done (2 warnings) (Diffsize: 31742) (DiffDiffsize: 4900) -
18:26:37  <planetmaker> o_O that's a "coarse" understanding of what licenses mean and what purpose they serve
18:27:13  <Brot6> swedishrails: rebuild of r237 done (Diffsize: 9075) (DiffDiffsize: 1482) -
18:27:57  <Brot6> german-townnames: rebuild of r35 done (Diffsize: 5042) (DiffDiffsize: 19) -
18:28:36  <andythenorth> planetmaker: if you refer to neko - coarse comes with the territory :)
18:28:40  <Brot6> smts: rebuild of r19 done (Diffsize: 14) (DiffDiffsize: 12) -
18:28:54  <planetmaker> I did refer to that, yes
18:30:24  <Brot6> dach: rebuild of r54 done (104 warnings) (Diffsize: 25201) (DiffDiffsize: 3497) -
18:31:12  <Brot6> belarusiantowns: rebuild of r8 done (Diffsize: 72) (DiffDiffsize: 19) -
18:36:40  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: bros (1 warnings), transrapidtrackset (Diffsize: 6), 2cctrainset (78 warnings), worldairlinersset (Diffsize: 6), heqs, basecosts, water-features (Diffsize: 6), isr (2 warnings) (Diffsize: 1367), 32bpp-extra (2 warnings), manindu (Diffsize: 2), newgrf_makefile (Diffsize: 1), snowlinemod, spanishtowns (Diffsize: 8), frenchtowns (Diffsize: 21), fish,
18:36:40  <Brot6> ttrs (7 warnings), ogfx-trees (Diffsize: 6), chips (1 warnings), indonesiantowns (1 warnings) (Diffsize: 350), airportsplus (Diffsize: 1161), comic-houses (3 warnings) (Diffsize: 22)
18:40:09  <Ammler> andythenorth: important is using one
18:40:15  <Ammler> and no nc and no nd
18:51:03  *** frosch123 has quit IRC
19:17:53  <Brot6> OpenGFX+ Trains - Code Review #3763: replace refittable_cargo_types (yexo) @
19:18:50  *** Zuu has joined #openttdcoop.devzone
19:20:23  <planetmaker> Yexo, seems we have two half-finished cargo types things for ogfx+trains ;-) Unfortunately I also started at the top :-)
19:20:44  <planetmaker> and yes, also quite some time ago... :-)
19:20:57  <Yexo> for me it was last weekend
19:22:18  <planetmaker> then it's my fault
19:33:19  *** JVassie has joined #openttdcoop.devzone
19:56:34  <Yexo> wrt #3732: what would you like as output?
19:56:35  <Brot6> Yexo: #3732 is "NewGRF Meta Language - Feature Request #3732: nml command to get grfdata md5sum? - #openttdcoop Development Zone"
20:02:50  <planetmaker> the output of grfid
20:02:53  <planetmaker> grfid -m
20:03:16  <planetmaker> as such what OpenTTD displays as well ingame for that NewGRF
20:05:17  <Yexo> yes, but to where? stdout, stderr, a file?
20:14:56  <planetmaker> well... The question really is how that should be done...
20:15:07  <planetmaker> If it's a separate call to nml, I'd say it should go to stdout
20:15:20  <planetmaker> If it then need to to a file it can be piped
20:15:43  <planetmaker> That'd also be useful for OpenGFX as I then could replace the grfid call by the respective nml call
20:16:01  <planetmaker> maybe "nmlc -m file" as typical call?
20:17:34  <Yexo> it's not a separate call, it's computed when the grf is build
20:17:45  <planetmaker> hm
20:17:55  <Yexo> if you want it as a separate call you can keep using grfid, no reason to duplicate that functionality
20:18:07  <planetmaker> it's a separate dep for building opengfx
20:18:24  <Yexo> nmlc --grf out.grf --md5 out.md5
20:18:28  <Yexo> that's an option
20:18:37  <planetmaker> I guess that's the best option we have then
20:19:57  <Yexo> otherwise I'd have to implement parsing of a grf file (at least to such an extend that the end of the data section is known) in nml, that's not something I fancy doing just to get an md5sum
20:20:09  <Yexo> especially not if an equivalent tool (grfid) already exists
20:20:12  <planetmaker> nah, that'd be clearly tmwftlb
20:20:57  <planetmaker> I guess the --md5 is a good option
20:21:26  <planetmaker> may I suggest the form as an obg file needs right away?
20:21:41  <Yexo> which is?
20:21:43  <planetmaker> ogfx_base.grf      = c768fe6799e5c9f5547ca368eed653cb
20:21:52  <Yexo> so "filename = md5sum"?
20:21:55  <Yexo> that's fine
20:22:01  <planetmaker> yup
20:22:32  <Yexo> but do you really want that? might not be so nice for md5sum checking of normal grf's
20:23:57  <planetmaker> well, that's where I'd need it "most"... I could then simply concatenate that output into the obg
20:24:30  <Yexo> echo "ogfx_base.grf =" -n >> obg; cat ogfx_base.md5 >> obg
20:24:42  <planetmaker> for each of the 6 files :-)
20:25:01  <planetmaker> but sure
20:25:06  <planetmaker> might be more versatile
20:25:22  <planetmaker> and more like the usual and expected output of an md5sum call
20:25:29  <Yexo> for f in base tropical arctic toyland; do echo ogfx_$f.grf -n >> obg; cat ogfx_$f.md5; done
20:26:56  <planetmaker> "echo blah -n >> file" prepends blah?
20:27:11  <Yexo> no, it echos without a final newline
20:27:21  <Yexo> that's the -n
20:27:51  <planetmaker> ah, ok
20:31:36  <planetmaker> ok, anyway, Just a plain md5sum will suit every need easiest is what we can conclude :-)
20:32:22  <Brot6> NewGRF Meta Language - Revision 1863:36f2cf53b0f5: Codechange: unify realsprite/template code (yexo) @
20:32:22  <Brot6> NewGRF Meta Language - Revision 1864:8590b1ce2eb0: Codechange: remove some special-casing from ma... (yexo) @
20:32:22  <Brot6> NewGRF Meta Language - Revision 1865:27a73e79df6c: Feature #3732: --md5 commandline option to wri... (yexo) @
20:33:15  <Brot6> NewGRF Meta Language - Feature Request #3732 (Closed): nml command to get grfdata md5sum? (yexo) @
20:48:11  <Rubidium> the ballast layer in ogfx-landscape's xcf looks fishy
20:48:13  <andythenorth> hmm
20:48:27  <andythenorth> PIL can do stuff with PSD layers, but not usefully so far
20:48:41  <andythenorth> if you fancy sprites that are white or transparent, it's just the tool for the job
20:49:10  <Rubidium> even then, why isn't something PIL-ish use to construct the actual underlying layer from the landscape sprites without track instead of copying those sprites manually into something else?
20:49:54  <Rubidium> this is, ofcourse, something that's going to have significant repercussions
20:51:05  <Rubidium> though it'd be interesting to see how well the actual 19-ish? landscape tiles can be constructed from just 5 tiles (flat and 4 steep slopes)
20:51:14  <andythenorth> Rubidium: I may have something that could do that :P
20:52:12  <andythenorth> many of the terrain tiles could be generated from a basic tile
20:52:25  <andythenorth> at least to me, they appear to use the same pattern, with simple recolouring
20:52:45  <Rubidium> yup
20:53:22  <Rubidium> proposing LordPixaII?
20:53:41  <Rubidium> although that'd even be a step further ;)
20:54:35  <andythenorth> right now I'd be happy if I could extract things from a PSD reliably :P
20:55:00  <V453000> andythenorth: still patient with the generator thing? :D Wouldnt you have it all drawn already by this time ? :D
20:56:02  <andythenorth> V453000: you have no idea how bored I am of clicking on pixels
20:56:18  <V453000> :D I cant imagine indeed
20:56:28  <andythenorth> nor doing copy-paste-move for load sprites and all that crap
20:56:45  <V453000> hm :)
21:02:04  <planetmaker> Rubidium, yes... it's not exactly finished...
21:03:20  <planetmaker> and I was not yet happy with the ballast so far
21:03:26  <planetmaker> looking funky with holes iirc
21:04:31  <andythenorth> V453000: the generator worked surprisingly quickly
21:04:41  <andythenorth> the slow bit has been packaging so other people can make sense of it :)
21:04:50  <V453000> oh :)
21:05:03  <V453000> looking forward to see the results
21:05:09  <andythenorth> in the thread
21:05:42  <andythenorth>
21:05:43  <Webster> Title: Transport Tycoon Forums View topic - Raster / shader project - insane? (at
21:07:15  <V453000> interesting interesting :) I meant the whole newGRF output :)
21:07:47  <andythenorth> maybe April 1
21:08:41  <V453000> :)
21:08:45  <V453000> anyway, gnight
21:09:49  <andythenorth> bye V453000
21:10:41  *** Jupix has quit IRC
21:13:20  *** Jupix has joined #openttdcoop.devzone
21:22:50  *** ODM has quit IRC
21:30:10  *** frosch123 has joined #openttdcoop.devzone
21:30:48  <andythenorth> hmm
21:30:50  <andythenorth> well
21:31:06  <andythenorth> I have layers 0, 1, 2, 3, 4 from my psd
21:31:29  <andythenorth> so there you go
21:31:33  <andythenorth> want to see the code?
21:31:34  <andythenorth> I know you do
21:31:47  *** Rubidium has left #openttdcoop.devzone
21:32:09  <andythenorth>
21:32:14  <andythenorth> I have no idea how reliable this is
21:32:44  <andythenorth> but it worked in my one test case
21:32:47  <andythenorth> planetmaker: ^
21:32:49  <Yexo> and where is that psdparser coming from?
21:33:04  <andythenorth>
21:33:05  <Webster> Title: jerem/psdparse ยท GitHub (at
21:33:14  <andythenorth> this relatively unsupported, not entirely documented project :)
21:33:21  <andythenorth> definitely production ready :P
21:33:30  <Yexo> I wouldn't expect anything else :p
21:33:51  <andythenorth> it's quite neat
21:34:06  <andythenorth> I dunno if any of you are interested in it, but I'll fool around and see if I can break it :P
21:34:15  <andythenorth> saves me a manual export step
21:34:29  <andythenorth> and makes compositing significantly easier
21:44:00  <planetmaker> Yexo, <-- the last commit breaks nml for python 2.5
21:45:15  <Yexo> untested commit that should fix it
21:45:44  <Brot6> NewGRF Meta Language - Revision 1866:8633130a4645: Fix: with statement needs import from future f... (yexo) @
21:46:13  <Yexo> and another one which actually fixes it
21:46:19  <Yexo> forgot I actually have python 2.5 installed
21:46:47  <Brot6> NewGRF Meta Language - Revision 1867:2f3755e8e611: Fix r1866: test before commit/push (yexo) @
21:58:43  <planetmaker> <-- Yexo, could you be so kind and see whether that works for you or do you have an idea why OpenTTD doesn't like the grf resulting from it (for OpenGFX+ Trains)
21:59:37  <planetmaker>
22:00:21  <planetmaker> dbg: [grf] [ogfx-trains/ogfx-trains.grf:33] LoadNewGRFFile: Unexpected sprite, disabling
22:00:51  <planetmaker> hm... I should try w/o that patch actually
22:03:22  <Brot6> BANDIT - Revision 327:fd07b0d22895: Codechange: convert tank trailer gestalt to use new Pixa methods (andythenorth) @
22:03:54  <Yexo> without that patch it doesn't load either for me
22:04:24  <Yexo> grfcodec doesn't like the grf either
22:04:27  <Yexo> that's a good sign
22:05:18  <planetmaker> indeed. It's not the patch
22:07:08  <Yexo> grfcodec is complaining about sprite 33, which is not even a real sprite...
22:07:14  <Yexo> at least, according to the nfo output from nmlc
22:07:22  <Yexo> something is seriously going wrong :(
22:10:22  <Yexo> will have to delay this to tomorrow evening or even saturday
22:10:23  <Yexo> bed time for me
22:10:26  <Yexo> good night
22:11:44  <planetmaker> sleep well
22:12:03  <planetmaker> no problem with that for me
22:17:16  <andythenorth> hmm
22:17:40  <andythenorth> when there are generated sprites with number > some
22:17:48  <andythenorth> nest them in folders, or use very long filenames?
22:17:56  <andythenorth> e.g. 7_8_tank_trailer_fifth_wheel_silver_STEL.png
22:18:06  <andythenorth> or is this a 'meh' kind of issue
22:18:27  <planetmaker> probably ;-)
22:19:17  <andythenorth> long filenames it is
22:19:58  <planetmaker> so... ogfx-trains breaks between NML r1807 and r1838
22:21:36  <andythenorth> any help?
22:21:37  <Webster> Title: BisectExtension - Mercurial (at
22:21:52  <planetmaker> no. I can't automate that
22:22:28  <planetmaker> otherwise it'd be a good one
22:22:50  <planetmaker> though hg comes with a bisect by default
22:24:09  <andythenorth> hmm
22:24:36  <planetmaker> maybe it's the same thing, though
22:25:01  <andythenorth> think so
22:25:17  * andythenorth is testing his nml projects for build errors
22:25:27  <andythenorth> maybe it's not just ogfx-trains....?
22:26:38  <Ammler> hg bisect is awesome
22:26:38  <planetmaker> probably not only
22:26:49  <planetmaker> I'm also bisecting NML. Not ogfx-trains
22:27:02  <planetmaker> andythenorth, and it's not a build error
22:27:12  <andythenorth> only shows up on loading in game?
22:27:12  <planetmaker> it's an error which needs starting openttd and using that newgrf
22:27:15  <andythenorth> k
22:27:31  <planetmaker> or rather in that case: then not using it :-(
22:28:28  <planetmaker> hm, but hg bisect indeed makes it a bit faster. Even w/o automated test
22:29:06  <planetmaker> hg bisect -b
22:29:09  <planetmaker> hg bisect -g
22:29:14  <planetmaker> and it updates automatically
22:29:22  <andythenorth> :)
22:29:25  <andythenorth> I never tried it
22:29:42  <andythenorth> frosch told me about it iirc, but I have been manually bisecting :P
22:29:49  <andythenorth> silly me
22:30:55  <andythenorth> sorry no help here, FIRS and BANDIT both work
22:30:56  <frosch123> i doubt i told you, i never  use bisect myself
22:31:00  <planetmaker> r1834 is bad, r1829 is good
22:31:18  <frosch123> always compute those numbers myself :)
22:31:33  <andythenorth> I am using nml r1867 fwiw
22:31:48  <andythenorth> the only info I have is 'not everything is broken' :P
22:32:01  <planetmaker> frosch123, it's the first time I use it...
22:33:16  <planetmaker> right... and the "winner" is r1833: Feature: use grf container format v2
22:34:48  <Ammler> still not useful to use openttd for test?
22:36:09  <Brot6> BANDIT - Revision 328:d8730870e241: Codechange: move Variation to; cleanup other stuff (andythenorth) @
22:36:26  <Brot6> NewGRF Meta Language - Bug #3765 (New): NML builds faulty OpenGFX+ Trains (r297) (planetmaker) @
22:36:38  <planetmaker> Ammler, a newgrf error on loading openttd doesn't mean openttd terminates with an error code
22:36:43  <planetmaker> so... not useful
22:37:20  <andythenorth> do you get the error in stdout?
22:37:23  <andythenorth> or such
22:37:32  <planetmaker> It shows in the console
22:37:34  <Ammler> you could grep debug, couldn't you?
22:37:52  *** JVassie has quit IRC
22:38:30  <andythenorth> if I use make run, I see newgrf errors in shell, dunno what debug levels I set
22:38:50  <andythenorth> I changed them once to help diagnose an issue
22:39:27  <andythenorth> I have seen the NARS 2 error about 50 thousand times it seems :P
22:40:45  <planetmaker> yes, that shows often ;-)
22:41:32  <andythenorth> do I need to add a license header string to every BANDIT file to be GPL compliant?
22:41:50  <planetmaker> no. But it makes code theft a tad more difficult
22:42:09  <andythenorth> if I include license.txt, is that minimal compliance?
22:42:23  <andythenorth> I want to commit someone else's GPL stuff into my repo
22:42:43  <planetmaker> you must not change his/her license notes
22:43:11  <planetmaker> but... has bandit no license.txt already?
22:43:28  <andythenorth> it does yes have one
22:43:32  <planetmaker> in any case: a license.txt coming with the bundle should iirc suffice
22:43:48  <andythenorth> k thanks
22:45:15  <planetmaker> if you pull-in a quite separate part of code: then it's at least good practise to point out the attribution explicitly
22:46:19  <Brot6> BANDIT - Revision 329:585552d861cb: Add: test of layered PSDs extraction with PIL / PSDParser (andythenorth) @
22:46:51  <planetmaker> like OpenTTD acknowledges the authorship for the md5 code etc and alike
22:47:42  <andythenorth> I'll adjust a little then
22:50:53  <Brot6> BANDIT - Revision 330:2fcc029038b1: Add: readme etc for psdparser (andythenorth) @
22:57:58  *** andythenorth has quit IRC
22:58:19  <Brot6> BANDIT - Revision 331:7b63520337b6: Codechange: some work to convert tipping trailer gestalt to P... (andythenorth) @
23:15:21  <Brot6> Central European Train Set - Revision 651:8d21f9c839cc: Codechange: different names for zoom leve... (oberhuemer) @
23:28:08  <Brot6> cets: update from r650 to r651 done (187 warnings) -
23:33:35  *** frosch123 has quit IRC
23:37:19  <Brot6> Britrains (BROS based on CETS) - Revision 21:3e42741779e3: Codechange: CETS revision 651 equivale... (oberhuemer) @
23:43:23  <Brot6> britrains: update from r20 to r21 done (2 warnings) -
23:51:40  *** Zuu has quit IRC

Powered by YARRSTE version: svn-trunk