Log for #openttdcoop.devzone on 24th September 2010:
Times are UTC Toggle Colours
02:38:52  <Brot6> OpenGFX+ Trees - Revision 27:9c74239a5f7f: Feature #1530: Swap trees for FIRS Fruit Plantation (Froix) @
02:40:44  <Brot6> OpenGFX+ Trees - Feature Request #1530 (Closed): Swap two trees for better look with FIRS (Froix) @
02:53:34  <Brot6> OpenGFX+ Trees - Revision 28:914d812a3393: Doc: renamed readme to get proper title automatically (Froix) @
02:53:34  <Brot6> OpenGFX+ Trees - Revision 29:a049d28bb16b: Feature: Tree Graphics - added and edited, 1 apple tre... (Froix) @
02:53:34  <Brot6> OpenGFX+ Trees - Revision 30:92816946e087: Codechange: Split code into smaller more readable litt... (Froix) @
02:56:01  *** Froix has joined #openttdcoop.devzone
03:10:07  <Froix> hello!
03:15:24  <Froix> all is quiet in the western front
03:29:06  *** Froix has quit IRC
04:30:06  *** fanioz has joined #openttdcoop.devzone
04:36:32  <Brot6> Bundles Update: g34019149 2010-09-24 cargodist   (
04:56:02  *** fanioz has quit IRC
07:04:36  *** fanioz has joined #openttdcoop.devzone
07:04:44  <fanioz> hello
07:05:45  <Terkhen> hi fanioz
07:06:34  <fanioz> hi Terkhen :D
07:08:42  <fanioz> do we really need (g)cc to compile a NML file ?
07:10:06  <Terkhen> IIRC it is required for including files
07:11:35  <fanioz> well I've got these at top of the output file :
07:11:37  <fanioz> # 1 "<stdin>"
07:11:39  <fanioz> # 1 "<built-in>"
07:11:39  <fanioz> # 1 "<command-line>"
07:11:39  <fanioz> # 1 "<stdin>"
07:13:10  <fanioz> and, nmlc <that_output_file> give a message "Illegal character '#' at "input", line 1"
07:15:05  <Terkhen> hm, are you using it from mingw/msys? I remember getting and discussing a similar error a few days ago, but my memory is bad as usual
07:15:54  <fanioz> yup, mingw. Well, then is was known issue
07:17:42  <fanioz> however I could do straight compile without using #include, no gcc, just nmlc.
07:21:31  <Terkhen> I have no idea how to fix it, though... I'll check this again later
07:27:32  <fanioz> thanks Terkhen
07:33:43  *** ODM has joined #openttdcoop.devzone
07:48:25  *** Webster has joined #openttdcoop.devzone
07:51:19  <planetmaker> fanioz: Terkhen is right with the need for gcc to process the includes. But... it seems to work on other platforms
07:51:54  <planetmaker> I don't remember the solution anymore either (if there was one). There was *some* issue...
07:52:01  <Terkhen> hm
07:52:32  <Terkhen> I remember discussing it here, but I couldn't find anything about this at the logs
07:52:33  <planetmaker> for you it works, Terkhen ?
07:52:40  <Terkhen> I can't test right now
07:52:57  <planetmaker> I mean... have you ever compile an NML project?
07:53:14  <Terkhen> not in msys
07:53:17  <planetmaker> hm
07:53:31  <Terkhen> I was going to test just when we discovered that using a VM was way faster :)
07:53:38  <planetmaker> :-D
07:54:17  <planetmaker> Alberth was around at that time, too, IIRC. He commented on the regex parsing the '#' lines
07:54:41  <planetmaker> obviously that regex fails then in MinGW.
07:54:59  <planetmaker> or the lines from mingw-gcc look different
07:55:23  <planetmaker> though I think we found out that at least not in an obvious way
07:57:06  <fanioz> so, if mingw gcc gave output  -> # 1 "<stdin>"  that was unexpected result ?
07:57:27  * fanioz didn't test yet with gnu cc
07:57:36  <Brot6> OpenGFX+ Trains - Revision 9:f66fc89c8758: Add #1528: Some toyland graphics for the flatbed wagon (planetmaker) @
07:57:45  <planetmaker> fanioz: that's what the lines should look like...
07:58:31  <planetmaker> <-- that's what my pre-processed nml files look like
08:02:11  <fanioz> hmm
08:02:12  <Brot6> OpenGFX+ Trains - Revision 10:b46af944d18b: Change: Remove some unneeded code and comments (planetmaker) @
08:02:50  <fanioz> so, it was nmlc didn't recognize them on mingw?
08:03:23  <planetmaker> seems like
08:03:43  <planetmaker> actually those lines are helpful in case of errors: they'll allow to give the file and line where the error i
08:03:46  <planetmaker> *is
08:04:45  <planetmaker> (and you certainly agree that multiple files usually make sense wrt structuring the code)
08:05:22  <fanioz> :D
08:07:22  <fanioz> Okay, here another question :D
08:07:27  <fanioz> version, on grf block{}  is it a version of NewGRF to be made, or version as in Action 8 (Graphic version)  ?
08:08:40  <planetmaker> that's the action14 version. So it's the newgrf version, like AIs have versions
08:10:38  <fanioz> clear :D
08:12:36  <Terkhen> <--- log of the error
08:12:40  <Terkhen> <--- start of the nml file
08:13:11  <Terkhen> I remember Alberth pointing us to the token that was causing the error
08:13:14  <Brot6> Indonesian Town Names - Revision 7:03654675c299: [NML] -Reformatted town lists (fanioz) @
08:16:42  <Terkhen> IIRC it was lines 45 and/or 46 of
08:18:48  <Terkhen> outside msys (in cmd) compilation fails with the same error, so I'm guessing python regexps are behaving diferently in windows for some reaseon
08:18:53  <Terkhen> reason*
08:19:11  <planetmaker> hm...
08:21:19  <Brot6> OpenGFX+ Trains - Revision 11:0080f69403fc: Change: Use the repository version as newgrf version (planetmaker) @
08:22:34  <planetmaker> I'd like to see this as an NML bug
08:22:41  <planetmaker> maybe you can add that there?
08:22:57  <Terkhen> okay
08:23:54  <Brot6> Example NewGRF Project - Revision 218:7c6e2cfb81c6: Change: [NML] Allow to use the repository ver... (planetmaker) @
08:26:12  <planetmaker> in any case I can't look at it right now and then it won't become forgotten :-)
08:43:00  *** fanioz has quit IRC
08:49:53  <Ammler> sed "/^#/d"?
08:53:35  <Rubidium> I'd say nml should just ignore it
08:53:58  <Rubidium> i.e. see it as a comment
08:54:34  <Rubidium> though it might be related to Windows newlines or something as AFAIK cpp at Linux does the same
08:54:57  <planetmaker> yes; the same thing works on linux and OSX
08:55:32  <planetmaker> Ammler, removing those lines would remove all sensible error locations
08:55:40  <planetmaker> which would make error messages much harder to read
08:55:56  <planetmaker> at the moment the error messages are usually quite good
08:56:58  <Ammler> well, you remove those after gcc for nmlc
08:58:47  <Terkhen> maybe it is yet another EOL related bug
08:59:35  <Terkhen> heh, it is
09:00:11  <Terkhen> converting the nml file to unix EOL format allows nmlc to compile it
09:10:59  *** fanioz has joined #openttdcoop.devzone
09:11:07  <planetmaker> nice
09:22:06  <Brot6> Indonesian Town Names - Revision 8:c645e0436727: [NML] -Added:: NML default languange (fanioz) @
09:38:01  <Terkhen> hmm... I'm not sure if this is a bug in nml or in the makefile
09:44:29  <Terkhen> bbl
09:59:46  *** ODM has quit IRC
10:16:05  *** KenjiE20 has joined #openttdcoop.devzone
10:42:26  <fanioz> <------- log of error
10:42:58  <fanioz> <------------ code snippet
10:44:16  <fanioz> any one could explain, please?
10:49:20  <Ammler> nml "decided" not to care about openttd < 1.0
10:49:31  <Ammler> (but that might not be your issue)
10:51:50  <fanioz> is that mean I could 'throw' that peace of checking anyway ? :D
10:52:00  <planetmaker> fanioz, string(STR_MIN_VERSION_OPENTTD)
10:52:16  <planetmaker> fanioz, no need to throw away
10:52:49  <fanioz> :D, thanks would try again
10:55:32  <fanioz> nmlc: "input", line 11: Syntax error, unexpected token "string"  <------ that said
10:56:02  <planetmaker> hm
10:56:29  <planetmaker> might be that it's a string which cannot be translated. Not sure...
10:56:49  <planetmaker> does it work with a literal string there? "minimum: 0.6.0"?
10:57:43  <Ammler> fanioz: it isn't not worth to check for <1.0, that's all
10:57:59  <Ammler> if not, it would be better to let nml do such checks
10:58:09  <Ammler> -not
10:59:32  <Ammler> I mean, how do you know, which version of openttd does support town names?
10:59:54  <Ammler> you might do that because you copied my nfo snippets :-)
11:00:18  <fanioz> Ammler:: no I don't but yes it was translated from the 'old' makegrf script :D
11:00:56  <fanioz> planetmaker, literal string "minimum  6.0" does it job
11:01:11  <fanioz> ~ "0.6.0"
11:01:55  <Ammler> then you should test for 1.0.0
11:02:38  <Ammler> but it is silly :-)
11:02:55  <fanioz> :D
11:03:13  <Ammler> I removed those tests from newer town names
11:03:45  <fanioz> okay, we might not need it. But at least there is known issue here .. :D
11:04:02  <Ammler> yes, you might make a bug report at nml
11:04:58  <Ammler> anyway, testing for OpenTTD version should be done by nml directly
11:07:24  <fanioz> still should / could / or it has been done ? :D
11:07:41  <Ammler> you should report it anyway
11:08:07  <Ammler> openttd version checking should not be done by you
11:08:25  <fanioz> :D
11:08:30  <fanioz> how about the ttdpatch part ?
11:08:39  <Ammler> same of course
11:09:07  <Ammler> every nml function could have a properity min_version
11:09:19  <fanioz> even I don't know what version exactly it does support town name
11:09:21  <fanioz> it was 'borrowed' from french town :D
11:10:01  <Ammler> yep, last time we talked about this feature, we concluded not to care about pre 1.0 :-)
11:11:42  <fanioz> okay, since the other town-names grf have no platform checking, I would do the same :D, assuming no one use pre 1.0
11:12:28  <Ammler> yes, but do report it to nml, it might help in other cases
11:13:58  <Ammler> btw. is it the first time you work with branches?
11:14:50  <Ammler> you are the first guy using non-default branch for non-release :-)
11:14:58  <fanioz> yup, first time with hg too :D
11:15:50  <fanioz> just to show you that I'm coding :D
11:16:26  <Ammler> I don't care at all, we have already enough sleeping project, so this could hide quite well :-P
11:17:00  <fanioz> :D
11:17:07  <Ammler> it is just that the cf doesn't support building nightlies of non-default branches
11:17:25  <Ammler> (yet)
11:17:56  <planetmaker> <Ammler> anyway, testing for OpenTTD version should be done by nml directly <-- how so?
11:18:09  <planetmaker> As author one needs the option to specify a version
11:18:18  <Ammler> because the nml coder has no clue, which function needs which version
11:18:20  <planetmaker> Still, of course, it could be a one-line command. But that's for later
11:18:32  <Ammler> that should be done by nml
11:18:53  <planetmaker> Ammler, that's... really advanced. And some functions may be used but silently ignored
11:19:00  <planetmaker> An automatic check would fail
11:19:06  <Ammler> how?
11:19:07  <planetmaker> I could also work around that via if ... then ... else
11:19:14  <planetmaker> so what would NML do?
11:19:31  <Ammler> every function has a min-version properity
11:19:49  <planetmaker> Should for example SERails disable on OpenTTD < 1.0 just because it doesn't support rail types - while it's fine to use it as simple replacement?
11:19:54  <planetmaker> how would that work automatically?
11:20:09  <planetmaker> That'd need not only a lexical parser but a semantical one. MUCH harder
11:20:19  <planetmaker> Ammler, yes. Every function has
11:20:27  <planetmaker> But how to know whether missing function is crucial?
11:20:32  <planetmaker> Or guarded by ifs?
11:20:41  <Ammler> true, might be harder
11:21:09  <Ammler> then nml should maybe warn at building?
11:21:30  <Ammler> anyway, how shall a nml coder know, which ottd version is supported?
11:25:15  <fanioz> I've to say I'm sory for my bad, it was just a-not-yet-updated-english.lng, so it was not an NML bug but my brain bug
11:25:24  <Ammler> not sure, if it is good to support multiple ottd versions with one grf
11:25:46  <Ammler> how do you manage that in bananas?
11:26:44  <Ammler> you should people make aware, that updating openttd would make the grf look nicer...
11:28:35  <Ammler> fanioz: also you might not know, that nml supports parts >255, do you?
11:29:22  <fanioz> no, is that mean we don't need to split towns-file ?
11:37:57  <Yexo> fanioz: the error you see it most likely because STR_MIN_VERSION_OTTD is not in your language file
11:38:43  <planetmaker> Ammler, the coder has to know. As before
11:38:58  <planetmaker> And read up in the docs. Which mentions when features are available after 1.0
11:38:58  <Ammler> before what?
11:39:02  <fanioz> Yexo: you're right, thats because I've not 'hg up' the language
11:39:03  <planetmaker> as now
11:39:17  <Ammler> nml coder should not need to read nfo spec
11:39:31  <planetmaker> Ammler, no. But the NML docs tell
11:39:58  <Yexo> s/NML docs tell/NML docs will have to tell/
11:40:04  <Ammler> :-)
11:40:28  <Ammler> well, then why not make it with the compiler?
11:41:47  <Yexo> because of cases like swedishrails
11:41:58  <Yexo> that some function is not supported doesn't mean it can't be used at all
11:42:03  <Ammler> yes, which is a very special case, isn't?
11:42:38  <Yexo> not so sure
11:42:40  <Ammler> a warning might be suiffice
11:42:50  <Ammler> doesn't need to disable the grf
11:43:07  <Yexo> in which case nml coders will ask for a way to disable that warning (assuming it's openttd warning, not nml during the compile)
11:43:10  <Ammler> but a warning would also be nice for ser
11:43:45  <Yexo> and to disable that warning you'll need at least one line of code, which is the same amount if you ask the nml coder to specify the minimum version him/her self
11:44:11  <Ammler> the big difference is who needs to know the version :-)
11:45:00  <Yexo> adding a new option to nml to print the minimum version needed for all features a grf uses will solve that
11:45:31  <Ammler> you forgot the "?"?
11:46:02  <Yexo> no, it was a statement, not a question
11:46:10  <Ammler> so we agree :-)
11:46:33  <Yexo> not really, I say nml should only print the version needed to stdout/stderr, not the to grf file
11:46:47  <Yexo> if the coder wants to have a version check in the grf file he'll have to code it himself
11:47:05  <Ammler> well, a good start at least
11:47:10  <Yexo> whereas you seem to want nml to write the version check to the grf itself
11:48:02  <Ammler> I guess, making that a "ActionB" isn't much effort anymore :-)
11:48:24  <Ammler> the "work" is to have min_version for every feature
11:48:40  <Yexo> yes, indeed
11:49:00  <Ammler> I would start with 1.0 :-)
11:50:32  <Rubidium> 1.1 ofcourse... it needs action 14 :)
11:58:03  <planetmaker> :-)
11:58:29  <planetmaker> <Ammler> yes, which is a very special case, isn't? <-- that's not special at all
11:58:34  <planetmaker> I'd consider it quite common
11:58:47  <planetmaker> FIRS, 2cctrainset,...
11:58:55  <Ammler> how do I see what is used for lineend/newline in a txtfile?
11:59:37  <Ammler> FIRS does have code to behave different on different ottd versions?
11:59:57  <Rubidium> Ammler: file?
12:00:03  <planetmaker> every newgrf of some complexity
12:00:29  <planetmaker> Ammler, clustering code for industries
12:01:02  <Ammler> and that is captured with if clauses?
12:01:21  <Ammler> I thought, that is simply ignored by older openttd
12:02:09  <Ammler> like action14
12:02:32  <Ammler> > file towns_small.csv
12:02:33  <Ammler> towns_small.csv: UTF-8 Unicode text
12:03:08  <Ammler> unix or windos line end?
12:03:13  <Rubidium> if you add windows newlines that should change
12:03:54  <Rubidium> but according to file's manpage you're having unix newlines there
12:04:52  <Ammler> "with CRLF line terminators", nice
12:05:41  <planetmaker> <Ammler> I thought, that is simply ignored by older openttd <-- it is. But so are all new features
12:06:21  <Ammler> hmm, but why doesn't that work: sed "s/64\n/100\n/" towns_small.csv
12:06:53  <Brot6> Indonesian Town Names - Revision 9:8a5bd9bcac1e: [NML] -Added:: NML 'sprite' converted from .NFO ... (fanioz) @
12:07:12  <Ammler> saved with kate, there are no trailing whitespaces
12:08:01  <Rubidium> sed, by default, splits on newlines so you can't match them
12:08:10  <Rubidium> $ is used for end-of-line though
12:08:18  <Ammler> planetmaker: hmm, so again, why does firs need a if { ottd_version } then else?
12:08:46  <planetmaker> in order to apply possibly another algorithm instead?
12:08:59  <Brot6> Bundles Update: g34019149 2010-09-24 cargodist   (
12:09:03  <Ammler> yes, but it doesn't right?
12:09:04  <planetmaker> I think it doesn't. But _any_ feature will be ignored, if it's not present, Ammler
12:09:17  <planetmaker> OpenTTD will complain, but not fail, if it's in principle valid syntax
12:09:21  <Ammler> so, ser is still the only grf :-P
12:09:30  <planetmaker> I'd not bet on that
12:09:35  <Ammler> :-)
12:09:43  <Ammler> the only devzone grf
12:09:46  <planetmaker> Nope
12:10:16  <planetmaker> I'm quite sure 2cctrainset or nutracks does something along those lines, too
12:10:42  <Ammler> Rubidium: so obviously, thanks :-)
12:10:43  <Rubidium> missing features or variables isn't the biggest problem
12:10:52  <planetmaker> And still: FIRS is the prime example why a minimum version restriction should NOT apply based on a feature's introduction
12:11:00  <Rubidium> unknown properties, *that's* an issue
12:11:12  <planetmaker> aren't they ignored?
12:11:30  <Yexo> they can't, because when they're unknown their size is unknown too
12:11:47  <planetmaker> true
12:12:33  <planetmaker> hm. grf version 8: have a byte define the property size :-)
12:12:34  <Rubidium> planetmaker: yes, they're ignored... with all bits preceding and following it until the file's boundaries
12:12:42  <planetmaker> hehe
12:13:18  <planetmaker> would that make sense to store the property sizes in the grf?
12:13:28  <planetmaker> maybe just once? In a header?
12:13:47  <planetmaker> like 00 01 01 <-- feature 0, property 1: size 1 byte
12:14:02  <planetmaker> possibly only those which are used in the newgrf
12:14:31  <planetmaker> would be a compiler task then
12:15:07  <Rubidium> I doubt that'll ever be part of grfcodec
12:15:21  <planetmaker> what's wrong about that approach?
12:16:02  <planetmaker> It'd increase grf size, yes... but would make them readable by versions which don't support a property. Too much work for too little gain?
12:16:07  <Rubidium> grfcodec isn't a compiler, it's simply converting something somewhat readable into binary blob and back
12:16:29  <Ammler> if you use the town name grf in scenario editor, it seems like A is prefered...
12:16:38  <planetmaker> well, yes. But a quick file pass over the nfo could be done.
12:17:01  <Rubidium> planetmaker: but it's totally unaware of the meaning of stuff
12:17:02  <Ammler> I placed 10 town, no town with probability 100 yet
12:19:00  <Rubidium> if you put an action 25 into it with 0.5 byte properties in big endian GRFCodec will be totally fine with that
12:19:35  <Rubidium> GRFCodec has absolutely no idea of the context or meaning of stuff
12:20:17  <Rubidium> NFORenum has some clue, but inserting such metadata isn't a job of NFORenum. It just checks and renumbers; that's all
12:20:43  <Rubidium> it's more an nfolinter than something else
12:26:04  *** Froix has joined #openttdcoop.devzone
12:29:00  <Ammler> planetmaker: added andy to isr as manager, so we have someone to blame
12:32:27  <Froix> hey Ammler!
12:33:17  <Ammler> Sali Froix :-)
12:34:13  <Froix> ey! mind transferring my maglev track project to the proper subproject.
12:35:14  <planetmaker> Not at all. Did I miss to move it to track types?
12:36:05  <Froix> it was in zzpending. i got it off there but couldn't put it anywhere else
12:36:29  <planetmaker> done
12:36:54  <planetmaker> I guess it was in 'pending' as it didn't contain anything yet :-)
12:37:00  <Froix> yep
12:37:07  <planetmaker> So I take you're going to change it? :-)
12:37:14  <Ammler> hehe
12:37:44  <Froix> should have long ago. i kinda lost some of my work files on that project. faulty harddrive
12:37:54  <planetmaker> :-O
12:38:11  <Ammler> parent projects don't have influence of the subprojects
12:38:29  <Froix> so it's ok if i upload my layered gimp files as well right?
12:38:36  <planetmaker> sure
12:38:47  <Ammler> so you would also be able to work on a project sitting there
12:38:50  <planetmaker> they're your graphical 'source' after all.
12:39:23  <Ammler> we don't mind filling our harddisk
12:39:35  <planetmaker> :-D
12:39:38  <Ammler> just don't upload generated files :-)
12:39:41  <Brot6> Indonesian Town Names - Revision 10:162834db559b: [NML] -Change:: town generator script (fanioz) @
12:39:43  <Froix> :->
12:39:52  <Ammler> to the repo I mean
12:40:06  <Ammler> feel free to use files or docs for other files
12:40:15  <planetmaker> 337M    /home/ingo/.openttd/data
12:40:15  <planetmaker> 171M    /home/ingo/.openttd/content_download
12:40:15  <planetmaker>  <-- 500M is not that much nowadays :-)
12:40:55  <planetmaker> though ... ~/ottd looks larger ;-)
12:41:24  <planetmaker> 580M    /home/ingo/ottd/grfdev
12:41:35  <planetmaker> not that much
12:42:45  <planetmaker> where actually both OpenGFX and FISH each 50M each
12:42:51  <Ammler> 45124   worldairlinersset <-- biggest grf repo
12:43:14  <planetmaker> oh, yes, missed that. 71M
12:43:36  <planetmaker> FIRS: 46M, 2cctrainset: 42M
12:43:59  <Ammler> hmm
12:44:01  <Ammler> 1008    opengfx
12:44:12  <planetmaker> the trees only have 1M :-)
12:44:30  <Froix> haha what are in those? do they include sound files?
12:44:30  <planetmaker> Ammler, might not be totally clean repo sizes I post here
12:44:48  <planetmaker> Froix, no. Graphics source files ;-) Like *.psd or so
12:44:58  <Froix> aha! psd files
12:45:02  <planetmaker> And... all those sets have 10000s of sprites
12:45:22  <Froix> my pc can't possibly handle photoshop
12:45:28  <planetmaker> FIRS source code has of the order of 20000 lines
12:46:11  <Ammler> 25M     opensfx
12:46:43  <Ammler> well, I meant, ogfx is rather small
12:48:23  <planetmaker> cat firs.nfo | wc -l
12:48:24  <planetmaker> 48151
12:48:50  <planetmaker> cat 2cctrainset.nfo | wc -l
12:48:50  <planetmaker> 35001
12:49:30  <Ammler> Froix: gimp shouldn't have troubles with psd
12:49:38  <planetmaker> cat ogfx*.nfo | wc -l
12:49:38  <planetmaker> 16521
12:49:53  <Ammler> but ps has troubles wigh gimp files
12:50:12  <Froix> i made use of the example newgrf proj. do i need those .sh files?
12:50:16  * planetmaker considers buying PS CS5 now that I'm forced to be a student while graduating
12:50:44  <planetmaker> Froix, you shouldn't need them
12:50:48  <Froix> ok
12:51:10  <planetmaker> Basically look what you have in the trees repo. That's what you need in the maglev repo, too
12:51:10  <Ammler> planetmaker: those "student" licenses are like drugs ;-)
12:51:34  <planetmaker> Ammler, maybe. But I own the PS elements anyway :-)
12:51:50  <planetmaker> And... it's definitely something decent to treat photos with
12:52:04  <Ammler> I wonder, how the "eu" does allow that, but then forces ms to have such a stupid broswer choser at installation
12:52:23  <planetmaker> the normal price tag is prohibitive. The student price tag is not cheap. But kinda acceptable given the tools it contains
12:53:24  <Ammler> they should rather forbid those special discounts for schools
12:54:08  <Rubidium> Ammler: but Adobe isn't selling an OS with PS CS5 included
12:54:33  <planetmaker> why should they forbid those discounts, Ammler ?
12:54:36  <Rubidium> there isn't a choose "office suite" or "development enviroment" either
12:54:37  <Ammler> Rubidium: but suse does for example
12:55:47  <Ammler> planetmaker: because people use those tools in the uni and then become workers and ask for those software
12:56:10  <Rubidium> Ammler: but doesn't suse give a choice during the installation?
12:56:29  <planetmaker> Ammler, if other software would offer what I need at the same ease: I'd not buy it.
12:56:35  <planetmaker> I buy it for private reasons only
12:56:40  <Ammler> Rubidium: not really, I don't think debian does
12:57:13  <Rubidium> Debian does somewhat (you'd need to choose expert installation though)
12:57:21  <Ammler> planetmaker: but then you should pay as much as a company needs
12:57:35  <planetmaker> Ammler, obviously they don't need the full price
12:57:50  <planetmaker> And... I'd not pay the regular price. At 1700€ I'd do without
12:57:52  <Rubidium> Ammler: name me one produce where "cost == income"
12:58:33  <Rubidium> s/produce/product/
12:59:01  <planetmaker> It's a matter of how much a commodity may cost.
12:59:08  <Ammler> [14:57] <Rubidium> Debian does somewhat (you'd need to choose expert installation though) <-- yes, that complicated way it is with suse and in some ways it was with microsoft
12:59:32  <Rubidium> MS didn't provide multiple browsers
12:59:44  <Rubidium> Debian does
12:59:46  <Ammler> still doesn't
12:59:55  <Ammler> it just links you to the others
13:01:20  <Rubidium> e.g. it installs epiphany and iceweasel, and neither is Debian's product
13:01:39  <Ammler> yes, and what if I like Firefox?
13:01:53  <Rubidium> then you have to get the binaries from Firefox
13:02:05  <Ammler> same as MS :-)
13:02:09  <Rubidium> although iceweasel = firefox without branding and with backported fixes
13:02:54  <Rubidium> Ammler: but MS is pushing *one* browser that's totally integrated into the OS, which is something totally different than having the choice of multiple browsers
13:02:59  <planetmaker> what's the reason for iceweasel to exist (except 'just because')?
13:03:13  <Rubidium> planetmaker: to backport bug fixes
13:03:47  <Rubidium> oh, and to use system libraries instead of the ones Mozilla thinks are best
13:03:47  <Ammler> isn't firefox somewhat protected and therefor debian can't use it?
13:04:09  <Ammler> the label I mean
13:04:27  <Rubidium> yes, if you modify the source code for any reason you can't use Firefox
13:04:38  <planetmaker> it doesn't have gpl but the moz license...
13:05:15  <Ammler> I wonder, why suse or other dists still use firefox
13:05:49  <Rubidium> Ammler: because they just package old and buggy or latest whenever there're firefox bug fixes
13:06:32  <andythenorth> I don't know why FIRS *does* have a minimum ottd version.
13:06:36  <andythenorth> maybe I added it but I doubt it
13:06:45  <andythenorth> do the commit logs have anything useful to say?
13:07:16  <Ammler> andythenorth: my experience is that on tickets, foobar reaction is very fast :-)
13:08:26  <Ammler> I have FF 3.6.10 from official repo
13:08:55  <Rubidium> Ammler: does APNG work for you?
13:09:11  <Ammler> any url?
13:09:21  <Rubidium>
13:09:32  <Ammler> hmm, 3.6.10 is also latest on
13:10:33  <Rubidium> <- there...
13:10:35  <Webster> Title: APNG - Wikipedia, the free encyclopedia (at
13:10:41  <Ammler> Rubidium: the logo is simply png
13:10:49  <Rubidium> Ammler: no, it's APNG
13:11:11  <Ammler> ah, doesn't have special extnesion
13:11:15  <Ammler> yes, it works
13:11:22  <Ammler> the APNG from wikipedia
13:11:26  <Rubidium> so then you're having at least two libpngs installed
13:12:34  <Ammler> libpng-devel-1.2.39-2.4.1.i586
13:12:35  <Ammler> libpng12-0-1.2.39-2.4.1.i586
13:12:38  <Ammler> doesn't look like
13:12:45  <Brot6> SMITS - Revision 0:8860b2edb941: Change: Adding source files. (Froix) @
13:12:58  <Rubidium> Ammler: ofcourse not, one is only available for Firefox
13:13:07  <Rubidium> i.e. the one that supports APNG
13:13:07  <Ammler>
13:13:32  <Rubidium> i.e. your other browsers don't support APNG (at least if they're using your system's libpng)
13:13:43  <planetmaker> meh. that lib highlighted me :-P
13:15:37  <Froix> nightly r0 :)
13:16:01  <Froix> that is if i don't touch it til tomorrow
13:16:23  <planetmaker> :-)
13:17:18  <planetmaker> Rubidium, btw, your hint to pass the repo version as parameter via gcc in NML projects was a good idea :-)
13:18:54  <Ammler> hmm, so you withdraw the idea to use custom_tags?
13:19:06  <planetmaker> no
13:19:24  <planetmaker> but it's a solution which works now. Without spending much brain on it ;-)
13:30:47  <Froix> there's a 4gb fixed partition on my HD. i wonder if any of you guys know how i could free that
13:31:29  <planetmaker> that grossly depends on your OS, the tools available and your daring ;-)
13:31:33  <Froix> i'm guessing it's where the embedded windows xp os used to reside
13:31:59  <planetmaker> IIRC knoppix comes with some nice partioning tool.
13:32:00  <Froix> acronis can't do anything about it
13:32:21  <Froix> i'll check that out
13:35:04  <Terkhen> Ammler: with swedish rails, the MD5 sum matches this one (
13:35:24  <Ammler> cool :-)
13:35:49  <Terkhen> I still get that "Incorrect command line error" in swisstowns, though
13:35:49  <Ammler> you don't mind to build a town names grf?
13:35:55  <Ammler> he :-)
13:36:50  <Ammler> then the makefile is fine, as I don't use it there
13:40:16  <Ammler> Froix: "OpenTTD (Windows palette compatible) DL Here" <-- how do I get a doc palette compatible openttd? ;-)
13:40:20  <Ammler> dos*
13:41:22  <Terkhen> Ammler: the error is that I'm missing 7za
13:41:34  <Ammler> well, but the grf is thee
13:41:44  <Ammler> can md5sum it and compare with bundles
13:41:46  <Froix> :-) i take it openttd is just windows palette?
13:41:53  <Ammler> no, it isn't
13:42:00  <Ammler> it handles both quite fine
13:42:04  <Froix> ah
13:42:15  <Ammler> trunk uses dos openttd.grf only
13:43:03  <Terkhen> Ammler: they are different
13:43:21  <Ammler> ok, same as I had then :-(
13:43:50  <Ammler> diffing the nfo shows that sprites are switched
13:44:03  <Ammler> I guess, the final grf would behave the same
13:44:22  * Froix slaps Froix around a bit with a large fishbot
13:44:29  <Froix> nice
13:44:33  <Ammler> I think, it has to do with the UTF-8
13:44:52  <Terkhen> maybe awk or other comand is behaving differently in msys for some reason
13:45:15  <Ammler> the nml is the same
13:45:19  <Ammler> isn't?
13:47:23  <Terkhen> hmm... I get a different md5sum in linux too
13:48:45  <Terkhen> the nml are the same, yes
13:49:14  <Ammler> so only nmlc does differ
13:49:36  <Ammler> Terkhen: different python versions?
13:50:12  <Terkhen> 2.7 in windows, 2.6.5 in linux... but I thought that shouldn't matter
13:50:33  <planetmaker> it might.
13:50:46  <Ammler> well, as the difference is only in townnames, it might be something special in that part
13:51:21  <Ammler> you could try airportplus for another nml example
13:52:00  <planetmaker> the question is: what? :-)
13:52:07  <planetmaker> or ogfx+trains
13:52:22  <Ammler> does ser build the nfo?
13:52:34  <Ammler> maybe it differs, if you build nfo too?
13:52:35  <planetmaker> not by default. But you can easily do that manually
13:53:02  <Terkhen> heh
13:53:19  <Ammler> Terkhen: can you remove the nfo part from nmlc and check the grf then?
13:53:45  <Ammler> nah
13:53:50  <Terkhen> for swedish rails, in windows I get no md5 file, in linux the file is present but the md5 is wrong
13:53:52  <Ammler> forget it
13:54:02  <planetmaker> hu, Terkhen ?
13:54:07  <Terkhen> if I use md5sum manually, I get the same md5 in both
13:54:12  <planetmaker> ah
13:54:27  <planetmaker> but different from the one automatically obtained?!
13:54:32  <Terkhen> yes
13:54:40  <planetmaker> :-O
13:54:46  <Ammler> check timestamp
13:55:02  <Ammler> maybe it is an old file and also not built now
13:55:10  <planetmaker> how is your md5sum file called, Terkhen ?
13:55:45  <Terkhen> swedishrails-nightly.md5
13:55:53  <planetmaker> hm
13:56:08  <planetmaker> and it's contents differs from md5sum swedishrails.grf?
13:56:58  <planetmaker> hm... I think the md5 is not built by default
13:56:59  <Terkhen> it must be from a previous version; I deleted it and it is not being generated again after make
13:57:06  <planetmaker> yes
13:57:34  <planetmaker> only if you build a bundle
13:58:31  <Terkhen> okay, now it's looking better :)
14:00:36  <Terkhen> I have no clue about the town grf problem; either it is a problem with python version or a msys problem
14:02:57  <planetmaker> or one of the bash script ;-)
14:17:12  <Ammler> planetmaker: how so? if the nml is the same and the bash only does nmlc ...
14:17:54  <Ammler> you don't need to use bash at all, you can run nmlc
14:21:53  <planetmaker> :-) Ok, then it's indeed an oddity in msys probably.
14:22:06  <planetmaker> Are also the line endings the same? e.g. both unix style?
14:24:22  <Terkhen> the script does not have that problem, the resulting nml file is in unix style
14:27:57  <Froix> dang!  i missed my main pnfo. there goes my nightly r0
14:28:14  <planetmaker> :-D
14:28:29  <Froix> i think i messed up with hgignore, tortoise ignored it
14:29:34  <Froix> *ignores
14:30:17  <planetmaker> you only want to ignore mynewgrf-*
14:30:21  <planetmaker> mind the "-"
14:30:31  <Froix> i see
14:30:36  <planetmaker> maybe also mynewgrf.nfo
14:30:44  <planetmaker> but not *nfo :-)
14:30:55  <planetmaker> or mynewgrf.* neither
14:33:00  <Ammler> [16:21] <planetmaker> Are also the line endings the same? e.g. both unix style? <-- md5sum would detect that
14:34:23  <Ammler> someone knows Vyatta?
14:34:33  <Ammler> I might install that on our server
14:35:24  <planetmaker> looks like a random assortment of letters to me
14:35:31  <Brot6> SMITS - Revision 1:b20f18b7e27d: Add: missing file - smits.pnfo (Froix) @
14:38:13  <Ammler> I still think, easiest would be, If I could assign 192.168er address to the host
14:38:38  <Ammler> but I have no idea, how to do that with XenServer
14:42:00  <planetmaker> <-- like that, Ammler ?
14:42:05  <Webster> Title: Xen mit Routing und Bridge – Hetzner DokuWiki (at
14:42:21  *** thgergo has joined #openttdcoop.devzone
14:42:55  <Ammler> hmm, I learned a lot, maybe I could go back and try Xen again?
14:44:22  <Ammler> installing new server etc. is just so easy with XenServer
14:44:22  <planetmaker> hm... what is it now, if not xen?
14:44:29  <Ammler> XenServer
14:57:26  *** Alberth has joined #openttdcoop.devzone
15:04:21  <Brot6> 2cc train set - Feature #1544 (New): 2-8-0 Consolidation (Voyager1) @
15:07:07  <fanioz> Illegal character '#' at "input", line 1  <---------- could be fixed with dos2unix the file before processed by nmlc
15:07:25  <fanioz> only on msys :D
15:07:38  <Rubidium> then it's actually failing on \r it seems :)
15:08:54  <Brot6> 2cc train set - Bug #1538: r615 new engines missing or wrong (Voyager1) @
15:10:13  <fanioz> yup
15:11:29  <fanioz> so, which one is easiest, fix the make file, or fix the nmlc :D
15:11:50  <Rubidium> the former
15:11:54  <Rubidium> the latter is better though
15:13:16  <Ammler> former doesn't fix my bash projects :-)
15:14:16  <Rubidium> nml's regression test's still failing for me
15:15:38  <Rubidium> <- is that worth filing a bug report?
15:16:47  <Yexo> not anymore
15:17:20  <Yexo> it doesn't fail here though
15:18:30  <Yexo> oh, it's that issue :(
15:23:45  <fanioz> [msys] unix2dos --dos2unix  unix2dos: cannot accept any conversion type argument other
15:23:46  <fanioz>   than --u2d (--unix2dos, -D) when the program is called with this name
15:26:23  <Yexo> Rubidium: can you pull and test if it works now?
15:27:23  <Alberth> a set that messes up the order?
15:27:24  <Brot6> NewGRF Meta Language - Revision 796:d569bd9ddb6a: Fix: sort action4's by language id before addin... (yexo) @
15:27:32  <Rubidium> make in regression doesn't fail anymore
15:27:47  <Yexo> great
15:28:03  <Yexo> Alberth: most likely it's not the set but the order the language files are read
15:28:16  <Yexo> it does something like "lang/*.lng" so the order is probably defined by the os
15:28:31  <Alberth> a nice other form of randomness :)
15:32:20  <Brot6> Example NewGRF Project - Feature #1545 (New): update script to allow others updating their projec... (Ammler) @
15:33:37  <Brot6> Example NewGRF Project - Feature #1545: update script to allow others updating their projects self (Ammler) @
15:33:51  <Rubidium> Yexo: more likely the file system
15:34:15  <Yexo> true, in any case "something outside of nml's control"
15:35:04  <Ammler> planetmaker: you set me as dev to the newgrf_makefile, but I actually never committed something and wouldn't feel comfortable to do now ;-)
15:36:30  *** frosch123 has joined #openttdcoop.devzone
15:37:03  <Ammler> else I would for example commit the ttdp mod :-P
15:38:26  <Terkhen> hmm... from what I read, opening the nml file with "rb" or "rU" instead of "r" would solve the eol issue in windows, but it does not work
15:42:43  <Ammler> Yexo: it results in different md5sum, so it is an issue
15:43:31  <Yexo> Ammler: what does?
15:54:35  *** thgergo has quit IRC
15:54:52  *** thgergo has joined #openttdcoop.devzone
15:57:20  <Ammler> nml output the sprites in other order
15:57:45  <Ammler> oh, you fixed it already :-)
16:11:30  <Brot6> grfcodec: update from r768 to r771 done -
16:13:25  <Brot6> nml: update from r795 to r796 done -
16:19:52  <Brot6> newgrf_makefile: update from r217 to r218 done -
16:20:02  *** fanioz_ has joined #openttdcoop.devzone
16:21:15  <Brot6> Example NewGRF Project - Revision 219:2a661407ef01: Change: More sophisticated update script whic... (planetmaker) @
16:21:32  *** fanioz__ has joined #openttdcoop.devzone
16:21:56  <Brot6> nforenum: update from  to r506 done -
16:22:14  *** fanioz__ has quit IRC
16:22:31  <Brot6> ogfx-trees: update from r26 to r30 done -
16:23:07  <Brot6> smts: update from  to r1 done (4 errors) -
16:23:17  <Brot6> Example NewGRF Project - Feature #1545: update script to allow others updating their projects self (planetmaker) @
16:23:24  <Froix> ouch
16:23:32  *** fanioz has quit IRC
16:23:48  <Ammler> that isn't much for a first compile :-)
16:24:02  *** fanioz has joined #openttdcoop.devzone
16:24:22  <Brot6> ttrs: update from r22 to r23 done (7 errors) -
16:24:25  <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r615), 32bpp-extra (r39), ai-admiralai (r68), airportsplus (r63), basecosts (r22), belarusiantowns (r7), comic-houses (r71), firs (r1402), fish (r394), frenchtowns (r4), grfcodec (r771), heqs (r376), metrotrackset (r56), nml (r796), nutracks (r117), ogfxplus (r42), opengfx (r546), openmsx (r97), opensfx (r97), snowlinemod (r45), swedishrails (r182), swisstowns (r19),
16:24:25  <Brot6> transrapidtrackset (r15), ttdviewer (r25), worldairlinersset (r664)
16:29:36  <Ammler> Froix: you don't have those errors local?
16:30:30  <Ammler> looks like is missing a +x
16:32:00  <Froix> no, i don't get any errors local
16:32:23  <Ammler> you has +x?
16:33:22  <Froix> where do i look for that?
16:34:12  <Ammler> ls -l scripts/
16:35:54  <planetmaker> hm
16:36:57  <planetmaker> Ammler: maybe the update script you wrote should use install instead of cp and set permissions accordingly? :-)
16:37:13  <Ammler> quite easy to update :-)
16:37:27  <planetmaker> Did you see also my comment to the ticket?
16:37:28  <Ammler> but Froix didn't use it
16:37:38  <planetmaker> nope. Wasn't there then ;-)
16:37:57  <Ammler> hmm, but I use cp -p here
16:38:08  <planetmaker> I'm still thinking also of how to deal with it that a ready-to-use bundle of the makefile is generated.
16:38:13  <Ammler> so yes, might be better to use cp -p or install
16:38:34  <planetmaker> maybe I move everything one level down.
16:40:00  <planetmaker> then make bundle_zip would only pack what is needed for other projects
16:40:24  <planetmaker> releases of the whole repo are anyway pointless
16:40:47  <Ammler> well, you can make a :-)
16:41:32  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: 2cctrainset (7 errors), 32bpp-extra, airportsplus, basecosts, belarusiantowns (3 errors) (Diffsize: 21), comic-houses (3 errors) (Diffsize: 13), firs (1 errors), fish (4 errors), frenchtowns (4 errors) (Diffsize: 9), heqs, metrotrackset (Diffsize: 1), nutracks (2 errors), ogfxplus (Diffsize: 6), opengfx (Diffsize: 1), snowlinemod, swedishrails,
16:41:32  <Brot6> swisstowns (Diffsize: 21), transrapidtrackset (Diffsize: 12), worldairlinersset
16:41:39  <Brot6> Example NewGRF Project - Bug #1449: Compiling under MinGW/MSYS (fanioz) @
16:42:10  <Ammler> Froix: anyway fix for your issue is chmod +x scripts/
16:42:40  <Froix> ok. just trying out this msys shell for the first time. i never really use the damn thing :)
16:42:56  <Ammler> hehe
16:42:57  <Alberth> Terkhen: "rb" open for binary reading (ie no EOL interpretation), how is that going to remove \r ?
16:43:28  <planetmaker> Ammler: not really. I can add new rules. But not alter existing
16:43:40  <Terkhen> I don't know, I was blindly following the documentation of open
16:43:51  <Terkhen> U should, if I understood it correctly
16:44:04  <Ammler> planetmaker: well, new target doesn't hurt
16:44:15  <Ammler> make update_bundle
16:44:25  <Ammler> bundle_update :-)
16:46:06  <Ammler> also maybe the Makefile could write the .devzone config too?
16:46:08  <Alberth> Terkhen: "... If Python is built without universal newline support a mode with 'U' is the same as normal text mode. ..."
16:47:43  <Terkhen> hmmm... if I does not work would that mean that python default binaries for windows are built without universal support?
16:47:59  <Terkhen> if it*
16:49:13  <Alberth> perhaps, no idea how to check the Python build options
16:49:54  <Terkhen> if it isn't, there is not much that can be done to solve this, since python can't be built with msys
16:51:16  <Alberth> the point is, \r should never get read by an application, by opening in text mode, the C library should translate the OS new-line convention to \n (and the other way around when writing).
16:52:12  <planetmaker> Alberth: would something like sed "s/\r//" solve the issue?
16:52:13  <Alberth> these problems typically happen when files are copied binary between platforms
16:52:34  <Alberth> planetmaker: that's what dos2unix does, basically
16:52:39  <Terkhen> isn't that what universal newline support is supposed to do for python?
16:53:03  <Terkhen> or do you mean the standard library?
16:53:52  <Ammler> what does openttd do, if the town randomizer uses the same name again?
16:54:35  <Ammler> but I am not able to get so many
16:54:45  <fanioz> "<stdin>", line 47: Dropping town name piece with 0 probability.  <--------- NML source at     what is it ?
16:54:58  <Alberth> C library?  that's    /lib/    or something in that direction (ie what gcc links against)
16:55:38  <Alberth> fanioz: having a name with 0 probability to be chosen is not very useful to keep arounf
16:55:42  <planetmaker>     text("dummy", 0)
16:55:43  <Ammler> fanioz: you are looking at a old nml project :-)
16:55:45  <Alberth> *around
16:56:01  <fanioz> :D
16:56:12  <Ammler> portuguese or swisstowns are newer
16:56:19  <Ammler> with >255 parts
16:57:25  <Alberth> Ammler: I didn't check the source, but it seemed to me that it skips town creation if you get the same town name again
16:57:48  <Terkhen> the versions of python found at the official site are probably built with MSVC
16:57:55  <Alberth> I once tried my GRF with 144 names, and I got 144 cities at 2Kx2K
16:58:23  <Ammler> you don't use probability from 1 to 100 :-)
16:58:41  <Alberth> Terkhen: that would be a quite logical choice
17:16:26  <Ammler> fanioz: a clause that dos2unix will only be used in mingw
17:17:03  <fanioz> true
17:17:15  <planetmaker> I'm really missing context...
17:17:50  <Ammler> planetmaker: nmlc can't handle "dos files" :-)
17:18:21  <planetmaker> so... should I add such statement? Just parse the nml through dos2unix?
17:18:34  <planetmaker> could even be done no-matter-what. Though that'd be a bit ugly
17:18:44  <planetmaker> maybe just for windoze :-)
17:18:45  <Ammler> :-)
17:19:03  <Ammler> well, I would prefer a solution for nmlc
17:19:15  <planetmaker> so do I
17:19:23  <fanioz> [Makefile.def] if there is no 'dos2unix' command, it would simply ignore. isn't it?
17:20:13  <Ammler> can't you use unix2dos also the other way?
17:21:27  <Terkhen> in msys it is called d2u and u2d
17:21:41  <Terkhen> at least for me
17:22:04  <Terkhen> heh, dos2unix works too, forget what I said
17:22:35  <fanioz> in 'my' msys unix2dos would only accept --u2d only
17:22:44  <fanioz> not with --d2u
17:37:14  <Froix> later guys
17:37:22  *** Froix has quit IRC
17:41:43  <Terkhen> fanioz: use dos2unix instead of unix2dos
17:42:43  <fanioz> proposed: :D
17:46:45  <Alberth> pondered about the problem while doing shopping
17:47:04  <Alberth> iirc, the file is loaded with
17:47:26  <Alberth> perhaps U support only happens with reading lines?
17:50:54  <Yexo> nml works fine under cygwin with both dos and unix line endings
17:51:46  <Terkhen> for me it failed both under cmd and msys... does it work under cmd for you?
17:52:59  <Yexo> it can't find ply in that case
17:54:12  <Alberth>  perhaps?
17:55:03  <fanioz> cmd - failed to compile on me too
17:55:28  <Alberth> alternatively, we may want to implement a template mechanism :)
17:57:24  <Yexo> Alberth: if that works it's fine
17:57:34  <Yexo> perhaps not the nicest solution, but ok
17:58:11  <Alberth> Yexo: it seems the trouble is with # lines (probably from the C pre-processor)
18:01:46  <Terkhen> Alberth: <-- now it gives this error... 639 is the last line of src/railtypes.pnml (just an empty line), which is also the last file included at the generated nml file
18:03:06  <Brot6> 32bpp-ez-patches: update from r20839 to r20842 done -
18:03:10  <planetmaker> you have another se rails version than I do ;-)
18:04:00  <Alberth> Hmm, it needs an additional \n at the end then.    What if you add a     + "\n"         at the end ?
18:04:06  <Terkhen> or I understood the nml file incorrectly :P
18:04:07  <Terkhen> let's see
18:04:34  <Alberth> although it is extremely hacky imho
18:05:47  <Brot6> clientpatches: update from r20839 to r20842 done -
18:06:24  <Alberth> it needs a cleaner solution
18:09:45  <Terkhen> Alberth: script = "\n".join(line.rstrip() for line in inputfile) "\n" <-- like this? mind that I don't know python at all :)
18:10:17  <Alberth> script = "\n".join(line.rstrip() for line in inputfile) + "\n"
18:10:43  <Terkhen> right, I was thinking on diff format and ignoring the +
18:10:57  <Alberth> although all devs should know Python as a matter of principle   :p
18:11:34  <planetmaker> :-P
18:12:27  <Terkhen> with that diff to nmlc, swedish rails builds fine under msys and the md5sum is the same than the one at the bundles page
18:12:43  <Terkhen> but even without knowing python the solution looks hackish to me
18:12:58  <Alberth> yep, very hacky
18:13:10  <Terkhen> learning python is one of those projects I'm always postponing :)
18:13:26  <Rubidium> sssssssssssssssss
18:13:34  <Alberth> next time, I won't give you a solution :)
18:13:49  <Terkhen> fair enough ;)
18:14:02  <planetmaker> sSSSSss. ssS
18:14:02  <Rubidium> python's the thing I'm always trying to avoid for hysterical reasons
18:14:09  * andythenorth likes python
18:14:18  <andythenorth> that's probably enough to warn some of you off it :)
18:14:52  <Rubidium> python on highly embedded device without a proper emulator == bad
18:14:59  <Rubidium> (or compiler)
18:15:32  <Alberth> 'highly embedded device' make it sound like a bad idea already
18:15:46  <Rubidium> did write something 200 SLOC-ish, took 30-45 minutes to get it compiled on the device
18:16:22  <Rubidium> then to figure out that the python on the device is still the stripped down one that just doesn't like X, Y or Z
18:16:40  <planetmaker> can anyone give me a hint why the flatbed wagon has so funny stats in toyland climate with opengfx+trains r11?
18:16:48  <planetmaker> I don't understand the behaviour at all...
18:17:01  <Brot6> serverpatches: update from h72c89b58 to h59412ac8 done (2 errors) -
18:17:03  <planetmaker> It seems to work in the other climates, but... toyland throws up
18:17:41  <Alberth> Rubidium: argh
18:19:22  <Rubidium> and it did have GPS and GSM, neither which worked reliably in some way
18:19:48  <Rubidium> if either starts to malfunction the only solution to seemed to be remove power for 15 minutes
18:19:57  <Alberth> that sounds like a useful device :p
18:20:05  <Rubidium> yeah... piece of crap
18:20:23  <Rubidium> so, that's why I don't quite like python as it makes me thing of that
18:21:29  <Alberth> a pity, but understandable
18:23:02  <Alberth> Yexo: any plans/ideas for an incusion/template mechanism in NML?
18:23:27  <Yexo> not yet
18:23:41  <Alberth> (so we can convince ours users to stop using other pre-processors ;) )
18:24:54  <planetmaker> meh, Rubidium :-)
18:26:17  <Alberth> Yexo:  building a C pre-processor is not that difficult, but perhaps we want something better? (no idea what though, especially for the #define part).
18:26:34  <Rubidium> should I do that trick here as well? Will make my IRC client a lot more "silent"
18:26:49  <Rubidium> hmm, no I can't... too bad
18:27:12  <planetmaker> he
18:28:23  *** Rubidium has left #openttdcoop.devzone
18:28:32  <Yexo> Alberth: maybe not difficult, but why would we want to write our own preprocessor?
18:29:29  <Alberth> requiring serious users to use a 3rd party one is not that nice imho
18:37:09  <frosch123> hmm, if there are steam diesel and sail liveries for ships... does a hovercraft livery make sense?
18:38:37  <andythenorth> frosch123: maybe
18:38:40  <andythenorth> but how far to go?
18:38:43  <andythenorth> hydrofoil livery?
18:38:52  <andythenorth> ekranoplan livery?
18:39:08  <frosch123> :p
18:39:32  * andythenorth ponders
18:39:50  <andythenorth> is there a generic class that would describe hovercraft, hydrofoil?
18:39:58  <frosch123> well, if we hide liveries without any associated vehicles?
18:40:00  <Brot6> FIRS Industry Replacement Set - Revision 1403:3d15c0f7521f: Feature (unfeature): hidden Wholesale... (andythenorth) @
18:40:00  <Brot6> FIRS Industry Replacement Set - Feature #462 (Closed): Remove Wholesale Market from firs.pnfo (andythenorth) @
18:40:15  <frosch123> andythenorth: don't mention "drive on land"
18:40:19  <andythenorth> :)
18:40:24  <andythenorth> I liked that patch of yours
18:40:30  <andythenorth> shame it crashed the game
18:41:12  <frosch123> what do you expect from a "oh, this prevents stuff from going on land, lets comment it out"-patches?
18:41:24  <andythenorth> personally I don't want to be micro-managing colour settings
18:41:26  <andythenorth> but others might
18:41:54  <frosch123> we also have monorail and maglev liveries...
18:41:57  <andythenorth> sail / steam / diesel / hovercraft / hydrofoil
18:42:01  <andythenorth> oars?
18:42:02  <frosch123> and dmu and emu
18:42:09  <andythenorth> nuclear
18:42:16  <andythenorth> any other common ship types?
18:42:22  <andythenorth> I think we can ignore, e.g. chain ferry
18:42:24  <frosch123> common?
18:42:59  <frosch123> andythenorth: if you start like that we should add newgrf defineable livery classes :p
18:43:07  <andythenorth> like labels and such?
18:43:11  <andythenorth> brrr
18:43:20  <andythenorth> nice, but is it needed?
18:43:27  <andythenorth> :P
18:43:35  <frosch123> anyway, let's see how easy it is to hide liveries from the gui without any vehicles
18:43:49  <Alberth> Terkhen:   a less hacky solution, could you please try that instead?
18:43:52  <Webster> Title: Paste #266833 | LodgeIt! (at
18:44:32  <andythenorth> for generic shops (used in town)...."Store" or "Market" ?
18:44:47  <frosch123> andythenorth: well, if you want liveries for certain vehicle types, it is silly if you have liveries for monorail and maglev, but none for metro
18:45:08  <andythenorth> go by rail type labels?
18:45:22  <frosch123> there are neither steam nor diesel rails
18:45:32  <andythenorth> hmm
18:45:34  <andythenorth> I dunno
18:45:37  <frosch123> nor dmu or emu rails :p
18:45:52  <frosch123> or passenger and freight rails :p
18:45:55  <andythenorth> for practical purposes, steam / diesel / sail covers ship needs
18:46:00  <andythenorth> I'm not doing any rowing boats
18:46:02  <andythenorth> nor nuclear
18:46:12  <andythenorth> I don't personally care about hovercraft liveries
18:46:16  <frosch123> but there is a hovercraft in the original game
18:46:25  <frosch123> shile there is no sailing stuff
18:46:28  <andythenorth> it's just a ferry imo
18:46:36  <andythenorth> it's a ferry that hovers :)
18:46:42  <Alberth> nuclear are used in underwater submarines, trivial to draw  :)
18:46:52  <andythenorth> already drawn?
18:47:00  <andythenorth> or was that TTO only?
18:47:09  <frosch123> there are also mobile nucler power plants in ships
18:47:30  <andythenorth> frosch123: what would your proposed list be ?
18:47:39  <Alberth> but not in ships allowed in OpenTTD probably
18:47:51  <andythenorth> nuclear icebreakers...
18:48:12  <Alberth> luckily we don't have ice :)
18:48:21  <andythenorth> we could
18:48:27  <andythenorth> if someone coded it :)
18:48:33  <andythenorth> water types
18:48:47  <andythenorth> anyway, I'd take a few ship liveries and be happy :)
18:48:51  <frosch123> andythenorth: i guess i'll go for "hide stuff from the gui which is not available" and then hirundos 3 classes. i do not care enough about those colours to code livery classes :)
18:49:21  <andythenorth> sail / steam / diesel / other
18:49:35  <andythenorth> other == whatever grf authors want to be awkward about
18:55:18  * andythenorth thinks "Store"
18:55:43  <Terkhen> Alberth: it works fine
18:56:07  <Alberth> and it looks way better, thanks for testing
18:57:17  <Terkhen> thank you for the fix :)
18:58:32  <andythenorth> Terkhen: so if I change just a string....I don't need to do anything particular?
19:00:24  <Brot6> FIRS Industry Replacement Set - Revision 1404:b5aca31728a8: Feature: General Store renamed to Store (andythenorth) @
19:01:03  <Brot6> NewGRF Meta Language - Revision 797:4d92f826f7a0: Fix: Silently eat CR characters of C pre-proces... (Alberth) @
19:02:30  <Terkhen> andythenorth: let's test the script :)
19:06:59  <Terkhen> andythenorth: "TEXT_IND_GENERALSTORE (Original: 1404, Translation: 1350)" <-- the script gives a warning about the changed string, the translator only have to get the output and check the changed strings and correct them accordingly
19:07:23  <Terkhen> this method is kind of hacky, but useful
19:08:38  <andythenorth> ok great :)
19:14:39  <Terkhen> hm, what's the correct grouping for TEXT_IND_ strings?
19:15:37  <andythenorth> Terkhen: alphabetical
19:16:07  <Terkhen> I mean... IIRC they were in groups of 5 before
19:16:24  <andythenorth> I found it easier to make them alphabetical
19:16:29  <andythenorth> for me in English anyway :P
19:16:36  <andythenorth> dunno about for translators!
19:19:21  <planetmaker> :-O you changed that? :-(
19:19:33  <planetmaker> did you change the translations, too?
19:20:33  <Brot6> OpenGFX+ Trains - Revision 12:7d58c94cc506: Change #1528: Let the flatbed wagon use new sprites (planetmaker) @
19:21:33  <Terkhen> <---I mean something like this
19:24:17  <Brot6> OpenGFX+ Trains - Revision 13:a209b9a54100: Change: Use spaces instead of tabs for indentation (planetmaker) @
19:26:30  <Brot6> OpenGFX+ Trains - Revision 14:73b3a4ce6077: Fix: Remove outdated and wrong comments (planetmaker) @
19:31:17  <Brot6> OpenGFX+ Trains - Revision 15:34b14c702e4f: Fix: Usage of some CTT entries was indicated wrongly (planetmaker) @
19:37:01  <andythenorth> planetmaker: no I didn't change translation
19:37:29  <planetmaker> hm... so we again have to re-sort there everything, too
19:38:33  <andythenorth> :)
19:39:05  <planetmaker> dead boring, I say :-(
19:39:11  <andythenorth> don't bother :)
19:39:16  <Alberth> for f in *.lng ; do cp $f tmp ; sort < tmp > $f; done
19:39:20  <Ammler> well, if it is alphabetical, just sort
19:39:24  <andythenorth> wait a minute...
19:39:52  <Alberth> hmm, first lines get messed up then?
19:39:56  <planetmaker> hm, true, Ammler :-)
19:40:03  <planetmaker> very good point ^ andythenorth
19:40:17  <andythenorth> it's only for readability
19:40:31  <andythenorth> I did it for my own convenience, if it doesn't work for others, don't bother :)
19:40:55  <Brot6> FIRS Industry Replacement Set - Revision 1405:37f41a50f0e2: Cleanup: lang 7F defines - couple of ... (andythenorth) @
19:41:20  <planetmaker> andythenorth: anything works. But the language files kinda need the same ordering.
19:41:29  <planetmaker> So it means to re-order all - or none
19:41:57  <planetmaker> besides, I think some strings are missing from the remove_defines. Is that right?
19:42:05  <andythenorth> so I only ordered the industry names...I should do the rest of the file?
19:42:09  <Ammler> vyatta nat :-)
19:42:19  <Ammler> but still no ipv6 :-)
19:42:37  <Ammler> I have no clue, how to configure that, something for later...
19:43:12  <planetmaker> andythenorth: not sure... Industries certainly is sensible :-)
19:43:20  <andythenorth> cargos is out of order too
19:43:23  <andythenorth> might do that
19:43:26  <andythenorth> it's brainless :)
19:43:29  <planetmaker> :-P
19:43:31  <andythenorth> and it's friday today
19:43:55  * andythenorth I doing a bubble sort :P
19:43:59  <andythenorth> manually
19:47:44  <Terkhen> a final sorting would be nice; my script would stop displaying false "modified strings"
19:47:58  <andythenorth> watch the next commit...
19:48:48  <Brot6> FIRS Industry Replacement Set - Revision 1406:6793b66d821a: Cleanup: reordered cargos in 7F lang ... (andythenorth) @
19:50:20  * andythenorth ponders
19:55:43  <andythenorth> combined lime + potash kilns
19:57:22  <andythenorth> in wood, stone, coal.  Out: chemicals, building materials
19:57:27  <andythenorth> or FMSP
20:05:56  * andythenorth thinks lime kiln is useful
20:06:03  <andythenorth> stone & coal in, chemicals out
20:06:15  <andythenorth> wonder how much it overlaps with cement plant :P
20:07:28  <andythenorth> planetmaker: opinion on Lime Kiln?
20:07:40  <andythenorth> as an early source of chemicals....
20:07:44  <planetmaker> what is "lime kiln"? :-P
20:08:00  <andythenorth>
20:08:02  <Webster> Title: Lime kiln - Wikipedia, the free encyclopedia (at
20:08:46  <planetmaker> :-P
20:11:23  <andythenorth>
20:11:24  <Webster> Title: Lime Kilns in Cumbria (at
20:11:34  <andythenorth> the modern kiln looks very cool
20:11:37  <andythenorth>
20:12:11  <andythenorth> wonder if it should also produce FMSP
20:12:31  <andythenorth> there are lots of sources of BDMT already
20:13:53  <planetmaker> bdmt?
20:13:58  <planetmaker> nvm
20:14:46  <planetmaker> hm... but proposal, andy: adding those industries is always easy :-)
20:15:00  <planetmaker> postpone it ;-)
20:15:12  <planetmaker> even though it possibly makes sense
20:15:22  <andythenorth> I can put it in the FIRS site
20:15:26  <andythenorth> it's not needed in 0.5
20:15:46  <andythenorth> thinking about what to code is slightly easier than actually coding :P
20:18:12  <Terkhen> hmm... remove_defines could probably be autogenerated from 7F_any
20:20:07  <frosch123> night
20:20:12  *** frosch123 has quit IRC
20:20:13  <Brot6> OpenGFX+ Trains - Revision 16:81e3af35c17b: Add #1528: Dedicated toyland graphics for piece goods... (planetmaker) @
20:44:22  *** Alberth has left #openttdcoop.devzone
20:46:01  * andythenorth plays the game
20:46:30  <Terkhen> :O
20:47:47  <andythenorth> "Plant Fibers"
20:47:51  <andythenorth> just looks weird :)
20:50:27  <Terkhen> I still haven't seen them in game... once I finish translating I'll either play FIRS or toyland
20:53:05  *** ODM has joined #openttdcoop.devzone
20:58:43  *** Rubidium has joined #openttdcoop.devzone
21:09:40  <Terkhen> andythenorth: there is something even more weird about plant fibers... check the cargo payment rates graph
21:10:30  <andythenorth> I just fixed that :)
21:10:32  <Brot6> FIRS Industry Replacement Set - Revision 1407:744454fdb1cb: Cleanup: fix alignments in the 7F lan... (Terkhen) @
21:10:32  <Brot6> FIRS Industry Replacement Set - Revision 1408:22ffb825db04: Fix: add missing strings to remove_de... (Terkhen) @
21:10:32  <Brot6> FIRS Industry Replacement Set - Revision 1409:e3de031f92dd: Change: update Spanish translation. (Terkhen) @
21:10:43  <andythenorth> it was the only cargo I was transporting, and now I have no money :(
21:10:48  <Terkhen> :D
21:11:00  <Terkhen> okay, I'll wait until you push to start playing
21:11:25  <Terkhen> don't forget to merge
21:16:59  <andythenorth> Terkhen: try pull now
21:17:04  <andythenorth> I'm not sure it's fixed
21:17:12  <andythenorth> cargos involve a lot of files :)
21:19:00  <Brot6> FIRS Industry Replacement Set - Revision 1410:10fc3b281ff2: Fix: Plant Fibre cargo had 0 payment ... (andythenorth) @
21:20:18  <Terkhen> it's working now, thanks :)
21:23:21  <andythenorth> good night
21:23:22  *** andythenorth has left #openttdcoop.devzone
21:41:46  *** ODM has quit IRC
23:15:28  *** GT has joined #openttdcoop.devzone

Powered by YARRSTE version: svn-trunk