Log for #openttdcoop.devzone on 16th October 2011:
Times are UTC Toggle Colours
00:05:06  <Brot6> Central European Train Set - Feature #3045: Länderbahn rolling stock (michi_cc) @
00:36:27  <Ammler> planetmaker: now you should also convert openttd.grf to nml
00:37:46  <Ammler> as long as your converting experience is fresh ;-)
00:38:36  <Ammler> I would like to drop grfcodec from the suse repo
00:39:39  <Ammler> hmm, this reminds me I should check where nml works...
00:42:03  <Ammler> not on centos5
00:42:42  <Ammler> not on SLE 10
01:12:42  *** JVassie_ has quit IRC
06:40:39  <Rubidium> why drop grfcodec?
06:41:22  <Rubidium> it's the only tool that doesn't require waiting for another version to be useful for state of the art NewGRF development
06:42:23  <Rubidium> having to update nforenum to not warn/error doesn't mean that grfcodec won't work
06:50:10  <Yexo> ^^ that was exactly the result of an earlier discussion
06:52:20  *** andythenorth has joined #openttdcoop.devzone
07:00:28  *** Zuu has joined #openttdcoop.devzone
07:01:10  <Brot6> FISH - Revision 691:641daf1770a9: Fix: refitted capacities were wrong for coasters (incorrect val... (andythenorth) @
07:22:01  *** andythenorth has quit IRC
07:22:16  <Brot6> FISH - Revision 692:a31a32095541: Codechange: prepare for different graphics for large coaster types (andythenorth) @
07:50:07  *** ODM has joined #openttdcoop.devzone
07:50:32  *** andythenorth has joined #openttdcoop.devzone
07:51:01  <andythenorth> it's a shame there's no escape for 'dec value + set 80h to make it a cb result'
08:30:11  <planetmaker> Ammler: not all people like to see openttd.grf converted
08:41:17  <planetmaker> andythenorth: patch grfcodec / nforenum ;-)
08:44:47  * andythenorth bbl
08:44:48  *** andythenorth has quit IRC
10:10:03  *** JVassie_ has joined #openttdcoop.devzone
10:29:03  <Brot6> DACH Trains - Feature #3163: EAOS (Yoshi) @
10:30:51  <Brot6> DACH Trains - Feature #3165 (New): EAOS - GFX (officercrockey) @
10:30:51  <Brot6> DACH Trains - Feature #3166 (New): EAOS - Code (officercrockey) @
11:06:33  <Brot6> DACH Trains - Feature #3163: EAOS (V453000) @
11:20:22  *** Zuu has quit IRC
11:32:35  *** hanf has joined #openttdcoop.devzone
11:49:21  <Brot6> OpenGFX - Bug #3135 (Closed): Lighthouse animation incorrect (planetmaker) @
12:00:34  <Brot6> OpenGFX - Bug #3135 (Closed): Lighthouse animation incorrect (planetmaker) @
12:02:30  <Brot6> DACH Trains - Feature #3165: EAOS - GFX (Yoshi) @
12:25:10  *** andythenorth has joined #openttdcoop.devzone
12:30:59  <V453000> andythenorth: the porcupine 30 hovercraft is _awesome_ !
12:31:11  <andythenorth> :)
12:31:15  <V453000> looks great and the visible containers just add to it :) great job
12:31:28  <andythenorth> there are some other hovercraft unfinished
12:42:42  <Ammler> [10:30] <planetmaker> Ammler: not all people like to see openttd.grf converted <-- well, most people don't buiild it
12:43:18  <Ammler> now we need 2 different tools, it would just make distro building easier
12:45:52  <Ammler> I might drop grfcodec in any case and just don't build the grf anymore...
12:47:24  <planetmaker> any reason to do so?
12:47:52  <Ammler> why should I keep maintaining grfcodec?
12:48:33  <planetmaker> what needs changing?
12:50:00  <Ammler> as I said, just convert openttd.grf to nml
12:51:45  <Ammler> wouldn't it be easiest to do that now?
13:01:14  <Ammler> also it would be nice to make release a bit before openttd, since I need some time to get a new package published in the official suse repo
13:03:25  * andythenorth wonders if grfcodec is going to die
13:06:26  <Ammler> not as long as some people still use it :-=
13:16:58  <planetmaker> at least not quickly
13:33:49  *** frosch123 has joined #openttdcoop.devzone
13:41:44  <Yexo> <Ammler> as I said, just convert openttd.grf to nml <_ that won't be done, for reasons explained earlier
13:42:38  <Yexo> <andythenorth> it's a shame there's no escape for 'dec value + set 80h to make it a cb result' <- just apply the patch in and you can do that
13:43:12  <andythenorth> :o
13:43:12  <Yexo> you would be able to write \w(0x8000 some_num +)
13:44:04  <Ammler> not as long as some people still use it :-=9
13:44:06  <Ammler> :-)
13:44:24  <Ammler> but it does not really matter, as long as openttd provides the grf itself
13:45:07  <Ammler> Hmm, also I did not ask to drop grfcodec
13:45:41  <Ammler> I asked to convert openttd.grf to nml, so I could still build it on the suse repo when I drop grfcodec there
13:46:01  <Yexo> I know you asked for that, and my asnwer was in response to that question
13:46:36  <Ammler> yes, but there is no earlier reason against :-)
13:46:52  <Ammler> Rubidium: spoke about dropping grfcodec
13:47:08  <Yexo> rb's comment from 8:40, and my comments from somewhere this week
13:47:26  <Yexo> I don't see a need to convert openttd.grf, it works fine as it is, and there aren't any big advantages
13:47:42  <Yexo> although grfcodec is still used by quite some people, it's not like everyone is using nml only
13:47:52  <Ammler> well, I would like to keep buiding the whole source
13:48:03  <Yexo> than you'll have to keep packaging grfcodec
13:48:17  <Yexo> there are hardly ever any changes to it, so it should be easy to keep up to date
13:48:19  <Ammler> yep, which I drop
13:48:26  <Yexo> that's your decision
13:49:10  <Ammler> it does not make sense to maintain a package which is needed for a optional building only
13:49:45  <Ammler> I guess, I were the only one building the grf anyway
13:50:08  <Yexo> most likely you and packagers from other distros
13:53:44  <Ammler> I just do not understand why converting openttd.grf to nml means dropping grfcodec, that sounds dramatic...
13:54:10  <frosch123> Ammler: read the discussion from wednesday 12th
13:54:20  <frosch123> it's quite obvious why converting openttd.grf to nml is a no-go
13:54:51  <Yexo> Ammler: you misunderstand the point
13:55:11  <Yexo> nobody else said anything about dropping grfcodec, only you want to drop is from suse
13:58:11  *** andythenorth has quit IRC
14:09:39  <Brot6> DACH Trains - Revision 2:7097047d59eb: SBB EAOS is now complete (officercrockey) @
14:12:09  <Ammler> well, better drop as keep it unmaintained, else you have similar issues as with DaleStan's releases
14:18:42  <Ammler> frosch123: everything I read yet was about why not dropping grfcodec, which I never asked for...
14:20:58  <frosch123> Ammler: my main point was, that do you do not want cicurlar dependencies between nml and openttd
14:21:22  <frosch123> if there is a new feature in ottd which needs new stuff in openttd.grf, what package shall add the feature first?
14:21:28  <frosch123> openttd, openttd.grf or nml?
14:21:39  <frosch123> and who shall wait on whom?
14:21:50  <frosch123> grfcodec otoh does not need any maintenace
14:22:10  <frosch123> nforenum is not exactly a requirement, it is only nice to have
14:23:51  <Ammler> ok, thanks for explaination, now I understand also what Rubi meant
14:25:17  <Ammler> but we have that issue with opengfx now :-P
14:25:52  <frosch123> no, the workflow is openttd.grf -> openttd -> nml -> opengfx
14:26:25  <Ammler> it could be nml -> openttd.grf -> opengfx -> openttd
14:26:30  <Yexo> Ammler: as soon as openttd is changed to need more sprites (or any update to openttd.grf), there will be a single commit (or two consequtive) that changes the openttd code and openttd.grf
14:26:54  <Yexo> opengfx is always a bit delayed
14:27:09  <Yexo> and openttd waiting for opengfx imo makes no sense
14:27:09  <frosch123> Ammler: you mean nml -> openttd.grf -> openttd -> nml -> opengfx -> nml bug fix -> openttd bug fix -> ...
14:27:54  <Ammler> frosch123: yeah, exactly, at least it would make sure, nml and opengfx got a update too
14:28:07  <Yexo> that is exactly the problem
14:28:15  <Yexo> openttd is not responsible for nml and opengfx, not should it be
14:28:27  <frosch123> Ammler: we are not ttdp. we do not commit untested stuff, and wait 5 years for the first grf to use it
14:28:31  <Ammler> frosch123: yeah, exactly, at least it would make sure, nml and opengfx got a update too9
14:29:37  <Ammler> hmm, this laptop is much worse typing "sidewards"
14:32:33  <Ammler> also a generic issue is that extending openttd with graphics still requires original set
14:33:47  *** hanf has quit IRC
14:34:10  <Ammler> openttd.grf*
14:36:24  <Rubidium> Ammler: Debian (and all derivatives) are compiling openttd.grf as well
14:37:33  <Ammler> fedora doesn't
14:38:35  <Rubidium> arch doesn't either. It doesn't even compile opengfx; it just uses the zip
14:39:04  <Ammler> like suse before I made the packages
14:39:50  <Ammler> doe they at least use different packages or pack everything to openttd?
14:40:18  <Ammler> or how tht is called there :-)
14:41:05  <Rubidium> arch has a different package for opengfx
15:41:45  *** JVassie_ has quit IRC
16:01:57  *** JVassie_ has joined #openttdcoop.devzone
16:06:24  *** mib_ta8sqo has joined #openttdcoop.devzone
16:22:30  *** andythenorth has joined #openttdcoop.devzone
16:23:31  *** andythenorth has quit IRC
16:39:48  *** andythenorth has joined #openttdcoop.devzone
16:44:41  *** andythenorth has quit IRC
17:11:00  <Brot6> nml: update from r1698 to r1699 done -
17:15:25  *** andythenorth has joined #openttdcoop.devzone
17:20:49  <planetmaker> 16:26 Yexo: Ammler: as soon as openttd is changed to need more sprites (or any update to openttd.grf), there will be a single commit (or two consequtive) that changes the openttd code and openttd.grf <-- IMHO it can be argued that such commit should also be done for OpenGFX concurrently
17:21:12  <planetmaker> There's IMHO no reason to "prefer" the TTD baseset here over OpenGFX
17:22:23  *** andythenorth has quit IRC
17:24:32  <Yexo> planetmaker: even with an update to opengfx it won't be updated right away
17:24:40  <Yexo> unless you'd make a release for every such case
17:24:48  <planetmaker> which makes sense
17:24:53  <Yexo> that's true
17:25:32  <Yexo> one major difference between openttd.grf and opengfx is the people who are maintaining it
17:25:46  <Yexo> the devs of openttd and the devs of opengfx are two overlapping but distinct groups
17:26:12  <planetmaker> yes... but it sends somehow the bit awkward message that the TTD grf is the "official" base set
17:27:25  <planetmaker> With the same reason it actually can be argued to rename the openttd.grf to ttd_extra.grf and move it to a separate project
17:27:35  <planetmaker> (also the name is kinda funny)
17:27:44  <planetmaker> I know, it's all for hysterical raisons this way
17:32:34  *** hanf has joined #openttdcoop.devzone
17:34:33  <Rubidium> ttd_extra.grf sucks as a name
17:34:52  <Rubidium> first and foremost as it's > 8 characters in length ;)
17:35:24  <Rubidium> which makes it cumbersome to use under DOS
17:36:20  <Brot6> opengfx: update from r835 to r838 done -
17:36:59  <planetmaker> trg1e.grf ;-)
17:37:18  <planetmaker> ttd_xtra.grf
17:38:32  <Rubidium> also... 1:15 (m:ss) doesn't seem like a significant gap between introducing a sprite in trunk and default ;)
17:39:02  <planetmaker> :-)
17:39:56  <Rubidium> though I agree, more than an hour is totally unacceptable!
17:40:07  <Brot6> cets: update from r249 to r262 done (569 warnings) -
17:40:39  <Rubidium> which means that not updating NML within that hour is totally unacceptable as well
17:42:49  <Brot6> fish: update from r687 to r692 done -
17:44:19  <planetmaker> Well. The same way patches for grfcodec are supplied, patches for NML can be supplied
17:45:15  <planetmaker> the arguement "with NML we cannot keep openttd.grf uptodate" can be reversed to "converting opengfx to nml was an error" with that argument you just gave
17:47:59  <Rubidium> well, or to: OpenGFX will (naturally) lag slightly more due to the dependency on NML
17:48:50  <Rubidium> in any case, as soon as the OpenGFX on NML goes stable NML should get a release branch
17:49:27  <planetmaker> it should get one prior to that. But yes, that's what we want
17:49:30  <Rubidium> then minor updates (and fixes) can be pushed quickly via the release branch instead of having a trunk that might not be in a releasable state
17:49:52  <planetmaker> true
17:51:34  <Rubidium> though OpenGFX requires more release of NML or GRFCodec than OpenTTD would; OpenTTD basically only releases once a year
17:53:01  <Brot6> vactrainset: compile of r1 still failed (#3044) -
17:54:57  <planetmaker> well, the reasons to update the base sets are not that frequent either ;-)
18:06:34  <Ammler> why should opengfx need more releases as openttd.grf?
18:07:09  <Ammler> (of NML or grfcodec)
18:08:45  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: ogfx-trains (Diffsize: 36135), narvs (11 warnings) (Diffsize: 39), ogfx-industries (1 warnings), firs, foobarstramtracks (Diffsize: 37022), manindu (Diffsize: 2), newgrf_makefile, rust (Diffsize: 37), ogfx-biggui, dutchtramset (Diffsize: 25988), swisstowns (Diffsize: 39), dutchroadfurniture (Diffsize: 2045), spanishtowns (Diffsize: 8), frenchtowns
18:08:45  <Brot6> (Diffsize: 21), ogfx-rv (Diffsize: 40), ogfx-landscape (2 warnings) (Diffsize: 40), swedishrails (Diffsize: 204), german-townnames (Diffsize: 39), belarusiantowns (Diffsize: 63), indonesiantowns (1 warnings) (Diffsize: 21), airportsplus (Diffsize: 964)
18:09:05  <Rubidium> it releases against the features in trunk of OpenTTD, instead of having a branch that doesn't add support for the newer OpenTTD features (= primarily action5 sprites)
18:10:02  <Rubidium> as such, it is relatively likely that if a new OpenGFX release is made, a new GRFCodec/NML release needs to be made so stable OpenGFX can be compiled with stable GRFCodec/NML
18:11:11  <Rubidium> for OpenTTD there generally only one release of graphics that require a newer GRFCodec to compile
18:11:33  <Rubidium> (where I said GRFCodec I more or less meant the NFORenum tool of the GRFCodec toolset)
18:27:38  <Ammler> planetmaker: if I don't get docs about how to cross compile one of the projects, I am most likely not able to setup it
18:27:53  <Ammler> I can just say, that obs is able to make such binaries
18:28:09  <Ammler> there are a lot windows packages available from obs
18:30:16  <planetmaker> can't you look at the specs of such packages and learn from them?
18:31:06  <Ammler> I yet didn't found one without a configure script :-)(
18:32:01  <Rubidium> how complex is the thing to compile? Does it require libraries?
18:32:13  <Ammler>
18:32:16  <Webster> Title: Packages of windows:mingw:win32 - openSUSE Build Service (at
18:32:21  <Ammler> Rubidium: grfcodec?
18:32:53  <Rubidium> CXX=$mingw_c++_compiler
18:32:56  <planetmaker> ^ so that we'd have nightlies of that, too
18:33:04  <Ammler> Rubidium: yes, that far I am too :-Pé
18:33:11  <Rubidium> oh shoot... libpng
18:33:20  <Ammler> yep, available too
18:33:32  <Rubidium> planetmaker: TrueBrain should just add it to the farm
18:34:12  <planetmaker> yes... but then it's of principle interest. Also for other projects like this new ttd viewer or similar
18:34:22  <Ammler> + CXX=i686-w64-mingw32-g++
18:34:24  <Ammler> + make -j8
18:34:25  <Ammler> [LD] objs/endian_check
18:34:27  <Ammler> src/endian_check.cpp:9:19: fatal error: stdio.h: No such file or directory
18:35:13  <Rubidium> w64 works?
18:35:22  <Rubidium> I thought that wasn't really stable yet
18:35:31  <Ammler> hmm?
18:35:47  <Rubidium> you're compiling win64 binaries there
18:36:07  <Rubidium> looking at the Makefile it doesn't support cross compiling
18:38:00  <Rubidium> though it looks like the compiler is badly configured as it can't find it's own "base" headers, which is something that's backed in the compiler's binary
19:02:52  <Brot6> clientpatches: compile of r23032 still failed (#2964) -
19:04:57  <Brot6> serverpatches: compile of r23032 still failed (#2966) -
19:06:04  *** andythenorth has joined #openttdcoop.devzone
19:07:10  <Brot6> 32bpp-ez-patches: compile of r23032 still failed (#2446) -
20:01:31  *** LordAro has joined #openttdcoop.devzone
20:14:43  <Brot6> FISH - Revision 693:f86fae38d9c7: Feature: set correct intro dates for vehicle ferries (andythenorth) @
20:14:43  <Brot6> FISH - Revision 694:e8af58bdea7b: Codechange: add source psds for additional generations of large... (andythenorth) @
20:25:12  <Ammler> at least, it is installed: /usr/lib/gcc/i686-w64-mingw32/4.6.1/include/c++/tr1/stdio.h
20:26:50  <Terkhen> nice :)
20:27:14  <Ammler> how is that nice? :-P
20:30:47  <Ammler> I somehow might need to tell make the include path
20:32:20  * Rubidium wonders whether dogfooding is employed by those making the cross compilers
20:35:51  <Terkhen> expending effort on something and finishing it is nice :P
20:36:08  <Ammler> finishing?
20:44:14  <Terkhen> you said it is installed ;)
20:47:07  <Brot6> Central European Train Set - Revision 263:e1f33fa7a661: added remaining A2 liveries (oberhuemer) @
20:51:30  <Brot6> cets: update from r262 to r263 done (569 warnings) -
20:55:10  <Brot6> Central European Train Set - Revision 264:11e0574bbd72: change: tracking table update for A2 (oberhuemer) @
20:57:29  <Brot6> Central European Train Set - Bug #3167 (New): DevZone compile failed (compiler) @
21:01:59  *** andythenorth has quit IRC
21:02:45  <Brot6> Central European Train Set - Revision 265:fceffc9543fb: fix: no numbers in variant names? (oberhuemer) @
21:06:11  <Brot6> cets: update from r263 to r265 done (569 warnings) -
21:10:01  <Brot6> Central European Train Set - Bug #3167 (Closed): DevZone compile failed (compiler) @
21:10:01  <Brot6> Central European Train Set - Bug #3167 (Closed): DevZone compile failed (oberhuemer) @
21:13:13  <Brot6> Central European Train Set - Bug #3167: DevZone compile failed (Eddi) @
21:24:35  *** frosch123 has quit IRC
21:28:25  *** LordAro has quit IRC
21:58:10  <Brot6> Central European Train Set - Bug #3167: DevZone compile failed (oberhuemer) @
21:59:03  <Brot6> Central European Train Set - Feature #3105: Länderbahn electric engines and MUs (oberhuemer) @
22:03:30  *** ODM has quit IRC
22:30:45  *** JVassie_ has quit IRC
22:36:55  *** KenjiE20 has quit IRC
22:37:25  *** KenjiE20 has joined #openttdcoop.devzone

Powered by YARRSTE version: svn-trunk