Times are UTC Toggle Colours
00:05:05 *** KenjiE20 has quit IRC 01:36:29 <DJNekkid> hellow my slightly less drunk then me guys! 06:33:49 <Brot6> 2cc train set - Bug #1087 (New): Hoppers in arctic has wrong cargo color (Voyager1) @ http://dev.openttdcoop.org/issues/1087 06:52:18 <Ammler> planetmaker: 1.0.3 would be a good time for openmsx release, wouldn't? :-) 06:52:51 <planetmaker> I guess 06:52:58 <planetmaker> moin :-) 06:53:59 <Ammler> indeed, hello :-P 06:54:20 <Rubidium> it'd only need a solution for the sound "issue" 06:54:39 <Ammler> which the current release does also have 06:55:15 <Ammler> you could call it beta then :-) 06:57:28 <planetmaker> those sound "issues" are somewhat elusive... and I have very little idea how to tackle them (if at all) 06:57:30 <Ammler> what about, if you skip those tracks? 06:58:34 <planetmaker> that's already one of my problems: person A states that a,b,c make problems while d,e,f are fine and person b states that a,d,e are problematic and b,c,f are fine 06:58:55 <planetmaker> and.... I don't have a problem with either... 06:59:01 <Ammler> and something else than missing pats? 06:59:47 <planetmaker> I'm nearly tempted to call what is in the repo now 1.0 and do the fixing in >1.0 07:00:16 <Ammler> or keep <1.0 07:00:24 <Ammler> and call it 0.3.0 07:01:33 <planetmaker> I thought of calling it 0.9 ;-) 07:02:02 <Ammler> 0.9 ~ 1.0-beta 07:02:04 <planetmaker> but then, it makes less sense than 0.3 or 1.0 07:02:20 <Rubidium> we need a dev that can reproduce and fix the issue 07:02:25 <planetmaker> yes 07:02:37 <planetmaker> michi_cc seems to be able somewhat... 07:02:42 <Rubidium> I think just completely reinitialising dmusic after each song might work 07:03:18 <planetmaker> that's my idea, too. Possibly media player or so do just that 07:03:32 <planetmaker> but windows is an unsupported platform for me :-P 07:04:16 <Ammler> maybe, if you "fix" that, you can also add feature to change music set ingame 07:04:41 <planetmaker> that's a different issue completely 07:05:21 <planetmaker> but it'd make sense to add such feature 07:05:50 <planetmaker> btw, Rubidium how does OpenTTD decide upon defaults for base sets when it finds all, but no cfg? 07:06:19 <Rubidium> whatever is most complete and found first (I think) 07:06:29 <planetmaker> I yesterday got after renaming my cfg original graphics, original sound and John whatever anthology 07:06:29 *** ODM has joined #openttdcoop.devzone 07:06:49 <planetmaker> what defines 'most complete'? 07:07:06 <Rubidium> number of missing/wrong md5-ed files 07:07:22 <Ammler> and if all complete? 07:07:40 <planetmaker> found first then :-) 07:07:55 <Ammler> hmm, I would guess, randomly like newgrfs :-) 07:08:29 <Rubidium> NewGRFs are also "found first" (or found last) 07:09:00 <Ammler> yes, but the "list" is randomly, isn't? 07:10:29 <planetmaker> so... what shall I do about OpenMSX? Call it 1.0 and provide a fix later so that it comes out with 1.0.3 OpenTTD or wait even more? 07:10:51 <Rubidium> first wait another 2 weeks? 07:11:00 <planetmaker> for what? 07:11:13 <Rubidium> 1.0.3-RC1 being released 07:11:17 <planetmaker> :-) 07:11:19 <Rubidium> possible fixes of dmusic 07:11:42 <planetmaker> ok 07:11:56 <planetmaker> But then it might well be that it's 4 weeks 07:12:07 <planetmaker> I'll be mostly away the next 4 weeks 07:12:25 <Rubidium> releasing openmsx shouldn't be that much of an effort (I think) 07:12:34 <Rubidium> if you prepare most of it in advance ofcourse 07:12:34 <planetmaker> nope, not much. 07:12:54 <planetmaker> I should commit the swap of two of imuh3's songs and update the changelog and it'd be mostly done 07:12:54 <Ammler> does fixing dmusic need changes in openmsx? 07:15:32 <Rubidium> Ammler: no, but the question is whether that fixes it 07:27:20 <planetmaker> ^ 07:28:49 <Rubidium> foobar!!!!!! 07:29:07 <planetmaker> hm? 07:29:25 <Rubidium> saw him just post on the forum; he can reproduce the issue 07:29:47 <Rubidium> and I've got an idea that might do the trick 07:29:49 <planetmaker> http://dev.openttdcoop.org/issues/1078 <-- that? 07:30:03 <planetmaker> yes, he run a series of tests 07:31:08 <planetmaker> I asked him to run a few tests as he's the first and only one whom I came accross and could reasonably ask about that ;-) 07:33:06 <planetmaker> but michi_cc obviously can reproduce it, too 07:36:37 <planetmaker> but you know that :-) 07:37:29 <Rubidium> yup, though I've not seen him during "office hours" 07:47:19 <planetmaker> Rubidium, btw, what about back-porting the depot construction date? 07:47:29 <Rubidium> savegame 07:47:38 <planetmaker> Or did I miss that in the commit logs or is it as feature not back-portable? 07:47:51 <Rubidium> +bump 07:48:03 <planetmaker> hm. It changes savegames? And that's rather undesired for bug fix releases? 07:48:15 <planetmaker> (yes, sure it changes savegame) 07:49:37 <Rubidium> we rather prefer not to do savegame bumps in stable releases 07:49:45 <planetmaker> ok, understandable :-) 07:50:00 <Rubidium> as it would break loading nightlies since that stable release 07:50:07 <planetmaker> I just wondered... and didn't think about that. Oh... yes 07:50:51 <planetmaker> hm.. what would you do, if such a fix was required? 07:51:01 <planetmaker> It'd need some serious hacking of the saveload things, would it? 07:51:29 <planetmaker> or did that never happen before? 07:51:30 <Rubidium> hope there was some "free" SL_CONDNULL in the chunk 07:51:44 <planetmaker> hm 07:52:45 <Rubidium> otherwise... never had that problem yet 08:55:38 *** Alberth has joined #openttdcoop.devzone 09:10:54 <Rubidium> planetmaker: did busy schedule change since 0.2.1? 09:13:33 <Rubidium> hmm... apparantly not 09:13:52 <planetmaker> dunno... but why? 09:14:10 <Rubidium> in that case... /me doesn't notice any differences when it's played in virtualbox 09:16:57 <Rubidium> oh... now I do :) 09:20:03 <Rubidium> so... my "fix" doesn't work.. too bad 09:24:36 <planetmaker> :-( 09:24:51 <planetmaker> I haven't noticed it so far... have you seen this on linux? 09:25:38 <Rubidium> nope, but that's because timidity is fully restarted each time 09:47:06 <Rubidium> yay "success"... no more nasty sounding midis with dmusic 09:47:36 <Rubidium> although... no more sound from midis with dmusic either 09:47:41 <planetmaker> good :-) 09:47:46 <planetmaker> What's the issue or solution? 09:48:36 <Rubidium> I think it has to do with "downloading" the "samples" to the midi synth 09:50:08 <planetmaker> hm 09:51:47 <planetmaker> hm... this kogut is starting to become slightly annoying. Even though mostly his questions / suggestions are not that bad 09:52:15 <Rubidium> I fear his vacation started and he left his unstupidity at school 09:52:23 <planetmaker> yeah 09:56:08 <andythenorth> I like Kogut. He gives me feedback which I crave, and his suggestions are nearly always valid 09:56:22 <andythenorth> his bug reports could be better, but they are....pithy :) 10:00:04 <planetmaker> yes 10:18:49 <Rubidium> oh bah... 10:19:09 <Rubidium> taking the whole directmusic stack down and rebuilding it for each song works 10:19:32 <Rubidium> but taking down/clearing caches in the obvious parts doesn't work 10:19:58 <planetmaker> meh :S 10:43:14 <Rubidium> okay... I give up... 10:43:31 <planetmaker> :-( 10:43:43 <Rubidium> I can't be bothered to restart "only" 80%... then just restart everything 10:44:45 <Rubidium> and the cause is (I think) buggy DirectMusic stuff (not properly clearing something) and different instruments in the midis 10:47:42 <Rubidium> oh... and some songs could use a bit more imagination in their name 10:48:03 <Rubidium> TT Song, TT Song II, TT Theme Song 10:50:04 <planetmaker> yes, they could 10:50:17 <planetmaker> but the author is absent till... later, August or so 10:51:58 <planetmaker> and I'm not sure whether I just should give them random, crazy names ;-) 10:52:10 <planetmaker> besides, ttsong I + II get replaced by TTSong III + IV :-P 10:52:28 <planetmaker> I and II are already in there as other songs from him. I only noticed afterwards 11:04:18 *** KenjiE20 has joined #openttdcoop.devzone 11:23:43 <Brot6> 2cc train set - Revision 573:535ae3f61158: Fix: Typo in the english file (DJNekkid) @ http://dev.openttdcoop.org/projects/2cctrainset/repository/revisions/535ae3f61158 11:30:25 <Brot6> GRFCodec - Revision 168:c8b55786b336: Add: tags for 0.9.8, 0.9.9 and 0.9.10 (Rubidium) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/c8b55786b336 11:36:12 *** andythenorth has left #openttdcoop.devzone 11:47:33 <Brot6> Example NewGRF Project - Code Review #1086: which is not installed on CentOS or RHEL (Ammler) @ http://dev.openttdcoop.org/issues/1086#change-2855 12:15:56 <Brot6> Example NewGRF Project - Code Review #1086: which is not installed on CentOS or RHEL (Ammler) @ http://dev.openttdcoop.org/issues/1086#change-2856 12:18:09 <Brot6> Example NewGRF Project - Code Review #1086: which is not installed on CentOS or RHEL (Rubidium) @ http://dev.openttdcoop.org/issues/1086#change-2857 12:53:38 *** andythenorth has joined #openttdcoop.devzone 12:55:13 <Brot6> FIRS Industry Replacement Set - Feature #1088 (New): Indication of closure for all secondary indu... (foobar) @ http://dev.openttdcoop.org/issues/1088 12:58:26 *** planetmaker is now known as planeftmakefr 12:59:02 <Brot6> FIRS Industry Replacement Set - Feature #1089 (New): Forest in tropic (foobar) @ http://dev.openttdcoop.org/issues/1089 13:00:19 *** planeftmakefr is now known as planetmaker 13:15:26 *** Seberoth has joined #openttdcoop.devzone 13:49:54 *** FooBar has joined #openttdcoop.devzone 14:31:08 *** FooBar has quit IRC 14:31:30 *** FooBar has joined #openttdcoop.devzone 14:44:17 <Brot6> Redmine - Revision 3840: Force the test RAILS_ENV to help prevent purging data when mistyping. #4572 (edavis10) @ http://dev.openttdcoop.org/projects/redmine/repository/revisions/3840 14:53:01 <planetmaker> Oh, Rubidium, seeing the grfcodec commit, did you hear from DaleStan? 15:11:11 <Ammler> planetmaker: 2 weeks 15:11:26 <Ammler> the project is hidden 15:11:27 <Rubidium> planetmaker: no 15:11:45 <Rubidium> it's just flushing the stuff I've already had 15:11:54 <Rubidium> so Ammler could use it for your CF 15:13:37 <Ammler> did you change something else then upx and gcc45? 15:14:26 <planetmaker> ok, I was just curios :-) Thx for the update 15:17:23 <Rubidium> yeah, but nothing really serious 15:17:45 <planetmaker> is bundle_src already added? 15:17:56 <planetmaker> Otherwise I might go for that now 15:18:59 <Rubidium> no 15:19:07 <Rubidium> if you do such stuff, do it for nforenum as well :) 15:19:16 <planetmaker> well, yes, sure 15:19:27 * planetmaker just cloned both project6s 15:27:04 <planetmaker> hm, I guess it is okay, to change the 'modified' flag also to 'M' as for all other OpenTTD projects? 15:27:43 <planetmaker> well... can be done anytime 15:28:42 <Rubidium> I'd leave it as-is for now 15:28:49 <planetmaker> yep 15:29:22 <Rubidium> maybe change it after the release 15:30:52 <planetmaker> we can see then 15:31:30 <planetmaker> I also would like the hg revision number to show somewhere instead of only the hash. But also later, I guess 15:31:43 <planetmaker> it's another 'issue' anyway 15:32:05 <planetmaker> well, not instead, but jointly with the hash might seem good 15:36:03 <Ammler> if it matters, I would prefer the number 15:38:29 <Brot6> NFORenum - Revision 374:2dc2f1d6206d: Add: tags for 3.2.0-3.4.6 (Rubidium) @ http://dev.openttdcoop.org/projects/nforenum/repository/revisions/2dc2f1d6206d 15:41:44 <planetmaker> hm... if norev != 0 then versionstr = 3.4.6 ... 15:42:00 <planetmaker> well. I won't touch versioning for bundle_src then. 15:46:57 <planetmaker> BUNDLE_NAME = nforenum-custom-$(REV) <-- but I'd like to change the default bundle name. Objections, Rubidium ? 15:47:18 <planetmaker> the "custom" should go IMHO 15:47:43 <Ammler> custom might be useful with "M" 15:48:10 <planetmaker> yes. But I won't care about that so far... I'll use the the default versioning. 15:48:18 <planetmaker> Which now is hash + possibly an 'E' 15:48:28 <planetmaker> hm 15:49:01 <planetmaker> [BUNDLE] Creating nforenum-h2dc2f1d6E.tgz 15:49:02 <Ammler> well, just don't invest too much effort unit it is decided how to continue... 15:49:15 <planetmaker> yes, I don't. It's a slightly wrapped hg archive ;-) 15:49:27 <Ammler> no hash please 15:49:37 <planetmaker> that's the version detection. 15:49:46 <planetmaker> And it was decided to not change that. Yet. 15:50:42 <Ammler> hmm, hg is a rubi change, so tht can be changed :-) 15:50:46 <planetmaker> After the release: I'm also for changing some of that behaviour 15:54:37 <planetmaker> 374-2dc2f1d6206d ? 15:55:16 *** Seberoth has quit IRC 15:59:04 <Brot6> NFORenum - Revision 375:1a4b8d9f5087: Add: [Makefile] Target 'bundle_src' (planetmaker) @ http://dev.openttdcoop.org/projects/nforenum/repository/revisions/1a4b8d9f5087 16:04:51 *** FooBar has quit IRC 16:10:47 <Hirundo> Alberth: you implemented warnings as simple print statements? 16:11:05 <Alberth> yes, do we have something better? 16:11:43 <Hirundo> I used the warnings module in action 5 code 16:11:54 <Hirundo> i.e. import warnings, warnings.warn("msg") 16:12:56 <Alberth> sounds like a better idea 16:14:17 <Hirundo> It makes no real difference, but I think it improves maintainability since warnings can be grepped easily if we want to change the implementation 16:14:30 <Alberth> yes, you are right 16:14:47 <Alberth> didn't realize that we used the warnings module 16:15:21 <Brot6> GRFCodec - Revision 169:584109302c1a: Add: [Makefile] Target 'bundle_src' (planetmaker) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/584109302c1a 16:19:06 <Brot6> 2cctrainset: update from r572 to r573 done (1 errors) - http://bundles.openttdcoop.org/2cctrainset/nightlies/r573 16:19:36 <Brot6> NFORenum - Revision 376:6f93cc9ed0d5: Change: [Makefile] Don't pack CF files into the source tar ... (planetmaker) @ http://dev.openttdcoop.org/projects/nforenum/repository/revisions/6f93cc9ed0d5 16:19:55 <Hirundo> When I wrote action5 code, I added the first warnings in nml history there, now you are the second :) 16:19:57 <Brot6> firs: update from r1035 to r1037 done - http://bundles.openttdcoop.org/firs/nightlies/r1037 16:21:24 <Brot6> grfcodec: update from r167 to r169 done - http://bundles.openttdcoop.org/grfcodec/nightlies/r169 16:22:10 <Brot6> heqs: update from r347 to r348 done - http://bundles.openttdcoop.org/heqs/nightlies/r348 16:23:01 <Brot6> nml: update from r530 to r544 done - http://bundles.openttdcoop.org/nml/nightlies/r544 16:23:10 <Brot6> Following repos didn't need a nightlies update: 32bpp-extra (r36), airportsplus (r52), bros (r12), comic-houses (r70), fish (r386), newgrf_makefile (r120), nmts (r16), nutracks (r85), ogfxplus (r39), opengfx (r465), openmsx (r80), opensfx (r96), snowlinemod (r15), swedishrails (r135), worldairlinersset (r648) 16:25:38 <planetmaker> :-O 14 NML changes 16:26:22 <Ammler> planetmaker: I like tar.gz or tar.bz2 better 16:26:51 <Alberth> Hirundo: will fix that 16:27:18 <Ammler> [18:25] <planetmaker>  14 NML changes <-- there were some failed builds the last days 16:27:35 <planetmaker> Ammler, the regression should be fixed now 16:27:58 <Ammler> ? 16:28:03 <planetmaker> but yeah. That's 3(?) changes which were carried over from yesterday then 16:28:14 <planetmaker> Ammler, it failed due to the regression failing, did it? 16:28:16 <Ammler> not just yesterday 16:28:41 <Rubidium> Ammler/planetmaker: until the first releae of either it should just use the mercurial hashes 16:28:43 <planetmaker> Yes. Still it was three commits in the past which made it fail when Hirundo fixed that 16:28:52 <planetmaker> Rubidium, it does that. 16:28:59 <Ammler> Rubidium: I need revisions :-( 16:29:07 <Rubidium> after that we'll dump the svn revision completely and go with hg revisions 16:29:14 <Ammler> or tell me, how debian can work with hashes? 16:29:25 <Rubidium> Ammler: it shouldn't! 16:29:33 <planetmaker> Ammler, for releases you don't need that 16:29:34 <Rubidium> because this SHOULD NOT be used 16:29:37 <Ammler> same with rpm 16:30:16 <planetmaker> Ammler, you get your versions once we can go public :-) 16:30:28 <Rubidium> exactly 16:30:40 <Ammler> planetmaker: that is too late for me, we use it already :-) 16:30:45 <Rubidium> then it's just a little tweaking of "findversion.sh" and it should work quite well 16:31:18 <planetmaker> yep 16:31:28 <Ammler> but it is no issue, as long as we can overwrite whatever you do 16:31:43 <planetmaker> Ammler, what's the issue ... yeah, just do that 16:31:51 <Ammler> I'll add the hg rev to the last release 16:32:12 <Ammler> just check how the grfcodec rpm looks 16:32:24 <Rubidium> and debian would use 20100709-h23458736 (possibly without the -h2345678) 16:32:56 <Ammler> yes, that is because of git :-) 16:33:26 <Alberth> Hirundo: ~hat/nml/hg_push/nml/grfstrings.py:196: UserWarning: Warning: String u'STR_NAME_FOSTER_EXPRESS_TRAM' is defined in languages '0x1f', but not in the default language 0x7f. 16:33:26 <Alberth> % (strid, ", ".join(hex(lang_dict['lang']) for lang_dict in lang_dicts), hex(DEFAULT_LANGUAGE))) 16:33:26 <Alberth> Not exactly a nice, userfriendly error message, is it? 16:33:32 <Ammler> date is a good alternative 16:33:50 <Rubidium> though for "official" distros patching the last svn source with the gcc4.5 and upx patch should be enough 16:33:57 <Hirundo> Alberth: not exactly 16:34:24 <Ammler> yeah, current grfcodec works nicely 16:34:27 <Hirundo> The warning code was introduced before the error messages were improved 16:34:31 <Hirundo> let me check some stuff 16:35:13 <Alberth> I don't understand where the 2nd line comes from 16:35:37 <Ammler> we should copy the regression tests to grfcodec and nforenum 16:36:47 <Ammler> hmm, nforenum might need new code, but grfcodec should just be able to reuse the nfos from nml regression tests 16:37:54 <Ammler> or we just rebuild opengfx daily :-) 16:38:09 <Alberth> most of that output is useless in newgrf context, a 'good' nfocodec would fail with an error 16:38:12 <Rubidium> rebuild it when grfcodec/nforenum gets rebuilt 16:38:33 <Alberth> s/nfocodec/grfcodec/ 16:41:16 <Ammler> Alberth: _does_ grfcodec fail? 16:41:30 <Alberth> no idea 16:41:34 <Ammler> :-) 16:41:48 <Hirundo> Alberth: I think the best option would be to implement a generic.warning(message, pos) 16:42:06 * Alberth agrees with Hirundo 16:42:35 <Ammler> Rubidium: just rebuilding isn't enough, I need a reference 16:42:48 <Hirundo> Then, either the warning module should be persuaded to give nicer messages, or alternatively a print xxx works as well 16:43:14 <Alberth> Hirundo: sys.stderr.write() :) 16:43:24 <Hirundo> whatever :) 16:43:33 <Alberth> Hirundo: but I need to buy and make some food first 16:43:39 <Ammler> I guess, a new diff file 16:45:04 <Alberth> Hirundo: http://pastebin.org/387601 my changes, in case you need it 16:45:48 <Hirundo> I may look at it, after I have traced some obscure bug in expression handling code 17:07:13 <Hirundo> Is anyone yet using NML's replacenew block? planetmaker? 17:08:30 <Brot6> NewGRF Meta Language - Revision 545:5052f000d984: Codechange: Allow resolving Identifiers to Stri... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/5052f000d984 17:08:30 <Brot6> NewGRF Meta Language - Revision 546:08a270f20540: Feature: Per-sprite image files, including temp... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/08a270f20540 17:08:43 * andythenorth finishes work and ponders writing some more code 17:12:31 *** frosch123 has joined #openttdcoop.devzone 17:21:07 <andythenorth> quak 17:21:54 <frosch123> quak :) 17:22:43 <andythenorth> @seen foobar 17:22:43 <Webster> andythenorth: foobar was last seen in #openttdcoop.devzone 20 hours, 7 minutes, and 50 seconds ago: <FooBar> anyhoe, I'm off. Good night! 17:23:17 <andythenorth> planetmaker: ecs forests do look pretty good 17:39:11 *** Seberoth has joined #openttdcoop.devzone 17:39:42 <planetmaker> andythenorth: I do even have permission to implement them in OpenGFX+ (which would mean it'd become GPL'ed) 17:39:58 <andythenorth> you should then :) 17:39:59 <planetmaker> But... the absolutely undocumented code deterred me so far 17:40:15 <andythenorth> I would change the layout for FIRS, but the code for tree tiles would be useful 17:40:27 <planetmaker> He really seems to code it like plain hex without comments 17:40:38 <Ammler> not really nice to reuse graphics of a released newgrf 17:40:39 <Rubidium> those thousands of sprites? 17:40:42 <planetmaker> yep. Basically 17:41:02 <planetmaker> andythenorth: ECS forests have ~7 layouts or so 17:41:47 * andythenorth wonders if inventing new code is more or less work than documenting existing code 17:42:31 * andythenorth wonders if helping frosch123 finish field tiles is more or less work than writing a complex forest using normal tiles. 17:42:44 <planetmaker> andythenorth: by the looks of it ... and he really told me to just de-compile it as it's what he writes - it's... probably easier, i the idea and principle is clear 17:43:10 <planetmaker> andythenorth: getting that fields patch into trunk would be WAY more sustainable ;-) 17:43:20 <Ammler> George used ActionC to document :-) 17:43:26 * Rubidium wonders whether writing grf2nml is more or less work than figuring out george's code 17:43:33 <andythenorth> frosch123: thoughts...? :) 17:44:14 <planetmaker> Rubidium: my bet is 5:3 concerning the work load ;-) 17:44:26 <planetmaker> Ammler: yes. A lot 17:44:30 <Rubidium> and Paul's? 17:44:47 <planetmaker> paul's? 17:45:18 <Rubidium> http://g.sports.yahoo.com/soccer/world-cup/blog/dirty-tackle/post/Paul-the-octopus-has-made-his-final-selections?urn=sow,254898 17:45:19 <Webster> Title: Paul the octopus has made his final selections - Dirty Tackle - World Soccer Blog - Yahoo! Sports (at g.sports.yahoo.com) 17:45:43 <planetmaker> oh, that one again :-) 17:45:59 * frosch123 wonders how hard it is to turn grf2html into grf2nml 17:46:01 <planetmaker> andythenorth: you just got SAC's permission to re-use her trees ;-) 17:46:11 <andythenorth> I know :) 17:46:15 <planetmaker> oki :-) 17:46:24 <andythenorth> I don't share the common stolen trees obsession. I like default tress 17:46:27 <andythenorth> trees /s 17:46:30 <andythenorth> and opengfx trees 17:46:41 * planetmaker likes the variety :-) 17:46:49 <planetmaker> which includes also the Japanese mod 17:46:55 <frosch123> i thought you wanted to use the default trees for the forrest, i.e. whatever the player loaded 17:47:14 <Ammler> what is the advantage on including a released grf to another grf? 17:47:17 <planetmaker> frosch123: yeah, that's what ECS does. And IIRC what andy wants :-) 17:47:21 <planetmaker> and it's a good choice 17:47:45 <frosch123> andythenorth: the work for ecs-like forrests is a subset of the work for field-based forrests 17:47:49 <planetmaker> Ammler: a more "uniform" look 17:48:06 <frosch123> i.e. the most work is to do spritelayouts for the slopes 17:48:29 <planetmaker> in ECS? Yeah, most likely 17:48:37 <Ammler> planetmaker: so you "turned" from "one grf per feature" to a "everything in one grf" guy? 17:48:43 <frosch123> though maybe you can do that with some preprocessor magic 17:48:49 <planetmaker> Ammler: no 17:48:55 <planetmaker> Did I say it's a good choice? 17:49:10 <andythenorth> Ammler: I don't understand what you mean? :o 17:49:31 <Ammler> inclucing stolen trees to a grf, including ECS forest to a grf 17:49:48 <planetmaker> Ammler: FIRS obviously needs a forest. Correct? 17:49:51 <andythenorth> how else would it be done? 17:49:53 <planetmaker> So... what to do 17:50:00 <planetmaker> a) Re-invent the wheel 17:50:07 <planetmaker> b) look how others (ECS) do it 17:50:11 <andythenorth> we have to write some code somewhere, why not reuse code that has been written before? 17:50:24 <planetmaker> c) use sprites for the same thing found elsewhere and re-arrange them 17:50:28 <Ammler> does ECS allow nd? 17:50:39 <Ammler> -n 17:50:40 <planetmaker> Ammler: I have his personal, express permission for OpenGFX+ 17:50:44 <planetmaker> for the forest 17:51:07 <frosch123> planetmaker: d) use preprocessor to do ecs-like stuff a lot easier 17:51:12 <Ammler> planetmaker: then you support his ND license 17:51:17 <planetmaker> hehe @ frosch123 :-) 17:51:20 <planetmaker> Ammler: how so? 17:51:37 <Ammler> you should get him to change the license 17:51:39 <planetmaker> OpenGFX+ of course will remain GPL 17:51:40 * andythenorth is confused? 17:51:46 <Ammler> or else don't use his work 17:52:00 <planetmaker> Ammler: that's fundamentalism :-) 17:52:35 * Ammler doesn't like "GPL only for friends" :-) 17:52:38 <planetmaker> And it'd be anyway something very similar one would come up with. So looking how he does gives the fast-track to what we want 17:52:45 <planetmaker> ??? @ Ammler 17:52:56 <planetmaker> I don't get you 17:53:07 <Rubidium> sounds like George implicitly licensed it GPL for planetmaker 17:53:08 <andythenorth> GPL for friends -> leads to more code GPL -> net benefit 17:53:21 <Ammler> George and Pikka use those silly license, so everyone needs to ask them if they like to use something 17:53:36 <planetmaker> thank you, andythenorth 17:53:46 <andythenorth> Ammler: is fighting a war, planetmaker is fighting a battle :) 17:53:49 <Ammler> if you now do exactly that, you support their silly unfair doing 17:54:10 <planetmaker> Ammler: yes. But once they grant a piece in GPL, that piece can be re-used everywhere. 17:54:20 <planetmaker> I don't see a detriment there? 17:54:24 <Rubidium> Ammler: what's wrong if they license they stuff GPL for you; then you can release it as GPL to everyone 17:54:28 <planetmaker> Why not make a piece GPL, if I can't the whole? 17:54:29 <andythenorth> Ammler yes, but the sum total of GPL code in the world increases. It's a net good 17:54:40 <Ammler> but why not use the effort to make those people making the whole set gpl? 17:54:54 <andythenorth> because the effort may not pay off? 17:55:02 <planetmaker> Ammler: if you can't go through the wall, walk around it ;-) 17:55:32 <Ammler> but you have a Forrest 17:55:46 <Ammler> I would say, using that forest is going around 17:56:41 <planetmaker> yes. Exactly 17:56:56 <planetmaker> And as such I won a GPL forest which there wasn't before 17:57:05 <Ammler> OpenGFX? 17:57:06 <planetmaker> And which otherwise would remain CC-BY-NC-ND 17:58:32 <Ammler> hmm, well, go that hard way and ask again for every single piece then... 17:59:13 <planetmaker> Ammler: we asked them. We tried to convince them. They chose their license 17:59:21 <planetmaker> We can now bitch and annoy them. 17:59:22 <Ammler> yes, so you support them 17:59:26 <Ammler> why? 17:59:28 <planetmaker> Or we can extend the GPL base 17:59:33 <Ammler> just don't reuse their work 17:59:52 <planetmaker> why should I not re-use something which I may? And then everyone else, too? 18:00:07 <Rubidium> so Ammler is against opening up previously "closed" sources 18:00:25 <planetmaker> in a piece-wise manner 18:00:49 <Ammler> Rubidium: I don't think, it is worth the effort 18:01:10 <planetmaker> all or nothing didn't work with those guys. So trying it piecewise is fine for me. Anything I do will be with an open-source community - friendly license 18:01:16 <planetmaker> commercial or not. 18:01:37 <planetmaker> to date that is GPL 18:01:57 <Ammler> it is just so silly :-) 18:02:27 <planetmaker> even though the OSI kinda recommends the CCDL even more than GPL 18:02:44 <Ammler> DL? 18:03:24 <planetmaker> common development and distribution license 18:03:42 <Rubidium> lots of CC licenses aren't considered free (by Debian) 18:04:02 <planetmaker> yep. But ccdl is :-) 18:04:10 <Ammler> Rubidium: because of the commercial clause, I assume? 18:04:52 <Ammler> planetmaker: so, what does that have to do with the Forrest? 18:05:03 <Rubidium> and the ND 18:05:29 <Rubidium> all Debian packaging is in principle a derivation of the original packaging 18:06:00 <planetmaker> Ammler: what's your choice: more or less open source? 18:06:18 <planetmaker> if it is "more": why is it bad if only parts of a closed source are released? 18:06:24 <Ammler> planetmaker: not supporting people which do not support os :-) 18:06:39 <planetmaker> Ammler: how do I support them by this? 18:06:51 <Ammler> by asking them for every single piece 18:07:02 <planetmaker> They do support open source by releasing it to open source 18:07:19 <planetmaker> Ammler: yes. And then I ask for every piece. And in the end everything is open source 18:07:21 <Ammler> it would be something else, if he does paint you something for your project. 18:07:25 <planetmaker> Does the way matter? 18:07:28 <Ammler> (or code or whatever) 18:07:34 <planetmaker> The result is important 18:07:47 <Ammler> yeah, go for it. 18:07:55 <planetmaker> Ammler: yes, I can also re-use the wood cutter's hut, if I want 18:08:14 <Ammler> IMO, it would help the community more, if you get George to release his work os 18:08:32 <planetmaker> yes, that'd be nicer. But I don't see that happening 18:08:46 <planetmaker> Not for me not wanting or not having tried 18:09:22 <planetmaker> And I know when I should stop to bug a person about a particular topic. At least for some time 18:09:31 <Ammler> but you didn't 18:09:32 <planetmaker> At least sometimes I do ;-) 18:09:37 <planetmaker> Ammler: I didn't? 18:09:38 <Ammler> you asked him for the forest :-( 18:09:46 <planetmaker> ... 18:09:49 <Ammler> you didn't stop 18:10:09 <planetmaker> I talked to George in lengths. In great lengths. Had conversations over a few weeks a year ago concerning his licenses 18:10:20 <Ammler> I know 18:10:29 <Ammler> you make that all useless 18:10:47 <planetmaker> I wrote lengthy, very lengthy e-mails and explanations, breaking down everything to him. Explaining what the single licenses mean and imply as far as I knew and know 18:10:59 <Ammler> you show him now, that is license works 18:11:05 <Ammler> his* 18:11:13 <planetmaker> And then he chose CC-BY-NC-ND. Because that is in his eyes the only license which protects his work in Russia 18:11:38 <planetmaker> And you tell me I didn't try to convince him?! Come on! 18:11:46 <Ammler> did I? 18:12:17 <Ammler> I meant, you make your whole work useless, if you now use his work anyway... 18:12:18 <planetmaker> [20:08] <planetmaker> Not for me not wanting or not having tried 18:12:20 <planetmaker> [20:09] <planetmaker> And I know when I should stop to bug a person about a particular topic. At least for some time 18:12:22 <planetmaker> [20:09] <Ammler> but you didn't 18:12:28 <Ammler> you didn't stop 18:13:36 <Ammler> well, we stop, maybe I find later some other words to explain what I mean. 18:16:59 * andythenorth thinks the community would be better served by writing some code :P 18:17:14 <planetmaker> your point certainly is that "if you ask him for a piece of his work, he will less likely consider to release everything as GPL" 18:17:14 <andythenorth> planetmaker: although my brain is fried, we should try and get FIRS 0.3 done.... 18:17:20 <Ammler> andythenorth: fully agree :-P 18:17:23 <planetmaker> Well. We should :-) 18:18:25 <Ammler> planetmaker: will you also get his source? 18:18:40 <Ammler> or just decompiled grf? 18:18:44 <planetmaker> Ammler: he doesn't seem to really have one. 18:18:53 <planetmaker> Have you seen his code snippets in the forum? 18:19:21 <planetmaker> No, he didn't give me a source file, though I asked for it. He told me that grfcodec's output would be what he has, too 18:19:39 <planetmaker> even when I specifically and again asked for the (commented) source code 18:19:45 <planetmaker> He has no real comments... 18:19:54 <Rubidium> would he be mb and be using m4nfo? 18:20:30 <planetmaker> george=mb? 18:20:43 <planetmaker> I doubt :-) 18:21:24 <planetmaker> and I really think that George writes the NFO like that... dunno. Probably as brain training :-) 18:21:34 <planetmaker> intellectual challange :-) 18:23:24 <planetmaker> or do you know more on that topic than I do, Rubidium ? :-) 18:23:58 <Ammler> ECS is from mb mostly 18:24:40 <Rubidium> why wouldn't he release source if there isn't something special about it? 18:24:48 <Rubidium> so there must be something special about it 18:25:23 <planetmaker> well, it came across not like 'I don't want to give it to you' but as a 'there's no point to it'. 18:25:29 <Brot6> FIRS Industry Replacement Set - Revision 1038:c1a28243ada7: Add: file for closure check (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/c1a28243ada7 18:25:44 <planetmaker> dunno, though 18:28:06 <planetmaker> andythenorth: anything I can now reasonably do for FIRS? 18:28:22 <planetmaker> which can be done in an hour or so? 18:34:35 <andythenorth> planetmaker: I'm adding stubs for controlling secondary industry closure 18:34:45 <andythenorth> you could expand those as I do them... 18:39:48 <andythenorth> planetmaker: I've added those stubs now 18:39:57 <Brot6> FIRS Industry Replacement Set - Revision 1039:fe54e6b43b8e: Change: basic code for industry closu... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/fe54e6b43b8e 18:40:15 <planetmaker> ok... I'm not sure I'm very good with that, though 18:40:18 <andythenorth> the template industry_closure_check.pnfo needs varaction 2 chains that check the parameter 18:40:24 <andythenorth> :) 18:40:35 <andythenorth> nvm if you don't fancy it 18:45:11 <Alberth> frosch123: about grf2nml: yexo made a start, you just have to finish it :p http://devs.openttd.org/~yexo/nml/ 18:47:30 <Rubidium> planetmaker: did the monies for the BBQ make it? 18:48:12 * andythenorth boggles at his own code for closing power stations 18:48:21 * andythenorth must have been smoking crack that day 18:48:58 <planetmaker> Rubidium: yep :-) Thank you very much 18:49:03 <Rubidium> good 18:49:11 <planetmaker> arrived 29 june 18:51:44 *** FooBar has joined #openttdcoop.devzone 18:51:51 <andythenorth> planetmaker: is PARAM_CLOSE_SECONDARY simply 1 or 0? 18:51:55 <andythenorth> hi FooBar 18:52:05 <FooBar> hi Andy! 18:52:08 <planetmaker> andythenorth: yes 18:52:12 <planetmaker> those are 1 or 0 18:52:17 <planetmaker> all of those 4(?) 18:52:19 <andythenorth> should be easy to sort that one out then 18:52:40 <frosch123> Alberth: i don't know python, but it looks like the part grf2html already has :) 18:52:44 <planetmaker> hm... I'm not sure I fancy writing action2 chains in plain NFO :-P 18:52:52 <andythenorth> I'll do it :P 18:52:55 <andythenorth> it's easy 18:52:58 <Rubidium> FooBar: could you check whether tonight's nightly fixes the garbled sound for you? 18:52:59 <planetmaker> :-) 18:53:09 <planetmaker> andythenorth: yes. You meanwhile know all those numbers and patterns 18:53:14 <FooBar> Rubidium: sure 18:53:21 <planetmaker> I'd have to look up each :-) 18:53:36 <Alberth> frosch123: I did not study it too closely :) 18:53:47 <andythenorth> planetmaker: 1 == closure allowed? 18:54:10 <andythenorth> hmm 18:54:16 <planetmaker> hm. disallow IIRC :-) 18:54:29 <andythenorth> more difficult than I thought. I have to now provide my own closure conditions 18:54:30 <planetmaker> but it depends upon how it should be interpreted ;-) 18:54:35 <andythenorth> unless there's a cb I'm missing 18:55:18 <planetmaker> let me also know, FooBar :-) 18:55:34 <FooBar> ok, I'll post the results here ;) 18:55:35 <andythenorth> brrrr 18:55:44 <andythenorth> closure :P 18:57:10 <andythenorth> what factors *should* secondary closure depend on? 18:57:41 <andythenorth> hmm 18:57:47 <andythenorth> eddi is not this channel 18:58:41 * planetmaker considers rather to make OpenMSX release-ready 19:01:33 <frosch123> andythenorth: trash the idea of protection time :) 19:01:36 <frosch123> it never works 19:02:52 <FooBar> Rubidium: the problem is gone, but you also introduced a new one: the game freezes for around 2 seconds when it switches to the next song 19:02:58 <frosch123> maybe close secondary industries only if not serviced, and there is an industry of the same type nearby 19:04:36 <Rubidium> FooBar: oh lol! 19:04:44 <FooBar> well, not really... 19:04:58 <Rubidium> the music (maybe) does 19:05:55 <FooBar> There might be a reason why dmusic is depricated... 19:07:03 <Rubidium> but... does it hang OpenTTD or just take a while before the next song starts? 19:08:10 <FooBar> Unfortunately it really freezes OpenTTD: the mouse cursor doesn't move for a short period and then suddenly jumps to the new position when also the music starts 19:08:31 <planetmaker> hm :-( 19:08:44 <frosch123> threading! 19:08:46 * frosch123 hides 19:08:56 <planetmaker> :-) 19:09:20 <Rubidium> okay, so dmusic is "officially" just screwed 19:11:25 <FooBar> win32 isn't much better either: there is a short pause between songs for again about 2 second (no game freeze), but that cuts the first bit off the song as well. Sort of like the song is started, but the speakers are turned on a little bit later. 19:11:51 <Rubidium> so Midi + Windows == sucks 19:13:07 <FooBar> A possible solution could be to dump DirectMusic and implement DirectSound instead, as that is still supported by MS. The way I understood it, dmusic is a layer between software and dsound, but software can also communicate with dsound directly, although the API is more difficult 19:13:27 <FooBar> Or that's what I've read on wikipedia 19:14:03 <frosch123> since when can directsound play midi? 19:14:43 <FooBar> that I don't know 19:17:10 * Rubidium fears we'll just have to go for DirectMusic with threading then :( 19:17:38 <Brot6> OpenMSX - Revision 81:652d5d068844: Change: Replace 'TT song I' by 'Downtown cab ride' (both by i... (planetmaker) @ http://dev.openttdcoop.org/projects/openmsx/repository/revisions/652d5d068844 19:19:41 <Brot6> OpenMSX - Revision 82:3141a0ff4502: Change: Rename 'TT title theme' in 'OpenTTD journey' (planetmaker) @ http://dev.openttdcoop.org/projects/openmsx/repository/revisions/3141a0ff4502 19:22:05 <frosch123> Rubidium: maybe just for resetting the instruments? 19:22:18 <frosch123> and then polling in the regular place whether it finished 19:22:42 <Rubidium> possibly 19:23:02 <Rubidium> although... with x64 there's no directmusic, so the other thing should work as well 19:23:05 * frosch123 shuts up. he has no idea about the interaction 19:23:19 <Rubidium> and if that's broken as well... 19:23:41 <frosch123> what other thing? 19:24:39 <FooBar> waveout 19:24:53 <frosch123> waveout is for wave, not midi :) 19:25:20 <Rubidium> frosch123: the win32_m thing 19:25:30 <FooBar> sorry, I read the wrong thing :P 19:25:39 <FooBar> " win32: Win32 WaveOut Driver" 19:25:40 <Rubidium> frosch123: which uses MCI 19:25:56 <FooBar> but that's for the sound effects 19:26:12 <FooBar> (I mean the waveout, not MCI) 19:26:42 <Rubidium> -mwin32 is what I'm talking about 19:26:48 <Rubidium> you said that's broken as well 19:27:05 <FooBar> yes, correctly 19:27:24 <FooBar> sorry for the confusion, I was reading the command line help, but read the wrong "win32" entry 19:28:20 <FooBar> But yes, I set -mwin32 as command line option, and that doesn't freeze, but does cut of 1 or two seconds off the beginning of a song and there is a pause between songs 19:28:42 * FooBar better shuts up now to let the professionals handle it 19:29:28 <Rubidium> we're literally telling MCI (win32): play song from 0 and then just check whether it's playing or not 19:29:40 <Rubidium> so any delays/cuts are purely caused by MCI/Windows 19:30:29 <FooBar> I did have WinAmp open (but not playing anything), let me check if that has an influence on the matter 19:31:40 <FooBar> nope, same thing 19:34:08 <Brot6> OpenMSX - Revision 83:7b3dffde27a1: Update: Let changelog reflect recent changes (planetmaker) @ http://dev.openttdcoop.org/projects/openmsx/repository/revisions/7b3dffde27a1 19:48:03 <Brot6> FIRS Industry Replacement Set - Revision 1040:c899434b95c7: Change: test code for secondary indus... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/c899434b95c7 19:53:10 <FooBar> planetmaker: would a "make dev" target be easy to implement in the makefile? This target will skip all checks and just build the grf following the shortest path possible. I think that will decrease build times considerably for if you only want a test version. Raw error messages and miserable failures on error are perfectly acceptable to me. 19:53:46 <planetmaker> FooBar: try make firs.grf 19:53:56 * FooBar tries 19:54:46 <FooBar> still generates makefile.dep, which is exactly what takes the most time ;) 19:55:04 <FooBar> even twice... 19:55:18 <andythenorth> make firs.grf is almost the same time as make install for me 19:55:25 <andythenorth> 12s vs 13s 19:55:26 <planetmaker> hm, ok 19:55:34 <planetmaker> was just a guess :-) 19:55:50 <FooBar> no problem, I'm also just asking 19:56:05 <Rubidium> make firs.grf would do most of the stuff anyway 19:56:16 <Rubidium> grfcodec firs.grf is probably the fastest 19:56:29 <andythenorth> :) 19:56:37 <andythenorth> slightly might not run the cpp stuff 19:56:42 <FooBar> yes, but I also want the actual nfo compiled ;) 19:56:45 <FooBar> yes, that :P 19:56:52 <Rubidium> but if it's using "magic" to merge multiple files.. then you're royally screwed 19:56:55 <FooBar> oh, and renum is useful in some respects as wel 19:56:59 <FooBar> *well 19:57:14 * FooBar tries "make magic" 19:57:36 <planetmaker> hm... make [1] error: no rule to make magic 19:57:41 <planetmaker> or something like that :-) 19:57:51 <FooBar> :) 19:58:01 <planetmaker> make: *** No rule to make target `magic'. Stop. 19:58:07 <Ammler> http://www.scons.org/ 19:58:08 <Webster> Title: SCons: A software construction tool (at www.scons.org) 19:58:55 <planetmaker> Ammler: I'm not sure that it'd solve the problem. The problem is the lengthy dependency check 19:59:10 <planetmaker> Mostly as there are no default rules which I can (re-)use from anywhere 19:59:26 <planetmaker> and my custom-taylored solution is... not fast as it seems 19:59:52 <planetmaker> My previous solution might have been a bit faster. But it was not as reliable 20:00:57 <FooBar> for me a "just build the damn thing" would be most useful. I understand that for a compile farm a check to see if there's anything changed is most useful. 20:01:24 <Ammler> where also time doesn't matter that much 20:01:25 <planetmaker> FooBar: nope. I did that for me. And for you and all the authors. Not for the compile farm 20:01:41 <planetmaker> Because this way you know when you have things missing 20:01:42 <FooBar> clean: 0m10; make: 1m25; make firs.grf: 1m14 20:01:53 <Alberth> how about a python scripy to compute deps? 20:01:58 <Alberth> *script 20:02:02 <planetmaker> Alberth: yes. maybe. 20:02:20 <planetmaker> But still... should it be faster? Why would it be faster than grep? 20:02:35 <planetmaker> s/should/will/ 20:02:43 <Alberth> and your thousands of processes? 20:02:48 <planetmaker> :-) 20:03:44 <Rubidium> that'd mean teaching people how to install python in mingw 20:03:47 <FooBar> I appreciate the effort on the makefile though, but given that my compile environment is not ideal, it eats quite a lot of my time 20:04:01 <planetmaker> FooBar: yes, I understand that :-) 20:04:01 <Ammler> Rubidium: why would you need mingw then? 20:04:04 <FooBar> Rubidium: there's python in Mercurial 20:04:37 <Ammler> it would make the think independent from gcc/cpp 20:04:38 <planetmaker> they most likely have python as they have hg. 20:04:43 <Ammler> thing* 20:04:59 <planetmaker> Ammler: it wouldn't 20:05:05 <planetmaker> I still need the pre-processor 20:05:12 <planetmaker> dep check != preprocessor 20:05:14 <Ammler> why? 20:05:34 <Ammler> what can cpp, what python doesn't? 20:05:35 <planetmaker> or how would you deal with the #include "blubber.blah"? 20:05:51 <planetmaker> all the main project files for all projects? 20:05:59 <planetmaker> They are meant to be pre-processed by gcc. 20:06:06 <planetmaker> Also all template code is cpp pre-processor code 20:06:12 <planetmaker> No way to get rid of that. 20:06:37 <planetmaker> It's like wanting OpenTTD to get rid of all C code ;-) 20:06:37 <Ammler> I didn't check scons deeper, but maybe it should be able to 20:07:05 <planetmaker> Ammler: scons also only is able to call things. And if it then calls cpp nothing is won 20:07:24 <planetmaker> scons is means to replace make. Not gcc 20:07:30 <Ammler> I assume, it replaces cpp 20:07:34 <planetmaker> nope 20:07:40 <planetmaker> make 20:07:43 <Ammler> yes, too 20:07:49 <Alberth> it is just another 'make' 20:08:01 <Alberth> but 'better' 20:08:11 <Ammler> if not, there might be a python pre processor? 20:08:13 <planetmaker> besides, Ammler gcc is not a problem. That's not the slow part 20:08:26 <Ammler> planetmaker: the dependency is 20:08:26 <andythenorth> it's pure and simple the dep check 20:08:27 <planetmaker> Ammler: sure there might be. But this is gCC 20:08:43 <planetmaker> and the dep check has nothing to do with any pre-processing 20:08:52 <andythenorth> we know it's the dep check because last time planetmaker rewrote it, we got approx 3x speed boost 20:08:53 <planetmaker> it#s completely independent stuff 20:09:26 <planetmaker> oh, did I indeed manage that? I already forgot ;-) 20:09:40 <Alberth> you suppresed it from your mind :) 20:10:01 <planetmaker> hm. But why would I suppress good moments? 20:10:08 <planetmaker> I'm usually not a machist... 20:10:13 <planetmaker> :-) 20:10:30 <planetmaker> *masochist 20:11:12 <Brot6> NewGRF Meta Language - Revision 547:eb474a9c750c: Codechange: Unify reporting of warning messages... (Alberth) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/eb474a9c750c 20:11:55 <andythenorth> planetmaker: you rewrote it because I complained a lot about 45s - 60s build times for FIRS :) 20:12:10 <Alberth> what should it recognize and produce? 20:13:02 <Alberth> andythenorth: why? so much quality time to enjoy a cup of coffee :p 20:13:06 <planetmaker> andythenorth: yes, I recall that. But not the order of the speed-up ;-) 20:13:18 <planetmaker> Alberth: it needs to write a Makefile.dep 20:13:33 <planetmaker> which contains the dependencies of the source files. So that it knows when to re-build stuff 20:13:47 <Alberth> that answer the second part :) 20:13:48 <planetmaker> As such it needs to scan each source file for dependencies 20:14:04 <andythenorth> Alberth: some days I might build FIRS 200 times...that much coffee will produce...very strange code :P 20:14:05 <planetmaker> *.pnfo *.tnfo *.nfo 20:14:10 * Alberth nods 20:14:24 <planetmaker> looking for includes of the same type. And for nfo-style includes of pcx files 20:14:44 <planetmaker> taking into account that that may be in a templated way 20:15:00 <Alberth> a few examples would be nice 20:15:02 <FooBar> The dep check takes 52 seconds on my (virtual) system 20:15:12 <planetmaker> sure. Let me look 20:15:24 <planetmaker> you want examples for the source which is searched and the result? 20:15:38 <Alberth> only constrructs that need to be recognized 20:15:51 <Alberth> results come later :) 20:16:18 <Alberth> but I know makefile syntax, so that should be easy 20:17:10 <Ammler> does it need that dep check at all, wouldn't simply error on building suiffice? 20:17:45 <planetmaker> http://dev.openttdcoop.org/projects/firs/repository/entry/sprites/nfo/i_furniturefactory.pnfo <-- usual #includes 20:17:57 <Ammler> did you ever benchmark, what's faster, rebuild all or the dep check? 20:17:58 <planetmaker> #include "i_furniturefactory_tiles_layouts/furniturefactory_layouts.pnfo" 20:18:42 <Ammler> because the other slow part is grfcodec, which needs to be done anyway evertime 20:18:52 <planetmaker> -1 sprites/pcx/industries/sheepfarm.pcx 10 10 09 52 64 -31 -21 <-- pcx file 20:20:34 <Alberth> and templated things? 20:20:42 <planetmaker> #include TEMPLATE_MU <-- non-standard include 20:21:01 <planetmaker> #define THIS_PCX_FILE sprites/pcx/mus/br168.pcx // Graphics file <-- pcx file in define 20:21:01 <FooBar> Ammler: without dep check you get things like below on missing file: 20:21:03 <FooBar> <stdin>:24:36: error: sprites/nfo/cargos.pnfo: No such file or directory 20:21:05 <FooBar> <stdin>:25:43: error: sprites/nfo/cargo_schemes.pnfo: No such file or directory 20:21:07 <FooBar> In file included from sprites/nfo/i_coalmine.pnfo:27, 20:21:08 <FooBar> from <stdin>:34: 20:21:09 <planetmaker> it's not commented out, so it's likely to be used 20:21:10 <FooBar> sprites/nfo/../../templates/template_primary_action23.pnfo:131:31: error: industry_color.pnfo: No such file or directory 20:21:18 <Ammler> FooBar: does that hurt? 20:21:27 <Ammler> I mean, is that worse then the dep error? 20:21:49 <planetmaker> FooBar: that's not the dep check. But it's part of the makefile which knows in the FIRS case how to create those two files 20:21:50 <FooBar> to me: no, although you have to scroll back up to see it 20:21:57 <planetmaker> Those two files are actually specially treated 20:22:20 <FooBar> what was the dep check for again? 20:22:25 <Alberth> planetmaker: #define must be scanned to find a match? 20:22:50 <planetmaker> Alberth: I guess on that line my current implementation will also fail 20:22:51 <Alberth> FooBar: know which files depend on which files, so you only rebuild those files that must be 20:23:07 <FooBar> ah ok 20:23:24 <planetmaker> Alberth: actually a grf always depends on all files which are part of the grf. There are no object files which are independent 20:23:47 <planetmaker> but yes. if the readme changes, no point to re-build the grf. Same with a psg file which is just the graphics source 20:23:57 <Alberth> so what stuff do you skip then? 20:24:06 <planetmaker> skip where? 20:24:39 <Alberth> actually a grf always depends on all files which are part of the grf <-- this says, we need all sources each time to me 20:24:53 <Ammler> Alberth: the problem is much less then in openttd, here you have to rebuild everytime everthing 20:24:57 <Alberth> ie are you actually skipping steps at all? 20:25:12 <Ammler> in openttd, sometimes, it happens, the dep check is worth 20:25:19 <Alberth> often, even 20:25:20 <planetmaker> not really. As the repo may contain files which don't contribute to the grf itself 20:25:41 <Ammler> planetmaker: the txt files, which are made in nothing time 20:27:10 <planetmaker> well. I could always re-build the grf, if *something* changed in the repo. Easy 20:27:17 <planetmaker> then the dep check would be gone 20:27:26 <Alberth> it sounds like grf: *.pnfo *.tnfo *.nfo is sufficient 20:27:32 <Ammler> you do as the rev is in the grf title :-) 20:27:39 <planetmaker> Alberth: *.pcx 20:27:50 <Alberth> ok, those too :) 20:27:56 <planetmaker> or *.<graphics extension> for NML 20:28:27 <Alberth> whatever 20:28:41 <Ammler> a better script would be a check, if new files in commits are added :-) 20:28:42 <Alberth> any need to have a python dep experiment? 20:29:01 <Alberth> 'hg up' :) 20:29:05 <planetmaker> well. Foobar is in need :-) 20:29:07 <planetmaker> hm? 20:29:51 <FooBar> I'd be happy to test, but I don't think it's quicker than no dep check at all 20:30:33 <FooBar> Let me put it like this: if it's quicker I'd use it, if not it's a waste of effort 20:30:51 <planetmaker> hard to know in advance :-) 20:31:10 <Alberth> make 'dep calc' empty 20:31:46 <Alberth> and replace deps by *.xyz for various values of xyz in the generated makefile 20:32:37 <FooBar> I currently have: depend: $(MAKEFILE_DEP) 20:32:38 <FooBar> $(MAKEFILE_DEP): 20:32:40 <FooBar> touch Makefile.dep 20:32:52 <FooBar> that seems to work 20:33:05 <planetmaker> Alberth: what would make sense is to replace the current dep check by 20:33:44 *** KenjiE20 has quit IRC 20:33:47 <FooBar> minor issue with that is that I have to use make remake every time, because it thinks it's up to date 20:33:48 <planetmaker> $(MAIN_TARGET): `hg st -A | grep -E '*nfo'` 20:33:49 <planetmaker> or alike 20:34:08 <Alberth> yeah, something very simple 20:34:08 <planetmaker> and an additional with grep -E '*.pcx'` 20:34:21 <planetmaker> it'd avoid any file scanning 20:34:30 <planetmaker> let's see and give foobar a test :-) 20:35:10 <FooBar> what you want me to do exactly? 20:35:18 <Alberth> find . -name "*.nfo" -print 20:36:35 <FooBar> ./sprites/firs.nfo 20:36:41 <FooBar> obviously 20:37:08 <FooBar> we use mainly pnfo files 20:37:13 <planetmaker> :-) 20:37:50 <FooBar> but with *.pnfo it gives a large list in no time 20:38:07 *** KenjiE20 has joined #openttdcoop.devzone 20:38:16 <planetmaker> FooBar: you want "*nfo" 20:38:53 <FooBar> whatever you say :P I have no clue what I'm doing atm anyways ;) 20:43:52 <planetmaker> http://pastebin.ca/1897453 <-- can you try that diff and see what it helps? 20:44:42 <planetmaker> hm... though Alberth's find is probably better 20:44:51 <planetmaker> not sure 20:45:51 <planetmaker> ^ FooBar 20:46:21 <FooBar> I think I broke patch... 20:48:20 <FooBar> no, I wrote the wrong commandline options... 20:50:04 <FooBar> that's what you get when you never use such thing 20:50:46 <FooBar> time make: 0m51 20:51:07 <FooBar> so it's a bit quicker. I notices a few errors though, but that might be due to unclean repo 20:53:13 <Rubidium> planetmaker/FooBar: the sound issue isn't in OpenTTD; I can easily reproduce it with DirectMusic Producer 20:54:01 <planetmaker> FooBar: so it's a 1/3 gain? 20:54:19 <planetmaker> yes, there are firs errors. That's even commited 20:54:26 <FooBar> approximately, it came from 1m25 20:54:49 <planetmaker> hm.. and it now fails to make the cargo.pnfo and so 20:55:17 <planetmaker> Rubidium: that's good to know and bad news. 20:55:36 <planetmaker> But I guess... it's not a show stopper then for OpenMSX anymore 20:55:50 <Alberth> planetmaker: you give it all files, or should it find them on its own? 20:56:15 <planetmaker> Alberth: what I gave foobar now gives it all repo files 20:56:31 <planetmaker> hg st -A is all. Then I sort for the interesting extensions 20:56:31 <Rubidium> planetmaker: the problem is that... we can't fix it in OpenTTD without making it hang for seconds (as FooBar said) 20:56:32 * Alberth was talking about the python makedep :) 20:56:44 <Rubidium> although now the win32 driver should skip the first bit anymor 20:56:45 <Rubidium> +e 20:57:16 <planetmaker> +not? :-) 20:57:24 <FooBar> I think the pause is acceptable, so maybe make win32 default? 20:57:41 <planetmaker> Alberth: i can give it all files, no problem 20:57:45 <FooBar> It at least is better than a pause+hang 20:57:51 <planetmaker> like hg st -A 20:58:07 <planetmaker> probably it makes sense. I need that elsewhere and I'll have it cached already. 21:00:19 <Rubidium> yeah, +not 21:01:10 <Alberth> planetmaker: http://pastebin.org/387797 python thefile.py *.pnfo 21:01:47 <Alberth> although the pcx pattern may be too limiting 21:04:33 <planetmaker> uh... if I only understood those python strings there :-) 21:05:16 <FooBar> it's just regex... 21:06:07 <FooBar> \s is horizontal whitespace, \d is decimal number 21:06:12 <Rubidium> okay... with some modifications to tttheme2 I got directmusic producer to not screw it up... however I can't export it as midi :( 21:06:29 <planetmaker> Rubidium: I removed ttthem2 21:06:39 <planetmaker> *TT song II 21:06:58 <planetmaker> though... it's know as one other song... dunno which right now 21:07:12 <planetmaker> nvm me :-) 21:10:13 <Alberth> planetmaker: \d+ is a unsigned number -? is an optional '-', \s* is optional white space, \s+ is 1 or more white space. It is a bit long due to many numbers \S+ means 'anything except whitespace' 21:10:45 <planetmaker> ah :-) Thanks 21:11:04 <Alberth> if it is too limiting, it will fail to find some lines 21:11:43 <Alberth> most likely cause would be a negative value at a place where it is not expected by the re 21:14:30 <Alberth> but just try it, and compare with current output :) 21:14:32 <planetmaker> FooBar: maybe you try with Alberth's solution, too: http://pastebin.org/387818 21:15:00 <planetmaker> oh... 21:15:22 <FooBar> oh? 21:15:50 <planetmaker> wait a moment with that diff :-) 21:15:55 <planetmaker> it's somewhat broken 21:16:12 <Alberth> *nfo$ ??? nfo$ should be enough 21:16:28 <Alberth> or at least .*nof$ :) 21:17:06 <FooBar> you mean "patch: **** Only garbage was found in the patch input." 21:17:52 <FooBar> might be caused by windows line endings... 21:20:10 <Alberth> everybody have lots of fun, /me is going to bed 21:20:47 <planetmaker> good night, Alberth 21:20:50 *** Alberth has left #openttdcoop.devzone 21:20:55 <planetmaker> ha! :-) 21:21:11 <FooBar> right 21:21:38 <FooBar> I have to watch tv anyways... 21:21:48 <FooBar> let me know of any new diff, if any ;) 21:32:13 <planetmaker> hm... I'm too tired I guess. I have to continue tomorrow 21:32:20 <planetmaker> Have a good night :-) 21:34:35 <Rubidium> FooBar: does the music work "right" (with delay) with http://rbijker.net/openttd/openttd.zip ? 22:22:56 <FooBar> Rubidium: there is a small delay, but no game freeze :) 22:23:30 <Rubidium> good... so it's acceptable and such 22:23:45 <FooBar> yes, quite acceptable indeed 22:24:53 <FooBar> delay might be even less than before, at least, I get that feeling 22:25:47 *** ODM has quit IRC 22:26:00 <Rubidium> as far as I'm aware that didn't change 22:26:36 <FooBar> well, it could be just me. There is still a delay though, that's for sure 22:27:04 <Rubidium> the theme song has a delay of like a second in the song itself already 22:29:22 <FooBar> I noticed that before, I was referring to delay between theme and next song. But then again, a reduction might just be my imagination. 22:30:15 <Rubidium> it might be that the waiting for the song to be loaded before playing it makes it play it sooner, but... speculation 22:30:34 <Rubidium> and I can't be bothered to statistically prove that 22:30:37 <FooBar> I'm not really interesting in timing it 22:30:39 <FooBar> :) 22:30:51 <FooBar> anyways, good job on fixing this 22:31:21 <Rubidium> well... it's not fixed 22:31:33 <Rubidium> it's just hacked around 22:31:35 <FooBar> well, the weird pitch change is fixed 22:31:49 <Rubidium> no... start with -mdmusic and it'll be back 22:32:25 <FooBar> oh, -mwin32 is mended somewhat and now default? 22:32:32 <Rubidium> yep 22:32:58 <FooBar> ah, well, this works for me :) 22:33:23 <FooBar> after a while, people will not remember that it was any different before 22:33:49 <FooBar> most people that is, I guess 22:33:52 <Rubidium> and if they complain they will get flamed for not reading known-bugs.txt 22:34:02 <FooBar> :) 22:34:32 *** frosch123 has quit IRC 22:34:34 <FooBar> anyways, I'm off to bad. Glad I could help with this 22:34:41 <FooBar> bad=bed :) 22:34:49 <FooBar> good night! 22:35:49 <Rubidium> nightynight 22:42:51 *** FooBar has quit IRC 23:56:10 *** Ammler has quit IRC 23:56:12 *** Ammler has joined #openttdcoop.devzone