Log for #openttdcoop.devzone on 1st October 2011:
Times are UTC Toggle Colours
00:14:19  <Yexo> michi_cc:  nml r1671 improves the situation for this specific testcase
00:14:34  <Yexo> param[4] = (param[0] || param[1] || param[2]) ? ALL_CLIMATES : NO_CLIMATE;
00:14:34  <Yexo>  <- that test went from 15 to 9 actions
00:14:52  <Brot6> NewGRF Meta Language - Revision 1672:3a3fecae601b: Change: use less act9/actD to implement logica... (yexo) @
00:16:03  <michi_cc> That's still 4 actions too much :p
00:16:47  <Yexo> yes, the rest is not caused by the logical or but by the ternary operator
00:24:54  <Yexo> and with r1673 it's now reduce to 5 actions :)
00:25:16  <Brot6> NewGRF Meta Language - Revision 1673:28a464c82790: Change: don't simplify the expression of a con... (yexo) @
00:27:26  <Yexo> it basically came down to this: "a || b" was implement as "bool(a) | bool(b)", step one was to change that to "bool(a | b)"
00:27:34  <planetmaker> michi_cc: <-- try that
00:27:53  <planetmaker> it needs NML r1670 or later
00:28:25  <Yexo> since "a ? b : c" is compiled as "b; if(a) c" and "if(a)" is actually "if(a!=0)" "bool(a) ? b : c" is the same as "a ? b : c" which is what r1673 did
00:29:43  <Brot6> NewGRF Meta Language - Bug #3100: High (pseudo-) sprite usage for conditional expressions (yexo) @
00:29:43  <Brot6> NewGRF Meta Language - Bug #3076 (Closed): Make var "random_bits" available for all features (yexo) @
00:33:47  <michi_cc> planetmaker: Still quite slow compared to Linux I'd wager, but a lot better than before.
00:34:07  <planetmaker> good :-)
00:34:19  <planetmaker> cets is not fast anyway...
00:34:20  <michi_cc> time now outputs seconds instead of minutes
00:35:00  <michi_cc> (for depend only that is, compilation itself isn't lightning fast either)
00:35:36  <michi_cc> Quite a lot seconds, but still... ;)
00:35:47  <planetmaker> hehe
00:36:34  <planetmaker> the whole thing here takes definitely longest of all the NewGRFs I have here
00:37:00  <planetmaker> I guess I could as well commit this makefile update
00:37:10  <planetmaker> I need to test it on the individual NewGRFs now anyway ;-)
00:38:24  <planetmaker> real	3m14.641s
00:38:24  <planetmaker> user	3m0.259s
00:38:37  <planetmaker> for one complete run of 'make' on cets
00:38:47  <planetmaker> without usage of -j
00:40:29  <Brot6> Example NewGRF Project - Revision 360:b9a1326fb7ee: Fix: Language directory must not be part of u... (planetmaker) @
00:40:29  <Brot6> Example NewGRF Project - Revision 361:035a81acd3fb: Fix: Don't depend on removed files (planetmaker) @
00:40:29  <Brot6> Example NewGRF Project - Revision 362:4691fa488a41: Fix: Done fail when gimp is not needed. And u... (planetmaker) @
00:44:27  *** JVassie has quit IRC
00:47:20  <Brot6> Example NewGRF Project - Revision 363:6435995eafc1: Change: Include the %.scm and %.png targets o... (planetmaker) @
00:53:13  <michi_cc> real 3m43.064s, and all that from 2152 lines of source :p
00:56:46  <Brot6> Central European Train Set - Revision 167:8f5ef9da8330: Change: [Makefile] Update to makefile r363 (planetmaker) @
00:56:46  <planetmaker> :-)
00:56:53  <planetmaker> ^^ there, comitted
00:57:17  <planetmaker> but that's not *that* much longer than on my machine. You made it sound much worse :-)
00:57:41  <michi_cc> And the uncommented, compact grfcodec NFO is actually bigger than the generated NML source (1.2MB to 1.1MB)
00:57:51  <planetmaker> @calc 223 / 184
00:57:51  <Webster> planetmaker: 1.21195652174
00:57:55  <michi_cc> Old depcheck was alone 4 mins
00:57:55  <planetmaker> 21%
00:58:02  <planetmaker> oi
00:58:20  <planetmaker> I guess compilation is about 2.5 minutes in my time
00:58:33  <michi_cc> new depcheck is 58s
00:59:48  <planetmaker> longest is the gfx.dep check (which is NML)
01:00:29  <planetmaker> it's 53 real, 47 user here
01:00:44  <planetmaker> @calc 58/47
01:00:44  <Webster> planetmaker: 1.23404255319
01:17:21  <Brot6> Example NewGRF Project - Revision 364:a59b0fb830db: Change (r362): Adding as required... (planetmaker) @
01:51:22  <Brot6> OpenGFX+ Road Vehicles - Revision 140:4d0b73862d07: Change: [Makefile] Update to r364 (planetmaker) @
06:44:13  *** andythenorth has joined #openttdcoop.devzone
06:50:38  *** andythenorth has quit IRC
06:53:35  <Brot6> FIRS Industry Replacement Set - Revision 2621:90d6e30fd71c: Change: [Makefile] Update to r364 (planetmaker) @
06:58:56  <Rubidium> short night, oh maker of planets?
07:28:24  <Brot6> FIRS Industry Replacement Set - Revision 2622:629c0897307b: Fix (r2621): Forgotten file and updat... (planetmaker) @
07:28:28  <planetmaker> short night. But I woke up already :-)
07:37:29  <Rubidium> planetmaker: is there any schedule for a next release of ogfx?
07:38:42  <planetmaker> I'd say we should depend that a bit on how much will get added or whether an update is needed
07:38:55  <planetmaker> 0.3.6 as now is very much like OpenGFX trunk currently
07:39:18  <planetmaker> Normally I'd look at a release mid-December again
07:39:48  <planetmaker> why?
07:40:21  <Rubidium> the buoy sprite is causing some "discussion"
07:40:29  <planetmaker> oh?
07:40:37  <planetmaker> Did I miss that discussion?
07:40:56  <planetmaker> OpenTTD uses its own via action5 iirc
07:41:09  <planetmaker> what's wrong with that?
07:41:36  <planetmaker> i.e. the original base set sprites are ignored
07:41:55  <Rubidium> the discussion is from one of the guys from the "fix ttd bugs" thing
07:42:11  <Rubidium> the sprite we use for the buoys on the viewport and toolbar are the same
07:42:18  <planetmaker> yes
07:42:34  <Rubidium> and it's not replaced by action5; we just use the toolbar sprite in the viewport
07:42:55  <planetmaker> hm, the action5 does NOT replace the GUI sprite?
07:43:19  <planetmaker> well, it's just one sprite...
07:43:28  <planetmaker> separating that would make sense
07:43:41  *** andythenorth has joined #openttdcoop.devzone
07:43:56  <planetmaker> separating that could be sufficient reason to make an extra release of OpenGFX
07:44:22  <Rubidium> yeah, but it feels kinda pointless for a single sprite
07:45:10  <Rubidium> on the other hand, to what extent do you have different canal edge / aqueduct graphics for the different climates?
07:45:45  <planetmaker> Let's check
07:47:00  <planetmaker> each terrain seems to have its own. Though they don't differ much
07:47:31  <Rubidium> ah, okay... that's better than with the original graphics where it's all the same ;)
07:48:32  <planetmaker> ah, the grassy border? Yes, that was not an issue here since the first full release
07:50:00  <planetmaker> I only recently stumbled over that when checking TTD base set and wondered about that
07:50:29  <Rubidium> hmm... climate "aware" airport previews... might be interesting as well
07:50:39  <Rubidium> but first some groceries I guess
07:50:45  <planetmaker> yup. and yup
07:51:28  *** JVassie has joined #openttdcoop.devzone
07:53:46  <Brot6> OpenGFX+ Airports - Feature #3101 (New): Climate-aware preview images (yexo) @
07:56:37  <planetmaker> :-)
07:57:05  <planetmaker> Terkhen: just fyi: I pushed the makefile changes to ogfx+rv
07:57:18  <Terkhen> awesome, thank you planetmaker :)
07:57:39  <planetmaker> it's slower now :S
07:57:48  <planetmaker> The nml dep check is not particularily fast
07:58:29  <Terkhen> hmmm... but it isn't recreating every file whenever you commit or change one of the xcf files anymore?
07:58:48  <planetmaker> sure. That it doesn't
08:00:43  <planetmaker> In principle you should also be able to define several files wherein you define the rules on how to create png images
08:00:53  <planetmaker> that's mean less re-creation when you change that file
08:01:25  <planetmaker> which might be interesting, as changing png_source_list needs to trigger a re-generation of all png files
08:01:34  <planetmaker> which depend on it
08:03:49  <Terkhen> if the generation of pngs is triggered less, then an increase in time is not important
08:03:55  <Terkhen> and that sounds interesting indeed
08:04:03  <Terkhen> maybe a png_source file for each xcf file
08:04:23  <Terkhen> I'll open a task
08:05:22  <Terkhen> I don't think I'll be expending time with ogfx-rv in the foreseeable future, though... no feedback in weeks + 3000 downloads = done
08:05:23  <Terkhen> :P
08:07:27  <Brot6> OpenGFX+ Road Vehicles - Feature #3102 (New): Define separate png_source_list files for each xcf ... (Terkhen) @
08:09:02  <planetmaker> yes, I thought about a separation like that. It'd make sense
08:12:04  <Terkhen> :)
08:38:18  *** andythenorth has quit IRC
09:52:45  *** frosch123 has joined #openttdcoop.devzone
11:16:54  *** Doorslammer has joined #openttdcoop.devzone
11:29:53  *** Doorslammer has quit IRC
11:48:14  *** hanf has joined #openttdcoop.devzone
12:02:00  <Brot6> Central European Train Set - Feature #3043: freight wagons (Eddi) @
12:50:53  <Ammler> planetmaker: about the use of hg archive, what is the difference between patch the repo and pack it and patch the repo, commit it and pack it?
12:51:15  <planetmaker> the commit is the difference
12:51:28  <Ammler> well, after packing, you strip it again
12:51:49  <Ammler> (or rollback)
12:52:06  <planetmaker> Why would I do "hg ci; hg bundle_src; hg rollback" when I can use "hg bundle_src"?
12:52:30  <planetmaker> I don't have to use hg archive; it just would be nicer makefile code
12:52:50  <Ammler> well, your makefile code does not work
12:53:04  <planetmaker> hu?
12:53:08  <Ammler> and my suggestion was to use hg archive to make the fix easier
12:53:11  <planetmaker> how does it not work?
12:53:22  <Ammler> with subrepos
12:53:36  <Ammler> that was the whole point :-)
12:53:59  <planetmaker> someone convinced me that (shared) sub repos (for graphics) is a bad thing ;-)
12:54:17  <Ammler> it's not about replacing current make bundle with hg archive
12:54:43  <planetmaker> it's only about bundle_?src anyway
12:54:54  <planetmaker> normal bundle is the compiled stuff ;-)
12:55:15  <Ammler> and the whole thing is important for opengfx only anyway
12:55:31  <Ammler> which is not worth
12:55:33  <planetmaker> yes. But I think we decided to not use sub-repos
12:55:37  <Ammler> as we could simply tar the whole repo
12:55:49  <planetmaker> yes... that's what now is done basically
12:56:02  <Ammler> well, with dependency onmercurial
12:56:05  <planetmaker> I copy the whole repo minus a few selected files and tar that
12:56:15  <planetmaker> yes, with dependency on hg. I don't mind
12:56:26  <Ammler> you still like to support source bundle without hg
12:56:35  <planetmaker> No :-P
12:56:46  <planetmaker> I removed that yesterday ;-)
12:57:02  <Ammler> really? :-o
12:57:50  <Ammler> so you convert the repo everytime?
12:58:04  <Ammler> or how do you remove files?
12:58:16  <planetmaker>
12:58:26  <planetmaker> hm, remove files?
12:58:46  <planetmaker> well, yes, I create a separate bundle_src_dir and copy all stuff I want to ship into taht dir
12:58:49  <planetmaker> then I tar it
12:58:59  <planetmaker> which is what we always did ;-)
12:59:02  <Ammler> ah, you do not tar the repo
12:59:07  <planetmaker> yup
12:59:08  <Ammler> just the workcopy, I guess
12:59:24  <planetmaker> actually a newly created directory
12:59:27  <Ammler> so why is mercurial a dependency?
12:59:51  <planetmaker> the files which need copying are given by hg st
13:00:10  <planetmaker> only that makes sure I copy all needed files
13:00:54  <planetmaker>
13:01:02  <Ammler> oh well, I meant hg as dependency for building
13:01:22  <planetmaker> for building the binary?
13:01:25  <Ammler> yep
13:01:41  <planetmaker> That's not strictly needed. You can still build the binary from a properly created source bundle
13:01:44  <Ammler> that is why I as suprised, that you changed that, which you didn't of course :-P
13:01:59  <planetmaker> oh, ok :-)
13:02:16  <Ammler> I think, the work you do to get rid of that dependency is not worth
13:03:09  <planetmaker> Well, it needs means to build a certain revision. That'll need work, too, if we just hg archive the stuff
13:03:25  <Ammler> as said, I would not use hg archive
13:03:30  <planetmaker> and look at the code. it's not that much
13:03:32  <Ammler> I would tar the whole repo
13:03:46  <Ammler> (with history (.hg)
13:04:08  <planetmaker> that'd be HUGE
13:04:14  <planetmaker> compared to a single revision
13:04:14  <Ammler> not really
13:09:44  <planetmaker> naja... maybe, maybe not. OpenGFX source would be twice the size
13:10:19  <planetmaker> 31M	./.hg and 17M	./sprites
13:12:12  <Ammler> yes, so no big difference, is it?
13:12:33  <Ammler> I mean, speaking as distro packager, I would not mind
13:12:47  <Ammler> suse doesn't pack sources on DVD anymore
13:13:23  <Ammler> we do also not care anymore, if package is .gz or .xz or whatever
13:13:43  <planetmaker> yes... but it'd mean creating a source bundle either is littered with all the stuff in that dir which is not part of the repo - or I loose it - or I clone the repo and tar that
13:13:49  <planetmaker> not really easier, too
13:14:09  <Ammler> well, the issue now is that it is complicated for you
13:14:25  <planetmaker> is it?
13:14:35  <Ammler> well, then get it working :-P
13:14:46  <planetmaker> it's 27  lines of code for all source bundles. And _what_ does not work?!
13:15:05  <planetmaker> it's working for over two years by what I can tell
13:15:21  <Ammler> sub-repos will be trashed?
13:15:26  <planetmaker> I guess
13:15:38  <Ammler> ok then, it should not hurt that much
13:16:40  <planetmaker> as said: people, including you iirc, convinced me that it'd be a nightmare to verify the automatic updates when pulling in the graphics repo which was updated by another project
13:16:44  <Ammler> as said, I would not invest any time in this, as opengfx is the only project, which needs it, and there we could also simply tar the whole repo
13:17:08  <Ammler> planetmaker: it was not working
13:17:08  <planetmaker> well... yes...
13:17:28  <Ammler> I never said, you shouldn't use sub-repos, I liked the idea
13:17:38  <planetmaker> I might toy with that idea another time. But not now really. It works as is and... yes, tmwftlg right now :-)
13:17:53  <planetmaker> yes, I still like it somehow :-)
13:18:07  <planetmaker> But it has its rough edges, too
13:18:25  <Ammler> but the other issue not working right now is the optional nml files
13:18:31  <Ammler> or is that fixed in the meantime?
13:18:49  <planetmaker> probably not. I didn't spend much time on that
13:19:34  <Ammler> maybe with nml 0.2 it might be worth to check again...
13:19:45  <planetmaker> getting the gimp dependency work was more important to me ;-)
13:19:54  <Ammler> same issue there
13:20:01  <planetmaker> hm?
13:20:15  <Ammler> isn't that optional too?
13:20:20  <planetmaker> It is
13:20:30  <Ammler> so why should that work, but nml not?
13:22:34  <Ammler> also you run "prerun" nml now, it might be a good time to overthink the idea about support for include and substitution
13:23:05  <Brot6> Unrealistic Trainset - Feature #3103 (New): 90s EMU (chrisbooth) @
13:24:01  <planetmaker> include and substitution?
13:24:58  <Ammler> get rid of damn gcc
13:25:57  <planetmaker> well. what nml now allows is to write dependencies in makefile style. Replacing the cpp is an entirely different thing.
13:26:11  <planetmaker> Yes, it'll be nice. Certainly also possible
13:26:14  <Ammler> yes
13:26:38  <Ammler> but one of the reasons, you didn't like include was teh need to run it twice
13:26:40  <planetmaker> But for what I know, it's quite a bit more work than the dep target I added now
13:26:55  <Ammler> which is now obsolete :-)
13:28:50  <planetmaker> eh?
13:29:03  <planetmaker> how is it obsolete?
13:29:09  <Ammler> the reason you had
13:30:55  <planetmaker> well. Running gcc is actually *very* fast
13:31:25  <planetmaker>
13:31:51  <Ammler> oh well
13:31:52  <planetmaker> the dep check via NML is about 250 times slower
13:32:16  <Ammler> gcc is not available for the windows guys, that is the reason against it
13:32:38  <planetmaker> well, it is. They need make anyway
13:32:57  <Ammler> what for would make be needed?
13:33:13  <planetmaker> automatic versioning and stuff
13:33:26  <planetmaker> bundling, installation, ...
13:33:40  <Ammler> yesyes, make is needed for us
13:34:03  <Ammler> if you use the makefile framework
13:34:09  <planetmaker> yes yes.
13:34:19  <Ammler> but the idea would be make nml useable without :-)
13:34:24  <planetmaker> And soonish Yoshi and the other guy will ask us how to get things running ;-)
13:34:33  <planetmaker> nml is usable without ;-)
13:34:38  <Ammler> not really
13:34:43  <planetmaker> Just don't use c syntax ;-)
13:34:59  <Ammler> well, depends how you define "useable" :-P
13:35:06  <planetmaker> you also can use an arbitrary pre-processor. Maybe m4 ;-)
13:35:25  <Ammler> yes, or nml
13:35:32  <Ammler> since it does pre-process
13:36:22  <Ammler> I do not care to tell people, you need to install linux to get nml working
13:36:36  <Ammler> but it is a big step for beginners
13:37:01  <planetmaker> nml does not pre-process really. The dependency check is just another output method for the NewGRF
13:37:10  <Ammler> for us it was easy, as we first switched to linux and then used nml
13:37:25  <Ammler> we did not install linux to get nml working...
13:37:39  <planetmaker> Well, no one disputes that nml handling includes natively is useful and desirable :-)
13:38:24  <planetmaker> But no-one wrote that pre-processing step so far
13:38:46  <Ammler> he, you run the dependency check while you build the nml?
13:38:57  <Ammler> so how is that useful then?
13:39:29  <Ammler> I thought, you run it once for dep check and if that succeeds another time to build it
13:39:38  <planetmaker> That's what is done
13:40:22  <planetmaker> But still, conceptually the dep check is an output type. NML is read, and found graphics files are output (detailed action parsing etc. is skipped then)
13:41:00  <Ammler> needed, else it would fail
13:41:29  <Ammler> it is quite strange, imo
13:41:57  <Ammler> not sure, if nml is the right tool to create that dep file
13:42:30  <Ammler> might also be the reason, it is that slow
13:42:55  <planetmaker> ok, maybe rephrased: The dep output is added at a stage where the file is already read and the NML knows about the graphics files it should use. Skipped is all parsing of switches, actions etc. which needs conversion to... hex for grf output
13:43:35  <planetmaker> and... gcc does the same for c(pp) files. Thus it seems logical
13:43:42  <planetmaker> Even the arguments are very similar ;-)
13:50:17  <planetmaker> unfortunately I couldn't make it identical
16:42:34  *** StepanBarth has joined #openttdcoop.devzone
16:45:49  <Brot6> Central European Train Set - Feature #2924: Prussian steam engines (oberhuemer) @
16:46:47  <Brot6> Central European Train Set - Feature #2924: Prussian steam engines (oberhuemer) @
16:54:48  <Yexo> <planetmaker> But still, conceptually the dep check is an output type. NML is read, and found graphics files are output (detailed action parsing etc. is skipped then) <- actually most of the parsign is already done at that stage
16:55:08  *** StepanBarth has quit IRC
17:02:34  *** ODM has joined #openttdcoop.devzone
17:03:54  *** JVassie has quit IRC
17:04:16  *** JVassie has joined #openttdcoop.devzone
17:10:29  <Brot6> nml: update from r1670 to r1673 done -
17:17:17  <Brot6> Central European Train Set - Feature #2924: Prussian steam engines (Eddi) @
17:17:38  *** LordAro has joined #openttdcoop.devzone
17:20:16  <Brot6> FIRS Industry Replacement Set - Bug #3104 (New): DevZone compile failed (compiler) @
17:22:44  <Brot6> cets: update from r163 to r167 done (470 warnings) -
17:23:58  <Brot6> newgrf_makefile: update from r352 to r364 done -
17:26:29  <Brot6> NewGRF Meta Language - Revision 1674:513c509a247f: Fix: the input_multiplier properties didn't ac... (yexo) @
17:26:45  <Brot6> Central European Train Set - Feature #2924: Prussian steam engines (oberhuemer) @
17:28:05  <Brot6> ogfx-rv: update from r139 to r140 done -
17:30:54  <Brot6> ogfx-industries: rebuild of r123 done (1 warnings) (Diffsize: 129173) (DiffDiffsize: 160780) -
17:31:55  <Brot6> firs: compile of r2622 still failed (#3104) -
17:33:16  <planetmaker> Yexo: yes, I know that it is done there already. That's why adding it as output type was so easy :-)
17:33:35  <Brot6> foobarstramtracks: rebuild of r23 done (Diffsize: 37000) (DiffDiffsize: 42910) -
17:34:59  <planetmaker> hm... I broke FIRS... :S
17:35:11  <Brot6> vactrainset: compile of r1 still failed (#3044) -
17:40:04  <Brot6> frenchtowns: compile of r6 still failed (#3099) -
17:40:50  <planetmaker> I wonder how it breaks...
17:46:46  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: ogfx-trains (Diffsize: 36114), narvs (11 warnings), manindu (Diffsize: 2), rust, dutchtramset (Diffsize: 25964), swisstowns, dutchroadfurniture (Diffsize: 1984), spanishtowns (Diffsize: 2), ogfx-landscape (1 warnings) (Diffsize: 36070), swedishrails, german-townnames, belarusiantowns (Diffsize: 30), indonesiantowns (1 warnings) (Diffsize: 1),
17:46:46  <Brot6> airportsplus (Diffsize: 948426)
17:52:21  <Brot6> AroAI - Revision 54:fbb2e459bd72: Doc: Add doxygen-style comments to functions in main.nut (LordAro) @
17:52:21  <Brot6> AroAI - Revision 55:7b03ed21b3ad: Doc: Doxyment of (LordAro) @
17:52:21  <Brot6> AroAI - Revision 56:0ea66e3eb197: Doc: manager.nut (LordAro) @
17:52:21  <Brot6> AroAI - Revision 57:b6ef13a256d4: Cleanup: Typos, coding style and unneeded comments (LordAro) @
17:52:25  <Brot6> AroAI - Revision 58:e6c9e4834e0d: Doc: util.nut (LordAro) @
17:52:28  <Brot6> AroAI - Revision 59:c9ab97e56fd0: Doc: vehiclemanager.nut (LordAro) @
17:52:31  <Brot6> AroAI - Revision 60:351670fdf6f6: DOc: Tidy up the readme a bit (LordAro) @
17:59:24  *** LordAro has quit IRC
18:17:42  *** JVassie has quit IRC
18:18:56  <planetmaker> Yexo: one of NML r1671 ... 1674 breaks FIRS
18:19:40  <Yexo> could you narrow it down for me please?
18:20:08  <Yexo> sorry to ask, but nml randomly crashes in cygwin due to dll problems
18:20:15  <Yexo> it runs correctly like 1 out of 10 times
18:20:34  <planetmaker> oh :S
18:20:44  <planetmaker> that sounds painful
18:20:47  <Yexo> it is :(
18:21:29  <planetmaker> nmlc: "sprites/nml/industries/arable_farm.pnml", line 109: Unrecognized identifier 'arable_farm' encountered  <-- that's the compile error I get
18:21:55  <planetmaker> and it seems to be r1672
18:22:14  <planetmaker> actually as it seems during dep check
18:23:18  <planetmaker> hm, not only
18:23:57  <planetmaker> yes, confirmed r1672.
18:25:00  <Yexo> I don't see anything suspicious in that commit
18:27:33  <planetmaker> I can't say that it looks suspicious either
18:27:56  <Yexo> fixed the dll problem, now trying to reproduce here
18:28:01  <Yexo> but make takes awfully long
18:29:38  <planetmaker> hm... nmlc ogfx-landscape.nml doesn't produce a grf anymore...
18:29:44  <planetmaker> it just pretends
18:29:45  *** JVassie has joined #openttdcoop.devzone
18:37:34  *** hanf has quit IRC
18:38:05  *** hanf has joined #openttdcoop.devzone
18:38:33  <Brot6> NewGRF Meta Language - Revision 1675:e6e79c4a4026: Fix r1672: make firs work again (not sure why ... (yexo) @
18:42:06  <Yexo> ok, both problems fixed
18:42:26  <Brot6> NewGRF Meta Language - Revision 1676:66f3c030b1b9: Fix r1670: automatically create a grf if no ou... (yexo) @
18:53:36  <planetmaker> he, great :-)
18:53:38  <planetmaker> thank you
19:02:08  <Brot6> clientpatches: compile of r22969 still failed (#2964) -
19:07:17  <Brot6> openttd-vehiclevars: update from r22967 to r22969 done -
19:09:03  <Brot6> serverpatches: compile of r22969 still failed (#2966) -
19:11:01  <Brot6> 32bpp-ez-patches: compile of r22969 still failed (#2446) -
20:38:10  <Brot6> Central European Train Set - Revision 168:9a40c6b852ae: remove unused custom callback pnml files (Eddi) @
20:38:10  <Brot6> Central European Train Set - Revision 169:5c738756acd9: attempt at refining the cargo wagon schem... (Eddi) @
20:38:10  <Brot6> Central European Train Set - Revision 170:c240b699a2de: fix tenders of the steam engines (Eddi) @
20:40:01  *** frosch123 has quit IRC
21:05:39  <Brot6> Central European Train Set - Feature #3043: freight wagons (michi_cc) @
21:26:04  *** ODM has quit IRC
22:13:26  <Brot6> Central European Train Set - Feature #2924: Prussian steam engines (oberhuemer) @
22:19:13  <Brot6> Central European Train Set - Feature #2924: Prussian steam engines (oberhuemer) @
22:20:24  <Brot6> Central European Train Set - Feature #3105 (New): Länderbahn electric engines and MUs (oberhuemer) @
22:21:34  <Brot6> Central European Train Set - Feature #2924: Prussian steam engines (oberhuemer) @
22:38:40  <Brot6> Central European Train Set - Revision 171:0fcc7e0778f6: warning when articulated vehicle ID is > 128 (Eddi) @

Powered by YARRSTE version: svn-trunk