Times are UTC Toggle Colours
05:40:49 <Brot6> BANDIT - Revision 332:fbf9e596f378: Codechange: gestalt for tipping trailers now uses Pixa methods (andythenorth) @ http://dev.openttdcoop.org/projects/bandit/repository/revisions/fbf9e596f378 05:47:00 <Brot6> BANDIT - Revision 333:2658e88e3ecf: Codechange: cleanup some load state support code (andythenorth) @ http://dev.openttdcoop.org/projects/bandit/repository/revisions/2658e88e3ecf 06:51:04 *** JVassie has joined #openttdcoop.devzone 07:18:58 *** JVassie has quit IRC 07:33:07 *** Zuu has joined #openttdcoop.devzone 07:40:26 *** andythenorth has joined #openttdcoop.devzone 08:26:28 *** Zuu has quit IRC 08:36:28 *** andythenorth has quit IRC 09:11:46 *** andythenorth has joined #openttdcoop.devzone 09:45:02 *** andythenorth has quit IRC 11:39:12 <Ammler> hmm, nml is gpl-2.0+ ? 11:39:21 <Ammler> setup.py is wrong then 11:49:08 <Ammler> planetmaker: about the licenses, maybe we can say, that the license needs at least be osi approved, which cc-by aren't 11:49:31 <Ammler> http://www.spdx.org/licenses/ 11:49:32 <Webster> Title: SPDX Standard Licenses (at www.spdx.org) 11:50:01 <Ammler> we really sucked at licensing opengfx :-( 11:50:40 <Ammler> but I guess, as excuse this happen before we get part of the managers 11:52:19 <planetmaker> well, OpenGFX is gpl v2. That's quite ok, I think 11:52:26 <planetmaker> Today I'd choose gpl v2+. But well 11:52:44 <planetmaker> and going with osi-approved licenses seems fine to me. Though I'd accept cc-by, too 11:54:30 <Brot6> NewGRF Meta Language - Bug #3766 (New): License not clearly stated as GPL-2.0+ (Ammler) @ http://dev.openttdcoop.org/issues/3766 11:55:48 <Ammler> the "legal team" of suse found this bug btw. :-) 11:56:11 <Ammler> it seems like the review the source seriously 11:56:18 <Ammler> they* 11:57:14 <planetmaker> http://www.tt-forums.net/viewtopic.php?p=998348#p998348 <-- so what do I answer? "None of the source codes I have or writes allows to use a 'no derivatives' clause"? 11:57:15 <Webster> Title: Transport Tycoon Forums View topic - [CONCEPT] Locomotion sprites to OpenTTD 32-bit graphics (at www.tt-forums.net) 11:58:09 <Ammler> planetmaker: that is up2you, I only care what will be hosted on devzone :-) 11:58:27 <Ammler> but of course you can always change your license of your "onlywork" 11:58:35 <planetmaker> everything I work in NewGRF terms will be hosted on the DevZone ;-) 11:58:50 <Ammler> well, nc-nd is a double nono 11:59:10 <planetmaker> and I'm not interested in the sprites, if I can't use them for OpenGFX or OpenGFX+ tbh 11:59:14 <Ammler> we can allow nc, but for sure no nd 11:59:25 <planetmaker> which was my plan: using them for OpenGFX+ Trains 12:00:04 <Ammler> but we really should be aware more about the + in gplv2 :-) 12:00:10 <planetmaker> thus it's absolutely true that I can't release the NewGRF. It's GPL and it needs the 8bpp sprites which I'm not even sure who drew them. 12:00:35 <planetmaker> well, yes, that's important 12:00:41 <planetmaker> or can be 12:01:28 <Ammler> planetmaker: as the owner of devzone, I would never force you to license something gplv2+, that will always be up to you :-P 12:01:53 <planetmaker> well. you're as much 'owner' of it as I am ;-) 12:02:01 <Ammler> so if you really want, well license it nc-nd 12:02:07 <planetmaker> no, I don't 12:02:23 <planetmaker> and I even may not license a derivative of OpenGFX+Trains as -nc-nd 12:02:29 <planetmaker> I don't own all copyrigh there 12:03:13 <Ammler> well, ask him, how you should do it 12:03:18 <planetmaker> besides I'm really not interested in -nc-nd licensed newgrfs 12:03:31 <Ammler> it would be best, if he comes to same conclusion as you :-) 12:08:09 <Ammler> http://www.tt-forums.net/viewtopic.php?f=36&t=47288 <-- this should be unsticked 12:08:10 <Webster> Title: Transport Tycoon Forums View topic - 32bpp-extra: a new openttdcoop project! (at www.tt-forums.net) 12:14:25 <planetmaker> did you report it? 12:14:37 <planetmaker> I've no authority in that forum 12:15:17 <planetmaker> (even though I think it would make sense to give the openttd devs that in the newgrf forum, too ;-) ) 12:18:36 <Ammler> I tried to tell that orudge many times, but ignored :-P 12:19:01 <planetmaker> it's not really important 12:19:09 <planetmaker> after all: it works 12:20:56 <Ammler> yes, but only because I bascially removed subscription on basically every thread 12:21:11 <planetmaker> eh? 12:21:43 <Ammler> well, and because I unsubscribed everywhere, I have no clue, if it is better now :-) 12:21:55 <planetmaker> what's bad? 12:22:34 <Ammler> as said, might be ok now 12:23:14 <Ammler> I do not really read the forums often anymore 12:23:30 <Brot6> Dutch Trains 2.0 - Feature #3746: Coaches (Voyager1) @ http://dev.openttdcoop.org/issues/3746#change-9864 12:23:54 <Ammler> and before I mostly read subscribed threads 12:33:09 *** andythenorth has joined #openttdcoop.devzone 15:20:10 <Brot6> Japanese Trains - Feature #3767 (New): Code MUs differently (oberhuemer) @ http://dev.openttdcoop.org/issues/3767 15:47:45 <Brot6> Japanese Trains - Feature #3767 (Assigned): Code MUs differently (oberhuemer) @ http://dev.openttdcoop.org/issues/3767 15:47:45 <Brot6> Japanese Trains - Feature #3767 (Assigned): Code MUs differently (dandan) @ http://dev.openttdcoop.org/issues/3767#change-9865 15:48:54 <Brot6> Japanese Trains - Feature #3767 (Assigned): Code MUs differently (dandan) @ http://dev.openttdcoop.org/issues/3767#change-9865 16:25:51 <Brot6> Dutch Trains 2.0 - Revision 273:08befcdde226: Feature: improved graphics of Lint41/H (graphics by... (foobar) @ http://dev.openttdcoop.org/projects/dutchtrains/repository/revisions/08befcdde226 17:16:09 <Brot6> nml: update from r1862 to r1867 done - http://bundles.openttdcoop.org/nml/nightlies/r1867 17:23:52 <Brot6> ogfx-trains: update from r296 to r297 done (48 warnings) - http://bundles.openttdcoop.org/ogfx-trains/nightlies/r297 17:26:09 <Brot6> bandit: update from r326 to r333 done (1 warnings) - http://bundles.openttdcoop.org/bandit/nightlies/r333 17:28:10 <Brot6> BANDIT - Revision 334:cce0ecfaf9d5: Change: new graphic for Hackler B80 (DanMacK) (andythenorth) @ http://dev.openttdcoop.org/projects/bandit/repository/revisions/cce0ecfaf9d5 17:29:08 <Yexo> who wrote some house drawing scripts? 17:29:29 <Yexo> I wonder if those could be used to generate good-enough quality sprites for the extra zoom levels, at least in 8bpp 17:29:38 <Yexo> might be a nice start for ogfx-houses 17:30:42 <andythenorth> zephyris did 17:31:02 <andythenorth> I proved that Pixa could do some building shapes 17:31:07 <andythenorth> but zeph's were far more house like 17:31:21 <andythenorth> although...why not just render? 17:32:25 <Yexo> render what? 17:32:26 <Yexo> Pixa might be interesting too, didn't look too closely at that yet 17:33:26 * andythenorth feels there is a world of free CGI models out there somewhere 17:33:36 <andythenorth> but turbosquid seems not to be that place :P 17:33:50 <andythenorth> are there not bazillions of google sketchup houses somewhere? 17:34:00 <Brot6> cets: update from r650 to r651 done (187 warnings) - http://bundles.openttdcoop.org/cets/nightlies/r651 17:34:01 <andythenorth> Pixa will do blocky buildings well 17:34:13 <andythenorth> teaching it to do sloped rooves is probably tmwftlb 17:34:20 <Yexo> not sure if rendering sketchup models will lead to nice sprites 17:34:46 <Yexo> it was more a general idea, don't want to start working on it just now 17:36:14 <andythenorth> I think pixa could be taught to intelligently scale 17:36:19 <andythenorth> perhaps not by me though 17:36:54 <andythenorth> I think it maybe could use interpolation to scale up quite well 17:37:15 <Brot6> dutchtrains: update from r272 to r273 done (4 warnings) - http://bundles.openttdcoop.org/dutchtrains/nightlies/r273 17:37:53 <Terkhen> I'm checking the 32bpp forum, specifically the february recap post, awesome :) 17:38:23 <Terkhen> I should work in opengfx+ road vehicles again 17:39:07 <Brot6> britrains: update from r20 to r21 done (2 warnings) - http://bundles.openttdcoop.org/britrains/nightlies/r21 17:43:08 <Brot6> OpenGFX+ Road Vehicles - Feature Request #3544 (Assigned): FS#4975 - Buses engine's power (Terkhen) @ http://dev.openttdcoop.org/issues/3544#change-9866 17:44:01 *** ODM has joined #openttdcoop.devzone 17:51:44 <andythenorth> anyone got experience handling pngs with alpha using PIL? 17:52:00 * andythenorth is about to try 17:53:18 <Brot6> NewGRF Meta Language - Bug #3765 (Closed): NML builds faulty OpenGFX+ Trains (r297) (planetmaker) @ http://dev.openttdcoop.org/issues/3765 17:53:18 <Brot6> NewGRF Meta Language - Revision 1868:f6004fbb4192: Fix #3765 r1833: some bytes intended for the d... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/f6004fbb4192 17:53:18 <Brot6> NewGRF Meta Language - Bug #3765 (Closed): NML builds faulty OpenGFX+ Trains (r297) (yexo) @ http://dev.openttdcoop.org/issues/3765#change-9867 17:53:21 <andythenorth> wondering if I need to give it RGBA or such 17:53:40 <Yexo> internet in the train is good for some things :) 17:54:02 <Yexo> planetmaker: not yet verified whether it works in openttd, but grfcodec decodes it correctly now 17:54:25 <Yexo> andythenorth: yes, nml loads rgba png's just fine 17:54:33 <Yexo> at least I think it does, haven't heard any complaints yet :p 17:54:39 <Hirundo> andythenorth: image mode is "RGBA" IIRC 17:55:01 <Yexo> in "RGB" mode every pixel is a tuple with 3 integers, in "RGBA" mode the tuple simply has 4 values 17:55:07 <Yexo> easy as that :) 17:55:14 <Hirundo> ^exactly 17:58:10 <andythenorth> k 17:58:21 <andythenorth> so I'd need to export RGBA pngs from photoshop, not paletted 17:59:09 * andythenorth wonders how paletted support alpha anyway 17:59:25 <andythenorth> does work for web graphics afaik 17:59:43 <Hirundo> you might have a RGBA palette 18:00:05 <Yexo> paletted just means that for every pixel an index in some palette is stored 18:00:21 <Yexo> each palette entry can be RGB, RGBA or whatever else you want 18:00:28 <andythenorth> http://www.libpng.org/pub/png/pngintro.html 18:00:29 <Webster> Title: Intro to PNG Features (at www.libpng.org) 18:00:37 <andythenorth> the pixel just gets an extra component 18:00:42 <Yexo> in openttd's context it's usually an 8bit RGB palette (where the exact colors are strictly defined) 18:01:12 <Brot6> Dutch Trains 2.0 - Feature #3768 (New): NID & mDDM (Voyager1) @ http://dev.openttdcoop.org/issues/3768 18:01:53 <andythenorth> the context here is compositing (imagine pasting steel coils onto a truck) 18:02:08 <Yexo> oh, seems it works a little bit differently. The palette still contains RGB information but each pixel has "palette index + alpha" 18:02:18 <andythenorth> I could ignore alpha and just not draw any pixel that is blue 18:02:58 <Yexo> if the source is already in the properly palette, just don't draw pixels with palette index 0 18:03:09 <Yexo> if the source is RGBA, use the alpha channel information 18:03:42 <andythenorth> +1 18:04:03 <andythenorth> tonight's fun project :) 18:04:31 <Yexo> hehe :) 18:06:08 <andythenorth> coding Pixa is the most ottd fun I've had in a while 18:06:23 <andythenorth> reminds me of when my job was coding flash games 18:10:40 <andythenorth> maybe I can get the images straight out of a psd with the alpha 18:11:20 <Yexo> my train is arriving :) 18:11:22 <Yexo> bye 18:11:43 <andythenorth> bye 18:13:46 <andythenorth> is it ok to rely on psds? 18:13:59 <andythenorth> from an open-ness point of view? 18:14:14 <andythenorth> I kind of do anyway, so I guess it's a moot point :P 18:27:24 *** Zuu has joined #openttdcoop.devzone 18:34:19 <Brot6> make-nml: compile of r0 still failed (#3730) - http://bundles.openttdcoop.org/make-nml/nightlies/ERROR/r0 18:43:27 *** frosch123 has joined #openttdcoop.devzone 18:54:16 <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: ogfx-industries (Diffsize: 127099), firs (6 warnings), opengfx, foobarstramtracks (Diffsize: 28769), manindu (Diffsize: 2), newgrf_makefile (Diffsize: 1), rust (15 warnings) (Diffsize: 6813), dutchtramset (21 warnings) (Diffsize: 20613), swisstowns (Diffsize: 51), dutchroadfurniture (Diffsize: 165910), spanishtowns (Diffsize: 8), frenchtowns 18:54:16 <Brot6> (Diffsize: 21), ogfx-rv (42 warnings) (Diffsize: 20398), ogfx-landscape (2 warnings) (Diffsize: 31742), swedishrails (Diffsize: 9075), german-townnames (Diffsize: 5042), dach (104 warnings) (Diffsize: 25201), belarusiantowns (Diffsize: 72), indonesiantowns (1 warnings) (Diffsize: 350), airportsplus (Diffsize: 1161) 19:02:35 <andythenorth> so what is gimp doing for opengfx? 19:02:52 <andythenorth> and do you want to test this psdparser thing? 19:02:59 <andythenorth> np if busy / not interested... 19:03:47 <Terkhen> what is psdparser? 19:04:07 <andythenorth> https://github.com/jerem/psdparse 19:04:08 <Webster> Title: jerem/psdparse ยท GitHub (at github.com) 19:04:34 <andythenorth> it appears to be a (mostly) complete python module to read psd layers 19:04:44 <andythenorth> it worked with the one psd I've tested it upon 19:05:35 <andythenorth> I mention as gimp seems to be a limiting step for compile performance 19:05:39 <Terkhen> nah, it requires coding 19:06:43 <Terkhen> but yes, gimp is annoyingly slow 19:06:54 <andythenorth> no guarantee that this other thing isn't too 19:07:13 <andythenorth> although there might also be php or perl modules for psd parsing 19:07:16 <andythenorth> or some flavour of c 19:08:45 * Terkhen would prefer a simple console application to include it inside the existing makefile framework 19:09:36 <andythenorth> python wrapper around psdparser and PIL 19:09:42 <andythenorth> probably not hard 19:09:47 <andythenorth> but I don't know the use case 19:10:40 <planetmaker> andythenorth: a psd parser won't help with gimp source files 19:11:17 <andythenorth> are they convertable? 19:11:18 <planetmaker> gimp exports layers from image files to other files 19:11:18 <andythenorth> hmm 19:11:26 <andythenorth> is gimp psd support read only? 19:11:36 <planetmaker> gimp can import psd, not sure whether it can write 19:12:58 <andythenorth> not sure PIL can work with xcf (are your files xcf?) 19:23:27 <frosch123> btw... did someone already check whether gimp can handle layers with rgb and paletted data in the same picture? 19:23:40 <frosch123> would be useful for rgbam stuff :) 19:28:35 <planetmaker> I didn't find such option so far 19:28:48 <planetmaker> the palette stuff seemed to work on all layers simultaneously 19:28:55 <planetmaker> but maybe I missed so far 19:29:13 <planetmaker> andythenorth: yes, the files are xcf. PIL's support for that is poor 19:29:34 <frosch123> yeah, that's what i remembered as well 19:30:02 <frosch123> are your scripts able to extract layers with specific names? 19:30:45 <andythenorth> hmm 19:31:04 <andythenorth> is the gimp slowness a non-problem anyway? how often is it run? 19:31:25 <frosch123> quite often after make clean :p 19:33:29 <andythenorth> I'm not sure if a PIL route would be any faster 19:33:36 <andythenorth> it's ~7s to generate 36 spritesheets atm 19:38:38 <andythenorth> although that's completely meaningless as the problems are different :P 19:44:10 <frosch123> hmm, there are "xcftools", which is said to be a command line tool that can extract layers from gimp images 19:44:30 <frosch123> my package manager knows it 19:59:22 *** ODM has quit IRC 19:59:39 *** ODM has joined #openttdcoop.devzone 20:00:16 <andythenorth> frosch123: xcftools appears to be designed for this purpose 20:00:17 <andythenorth> http://henning.makholm.net/software 20:00:18 <Webster> Title: Henning Makholm's software (at henning.makholm.net) 20:00:35 <frosch123> andythenorth: i am already trying to put it into the ogfx makefile 20:01:10 <frosch123> it contains a tool to list the names of layers as well as extracting single layers 20:01:19 <frosch123> but i guess it won't be able to handle psd 20:01:27 <frosch123> though py-imaging is said to handle psd 20:02:07 <andythenorth> orly? :) 20:02:12 <andythenorth> I'll look at that 20:02:22 <andythenorth> pyparser handles at least 1 psd so far :) 20:02:43 <andythenorth> oh py-imaging is just a synonym for PIL 20:03:04 <andythenorth> PIL handles psd read only, it can seek to layers, but seems to have trouble actually getting useful image data out of them 20:03:44 <andythenorth> it can handle the composite 'flat' image of all layers fine from a psd 20:06:25 <frosch123> imagemagick might also be a try 20:08:44 * andythenorth reads 20:09:52 <frosch123> hmm, how does the ogfx build process work... 20:10:06 <frosch123> the *scm look generated, but they are tracked by hg 20:13:54 <planetmaker> frosch123: the script only is able to operate with layer names 20:14:10 <planetmaker> the scm are tracked? 20:14:25 <frosch123> hg purge did not remove them 20:14:41 <andythenorth> hmm, google suggests imagemagick is meant to be 'better' than PIL. But it's not clear what the criteria are :P 20:14:42 <frosch123> nor did maintainer-clean 20:14:44 <planetmaker> hm... maybe I added them so that building w/o generating everything works 20:14:46 <planetmaker> probably 20:15:03 <frosch123> maintainer-clean removes the generated pngs 20:15:06 <frosch123> but not the scm 20:15:09 <planetmaker> but maintainer-clean should delete the scm 20:15:35 <frosch123> hmm, it did... 20:15:48 <frosch123> oh, hmm, does hg purge maybe skip ignored files? 20:16:14 * frosch123 is confused 20:18:04 <frosch123> ok, anyway, apparently i need to process the xcf2png with xcftools 20:18:18 <frosch123> and ogfx only generates stuff from xcf, not from psd 20:18:28 <frosch123> so, psd is no trouble 20:19:16 <andythenorth> psd is of interest to me, not ogfx :) 20:19:26 <andythenorth> I conflated the issues slightly :P 20:19:51 <frosch123> ogfx contains psd as well, but they are not involved in the build process 20:19:52 <planetmaker> with xcftools? 20:20:17 <planetmaker> gimp is uses on the scm. And the scf2png is a handwritten file 20:20:26 <frosch123> planetmaker: a package that can extract layers from xcf files 20:20:35 <frosch123> i am trying to remove the gimp dependency from ogfx 20:20:43 <frosch123> and use xcftools instead 20:20:48 <frosch123> and then see how much faster it is 20:20:51 <planetmaker> xcftools was something I recall testing 20:20:59 <planetmaker> For instance I couldn't compile it 20:21:14 <planetmaker> on my machine. Which made it quite unattractive... iirc 20:21:24 <frosch123> it's known by the debian package manager 20:21:31 <frosch123> so seems to be an osx issue 20:21:38 <planetmaker> and it's another dependency which gimp is replaced by and which is much harder to get by 20:21:52 <planetmaker> hm, it's in debian? 20:21:56 <frosch123> yes 20:22:19 <frosch123> i would not have bothered with some random thing found on the webs :) 20:22:44 <frosch123> no idea whether it is in suse 20:26:06 *** Rubidium has joined #openttdcoop.devzone 20:26:38 <planetmaker> ok, I'll have to check out that tool then again 20:26:41 <planetmaker> I guess 20:27:50 <andythenorth> hmm 20:27:58 <andythenorth> other people report compiling xcftools for mac 20:28:07 <andythenorth> I didn't try yet though 20:28:59 <planetmaker> ok, maybe I've faulty memory. It's known to happen 20:29:47 <andythenorth> I remember you tried stuff 20:30:04 <andythenorth> I've just discovered the seashore OS X app I installed to read xcf files at that time :P 20:30:15 <planetmaker> :-D 20:30:44 <andythenorth> and I guess you don't want to be dependent on layered psds 20:32:25 <frosch123> he, i found a bug in ogfx 20:32:33 <planetmaker> hm? 20:32:41 <Rubidium> what did I do wrong? ;) 20:32:47 <frosch123> my makefile aborts with "xcf2png: The image has no layer called 'GridTropical'" 20:32:55 <frosch123> and indeed there is a typo in the layer name 20:33:03 <frosch123> so, what does the current build process do? 20:33:23 <frosch123> the name in the xcf is "GridTropcial" 20:33:55 <planetmaker> oh 20:35:02 <planetmaker> I guess it should be fixed in the xcf. But... why does it build for me? 20:35:08 <planetmaker> or the devzone? 20:35:44 <Rubidium> cause gimp "silently" ignores it? 20:37:08 <frosch123> there is no GridDesert either 20:38:49 <frosch123> http://devs.openttd.org/~frosch/diffs/xcf2png.diff <- a bit hacky (since i still use the scm, though they do not really have a purpose anymore), but fast 20:39:21 <frosch123> the layer extraction takes less than a second 20:39:28 <frosch123> nml is slowest now :p 20:42:11 <Rubidium> yep, it's definitely faster 20:42:20 <Rubidium> is the resut the same? 20:42:52 <frosch123> http://paste.openttdcoop.org/show/1170/ <- result of tip + diff 20:42:52 <Rubidium> so next step'll be: make nml that much faster ;) 20:43:14 <frosch123> does someone still have a build from gimp? 20:43:23 <frosch123> so i do not have to rebuild it? :) 20:43:35 <Rubidium> the CF? 20:44:13 <Rubidium> http://bundles.openttdcoop.org/opengfx/nightlies/r959/opengfx.md5 20:44:30 <frosch123> extra is different 20:44:35 <Rubidium> tropical and extra differ 20:44:46 <frosch123> well, tropical is the bug i fixed 20:44:49 <Rubidium> possibly the M 20:44:53 <frosch123> hmm, maybe extra as well 20:44:59 <andythenorth> :o imagemagick looks insanely full featured 20:45:08 <frosch123> yes, sure, i fixed the rivers, so i changed extra 20:45:21 <frosch123> andythenorth: imagemagick is a big mess 20:45:36 <frosch123> but if it works, it works 20:46:30 <Rubidium> frosch123: I'll try a build without the Makefile change 20:47:13 <andythenorth> I'll stick with PIL :) 20:48:23 <frosch123> planetmaker: btw. the xcf2png files contained the parameters for xcf2png in just the right order :) 20:48:51 <planetmaker> does there have to be an order? 20:48:52 <frosch123> eugh... 20:49:08 <frosch123> only now i notice that they are called the same... xcf2png 20:49:21 <frosch123> planetmaker: i just prepend a "xcf2png -o" 20:49:26 <Rubidium> tropical has the same md5sum as you got when built with gimp 20:49:42 <frosch123> "-o" is followed by the output filename, then comes the xcf filename, and then the layer names 20:52:34 <Rubidium> xcf2png seems to yield the exact same result as gimp 21:00:31 <planetmaker> if it's really that much faster... it's definitely worth it 21:01:41 <Brot6> OpenGFX - Bug #3769 (New): waterfeatures.xcf2png references wrong layers (frosch) @ http://dev.openttdcoop.org/issues/3769 21:02:08 <frosch123> ^^ the bug with the typo is obvious, but i have no idea how the desert grid is supposed to be 21:03:22 <frosch123> devzone uses suse, doesn't it? does suse know xcf2png? 21:07:29 <Rubidium> xcf2png: real 0m0.012s 21:07:35 <Rubidium> (for a single png) 21:07:52 <Rubidium> sprites/png/trees/temperate/tree_wide_01_leaf.gimp.scm in this case 21:08:34 <Rubidium> gimp: real 0m1.843s 21:08:55 <Rubidium> for xcf2png I took the longest of 4 runs, for gimp I took the shortest of 4 runs ;) 21:10:28 <frosch123> how unfair :p 21:10:45 <Brot6> SuperLib - Revision 52:c8e972fd480a: Remove: unused variables (Zuu) @ http://dev.openttdcoop.org/projects/superlib/repository/revisions/c8e972fd480a 21:10:46 <Brot6> SuperLib - Revision 53:6441a5468884: Feature: Functions for storing data in vehicles/stations (or... (Zuu) @ http://dev.openttdcoop.org/projects/superlib/repository/revisions/6441a5468884 21:11:49 <Rubidium> yeah, 150 times faster vs 200 times faster (average of xcf2png was a little over 9);) 21:12:24 <Rubidium> with a deviation of like 30% ;) 21:12:40 <Rubidium> the gimp ones were (relatively) much closer 21:14:11 <michi_cc> planetmaker: I tried compiling xcf2png on cygwin just out of curiosity, and I had to apply the debian patches to get it to work, so maybe you have to do that for OS X as well. 21:14:27 <Brot6> SuperLib - Revision 54:2309bfa95d8e: Fix: Forgot to commit the actual new source file (Zuu) @ http://dev.openttdcoop.org/projects/superlib/repository/revisions/2309bfa95d8e 21:14:29 <frosch123> lol 21:14:46 <frosch123> so, it is maintained by debian :p 21:15:46 <michi_cc> Well, it's only two important patches, one is for libpng14+ (so not needed if you still have 1.2) and the other fixed some makefile problem with libs. 21:19:43 <Ammler> planetmaker: gimp supports export to psd, as foobar worked on ogfx, we agreed to save gimp files as psd 21:20:59 * frosch123 would have suggested the convert all psd to xcf just for the better build process 21:22:29 <Ammler> also if another tool needs first building, I would stay with gimp as tht is part of standard repos on the known distros :-) 21:23:00 <Ammler> or it could be part of nml 21:23:03 <frosch123> xcf2png should at least be an alternative to gimp 21:23:24 <frosch123> and it is part of the good distros :p 21:24:01 <frosch123> debian and gentoo have it 21:24:18 <Rubidium> and fedora 21:24:31 <Ammler> what is package name? 21:24:36 <frosch123> xcftools 21:24:36 <Rubidium> xcftools 21:24:49 <Rubidium> oswatershed.org/pkg/xcftools 21:25:13 <Ammler> well, that des not exist on suse 21:26:08 <Rubidium> though the question is whether an at least factor 200 speedup of image creation is wanted or not (and the ability to run it on all cores at once) 21:26:27 <Rubidium> thus speeding it up even more 21:26:45 <frosch123> Rubidium: the makefile can check for both xcf2png and gimp 21:26:52 <frosch123> and use whatever it available 21:27:13 <frosch123> so, the proper distributions can build fast :p 21:27:23 <Rubidium> there is one caveat... 21:27:38 <Rubidium> ... xcf2png results in different PNGs (binary) than gimp 21:27:42 <Ammler> why not use psd and the tool andythenorth suggested? 21:28:05 <frosch123> because it is only a suggestion yet? 21:28:13 <Rubidium> Ammler: because that's a proprietary format? 21:28:23 <Ammler> yes, but a python script might be easiesr 21:28:41 <Ammler> coud be included to nml 21:28:47 <frosch123> didn't andy said the python thingie does not work with psd? 21:29:06 <Ammler> I thought, it doesn't with xcf :-) 21:29:07 <michi_cc> psdparser seems to be even more obscure than xcftools, can't find it in debian for example. 21:29:14 <frosch123> (i thought you were refering to imagemagick) 21:29:55 <Ammler> michi_cc: it is just script using pil, afaik 21:31:11 <Rubidium> anyhow... you'd be choosing between 21:31:39 <Rubidium> a) a proprietary format with a random person that tried to understand said format and wrote some script for it 21:31:52 <Rubidium> b) an open format with a tool written by the author of the format 21:34:18 <Ammler> I would chose b :-P 21:34:52 <michi_cc> Get suse to carry xcftools then, even debian can do it :) 21:35:10 <Rubidium> also, if you are so vocal about "only" allowing GPL (or other free stuff) on your server, why would you allow a non-free format in favor of a closed/proprietary format? 21:35:12 <Ammler> ah, that would be no big deal 21:35:19 <andythenorth> psdparser is a non-supported tool 21:35:35 <andythenorth> with only two contributors and no distributions 21:36:18 <Ammler> michi_cc: specially if fedora has it, it is mostly easy to copy the spec 21:36:25 <andythenorth> I'm dubious about using psdparser even during graphics generation 21:37:08 <andythenorth> I might try it anyway 21:37:33 <Ammler> xcftools might also be able to handle psd maybe 21:37:46 <andythenorth> no. xcf only afaict 21:38:08 <andythenorth> you'd script gimp to do the psd, then xcftools to get the layers out 21:38:10 <andythenorth> maybe 21:38:23 <frosch123> Ammler: no, it can only handle xcf 21:38:26 <frosch123> i tried it :) 21:38:38 <Rubidium> just convert psd to xcf once 21:38:59 <andythenorth> how many loading states are needed for a vehicle? 21:39:00 <andythenorth> 3? 4? 21:39:10 <andythenorth> I could template for n, but it's tmwftlb 21:39:15 <andythenorth> I need to pick a number... 21:39:49 <frosch123> with extra zoom you might need more :p 21:40:13 <frosch123> anyway, it depends on the loading speed and capacity of your vehicle 21:40:29 <frosch123> it makes no sense to define more graphics than the vehicle will usually take cargo for 21:42:05 <andythenorth> ach, I'll pick 4 :) 21:43:08 * Rubidium ponders whether/how/where to continue with refactoring the sprite sheets of opengfx 21:44:25 <andythenorth> write a PIL script to detect blue boxes, then make each one a png :P 21:44:31 <andythenorth> perhaps not entirely helpful 21:44:42 <andythenorth> "PNG is pronounced ping" 21:44:45 <andythenorth> how stupid 21:45:28 <frosch123> andythenorth: considering terrain.xcf with its about 50+ layers, ogfx seems to take a different approach :) 21:47:24 <Rubidium> actually, for terrains you should be able to generate all (clear) sprites from ~40 sprites 21:47:39 <Brot6> BANDIT - Feature #3684 (Rejected): Draw box trailers to various lengths + styles (andythenorth) @ http://dev.openttdcoop.org/issues/3684#change-9869 21:47:39 <Brot6> BANDIT - Feature #3689 (Rejected): Draw pup version of trailer (andythenorth) @ http://dev.openttdcoop.org/issues/3689#change-9870 21:47:41 <planetmaker> well... yes, maybe 21:47:45 <Rubidium> or even less if you use recolouring 21:48:03 <planetmaker> might actually be nice. 21:48:09 <andythenorth> recolouring ftw 21:48:34 <Rubidium> then... 10 sprites (5 generic, 5 toyland) and 10 recolourings 21:48:52 <planetmaker> The xcf as they are, are created for two reasons: easy grid + no grid versions. And easy overlay with shores, rivers, infrastructure, canals etc 21:48:59 <planetmaker> thus the latter match the ground 21:49:38 <Brot6> SuperLib - Revision 55:d6b6c4bb8097: Add: Initial support for building airports for industries (Zuu) @ http://dev.openttdcoop.org/projects/superlib/repository/revisions/d6b6c4bb8097 21:49:39 <Brot6> SuperLib - Revision 56:85775c1fe829: Add: Functions to find char or string in a string from the back (Zuu) @ http://dev.openttdcoop.org/projects/superlib/repository/revisions/85775c1fe829 21:49:39 <Brot6> SuperLib - Revision 57:8086c6510fbf: Fix: ReadStrFromObjectName didn't work. Also relocate code t... (Zuu) @ http://dev.openttdcoop.org/projects/superlib/repository/revisions/8086c6510fbf 21:49:40 <Rubidium> hmm, more recolorings actually, although you could construct the intermediate recolourings from the "empty" and "full" tile recolourings 21:49:53 <planetmaker> For the sake of generating the ground sprites along, it's not worth it. The important thing is the composition with the overlays 21:49:57 <planetmaker> *alone 21:50:23 <Rubidium> planetmaker: yes, these generated sprites should then be the base for further composition 21:51:23 <andythenorth> could generate gridlines / no gridlines 21:51:43 <Rubidium> however, what annoyed me was that I was seeing the same sprites over and over again as underlying layer 21:51:50 <frosch123> andythenorth: ogfx already does so 21:52:05 <Rubidium> being copied over and over again making it very hard to change the ground tiles reliably 21:52:17 <andythenorth> same problem I have in my sets 21:52:58 <planetmaker> Rubidium: well, mostly I contained it to two files meanwhile: terrain.xcf and infrastructure.xcf 21:53:07 <planetmaker> and indeed, that copying annoyed me quite a lot 21:53:28 <planetmaker> missing basically is the use of the ground tiles in some industries and houses 21:53:47 <Rubidium> planetmaker: what about the sprite sheets I recently extracted from terrain04.png? 21:54:07 <planetmaker> you mean the ground tile refactoring? 21:54:21 <Rubidium> yep 21:54:22 <planetmaker> yes... it had not been ported to OpenGFX itself 21:54:32 <frosch123> ah, rb made that insane xcf? :) 21:54:41 <Rubidium> frosch123: hell NO 21:54:45 <planetmaker> :-D 21:55:08 <planetmaker> I basically created and expanded the xcfs where they saved work for me 21:55:33 <Rubidium> and I'm seeing the same with the infrastructure 21:55:35 <planetmaker> But I did not spend an aweful lot of time on replacing the existing sprites while they are the same. 21:55:44 * andythenorth hasn't opened these files....but...is there a predictable grid structure? 21:55:54 <andythenorth> i.e. would it be trivial to composite with PIL? 21:55:56 <frosch123> look at terrain.xcf 21:56:10 <frosch123> xcf2png does the composition 21:56:10 <Rubidium> the terrain one is almost predictable 21:56:27 <Rubidium> there are two places where there should be 1 extra pixel between the sprites 21:56:36 <Rubidium> then it'd be spaced nicely everywhere 21:57:16 <andythenorth> hmm 21:57:21 <andythenorth> my xcf view is frankly shit 21:58:05 <andythenorth> I'll have to get gimp or such 21:59:01 <Rubidium> @calc 19*8 21:59:01 <Webster> Rubidium: 152 21:59:27 <andythenorth> anyway compositing images is pretty trivial with PIL 21:59:35 <andythenorth> on my todo list for Pixa is: 21:59:52 <andythenorth> - opening a bitmap and convert it to Pixa sequence 22:00:02 <andythenorth> - automatically knock out any blue when pasting 22:00:03 <Rubidium> the 152 field sprites can be generated with 6 sprites (1 flat, 4 steep, 1 hay bale) and 8 recolourings 22:00:16 <andythenorth> - utility to make it easier to define colour transforms 22:00:33 <planetmaker> yep, they can. And it would probably make sense to use such thing 22:01:49 <Rubidium> @calc 28*19+4*4 22:01:49 <Webster> Rubidium: 548 22:02:06 <Rubidium> wow... 700 terrain sprites 22:03:27 <Rubidium> 6 field, 5 normal, 8 rough, 5 rocks, 5 toyland -> 29 sprites 22:04:09 <Rubidium> and some 40 recolourings and we're done 22:04:24 <Rubidium> only 10% of the sources needed 22:06:49 <Rubidium> then 12 road tiles (x5 for pavement/desert/toyland) can be used to construct all road tiles 22:07:28 <Brot6> BANDIT - Feature #3770 (New): Setup Pixa gestalts to draw cargo sprites (andythenorth) @ http://dev.openttdcoop.org/issues/3770 22:09:12 * andythenorth looks at the terrain tile pngs 22:09:20 <andythenorth> are the recolourings so simple? 22:09:52 <Rubidium> it definitely feels that way 22:10:07 <andythenorth> the fields look quite...drawn 22:10:57 <andythenorth> if the artists have intervened, and drawn new pixels, instead of just used flood fill....recolouring won't work :| 22:11:11 <andythenorth> hmm 22:11:17 <andythenorth> photoshop -> diff layers 22:11:39 <frosch123> i don't think the recolouring would work for extra zoom sprites 22:11:48 <frosch123> grass just looks different than snow 22:12:15 <frosch123> though snow/desert and arctic/tropic/temperate grass might work with recolouring 22:12:19 <andythenorth> so field 08 and field 18 are different pattern :( 22:13:04 <Rubidium> andythenorth: the fields should have the same pattern with different colours 22:13:09 <planetmaker> andythenorth: I'm sure that the fields are somewhat recoloured. It's Zeph's work 22:13:11 <andythenorth> they don't 22:13:12 <Rubidium> the problem is that they aren't always 22:13:19 <andythenorth> artists :P 22:13:31 <andythenorth> engineers should make the art 22:13:51 <planetmaker> Grass, desert, snow are different textures, thus no re-colouring. But the grass in all three landscapes: yes 22:14:19 <Rubidium> planetmaker: why can't they have the same base texture with different recolouring? 22:14:21 <planetmaker> well... fields and same pattern, different colour: The stuff grows... 22:14:41 <planetmaker> Rubidium: you now mean desert and grass and snow? 22:14:50 <Rubidium> planetmaker: yes 22:14:58 <planetmaker> it has a different 'granularity' or roughness 22:15:37 <andythenorth> frosch123: snow is indeed different to grass in original game 22:16:12 <Rubidium> might be solved by recolouring where you squash colours together in a fancy way; going from 200 colours -> ~10? 22:16:32 <Rubidium> otherwise it's 10 sprites extra ;) 22:16:50 <andythenorth> also arctic and temperate grass are also different :o 22:16:59 <Rubidium> though it complicates bare -> arctic 22:17:21 <Rubidium> which you'd then need to composite in some manner with masks 22:17:53 <Rubidium> though... then you could use these masks for the other transitions as well reducing the number of recolour sprites 22:18:31 <planetmaker> well, the texture of the grasses could well be the same, just recoloured. No problem there IMHO 22:19:04 <andythenorth> the fields would be trivial to do 22:19:15 <andythenorth> layer 1 is brown 22:19:19 <andythenorth> layer 2 is the grass 22:19:44 <andythenorth> for each growth state, draw more / less of the green pixels in layer 2 22:19:47 <andythenorth> ignore the others 22:19:52 <andythenorth> you get more or less grass 22:20:06 *** ODM has quit IRC 22:21:27 <andythenorth> afaict bare is just a recolour of temperate grass 22:25:03 <andythenorth> also....zeph did a pretty awesome job on the terrain tiles ;) 22:25:27 <Rubidium> andythenorth: that's basically the idea of the mask; just let pixels XYZ of the lower layer "shine" through 22:25:44 <andythenorth> treat it as a knockout mask 22:26:29 <andythenorth> if the tiles were drawn in false colour it would be trivial 22:26:55 <andythenorth> if you have 8 colours in final result, draw in 16 22:27:03 <andythenorth> some are knocked out as needed 22:27:11 <andythenorth> some are merged down to one colour 22:27:26 <Rubidium> yep, also possible 22:27:30 <andythenorth> but the drawing is already done :P 22:27:32 <Rubidium> requires more recolour masks 22:27:56 <Rubidium> though you'd need 4 times the colours compared to the ones currently used 22:27:58 <Zuu> Yexo: Did you forget the AIOrder.AIOF_* flags when you removed the "AI" prefix to enum flags? 22:28:36 <Zuu> Eg is it a bug that there exist GSOrder.AIOF_TRANSFER 22:28:54 <andythenorth> it's basically what the function on l4 here is doing: http://dev.openttdcoop.org/projects/bandit/repository/entry/misc/pixel_generator/gestalts/common.py 22:29:03 <andythenorth> draw stuff, or not draw stuff 22:29:49 <andythenorth> I'd probably do it differently for the tile case 22:29:53 <planetmaker> fields also need a ripe stage and a harvested stage. Which kinda is Earth again 22:30:45 <andythenorth> one thing that can be done with Pixa-style is, rather than pure compositing, use one image as a set of control codes to draw in another image 22:31:10 <andythenorth> so you might always draw over the base earth 22:31:31 <andythenorth> picking n colours from a grass layer 22:34:49 <andythenorth> I'm not sure you gain much for existing 8bpp opengfx 22:35:03 <andythenorth> but maybe if 32bpp is being added.... 22:35:28 <andythenorth> you gain maintainability at the cost of complexity 22:35:35 <andythenorth> but who needs to maintain grass tiles anyway? :P 22:37:40 <andythenorth> hmm 22:37:52 <andythenorth> but rocks and such seem like a clear case for compositing at least 22:38:41 <andythenorth> and shore tiles :o 22:41:06 <andythenorth> ugh 22:41:12 * andythenorth discovers infra08.png 22:41:23 <Rubidium> andythenorth: discover infra06 as well 22:41:41 <andythenorth> yeah 22:41:51 <andythenorth> so....did I mention I've written a pixel generator? :P 22:41:56 <Rubidium> also discover terrain04.png in somewhat older versions of opengfx 22:42:05 <andythenorth> and it can composite... :P 22:42:18 <Rubidium> andythenorth: when is it of LordPixaII stability/quality? ;) 22:42:30 <andythenorth> dunno 22:42:33 <andythenorth> only I'm testing it 22:42:46 <andythenorth> it's not packaged well yet 22:43:07 <andythenorth> but I discover what it's missing by testing it against cases 22:43:36 <andythenorth> you may find it easier to roll your own anyway 22:43:44 <andythenorth> what it does isn't hard 22:43:55 <andythenorth> it's only taken so long because I'm a bad programmer 22:44:52 *** frosch123 has quit IRC 22:46:27 <andythenorth> ho 22:46:29 <andythenorth> haybales 22:47:58 <andythenorth> so...infrastructure (road, rail) doesn't get partial snow because....? 22:48:04 <andythenorth> - lack of bits spare? 22:48:13 <andythenorth> - too expensive to calculate? 22:48:16 <andythenorth> - no graphics? 22:48:31 <andythenorth> - nobody cares? 22:48:56 <planetmaker> c) and missing ingame support 22:49:28 <planetmaker> it would need a change how snow cover is calculated: global height. In principle feasible. I'm not exactly sure why it wasn't done 22:49:47 <planetmaker> Our grf-frog just left 22:50:39 <andythenorth> but openttd could be patched to calculate it? 22:50:56 <Rubidium> andythenorth: yes 22:51:07 <andythenorth> graphics could be generated... 22:51:17 <Rubidium> andythenorth: better not ;) 22:51:20 <andythenorth> no benefit to me, I use SF base set :P 22:51:27 <Rubidium> better let OpenTTD do the composition itself 22:51:47 <Rubidium> makes it work nicer with different tile sets and rail types 22:51:48 <andythenorth> you could also do that for....all the other composited tiles... 22:51:59 <planetmaker> Rubidium: the composition itself would be very helpful wrt ground sprites 22:52:15 <planetmaker> like that nothing needs define a ground tile 22:52:23 <planetmaker> as there'll always be one 22:52:54 <Rubidium> though it'll be a quite significant "event" to get everything to change 22:52:54 <planetmaker> which also could be like grass + (partial) snow cover + grf-supplied ground+building sprites 22:52:58 <andythenorth> no more holes in the scenery when you screw up your newgrf :) 22:53:18 <planetmaker> ah, the change was the point... 22:53:32 <andythenorth> we needs something for v2 anyway 22:53:53 <andythenorth> or 1.3... 22:54:08 <Rubidium> ad it might be better to somewhat start from scratch with certain things at some point 22:54:30 <andythenorth> what about all the legacy newgrf crap :P 22:54:39 <Rubidium> drop it ;) 22:54:52 <andythenorth> how about full 3D? :) 22:55:15 <andythenorth> maybe not, eh? 22:55:22 <Rubidium> though it'd probably even mean dropping original graphics support 22:55:48 <Rubidium> as then you can do the really significant cleanups 22:56:05 <Rubidium> and prepare everything to be much more generic 22:56:15 <Rubidium> like all climates on the map 22:56:51 <Rubidium> though I fear it never comes out of the idea stage 22:57:24 <Rubidium> mostly as it'll cause a lot of drama and work 22:58:18 <andythenorth> no more SF sprites? :( 22:58:24 * andythenorth would be sad 22:58:40 <michi_cc> planetmaker: You want http://www.icosahedron.de/openttd/patches/cool_stuff2.png then? :p 22:58:59 <planetmaker> That's what I thought about, indeed 22:58:59 <andythenorth> doesn't everyone? :) 22:59:51 <planetmaker> though I recall that discussion predating that patch 23:00:02 * andythenorth just wants less stupid tram-rail crossings 23:00:08 <andythenorth> and even tried to patch for it 23:01:08 <andythenorth> also....good night 23:01:13 * andythenorth was up at 4am 23:01:19 <andythenorth> and may be so again :P 23:01:21 <planetmaker> ui. Sleep well 23:01:32 <andythenorth> bye 23:01:33 *** andythenorth has quit IRC 23:07:35 <Brot6> BANDIT - Feature #3771 (New): Setup Pixa to draw more trailer types (andythenorth) @ http://dev.openttdcoop.org/issues/3771 23:18:38 * Zuu misses GSOrder.UnshareOrders 23:18:46 * Zuu goes and file a feature request 23:22:05 <planetmaker> does the feature request feature a file? 23:34:20 <Zuu> planetmaker: No attached file 23:34:41 <Zuu> do you want a file? :-) 23:47:10 <Yexo> Zuu: I didn't do that, that was truebrain's work 23:47:14 <Yexo> so complain to him please :) 23:47:22 <Yexo> (yes, I like delegating complaints) 23:47:31 <Zuu> I've filed a bugreport now. 23:47:56 * Yexo wonders how long until I'll have to fix that anyway :p 23:48:01 <Zuu> It will make sense to fix this before 1.2 is out as then only very few GS have to change. 23:48:16 <Yexo> yes, but on the other hand: 1.2 is already branched 23:48:27 <Yexo> rc1 has been released, so not sure we want to change it now 23:48:52 <Zuu> GSOrder.AIOF_* has only been available for a limited amount of time. The only GS that I know use it is the tutorial. 23:49:06 <Zuu> Hmm, true 23:49:31 <Zuu> Could be added to 1.3 and have it in compatibility layer. 23:49:40 <Yexo> yep 23:49:44 <Yexo> same can still be doen for 1.2 23:50:14 <Yexo> document it as [AI/GS]Order.OF_* but have the old names (AIOF_*) still available in the compatibility layer 23:50:59 <Zuu> Sounds good, as that will make it easier to release gamescripts with the new name with compatibility for 1.2. 23:55:19 <Zuu> Regarding FS#5089 (missing UnshareOrders etc): Unless you are faster, I will probably make a patch myself as to get forward with my fleet management GS. 23:58:47 <Yexo> I doubt I'm faster 23:58:51 <Yexo> but we'll see 23:58:55 <Yexo> good night