Log for #openttdcoop.devzone on 9th July 2010:
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) @
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> <-- 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) @
11:30:25  <Brot6> GRFCodec - Revision 168:c8b55786b336: Add: tags for 0.9.8, 0.9.9 and 0.9.10 (Rubidium) @
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) @
12:15:56  <Brot6> Example NewGRF Project - Code Review #1086: which is not installed on CentOS or RHEL (Ammler) @
12:18:09  <Brot6> Example NewGRF Project - Code Review #1086: which is not installed on CentOS or RHEL (Rubidium) @
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) @
12:58:26  *** planetmaker is now known as planeftmakefr
12:59:02  <Brot6> FIRS Industry Replacement Set - Feature #1089 (New): Forest in tropic (foobar) @
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) @
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) @
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) @
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) @
16:19:06  <Brot6> 2cctrainset: update from r572 to r573 done (1 errors) -
16:19:36  <Brot6> NFORenum - Revision 376:6f93cc9ed0d5: Change: [Makefile] Don't pack CF files into the source tar ... (planetmaker) @
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 -
16:21:24  <Brot6> grfcodec: update from r167 to r169 done -
16:22:10  <Brot6> heqs: update from r347 to r348 done -
16:23:01  <Brot6> nml: update from r530 to r544 done -
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 "" 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/ 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:  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) @
17:08:30  <Brot6> NewGRF Meta Language - Revision 546:08a270f20540: Feature: Per-sprite image files, including temp... (Hirundo) @
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>,254898
17:45:19  <Webster> Title: Paul the octopus has made his final selections - Dirty Tackle - World Soccer Blog - Yahoo! Sports (at
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) @
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) @
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
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) @
19:19:41  <Brot6> OpenMSX - Revision 82:3141a0ff4502: Change: Rename 'TT title theme' in 'OpenTTD journey' (planetmaker) @
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) @
19:48:03  <Brot6> FIRS Industry Replacement Set - Revision 1040:c899434b95c7: Change: test code for secondary indus... (andythenorth) @
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>
19:58:08  <Webster> Title: SCons: A software construction tool (at
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) @
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> <-- 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> <-- 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:        python *.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:
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 ?
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

Powered by YARRSTE version: svn-trunk