Times are UTC Toggle Colours
00:08:32 *** KenjiE20 has quit IRC 00:30:43 *** Webster has joined #openttdcoop.devzone 01:07:09 *** Seberoth has quit IRC 02:01:41 *** welshdragon has quit IRC 02:17:40 *** welshdragon has joined #openttdcoop.devzone 07:01:09 *** ODM has joined #openttdcoop.devzone 08:14:31 *** welshdragon has quit IRC 08:15:19 *** welshdragon has joined #openttdcoop.devzone 08:37:26 *** Alberth has joined #openttdcoop.devzone 10:09:06 *** FooBar has joined #openttdcoop.devzone 10:09:40 <FooBar> andythenorth: I've been thinking about locating most processing industries only near towns 10:39:58 *** KenjiE20 has joined #openttdcoop.devzone 10:42:15 *** Seberoth has joined #openttdcoop.devzone 10:49:34 <Brot6> Metro Track Set - Feature #1159 (Closed): unsilence renum warning (foobar) @ http://dev.openttdcoop.org/issues/1159 10:49:34 <Brot6> Metro Track Set - Revision 31:ea5c5a718985: Backed out changeset: c82853399743 (foobar) @ http://dev.openttdcoop.org/projects/metrotrackset/repository/revisions/ea5c5a718985 10:49:34 <Brot6> Metro Track Set - Revision 32:d2d699206315: Merge (r23, r31): unsuppress renum warnings (closes #... (foobar) @ http://dev.openttdcoop.org/projects/metrotrackset/repository/revisions/d2d699206315 10:49:35 <Brot6> Metro Track Set - Feature #1159 (Closed): unsilence renum warning (foobar) @ http://dev.openttdcoop.org/issues/1159#change-2976 10:52:47 *** ODM has quit IRC 11:02:00 *** Froix has joined #openttdcoop.devzone 11:02:37 <Froix> Hello World 11:03:20 <Yexo> hello Froix 11:03:31 <Froix> hey 11:03:44 <Froix> just registered. anything i need to know? 11:04:28 <Yexo> registered where? what do you want to do? 11:05:03 <Froix> here. i'm looking at this newgrf project hosting. I'm a little lost 11:05:10 <Yexo> ah, ok 11:05:33 <Yexo> are you going to make a newgrf yourself or are you interested in helping out any of the existing projects? 11:06:11 * FooBar searches 11:06:25 <FooBar> Shanghai maglev :) 11:08:35 <Froix> that one 11:08:37 <FooBar> Your name sounded familiar :) 11:08:37 <Froix> :) 11:08:37 <Froix> what's the first step? 11:08:37 <FooBar> oh, welcome! 11:08:37 <FooBar> almost forgot that 11:08:37 <Froix> thnks 11:08:37 <Froix> "create ticket for new project".. is that it? 11:08:37 <Yexo> yes, after that you'll have to wait for Ammler to actually create it 11:08:37 <Froix> oh ok. tnx 11:09:00 <Ammler> actually, every Manager can create a new project 11:09:32 <FooBar> I knew I could, but didn't know if that would undermine authority :D 11:09:39 <Ammler> I wouldn't think so :-) 11:09:44 <Yexo> you told me before I could, but I have no idea how 11:12:18 <Ammler> Froix: basically we just need a name for your project identifier, everything else can then be edited later 11:12:33 <Ammler> (from yourself) 11:13:05 <Ammler> you like to use existing project? 11:13:11 <Ammler> like swedishrails? 11:14:26 <Froix> use? how do u mean? copy format and all? 11:15:28 <Brot6> #openttdcoop - Membership #1160 (New): Shanghai Maglev Track Set (Froix) @ http://dev.openttdcoop.org/issues/1160 11:15:43 <FooBar> yes, basically copy the code and add your own graphics. If you like your own current code, you can also keep that 11:15:52 <Ammler> copy and replace the sprites, yes 11:17:25 <Ammler> "Shanghai-Maglev-Track-Set" is a bit long identifier, you like to use that or have you a shorter proposal? 11:17:38 <Ammler> this is used in the url and repo 11:18:01 <FooBar> I think it's even too long... 20 char maximum 11:18:10 <Ammler> indeed 11:18:26 <Froix> SMTS? 11:18:28 <Froix> ok? 11:18:39 <FooBar> that would work 11:19:19 <FooBar> but I'll leave the creation of the project to Ammler, otherwise things will get very confusing right now :) 11:19:40 <Ammler> done 11:20:10 <Ammler> http://dev.openttdcoop.org/projects/smts/settings <-- feel free to edit 11:20:19 <Ammler> the repo will be created soon 11:21:07 <Brot6> repository /home/ottdc/hg-repos/smts registered in Redmine with url /home/ottdc/hg-repos/smts 11:21:07 <Brot6> repository /home/ottdc/hg-repos/smts created 11:23:25 <FooBar> Ammler, things like below probably mean that I have to build grfcodec myself? 11:23:27 <FooBar> /usr/local/bin/grfcodec: 1: cannot create =@@�@8: Protocol error 11:23:28 <FooBar> /usr/local/bin/grfcodec: 1: ELF: not found 11:23:29 <FooBar> /usr/local/bin/grfcodec: 1: �/: Protocol error 11:23:32 <FooBar> /usr/local/bin/grfcodec: 3: R0: not found 11:23:34 <FooBar> /usr/local/bin/grfcodec: 3: U: not found 11:23:38 <FooBar> /usr/local/bin/grfcodec: 3: p�O�x9e=w 11:24:36 <Brot6> NewGRF Meta Language - Revision 594:2f40b67cda40: Doc: add some documentation for the builtin exp... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/2f40b67cda40 11:24:36 <Brot6> NewGRF Meta Language - Revision 595:c2f7950b0b69: Doc: document all functions in the Expression c... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/c2f7950b0b69 11:24:36 <Brot6> #openttdcoop - Membership #1160 (Closed): Shanghai Maglev Track Set (Froix) @ http://dev.openttdcoop.org/issues/1160 11:24:36 <Brot6> #openttdcoop - Membership #1160 (Closed): Shanghai Maglev Track Set (Ammler) @ http://dev.openttdcoop.org/issues/1160#change-2977 11:24:36 <Ammler> push a test (beta) release and then you could see, if it works 11:24:59 <Ammler> FooBar: where did you get it from? 11:25:10 <FooBar> oh, I was trying to install the new devzone grfcodec/nforenum on my local ubuntu 11:25:19 <Ammler> from? 11:25:27 <FooBar> bundles 11:25:37 <Ammler> the rpm? 11:25:42 <FooBar> but appearently linux != linux 11:25:50 <FooBar> yes, as the other appeared to be the source :) 11:26:09 <Yexo> you could also try to build it yourself 11:26:13 <FooBar> ubuntu is debian based 11:26:17 <Ammler> the rpm is 64bit variant 11:26:38 <FooBar> ah, there we go 11:26:38 *** Froix has quit IRC 11:26:46 <Ammler> the rpm is mainly just for our projects itself 11:27:01 <Ammler> as soon, as this get official, openttd.org cf will compile those 11:27:13 <FooBar> ah, I misread the x86_64 for just x86 11:28:01 <Ammler> well, if wanted, I can publish the 32version too 11:28:29 <FooBar> silly linux world, did they really have to go for x86 and x86_64? on windows "we" just stick with x86 and x64 :P 11:28:31 <FooBar> I can try to build first 11:28:54 <FooBar> if that works, then other versions are fine when the project is "released" 11:29:36 <Ammler> you can view the spec file to see, what packages are needed to build 11:30:28 <FooBar> I'll start with renum, as that is most critical 11:30:58 <Ammler> yeah, grfcodec doesn't have any required updated, afaik 11:31:02 *** Froix has joined #openttdcoop.devzone 11:31:41 <Froix> sorry experiencing online problems 11:32:00 <Ammler> Froix: http://dev.openttdcoop.org/projects/home/wiki/Welcome might be start 11:32:07 <Ammler> skip the parts about SSH 11:32:14 <FooBar> no problem, it's probably not your fault ;) 11:32:34 <Froix> probably ^^ 11:32:43 <FooBar> :) 11:32:51 <Ammler> and feel free to ask here, nml might not be that newbie proof yet 11:32:54 <FooBar> What operating system are you using? 11:33:06 <Froix> windows xp 11:33:09 <Ammler> and planetmaker is on vacation, but others might also be able to help 11:33:17 <Froix> ok tnx 11:33:44 <FooBar> ah, I'm probably the guy to talk to for windows-specific problems, although I haven't tried NML yet... 11:34:28 <FooBar> it could be that the makefile doesn't work for you on XP, as it doesn't work for me on Win7 either 11:34:39 <FooBar> (if you intend to use that) 11:35:47 <Yexo> makefile does work fine here on xp (with cygwin) 11:35:49 <Ammler> @topic remove -1 11:35:59 <Ammler> @services op 11:36:00 *** ChanServ sets mode: +o Webster 11:36:03 <Ammler> @topic remove -1 11:36:07 *** Webster changes topic to "Talk about things hosted and developed on http://dev.openttdcoop.org | Downloads log: http://bundles.openttdcoop.org/log.csv" 11:36:24 <FooBar> Yexo: didn't work here with cygwin nor with mingw/msys 11:36:43 <FooBar> nor with what rubi recommended of which I forgot the name 11:37:02 <Ammler> that is a "mingw bundle" 11:38:03 <FooBar> with some sprinkles, but basically it is 11:38:15 <FooBar> The bundling might be the sprinkle :) 11:38:29 <Froix> be back to test it out laters 11:38:32 <Froix> tnx guys 11:38:38 <FooBar> you're welcome 11:38:47 *** Froix has quit IRC 11:38:48 * FooBar forgot what he was actually doing 11:39:09 <FooBar> oh yes, trying to compile renum 11:39:57 <Rubidium> FooBar: Windows actually uses Win32 and x64 in MSVC, and x86 + amd64 in Program Files 11:40:36 <Rubidium> also x86_64 is more similar to all the other architectures with 64 bits, e.g. sparc64, ppc64 11:40:54 <FooBar> although inconsistent, still less confusing than x86_64 if you ask me 11:41:00 <Rubidium> even then x64 and x86 aren't that distinctive, whereas x86 and x86_64 is 11:41:02 <FooBar> I know where it came from, but it's still confusing 11:41:28 <FooBar> but then reading properly helps a great deal :) 11:41:34 *** Alberth is now known as Guest193 11:41:34 *** Guest193 is now known as Guest194 11:42:01 <FooBar> Hi Guest194 11:42:17 * FooBar couldn't resist 11:42:57 <Rubidium> although I *agree* that x86 is a very bad name in itself, given 186 and 286 are 16 bits 11:43:17 <FooBar> yes, it should be more like 386+ 11:43:22 <Rubidium> so lets propose to retroactively name x86 based architectures x86_16, x86_32 and x86_64 11:43:28 *** welshdragon has quit IRC 11:44:11 <FooBar> I could live with that, but then why not just 16bit, 32bit and 64bit 11:44:28 *** Alberth1 has joined #openttdcoop.devzone 11:44:30 <FooBar> that even saves a char and doesn't include having to hold the shift key for a while :D 11:44:34 <Rubidium> because you might not be quite using an x86-ish computer 11:44:34 <Ammler> because there is sparc, ppc and such 11:44:57 <Rubidium> ppc is a bad name as well, but we'll blame MS for that 11:45:13 <FooBar> you mean "pocket pc", right? 11:45:32 <Ammler> hmm, not power pc? 11:45:48 <Rubidium> as I said... it's a bad name 11:45:50 <FooBar> microsoft can hardly be blamed for power pc, I believe that was first... 11:46:25 <FooBar> anyhoe, I just got me boost 11:46:48 *** Guest194 has quit IRC 11:47:25 <Brot6> NewGRF Meta Language - Revision 596:fca204434dc3: Codechange; move class Assignment to ast/grf.py... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/fca204434dc3 11:47:58 <FooBar> seems ubuntu doesn't come with g++... 11:48:25 <Ammler> you might be able to install pattern devel 11:49:24 <FooBar> it does something now... 11:49:43 <FooBar> some warnings... 11:49:44 <Ammler> gcc-c++ 11:50:57 <FooBar> strings.cpp:376: warning: ignoring return value of ‘char* fgets(char*, int, FILE*)’, declared with attribute warn_unused_result 11:51:08 <FooBar> and then two more of those 11:51:38 <FooBar> there is a very large renum file created though :S 11:51:47 <FooBar> is that normal? 3.9 MB 11:52:15 <Ammler> not stripped 11:52:43 <FooBar> no, I just typed "make" 11:52:47 * FooBar tries again with make remake 11:52:57 <FooBar> no... make release 11:54:33 <Ammler> yes, make release might strip 11:56:03 <Ammler> else just run strip nforenum, if you care 11:56:45 <FooBar> 423 kB looks more like it 11:58:13 <Ammler> if you like, you can collect your compile warnings and post those on the tracker 11:58:54 <FooBar> do I have access to that tracker? 11:59:05 <FooBar> grfcodec spits more warnings... 12:00:30 <Ammler> yep, added the group Managers as Reporters 12:00:50 *** welshdragon has joined #openttdcoop.devzone 12:00:50 <FooBar> thanks! 12:01:07 *** welshdragon has quit IRC 12:03:04 <Ammler> also you might report WARNINGS which should be implemented 12:03:18 <FooBar> I'm getting upx first and try again. It appears I didn't have that 12:03:28 <Ammler> make UPX= release 12:03:39 <Ammler> "UPX is crap" 12:03:45 <FooBar> I don't think that caused extra warnings, but still 12:05:02 <FooBar> well, it might be crap, but "make release" wanted it... 12:05:18 <FooBar> and I wonder if it can get the filesize down 12:05:21 <FooBar> :) 12:05:38 <Ammler> but then you have a slower grfcodec instead :-P 12:07:18 <Ammler> it might not matter at all 12:09:41 <FooBar> I don't want slower :) It's already slow enough :D 12:20:35 <Brot6> NewGRF Meta Language - Revision 597:c82c5347d852: Add: code to convert ast/deactivate to nml-code (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/c82c5347d852 12:20:35 <Brot6> NewGRF Meta Language - Revision 598:c028146938dd: Add: code to convert ast/error to nml-code (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/c028146938dd 12:22:22 <Brot6> NewGRF Meta Language - Revision 599:82bfb0b37d22: Codechange: move item_names from expression.py ... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/82bfb0b37d22 12:45:16 *** Froix has joined #openttdcoop.devzone 12:52:56 <Froix> hey 12:55:00 <Froix> buzz buzz 12:55:09 *** welshdragon has joined #openttdcoop.devzone 12:57:12 <Brot6> SMTS - swedishrails.pnml (Froix) @ http://dev.openttdcoop.org/attachments/download/794/swedishrails.pnml 12:58:44 <FooBar> hi 12:59:28 <Froix> hey 12:59:58 <Froix> how can i test out the compiler here if it works for me 13:00:47 <FooBar> have you installed tortoisehg, mingw and msys? 13:00:55 <Ammler> well, you need to fill the repo 13:01:06 <FooBar> or alternatively, tortoisehg and cygwin? 13:01:42 <FooBar> yexo sais the compiling with cygwin works for him, so that might be recommended over mingw 13:02:03 <Froix> i have mingw. i'm not sure it's working though 13:02:31 <Froix> how do i fill the repo? 13:02:40 <FooBar> type, lets see, "grep --help" in a command line window (without the quotes) 13:02:41 <Ammler> first step is anyway to use the hg repo 13:02:50 <Yexo> are you going to write nfo code (ie use grfcodec / nforenum) or nml code? 13:03:14 <Froix> nfo for now 13:03:50 <Yexo> to start pick any nfo project at the devzone, clone that repository and try to build it 13:04:16 <Froix> ok 13:05:02 <FooBar> the "example newgrf project" might be a good start 13:05:18 <FooBar> hg clone http://mz.openttdcoop.org/hg/newgrf_makefile 13:05:28 <Ammler> hmm... 13:05:49 <FooBar> as you can use that as a start for your own project as well (unless you want to start with a more complete project) 13:06:34 <FooBar> Ammler: link not good? 13:06:50 <Froix> i'm there. what next? 13:07:08 <FooBar> open a command window in that directory 13:07:09 <Ammler> try to build that grf 13:08:01 <FooBar> if you're in the correct directory, type "make" (again without quotes) and press enter 13:08:05 <Ammler> FooBar: all fine, I was thinking, he likes to branch ser and replace the sprites 13:08:37 <FooBar> Ammler: Seems he likes to use NFO for now, maybe branch metrotrackset in that case... 13:08:45 <Ammler> yes :-) 13:09:06 <Froix> i'm looking at a summary. is this the clone? i can make changes to this? 13:09:51 <Ammler> clone your repo 13:10:15 <Ammler> and copy the files from an other project 13:10:48 <Ammler> or clone another project, change it, and push to your repo 13:11:25 <FooBar> if you want a big head start, you can copy the metrotrackset project. It basically has all the nfo you need, you just change the graphics and then continue from there 13:20:48 <Ammler> http://hginit.com/ might be a nice starter tut 13:20:50 <Webster> Title: Hg Init: a Mercurial tutorial by Joel Spolsky (at hginit.com) 13:27:09 <Froix> haha this is a whole new world to me 13:28:43 <Froix> I'm looking at the metrotracks code and it uses commands i'm not aware of 13:30:59 <Froix> sorry i'm a little slow. perhaps i'm better off writing nfo codes on my notepad 13:39:24 <FooBar> there are some codes in it that are picked up by the makefile 13:39:54 <FooBar> like including files (#include) and replacing values ({{VALUE}}) 13:40:22 <FooBar> where you read #include, you /think/ the contents of the file specified 13:41:32 <FooBar> it all starts with metrotrk.pnfo 13:48:36 <Brot6> GRFCodec - Bug #1161 (New): Build warnings strings.cpp (foobar) @ http://dev.openttdcoop.org/issues/1161 13:51:03 <Brot6> GRFCodec - Bug #1161: Build warnings strings.cpp (foobar) @ http://dev.openttdcoop.org/issues/1161#change-2978 13:51:04 <Brot6> NewGRF Meta Language - Revision 600:91e26f7a254b: Codechange: introduce FreeNumberList as a gener... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/91e26f7a254b 13:51:04 <Brot6> NewGRF Meta Language - Revision 601:feff534dac93: Codechange: use FreeNumberList for the free par... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/feff534dac93 13:51:04 <Brot6> NewGRF Meta Language - Revision 602:548751dcbefc: Codechange: use FreeNumberList to keep track of... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/548751dcbefc 13:52:59 <Brot6> GRFCodec - Bug #1162 (New): Build warnings (foobar) @ http://dev.openttdcoop.org/issues/1162 13:54:14 <Brot6> GRFCodec - Bug #1161 (Closed): Build warnings strings.cpp (foobar) @ http://dev.openttdcoop.org/issues/1161 13:54:14 <Brot6> NFORenum - Bug #1163 (New): Build warnings (foobar) @ http://dev.openttdcoop.org/issues/1163 13:54:14 <Brot6> GRFCodec - Bug #1161 (Closed): Build warnings strings.cpp (foobar) @ http://dev.openttdcoop.org/issues/1161#change-2979 14:06:10 <Brot6> NFORenum - Bug #1164 (New): colour string codes not allowed in textstrings for railtypes (foobar) @ http://dev.openttdcoop.org/issues/1164 14:06:11 <Brot6> NewGRF Meta Language - Revision 603:da35eff11785: Fix (r600): some empty lines had whitespace (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/da35eff11785 14:13:43 <Brot6> NFORenum - Support #1165 (New): action3 railtypes default ID (foobar) @ http://dev.openttdcoop.org/issues/1165 14:30:32 <Brot6> Metro Track Set - Bug #1166 (Assigned): glitches in non-railtype ogfx bridges (foobar) @ http://dev.openttdcoop.org/issues/1166 14:30:32 <Brot6> Metro Track Set - Support #1167 (Assigned): test release (foobar) @ http://dev.openttdcoop.org/issues/1167 14:33:01 <FooBar> Ammler: for beta release, would 1.0.0-beta work as tag? 14:33:12 <Ammler> yes 14:33:21 <FooBar> ok, then expect a beta release ;) 14:33:29 <Yexo> better use beta1 or something like that 14:33:34 <Ammler> -+ and _ 14:33:38 <Yexo> "1.0.0-beta1" of course 14:33:55 <Ammler> oh, and . 14:37:48 * FooBar rolls back 14:37:50 <Ammler> the ugly thing about is that 1.0.0-beta1 > 1.0.0 14:38:09 <Ammler> but that should bother you 14:38:12 <FooBar> I can do 0.9, I don't care 14:38:12 <Ammler> n't 14:38:39 <Ammler> it is just for packaging 14:38:56 <FooBar> well, this release is just for testing ;) 14:39:02 <Ammler> If I would make a rpm, I would change that to 1.0-beta1 14:39:16 <Ammler> 1.0-beta1 < 1.0.0 14:39:32 <Ammler> yeah, we don't package newgrfs yet 14:39:32 <FooBar> that is interesting, I like that 14:39:34 <Ammler> :-) 14:40:07 <Ammler> and for example openttd 1.0.2-RC1 is 1.0.1.90-RC1 14:40:51 <Ammler> or else I would need to make the real release 1.0.2.0 14:41:04 <FooBar> too many numbers ;) 14:41:43 <Ammler> yes, that is why "we" workaround with <old>.90 14:42:08 <Ammler> but ususally you don't package testings 14:42:30 <FooBar> true, but in this case you want a beta ;) 14:42:47 <Ammler> well 14:43:14 <Ammler> that was for checking if your set does build on the server,since you don't have nightly 14:43:40 <FooBar> exactly 14:44:01 <Ammler> you should still enable nightly as kind of regression test for nforenum and grfcodec :-P 14:44:43 <FooBar> I can, but I think after tomorrow there's not much regression as then "it's done" 14:44:54 <Ammler> that is the idea begind 14:44:58 <FooBar> then users have to find errors first 14:45:03 <Ammler> your set doesn't chagne, but renum and codec does 14:45:20 <Ammler> and so you have a good reference for tests 14:45:21 <FooBar> are you rebuilding with no changes to the set then? 14:45:30 <Ammler> yes, but not publish 14:45:43 <FooBar> ok, then I will enable nightly and not do a beta 14:46:21 <Ammler> there is nutracks, but that has a lot errors currently 14:46:57 <FooBar> I have two different warnings on metrotrackset with newest renum 14:47:18 <Ammler> yeah, you have posted those, I guess 14:47:26 <FooBar> yes, exactly 14:48:09 <FooBar> both might be considered "not a bug" though, but we'll see 14:49:26 <Brot6> Metro Track Set - Support #1167 (Closed): test release (foobar) @ http://dev.openttdcoop.org/issues/1167 14:49:26 <Brot6> Metro Track Set - Support #1167 (Closed): test release (foobar) @ http://dev.openttdcoop.org/issues/1167#change-2980 14:49:31 <Ammler> there are still some string codes not working for description, like size 14:50:42 <Brot6> Metro Track Set - Revision 33:2bf053d6ccc2: Change: enable nightly compile (foobar) @ http://dev.openttdcoop.org/projects/metrotrackset/repository/revisions/2bf053d6ccc2 14:51:05 <FooBar> now to wait until it's actually "night" :P 14:51:43 <Ammler> yeah, but have early night :-) 14:52:27 <FooBar> true, maybe call it "eveningy" :P 14:53:27 <FooBar> haven't you talked about removing the word "nightly" and only keep r+number? 14:53:43 <FooBar> I remember something like that passing by, not the outcome though 14:53:53 <Ammler> well, the server ususally does nightly 14:54:06 <Ammler> but when you make custom builds, they shouldn't be called that 14:54:11 <FooBar> I don't mind really, just wondering 14:54:51 <Ammler> that was the idea behind, don't know, I guess, we didn't change that 14:55:53 <FooBar> I think the word "nightly" has a well-defined meaning in openttd world. People not using openttd nightly probably don't use newgrf nightly either 14:56:37 <Ammler> those people use bananas only 14:57:05 <Ammler> so if you upload a nightly to bananas, they might use it 14:57:19 <FooBar> true, but that doesn't happen too often 14:57:54 <Ammler> for unreleased sets maily 15:07:54 <Brot6> NewGRF Meta Language - Revision 604:bfbe3612b566: Codechange: introduce BaseAction, a base class ... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/bfbe3612b566 15:09:00 <Alberth1> \o/ 15:12:50 *** Froix has quit IRC 15:14:27 <Rubidium> FooBar: would you be so kind as to disclose the "global" CFLAGS that are passed to gcc? Primarily because the warnings you report as a bug are as far as I can see of a CFLAG setting that is quite pedantic 15:15:13 <FooBar> happily, if I knew how to... 15:15:32 <Rubidium> FooBar: OpenTTD nightlies are silently being called openttd-trunk-rXYZ, not openttd-nightly-rXYZ :) 15:15:49 <FooBar> hmmm...indeed they are :) 15:16:03 * FooBar wonders why people still call them nightlies... 15:16:15 <FooBar> "trunkies" :P 15:16:20 <FooBar> anyhow, you were saying? 15:16:51 <Rubidium> probably because the frontpage says "download nightly" :) 15:17:13 <FooBar> lot of inconsistensies today... 15:17:28 <FooBar> anyways, I kept all settings default for both grfcodec and nforenum 15:17:36 <FooBar> just downloaded the source and built it 15:17:56 <FooBar> so CFLAGS is as the makefile defines them 15:18:26 <Rubidium> FooBar: what does export say? 15:18:30 <Ammler> "trunk" is the branch, so this ok, nightly scheduled 15:19:02 <Ammler> we could call ours default :-) 15:19:37 <FooBar> Rubidium: now you really have to help me: what do I do to have export tell me anything? 15:19:52 <Alberth1> type 'export' :) 15:20:17 <Alberth1> and look for a line with CFLAGS 15:20:28 <Rubidium> open a console/terminal/command prompt and type export and do not forget pretting the "enter" key :) 15:20:47 <FooBar> thanks 15:21:00 <FooBar> the console I figured I had to use :) 15:21:08 <Ammler> if too much output add "| grep FLAG" 15:22:01 <FooBar> there's no such thing as CFLAGS 15:22:14 <FooBar> I'm in the dir with grfcodec 15:22:36 <Rubidium> excuse me 15:23:12 <FooBar> should I have built first? 15:23:28 <Rubidium> oh fracking frack... stupid morons at Ubuntu did it again... when are they fracking go to learn that making the compiler pedantic by default is going to make a lot of people annoyed? 15:26:49 <Rubidium> so now I have to fracking search for the stuff they actually changed so I can reproduce the issues 15:27:19 <FooBar> highlight me if I need to try something different 15:31:00 <Ammler> Rubidium: or set it a bit less pedantic in the Makefile? 15:32:00 <Rubidium> Ammler: yeah... good idea... what CFLAGS do I need for that? 15:32:17 <Ammler> ok, I see :-P 15:33:17 <Rubidium> I've got a rough idea of the passed CFLAGS though :), but need to be sure 15:40:38 <Rubidium> ofcourse the only "clear" place to find it is in the changes they make to the package sources... 15:42:25 <Ammler> don't you need to know that for OpenTTD anyway? 15:44:10 <Rubidium> not really because we're probably setting even more pedantic CFLAGS than Ubuntu 15:44:49 *** frosch123 has joined #openttdcoop.devzone 16:18:54 <Brot6> metrotrackset: update from to r33 done (1 errors) - http://bundles.openttdcoop.org/metrotrackset/nightlies/r33 16:20:21 <Brot6> nforenum: update from r406 to r407 done - http://bundles.openttdcoop.org/nforenum/nightlies/r407 16:20:46 <Brot6> nml: compile of r604 failed - http://bundles.openttdcoop.org/nml/nightlies/ERROR/r604 16:20:54 <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r573), 32bpp-extra (r36), airportsplus (r52), comic-houses (r71), firs (r1076), fish (r386), grfcodec (r178), heqs (r371), newgrf_makefile (r124), nutracks (r86), ogfxplus (ERROR r41), opengfx (r469), openmsx (r91), opensfx (r97), snowlinemod (r15), swedishrails (r140), worldairlinersset (r659) 16:22:21 <Brot6> 32bpp-extra: rebuild of r36 done (3584 errors) (Diffsize: 341) - http://bundles.openttdcoop.org/32bpp-extra/nightlies/r36/log 16:22:25 <Ammler> mäh, it isn't installed 16:26:39 <Brot6> nutracks: rebuild of r86 done (164 errors) (Diffsize: 243) - http://bundles.openttdcoop.org/nutracks/nightlies/r86/log 16:27:08 <Brot6> ogfxplus: update from r40 to r41 done - http://bundles.openttdcoop.org/ogfxplus/nightlies/r41 16:29:44 <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: 2cctrainset (1 errors), airportsplus, comic-houses (3 errors), firs (5 errors), fish (1 errors), heqs, metrotrackset (1 errors), newgrf_makefile, opengfx, snowlinemod, worldairlinersset 16:32:59 <Brot6> NFORenum - Bug #1164 (Closed): colour string codes not allowed in textstrings for railtypes (foobar) @ http://dev.openttdcoop.org/issues/1164 16:32:59 <Brot6> NFORenum - Bug #1164 (Closed): colour string codes not allowed in textstrings for railtypes (yexo) @ http://dev.openttdcoop.org/issues/1164#change-2981 16:32:59 <Brot6> NFORenum - Revision 408:2fffe87d5ccd: Fix [#1164]: colour string codes are allowed in railtype st... (yexo) @ http://dev.openttdcoop.org/projects/nforenum/repository/revisions/2fffe87d5ccd 16:35:10 <Alberth1> Ammler: ERROR directory does not seem to exist, is that why the url is broken? 16:35:33 <Alberth1> (of nml) 16:39:16 <Yexo> about http://dev.openttdcoop.org/issues/1165 I'm not sure what the best solution is 16:40:07 <Yexo> we could disable warning 100 completely for railtypes? 16:40:19 <Yexo> Rubidium / FooBar: any comments on that one? 16:40:33 <Yexo> or frosch123? 16:40:36 <FooBar> you're lucky, I just returned ;) 16:40:43 <Ammler> Alberth1: it doesn't install it either 16:41:41 <FooBar> I think disabling that warning for just railtypes might do the trick, as I don't see an other solution 16:41:43 <frosch123> imo it is wrong to use "icons" for the default 16:41:53 <frosch123> it should go to some fail-state 16:42:05 <frosch123> or everything will show the icons if we add more cases 16:42:17 <Yexo> the default isn't used for railtypes 16:42:35 <FooBar> I was about to say that: something that isn't defined, isn't shown 16:43:22 <FooBar> say if I don't define thie icons, it falls back to the default icons of the first railtype; it doesn't use <default> 16:43:29 <frosch123> my assumption is that ottd resolves the default if one of the cases is missing. if that is not the case, i guess default would only be used if we get callbacks 16:44:02 <Yexo> the default is read but ignored by openttd (newgrf.cpp:3919) 16:44:15 <Rubidium> Yexo: I've got no real clue about railtypes, so can't say anything useful about them; I'm working on the compile warnings though 16:44:24 <Yexo> ok 16:45:12 <FooBar> I can easily define a different default, but that would mean adding some pointless action2 that has no meaning and is never used 16:45:29 <Yexo> you can also give an invalid action2 id as default 16:45:34 <Yexo> but then you'd probably get another warning 16:45:37 <FooBar> :) 16:45:40 <FooBar> exactly 16:45:52 <Yexo> hmm, actually that might work 16:45:57 <Yexo> it is exactly what nml does :p 16:47:15 <FooBar> well, solving one error by displaying another is not really solving ;) 16:51:05 <frosch123> we should add some railtype callback to make use of the defaultcase :p 16:51:12 <frosch123> maybe railtype availability? 16:51:22 <Brot6> NewGRF Meta Language - Revision 605:2590d45d8107: Codechange: Reduce code duplication in the real... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/2590d45d8107 16:53:22 <Brot6> Metro Track Set - Feature #1168 (New): snowy depot for railtypes (foobar) @ http://dev.openttdcoop.org/issues/1168 17:00:48 <FooBar> frosch123: that would be a good one. Pikka(?) already suggested an option to set when a railtype should be available on top of the engine availability 17:02:17 <frosch123> i am thinking about a callback which can check the date, and get some extra variables which tell stuff like: there are engines which can run on the rail, there are engines which cannot run on any other available track, .... 17:04:29 <FooBar> be my guest :) 17:05:51 <Brot6> GRFCodec - Revision 179:aed04cef5787: Fix: "format not a string literal" warnings (Rubidium) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/aed04cef5787 17:07:30 <Brot6> GRFCodec - Revision 180:b9b47515ea34: -Fix: comparison that is always true (Rubidium) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/b9b47515ea34 17:40:23 *** frosch123 has quit IRC 17:40:38 <Brot6> GRFCodec - Revision 181:8364082c2756: Fix: more warnings about not passing string literals to printf (Rubidium) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/8364082c2756 17:40:38 <Brot6> GRFCodec - Revision 182:fbdf71e0294b: -Fix: missing initializer warning (Rubidium) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/fbdf71e0294b 17:40:38 <Brot6> GRFCodec - Revision 183:2102c6089cb2: Fix: do not ignore return value of fread (Rubidium) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/2102c6089cb2 17:40:39 <Brot6> GRFCodec - Revision 184:b25ed8af0593: Fix: do not ignore the return value of fscanf and fgets (Rubidium) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/b25ed8af0593 17:42:52 <Brot6> GRFCodec - Revision 185:deba5f884f3f: Change: detect upx instead of making people disable it expl... (Rubidium) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/deba5f884f3f 17:44:11 <Brot6> NFORenum - Revision 409:c16f41427808: Change: detect upx instead of making people disable it expl... (Rubidium) @ http://dev.openttdcoop.org/projects/nforenum/repository/revisions/c16f41427808 18:00:51 <Brot6> GRFCodec - Revision 186:2973c5d83c95: Fix: do not ignore the return value of fwrite (Rubidium) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/2973c5d83c95 18:00:51 <Brot6> GRFCodec - Revision 187:655fd76fd42e: Change: add more (pedantic) compiler warnings (closes #1162) (Rubidium) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/655fd76fd42e 18:00:51 <Brot6> GRFCodec - Bug #1162 (Closed): Build warnings (Rubidium) @ http://dev.openttdcoop.org/issues/1162#change-2982 18:06:01 <Brot6> NFORenum - Revision 410:a80398c19576: Fix: "type qualifiers on function return type" warning (Rubidium) @ http://dev.openttdcoop.org/projects/nforenum/repository/revisions/a80398c19576 18:09:34 <Rubidium> FooBar: your compile issues should now be fixed, although I haven't thoroughly tested the changes yet 18:09:56 <FooBar> I'll try in a short while 18:10:58 <Brot6> NFORenum - Revision 411:6c448c48a81d: Fix: do not ignore the return value of fgets (Rubidium) @ http://dev.openttdcoop.org/projects/nforenum/repository/revisions/6c448c48a81d 18:10:58 <Brot6> NFORenum - Revision 412:11070125474a: Change: add more (pedantic) compiler warnings (closes #1163) (Rubidium) @ http://dev.openttdcoop.org/projects/nforenum/repository/revisions/11070125474a 18:10:58 <Brot6> NFORenum - Bug #1163 (Closed): Build warnings (Rubidium) @ http://dev.openttdcoop.org/issues/1163#change-2983 18:21:50 <FooBar> grfcodec builds without warning 18:22:54 <FooBar> and so does renum. Well done! 18:23:35 <andythenorth> evening 18:23:54 <FooBar> hi Andy 18:24:04 <FooBar> got my message from this morning? 18:25:42 <FooBar> about locating industries near towns 18:26:45 <andythenorth> I saw the one in the forums, not others 18:26:49 <andythenorth> was it pm or irc? 18:27:01 <FooBar> irc 18:27:09 <andythenorth> ah 18:27:20 <andythenorth> I have absolutely no idea how to see those messages sorry 18:27:23 <FooBar> "I've been thinking about locating most processing industries only near towns" 18:27:49 <andythenorth> it's an idea, but would have certain problems 18:27:50 <FooBar> well, it was just a highlight here in the channel, but I don't blame you for missing it 18:28:14 <FooBar> i think heavy industry should not be located near town, with pollution and everything 18:28:28 <andythenorth> my principal objections are.... 18:28:38 <FooBar> but other processing industries, especially early ones should IMO 18:28:43 <FooBar> let's hear them :) 18:28:49 <andythenorth> (1) it annoys players in PBI (planetmaker has specifically asked for *not* doing this) 18:29:28 <andythenorth> (2) it makes gameplay harder. Building routes in constrained spaces around towns becomes less fun after a bit 18:29:51 <andythenorth> (3) it might slow down industry generation 18:29:56 <andythenorth> however... 18:30:10 <andythenorth> ...some players have also requested it 18:30:24 <FooBar> (2) was a pro for me, but given that PBI /and/ ECS have it, it makes (1) a con for me as well... 18:30:39 <FooBar> i.e., we don't need to have what others have 18:31:09 <andythenorth> (A) it's already in place for Brewery, Bakery - using built-in methods 18:31:44 <andythenorth> (B) it would be quite easy to adapt clustering code so landscape generator places certain industries near town, but players can build anywhere 18:32:15 <andythenorth> FooBar: make a list of industries you think should locate near town? 18:33:01 <FooBar> allowing players to build anywhere is fine with me; actually preferred... you could simulate having to relocate an industry due to town growth... 18:33:15 <FooBar> ok, let's make a list. I'll add it as suggestion to the tracker 18:34:08 <andythenorth> I was also thinking of for certain industries enforcing min / max distances to other industry types 18:34:21 <andythenorth> e.g. an update of conflicting industry types, but more under our control 18:35:15 <FooBar> minimum distance is probably not necessary, except for clustering industries 18:35:37 <FooBar> wait...thats maximum... 18:35:44 * FooBar tries again 18:35:54 <FooBar> *maximum* distance is probably not necessary, except for clustering industries 18:37:48 <andythenorth> perhaps not 18:38:04 <andythenorth> depends if we want to be sure a resource isn't too far from a processor 18:38:29 <andythenorth> I've started a new game where fishing grounds are really too far from fishing harbours for example 18:39:12 <andythenorth> I think max distance might require a logical condition that was never met though! 18:42:51 <FooBar> well, maybe for specific cases, but generally I don't really care 18:44:11 <andythenorth> min distance is to prevent, e.g. gravel pit next to cement works 18:44:18 <andythenorth> arguably that's valid in RL 18:44:27 <andythenorth> so I'm not sure whether to prevent it or not 18:45:22 <Brot6> FIRS Industry Replacement Set - Feature #1169 (New): locate industries near town (foobar) @ http://dev.openttdcoop.org/issues/1169 18:45:28 <FooBar> well, its not useful for gameplay, as it's not profitable if things are next to each other 18:46:08 <andythenorth> it also causes some station pickup / dropoff issues because stations overlap both industries 18:46:10 <FooBar> well, that's the list in the link 18:46:18 <andythenorth> however about 6 tiles min distance might be enough 18:46:24 * andythenorth reads ticket 18:46:59 <FooBar> I limited it to /classic/ industries, modern industries needn't locate near towns 18:47:30 <FooBar> also the limitation could be lifted after a certain year 18:47:43 <andythenorth> can we play yes / no on these? 18:47:56 <Rubidium> maybe 18:48:03 <andythenorth> I've just updated the ticket btw - indicating the ones done 18:48:05 <FooBar> sure, but in my case all are "yes" :P 18:48:27 <andythenorth> blacksmith: yes 18:48:38 <andythenorth> dock yard: maybe 18:48:54 <andythenorth> actually yes 18:49:08 <Brot6> FIRS Industry Replacement Set - Feature #1169 (New): locate industries near town (foobar) @ http://dev.openttdcoop.org/issues/1169 18:49:10 <andythenorth> furniture factory: no imo 18:49:15 <andythenorth> dairy: no imo 18:49:42 <andythenorth> hmm 18:49:51 * FooBar has phonecall 18:49:55 <andythenorth> :) 18:50:29 <Brot6> FIRS Industry Replacement Set - Feature #1169 (New): locate industries near town (foobar) @ http://dev.openttdcoop.org/issues/1169 19:00:12 <Ammler> the problem with industires near town is, that "near town" doesn't change when a town grows, so you will have no free tiles on big cities anymore to build something 19:14:02 <FooBar> well, that took a while but I'm back 19:14:36 <Alberth1> that was also the case with subsidies, but that is solved 19:15:41 <FooBar> anyways, my basic reasoning for locating towns near those industries is that "back in the days" people lived close to their work, as they had no fast means of transportation. They may have used a bike, or otherwise went on foot 19:17:20 <FooBar> so the restriction could apply until, say, 1950. After that, when cities grow, industries can locate everywhere 19:22:19 <Ammler> or industries are able to clear houses to make space 19:28:50 <Alberth1> that does not help, as the user cannot build a station near it then 19:30:42 <andythenorth> FooBar: it would leave a lot of bare game land....and make for *very* crowded towns 19:31:06 <andythenorth> I'm not specifically against it, but I wouldn't apply it as much as you're proposing, for both gameplay and reality reasons :) 19:31:44 <FooBar> shall we continue the yes/no game and see where we get? 19:32:01 <FooBar> or maybe a yes game from your side if that are less industries :) 19:34:09 <FooBar> Or, for me those would be some sort of minimum: 19:34:11 <FooBar> * bakery (done) 19:34:12 <FooBar> * blacksmith 19:34:14 <FooBar> * brewery (done) 19:34:15 <FooBar> * dock yard 19:34:17 <FooBar> * lumber yard 19:34:19 <FooBar> * fishing harbour (done) 19:34:20 <FooBar> * glass works 19:34:22 <FooBar> * junk yard (done) 19:34:23 <FooBar> * machine shop 19:34:26 <FooBar> * marina 19:34:38 <FooBar> the in-town list still applies 19:37:21 <andythenorth> FooBar how many tiles is "in town"? 19:37:38 <FooBar> replace town building 19:38:15 <FooBar> those things are all one tile, maybe the supermarket 2 tiles 19:38:55 <FooBar> wait, the gas station is 2 tiles as well 19:40:33 <andythenorth> yes 19:40:39 <andythenorth> in-town all make sense 19:40:48 <andythenorth> how near is near-town? 19:42:09 <FooBar> 15 tiles or so I guess 19:43:24 <FooBar> from town edge, not from center 19:43:56 <andythenorth> dock yard: yes 19:44:01 <andythenorth> lumber yard: not sure 19:44:23 <andythenorth> glass works. not sure. Produces goods...how far should they be transported? 19:44:40 <FooBar> to other town also? 19:44:45 <andythenorth> hmm 19:44:47 <andythenorth> maybe 19:45:17 <FooBar> cargodist should help with that in due time 19:45:24 <andythenorth> machine shop: no strong feelings 19:45:26 <andythenorth> marina: yes 19:47:54 <FooBar> looking at cargo, lumber yard and machine shop are very similar, both only produce supplies 19:48:18 <andythenorth> yup 19:48:30 <andythenorth> lumber yard was added to balance machine ship 19:48:32 <andythenorth> shop /s 19:48:38 <andythenorth> machine shop was dominating the whole game 19:49:18 <FooBar> I used both in my recent game 19:49:40 <andythenorth> FooBar: exactly :) 19:52:55 * FooBar ponders if it's useful to cluster secondaries that produce the same thing, like an industrial parks 19:53:29 <andythenorth> it is if they produce same from different inputs 19:53:40 <andythenorth> I had a game with textile mill, foundry etc nearby 19:53:42 <FooBar> that's what I was looking at 19:53:44 <andythenorth> all producing goods 19:53:58 <andythenorth> in my game they happened to cluster like that anyway 19:54:07 <FooBar> for instance paper mill, plastics plant, flass works and metal foundry all produce goods+mnsp 19:54:22 <FooBar> that's glass works by the way :) 19:55:02 <FooBar> dairy/meatpacker/sugarrefinery 19:55:11 <andythenorth> it's a thought 19:55:16 <andythenorth> could be a random chance 19:55:29 <andythenorth> once the code is in place it's quite easy to fool around with clustering 19:55:34 <andythenorth> very boring to test though :P 19:55:51 <FooBar> not necessarily boring, just takes a very long time 19:56:01 <FooBar> i.e. play a game with it and see if it works :) 19:56:30 <FooBar> we could also employ the public for that: if a lot complain, it's no good 19:56:41 <andythenorth> it's quite easy to test clustering - don't need a test game :) Just generate map lots of times :P 19:57:16 <FooBar> oh, that kind of testing :) 19:57:24 <FooBar> I thought like seeing if it's useful 19:58:24 <FooBar> still, using the public could work. For example, I don't test metrotrackset in TTDP, I just assume it works and I assume I will be notified if it doesn't :D 20:01:22 <andythenorth> I just assumed farm clustering would work :) It did 20:02:01 <FooBar> :) 20:02:06 <FooBar> well, there you go 20:02:29 <andythenorth> FooBar: do you know how to implement the location restrictions for the industries you suggested? 20:02:40 <FooBar> I have no clue 20:02:53 <FooBar> I usually tend to suggest things without looking if it's possible 20:03:15 <andythenorth> it's close to easy 20:03:16 <FooBar> thinking out of the box ;) 20:03:22 <andythenorth> there are stubs in place for cb28 already 20:03:30 <andythenorth> there is location code for farms and mines already 20:03:49 <andythenorth> it is just a bit of work to adapt to the industries you suggested 20:03:58 <andythenorth> needs a bit of up-front design though 20:04:13 <andythenorth> want to implement it? 20:04:23 <FooBar> what do you mean by "up-front"? 20:05:10 <FooBar> I don't want to implement it /right now/, but it's something I could tend to in the near-distant future 20:05:39 <andythenorth> FooBar: 'up-front' as in, work out a couple of details first :) 20:05:51 <FooBar> ah ok, makes sense 20:07:25 <FooBar> I do also want to work on a few of my own projects first: reuse the code of metrotrackset for transrapidtrackset. For the latter I also intended to redo the graphics, but I don't fancy drawing at the moment, so that's a good thing (for FIRS) 20:07:47 <andythenorth> np with mr 20:07:48 <andythenorth> me /s 20:08:15 <FooBar> I also have some secret project in mind which involves a base graphics set and maybe one day work. Can't say anything about that yet though 20:09:16 <FooBar> dutch tram set is on hold, as that works reasonably flawless 20:09:45 <FooBar> besides, I rather have someone helping me with that: drawing additional vehicles :P 20:13:44 *** Alberth1 has left #openttdcoop.devzone 20:15:01 <FooBar> I think we'll should put the "locate near town" on ice. It's good to have discussed it, but I think there are more useful things to add first 20:15:08 <Brot6> FIRS Industry Replacement Set - Feature #1170 (New): clustering of certain industries (foobar) @ http://dev.openttdcoop.org/issues/1170 20:19:44 <Brot6> #openttdcoop - Revision 115:29c718d84f0c: [Compiler] Fix: different repo/distro version get diffe... (Ammler) @ http://dev.openttdcoop.org/projects/home/repository/revisions/29c718d84f0c 20:19:44 <Brot6> #openttdcoop - Revision 116:00b8db94ff78: [Compiler] Add parameter -c to clean the chroot (Ammler) @ http://dev.openttdcoop.org/projects/home/repository/revisions/00b8db94ff78 20:20:20 <Brot6> nml-test: compile of r584 failed - http://bundles.openttdcoop.org/nml-test/nightlies/ERROR/r584 20:29:39 *** frosch123 has joined #openttdcoop.devzone 20:35:17 <andythenorth> FooBar: a FIRS game starting in 1830 kind of sucks :) 20:42:01 <FooBar> why? vehicles too slow (or none at all)? 20:42:29 <FooBar> 1900 worked for me last time 20:42:46 <andythenorth> cargo chains...incomplete :) 20:43:00 <andythenorth> UKRS 2 vehicles quite inadequate capacity 20:43:02 <andythenorth> no ships :o 20:45:00 <FooBar> well, I guess some industries are still missing... 20:45:21 <andythenorth> blacksmith could be an easy add 20:46:28 <FooBar> how about adding missing industries as differently coloured boxes? 20:47:06 <FooBar> that way the chains are there, we could look at the economies 20:47:23 <andythenorth> yup 20:47:40 * andythenorth wonders whether to add it to this test game or not 20:47:47 <andythenorth> adding industries is ok 20:47:53 <andythenorth> changing existing ones is not :) 20:48:17 <FooBar> depends what you change really... 20:50:22 <FooBar> but I like the boxes idea. Worked fine for OpenGFX (but in a different way), should also work fine for FIRS as well 20:50:41 <andythenorth> yup 20:53:40 <Brot6> FIRS Industry Replacement Set - Feature #1171 (New): add missing industries as boxes (foobar) @ http://dev.openttdcoop.org/issues/1171 20:54:49 <andythenorth> I'd do the blacksmith now...but bedtime :) 20:55:52 <FooBar> ok, good night! 21:19:27 <Brot6> nml: update from r585 to r606 done - http://bundles.openttdcoop.org/nml/nightlies/r606 21:20:23 <Brot6> NewGRF Meta Language - Revision 606:d994b61bfda8: Revert (r590): the buildsystem doesn't install ... (Ammler) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/d994b61bfda8 21:22:07 *** frosch123 has quit IRC 21:22:09 <Brot6> swedishrails: compile of r140 failed - http://bundles.openttdcoop.org/swedishrails/nightlies/ERROR/r140 21:22:49 <Ammler> Yexo: http://dev.openttdcoop.org/projects/nml/repository/revisions/cdae00abc39f/diff.diff 21:22:52 <Ammler> any idea? 21:23:10 <Ammler> http://bundles.openttdcoop.org/swedishrails/nightlies/ERROR/r140/swedishrails-r140-build.err.log 21:23:21 <Yexo> that's the change yo ujust reverted, right? 21:23:24 <Ammler> wrong paste, this is for you ^ 21:23:30 <Yexo> dunno, alberth committed in the first place 21:23:32 <Ammler> wrong paste, this is for you ^ 21:23:47 <Yexo> working on it already :p 21:23:55 <Ammler> some lags :-) 21:24:06 <Yexo> something to do with my codechanges today :( 21:28:18 <Yexo> fixed 21:29:02 <Ammler> I guess, it is fine enough, using those packages for installation tests 21:29:27 <Ammler> I don't setup a testsuite for nml now, maybe with the release 21:29:30 <Brot6> NewGRF Meta Language - Revision 607:c82daae4d521: Fix (r602): FreeNumberList needs at least one s... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/c82daae4d521 21:30:19 <Ammler> why didn't the regression test find it? 21:30:41 <Yexo> because the regression tests are not extensive enough yet 21:36:03 <Rubidium> Ammler: if you're running regression tests; could you put grfcodec and nforenum through its paces as well? 21:37:29 <Ammler> you mean in the nml test? 21:37:37 <Ammler> or when we setup a testsuite? 21:38:38 <Rubidium> nah, just a rebuild run :) 21:38:55 <Rubidium> I've done some changes all over the code that might backfire under some conditions 21:39:08 <Rubidium> and I rather have that tested before I'm going to do any further work 21:39:20 <Ammler> well, we rather should add the regression test to the packages, so they fail 21:40:24 <Rubidium> don't have enough NFO knowledge to actually get that done :) 21:40:41 <Ammler> using the nml tests? 21:41:46 <Yexo> using the nml tests for nforenum/grfcodec is not a good idea as nml only generates a subset of all valid nfo code 22:07:12 <Ammler> [18:29] <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: 2cctrainset (1 errors), airportsplus, comic-houses (3 errors), firs (5 errors), fish (1 errors), heqs, metrotrackset (1 errors), newgrf_makefile, opengfx, snowlinemod, worldairlinersset <-- isn't this a good confirmation for you then? 22:09:19 <Rubidium> yeah, I'm doing OpenTTD stuff at the moment anyhow :) 22:50:39 *** Seberoth has quit IRC 23:03:21 <Brot6> Metro Track Set - Revision 36:4f02a0bcf83a: Feature: snowy ogfx sprites for railtypes (closes #1168) (foobar) @ http://dev.openttdcoop.org/projects/metrotrackset/repository/revisions/4f02a0bcf83a 23:03:21 <Brot6> Metro Track Set - Bug #1166 (Closed): glitches in non-railtype ogfx bridges (foobar) @ http://dev.openttdcoop.org/issues/1166#change-2985 23:03:21 <Brot6> Metro Track Set - Feature #1168 (Closed): snowy ogfx sprites for railtypes (foobar) @ http://dev.openttdcoop.org/issues/1168#change-2986 23:14:06 *** FooBar has quit IRC