Times are UTC Toggle Colours
00:15:40 <planetmaker> g'night 00:16:25 <Brot6> Total Town Replacement Set - Revision 5:85a8b68c5010: Fix: Missing string terminations (planetmaker) @ http://dev.openttdcoop.org/projects/ttrs/repository/revisions/85a8b68c5010 00:16:25 <Brot6> Total Town Replacement Set - Revision 6:41e666c809c4: Change: Indentation level adjusted for para... (planetmaker) @ http://dev.openttdcoop.org/projects/ttrs/repository/revisions/41e666c809c4 00:28:09 *** KenjiE20 has quit IRC 05:16:00 *** OwenS has quit IRC 05:17:32 *** OwenSX-28AC has joined #openttdcoop.devzone 05:17:41 *** OwenSX-28AC is now known as OwenS 05:29:14 *** OwenS has quit IRC 05:29:14 *** planetmaker has quit IRC 05:29:37 *** OwenS has joined #openttdcoop.devzone 05:29:37 *** planetmaker has joined #openttdcoop.devzone 06:11:03 <planetmaker> @base 16 10 18 06:11:03 <Webster> planetmaker: 24 06:49:34 <Brot6> Total Town Replacement Set - Revision 7:45e2bfec10fe: Feature: Add parameter which allows to disa... (planetmaker) @ http://dev.openttdcoop.org/projects/ttrs/repository/revisions/45e2bfec10fe 06:51:06 <Brot6> FIRS Industry Replacement Set - Feature #1295 (New): allow TTRS, if parameter 04 is set (planetmaker) @ http://dev.openttdcoop.org/issues/1295 07:39:43 <Brot6> Total Town Replacement Set - Feature Request #1287: FIRS compatible (planetmaker) @ http://dev.openttdcoop.org/issues/1287#change-3395 08:03:17 *** Webster has joined #openttdcoop.devzone 08:03:18 *** Guest615 has quit IRC 08:12:35 <Brot6> Total Town Replacement Set - Revision 8:6010d3ac3191: Fix: Header file was missing (planetmaker) @ http://dev.openttdcoop.org/projects/ttrs/repository/revisions/6010d3ac3191 08:23:56 *** ODM has joined #openttdcoop.devzone 08:59:29 <Brot6> FIRS Industry Replacement Set - Revision 1248:0ee89c3e3523: Fix: Wholesale market production/acce... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/0ee89c3e3523 09:01:05 <planetmaker> http://dev.openttdcoop.org/projects/firs/repository/revisions/0ee89c3e3523 09:01:15 <planetmaker> uhm... :-P 09:41:24 <Brot6> Total Town Replacement Set - Feature Request #1287 (Feedback): FIRS compatible (foobar) @ http://dev.openttdcoop.org/issues/1287#change-3397 09:47:14 <Brot6> FIRS Industry Replacement Set - Feature #1295 (Closed): allow TTRS, if parameter 04 is set (planetmaker) @ http://dev.openttdcoop.org/issues/1295 09:47:14 <Brot6> FIRS Industry Replacement Set - Revision 1249:3c546c1c20f7: Feature: only allow TTRS if TTRS para... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/3c546c1c20f7 09:47:14 <Brot6> FIRS Industry Replacement Set - Feature #1295 (Closed): allow TTRS, if parameter 04 is set (foobar) @ http://dev.openttdcoop.org/issues/1295#change-3398 10:07:18 <Brot6> Total Town Replacement Set - Feature Request #1287: FIRS compatible (planetmaker) @ http://dev.openttdcoop.org/issues/1287#change-3399 10:12:14 <Brot6> Total Town Replacement Set - Feature Request #1287: FIRS compatible (planetmaker) @ http://dev.openttdcoop.org/issues/1287#change-3399 10:35:22 <Ammler> planetmaker: are you aware that George is working on TTRS4? 10:35:30 <planetmaker> yes 10:35:36 <Ammler> did you talk to him? 10:35:49 <planetmaker> I contacted him but got so far no reply 10:36:05 <Ammler> maybe he would like join yuo :-) 10:36:07 <planetmaker> And as said: I only plan a bug-fix release, not a new NewGRF 10:36:54 <Ammler> but you need a new ID for FIRS 10:37:03 <planetmaker> no 10:37:09 <Ammler> or how else should firs detect if ttrs is compatible? 10:37:19 <planetmaker> Adding a parameter doesn't require a new ID IMHO 10:37:38 <planetmaker> see FS 4077 :-P 10:38:54 <Ammler> why do you need to keep the ID? 10:39:20 <planetmaker> why shouldn't I? It remains compatible 10:39:26 <Rubidium> safegaim? 10:39:38 <Ammler> well 10:39:59 <planetmaker> I can update a game with the (new) TTRS, if I don't change parameters 10:40:06 <planetmaker> That's the definition of compatible, right? 10:40:29 <planetmaker> It might be different, if I de-activate TTRS automatically when I find FIRS. But that's not (yet) done 10:40:41 *** KenjiE20 has joined #openttdcoop.devzone 10:40:55 <Ammler> but firs should notice, that someone should update TTRS 10:41:22 <Ammler> maybe you should branch TTRS :-P 10:41:34 <Rubidium> Ammler: have you actually seen the content of FS#4077? 10:41:43 <planetmaker> yes.http://bugs.openttd.org/task/4077 10:42:20 <planetmaker> I'm not sure though wether the implementation concept I propose is a good one or whether it should be a (new) variable 10:42:54 <Ammler> Rubidium: that is FS# not r ;-) 10:44:02 <planetmaker> Ammler, I got and added that idea only few hours ago... 10:44:11 <Rubidium> yes, and it's really new and... is TTRS *that* close to release that it can't wait lets say a day for someone to actually pick up on the idea? 10:44:21 <planetmaker> And I think that there might be a better idea than the way I propose there 10:45:14 <Ammler> sometimes you guys :-) 10:46:20 <Rubidium> I'm just wondering why you want to go for the drastic solution of changing the GRF ID (and it thus not showing as upgrade, and thus the *old* TTRSes still showing in-game) 10:46:31 <Rubidium> when there might be another better solution "around the corner" 10:46:37 <Ammler> you think, patching openttd is less drastic? 10:46:54 <Ammler> but I am absolutely fine 10:47:21 <Rubidium> if it is the logical evolution of action14 and action7/9, then no... it's not drastic 10:48:29 <planetmaker> :-) 10:48:31 <Rubidium> I actually think that not doing GRFID bumps to show to other NewGRFs that you've become compatible with them is better in the long run 10:49:06 <Ammler> Rubidium: maybe openttd should then support something like provides and obsoletes 10:49:15 <planetmaker> Do I understand correctly: GRFID shall not change in the long run, even if it becomes incompatible? 10:50:52 <Rubidium> Ammler: that is also a good idea, although I'm not that sure about provides 10:51:17 <Ammler> that would at least make it "compatible" to ttdp again, since there the GRFID doesn't matter 10:51:29 <Ammler> (in that case) 10:51:37 <Rubidium> but a NewGRF could definitely tell from which NewGRF version the savegame format is compatible 10:52:51 <Rubidium> and with that information you can determine the newest local NewGRF that is compatible with your savegame 10:55:23 <planetmaker> hm, how? You mean the newgrf version (action14) should not change for compatible newgrfs? 10:55:39 <planetmaker> then firs, snowlinemod, ttrs are doing it wrong [TM] 10:56:32 <Rubidium> planetmaker: http://noai.openttd.org/docs/1.0.3/classAIInfo.html#f2b7eed2c310d1ea95b0282bad7a7875 10:58:32 <planetmaker> That number is saved in the savegame? 10:58:42 <planetmaker> with the AIID / GRFID? 10:59:13 <planetmaker> so... what happens: I now have a game with minimum version=7. 10:59:14 <Rubidium> for AIs it is, for NewGRFs it isn't (yet?) 10:59:45 <planetmaker> Now later I make a version, say 25, which will not load that anymore. How does OpenTTD know that the version25 I have, doesn't match? 10:59:59 <planetmaker> when I load that (old) savegame 11:00:07 <planetmaker> yes, I know newgrf don't (yet) support that 11:00:24 <Rubidium> because your version25 will have an action14 saying: "min NewGRF version to load: 24" 11:00:45 <Rubidium> (assuming 24 is the version where the savegame format got destroyed 11:00:53 <planetmaker> ok 11:01:15 <planetmaker> and OpenTTD will then look for AI v7 ... v23 in bananas? 11:01:50 <Rubidium> nope, it'll look for the exact NewGRF in the savegame and otherwise it'll bail out not loading anything 11:02:05 <planetmaker> ok 11:02:25 <planetmaker> fine enough, I think 11:02:35 <Rubidium> and when there's no minversion/newgrf version it'll just do the old stuff 11:03:01 <planetmaker> yup, of course. If I have the proper one, I use it 11:04:10 <Rubidium> uhm, old stuff being the old methods, i.e. a random one or (if the NewGRF has version, but not minversion) the newest 11:04:22 <Rubidium> if the "correct" one is missing 11:04:43 <Rubidium> and even then, a NewGRF will only be "upgraded" when you don't have the one the savegame was saved with 11:14:09 <planetmaker> yes, sure 11:31:14 <planetmaker> ceterum censeo bananam esse edendam ;-) 11:33:38 <Rubidium> my point was that the Romans didn't have a u 11:34:37 <planetmaker> or a v ;-) 11:35:22 <planetmaker> but "v" is definitely easier to carve into stone than "u" 11:35:38 <planetmaker> but it remains questionable how they pronounced it. 11:36:21 <Rubidium> true, very true 11:36:33 *** Seberoth has joined #openttdcoop.devzone 12:32:34 <Yexo> planetmaker: about FS#4077, why not use "parameter 80" as version? 12:32:45 <Yexo> currently no newgrf can access param 80 for other newgrfs because it doesn't exist 12:34:20 <Yexo> or if the parameter is not defined, a value of 0 is used instead <- from http://wiki.ttdpatch.net/tiki-index.php?page=ReadingOtherGRFParameters 12:34:50 <Yexo> so it's even somewhat backwards compatible, as in returning 0 for newgrfs that don't have a version set and also for ttdpatch/openttd versions that don't support it 13:45:16 <Ammler> ld -lpng doesn't find the lib, that might be because there is not libpng.so, but a libpng12.so 13:45:28 <Ammler> how do I tell make to search for libpng12.so 13:49:52 <Yexo> planetmaker: swedishrails works again with latest nml 13:50:32 <Brot6> NewGRF Meta Language - Bug #1274 (Closed): regression: builds of Swedish Rails have no ingame eff... (yexo) @ http://dev.openttdcoop.org/issues/1274#change-3400 13:50:32 <Brot6> NewGRF Meta Language - Revision 673:8f489336c52f: Fix (r564) [closes #1274]: all else blocks were... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/8f489336c52f 13:51:06 <Ammler> Yexo: is there a way to test that now without the need to run it in openttd? 13:51:38 <Yexo> probably not 13:52:03 <Yexo> you coulud try building the release version and comparing the md5 of the resulting grf 13:52:15 <Ammler> well, that we already do 13:52:23 <Yexo> but there are valid reasons why it could be different 13:55:13 <Ammler> what about loading it in openttd -D -dgrf=9 and grep the output? 13:57:39 <Yexo> you can't automate the testing 13:57:54 <Yexo> one line of nml can be encoded in nfo in several ways that might be equally valid 13:58:09 <Yexo> but different output will lead to a differnt md5 and different debug output from openttd 14:04:56 <Ammler> different md5sum is no sign for failing, so that shouldn't trigger a fail 14:26:51 *** FooBar has joined #openttdcoop.devzone 14:36:04 <Brot6> 2cc train set - Revision 587:eceb4d3b0bad: Fix: #1289 and #1290 (DJNekkid) @ http://dev.openttdcoop.org/projects/2cctrainset/repository/revisions/eceb4d3b0bad 14:36:04 <Brot6> 2cc train set - Revision 588:be9933e73f0c: Fix: Merge (DJNekkid) @ http://dev.openttdcoop.org/projects/2cctrainset/repository/revisions/be9933e73f0c 14:36:04 <Brot6> 2cc train set - Support #1289 (Closed): Corrected ChME3 sprites (DJNekkid) @ http://dev.openttdcoop.org/issues/1289#change-3401 15:05:22 <planetmaker> <Yexo> [14:32:33] planetmaker: about FS#4077, why not use "parameter 80" as version? <-- no reason 15:05:26 <planetmaker> Is it not taken? 15:05:40 <planetmaker> If so, then I indeed propose parameter 80 rather than 7F. 15:05:42 <Yexo> as far as I can see currently only 0..7F are valid values 15:05:53 <Yexo> re-using 7F could in theory break older grfs 15:05:56 <planetmaker> And I'm very happy to see SErails compile again :-) 15:06:19 <planetmaker> I just wonder whether 80 is in use... that is the start of the global parameters 15:06:36 <Yexo> in openttd it is not 15:06:40 <planetmaker> or is that only 81 as first? 15:06:41 <Yexo> no idea how ttdpatch implements the spec 15:06:52 <planetmaker> well. That doesn't matter, they don't support it ;-) 15:06:59 <planetmaker> and hardly ever will 15:13:11 <Yexo> it does matter, because it'd be easiest of ttdpatch just always returned 0 when checking the version of another grf 15:16:56 <planetmaker> hm, yes 15:17:16 <planetmaker> hm... I don't find 0x80 used. But that's of course not a proof :-) 15:21:54 *** frosch123 has joined #openttdcoop.devzone 15:42:42 *** ODM has quit IRC 16:19:48 <Brot6> FIRS Industry Replacement Set - Revision 1250:5391773f09d3: Fix (r1249): Don't require TTRS to us... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/5391773f09d3 16:20:25 <Brot6> 2cctrainset: update from r586 to r588 done (47 errors) - http://bundles.openttdcoop.org/2cctrainset/nightlies/r588 16:21:30 <Brot6> firs: update from r1246 to r1250 done - http://bundles.openttdcoop.org/firs/nightlies/r1250 16:22:31 <Brot6> nml: update from r672 to r673 done - http://bundles.openttdcoop.org/nml/nightlies/r673 16:23:11 <Brot6> snowlinemod: update from r33 to r36 done - http://bundles.openttdcoop.org/snowlinemod/nightlies/r36 16:23:15 <Brot6> Following repos didn't need a nightlies update: 32bpp-extra (r38), airportsplus (r53), basecosts (r20), comic-houses (r71), fish (r387), grfcodec (r234), heqs (r372), metrotrackset (r56), newgrf_makefile (r162), nforenum (r474), nutracks (r98), ogfxplus (r41), opengfx (r502), openmsx (r97), opensfx (r97), swedishrails (r143), transrapidtrackset (r15), ttdviewer (r25), worldairlinersset (r663) 16:25:16 <planetmaker> hm, I'm sure swedishrails needs an update ;-) 16:25:33 <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: ogfxplus, swedishrails (28 errors) (Diffsize: 3499) 16:26:05 <planetmaker> 28 errors?! 16:27:06 <planetmaker> hm pure white? Where the heck do they come from? :S 16:29:23 <planetmaker> hm, that's 'only' wrong y-offsets it seems 16:31:56 <Rubidium> another happy customer of my only contribution to NML :) 16:32:06 <planetmaker> yep :-) 16:32:42 <planetmaker> but it's indeed a very useful toold 16:32:49 <frosch123> with one contribution you are infinitely times ahead of me 16:33:54 <Ammler> useful to add grf2html output as docs to the bundle? 16:34:19 <Rubidium> for "normal" users? 16:34:34 <Ammler> not as bundle 16:34:48 <frosch123> you mean like the doxygen stuff for ottd? 16:35:00 <Ammler> bundles.openttdcoop.org/<grf>/docs/ 16:35:06 <Ammler> frosch123: yes 16:35:17 <planetmaker> possibly yes 16:35:53 <Ammler> firs has "grf2html" error 16:36:05 <Ammler> but nforenum doesn't? 16:37:28 <frosch123> Sprite too long: 90 bytes left. <- 90 bytes :o 16:37:37 <Ammler> yes :-) 16:37:47 <Ammler> # 5 16:37:48 <Ammler> Errors: 16:37:50 <Ammler> Sprite too long: 1 bytes left. 16:37:53 <Rubidium> real or pseudo? 16:38:00 <frosch123> pseudo 16:38:06 <Ammler> A14 16:38:20 <Rubidium> maybe it's nforenum ignoring stuff it doesn't know? 16:38:31 <frosch123> first error is correct 16:38:38 <frosch123> the action14 has a 00 too much 16:39:15 <Ammler> also grf2html can read ttrs.grf correctly 16:39:23 <Ammler> why isn't grfcodec -d able to? 16:39:44 <Ammler> (write a "proper" nfo) 16:39:46 <frosch123> what does grfcodec complain about? 16:40:25 <Ammler> well, the issue you discussed yesterday about encoding 16:40:30 <Ammler> codepage 16:41:05 <frosch123> you mean grfcodec does not convert latin1 into utf-8 and adds utf8 control codes? 16:41:05 <Ammler> hmm, how do I tell a 64 bit system to use a 32bit rpm 16:41:07 <Rubidium> Ammler: primarily because GRFCodec isn't aware of the whole NFO specs. It just writes the bytes down and if it looks like a text it puts it between quotes 16:41:11 <frosch123> i would not consider that wrong :) 16:42:02 <frosch123> anyway, no idea what garbage andy added to sprite 3219 ::) 16:42:09 <Rubidium> and because it doesn't know the specs it doesn't know what is a string and what isn't and as such any codepage conversion could potentially make the NFO not a 1:1 copy of the GRF 16:42:42 <frosch123> s/could potentially/will/ 16:43:22 <frosch123> Ammler: do you see the <UTF-8> control codes in front of the utf-8 strings? 16:43:33 <frosch123> grfcodec/renum would have to add them, if they want to convert 16:44:29 <Ammler> but it is FF? 16:44:52 <Rubidium> language ID? 16:45:07 <Rubidium> "any" | 80h 16:46:43 <Ammler> 8 * 82 0B 02 "$�A TTRS3 nem haszn�lhat� egy�tt " -> 8 * 82 0B 02 24 FF 41 20 54 54 52 53 33 20 6E 65 6D 20 68 61 73 7A 6E E1 6C 68 61 74 F3 20 65 67 79 FC 16:47:10 <Ammler> true, that might be langid 16:47:17 <frosch123> no, those are string codes 16:47:24 <frosch123> you have to run "renum -a" on it 16:47:55 <Rubidium> there FF is the message-id for: custom, string follows 16:48:05 <planetmaker> Ammler, that is langID 16:48:09 <planetmaker> it's Hungarian. 24 16:48:31 <planetmaker> unless I'm wrong and it is Portuguese. That was also mixed up wrongly. Then it's 36 16:48:33 <frosch123> oops, i mean "nforenum -a" of course 16:50:00 <Ammler> that does produce errors here 16:50:09 <Ammler> (or warnings) 16:50:21 <frosch123> most older grfs do 16:51:01 <planetmaker> "früher war alles besser!" ;-) 16:51:02 <Ammler> does encoding on that grf work? 16:51:09 <Ammler> nfo* 16:51:23 <planetmaker> ttrs? yes 16:51:44 <Ammler> so you basically keep the "errors" 16:51:46 <Ammler> ? 16:53:41 <planetmaker> I currently only have 6 errors 16:54:02 <Ammler> then you fixed those? 16:54:27 <Ammler> hmm 16:55:09 <planetmaker> I fixed some, yes 16:55:23 <planetmaker> e.g. many strings had two trailing 00 too much 16:55:25 <planetmaker> http://pastebin.com/C577NYbW 16:55:28 <planetmaker> ^ plust a zillion white pixels 16:55:29 <planetmaker> -t 16:55:42 <Ammler> frosch123: didn't we already suggest to make grf2nfo too with your tool? 16:56:09 <Brot6> FIRS Industry Replacement Set - Revision 1251:976a2309c3b0: Codechange: also skip NA City Set/Can... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/976a2309c3b0 16:56:32 <frosch123> no, what would be the benefit? 16:56:56 <frosch123> i also do store .png not .pcx 16:57:04 <Ammler> to have a kind of readable nfo 16:57:15 <Brot6> FIRS Industry Replacement Set - Revision 1252:648c5f652533: Codechange: remove leftover/broken ac... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/648c5f652533 16:57:35 <frosch123> do you mean the latin-1/utf-8 mixture, or other stuff? 16:57:47 <Ammler> yes, and maybe comments 16:58:38 <frosch123> the latin-1/utf-8 stuff should be possible to do in renum 16:59:10 <frosch123> what is the problem with comments? 16:59:35 <Ammler> none, the additional html test could be added as comment to the nfo 16:59:40 <Ammler> text* 17:00:21 <frosch123> andersi suggested to add nfo into the .html 17:00:45 <Brot6> FIRS Industry Replacement Set - Revision 1253:67e10e42fd3b: Codechange: remove leftover/broken ac... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/67e10e42fd3b 17:00:50 <frosch123> but mixing grf2html output with nfo does not work very well, as the information is not presented in the same order in several cases 17:39:58 <Brot6> FIRS Industry Replacement Set - Feature #1236 (Feedback): 1 tile buffer should be ignored when pl... (foobar) @ http://dev.openttdcoop.org/issues/1236#change-3402 17:43:21 <Brot6> FIRS Industry Replacement Set - Feature #1236: 1 tile buffer should be ignored when player / scen... (andythenorth) @ http://dev.openttdcoop.org/issues/1236#change-3403 18:06:54 *** ODM has joined #openttdcoop.devzone 18:15:35 <Brot6> FIRS Industry Replacement Set - Feature #1235: 1 tile buffer - Generic Tiles (foobar) @ http://dev.openttdcoop.org/issues/1235#change-3404 18:20:37 <Brot6> Total Town Replacement Set - Revision 9:07c53194bd0c: Change: convert to UTF-8 (planetmaker) @ http://dev.openttdcoop.org/projects/ttrs/repository/revisions/07c53194bd0c 18:33:00 <Brot6> FIRS Industry Replacement Set - Feature #1235: 1 tile buffer - Generic Tiles (foobar) @ http://dev.openttdcoop.org/issues/1235#change-3404 18:34:38 <Brot6> FIRS Industry Replacement Set - Revision 1254:522bf297992e: Feature: 1 tile buffer for generic ti... (foobar) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/522bf297992e 18:34:38 <Brot6> FIRS Industry Replacement Set - Feature #1235 (Closed): 1 tile buffer - Generic Tiles (foobar) @ http://dev.openttdcoop.org/issues/1235#change-3405 18:35:48 * andythenorth goes away for a bit and FooBar does loads of commits :) 18:35:54 <andythenorth> I should stay off irc more :p 18:36:14 <FooBar> I wasn't on IRC a lot the past few days either ;) 18:36:36 <FooBar> I added some comments to a few tickets, you might want to check those 18:36:58 <FooBar> do you have time to discuss a thing or two? 18:37:15 <andythenorth> yup 18:37:24 <andythenorth> I have a baby to entertain, so may go afk sometimes 18:37:47 <FooBar> no problem, I can play openttd ;) 18:37:52 <FooBar> let's start with http://dev.openttdcoop.org/issues/898 18:38:07 <FooBar> pm suggested to move sand to a different slot 18:38:32 <andythenorth> what do you think? 18:38:43 <FooBar> personally I think every industry set should either define the cargo they use or alternatively check if the cargo is actually available 18:39:06 <andythenorth> I think this is a bug with TTRS 18:39:06 <FooBar> TTRS in this respect is an industry set 18:39:11 <andythenorth> isn't planetmaker fixing it? 18:39:52 <FooBar> he made an option to disable the bank, but I don't know if there will be an option to keep the bank with FIRS (as add-on) 18:39:57 <planetmaker> well. I am. Still. You have free cargo slots. So it might be a good idea to move sand despite 18:40:08 *** Seberoth has quit IRC 18:40:19 <planetmaker> *I am fixing it 18:40:43 <FooBar> can't TTRS just check if valuables is available and if not define it as cargo (as well as using a CTT) 18:40:52 <planetmaker> People will still use old TTRS. And then even old TTRS can be considered a valid add-on 18:41:32 <Ammler> frosch123: how do I tell grf2html to use libpng12.so instead libpng.so? 18:41:43 <andythenorth> TTRS is doing it wrong 18:41:47 <FooBar> I see your point, but the next day some other set comes around requiring to move some other cargo to some other slot 18:41:48 <planetmaker> And I honestly don't feel like spending an aweful lot of time on codint TTRS :-) 18:42:07 <planetmaker> FooBar, no such thing will happen. New sets is something different 18:42:09 <frosch123> Ammler: head should pick it itself 18:42:11 <planetmaker> TTRS has the older rights 18:42:19 <planetmaker> Your set is a baby in relation to it 18:42:29 <frosch123> what libs do you have in /usr/lib ? 18:42:35 <Ammler> frosch123: I got a ld -lpng not found or something 18:42:45 <Ammler> libpng12.so 18:42:45 <FooBar> not necessarily new sets, but maybe also older sets that haven't been tested with FIRS yet 18:42:48 <planetmaker> I definitely wouldn't argue for a new set that way 18:43:00 <planetmaker> as of which? 18:43:02 <Ammler> it is suse 11.3, which has libpng14 as default 18:43:12 * andythenorth thinks 18:43:14 <Ammler> so libpng.so is linked to libpng14.so 18:43:19 *** Seberoth has joined #openttdcoop.devzone 18:43:23 <andythenorth> so industry sets *do* use a CTT yes? 18:43:29 <Ammler> (but I haven't installed it anyway) 18:43:30 <frosch123> on gentoo i had to add the libpng12.so as symlink to libpng12.so.0 18:43:31 <planetmaker> I have no clue 18:43:34 <frosch123> but then it worked 18:43:43 * FooBar thinks a bit more 18:43:51 <Ammler> mäh, so I need to make a rpm, which simply makes that symlink :-P 18:44:06 <planetmaker> I think it's just the cargo slot. I think TTRS doesn't define any cargo. It keeps existing cargo definition 18:44:21 <planetmaker> So a solution might be: define valuables, if TTRS is around :-P 18:44:31 <andythenorth> but it would have to be in the right slot? 18:44:41 <planetmaker> But I honestly have little clue. So far 18:44:47 <andythenorth> will break DB Set XL FIRS plugin 18:44:51 <andythenorth> :P 18:44:52 <andythenorth> meh 18:45:00 <planetmaker> that's broken anyway. And the author is unhelpful as ever 18:45:09 <FooBar> well, moving sand isn't that difficult. 18:45:31 <FooBar> just needs a big shovel 18:45:38 <planetmaker> for people who know what they do, I'd assume so ;-) 18:45:41 * andythenorth afk 18:46:09 * frosch123 is confused 18:46:19 <frosch123> Ammler: do you have libpng12 installed? or only 14? 18:46:43 <Ammler> i have only libpng12 installed 18:46:56 <frosch123> then it should work :s 18:47:03 <FooBar> IMO, the best would be to fix TTRS and stimulate people to upgrade to the newest version. FIRS already stimulates to upgrade to 3.03 or newer 18:47:39 <planetmaker> then please go ahead and implement that. 18:47:44 <planetmaker> You know how to do that. I don't 18:47:49 <frosch123> ammler, maybe try removing the "{$LINKLIB png12}" line from the top of osspecific.pas 18:47:58 <FooBar> no problem, I could do that 18:48:27 <frosch123> it should then take libpng.so, but fail if that links to 14 18:48:44 <FooBar> that would also make TTRS future-proof if some other set comes around and redefines valuables 18:48:44 <planetmaker> FooBar, look for "properties" in the BIG (p)nfo file 18:48:49 <planetmaker> that's where the banks are 18:48:56 <FooBar> ok, thanks :) 18:49:22 <planetmaker> that's true. That'd make it future-proof 18:49:55 <planetmaker> if you feel like, separate the code to a new file and include it there where needed. 18:50:06 <planetmaker> If not... well :-) 18:50:38 <FooBar> IMO if it's possible to fix something that is broken than that is always a better solution than working around it 18:50:49 <FooBar> And since we're now in the position to fix it... 18:50:49 <planetmaker> of course 18:50:56 <planetmaker> I do agree. 18:51:29 <planetmaker> But one thing I'm concerned about: will then TTRS remain savegame compatible with old savegames? 18:51:39 <planetmaker> That's something which IMHO needs absolutely be made sure 18:51:55 <planetmaker> I don't want to start issues with that nor a new GRFID 18:51:56 <FooBar> speaking about big... TTRS has more sprites than FIRS! :o 18:52:04 <planetmaker> yeah 18:52:09 <planetmaker> and more errors :-P 18:52:37 <FooBar> compatibility: if you disable the banks in a running game, that would break the compatibility 18:53:03 <planetmaker> yes. But also cargo-redefinition 18:53:29 <FooBar> I think that will be fine; I only redifine if it's not available 18:53:50 <FooBar> But some testing might not hurt 18:53:51 * planetmaker is happy 18:54:00 <planetmaker> I actually hoped that you'd supply that part :-) 18:54:10 * Rubidium thinks of chorus of Peaches (by Busted) but replacing peaches for errors :) 18:54:40 <Rubidium> hmm, not quite the chorus but the last bit of the song, but who cares? 18:56:33 <FooBar> hmmm... nfo is a bitch if it's uncommented... 18:56:37 <andythenorth> if fixing TTRS turns out to not be possible, we can move sand 18:56:41 <andythenorth> I don't really care 18:56:46 <planetmaker> FooBar, very much so. yes :-( 18:56:56 <planetmaker> andythenorth, both IMHO can be done 18:57:02 <andythenorth> but we shouldn't build wrong on top of wrong. It's worse than technical debt :P 18:57:07 <planetmaker> assigning sand in FIRS to another slot is nothing big 18:57:32 <planetmaker> you probably have broken savegame compatibility anyway already on the way since 0.3 :-P 18:57:56 <andythenorth> yup 18:58:03 <planetmaker> then it's a non-issue 18:58:26 <andythenorth> I wanted to keep the reserved slots free though, not waste them on cargos that should fit perfectly elsewhere 18:58:38 <andythenorth> FIRS just doesn't play nice with sets that define or expect cargos 18:58:41 <planetmaker> andythenorth, it's just that the reserved slots move ;-) 18:59:08 <andythenorth> no, what happens is we lose a reserved slot to TTRS, which means sometime in future the same issue comes up and we have to work around it again 18:59:19 <planetmaker> eh? 18:59:22 <andythenorth> TTRS just won't be compatible with some FIRS economies 18:59:30 <andythenorth> TTRS is grabbing a slot 18:59:41 <planetmaker> I don't see that happening. Except when you define ALL slots 18:59:41 <andythenorth> the slots are mine not TTRS :P 18:59:53 <andythenorth> well it just means we now only have 30 cargo slots 19:00:17 <planetmaker> Well. My point is: moving sand doesn't cost you a slot 19:00:30 <planetmaker> But it makes cooperation with (old) TTRS easy 19:00:52 <planetmaker> and the conflict will only occur when FIRS starts to really use everything 19:01:45 <andythenorth> so we just defer the problem to the future :P 19:01:56 <andythenorth> and we do work now to incur the same problem in the future 19:02:06 <planetmaker> hardly 19:02:23 * andythenorth is arguing principles, the actual work isn't much ;) 19:02:29 <planetmaker> except you changed your stance, that you keep two add-on slots 19:02:40 * planetmaker argues also principles ;-) 19:03:33 <Brot6> FIRS Industry Replacement Set - Feature #1296 (Assigned): Make sure TT-Foundry pages for FIRS are... (andythenorth) @ http://dev.openttdcoop.org/issues/1296 19:03:42 <planetmaker> my principle is: less potential for conflict in the common cases 19:04:07 <planetmaker> I'm aware that it won't solve every conflict, especially not future ones 19:04:16 <andythenorth> ....until we want an economy with >30 cargos 19:04:22 <andythenorth> which also supports NARS 2 19:04:22 <planetmaker> yes 19:04:30 <planetmaker> _until_ 19:04:43 <planetmaker> but that is a subset of economies. Thus less conflict potential :-) 19:04:59 <planetmaker> note: I also don't argue not fixint TTRS. Both :-) 19:05:02 <planetmaker> *fixing 19:05:17 <andythenorth> honestly we probably have the slots spare in reality 19:05:26 <andythenorth> FooBar: I might kill Survey Supplies 19:05:35 <planetmaker> :-) 19:05:38 <andythenorth> ironic really 19:05:44 <planetmaker> why? 19:06:05 <andythenorth> I only created the set to give some HEQS vehicles something to transport. The original plan was just to add a survey camp and use default industries :P 19:06:12 <andythenorth> "now look what happened" 19:06:27 <andythenorth> Survey Supplies is a vanity cargo 19:06:35 <planetmaker> :-) 19:06:36 <andythenorth> I don't think surveying will add much to gameplay 19:06:44 <planetmaker> depends 19:07:01 <FooBar> hmmm... in my games with FIRS I actually never missed the survey supplies, so do what you think is best 19:07:19 <planetmaker> that I subscribe to, too 19:07:51 <andythenorth> I'll deprecate it 19:07:57 <FooBar> maybe just keep around what we have of it and then see what to do about it around 0.9 19:10:02 <FooBar> also, wtf does industry variable 86 entail? 19:10:16 <FooBar> or var 88 for that matter... 19:10:58 <andythenorth> 80+ var 19:10:59 <andythenorth> ? 19:11:34 <andythenorth> 86 -> XY dimensions of industry? 19:11:43 <andythenorth> 88 -> types of cargo produced? 19:12:23 <FooBar> hmmm... I'll try to translate further to see where it leads... 19:12:30 <FooBar> but it doesn't seem useful at this point 19:18:25 <FooBar> nope, doesn't make sense: http://pastebin.org/761768 19:19:11 <FooBar> seems to be some sort of callback result, apart from that there's not checked to see if in callback... 19:20:28 <FooBar> but then CB 28 is active... 19:21:05 <FooBar> and that is where the variables come from as well... 19:23:08 <FooBar> so in the end it makes some sense, but it's weirdly coded... 19:37:52 <Brot6> Total Town Replacement Set - Revision 10:cc1da583a917: Codechange: move banks to separate file an... (foobar) @ http://dev.openttdcoop.org/projects/ttrs/repository/revisions/cc1da583a917 19:39:29 <planetmaker> :-) 19:40:15 <FooBar> I'm noticing that the banks are never going to work combined with FIRS, except for temperate 19:40:29 <andythenorth> for why? 19:40:38 <FooBar> in tropic and arctic, the banks don't produce, only accept 19:40:50 <FooBar> and since there's nothing in FIRS that produces GOLD or DIAM... 19:42:14 <FooBar> so I think it's best not to allow TTRS banks together with FIRS after all 19:42:29 <FooBar> doesn't mean that TTRS doesn't need fixing now :) 19:46:54 <planetmaker> :-) But it makes sense. Can you add that piece of information to the bank issue of TTRS, please? 19:47:28 <planetmaker> (or fix it / how you like) 19:47:40 <planetmaker> maybe banks accept... scrap metal? 19:47:43 <planetmaker> :-P 19:49:21 <FooBar> sure, I'll add it 19:50:24 <planetmaker> I'm just not sure whether it would make sense to re-define tropical and arctic banks then to behave similar to temperate ones. 19:51:02 <Brot6> Total Town Replacement Set - Feature Request #1287: FIRS compatible (foobar) @ http://dev.openttdcoop.org/issues/1287#change-3406 19:51:34 <FooBar> now that might break stuff 19:51:42 <FooBar> or at least influence gameplay 19:52:09 <Ammler> doesn't firs already enough industries? 19:52:27 <FooBar> image TTRS with default industries: gold mine or diamond mine are useless if banks also produce gold/diamonds... 19:52:36 <Ammler> I don't think, someone will miss banks 19:52:57 <FooBar> It's way more profitable to have a truck between two banks than between a mine and a bank: no empty runs 19:53:46 <FooBar> It might be something for a parameter option, but not for default behaviour 19:54:03 <FooBar> also I agree with Ammler: FIRS doen't really need the banks 19:54:25 <FooBar> so fixing TTRS and not allowing the banks with FIRS might not be a bad option 19:56:55 <planetmaker> FIRS doesn't need banks, sure :-) 19:57:01 <planetmaker> But towns might need banks ;-) 19:57:18 <planetmaker> in the sense of: they look good there. So making use of them doesn't hurt 19:57:26 * andythenorth doesn't care either way 19:57:43 <andythenorth> I don't use TTRS, it's neither TTD style nor OpenGFX style 19:57:46 <planetmaker> Changing tropic+arctic banks in TTRS by default was also not my intention; I implicityl thought in conjunction with FIRS 19:57:52 <Ammler> yes, just convert those to houses :-) 19:58:25 <planetmaker> I actually got an e-mail from George... TTRS4 is kinda stalled atm, but it's still around. 19:58:37 <planetmaker> And he'd be interested to jointly bring TTRS4 into being 19:59:09 <planetmaker> which obviously shall partially also obsolete ECS houses 19:59:21 <Ammler> planetmaker: csaboka would have single pcxes for TTRS houses 19:59:36 <planetmaker> Ammler, it seems rather they're in bmp 19:59:44 <Ammler> at least from what I have read in the forums 19:59:44 <planetmaker> grfmaker, you know 19:59:48 <Ammler> ah ok 19:59:50 <planetmaker> not single bmps, but several 19:59:53 <planetmaker> I have them 19:59:54 <Ammler> doesn't matter, does it? 20:00:08 <planetmaker> I just didn't bother to commit them 20:00:22 <planetmaker> actually... I didn't even look at them yet 20:00:27 <Ammler> well, are those kind "templated"? 20:00:33 <Ammler> ok :-) 20:00:33 <planetmaker> let's see :-) 20:01:55 <Ammler> frosch123: you tried building grf2html on x86_64? 20:01:57 <Ammler> https://build.opensuse.org/package/live_build_log?arch=x86_64&package=grf2html&project=home%3Aopenttdcoop&repository=openSUSE_11.2 20:02:30 <planetmaker> not bad: http://img.openttdcoop.org/images/additional. 20:02:54 <planetmaker> but I'd re-arange stuff anyway for a template 20:03:41 <Ammler> hmm, c&p issue? 20:04:20 <planetmaker> hm? 20:04:27 <frosch123> # Windows resource compiler. Note: This always has to be the 32bit version, independent of target architecture. <- Ammler: i am currently running it on x64, and there is a comment in the makefile :p 20:04:55 <andythenorth> FooBar: what else do we need to discuss? 20:05:09 <FooBar> oh yes, we were discussing things :P 20:05:16 <FooBar> let's see 20:05:17 <frosch123> (yeah, pascal is not that easy to compile as c) 20:05:22 <Ammler> :-) 20:05:30 <Ammler> well, it wasn't that hard locally :-) 20:05:40 <FooBar> what are we going to do about incomplete chains? 20:05:43 <Ammler> I just get troubles on 64 and suse 11.3 20:06:04 <FooBar> mainly gravel is a bit problematic now and I can't think of anything interesting that needs gravel 20:06:49 <andythenorth> yes gravel looks tricy 20:06:52 <andythenorth> tricky /s 20:07:02 <Rubidium> tennis courts! 20:07:05 <Ammler> the question is how to I tell the 64er system to use 32er mingw 20:07:32 <Rubidium> is 64 bits mingw already released? 20:07:35 <frosch123> what does your spec look lke? 20:07:39 <Rubidium> thought it wasn't quite done yet 20:07:46 <FooBar> apart from concrete, the other purpose of gravel is to pave roads 20:07:47 * andythenorth wonders why gravel is in FIRS at all? 20:08:13 <Rubidium> because someone put it on tt-foundry? 20:08:43 <frosch123> WINDRES=/opt/cross/bin/i386-mingw32msvc-windres <- actually that is the right one 20:08:46 <FooBar> to put in cement? Which doesn't even have gravel in it? 20:08:47 <andythenorth> and why does the cement plant accept sand? 20:08:51 <Terkhen> version 1.0 of mingw64 is already released 20:08:52 <FooBar> dunno 20:08:54 <andythenorth> it should be clay and limestone 20:08:59 <Ammler> https://build.opensuse.org/package/view_file?file=grf2html.spec&package=grf2html&project=home%3Aopenttdcoop 20:09:02 <Terkhen> I never got to test it 20:09:09 <andythenorth> I'm sure we discussed it somewhere :) 20:09:12 <FooBar> not even clay, there's no clay in cement 20:09:26 <Ammler> hmm, true 20:09:33 <FooBar> maybe the cement plant needs to be a concrete plant 20:09:53 <frosch123> hmm, actually i should trash the hardcoded versions and add some svn detection 20:09:54 <Rubidium> Ammler: does the makefile autodetect mingw? 20:09:54 <andythenorth> strictly yes 20:10:29 * planetmaker doesn't know the difference between cement and concrete in English 20:10:30 <FooBar> why did the cement plant accept coal again? 20:10:30 <Ammler> Rubidium: like frosch123 posted: WINDRES=/opt/cross/bin/i386-mingw32msvc-windres 20:10:49 <Rubidium> Ammler: is only that needed? No pascal cross compiler or so? 20:10:49 <FooBar> cement is the grey powder to make concrete 20:11:16 <frosch123> hmm, how does that WINDRES systax work with just appending stuff to make? 20:11:17 <Ammler> BuildRequires: fpc libpng-devel cross-mingw-binutils 20:11:21 <planetmaker> ah 20:11:31 <planetmaker> Then I guess concrete is better 20:11:38 <andythenorth> FooBar: coal or other fuel is an important ingredient for cement making 20:11:40 <planetmaker> though it depends 20:11:42 <FooBar> planetmaker: Zement (lat. caementum „Bruchstein“, „Baustein“) ist ein hydraulisches Bindemittel für die Baustoffe Mörtel und Beton. 20:11:44 <planetmaker> there could be both 20:11:56 <FooBar> ah fuel, that is fine then 20:12:04 <frosch123> Rubidium: i have also only the x64 compiler installed 20:12:06 <planetmaker> FooBar, I know :-) 20:12:18 <FooBar> wait for the translation: 20:12:20 <planetmaker> But in German language you can use the same word also for concrete 20:12:31 <planetmaker> at least sloppily 20:12:37 <FooBar> Zement == Cement; Beton == Beton :P 20:12:48 <Rubidium> guess I don't understand what's going on. Why would you need windres if you're not making something for windows? 20:13:10 <planetmaker> FooBar, but I wonder: would one rather have a cement plant or a concrete plant? 20:13:11 <FooBar> well, sloppily we use in Zement for Mörtel in Dutch, but not for concrete 20:13:17 <Rubidium> or you are making something for windows, in which case fpc probably isn't the mingw pascal compiler 20:13:23 <planetmaker> If it's transported via train, I'd still opt for cement 20:13:29 <FooBar> also, I meant Beton = concrete :P 20:13:35 <planetmaker> yes ;-) I figured 20:13:52 <planetmaker> And yes, you're right; it's sloppily used for Mörtel. 20:13:58 <planetmaker> Beton is more stable 20:14:08 <frosch123> Rubidium: it was a windows application, then was ported to linux, and fpc reads the windows-format resourcefiles 20:14:23 <FooBar> anyways, we're drifting off... 20:14:28 <planetmaker> :-) 20:14:39 <planetmaker> I think cement makes sense 20:14:42 <frosch123> quite complicated, maybe someone should just port it to c :p 20:14:45 <planetmaker> you produce the powder 20:15:11 <planetmaker> which you then can deliver to ... construction sites and wholesale markets 20:15:12 <FooBar> that's also what the graphics represent, so I'd prefer keeping them as they look good 20:15:17 <planetmaker> yep 20:15:35 <planetmaker> you could have mines accept it ;-) 20:15:51 <andythenorth> ummm 20:15:54 <andythenorth> I changed that :P 20:16:02 <Rubidium> frosch123: oh, nasty :) 20:16:04 <andythenorth> cement plant used to produce ENSP 20:16:28 <andythenorth> the cement plant is a combined cement and concrete plant :) 20:16:45 <andythenorth> it produces construction materials for towns ('Goods') 20:17:08 <Rubidium> I like the grf2html spec with it's references, but it doesn't tell where those references are going to 20:17:21 <planetmaker> andythenorth, no problem :-) 20:17:26 <andythenorth> in some future economies, maybe the cargo 'Construction Materials' makes a guest appearance, affecting town growth 20:17:47 <frosch123> what references? 20:18:02 <planetmaker> :-) @ andythenorth 20:18:05 <Rubidium> This tool converts TTDPatch [1] NewGrfs [2] into an easier readable html document. <- the [1] and [2] 20:18:24 <frosch123> oh, those :p 20:18:57 <Rubidium> and by reading that description I would say it's GPLv1 licensed :) 20:18:59 <Ammler> frosch123: on the build log I pasted 20:19:08 <Ammler> windres already worked 20:19:14 <Ammler> or am I wrong 20:19:58 <Ammler> Error: /usr/bin/ppcx64 <-- this is suspect 20:20:21 <FooBar> I think the gravel quarry needs to become a limestone quarry 20:20:39 <planetmaker> why? 20:20:46 <Ammler> hmm, maybe not :-) 20:21:07 <FooBar> then we can just stick with a cement plant... 20:21:18 <planetmaker> hm. well. why not 20:21:25 <planetmaker> Limestone already exists as cargo 20:21:34 <planetmaker> thus it should be readily supported even 20:21:38 <FooBar> true 20:21:54 <planetmaker> it probably would only need re-colouring of the gravel thingy 20:22:09 <FooBar> also the quarry graphics are probably fine, according to wikipedia limestone is also grey 20:22:38 <FooBar> I recall it to be more yellow-ish though 20:22:45 <planetmaker> http://images.google.com/images?hl=en&source=imghp&biw=1267&bih=848&q=limestone&gbv=2&aq=f&aqi=g10&aql=&oq=&gs_rfai= 20:22:46 <Webster> Title: limestone - Google Search (at images.google.com) 20:23:08 * planetmaker recalls it also more yellowish 20:23:54 <frosch123> except i have 2.4.0-2 it looks the same for me 20:23:56 <FooBar> no, I'm confused with marl 20:24:11 <FooBar> (that's Mergel in German or Dutch) 20:24:41 <FooBar> marl is indeed yellowish 20:25:03 <Ammler> oh, you have newer fpc? 20:25:12 <planetmaker> well. Limestone has a tendency there, too. But as usual: there's a variety 20:25:31 <FooBar> but then, replacing gravel with marl doesn't solve the problem that it isn't accepted before the cement plant is introduced... 20:25:36 <FooBar> we seem to be fixing the wrong problem... 20:26:13 <Ammler> maybe I should also use 32bit fpc? 20:26:57 <Ammler> ppcx32? :-) 20:27:02 <Rubidium> FooBar: mergel != limestone; mergel = limestone + something clay-ish 20:27:18 <FooBar> Rubidium: I knew that ;) 20:27:54 <FooBar> I never said marl = limestone, or did I? 20:28:01 <andythenorth> FooBar: 'gravel' was originally 'stone' IIRC, then we argued about the best name 20:28:08 <andythenorth> I could look in the thread... 20:28:12 <frosch123> Ammler: it also works for me, when i replace fpc with ppcx64 20:28:12 <Rubidium> nah, I just missed that line 20:28:25 <Ammler> hmm :-( 20:29:01 <FooBar> limestone seems to be used in glass making (in some circumstances) 20:29:03 <frosch123> http://pastebin.com/v9zcv1rr <- that is my output if i disable the .SILENT 20:29:11 <FooBar> also added to paper 20:29:22 <FooBar> or toothpaste 20:29:25 <frosch123> the same for fpc and ppcx64 20:29:33 <planetmaker> jo 20:29:41 <frosch123> no idea about the difference of those, they are not just symlinks 20:29:47 <FooBar> also used in blast furnaces to extract iron from iron ore 20:30:17 <planetmaker> and as construction material directly 20:30:36 <planetmaker> fertilizer kind of 20:30:38 <FooBar> true, but that would potentially need a new industry... 20:31:28 <FooBar> maybe we need an additional step between the iron ore and the steel mill... 20:31:36 <andythenorth> nah 20:32:05 <frosch123> ppc386 seems to be the 32bit compiler, not installed here though 20:32:06 <andythenorth> then we'd need an alumina plant for bauxite as well 20:32:16 <planetmaker> nah 20:33:32 <FooBar> have one do both: an 'ore extractor' 20:33:32 <andythenorth> FooBar: http://www.tt-forums.net/viewtopic.php?p=766413#p766413 20:33:34 <Webster> Title: Transport Tycoon Forums • View topic - FIRS Industry Replacement Set - Development (at www.tt-forums.net) 20:33:53 <FooBar> I was in favour of gravel? :S 20:34:30 <andythenorth> apparently 20:34:42 <andythenorth> I would have preferred 'Stone' 20:35:05 <andythenorth> however we now have a gravel pit (and planned...a dredging site) 20:35:12 <andythenorth> I think it's all fine 20:35:21 <andythenorth> we just have this question about gravel before 19xx 20:35:41 <FooBar> agreed 20:35:57 <andythenorth> gravel -> town? 20:36:25 <FooBar> hmmm... I'm not convinced by that 20:36:53 <FooBar> then I'd rather not use gravel until there's a cement plant 20:37:28 <Ammler> frosch123: it looks like the windres is skipped here 20:37:50 <Ammler> it doesn't matter, if I run make WINDRES=/opt/cross/bin/i386-mingw32msvc-windres or just make 20:38:15 <frosch123> as i said, i do not know that syntax 20:38:38 <frosch123> what does it do? does it overwrite stuff from the makefile, or does it initialise stuff, which is then overridden by the makefile? 20:38:57 <andythenorth> FooBar: we could put an intro date on gravel quarry 20:39:08 <andythenorth> I'd rather see another use for the cargo though 20:39:16 <FooBar> me too 20:39:56 <FooBar> There's just no interesting industry that accepts gravel... 20:40:35 <frosch123> Ammler: maybe to "make clean" first? 20:40:45 <andythenorth> basically gravel == construction 20:40:59 <frosch123> at least "make WINDRES=blub" fails for me :p 20:41:08 <andythenorth> it would be more interesting in the context of newgrf town growth cargos 20:41:49 <Ammler> yes :-) 20:42:31 <FooBar> I guess we need a new "general contractor" industry 20:42:42 <Ammler> frosch123: can I make the output more verbose? 20:42:56 <frosch123> you can remove the .SILENT from the makefile 20:42:58 <FooBar> that accepts gravel, ENSP and maybe something else 20:43:02 <frosch123> but you will not get more than in my paste 20:43:13 <frosch123> because it just does not do more :p 20:43:47 <frosch123> only 5 lines 20:46:11 <Ammler> well, we could also simply build with i586 20:46:21 <FooBar> it can also accept steel 20:46:37 <FooBar> and most likely produce nothing 20:47:16 <Ammler> I have no clue :-( 20:47:26 <frosch123> i only have the i586, and i doubt there is a difference, as the resfile does not contain any code 20:57:12 <frosch123> well, if i drop the support to compile all sources on windows (i.e. without gnu tools), i can likely get rid of the need for resource files 20:57:47 <frosch123> hmm, or i could also convert them into source 21:00:38 <Ammler> shouldn't it be easy possible ot use a i586 bin on x86_64? 21:01:07 <frosch123> you need a 32bit libpng and other libs 21:01:24 <Ammler> zlib and libc 21:01:41 <frosch123> like those, yes 21:02:05 <Ammler> https://build.opensuse.org/package/binary?arch=i586&filename=grf2html-r230-2.1.i586.rpm&package=grf2html&project=home%3Aopenttdcoop&repository=openSUSE_11.2 21:03:16 <frosch123> well, at least 32bit works :) 21:03:51 <andythenorth> FooBar: general contractor sounds like the 'Engineers Yard' (now removed :P) 21:04:10 <FooBar> yes it does :) 21:04:50 <FooBar> maybe that needs to be reinvented then... 21:07:41 *** thgergo has joined #openttdcoop.devzone 21:12:20 <Brot6> Grf2Html - Feature #1297 (New): Get rid of resource files (frosch) @ http://dev.openttdcoop.org/issues/1297 21:13:53 <Brot6> Grf2Html - Feature #1298 (New): Create version information from repository version (frosch) @ http://dev.openttdcoop.org/issues/1298 21:16:57 <frosch123> night 21:17:01 *** frosch123 has quit IRC 21:18:13 <Brot6> Total Town Replacement Set - Revision 11:7ef9bc72144d: Feature: define cargo for banks (foobar) @ http://dev.openttdcoop.org/projects/ttrs/repository/revisions/7ef9bc72144d 21:18:27 <FooBar> I'm not so sure about that feature though 21:19:25 <FooBar> It might be better to check if VALU/GOLD/DIAM is available and base the decision to have a bank or not on that fact 21:21:45 <planetmaker> what does it do now? 21:22:51 <planetmaker> nvm 21:23:15 <planetmaker> but... //if tropic, check if DIAM available, if not, define it and add cargo translation table 21:23:23 <planetmaker> seems wrong. It only checks for climate, right 21:23:29 <planetmaker> and then defines it unconditionally 21:24:10 <FooBar> oh, that is a leftover comment... 21:24:17 <FooBar> there's no use in defining a CTT 21:24:24 <planetmaker> :-) 21:24:44 <FooBar> I thought that cargos were defined on a per-grf basis and allocated a free slot depending on that, but that isn't the case 21:24:45 <Brot6> Total Town Replacement Set - Feature Request #1287: FIRS compatible (foobar) @ http://dev.openttdcoop.org/issues/1287#change-3407 21:25:16 <FooBar> You define a cargo for one specific ID and it will just use that ID, regardless if it's used and if there are other free IDs 21:25:43 <planetmaker> hm. 21:28:18 <Brot6> Total Town Replacement Set - Feature Request #1287: FIRS compatible (Ammler) @ http://dev.openttdcoop.org/issues/1287#change-3408 21:38:18 <andythenorth> goodnight 21:38:31 <Terkhen> night andythenorth 21:40:35 <FooBar> night 21:40:45 <FooBar> also for me btw... 21:40:48 *** FooBar has quit IRC 22:02:20 <Brot6> Total Town Replacement Set - Revision 12:ff70262d476d: Add: Swedish and Polish translations (by A... (planetmaker) @ http://dev.openttdcoop.org/projects/ttrs/repository/revisions/ff70262d476d 22:03:02 <planetmaker> good night here, too 22:11:02 <Brot6> FIRS Industry Replacement Set - Bug #1299 (New): Industries not using TTD strings when possible (Terkhen) @ http://dev.openttdcoop.org/issues/1299 22:15:16 <Brot6> NewGRF Meta Language - Bug #1300 (New): internal error with utf8 encoding (planetmaker) @ http://dev.openttdcoop.org/issues/1300 22:19:55 <Brot6> Example NewGRF Project - Revision 163:f29656368230: Fix: update script wasn't quite up to date (planetmaker) @ http://dev.openttdcoop.org/projects/newgrf-makefile/repository/revisions/f29656368230 22:24:13 <Rubidium> is it me or is obs missing from that script? 22:24:49 <Yexo> planetmaker: I can't reproduce #1300 22:25:46 <Yexo> do you have any local changes in your swedishrails checkout? 22:25:53 <Yexo> like other language files in lang/ ? 22:26:04 *** ODM has quit IRC 22:26:31 <planetmaker> hm... probably yes 22:26:45 <Yexo> can you upload those to the task? 22:26:47 <planetmaker> yes. A German and a Swedish file 22:27:11 <Yexo> if anything a better error should be shown and just that language file ignored 22:28:12 <planetmaker> added 22:28:38 <planetmaker> It will be the Swedish one 22:29:01 <planetmaker> as the German has been lingering there for eons 22:29:12 <Brot6> NewGRF Meta Language - Bug #1300: internal error with utf8 encoding (planetmaker) @ http://dev.openttdcoop.org/issues/1300#change-3409 22:29:27 <Yexo> it is 22:30:41 <planetmaker> converting to utf8 helps ;-) 22:30:45 <planetmaker> indeed 22:32:45 <planetmaker> doh... nasty nasty encodings :-( 22:33:12 <planetmaker> I should have thought of that, given I spent today over an hour to convert ttrs to utf8 22:34:47 <Yexo> Language file \"%s\" contains non-utf8 characters. Ignoring (part of) the contents. <- Is that warning enough? 22:35:24 <Ammler> he, how is it possible to have non-utf8 chars? 22:35:35 <planetmaker> I guess. Because it makes clear what has to be done 22:35:52 <Yexo> Ammler: not all byte strings are valid in utf8 22:36:16 <planetmaker> Or... Maybe add "Check file encoding" 22:37:32 <Brot6> NewGRF Meta Language - Revision 674:3d158a029c74: Fix [#1300]: don't crash when a language file c... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/3d158a029c74 22:38:00 <planetmaker> actually this bug shows one thing: it might be good, if the included language files need explicit inclusion 22:38:00 <Yexo> I'd have done that if I hadn't already pushed the changeset 22:39:02 <Ammler> and a subdir "unfinished" like openttd :-) 22:39:46 <Brot6> NewGRF Meta Language - Bug #1300 (Closed): internal error with utf8 encoding (planetmaker) @ http://dev.openttdcoop.org/issues/1300 22:39:47 <Brot6> NewGRF Meta Language - Bug #1300 (Closed): internal error with utf8 encoding (yexo) @ http://dev.openttdcoop.org/issues/1300#change-3410 22:39:47 <planetmaker> That's up to the grf author IMHO :-) 22:43:19 <Brot6> Example NewGRF Project - Revision 164:1112b08ef11e: Fix: don't have double rule definitions (planetmaker) @ http://dev.openttdcoop.org/projects/newgrf-makefile/repository/revisions/1112b08ef11e 22:48:12 <Brot6> Swedish Rails - Revision 144:91d4bb808ee7: Change: [Makefile] Update to r164 (planetmaker) @ http://dev.openttdcoop.org/projects/swedishrails/repository/revisions/91d4bb808ee7 22:59:03 <Brot6> Swedish Rails - Bug #1301 (Confirmed): templates for TTD/TTRS level crossings (planetmaker) @ http://dev.openttdcoop.org/issues/1301 23:29:38 *** thgergo has quit IRC