Log for #openttdcoop.devzone on 24th August 2010:
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) @
00:16:25  <Brot6> Total Town Replacement Set - Revision 6:41e666c809c4: Change: Indentation level adjusted for para... (planetmaker) @
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) @
06:51:06  <Brot6> FIRS Industry Replacement Set - Feature #1295 (New): allow TTRS, if parameter 04 is set (planetmaker) @
07:39:43  <Brot6> Total Town Replacement Set - Feature Request #1287: FIRS compatible (planetmaker) @
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) @
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) @
09:01:05  <planetmaker>
09:01:15  <planetmaker> uhm... :-P
09:41:24  <Brot6> Total Town Replacement Set - Feature Request #1287 (Feedback): FIRS compatible (foobar) @
09:47:14  <Brot6> FIRS Industry Replacement Set - Feature #1295 (Closed): allow TTRS, if parameter 04 is set (planetmaker) @
09:47:14  <Brot6> FIRS Industry Replacement Set - Revision 1249:3c546c1c20f7: Feature: only allow TTRS if TTRS para... (foobar) @
09:47:14  <Brot6> FIRS Industry Replacement Set - Feature #1295 (Closed): allow TTRS, if parameter 04 is set (foobar) @
10:07:18  <Brot6> Total Town Replacement Set - Feature Request #1287: FIRS compatible (planetmaker) @
10:12:14  <Brot6> Total Town Replacement Set - Feature Request #1287: FIRS compatible (planetmaker) @
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.
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:
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
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, but a
13:45:28  <Ammler> how do I tell make to search for
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) @
13:50:32  <Brot6> NewGRF Meta Language - Revision 673:8f489336c52f: Fix (r564) [closes #1274]: all else blocks were... (yexo) @
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) @
14:36:04  <Brot6> 2cc train set - Revision 588:be9933e73f0c: Fix: Merge (DJNekkid) @
14:36:04  <Brot6> 2cc train set - Support #1289 (Closed): Corrected ChME3 sprites (DJNekkid) @
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) @
16:20:25  <Brot6> 2cctrainset: update from r586 to r588 done (47 errors) -
16:21:30  <Brot6> firs: update from r1246 to r1250 done -
16:22:31  <Brot6> nml: update from r672 to r673 done -
16:23:11  <Brot6> snowlinemod: update from r33 to r36 done -
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><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>
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) @
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) @
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) @
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) @
17:43:21  <Brot6> FIRS Industry Replacement Set - Feature #1236: 1 tile buffer should be ignored when player / scen... (andythenorth) @
18:06:54  *** ODM has joined #openttdcoop.devzone
18:15:35  <Brot6> FIRS Industry Replacement Set - Feature #1235: 1 tile buffer - Generic Tiles (foobar) @
18:20:37  <Brot6> Total Town Replacement Set - Revision 9:07c53194bd0c: Change: convert to UTF-8 (planetmaker) @
18:33:00  <Brot6> FIRS Industry Replacement Set - Feature #1235: 1 tile buffer - Generic Tiles (foobar) @
18:34:38  <Brot6> FIRS Industry Replacement Set - Revision 1254:522bf297992e: Feature: 1 tile buffer for generic ti... (foobar) @
18:34:38  <Brot6> FIRS Industry Replacement Set - Feature #1235 (Closed): 1 tile buffer - Generic Tiles (foobar) @
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
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 instead
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>
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 is linked to
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 as symlink to
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, 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) @
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:
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) @
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) @
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>
20:02:30  <planetmaker> not bad:
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>
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>
20:22:46  <Webster> Title: limestone - Google Search (at
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> <- 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:
20:33:34  <Webster> Title: Transport Tycoon Forums • View topic - FIRS Industry Replacement Set - Development (at
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>
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) @
21:13:53  <Brot6> Grf2Html - Feature #1298 (New): Create version information from repository version (frosch) @
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) @
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) @
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) @
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) @
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) @
22:15:16  <Brot6> NewGRF Meta Language - Bug #1300 (New): internal error with utf8 encoding (planetmaker) @
22:19:55  <Brot6> Example NewGRF Project - Revision 163:f29656368230: Fix: update script wasn't quite up to date (planetmaker) @
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) @
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) @
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) @
22:39:47  <Brot6> NewGRF Meta Language - Bug #1300 (Closed): internal error with utf8 encoding (yexo) @
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) @
22:48:12  <Brot6> Swedish Rails - Revision 144:91d4bb808ee7: Change: [Makefile] Update to r164 (planetmaker) @
22:59:03  <Brot6> Swedish Rails - Bug #1301 (Confirmed): templates for TTD/TTRS level crossings (planetmaker) @
23:29:38  *** thgergo has quit IRC

Powered by YARRSTE version: svn-trunk