Times are UTC Toggle Colours
07:03:33 *** Alberth has joined #openttdcoop.devzone 07:16:35 <Brot6> NewGRF build framework - Feature Request #4053: Add support for GNU M4 macro processor XXotic750X @ http://dev.openttdcoop.org/issues/4053#change-11199 07:18:28 <Alberth> Xotic750: why do you use m4 instead of cpp? 07:19:50 <Alberth> I have also tried to push m4 to other newgrf coders and failed, they don't seem to understand m4. 07:20:04 <Xotic750> because of the flexibility, I can create loops (iterate). I can reference other macros without having to deal with the 2 pass issues of cpp, and in all it makes for more maintainable nml code imo 07:20:38 <Xotic750> as the code is readable rather than all on a single line, like created with cpp 07:21:26 <Xotic750> the language is not so hard 07:21:40 <Alberth> I know, I have done m4 programming too 07:21:56 <Xotic750> I have never used it before this 07:22:05 <Alberth> my fear is however that you're moving code onto an island that only you can understand/maintain 07:22:54 <Alberth> even though m4 is better, if people don't get it, it's of no use imho 07:22:57 <Xotic750> it should be pretty clear to anyone that knows m4 07:23:04 <Alberth> perhaps we should extend nml on some way? 07:23:34 <Alberth> well, I think there are about 2 people understanding m4, you and me 07:24:09 <Alberth> and I don't see others taking it up :( 07:24:10 <Xotic750> currently, maintaining both branches proves to me the benfits in hand 07:24:46 <Xotic750> but sure, if it could be done directly in nml, that would be great 07:25:29 <Alberth> yeah, I am sold, you are sold, but the rest of the community needs to be sold too (or at least some significant portion of it) before it becomes viable as standard for newgrf projects, imho 07:25:45 <Xotic750> and the thing is if nobody demonstrates how to use m4, then it will definately never be used 07:25:58 <Alberth> true, so you make a good case 07:26:10 <Alberth> perhaps you should do a little advertising? 07:26:27 <Xotic750> so, all I can do is maintain 2 branches and hope people will see the benefits 07:26:49 <Xotic750> in what respect? I post about both branches on the forum 07:27:07 <Alberth> ie everything is now nicely packed away in a branch. People won't start reading your code to do their projects 07:27:45 <Alberth> make it more concrete perhaps, show how much nicer m4 is than cpp 07:28:57 <Xotic750> other than having 2 branches, how would you suggest going about that? 07:31:21 <Alberth> To convince people, you need to show them examples that they understand and can use, I think 07:31:45 <Alberth> perhaps see your m4 macros as a new framework that you publish as a separate entity? 07:32:17 <Alberth> note I am mostly just thinking aloud here, I am just as clueless how to do this as you are 07:33:29 <Xotic750> if m4 was added to the standard framework then it would be fair easy to make an example project that could be cloned 07:33:55 <Alberth> I just see you moving everything to m4, and nobody reacting, which makes me fear your efforts will be wasted 07:34:00 <Xotic750> otherwise it would be just like the m4 branch that I am maintaining 07:34:12 <Alberth> why not clone the newgrf framework to a new project? 07:34:31 <Xotic750> I guess that's a route that could be tried 07:34:48 <Alberth> although your proposal would be simpler, perhaps 07:34:57 <Alberth> planetmaker: opinion? ^^ 07:35:37 <Xotic750> still, I was interested in learning m4, so has been a great exercise for me 07:35:57 <Alberth> the problem to making it part of the standard framework is that it becomes a new dependency 07:37:14 <Xotic750> sure, though I don't see that as being a big issue, m4 is common on all platforms, and normally installed by default 07:37:32 <Xotic750> for automake etc etc 07:37:32 <Alberth> try any random windows system :) 07:37:44 <Alberth> which is the biggest user base 07:37:49 <Xotic750> I don't use windows :P 07:38:09 <Xotic750> but sure, I know what you are saying there 07:38:19 <Alberth> neither do I, but for a macro processor to become viable, you have to consider such things 07:38:25 <Xotic750> but they have cygwin available 07:38:46 <Alberth> somewhat, cygwin is also a nightmare for the average windows user 07:38:58 <Xotic750> and they can only build OpenGFX+ Trains under a linux system at present (from source) 07:39:19 <Alberth> even nml is tricky already 07:39:22 <Xotic750> due to some of the shell scripts that I use to postprocess files 07:40:30 <Xotic750> though, I would say that most developers here are unix users, true? 07:40:45 <Alberth> for newgrfs? I doubt that 07:40:47 <Xotic750> and most game users are windows user? 07:41:07 <Xotic750> ok 07:41:11 <Alberth> yep, but they are non-relevant 07:41:44 <Xotic750> I would also say that cpp is fine for small projects 07:42:06 <Xotic750> but when you start doing more ceomplex stuff then the m4 benefits shine through 07:42:12 <Alberth> even programmers is just about 50% or so, as they often have other needs besides programming that is only available at windows 07:43:05 <Xotic750> I don't know if there is a native windows build of m4 07:43:25 <Alberth> Unlikely, you cannot click it :) 07:44:02 <Xotic750> yes, apparently there is a win32 port 07:44:49 <Xotic750> http://unxutils.sourceforge.net/ 07:44:49 <Alberth> Well, I hope you understand my concerns somewhat. I do like the m4 approach, but it needs more use to become useful in general, I think 07:44:50 <Webster> Title: Native Win32 ports of some GNU utilities (at unxutils.sourceforge.net) 07:45:59 <Xotic750> I do, and perhaps if I get some other spare time then I can begin to demonstrate some of its uses 07:46:22 <Alberth> showing people the m4 framework will hopefully do that, and perhaps you can also have a look what parts could be moved to nml, which is easier in the end, I think 07:47:23 <Alberth> except our nml dev is already very busy with other things 07:47:59 <Xotic750> I will keep things in mind :) And nmlc is coming along in leaps I would like to say 07:48:31 <Alberth> yeah, Hirundo is doing a good job there 07:50:11 <Xotic750> I'm currently trying to build the 07:50:17 <Xotic750> zbasebuild 07:50:35 <Xotic750> I want to see how things are begining to look 07:51:20 <Xotic750> it's been compiling for quite some time though :) 07:52:17 <Alberth> yeah 20 minutes or so without cache 07:52:31 <Alberth> 30 minutes if you have an 'old' nml :) 07:53:06 <Alberth> the new build project is however zbuild, but it is still somewhat experimental 07:53:25 <Xotic750> yes, that's what I cloned 07:53:26 <Alberth> and besides the 3 sub-repos, mostly empty :p 07:53:39 *** Zuu has joined #openttdcoop.devzone 07:53:46 <Alberth> moin Zuu 07:54:12 <Xotic750> it's been 50 minutes on my pc now though :P 07:54:33 <Xotic750> my PCs are old :) 07:54:34 <Alberth> oh, perhaps it's building opengfx too 07:54:45 <Xotic750> I think it is 07:55:19 <Alberth> abort, revert the opengfx repo, touch all *.png files :) 07:55:26 <Xotic750> and it just finished 07:55:30 <Alberth> :) 07:55:32 <dihedral> oi 07:55:43 <Alberth> moin dihedral 07:55:58 <dihedral> i was in the DC last night - from 2200 until 0420 :-D 07:56:20 <Xotic750> ok, it produced lots of grfs 07:56:23 <dihedral> i am somewhat whacked! 07:56:40 <Alberth> try a little AC instead :p 07:57:10 <Xotic750> do I need to drop all of the grfs in the data dir? 07:58:18 <Alberth> I made the normal opengfx non-findable by openttd, and added a softlink to zbasebuild from an openttd baseset directory instead 07:58:31 <Alberth> so openttd can simply find all the grfs itself 08:00:02 <Zuu> Hello Alberth 08:08:39 <Alberth> ok, 10k new files in zbase :p 08:12:55 <Brot6> zBuild - Revision 8:9d4521c52017: Fetched updates from subrepos XAlberthX @ http://dev.openttdcoop.org/projects/zbuild/repository/revisions/9d4521c52017 08:13:49 <Brot6> zBuild - Revision 9:dcd2837c2560: Add: Fetch script for updating the subrepos XAlberthX @ http://dev.openttdcoop.org/projects/zbuild/repository/revisions/dcd2837c2560 08:15:09 <Xotic750> ok, I have it :) 08:15:43 <Xotic750> stripy water :P 08:19:42 <Xotic750> Trains look nice on the tracks, but will need different offsets 08:23:39 <Alberth> until recently, tracks didn't even line up properly :) 08:25:40 <Xotic750> I see quite a few glitches and angles not quite right, but it's looking good 08:26:09 <Xotic750> it will be nice once it all starts coming together 08:26:40 <Alberth> I am mostly just figuring out which sprite goes where, and adding the alternative sprite lines 08:27:17 <Xotic750> sure will keep you busy :) 08:28:02 <Alberth> I am running out of free days to work on it, so it will become harder to keep up :) 08:34:39 <Xotic750> how a train looks, with the offsets adjusted to match :) 08:34:41 <Xotic750> http://img856.imageshack.us/img856/2504/screenshotat20120726103.png 08:35:21 <Alberth> very pretty 08:36:43 <Terkhen> Xotic750: I'm sure that you can run M4 on windows with either cygwin or msys 08:37:22 <Xotic750> yep, there is also a native version in win32 08:37:45 <Terkhen> but when I tested, compilation of normal newgrf projects was horribly slow 08:37:53 <Xotic750> not that I can test any of those solutions :) 08:37:57 <Rubidium> do you mean the slopes of tiles by angles? Then maybe you need to update the zbase repository (loads of new sprites that should fix the slopes) 08:38:18 <Xotic750> I just cloned the latest 08:38:24 <Xotic750> from zbuild 08:39:33 <Xotic750> but most slopes are correct, some that are not 08:40:40 <Terkhen> on windows, a plain newgrf project with png sprites took twice the time than in a linux VM, and roughly four times more than in native linux 08:40:43 <Xotic750> it seems to be mostly slopes that contain road and rail that are not 08:40:45 <Xotic750> nasty :) 08:41:43 <Xotic750> sounds pretty normal for windows, it normally takes 4x longer to do anything, even navigation :P 08:44:43 <Terkhen> not really 08:45:27 <Terkhen> I usually have dual boot and the performance is not that different 08:45:40 <Xotic750> nah, I just like my linux environments, I feel a bit lost when I have to use windows 08:46:00 <Terkhen> windows just don't like creating many small processes :) 08:46:01 <Xotic750> I can't remember the last time I used a windows machine 08:46:39 <Terkhen> I prefer linux but I like the games too :P 09:07:55 <Brot6> OpenGFX+ Trains renders - Revision 46:e71fc70cbd18: Fix: Missing material for refrigerated symbols a... XXotic750X @ http://dev.openttdcoop.org/projects/ogfx-trains-render/repository/revisions/e71fc70cbd18 09:09:40 <Brot6> OpenGFX+ Trains - Revision 758:a1997c3c3fcd: Update: Sprites for monorail refrigerated wagon to show... XXotic750X @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/a1997c3c3fcd 09:24:26 <Hirundo> That zBase screenshot looks *very* nice 09:24:43 <Hirundo> is it done yet :P ? 09:26:44 <Alberth> of course it is :p 09:26:44 <Hirundo> btw, using cygwin to run linux-y build systems sucks in my experience 09:27:46 <Brot6> zbuild: compile of r8 still failed (#4095) - http://bundles.openttdcoop.org/zbuild/push/ERROR/r8 09:29:27 <Brot6> zbuild: compile of r8 still failed (#4096) - http://bundles.openttdcoop.org/zbuild/nightlies/ERROR/r8 09:46:09 <Hirundo> planetmaker: Wrt. to the regression issue, both versions of the grf are fine but the sprites are cropped differently 09:46:45 <Hirundo> Currently I'm adding a lot of debug output to the cropping code, so I can diff the output and see where this difference comes from 09:55:54 <Brot6> NewGRF Meta Language - Revision 1951:819488d7f9e5: Add: Lots of debugging output to the sprite cropp... XHirundoX @ http://dev.openttdcoop.org/projects/nml/repository/revisions/819488d7f9e5 10:04:13 <Hirundo> Xotic750: Can't you script the process of creating a purchase menu sprite? 10:05:59 <Xotic750> Sure I could, but it seemed like something that I should be able to do within nml as the mechanisms are there for it. But first I wanted to check if it was available or feasible 10:06:57 <Xotic750> or perhaps something needs to change within the OpenTTD code itself first? 10:07:55 <Hirundo> Indeed, it needs modification to OpenTTD and nfo first 10:08:58 <Xotic750> I think it would a nice feature to have, I would look at the code to see what needs to be done but I fear that it would take me too long 10:09:02 <Alberth> buy menu sprites have other requirements than ingame sprites 10:12:11 <Alberth> Brot6: What's the point of building a nightly and raising a ticket about its failure when the push already fails? 10:12:34 <Xotic750> Where would be the best place to request such a feature? On the forum or is there an issues list I can submit to? 10:13:48 <Hirundo> For discussion, it's best to either open a forum topic or discuss in #openttd 10:14:59 <Hirundo> though IIRC there are quite some problems with it, mainly that the vehicles shown do not actually exist 10:15:23 <Hirundo> quite some NewGRFs have a single 'tender' vehicle that changes it gfx depending on the engine it is attached to 10:15:43 <Hirundo> But this mechanism fails in the purchase list 10:16:17 <Xotic750> we are using a single tender and changing the graphics depending on engine attached 10:17:00 <Hirundo> Exactly. But how do you change the graphics when there is no engine? (and no tender, either) 10:17:56 <Xotic750> we have a parameter to say use or not use tenders in game 10:18:10 <Xotic750> the tender is an articulated part and not purchaseable 10:19:54 <Hirundo> I understand that 10:20:36 <Hirundo> Problem remains though that the vehicles don't *exist* on the map (or anywhere else in your computer's memory), so you can't use (most) variables or livery overrides 10:21:15 <Hirundo> The variables you can use are either global (eg current date) or get some semi-bogus value (e.g. construction date is set to the current date as well) 10:21:32 <Hirundo> Without variables or livery overrides, how would you pick the tender graphics? 10:23:00 <Xotic750> if the purchase menu understands that an engine has an articulated tender, then I guess we could define a tender per vehicle rather than just one that changes graphics? 10:24:22 <Hirundo> Exactly. But you can't tell all those old grfs that have been around for years to do that as well 10:24:39 <Hirundo> So you'd need some flag, set by NewGRFs, to tell OpenTTD to draw tenders 10:25:34 <Xotic750> like there is a property to say "dual-headed", have one that says "has-tender"? 10:26:13 <Xotic750> then the first articulated part will be the graphics used in the menu 10:27:00 <Hirundo> No, you need some way of telling OpenTTD that, 'not only do I have a tender, but I can draw it correctly in the purchase list and I'd like to do so' 10:27:42 <Hirundo> Without such a flag, OpenTTD would try and fail to draw tenders in the Plist for grfs that don't expect it (e.g. current ogfx-trains) 10:28:24 <Hirundo> Ammler: Could you trigger a recompile of NML? 10:29:35 <Xotic750> My knowledge is not that extensive, but is there any way that you can think of that would work? Or do you think it just wouldn't be possible? 10:30:21 <Hirundo> Of course it would be possible, but it needs some changes to openttd 10:31:23 <Xotic750> What changes would I be requesting if I open a topic_ 10:37:59 <Brot6> zbuild: compile of r9 still failed (#4095) - http://bundles.openttdcoop.org/zbuild/push/ERROR/r9 10:39:03 <Brot6> zbuild: compile of r9 still failed (#4096) - http://bundles.openttdcoop.org/zbuild/nightlies/ERROR/r9 10:40:20 <Hirundo> Request to let OpenTTD draw articulated parts in the purchase menu. To preserve backwards compatibility, OpenTTD should only do so if the NewGRF sets some flag. Such a flag could be per-vehicle (e.g. a bit in the misc_flags property, 0x27 for trains) or per-grf (e.g. by setting a bit in parameter 0x9E). 10:40:28 <Hirundo> Xotic750: ^^ 10:50:03 <Xotic750> Nice, thanks :) 10:50:56 <Ammler> 2012-07-26 10:50:36+00:00: START compile nml (nightlies): r1931 to r1951 (819488d7f9e5) 11:00:12 <Xotic750> Hirundo: http://www.tt-forums.net/viewtopic.php?f=33&t=61663 11:00:14 <Webster> Title: Transport Tycoon Forums View topic - Draw articulated parts in the purchase menu. (at www.tt-forums.net) 11:00:18 <planetmaker> Hirundo, I gave you full ssh to the CF, so that you can manually start it: ssh -p22 hg@hg.openttdcoop.org 11:00:41 <planetmaker> ./misc/compiler/scheduler.sh nml 11:00:57 <planetmaker> will start a compilation of nml. call the script with -h for the possible flags like -r or -f 11:01:53 <planetmaker> if the CF should be locked or stuck, I created a script to reset the CF 11:02:04 <planetmaker> ./reset-compiler 11:02:07 <planetmaker> will then do the trick 11:02:35 <Brot6> nml: compile of r1951 still failed (#4097) - http://bundles.openttdcoop.org/nml/nightlies/ERROR/r1951 11:02:41 <Hirundo> planetmaker: I'm still w/o my private key, it may be best to generate a new one 11:02:58 <planetmaker> fine with me. Just provide me with the file 11:03:05 <planetmaker> (of the public one, of course) 11:03:35 <planetmaker> But I'm telling you now as I might be mostly not available the next few days. At least I don't know when I will be online 11:07:36 <Hirundo> planetmaker: Shall I just pastebin the public key? 11:08:15 <Ammler> yes 11:08:24 <Ammler> planetmaker: reset script? 11:10:09 <Ammler> I see, why didn't you place it in same home as the other scripts? 11:10:35 *** Hirundo_VM has joined #openttdcoop.devzone 11:10:52 <Hirundo_VM> http://paste.openttdcoop.org/show/1593/ 11:11:33 <Brot6> zBase - Revision 34:be018779f068: Add: Power station (without smoke or spark special effect sprites)... XzephyrisX @ http://dev.openttdcoop.org/projects/zbase/repository/revisions/be018779f068 11:12:04 *** Hirundo_VM has quit IRC 11:13:05 <Ammler> Hirundo: done 11:13:24 <Ammler> planetmaker: ^ 11:14:47 <Hirundo> How do I output the stdout of nml->grf compilation to some log file? 11:15:06 *** NataS has joined #openttdcoop.devzone 11:16:08 *** KenjiE20|SSH has joined #openttdcoop.devzone 11:16:41 <Ammler> you should also use the screen running on hg 11:17:16 <Ammler> alias shg="ssh -t hg.openttdcoop.org screen -x" 11:17:24 *** orudge` has joined #openttdcoop.devzone 11:17:47 *** Nat_aS has quit IRC 11:17:47 *** KenjiE20 has quit IRC 11:17:47 *** orudge has quit IRC 11:18:04 *** orudge` is now known as orudge 11:18:14 <Ammler> Hirundo: check the spec in .devzone/build/ 11:18:52 <Ammler> it is a kind of shell script 11:19:28 <Hirundo> .devzone/build where? 11:20:00 <Ammler> http://dev.openttdcoop.org/projects/nml/repository/changes/.devzone/build/nml.spec 11:20:46 <Ammler> ah, what did I break now? :-( 11:28:52 <Ammler> (fixed) 11:30:25 <Brot6> NewGRF Meta Language - Revision 1952:b78c17726d31: Change: Output cropping debug output to stderr in... XHirundoX @ http://dev.openttdcoop.org/projects/nml/repository/revisions/b78c17726d31 11:30:38 <Alberth> Hirundo: nmlc bladiebladiebla > logfile 11:31:26 <Alberth> or >& if you want both stdout and stderr in one log file 11:36:23 <Ammler> ah sorry, meant you refer to the compiler 11:38:26 <Brot6> nml: compile of r1952 still failed (#4097) - http://bundles.openttdcoop.org/nml/nightlies/ERROR/r1952 11:39:55 <Hirundo> Ammler: Why does neither stdout nor stderr end up here? http://bundles.openttdcoop.org/nml/nightlies/ERROR/r1952/nml-r1952-build.test.log 11:42:04 <Hirundo> The nml.spec seems to suggest to me that both stdout and stderr are sent there, see http://paste.openttdcoop.org/show/1594/ 11:42:24 <Hirundo> But I may be wrong, I'm not very experienced with this sort of stuff 11:50:26 <Ammler> what do you miss? 11:51:05 <Ammler> PYTHONPATH=%{buildroot}%{python_sitelib} make _V= NMLC=%{buildroot}%{_bindir}/nmlc 1>%{name}-%{version}-build.test.log 2>&1 11:52:16 <Ammler> Binary files output/006_vehicle.grf and expected/006_vehicle.grf differ 11:52:18 <Ammler> make: *** [006_vehicle] Error 2 11:53:32 <Ammler> don't use paste for 3 lines only, please 11:54:17 <Hirundo> I added lots of print statements to NML, but the output isn't shown anywhere 11:54:31 <Ammler> in this channel you can safely paste around 10 lines :-) 11:55:12 <Hirundo> Both when printing to stdout (r1951) and stderr (r1952) 11:55:18 <Ammler> Hirundo: you added those to the nml building? 11:55:32 <Ammler> you have those locally? 11:55:52 <Hirundo> Both locally as well as on the server, I committed and pushed them 11:55:53 <Ammler> that would be worth a paste :-P 11:56:10 <Hirundo> http://dev.openttdcoop.org/projects/nml/activity 11:56:25 <Ammler> I meant the difference you have locally and our server 11:56:46 <Hirundo> Locally I get gazillions of lines of output, on the server I get none 11:57:11 <Ammler> could you please past a prove :-P 11:58:10 <Hirundo> yes, one minute.. 12:01:43 <Hirundo> http://paste.openttdcoop.org/show/1595/ <- best disable line numbers, with them enabled it does something strange for me 12:01:48 <Hirundo> Ammler: ^ 12:03:55 <Hirundo> That's not even the whole paste, should be around 2k lines 12:07:20 <Ammler> well, what should that prove? 12:08:36 <Hirundo> That I get lots of output locally, but when running the regression test on the server there is none 12:09:48 <Ammler> :-) 12:09:50 <Hirundo> And I need that debug output to figure out why the regression test fails on the server (in the chroot), while it works for me, XAlberthX and even when running the regression test on the server normally 12:09:57 <Ammler> I will check on the server directly 12:10:46 <Alberth> could it be the json library or so? 12:11:06 *** dihedral has quit IRC 12:11:17 *** dihedral has joined #openttdcoop.devzone 12:14:02 <Hirundo> JSON is only used for the cache, which is not used by the server 12:14:10 <Hirundo> Though PIL might be the issue 12:14:52 <Ammler> I doubt, PIL differ much from server to my local install 12:14:59 <Ammler> (I see the output locally too) 12:16:31 <Hirundo> From the .grf output I have deduced that the differences are in the sprite cropping 12:17:12 <Ammler> well, the grf issue is another one than the output issue, I would think 12:18:04 <Ammler> do you use anoter version of pil locally? 12:18:47 <Hirundo> I have PIL 1.1.7 12:19:18 <Hirundo> solving the output issue would go a long way in solving the grf issue 12:19:29 <Ammler> [ 446s] [217/219] installing python-imaging-1.1.7-8.1.2 12:20:17 <Ammler> yes, I see 12:24:50 <Ammler> dev:~/rpmbuild/BUILD/nml/regression> make 12:24:52 <Ammler> Running test 001_action8 12:24:53 <Ammler> Running test 002_sounds 12:24:55 <Ammler> Running test 003_assignment 12:24:56 <Ammler> Running test 004_deactivate 12:24:58 <Ammler> Running test 005_error 12:24:59 <Ammler> 0 output 12:25:09 <Ammler> maybe other flags? 12:25:47 <Ammler> hmm 12:25:50 <Ammler> there is output 12:25:58 <Hirundo> There should be output when outputting 006_vehicle 12:26:04 <Hirundo> s/outputting/running test 12:26:08 <Ammler> yes, there is 12:26:20 <Brot6> OpenGFX+ Trains renders - Revision 47:14d3fe017590: Update: Modernised monorail livestock models and... XXotic750X @ http://dev.openttdcoop.org/projects/ogfx-trains-render/repository/revisions/14d3fe017590 12:27:14 <Brot6> OpenGFX+ Trains renders - Revision 48:30fb45823516: Add: Monorail early livestock wagons and rendere... XXotic750X @ http://dev.openttdcoop.org/projects/ogfx-trains-render/repository/revisions/30fb45823516 12:28:35 <Hirundo> Ammler: Does the test fail or succeed? 12:29:32 <Ammler> Hirundo: try with _V 12:30:00 <Ammler> damn 12:30:04 <Ammler> no, no need 12:30:12 <Ammler> it fails 12:30:24 <Ammler> wait, I could paste the output in the meantime 12:31:33 <Ammler> it succeeds when you run with local nml, it fails with installed nml 12:32:20 <Ammler> you have some modul changes? 12:32:39 <Hirundo> I'd really like the output of the failed build, if possible 12:33:42 <Ammler> te faild output has no more output as the log you have in bundles 12:34:08 <Ammler> PYTHONPATH=/home/abuild/rpmbuild/BUILDROOT/nml-r1952-suse1210.i386/usr/lib/python2.7/site-packages make _V= NMLC=/home/abuild/rpmbuild/BUILDROOT/nml-r1952-suse1210.i386/usr/bin/nmlc fails 12:34:21 <Ammler> make _V= succeeds 12:34:38 <Ammler> (with output) 12:35:09 <Ammler> when did you add the additional output? 12:35:21 <Hirundo> r1951 and r1952, today 12:35:25 <Ammler> and since when does server fail? 12:35:36 <Hirundo> since a few days, IIRC 12:36:51 <Brot6> OpenGFX+ Trains - Revision 759:73b2526c3aa9: Update: 32bpp Sprites for monorail livestock wagon XXotic750X @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/73b2526c3aa9 12:37:07 <Alberth> Ammler: yesterday, when planet maker was busy with zbuild 12:37:42 <Hirundo> Alberth: It failed before, the last published nighly is r1931 12:38:05 <Alberth> ok, I was not aware of that 12:38:29 <Brot6> OpenGFX+ Trains - Revision 760:11af41f4c17a: Add: 32bpp Sprites for monorail early livestock wagons XXotic750X @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/11af41f4c17a 12:39:47 <Brot6> OpenGFX+ Trains - Revision 761:711e1ee05355: Merge with default XXotic750X @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/711e1ee05355 12:40:05 <Ammler> ok, 1931 works 12:40:12 <Ammler> 1950 fails too 12:41:13 <Ammler> no rev between something changes in install? 12:41:34 <Hirundo> not AFAIK, but will check 12:42:36 <Ammler> 1940 ok 12:43:41 <Hirundo> pm added {BUILD}/regression/output/*.grf to .devzone/build/files, but that was after things broke 12:43:48 <Ammler> 45 fails 12:44:02 <Hirundo> And I changed the regression makefile to enable sprite cropping 12:44:44 <Hirundo> which was r1941 12:46:00 <Ammler> 43 fails 12:46:15 <Ammler> 41 fauks 12:47:22 <Ammler> and to prove: 40 ok 12:47:40 <Ammler> so r1941 is the buggy commit 12:48:01 <Hirundo> r1941 enabled sprite cropping, which is where the bug is found 12:48:05 <Ammler> yes 12:48:17 <Ammler> the spec file has nmlc as you see 12:48:37 <Ammler> NMLC=/home/abuild/rpmbuild/BUILDROOT/nml-r1952-suse1210.i386/usr/bin/nmlc 12:49:18 <Ammler> you need to change the spec so it calls the same NMLC flags as you do for the compare grfs 12:50:53 <Ammler> PYTHONPATH=/home/abuild/rpmbuild/BUILDROOT/nml-r1952-suse1210.i386/usr/lib/python2.7/site-packages make _V= NMLC="/home/abuild/rpmbuild/BUILDROOT/nml-r1952-suse1210.i386/usr/bin/nmlc -s -c" 12:51:01 <Ammler> and then it is ok 12:51:20 <Ammler> please ping if I shall do it for you 12:51:34 <Hirundo> No, I think I have a better solution 12:52:59 <Hirundo> Define NML_FLAGS = -s -c in the regression makefile, so NMLC just contains the path to the NML file and not the flags 12:53:07 <Ammler> still strange that it has no additional output before it fails 12:53:17 <Ammler> do you somehow cache the output? 12:53:48 <Hirundo> Not that I know of, but I don't know what python does 12:53:51 <Ammler> Hirundo: yes, that is better 12:54:48 <Ammler> Hirundo: maybe also add a comment, that it needs the flags to succeed the test 12:55:18 <Ammler> (basically do not let user change the flags) 12:55:35 <Hirundo> Currently I have NML_FLAGS ?= -s -c 12:55:44 <Ammler> why is not useful 12:55:51 <Ammler> s/why/which/ 12:55:55 <Brot6> Ammler meant: "which is not useful" 12:56:56 <Ammler> and blame damn planetmaker for that error ;-) 12:57:25 <Hirundo> If someone is smart enough to set NML_FLAGS, he probably knows what he's doing 12:57:48 <Ammler> ok, but adding comment might not hurt 13:02:22 <Brot6> NewGRF Meta Language - Revision 1953:de6e05fa27fd: Revert(r1951, r1952): Remove debugging output. XHirundoX @ http://dev.openttdcoop.org/projects/nml/repository/revisions/de6e05fa27fd 13:02:22 <Brot6> NewGRF Meta Language - Revision 1954:f4355c057d93: Fix: Set nml flags seperately in regression makef... XHirundoX @ http://dev.openttdcoop.org/projects/nml/repository/revisions/f4355c057d93 13:03:14 <Hirundo> Should be done now 13:03:20 <Hirundo> Much thanks, Ammler 13:05:09 <Hirundo> It's mostly my fault, I have been tinkering with the makefile without really knowing what I'm doing 13:10:34 <Ammler> well, I said blame pm, because he usually splits flags and binary path 13:11:39 <Brot6> nml: update from r1931 to r1954 done - http://bundles.openttdcoop.org/nml/nightlies/r1954 13:12:10 <Ammler> Hirundo: also you don't need to trigger manually after failed build 13:12:25 <Ammler> that is done automatically until it succeeds again 13:12:56 <Alberth> and then automatically until it fails again ? :p 13:13:05 <Ammler> as you asked me to trgger nml, I expected yesterday build was successful 13:13:39 <Ammler> (I did not read anything more as my highlight :-P 13:14:08 <Ammler> Alberth: no, then it does only build nightlywise 13:14:17 <Alberth> ah, ok 13:14:27 <Ammler> but after faild buidl, every push triggers a build 13:15:11 <Ammler> as it expects the bugfix :-) 13:17:37 <Xotic750> I would love a nightly to run on OpenGFX+ Trains :) 13:18:35 <Ammler> me too :'-( 13:19:04 <Brot6> zBase - Bug #4099 (New): suspension bridge glitches XAlberthX @ http://dev.openttdcoop.org/issues/4099 13:21:08 <Ammler> Xotic750: is there already done the splitting of the blender files? 13:21:23 <Ammler> s/blender/rendered/ 13:21:23 <Brot6> Ammler meant: "Xotic750: is there already done the splitting of the rendered files?" 13:21:50 <Xotic750> the blender files and renders are in their own project, the problem is the history in the original repo 13:22:07 <Ammler> so tha repo is still 2G? 13:22:29 <Ammler> well, we should fix it anyway 13:22:29 <Xotic750> #4017 13:22:30 <Brot6> Xotic750: #4017 is http://dev.openttdcoop.org/issues/show/4017 "Support #4017: Reduce repo size by archiving sources that are split into own repo - OpenGFX+ Trains - #openttdcoop Development Zone" 13:22:33 <Xotic750> YEP 13:22:39 <Alberth> Ammler: history contains EVERYTHING, it only grows 13:23:01 <Ammler> Alberth: yes, but you chould convert the repo and remove those files 13:23:09 <Xotic750> oops, caps :) 13:24:59 <Ammler> or I need to change the build script and use snapshots instead repos 13:35:56 <Brot6> zBaseBuild - Revision 36:a7c81d92e8bf: Add: Saw mill XAlberthX @ http://dev.openttdcoop.org/projects/zbasebuild/repository/revisions/a7c81d92e8bf 13:35:56 <Brot6> zBaseBuild - Revision 37:0da8f6a88122: Add: Some bridges (not finished yet) XAlberthX @ http://dev.openttdcoop.org/projects/zbasebuild/repository/revisions/0da8f6a88122 13:35:56 <Brot6> zBuild - Revision 10:715cf495bc10: Change: Updated subrepos XAlberthX @ http://dev.openttdcoop.org/projects/zbuild/repository/revisions/715cf495bc10 13:51:08 <Brot6> zBuild - Revision 11:9c6c090c393e: Add: Power station XAlberthX @ http://dev.openttdcoop.org/projects/zbuild/repository/revisions/9c6c090c393e 13:51:10 <Brot6> zBaseBuild - Revision 38:7308558a1ba3: Add: Power station XAlberthX @ http://dev.openttdcoop.org/projects/zbasebuild/repository/revisions/7308558a1ba3 14:17:56 <Brot6> zBase - Bug #4098 (Closed): Arctic maglev too green XRubidiumX @ http://dev.openttdcoop.org/issues/4098 14:17:56 <Brot6> zBase - Revision 35:fea2f0864fbd: Fix (r27): Change arctic maglev to correct grass texture. Bug #409... XzephyrisX @ http://dev.openttdcoop.org/projects/zbase/repository/revisions/fea2f0864fbd 14:17:56 <Brot6> zBase - Bug #4098 (Closed): Arctic maglev too green XzephyrisX @ http://dev.openttdcoop.org/issues/4098#change-11200 14:36:24 <Brot6> zbuild: compile of r10 still failed (#4096) - http://bundles.openttdcoop.org/zbuild/nightlies/ERROR/r10 14:36:41 <Rubidium> afternoon 14:37:04 <Brot6> zbuild: compile of r10 still failed (#4095) - http://bundles.openttdcoop.org/zbuild/push/ERROR/r10 14:39:59 <Alberth> hi hi 14:43:29 * Rubidium finds it interesting that the normal zoom 32bpp sprites look less detailed than the 8bpp ones 14:44:17 <Rubidium> also, the bridge sprites need to come down a few pixels I think 14:45:04 <planetmaker> Rubidium: adding detail to 8bpp is easy. Just change a pixel. In 32bpp... you need to model :-) 14:45:11 <planetmaker> hello also everyone :-) 14:45:55 <Rubidium> still... the ground tiles look like they are one colour with an edge 14:47:34 <planetmaker> yes. The grass looks boring to me. Too little variety 14:47:50 <planetmaker> It's all the grass from a green of a golf course. Or similar 14:53:38 *** frosch123 has joined #openttdcoop.devzone 14:55:26 *** Zuu has quit IRC 14:56:25 <Alberth> Rubidium: http://www.tt-forums.net/viewtopic.php?p=1035907#p1035907 This comment from zephyris? 14:56:27 <Webster> Title: Transport Tycoon Forums View topic - OpenGFX+ Trains development and translations thread (at www.tt-forums.net) 14:56:50 *** LordAro has joined #openttdcoop.devzone 14:58:13 <Alberth> Anyone understand why this fails? http://devs.openttd.org/~alberth/snowy_arctic_terrain.patch 14:59:26 <Alberth> http://devs.openttd.org/~alberth/faulty_snowy_arctic.png 15:00:36 <Rubidium> wrong steep slope sprites? 15:00:58 <Rubidium> as in, wrong in zbase 15:01:15 <Rubidium> having said that.. the foundations look a bit fishy as well 15:02:30 <Brot6> zBaseBuild - Revision 39:4adb28e884f9: Add: Tropical desert terrain XAlberthX @ http://dev.openttdcoop.org/projects/zbasebuild/repository/revisions/4adb28e884f9 15:02:30 <Brot6> zBuild - Revision 12:77c72f13d906: Add: Tropical desert terrain XAlberthX @ http://dev.openttdcoop.org/projects/zbuild/repository/revisions/77c72f13d906 15:04:34 *** LordAro has quit IRC 15:04:59 *** LordAro has joined #openttdcoop.devzone 15:05:28 <Rubidium> can't quite lay my finger on the real problem with the foundations though; for some reason it moves a few pixels and I can't properly align them (or the rail on top of them) 15:07:20 <Brot6> zBaseBuild - Revision 40:b972eca4ea7b: Add: foundation sprites XRubidiumX @ http://dev.openttdcoop.org/projects/zbasebuild/repository/revisions/b972eca4ea7b 15:27:41 *** KenjiE20|SSH has quit IRC 15:28:30 <Brot6> zBaseBuild - Revision 41:01ba39418f79: Add: some level crossings XRubidiumX @ http://dev.openttdcoop.org/projects/zbasebuild/repository/revisions/01ba39418f79 15:29:18 *** KenjiE20 has joined #openttdcoop.devzone 15:42:38 *** Zuu has joined #openttdcoop.devzone 15:53:34 <Brot6> zBaseBuild - Revision 42:31fd5d09361b: Add: some rail infrastructure for the tropical climate XRubidiumX @ http://dev.openttdcoop.org/projects/zbasebuild/repository/revisions/31fd5d09361b 15:59:19 <Brot6> zbuild: compile of r12 still failed (#4095) - http://bundles.openttdcoop.org/zbuild/push/ERROR/r12 15:59:19 <Brot6> zbuild: compile of r12 still failed (#4096) - http://bundles.openttdcoop.org/zbuild/nightlies/ERROR/r12 16:02:00 <Rubidium> wow, that CF is slow 16:02:22 <Rubidium> only after about 8.5 minutes it has everything installed and the actual building starts after around 20 minutes 16:04:12 <Rubidium> don't see any reason why that zbuild compile would fail; something fishy is going on, that's for sure 16:07:16 <Alberth> there are problems with nml on the server 16:08:22 <Alberth> not reproducable anywhere else 16:08:41 <Rubidium> the first error I spot is something failing to write to a build error log 16:26:34 <Ammler> Alberth: anything else as we just fixed? 16:47:24 <Alberth> I missed the nml fix? oh, in that case, perhaps planet maker did not get further as he got stuck on nml 16:49:09 <Rubidium> Ammler: I think the build failure of zbuild is something in the farm or maybe the rpm spec 17:22:56 <Brot6> zBase - Bug #4100 (New): snowy arctic terrain sprites not contiguously decreasing in snowy-ness XAlberthX @ http://dev.openttdcoop.org/issues/4100 17:23:49 <Brot6> zBaseBuild - Revision 43:3b39c0398fd3: Add: Snowy arctic terrain XAlberthX @ http://dev.openttdcoop.org/projects/zbasebuild/repository/revisions/3b39c0398fd3 17:23:49 <Brot6> zBuild - Revision 13:eb5b95de25fc: Updated zbasebuild XAlberthX @ http://dev.openttdcoop.org/projects/zbuild/repository/revisions/eb5b95de25fc 17:28:59 <Brot6> firs: update from r2859 to r2860 done - http://bundles.openttdcoop.org/firs/nightlies/r2860 17:31:15 <Brot6> zbuild: update from to r13 done - http://bundles.openttdcoop.org/zbuild/push/r13 17:34:08 <Brot6> zBaseBuild - Revision 44:40ea79d05b31: Add: fences to rails XRubidiumX @ http://dev.openttdcoop.org/projects/zbasebuild/repository/revisions/40ea79d05b31 17:47:15 <Brot6> opengfx: update from r978 to r980 done (12 warnings) - http://bundles.openttdcoop.org/opengfx/nightlies/r980 17:49:24 <Brot6> dutchtrains: update from r629 to r633 done - http://bundles.openttdcoop.org/dutchtrains/nightlies/r633 17:50:26 <Brot6> metrotrackset: update from r105 to r106 done - http://bundles.openttdcoop.org/metrotrackset/nightlies/r106 17:52:11 <Brot6> fish: update from r823 to r825 done - http://bundles.openttdcoop.org/fish/nightlies/r825 17:53:12 <Brot6> Dutch Track Set - Bug #4101 (New): DevZone compile failed XcompilerX @ http://dev.openttdcoop.org/issues/4101 17:53:27 <Brot6> ai-aroai: update from r60 to r62 done - http://bundles.openttdcoop.org/ai-aroai/nightlies/r62 18:07:16 *** Alberth has left #openttdcoop.devzone 18:08:15 <Brot6> zBase - Revision 36:2ea0b356ef9c: Add: Volumetric leaf materials and a demonstration temperate tree. XzephyrisX @ http://dev.openttdcoop.org/projects/zbase/repository/revisions/2ea0b356ef9c 18:10:41 <Ammler> it seems like planetmaker copied the opengfx spec, which isn't a very clever idea, as that is very special 18:12:37 <Ammler> opengfx seems to lack some ignore rules 18:21:59 <Brot6> OpenGFX+ Trains - Revision 762:5145c1c9f634: Feature: Afrikaans language support, thanks te_lanus XXotic750X @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/5145c1c9f634 18:22:30 <Brot6> OpenGFX+ Trains - Revision 763:4266ba425abd: Merge with default XXotic750X @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/4266ba425abd 18:23:16 *** Xotic750_ has joined #openttdcoop.devzone 18:25:51 <Brot6> Dutch Track Set - Bug #4101 (Closed): DevZone compile failed XcompilerX @ http://dev.openttdcoop.org/issues/4101 18:25:51 <Brot6> Dutch Track Set - Revision 86:a542bf8f3e0b: Fix #4101: When there are no capitals in the filename, a... XTransportmanX @ http://dev.openttdcoop.org/projects/dutchtracks/repository/revisions/a542bf8f3e0b 18:25:51 <Brot6> Dutch Track Set - Bug #4101 (Closed): DevZone compile failed XTransportmanX @ http://dev.openttdcoop.org/issues/4101#change-11201 18:31:24 <Brot6> zbuild: compile of r13 still failed (#4096) - http://bundles.openttdcoop.org/zbuild/nightlies/ERROR/r13 18:35:40 <Brot6> bandit: rebuild of r553 done (1 warnings) (Diffsize: 8191) (DiffDiffsize: 1013) - http://bundles.openttdcoop.org/bandit/nightlies/r553/log 18:40:50 <Brot6> cets: rebuild of r700 done (195 warnings) (Diffsize: 45519) (DiffDiffsize: 45517) - http://bundles.openttdcoop.org/cets/nightlies/r700/log 18:44:06 <Brot6> Revived US Trainset - Bug #4102 (New): DevZone compile failed XcompilerX @ http://dev.openttdcoop.org/issues/4102 18:44:06 <Brot6> Dutch Tram Set - Bug #4103 (New): DevZone compile failed XcompilerX @ http://dev.openttdcoop.org/issues/4103 18:45:30 <Brot6> make-nml: compile of r14 still failed (#4048) - http://bundles.openttdcoop.org/make-nml/nightlies/ERROR/r14 18:47:06 <Brot6> britrains: rebuild of r45 done (7 warnings) (Diffsize: 67278) (DiffDiffsize: 25122) - http://bundles.openttdcoop.org/britrains/nightlies/r45/log 18:50:39 <Brot6> frenchtowns: compile of r6 still failed (#4058) - http://bundles.openttdcoop.org/frenchtowns/nightlies/ERROR/r6 18:51:58 <Brot6> zBaseBuild - Revision 45:b6797968bd08: Fix: use \FFOT<something> as GRFID for the extra GRF. This is... XRubidiumX @ http://dev.openttdcoop.org/projects/zbasebuild/repository/revisions/b6797968bd08 18:51:58 <Brot6> zBaseBuild - Revision 46:5272d073f95f: Add: extra shore sprites XRubidiumX @ http://dev.openttdcoop.org/projects/zbasebuild/repository/revisions/5272d073f95f 18:54:41 <Brot6> ogfx-rv: rebuild of r162 done (Diffsize: 8735) (DiffDiffsize: 1337) - http://bundles.openttdcoop.org/ogfx-rv/nightlies/r162/log 18:55:02 <Brot6> dutchtracks: update from r82 to r86 done - http://bundles.openttdcoop.org/dutchtracks/nightlies/r86 18:56:02 <Brot6> ogfx-landscape: rebuild of r111 done (2 warnings) (Diffsize: 1320) (DiffDiffsize: 193) - http://bundles.openttdcoop.org/ogfx-landscape/nightlies/r111/log 18:58:26 <Brot6> DACH Trains - Bug #4104 (New): DevZone compile failed XcompilerX @ http://dev.openttdcoop.org/issues/4104 18:59:54 <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: ogfx-industries (Diffsize: 129404), foobarstramtracks (Diffsize: 28769), friss (Diffsize: 2160), manindu (Diffsize: 2), newgrf_makefile (Diffsize: 1), swisstowns (Diffsize: 51), dutchroadfurniture (Diffsize: 203965), spanishtowns (Diffsize: 8), swedishrails (Diffsize: 1836), german-townnames (Diffsize: 5042), belarusiantowns (Diffsize: 72), 18:59:54 <Brot6> indonesiantowns (1 warnings) (Diffsize: 350), debugveh (Diffsize: 989), airportsplus (Diffsize: 6970) 19:34:38 <Brot6> zbuild: compile of r13 still failed (#4096) - http://bundles.openttdcoop.org/zbuild/nightlies/ERROR/r13 20:13:46 *** Xotic750_ has quit IRC 20:17:56 *** frosch123 has quit IRC 22:06:57 <Brot6> Berries - Revision 38:df6d4cc76435: Change: Move the process of initiating the irc connectiong to a ... XdihX @ http://dev.openttdcoop.org/projects/berries/repository/revisions/df6d4cc76435 22:06:57 <Brot6> Berries - Revision 39:e7748066e565: Change: use the new connection behavior of the IrcBot XdihX @ http://dev.openttdcoop.org/projects/berries/repository/revisions/e7748066e565 22:06:57 <Brot6> Berries - Revision 40:13990973ef2f: Change: Rename the Plugin to "IRC" (has an effect on config and ... XdihX @ http://dev.openttdcoop.org/projects/berries/repository/revisions/13990973ef2f 22:07:50 *** Zuu_ has joined #openttdcoop.devzone 22:07:58 <dihedral> good night 22:15:01 *** Zuu has quit IRC 22:16:27 *** Zuu_ has quit IRC 22:37:42 *** LordAro has quit IRC