Config
Log for #openttdcoop.devzone on 23rd March 2011:
Times are UTC Toggle Colours
00:00:08  <Hirundo> I guess I did not test hard enough back then....
00:01:05  <Yexo> Hirundo: the curious thing is that it has been reported in the opengfx+trains topic 2 times today
00:01:18  <Yexo> but not before, so either nobody noticed it in all that time or another commit broke it
00:02:38  <Hirundo> hmmm yes, there have been NML base cost grfs around
00:05:22  <Hirundo> I think this is the culprit: http://hg.openttdcoop.org/nml/rev/076359704a37
00:06:02  <Hirundo> In that case, other stuff might be affected too
00:06:26  <Yexo> ah, yes, that one caused it indeed
00:06:55  <Hirundo> I'll check
00:06:57  <Yexo>   1.58 +    offset += size <- that is wrong
00:07:36  <Yexo> when size == 3, it should skip 3 bytes
00:07:45  <Yexo> s/== 3/== 2/
00:08:36  <Hirundo> No it's right, offset is adjusted also (either 5 or 4)
00:08:47  <Yexo> oh, right :)
00:12:14  <Hirundo> Snowline might be bugged also, not sure *testing*
00:12:18  <Brot6> NewGRF Meta Language - Revision 1301:bdb07b24033e: Fix r1226: same fix as r1300 but for the snowl... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/bdb07b24033e
00:12:19  <Yexo> just fixed that one
00:12:48  <Yexo> the rest is all correct
00:12:59  <Yexo> there are only 3 functions in action0.py that use action6
00:13:12  <Yexo> the 'default' action0 property block, snowline table and basecost table
00:15:06  <Hirundo> While testing, I did get some internal divide-by-zero error
00:15:48  <Yexo> hmm, that's actually easy to reproduce
00:16:04  <Yexo> param[0] = 3 / 0; <- just that
00:19:14  <Yexo> param[0] = hasbit(3,-1); <- gives internal error: (ValueError) "negative shift count".
00:19:52  <Yexo> something for later
00:19:54  <Yexo> good night
00:21:52  <Hirundo> goodnight
00:22:05  <Brot6> NewGRF Meta Language - Bug #2457 (New): Divide by zero / shift by negative amount (Hirundo) @ http://dev.openttdcoop.org/issues/2457
00:33:50  <Brot6> NewGRF Meta Language - Bug #2458 (New): Internal error: Divide by zero in snowline code (Hirundo) @ http://dev.openttdcoop.org/issues/2458
01:16:47  *** KenjiE20 has quit IRC
06:15:52  *** andythenorth has joined #openttdcoop.devzone
06:16:00  *** andythenorth has quit IRC
06:20:08  *** supermop has quit IRC
07:01:10  <Brot6> OpenGFX+ Trains - Revision 235:a96c255b3861: Doc: Some more comments and some better variable names (planetmaker) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/a96c255b3861
07:09:07  <planetmaker> thanks for the quick fix(es), Yexo :-)
07:13:28  <Brot6> OpenGFX+ Trains - Revision 236:3dcc11a7946a: Doc: Prepare changelog for 0.2.4 (planetmaker) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/3dcc11a7946a
07:13:28  <Brot6> OpenGFX+ Trains - Revision 237:644ad99997a0: Added tag 0.2.4 for changeset 3dcc11a7946a (planetmaker) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/644ad99997a0
07:14:57  <Brot6> ogfx-trains: update from 0.2.3 to 0.2.4 done - http://bundles.openttdcoop.org/ogfx-trains/releases/0.2.4
07:34:46  *** andythenorth has joined #openttdcoop.devzone
07:42:35  <Brot6> FIRS Industry Replacement Set - Revision 1882:438bcc7a0e91: Change: add Recycling Depot industry (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/438bcc7a0e91
07:46:36  <Brot6> FIRS Industry Replacement Set - Revision 1883:63e81d68d0e5: Change: set fund cost for Recycling D... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/63e81d68d0e5
07:48:11  <andythenorth> hmm
08:47:29  *** andythenorth has quit IRC
09:22:15  <Brot6> 2cc train set - Feature #56: rework region availability parameter (EmperorJake) @ http://dev.openttdcoop.org/issues/56#change-6352
09:51:25  *** andythenorth has joined #openttdcoop.devzone
09:53:42  <Ammler> nml needs a minversion for nml itself ;-)
09:54:36  <planetmaker> well, not really. It just has the issue which every compiler has: different versions give different binary output
09:54:47  <planetmaker> but that matters for grfs. For a binary it doesn't
09:54:55  <planetmaker> s/binary/executable/
09:58:31  *** andythenorth_ has joined #openttdcoop.devzone
09:58:31  *** andythenorth has quit IRC
10:01:19  <Ammler> well, that is a common thing, for openttd we have "BuildRequires: grfcodec >= 5.1"
10:02:18  <Ammler> nml could have such a properity too and fail if the version is lower
10:03:01  <Ammler> grf { minnmlc: 1301; }
10:04:03  <Ammler> that way, your issue would have solved automatically
10:08:28  <planetmaker> hm. yes, maybe
10:08:31  <Brot6> NewGRF Meta Language - Feature Request #2459 (New): properity for minimum required nmlc to build (Ammler) @ http://dev.openttdcoop.org/issues/2459
10:10:27  <Brot6> NewGRF Meta Language - Feature Request #2459: properity for minimum required nmlc to build (Ammler) @ http://dev.openttdcoop.org/issues/2459#change-6353
10:42:06  * andythenorth_ ponders
10:42:16  <andythenorth_> recyclables -> recycling plant: done
10:42:23  <andythenorth_> recyclables -> glass works?
10:42:32  <andythenorth_> recyclables -> plastics plant?
10:43:43  <andythenorth_> recyclables -> biorefinery (biomass processor)
10:45:01  <andythenorth_> and also
10:45:16  <andythenorth_> 1t production of recyclables per 16 units population
10:45:18  <andythenorth_> ?
10:46:59  <V453000> @calc 10000/16
10:46:59  <Webster> V453000: 625
10:47:29  <V453000> sounds reasonable :)
10:47:31  <andythenorth_> @calc 400/16
10:47:31  <Webster> andythenorth_: 25
10:47:44  <andythenorth_> could be quite interesting
10:47:50  <andythenorth_> small towns = 1 truck per month
10:47:54  <andythenorth_> big towns = trains
10:48:03  <andythenorth_> cities = multiple trains
10:48:34  <V453000> seems good
10:48:52  <andythenorth_> or 1/12
10:48:55  <andythenorth_> I'll test
10:49:22  <V453000> @calc 10000/12
10:49:22  <Webster> V453000: 833.333333333
10:49:38  <andythenorth_> @calc 400/12
10:49:38  <Webster> andythenorth_: 33.3333333333
10:53:12  <andythenorth_> 1x2 tiles, or 2x2 ?
10:53:19  <andythenorth_> I am thinking it is like this: http://maps.google.co.uk/maps?hl=en&ie=UTF8&ll=51.455257,-2.571707&spn=0.001825,0.004549&t=h&z=18
10:53:28  <andythenorth_> probably a limit of one per city
10:55:36  <andythenorth_> 2x2 works
10:59:12  * andythenorth_ decides that recyclables only accepted at recycling plant
10:59:31  <andythenorth_> the point is to cause players to have fun with an entirely new chain
11:02:24  <Brot6> FIRS Industry Replacement Set - Feature #2460 (Rejected): Recyclables could be accepted by Glass ... (andythenorth) @ http://dev.openttdcoop.org/issues/2460
11:12:42  <Brot6> FIRS Industry Replacement Set - Revision 1884:9f2a86993f97: Change: set layout for Recycling Depot (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/9f2a86993f97
11:17:04  <Brot6> NewGRF Meta Language - Feature Request #2459: properity for minimum required nmlc to build (yexo) @ http://dev.openttdcoop.org/issues/2459#change-6354
11:29:42  <Yexo> Ammler: imo a version check is something for the build system
11:33:33  <planetmaker> hm, probably
11:35:36  * andythenorth_ is offering sale prices on FIRS 0.7.0 tickets ;)
11:35:37  <andythenorth_> http://dev.openttdcoop.org/versions/show/145
11:53:00  *** KenjiE20 has joined #openttdcoop.devzone
12:11:39  <Ammler> Yexo: not really
12:12:00  <Ammler> or how should the build system know, which version your nml needs?
12:12:13  <planetmaker> makefile.config
12:12:45  <Ammler> and if you download the source of ogfx-trains, how do you know, which vesion you need at home? :-P
12:13:01  <Ammler> well, then update the Makefile
12:13:29  <Yexo> normally that the version would be checked in a configure script, if there was one
12:14:08  <Ammler> oh, but I agree on the ActionC thing
12:14:15  <Ammler> that is of course not good
12:14:50  <Ammler> Yexo: how can nmlc fail without reading the nml?
12:15:20  <Yexo> what do you mean? of course it won't fail without reading the nml
12:15:24  <Ammler> IMO, it needs to read the nml to find that the syntax is too new ;-)
12:15:57  <Yexo> but there is no difference between "new, unsupported in this version"-syntax and "user typed something wrong"-syntax errors
12:16:06  <Yexo> at least no difference that nml can detect
12:16:28  <Ammler> well, that is no need, if it fails because of wrong/unknown syntax
12:16:44  <Ammler> that is fine, the issue is if it wouldn't fail
12:17:04  <Ammler> it only needs to fail _if_ the synstx is ok
12:17:23  <Yexo> if it wouldn't fail there wouldn't be a problem, would there?
12:17:31  <Ammler> ogfx-trains has one
12:17:42  <Ammler> build doesn't fail
12:18:11  <Yexo> ah, due to bugs in nml you mean
12:18:18  <Yexo> imo that is not a job for all grf projects to fix
12:18:19  <Ammler> not necessary bugs
12:18:28  <Ammler> could also be simply spec change or wahtever
12:19:02  <Yexo> I don't expect any spec changes that won't result in older nml versions failing to compile
12:19:03  <Ammler> the point is there should be a way to tell a nmlc user that he needs to update
12:19:24  <Yexo> does grfcodec have something for that? or nforenum? of gcc?
12:19:50  <Yexo> see openttd/gcc, the configure script checks the version and prints an error if the version is too low
12:19:54  <Ammler> can't nml be better?
12:20:08  <Yexo> but it's not better
12:20:17  <Yexo> it ties the spec of the language to a single implementation
12:20:22  <Ammler> there is no disadvantage :-)
12:20:34  <Yexo> not that I expect another implementation ever for nml, but that's not the point
12:20:37  <Ammler> there are a lot tools, which check current version
12:20:49  <Ammler> e.g. addons for firefox :-)
12:21:11  <Yexo> yes, but those are specific for one product, firefox
12:21:33  <Yexo> grf-projects codec in nml are not specific for "current nmlc implementation in python", but written for "nml-spec"
12:22:01  <Ammler> please tell me one negative point about except the needed work?
12:22:07  <Yexo> so if there would be a version field in nml files it should be an independent "spec-version" field, not "revision of nml repo"-field
12:22:19  <Yexo> <Yexo> it ties the spec of the language to a single implementation
12:22:28  <Yexo> and the fact that imo it conceptually doesn't belong there
12:22:32  <Ammler> ah indeed
12:22:35  <Ammler> nfo does use it too
12:22:57  <Yexo> nfo has a "spec-version" at the top of the nfo file, not a version of grfcodec/nforenum needed to compile the file
12:23:10  <Ammler> yes, then take it as that
12:23:59  <Yexo> the problem with that is most likely for a new spec version nml will fail to detect the version field as it wouldn't be able to parse the file, although that might not be such a big problem
12:24:04  <Yexo> fail in that case is expected
12:24:27  <Ammler> as said, the problem is if it doesn't fail
12:25:59  <Ammler> so shall I move the ticket to the makefile framwork? :-P
12:26:09  <Yexo> no, leave it for nml for a while
12:27:35  <Ammler> I still dream that nmlc will somewhen we able to use without the makefile framwork, though :-)
12:28:41  <Ammler> maybe a 2nd tool nmlpp ;-)
12:29:32  <Yexo> the makefile framework is currently only used to have a preprocessor
12:29:54  <Yexo> writing a small preprocessor in python should be quite easy
12:30:07  <Yexo> not that interesting though since we already have a working solution
12:30:53  <planetmaker> well, besides pre-processor it also handles the bundling, versioning etc pp
12:31:12  <planetmaker> All that would need re-invention
12:31:22  <planetmaker> which would sum up to the same thing mostly
12:31:23  <Yexo> hmm, true :)
12:31:31  <Yexo> it's so easy to forget all those nice things that "just work" :)
12:31:59  <Yexo> so indeed, without makefile framework will probably never happen
12:32:00  <planetmaker> :-)
12:34:32  <planetmaker> Most importantly though: things would not get easier really if it was directly integrated in nml
12:35:19  <planetmaker> every project will need some sort of configure
12:35:44  <planetmaker> that, of course, could be done differently. Now it's all in makefile.config
12:36:38  <planetmaker> (or at least I don't see how it could really be made much easier, even if (re-)written)
12:39:54  <planetmaker> But I guess when Ammler says "without makefile framework" he means only "without the use of the gcc preprocessor"
12:40:27  <Yexo> in that case, as I said, a preprocessor is easily written
12:41:53  <planetmaker> it would probably suffice to handle
12:41:57  <planetmaker> #define XY bla bla
12:42:04  <Yexo> and includes
12:42:08  <planetmaker> and #include "path/to/blub.x"
12:42:13  <planetmaker> yup
12:46:05  <Ammler> well, not without makefile framework, but without make/gcc and friends
12:46:28  <Ammler> well, not without makefile framework, but without make/gcc and friends
12:46:42  <planetmaker> you can. Just don't use #define and #include
12:47:06  <planetmaker> and you'll have to do without automatic versioning, installation and bundling
12:47:17  <Ammler> yeah, either nmlc does do that or another (python) tool is needed
12:47:55  <planetmaker> I could see nmlc handling #define and #include
12:48:01  <Ammler> (not the bundling, but substitute and include)
12:48:09  <Ammler> yes :-)
12:48:09  <planetmaker> But I don't see nmlc doing anything like versioning and installation services
12:48:50  <Ammler> I think the bundling part isn't really needed for developers
12:49:21  <Ammler> and then you could still use make for that :-)
12:49:28  <Yexo> maybe not, but it's necessary to build nightlies on the cf
12:49:53  <Brot6> 2cc train set - Feature #56: rework region availability parameter (Voyager1) @ http://dev.openttdcoop.org/issues/56#change-6355
12:50:05  <Yexo> take supermop as example, he doesn't use make/gcc but does use nml
12:50:25  <planetmaker> the one thing which you'd still need as developer IMHO is setting the version automatically. But people like ^ will do without
12:50:33  <planetmaker> most do without that when programming anyway
12:51:58  <Ammler> IMO, we "abuse" make
12:52:18  <planetmaker> we use it for what it is made
12:52:33  <Ammler> nah, it is not make for templating :-)
12:52:37  <Ammler> made*
12:53:16  <Ammler> the "if" is made for building different architectures etc.
12:53:51  <Ammler> like openttd uses cpp
12:55:33  <Ammler> there include is part of gcc, right?
12:55:38  <planetmaker> well, that could be seen as such. Though you'd wonder where OpenTTD uses templates ;-)
12:56:16  <planetmaker> Ammler, openttd and the makefiles here use the same part of gcc to include files ;-)
12:56:43  <Ammler> yes, gcc not cpp, like nml should use nmlc not cpp :-P
12:57:52  <Ammler> or does your framweork gcc somewhere?
12:58:24  <Ammler> well, I meant the tool, which compiles cpp code
12:58:25  <planetmaker> cpp is part of gcc
12:58:37  <planetmaker> it's the same binary ;-)
12:58:51  <Ammler> ah ok, but you know what I mean :-P
12:58:52  <planetmaker> cpp = c pre processor
12:59:31  <Ammler> the include stuff in openttd is not made with pre processing, right?
12:59:49  <planetmaker> of course it is
12:59:58  <Ammler> except the part which is meant to pre process like dedicated stuff etc.
13:00:03  <planetmaker> gcc/cpp processes all includes
13:00:14  <Ammler> hmm
13:00:17  <planetmaker> and then this pre-processed code is compiled
13:00:21  <planetmaker> that's how the compiler works
13:00:51  <Ammler> I thought, there are different includes used for headers etc.
13:01:33  <planetmaker> thus each object file is compiled from the pre-processed corresponding cpp file
13:02:27  <Ammler> well, then my "dream" does even make more sense,
13:02:42  <Ammler> include pre processing to nmlc :-)
13:04:19  <planetmaker> the processing of #include and #define: yes
13:04:51  <Ammler> what else?
13:06:00  <Ammler> basically that you can replace "gcc -E" with "nmlc -E" :-P
13:07:42  <Ammler> but I have a binary cpp here
13:10:10  <Ammler> is cpp just a wrapper to gcc -E?
13:10:42  <Ammler> no
13:11:45  <Brot6> NewGRF Meta Language - Feature Request #2459: properity for minimum required nmlc to build (Ammler) @ http://dev.openttdcoop.org/issues/2459#change-6353
13:13:42  <Brot6> Example NewGRF Project - Feature Request #2461 (New): properity for minimum required nmlc to build (Ammler) @ http://dev.openttdcoop.org/issues/2461
13:14:06  <Ammler> hmm, didn't work as I liked --> delete
13:14:11  <Brot6> NewGRF Meta Language - Feature Request #2351: building of win32 executable for nml (Ammler) @ http://dev.openttdcoop.org/issues/2351#change-6339
13:42:35  *** andythenorth_ has quit IRC
14:40:01  *** andythenorth has joined #openttdcoop.devzone
14:56:12  *** andythenorth has quit IRC
15:01:22  *** andythenorth has joined #openttdcoop.devzone
15:58:23  * andythenorth ponders
15:58:32  <andythenorth> can I bothered to write cb14c check?
15:58:50  <andythenorth> I need one fixed cargo and one random cargo from a list
15:58:57  <andythenorth> and I have to check var 10 as well
15:59:05  <andythenorth> sounds like two varaction 2s to me
15:59:28  <andythenorth> Yexo: is cb14c implemented in nml?
16:01:33  <Yexo> no callback is explicitly implemented in nml, but you can implement all callbacks you want via switch-blocks (=varaction2)
16:02:14  <andythenorth> was looking for a sub-contractor :D
16:02:21  <andythenorth> I should do it myself though :P
16:02:31  <andythenorth> I have to insert it to FIRS template structure
16:02:32  <Yexo> was do you need exactly?
16:02:39  <Yexo> no use for nml there
16:03:01  <Yexo> one static cargo, the other one chosen from a list with fixed size?
16:03:04  <andythenorth> was thinking maybe you needed an excuse to understand cb14c in nfo ;)
16:03:06  <andythenorth> yes
16:03:20  <Yexo> if you assign the ticket to me I'll code it later tonight
16:03:33  <andythenorth> ok thanks
16:04:22  <andythenorth> Yexo: fancy making an industry production depend on town size?
16:04:26  <andythenorth> again not hard, I'm just lazy
16:04:39  <Yexo> is the town size exposed to industries?
16:04:42  <andythenorth> and I have a baby who contends for time
16:04:47  <andythenorth> I think so
16:04:49  <andythenorth> I'll check
16:04:54  <andythenorth> it's related object of the industry
16:05:35  <andythenorth> var 82 of cities
16:05:37  <andythenorth> http://wiki.ttdpatch.net/tiki-index.php?page=VarAction2Cities
16:06:14  <Yexo> not so hard indeed if you have a good specification
16:06:32  <andythenorth> I'll write tickets
16:06:34  <Yexo> like 0..1000 population: produce X, 1000..3000 pop: produce Y, otherwise produce Z
16:07:00  * andythenorth is unbelievably lazy
16:07:14  <andythenorth> Yexo: simply: production = popn / 16
16:07:24  <Yexo> even easier :)
16:07:43  <andythenorth> but that's per month, so adjusted for production cycle
16:07:53  <Yexo> so again / 8 ?
16:08:23  <planetmaker> (.../8)+1
16:08:25  <planetmaker> ;-)
16:08:25  <Yexo> that'll get ugly for very small towns though, so probably not good
16:08:57  <planetmaker> or max(.../8,1)
16:09:08  <Yexo> ((pop >> 4) + 7) / 8 <- a single advanced varaction2 var
16:10:23  <Brot6> FIRS Industry Replacement Set - Feature #2462 (New): Recycling Depot production to depend on town... (andythenorth) @ http://dev.openttdcoop.org/issues/2462
16:17:30  <andythenorth> hmm
16:17:44  <andythenorth> is it better if recycling plant produces 1 predictable and 1 random cargo?  or 2 random?
16:19:28  <Brot6> FIRS Industry Replacement Set - Feature #2463 (New): Recycling plant to randomise 2nd output carg... (andythenorth) @ http://dev.openttdcoop.org/issues/2463
16:21:24  <andythenorth> hmm
16:21:33  * andythenorth made small oversight
16:21:40  <andythenorth> nvm
16:26:18  * andythenorth can't figure out how to optionally handle cb14c in production template 
16:26:57  <andythenorth> if I use #ifdef, my range count it going to be wrong
16:27:11  <andythenorth> in the cases where 14c is not used
16:27:16  <andythenorth> it / is /s
16:28:14  <Yexo> you'll need to ifdef the range count too
16:28:40  * andythenorth wonders if there's a cb that can be handled that just says 'fail'
16:28:51  <andythenorth> for the #ifndef case
16:29:04  <Yexo> most of the time returning the 'real' graphics is failing
16:29:15  <andythenorth> I'd need a value to check though
16:29:41  <andythenorth> is there a value guaranteed to never be a real cb?
16:30:06  <andythenorth> FFFFh ?
16:30:09  <Yexo> 0x3E  .. 0x13F ?
16:30:44  <andythenorth> it's one of those decisions that can cause severe 'wft' in later years if I do it wrong
16:30:56  <andythenorth> wtf even
16:31:02  <Yexo> value 0 is defined in the openttd code as CBID_NO_CALLBACK
16:31:14  <andythenorth> that's interesting
16:31:18  <andythenorth>     C1 00   00 00   00 00 //handle production cb chain
16:31:36  <Yexo> just make sure the default points to C1 00 too if you do that
16:31:42  <Yexo> otherwise you might get interesting results
16:31:43  <andythenorth> if I use 0, production cb will run twice?
16:31:47  <Yexo> no
16:32:01  <andythenorth> range check means only handled once?
16:32:29  <Yexo> it's always only called once, a newgrf can't influence that
16:32:56  <Yexo> cb nubmers 02 .. 0F are also unused
16:33:13  <andythenorth> maybe I use 0F and leave notes
16:35:43  <Yexo> why not simply use an ifdef for the number of ranges too?
16:36:36  <andythenorth> makes the action 2 uglier
16:36:39  <Yexo> anyway, I have to go now
16:36:44  <andythenorth> np
16:36:52  <andythenorth> bye
16:46:47  <Brot6> FIRS Industry Replacement Set - Revision 1885:2e5936860c92: Change: add support for handling cb 1... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/2e5936860c92
16:46:51  <andythenorth> ^ugly
16:49:38  <Ammler> is there no #else?
16:50:06  <andythenorth> it's ugly to ifdef a range check for one case
16:50:11  <andythenorth> what if there are other cases?
16:50:17  <Brot6> FIRS Industry Replacement Set - Revision 1886:aba2153da046: Change: extend support for cb 14C (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/aba2153da046
16:50:18  <andythenorth> scales very badly
16:55:02  *** Desrik has joined #openttdcoop.devzone
16:56:59  *** Desrik has quit IRC
16:57:14  <Ammler> andythenorth: couldn't nforenum "fix" the range count?
16:57:35  <Ammler> or does it just error if it is wrong?
16:57:41  <andythenorth> from the compiled nfo?
16:57:41  <planetmaker> not really. It's an error
16:57:53  <Ammler> planetmaker: does it make sense?
16:58:28  <Ammler> maybe a FR is required ;-)
17:03:03  <Brot6> FIRS Industry Replacement Set - Feature #2463 (New): Recycling plant to randomise 2nd output carg... (andythenorth) @ http://dev.openttdcoop.org/issues/2463
17:07:11  * andythenorth has resolve conflicts
17:09:28  <Yexo> andythenorth: did you test whether that actually compiles?
17:09:41  <andythenorth> appears to
17:09:44  <Yexo> from r1885 it looks like it expects THIS_HANDLECB14C to be a word, while in r1886 you define it to be a byte
17:09:54  <andythenorth> that was a MISTAKE :D
17:10:00  <andythenorth> fixing it
17:10:41  <Brot6> FIRS Industry Replacement Set - Revision 1887:9b7387204ef6: Change: remove recycling plant pnfo t... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/9b7387204ef6
17:10:41  <Brot6> FIRS Industry Replacement Set - Revision 1888:d3c54fd5301b: Add: recycling plant pnfo - fixes mer... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/d3c54fd5301b
17:10:44  * Yexo is gone again for training, will be back later tonight
17:10:49  <andythenorth> enjoy
17:11:04  * andythenorth invents ever worse ways to deal with merge conflicts
17:11:36  <andythenorth> one day I'll grok it
17:11:57  <Brot6> nml: update from r1298 to r1301 done - http://bundles.openttdcoop.org/nml/nightlies/r1301
17:13:10  <Brot6> firs: update from r1878 to r1888 done - http://bundles.openttdcoop.org/firs/nightlies/r1888
17:18:09  <Brot6> ai-aroai: update from r22 to r23 done - http://bundles.openttdcoop.org/ai-aroai/nightlies/r23
17:18:35  <Brot6> FIRS Industry Replacement Set - Revision 1889:17fd733fc841: Change: use neighbour spacing check f... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/17fd733fc841
17:19:28  <Brot6> firs: update from r1888 to r1889 done - http://bundles.openttdcoop.org/firs/nightlies/r1889
17:19:58  <Brot6> ogfx-trains: update from r234 to r237 done - http://bundles.openttdcoop.org/ogfx-trains/nightlies/r237
17:20:05  <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r750), 32bpp-extra (r39), ai-admiralai (r75), ailib-common (r21), ailib-direction (r17), ailib-list (r32), ailib-string (r29), ailib-tile (r16), airportsplus (r73), basecosts (r22), belarusiantowns (r8), bros (r52), chips (r82), comic-houses (r71), fish (r617), frenchtowns (r6), grfcodec (r828), heqs (r580), indonesiantowns (r41), manindu (r7), metrotrackset (r56), narvs
17:20:05  <Brot6> (r29), newgrf_makefile (r265), nml (r1301), nutracks (r179), ogfx-industries (r12), ogfx-landscape (r58), ogfx-rv (r80), ogfx-trees (r42), opengfx (r618), openmsx (r97), opensfx (r97), smts (r19), snowlinemod (r49), spanishtowns (r10), swedishrails (r198), swisstowns (r22), transrapidtrackset (r15), ttdviewer (r26), ttrs (r36), worldairlinersset (r671)
17:22:18  <Brot6> FIRS Industry Replacement Set - Revision 1890:c97f5fac35f2: Change: use different ground tile for... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/c97f5fac35f2
17:22:39  <Brot6> ogfx-landscape: rebuild of r58 done (Diffsize: 7) (DiffDiffsize: 8) - http://bundles.openttdcoop.org/ogfx-landscape/nightlies/r58/log
17:22:52  <Brot6> ogfx-rv: rebuild of r80 done (Diffsize: 7) (DiffDiffsize: 10) - http://bundles.openttdcoop.org/ogfx-rv/nightlies/r80/log
17:23:43  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: airportsplus (Diffsize: 1), belarusiantowns (Diffsize: 30), frenchtowns, indonesiantowns (1 errors) (Diffsize: 1), manindu (Diffsize: 1), narvs (Diffsize: 1), newgrf_makefile, ogfx-industries (Diffsize: 1), spanishtowns (Diffsize: 1), swedishrails (Diffsize: 7), swisstowns (Diffsize: 156)
17:25:53  <Ammler> hmm, btw., you were aware that newer nml changed teh grf :-)
17:51:30  <Ammler> \o/ redmine has raw file view mode now, I should update :-)
17:56:19  *** frosch123 has joined #openttdcoop.devzone
18:22:46  *** Brot6 has quit IRC
18:36:35  *** ODM has joined #openttdcoop.devzone
20:04:33  *** andythenorth has quit IRC
20:11:47  *** andythenorth has joined #openttdcoop.devzone
20:25:59  *** andythenorth has quit IRC
20:29:58  *** andythenorth has joined #openttdcoop.devzone
20:59:28  *** andythenorth has quit IRC
21:55:11  <Yexo> Ammler: why is brot no longer here?
21:55:24  <Rubidium> he's been bad
21:56:41  <Ammler> Rubidium: you made him (it) bad?
21:57:19  <Rubidium> yeah, I'm always at fault
21:59:39  <frosch123> maybe he did not get enough flour soup here, and left
22:02:08  *** Brot6 has joined #openttdcoop.devzone
22:03:05  *** frosch123 has quit IRC
22:03:55  <Ammler> errerror logs don't complain either
22:23:15  *** thgergo has joined #openttdcoop.devzone
22:30:55  *** ODM has quit IRC
22:42:04  <Brot6> FIRS Industry Replacement Set - Revision 1893:5690cfa73b87: Feature #2462: recycling depot produc... (yexo) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/5690cfa73b87
22:44:58  <Brot6> FIRS Industry Replacement Set - Feature #2462: Recycling Depot production to depend on town size (yexo) @ http://dev.openttdcoop.org/issues/2462#change-6358
23:00:14  <Brot6> FIRS Industry Replacement Set - Feature #2463 (Closed): Recycling plant to randomise 2nd output c... (andythenorth) @ http://dev.openttdcoop.org/issues/2463
23:00:14  <Brot6> FIRS Industry Replacement Set - Feature #2463 (Closed): Recycling plant to randomise 2nd output c... (yexo) @ http://dev.openttdcoop.org/issues/2463#change-6359
23:00:14  <Brot6> FIRS Industry Replacement Set - Revision 1894:fb95b1ce9d7a: Feature #2463: recycling plant has ra... (yexo) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/fb95b1ce9d7a

Powered by YARRSTE version: svn-trunk