Times are UTC Toggle Colours
02:38:52 <Brot6> OpenGFX+ Trees - Revision 27:9c74239a5f7f: Feature #1530: Swap trees for FIRS Fruit Plantation (Froix) @ http://dev.openttdcoop.org/projects/ogfx-trees/repository/revisions/9c74239a5f7f 02:40:44 <Brot6> OpenGFX+ Trees - Feature Request #1530 (Closed): Swap two trees for better look with FIRS (Froix) @ http://dev.openttdcoop.org/issues/1530#change-4042 02:53:34 <Brot6> OpenGFX+ Trees - Revision 28:914d812a3393: Doc: renamed readme to get proper title automatically (Froix) @ http://dev.openttdcoop.org/projects/ogfx-trees/repository/revisions/914d812a3393 02:53:34 <Brot6> OpenGFX+ Trees - Revision 29:a049d28bb16b: Feature: Tree Graphics - added and edited, 1 apple tre... (Froix) @ http://dev.openttdcoop.org/projects/ogfx-trees/repository/revisions/a049d28bb16b 02:53:34 <Brot6> OpenGFX+ Trees - Revision 30:92816946e087: Codechange: Split code into smaller more readable litt... (Froix) @ http://dev.openttdcoop.org/projects/ogfx-trees/repository/revisions/92816946e087 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 (http://finger.openttdcoop.org) 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) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/f66fc89c8758 07:57:45 <planetmaker> fanioz: that's what the lines should look like... 07:58:31 <planetmaker> http://pastebin.org/1143999 <-- 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) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/b46af944d18b 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> http://pastebin.com/S7KLEM0c <--- log of the error 08:12:40 <Terkhen> http://pastebin.com/SA1QEgJ1 <--- 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) @ http://dev.openttdcoop.org/projects/indonesiantowns/repository/revisions/03654675c299 08:16:42 <Terkhen> IIRC it was lines 45 and/or 46 of tokens.py 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) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/0080f69403fc 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) @ http://dev.openttdcoop.org/projects/newgrf-makefile/repository/revisions/7c6e2cfb81c6 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) @ http://dev.openttdcoop.org/projects/indonesiantowns/repository/revisions/c645e0436727 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> http://pastebin.com/ZGZrYGNA <------- log of error 10:42:58 <fanioz> http://pastebin.com/fS6fbBTU <------------ 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) @ http://dev.openttdcoop.org/projects/indonesiantowns/repository/revisions/8a5bd9bcac1e 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 (http://finger.openttdcoop.org) 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) @ http://dev.openttdcoop.org/projects/indonesiantowns/repository/revisions/162834db559b 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> google.com 13:09:32 <Ammler> hmm, 3.6.10 is also latest on getfirefox.com 13:10:33 <Rubidium> http://en.wikipedia.org/wiki/APNG <- there... 13:10:35 <Webster> Title: APNG - Wikipedia, the free encyclopedia (at en.wikipedia.org) 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) @ http://dev.openttdcoop.org/projects/smts/repository/revisions/8860b2edb941 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> optipng-0.6.3-0.pm.1.1.i586 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 (http://bundles.openttdcoop.org/swedishrails/nightlies/r182/swedishrails-nightly.md5) 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 make.sh 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) @ http://dev.openttdcoop.org/projects/smts/repository/revisions/b20f18b7e27d 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> http://wiki.hetzner.de/index.php/Xen_mit_Routing_und_Bridge <-- like that, Ammler ? 14:42:05 <Webster> Title: Xen mit Routing und Bridge – Hetzner DokuWiki (at wiki.hetzner.de) 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) @ http://dev.openttdcoop.org/issues/1544 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) @ http://dev.openttdcoop.org/issues/1538#change-4043 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> http://pastebin.com/ZkyCbcaJ <- 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) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/d569bd9ddb6a 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) @ http://dev.openttdcoop.org/issues/1545 15:33:37 <Brot6> Example NewGRF Project - Feature #1545: update script to allow others updating their projects self (Ammler) @ http://dev.openttdcoop.org/issues/1545#change-4045 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 - http://bundles.openttdcoop.org/grfcodec/nightlies/r771 16:13:25 <Brot6> nml: update from r795 to r796 done - http://bundles.openttdcoop.org/nml/nightlies/r796 16:19:52 <Brot6> newgrf_makefile: update from r217 to r218 done - http://bundles.openttdcoop.org/newgrf_makefile/nightlies/r218 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) @ http://dev.openttdcoop.org/projects/newgrf-makefile/repository/revisions/2a661407ef01 16:21:32 *** fanioz__ has joined #openttdcoop.devzone 16:21:56 <Brot6> nforenum: update from to r506 done - http://bundles.openttdcoop.org/nforenum/nightlies/r506 16:22:14 *** fanioz__ has quit IRC 16:22:31 <Brot6> ogfx-trees: update from r26 to r30 done - http://bundles.openttdcoop.org/ogfx-trees/nightlies/r30 16:23:07 <Brot6> smts: update from to r1 done (4 errors) - http://bundles.openttdcoop.org/smts/nightlies/r1 16:23:17 <Brot6> Example NewGRF Project - Feature #1545: update script to allow others updating their projects self (planetmaker) @ http://dev.openttdcoop.org/issues/1545#change-4046 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) - http://bundles.openttdcoop.org/ttrs/nightlies/r23 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 mdep.py is missing a +x 16:32:00 <Froix> no, i don't get any errors local 16:32:23 <Ammler> you mdep.py 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 Makefile.in :-) 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) @ http://dev.openttdcoop.org/issues/1449#change-4047 16:42:10 <Ammler> Froix: anyway fix for your issue is chmod +x scripts/mdep.py 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 http://pastebin.com/i0wi8xFw what is it ? 16:54:58 <Alberth> C library? that's /lib/libc.so.6 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: http://dev.openttdcoop.org/issues/1449#change-4047 :D 17:46:45 <Alberth> pondered about the problem while doing shopping 17:47:04 <Alberth> iirc, the file is loaded with fp.read() 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> http://pastebin.com/4KPYiccn 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: http://pastebin.com/DZVBnXb3 <-- 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 - http://bundles.openttdcoop.org/32bpp-ez-patches/testing/r20842 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 - http://bundles.openttdcoop.org/clientpatches/testing/r20842 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) - http://bundles.openttdcoop.org/serverpatches/testing/h59412ac8 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) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/3d15c0f7521f 18:40:00 <Brot6> FIRS Industry Replacement Set - Feature #462 (Closed): Remove Wholesale Market from firs.pnfo (andythenorth) @ http://dev.openttdcoop.org/issues/462#change-4049 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: http://paste.pocoo.org/show/266833/ a less hacky solution, could you please try that instead? 18:43:52 <Webster> Title: Paste #266833 | LodgeIt! (at paste.pocoo.org) 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) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/b5aca31728a8 19:01:03 <Brot6> NewGRF Meta Language - Revision 797:4d92f826f7a0: Fix: Silently eat CR characters of C pre-proces... (Alberth) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/4d92f826f7a0 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) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/7d58c94cc506 19:21:33 <Terkhen> http://pastebin.com/EeGXaLwX <---I mean something like this 19:24:17 <Brot6> OpenGFX+ Trains - Revision 13:a209b9a54100: Change: Use spaces instead of tabs for indentation (planetmaker) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/a209b9a54100 19:26:30 <Brot6> OpenGFX+ Trains - Revision 14:73b3a4ce6077: Fix: Remove outdated and wrong comments (planetmaker) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/73b3a4ce6077 19:31:17 <Brot6> OpenGFX+ Trains - Revision 15:34b14c702e4f: Fix: Usage of some CTT entries was indicated wrongly (planetmaker) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/34b14c702e4f 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) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/37f41a50f0e2 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 wonders...am 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) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/6793b66d821a 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> http://en.wikipedia.org/wiki/Lime_kiln 20:08:02 <Webster> Title: Lime kiln - Wikipedia, the free encyclopedia (at en.wikipedia.org) 20:08:46 <planetmaker> :-P 20:11:23 <andythenorth> http://www.visitcumbria.com/limekilns.htm 20:11:24 <Webster> Title: Lime Kilns in Cumbria (at www.visitcumbria.com) 20:11:34 <andythenorth> the modern kiln looks very cool 20:11:37 <andythenorth> http://www.visitcumbria.com/julian/shap-c0109.jpg 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) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/81e3af35c17b 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) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/744454fdb1cb 21:10:32 <Brot6> FIRS Industry Replacement Set - Revision 1408:22ffb825db04: Fix: add missing strings to remove_de... (Terkhen) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/22ffb825db04 21:10:32 <Brot6> FIRS Industry Replacement Set - Revision 1409:e3de031f92dd: Change: update Spanish translation. (Terkhen) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/e3de031f92dd 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) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/10fc3b281ff2 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