Log for #openttdcoop.devzone on 26th July 2012:
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 @
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>
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
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 @
08:13:49  <Brot6> zBuild - Revision 9:dcd2837c2560: Add: Fetch script for updating the subrepos XAlberthX @
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>
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 @
09:09:40  <Brot6> OpenGFX+ Trains - Revision 758:a1997c3c3fcd: Update: Sprites for monorail refrigerated wagon to show... XXotic750X @
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) -
09:29:27  <Brot6> zbuild: compile of r8 still failed (#4096) -
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 @
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) -
10:39:03  <Brot6> zbuild: compile of r9 still failed (#4096) -
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:
11:00:14  <Webster> Title: Transport Tycoon Forums View topic - Draw articulated parts in the purchase menu. (at
11:00:18  <planetmaker> Hirundo, I gave you full ssh to the CF, so that you can manually start it: ssh -p22
11:00:41  <planetmaker> ./misc/compiler/ 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) -
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>
11:11:33  <Brot6> zBase - Revision 34:be018779f068: Add: Power station (without smoke or spark special effect sprites)... XzephyrisX @
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 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>
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 @
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) -
11:39:55  <Hirundo> Ammler: Why does neither stdout nor stderr end up here?
11:42:04  <Hirundo> The nml.spec seems to suggest to me that both stdout and stderr are sent there, see
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>
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> <- 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 @
12:27:14  <Brot6> OpenGFX+ Trains renders - Revision 48:30fb45823516: Add: Monorail early livestock wagons and rendere... XXotic750X @
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 @
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 @
12:39:47  <Brot6> OpenGFX+ Trains - Revision 761:711e1ee05355: Merge with default XXotic750X @
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 @
13:02:22  <Brot6> NewGRF Meta Language - Revision 1954:f4355c057d93: Fix: Set nml flags seperately in regression makef... XHirundoX @
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 -
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 @
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 "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 @
13:35:56  <Brot6> zBaseBuild - Revision 37:0da8f6a88122: Add: Some bridges (not finished yet) XAlberthX @
13:35:56  <Brot6> zBuild - Revision 10:715cf495bc10: Change: Updated subrepos XAlberthX @
13:51:08  <Brot6> zBuild - Revision 11:9c6c090c393e: Add: Power station XAlberthX @
13:51:10  <Brot6> zBaseBuild - Revision 38:7308558a1ba3: Add: Power station XAlberthX @
14:17:56  <Brot6> zBase - Bug #4098 (Closed): Arctic maglev too green XRubidiumX @
14:17:56  <Brot6> zBase - Revision 35:fea2f0864fbd: Fix (r27): Change arctic maglev to correct grass texture. Bug #409... XzephyrisX @
14:17:56  <Brot6> zBase - Bug #4098 (Closed): Arctic maglev too green XzephyrisX @
14:36:24  <Brot6> zbuild: compile of r10 still failed (#4096) -
14:36:41  <Rubidium> afternoon
14:37:04  <Brot6> zbuild: compile of r10 still failed (#4095) -
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:    This comment from zephyris?
14:56:27  <Webster> Title: Transport Tycoon Forums View topic - OpenGFX+ Trains development and translations thread (at
14:56:50  *** LordAro has joined #openttdcoop.devzone
14:58:13  <Alberth> Anyone understand why this fails?
14:59:26  <Alberth>
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 @
15:02:30  <Brot6> zBuild - Revision 12:77c72f13d906: Add: Tropical desert terrain XAlberthX @
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 @
15:27:41  *** KenjiE20|SSH has quit IRC
15:28:30  <Brot6> zBaseBuild - Revision 41:01ba39418f79: Add: some level crossings XRubidiumX @
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 @
15:59:19  <Brot6> zbuild: compile of r12 still failed (#4095) -
15:59:19  <Brot6> zbuild: compile of r12 still failed (#4096) -
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 @
17:23:49  <Brot6> zBaseBuild - Revision 43:3b39c0398fd3: Add: Snowy arctic terrain XAlberthX @
17:23:49  <Brot6> zBuild - Revision 13:eb5b95de25fc: Updated zbasebuild XAlberthX @
17:28:59  <Brot6> firs: update from r2859 to r2860 done -
17:31:15  <Brot6> zbuild: update from  to r13 done -
17:34:08  <Brot6> zBaseBuild - Revision 44:40ea79d05b31: Add: fences to rails XRubidiumX @
17:47:15  <Brot6> opengfx: update from r978 to r980 done (12 warnings) -
17:49:24  <Brot6> dutchtrains: update from r629 to r633 done -
17:50:26  <Brot6> metrotrackset: update from r105 to r106 done -
17:52:11  <Brot6> fish: update from r823 to r825 done -
17:53:12  <Brot6> Dutch Track Set - Bug #4101 (New): DevZone compile failed XcompilerX @
17:53:27  <Brot6> ai-aroai: update from r60 to r62 done -
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 @
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 @
18:22:30  <Brot6> OpenGFX+ Trains - Revision 763:4266ba425abd: Merge with default XXotic750X @
18:23:16  *** Xotic750_ has joined #openttdcoop.devzone
18:25:51  <Brot6> Dutch Track Set - Bug #4101 (Closed): DevZone compile failed XcompilerX @
18:25:51  <Brot6> Dutch Track Set - Revision 86:a542bf8f3e0b: Fix #4101: When there are no capitals in the filename, a... XTransportmanX @
18:25:51  <Brot6> Dutch Track Set - Bug #4101 (Closed): DevZone compile failed XTransportmanX @
18:31:24  <Brot6> zbuild: compile of r13 still failed (#4096) -
18:35:40  <Brot6> bandit: rebuild of r553 done (1 warnings) (Diffsize: 8191) (DiffDiffsize: 1013) -
18:40:50  <Brot6> cets: rebuild of r700 done (195 warnings) (Diffsize: 45519) (DiffDiffsize: 45517) -
18:44:06  <Brot6> Revived US Trainset - Bug #4102 (New): DevZone compile failed XcompilerX @
18:44:06  <Brot6> Dutch Tram Set - Bug #4103 (New): DevZone compile failed XcompilerX @
18:45:30  <Brot6> make-nml: compile of r14 still failed (#4048) -
18:47:06  <Brot6> britrains: rebuild of r45 done (7 warnings) (Diffsize: 67278) (DiffDiffsize: 25122) -
18:50:39  <Brot6> frenchtowns: compile of r6 still failed (#4058) -
18:51:58  <Brot6> zBaseBuild - Revision 45:b6797968bd08: Fix: use \FFOT<something> as GRFID for the extra GRF. This is... XRubidiumX @
18:51:58  <Brot6> zBaseBuild - Revision 46:5272d073f95f: Add: extra shore sprites XRubidiumX @
18:54:41  <Brot6> ogfx-rv: rebuild of r162 done (Diffsize: 8735) (DiffDiffsize: 1337) -
18:55:02  <Brot6> dutchtracks: update from r82 to r86 done -
18:56:02  <Brot6> ogfx-landscape: rebuild of r111 done (2 warnings) (Diffsize: 1320) (DiffDiffsize: 193) -
18:58:26  <Brot6> DACH Trains - Bug #4104 (New): DevZone compile failed XcompilerX @
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) -
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 @
22:06:57  <Brot6> Berries - Revision 39:e7748066e565: Change: use the new connection behavior of the IrcBot XdihX @
22:06:57  <Brot6> Berries - Revision 40:13990973ef2f: Change: Rename the Plugin to "IRC" (has an effect on config and ... XdihX @
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

Powered by YARRSTE version: svn-trunk