Log for #openttdcoop.devzone on 11th October 2011:
Times are UTC Toggle Colours
01:41:22  <Brot6> OpenGFX - Feature #3136: toyland ground tile reused identically (athanasios) @
06:48:58  <Brot6> NewGRF Viewer - Code Review #3126: do not add binaries to source repo (Ammler) @
07:45:28  <Brot6> NewGRF Viewer - Revision 0:e3b1aa87d09a: First commit. Some revision history absent but nothing i... (UnicycleBloke) @
07:45:28  <Brot6> NewGRF Viewer - Revision 1:5625a0e4ec1c: Restored files which appear to have been lost in a VM cr... (UnicycleBloke) @
07:45:28  <Brot6> NewGRF Viewer - Revision 2:8c32057dec04: Added functions to write actions. WIP. (UnicycleBloke) @
07:45:30  <Brot6> NewGRF Viewer - Revision 3:4b92309b7f65: Couple of tiddlers reported by mingw. (Alan@Alan-Laptop.home) @
07:48:47  <Brot6> NewGRF Viewer - Code Review #3126: do not add binaries to source repo (UnicycleBloke) @
07:50:20  <Brot6> NewGRF Viewer - Code Review #3126: do not add binaries to source repo (UnicycleBloke) @
07:50:43  *** ODM has joined #openttdcoop.devzone
08:05:41  *** hanf has joined #openttdcoop.devzone
08:07:49  <Brot6> NewGRF Viewer - Code Review #3126: do not add binaries to source repo (admin) @
08:39:45  *** hanf has quit IRC
08:41:57  *** JVassie has joined #openttdcoop.devzone
08:47:44  <Brot6> OpenGFX - Code Review #3139 (New): review use of train alignment templates (planetmaker) @
08:51:22  *** JVassie_ has joined #openttdcoop.devzone
08:58:17  *** JVassie has quit IRC
10:03:47  <Yexo> planetmaker: is toyland/toyland-1178-gui-recolor.pnfo
10:04:03  <Yexo> actually it's only the recolor sprite, not the real sprites
10:04:19  <planetmaker> cool. thank you :-)
10:05:08  <planetmaker> it means I can convert the whole toyland grf to nml, too :-)
10:05:48  <Yexo> nice :)
10:15:30  <Brot6> OpenGFX - Revision 793:fafe04e43655: Fix: One pnfo file was not added as updated from source nml ... (planetmaker) @
10:15:30  <Brot6> OpenGFX - Revision 794:31ce9550b724: Codechange: Use nml source for toyland grf. (Recolour conver... (planetmaker) @
10:44:49  <Ammler> planetmaker: were you able to reproduce the race conditions issues I have?
10:45:25  <planetmaker> not on my machine. Do you have a paste of how they look for you?
10:45:43  <planetmaker> I haven't yet tried on devzone
10:45:54  <planetmaker> except that I didn't see when the CF built OpenGFX
10:46:26  <planetmaker> I just noticed though that calling 'make install' after a 'make maintainer-clean' won't work
10:47:50  <Ammler> you tried with j10?
10:48:04  <planetmaker> I tried j5
10:48:11  <Ammler> make install is never used without make
10:48:19  <Ammler> so that does not matter
10:48:51  <Ammler> or do you still depend on all for install?
10:49:30  <Ammler> would be bad
10:51:08  <Ammler> just remember that make install could be run by root
10:51:28  <Ammler> it would be awesome ugly, if root then would build something
10:53:40  <planetmaker> the make manual recommends for 'install': "Compile the program and copy the executables, libraries, and so on to the file names where they should reside for actual use"
10:54:01  <Ammler> "recommends"
10:54:10  <planetmaker> thus you should always call make && sudo make install
10:54:16  <Ammler> yep
10:54:28  <Ammler> thus you should not depend on all for install
10:54:43  <Ammler> just safety
10:54:53  <planetmaker> ok, they don't recommend but say "All GNU programs _should_ have the following targets"
10:55:03  <planetmaker> which is "do that or you do it wrong" ;-)
10:55:08  <Ammler> yes, should have that target
10:55:15  <Ammler> but not should depend on all
10:55:46  <Ammler> well, it does not hurt
10:56:07  <Ammler> I didn't say wrong, just ugly :-P
10:56:33  <Ammler> openttd does it same ugly style, iirc
10:57:07  <planetmaker> it should depend on all. It should not re-compile when 'all' just has been called
10:57:27  <Ammler> well, I hope that last one is a mustn't
10:57:48  <planetmaker> ?
10:58:04  <Ammler> "shouldn't re-compile if all just was called" is wrong
10:58:20  <planetmaker> it's a quote
10:58:34  <Ammler> well, it is a recommendations
10:58:42  <Ammler> it woudl be wrong, if it would rebuild
11:01:32  <Brot6> Example NewGRF Project - Bug #3128 (Closed): DevZone compile failed (planetmaker) @
11:03:16  <Brot6> Example NewGRF Project - Feature #3140 (New): Add target 'dist' (planetmaker) @
12:55:46  <planetmaker> hm... some recolour sprite must be broken, Yexo... <-- for testing
12:59:22  <Yexo> which kind of sprite is broken?
13:00:11  <planetmaker> the gray for GUI
13:00:22  <planetmaker> it's the DOS brown
13:00:59  <planetmaker> can I do something wrong?
13:01:23  <planetmaker> I called it with nmlc -c -p WIN but that didn't seem to have changed anything
13:01:27  <Yexo> forgot to compile with -p WIN ?
13:01:37  <Yexo> than there is a problem with the palette
13:01:40  <planetmaker> hm... I'll try a full re-compile
13:02:34  <planetmaker> hm... I might not use the defined nml flags there... Let's see :-)
13:05:23  <planetmaker> hm.... *should*. But let's see what it looks after re-compile
13:09:11  <Yexo> planetmaker: wrt can't you just decompile the grf for that?
13:09:12  <Webster> Title: Transport Tycoon Forums View topic - [OTTD] OpenGFX+ Big GUI (Double Sized GUI) [WIP] (at
13:09:53  <planetmaker> Yexo: yes, I can. But usually the resulting png file is less nice than orderly sprites in source files
13:09:58  <planetmaker> can be the other way
13:10:39  <planetmaker> depending on how the original png files of him look like, I might do that
13:11:37  <planetmaker> he... "nmlc: Image file "sprites/png/trees/toyland/toyland_tree_balloon.png": Image has 'DOS' palette, but you forced the 'WIN' palette "
13:11:43  <planetmaker> and I didn't touch that file ;-)
13:12:03  <Yexo> that means the recolour sprite would also have the DOS palette
13:12:09  <Yexo> which means trouble
13:12:20  <planetmaker> but that's another grf. Thus in temperate it shouldn't matter
13:12:25  <Yexo> yes, exactly
13:30:14  <Brot6> OpenGFX - Revision 795:1af987daf176: Fix: Force windows palette for NML output (planetmaker) @
13:30:14  <Brot6> OpenGFX - Revision 796:a2036320b625: Fix: Tree sprite had DOS palette (planetmaker) @
13:30:27  <planetmaker> well, indeed that does not fix the palette issue...
13:30:33  <planetmaker> hm...
13:31:08  <Yexo> it's a bug in my conversion
13:31:14  <planetmaker> sure?
13:31:20  <Yexo> yes
13:35:19  *** hanf has joined #openttdcoop.devzone
13:39:31  <Yexo> planetmaker: can you test again with the fix I just pushed?
13:39:42  <planetmaker> sure
13:40:03  <Brot6> OpenGFX - Revision 797:fb49d2938f46: Fix: recolour sprites for grey and white were wrong (yexo) @
13:46:20  <planetmaker> startup screen looks correctly coloured again :-) thanks, Yexo
14:06:39  *** hanf has quit IRC
14:14:03  <Brot6> repository /home/hg/ogfx-biggui registered in Redmine with url /home/hg/ogfx-biggui
14:14:03  <Brot6> repository /home/hg/ogfx-biggui created
14:15:04  <Brot6> OpenGFX BigGUI - Revision 0:703b9315d79c: Add: Initial setup (planetmaker) @
14:15:17  <planetmaker> now I just need sprites ;-)
14:55:29  <Brot6> NewGRF Meta Language - Bug #3141 (New): Use action5, type a + 0x80 when not all sprites supplied (planetmaker) @
15:03:20  <Brot6> NewGRF Meta Language - Bug #3141: Use action5, type a + 0x80 when not all sprites supplied (planetmaker) @
15:04:19  <Yexo> planetmaker: I'd argue that is an nforenum bug
15:04:58  <Yexo> but the spec is not very clear about it
15:05:16  <planetmaker> yes, it's not
15:05:33  <Yexo> openttd doesn't care either way
15:06:09  <planetmaker> not sure it's worth to fix that issue within nforenum
15:06:17  <planetmaker> I'll move the issue then
15:06:26  <Yexo> leave it for a bit
15:06:36  <Yexo> perhaps frosch has something to say about it when he gets online
15:07:31  <planetmaker> ok
15:09:30  <planetmaker> in any case, fully docmented now ;-)
15:09:36  <Brot6> NewGRF Meta Language - Bug #3141: Use action5, type a + 0x80 when not all sprites supplied (planetmaker) @
15:10:51  <planetmaker> Yexo: is there an easy way to convert the zillion 2cc sprites?
15:35:50  <Yexo> yes
16:03:54  <Yexo> planetmaker: it's this: but it needs to be extended for all 16 colors
16:04:39  <planetmaker> ah, I see. Thank you :-)
16:10:38  * planetmaker is confused... the extra newgrf defines actionA for sprites 4836 and 4839..4842...
16:11:07  <planetmaker> hm.. base + logo or so
16:11:09  <Brot6> Backup opengfx: abort: no suitable response from remote hg!
16:11:39  <Rubidium> planetmaker: maybe it's one of the fix ttd grf things?
16:12:13  <planetmaker> No, those are the letters for "OpenTTD" in the title screen
16:12:40  <planetmaker> the one which don't appear in Transport Tycoon deluxe
16:13:29  <planetmaker> thus I can do actionA on sprites# (base) + x for those in the logo grf.
16:13:34  <planetmaker> Learnt something :-)
16:13:57  <planetmaker> But... I wonder why it needs actionA and is not directly there...
16:14:39  <Rubidium> unwasting sprite numbers maybe?
16:16:58  <planetmaker> yes, most likely
16:32:44  <planetmaker> in the extra NewGRF are anyway a few oddities ;-)
16:41:40  <Rubidium> without oddities it wouldn't be fun
16:45:11  <planetmaker> yeah :-)
16:45:25  <planetmaker> I guess it's in for a cleanup once we have it in NML
17:10:35  <Brot6> nml: update from r1685 to r1687 done -
17:14:51  <Brot6> OpenGFX - Revision 798:f49149a2085d: Fix: Typo in directory name (planetmaker) @
17:14:51  <Brot6> OpenGFX - Revision 799:f3561d9b1b43: Cleanup: Don't define the same sprite in two places differently (planetmaker) @
17:14:51  <Brot6> OpenGFX - Revision 800:8fea0658ff10: Codechange: Use NML source for some parts of the log and ext... (planetmaker) @
17:15:27  <planetmaker> when OpenGFX is converted it will have come a looong way from its beginnings
17:20:05  <Brot6> opengfx: update from r785 to r800 done (2 warnings) -
17:22:55  <Brot6> ogfx-biggui: update from  to r0 done -
17:24:56  <Brot6> OpenGFX - Revision 801:a4f35b1639c7: Codechange: use NML source for 2cc recolour sprites (yexo) @
17:25:47  <planetmaker> oh :-) \o/
17:26:51  <planetmaker> do I have another free wish? :-P
17:27:58  <planetmaker> that'd be the 640px sprite width now :-)
17:28:22  <Yexo> didn't I fix that yesterday?
17:29:00  <planetmaker> oh. You did.
17:29:05  <planetmaker> I completely missed that :-)
17:29:53  <planetmaker> great. Then we'll have it nml-ified by the end of the week :-)
17:30:34  <Terkhen> :)
17:31:55  <planetmaker> then I only need an NML release for the next OpenGFX release :-)
17:32:19  <planetmaker> which still has time
17:34:12  <planetmaker> bbl
17:35:22  <Brot6> NewGRF Meta Language - Bug #3124 (Closed): sprites wider than 255px needed for base sets (yexo) @
17:38:20  <Brot6> Manual Industries - Bug #3142 (New): DevZone compile failed (compiler) @
17:39:19  <Brot6> Example NewGRF Project - Bug #3143 (New): DevZone compile failed (compiler) @
17:40:45  <Yexo> Ammler: ^^ "Server returned an error: HTTP Error 400: Bad Request" "Uncaught exception: Connection timed out - connect(2)"
17:44:32  <Brot6> vactrainset: compile of r1 still failed (#3044) -
17:59:20  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: ogfx-trains (Diffsize: 36114), narvs (11 warnings), ogfx-industries (1 warnings) (Diffsize: 129173), firs (Diffsize: 12), foobarstramtracks (Diffsize: 37000), cets (569 warnings), rust, dutchtramset (Diffsize: 25964), swisstowns, dutchroadfurniture (Diffsize: 1984), spanishtowns (Diffsize: 2), frenchtowns, ogfx-rv, ogfx-landscape (2 warnings),
17:59:20  <Brot6> swedishrails, german-townnames, belarusiantowns (Diffsize: 30), indonesiantowns (1 warnings) (Diffsize: 1), airportsplus (Diffsize: 964)
18:10:47  *** frosch123 has joined #openttdcoop.devzone
18:21:31  <Brot6> Manual Industries - Bug #3142 (Rejected): DevZone compile failed (compiler) @
18:21:31  <Brot6> Manual Industries - Bug #3142 (Rejected): DevZone compile failed (frosch) @
18:22:43  <Yexo> frosch123: about I argued it's a nforenum bug, what do you think?
18:22:59  <Yexo> basically nforenum assumes that if there is no offset all sprites will be present
18:23:26  <Yexo> while openttd and nml don't care about whether there is an offset, no offset just means a default offset of zero
18:23:57  <frosch123> what is the usecase of "no offset and not all sprites"?
18:24:08  <frosch123> replacing only sprite 0 sounds uncommon to me
18:24:16  <Yexo> replacing sprite 0..5 for example
18:24:21  <frosch123> so, isn't the warning more likely to be correct?
18:24:25  <Yexo> it's as useful as replacing sprite 6..10
18:24:53  <frosch123> well, imo it is not too bad to request a offset in the 0..5 case
18:25:31  <Yexo> that's a good point
18:25:33  *** hanf has joined #openttdcoop.devzone
18:25:38  <frosch123> if we remove the check, nforenum will not warn on incomplete basesets
18:26:39  <frosch123> so, imo it is better to warn if there is no offset.
18:26:53  <Yexo> yes, you've convinced me
18:26:56  <Yexo> I'll fix nml instead than
18:30:49  <frosch123> shall we add a note about that interpretation to the specs?
18:31:13  <frosch123> (though it is entriely renum specific currently)
18:31:31  <Yexo> yes, but only as note, not as "must have offset"
18:31:41  <Yexo> as I still think the offset is nice, but there is no reason to require it
18:38:01  <frosch123> added
19:02:39  <Brot6> clientpatches: compile of r23023 still failed (#2964) -
19:04:28  <Brot6> serverpatches: compile of r23023 still failed (#2966) -
19:06:37  <Brot6> 32bpp-ez-patches: compile of r23023 still failed (#2446) -
19:30:59  <Brot6> NewGRF Meta Language - Revision 1688:59c0c19cc349: Fix: disallow magic pink in the windows palett... (yexo) @
19:31:21  <Yexo> planetmaker: since I still can't get opengfx to build, could you test if it still builds with nml r1688?
19:31:52  <Yexo> some differences in the pnfo recolour sprites are to be expected, mainly the last line of the sprite from all zeros to F0..FF
20:03:10  <Brot6> NewGRF Meta Language - Revision 1689:9994556afb1d: Fix: returning a parameter in a switch-block f... (yexo) @
20:19:39  <planetmaker> Yexo: why does it fail to build for you?
20:20:23  <Yexo> not sure, will now try again
20:21:27  <planetmaker> don't try a 'make install' after a 'make maintainer-clean'
20:21:36  <planetmaker> that's known to not work properly
20:21:49  <Yexo> I don't have gimp
20:21:58  <Yexo> so right now I'm just going for "make" after "hg revert-a"
20:22:58  <planetmaker> ah, ok.
20:25:17  <Yexo> depcheck just done (5 minutes)
20:26:17  <planetmaker> yeah...
20:26:23  <planetmaker> it's very very ugly now :-)
20:27:04  <planetmaker> I wonder whether it's worth to just remove the dep check for everything except graphics
20:27:31  <Yexo> errors in ogfxe_extra.nfo on sprite 282
20:27:32  <Rubidium> then hurry with the NML thing ;)
20:27:40  <planetmaker> Rubidium: yes, that's the plan
20:27:53  <planetmaker> Yexo: yes, there's one sprite with a an nforenum warning
20:28:07  <Yexo> that's 277
20:28:11  <planetmaker> hm
20:28:21  <Yexo> I get a fatal nforenum error after that
20:28:29  <planetmaker> that sounds like wrong sprite numbers. I'll look
20:28:34  <planetmaker> which grfcodec do you have?
20:28:39  <planetmaker> You need the newest
20:28:45  <Yexo> r835
20:29:15  <planetmaker> that should do :-)
20:29:43  <Yexo> updating now to be sure
20:29:56  <planetmaker> that's afaik "the latest"
20:30:06  <Yexo> no, r838 is
20:30:10  <planetmaker> at least it's the one I use(d)
20:30:18  <Yexo> r836 is the addition of the new action5 types
20:30:24  <Yexo> or rather allowing offsets for all types
20:30:37  <planetmaker> that's probably my 'M' :-)
20:31:06  <Yexo> restarting make for opengfx, will the depcheck take as long every time?
20:31:47  <planetmaker> the dep check or generating makefile.dep?
20:31:53  <planetmaker> the dep check... yes :-(
20:31:57  <planetmaker> should I kick it?
20:32:22  <planetmaker> hm... I only get an nforenum warning for 277
20:33:05  <planetmaker> Yexo: Makefile: edit the target 'all' and remove the recursive call of 'Make depend'
20:33:29  <Yexo> right now it looks like the dep check takes longer than the actual compilation
20:33:39  <Yexo> so it would be faster to always recompile everything and leave the depcheck out
20:34:38  <planetmaker> ah, Yexo: you have to delete your .nforenum dir
20:34:44  <planetmaker> the data files are not automatically updated
20:34:52  <Yexo> why not?
20:34:55  <Yexo> they should be
20:34:55  <planetmaker> Dunno
20:35:11  <planetmaker> deleting that was what helped me
20:35:28  <Yexo> ah, you didn't update the version in data.cpp
20:35:35  <planetmaker> oh. drat
20:35:44  <planetmaker> I didn't know
20:35:50  <Yexo> whenever you change something in src/data.cpp for nforenum, you should increase the second number in the NDF_HEADER
20:36:18  <planetmaker> I see...
20:36:35  <Yexo> anyway, I don't seem to have a .nforenum directory at all
20:36:43  <planetmaker> in ~ ?
20:36:48  <Yexo> nope
20:36:48  <planetmaker> or in opengfx ?
20:36:52  <Yexo> neither there
20:37:22  <Rubidium> on "proper" OSes it doesn't write them anymore, unless force to
20:37:24  <planetmaker> strange. But it's the sprite for action5, type 88
20:37:47  <Yexo> planetmaker: but now it builds
20:37:52  <Rubidium>   277 * 5        05 08 FF \w4
20:37:55  <Yexo> I was just missing the updated grfcodec
20:37:58  <Rubidium> that's the thing it warns on
20:38:04  <planetmaker> Rubidium: yes, that's know
20:38:25  <Rubidium> but that's type 8, not 88
20:38:26  <planetmaker> which can be considered an nforenum bug... but the specs are not clear
20:38:37  <Yexo> we determined that the warning is valid in most cases, but not in this case. The solution will be to adapt nml to it writes nfo were nforenum doesn't warn on
20:38:38  <planetmaker> it has no offset. But neither the full sprite amount
20:39:10  <planetmaker> Good. I felt it is better to consider all non-complete action5 as type +0x80
20:39:33  <Yexo> it'll still write is as type 8, but it'll also write the offset of zero
20:39:43  <planetmaker> that doesn't help, Yexo
20:39:47  <Yexo> hmm, or does it have to be type 0x88?
20:39:50  <planetmaker> yes
20:39:59  <planetmaker> I checked :-)
20:40:05  <planetmaker> it'll be an error to add 3 bytes
20:40:09  <planetmaker> with type 8
20:40:18  <Yexo> ok
20:40:58  <Rubidium> planetmaker: you made the specs "unclear" by adding the option to support a partial amount of sprites
20:41:16  <Yexo> that was already allowed for some types
20:41:18  <Rubidium> before that, the specs kinda said: it needs this many sprites
20:41:19  <planetmaker> Rubidium: not quite. The same applies to the existing types
20:41:47  <Rubidium> Yexo: which are... 14, 15 and 16 which all state "up to X" instead of "X"
20:42:03  <planetmaker> Rubidium: yes. But they behave exactly the same
20:42:06  <planetmaker> now
20:42:06  <Rubidium> "up to X" kinda implies that any amount is valid
20:42:21  <planetmaker> Thus nforenum will warn on the same thing
20:42:25  <Yexo> but nforenum would emit a warning if you provided 5 sprites without an offset
20:42:32  <Yexo> which is the same problem we now have
20:43:19  <Rubidium> ah well... it's a warning, and sometimes what you do is valid. Otherwise it would've been an error
20:43:53  <Yexo> hence the solution of adapting nml to write slightly differnt nfo were nforenum will not warn
20:45:25  <planetmaker> Yexo: but what should I test now with OpenGFX?
20:46:03  <Yexo> I can compile it now, so nothing
20:46:27  <planetmaker> ok :-)
20:48:16  <planetmaker> granted, i didn't know that the dep check would become this bad when I started to hack in support to use nml and grfcodec concurrently
20:59:29  <Brot6> NewGRF Meta Language - Revision 1690:35d9baa5e456: Change: output for action5 to write an offset ... (yexo) @
21:03:22  <Yexo> Makefile.local.sample is missing the definition for NML
21:08:40  <planetmaker> no(t anymore) ;-)
21:08:53  <Brot6> OpenGFX - Revision 802:68071312a589: Add: NML and its config to Makefile.local.sample (planetmaker) @
21:09:12  <planetmaker> hm, I have changed pnfo files for the files which contain recolour sprites
21:09:22  <Yexo> that's correct
21:09:32  <planetmaker> will you commit it? Shall I?
21:09:53  <Yexo> you can do it if you update nml first so the changed extra-canals.pnfo is also in it
21:10:02  <Yexo> the nforenum warning is now gone
21:10:31  <planetmaker> well, if you have it, you can do that, too, I don't mind. But if mine builds quicker, I'll gladly do it.
21:10:35  <planetmaker> You build in a VM?
21:10:42  <Yexo> no, in cygwin right now
21:10:54  <planetmaker> ah.
21:12:36  <planetmaker> I plan to revise the build system thoroughly when I can build everything from NML
21:12:58  <planetmaker> kicking out all nfo will help. And then I'll time building with and w/o dep check(s)
21:13:26  <planetmaker> possibly then again the usual from an NML grf can be used. But time will need a check
21:14:18  <Yexo> I hope that time will be soon
21:14:29  <planetmaker> give me feature 05 in NML :-P
21:15:17  <Yexo> that's waterfeatures?
21:15:20  <planetmaker> yes
21:15:44  <planetmaker> I think that's the only stumble stone to make everything nml only
21:16:10  <planetmaker> and converting a few more source files. But that's done moderately quickly
21:16:14  <planetmaker> most is done
21:17:44  <frosch123> night
21:17:47  <Brot6> Central European Train Set - Revision 237:cab8bfb2d4d0: add recolour table(s) (currently only mag... (Eddi) @
21:17:47  <Brot6> Central European Train Set - Revision 238:44dc24a22fe5: add code for generating recolour selectio... (Eddi) @
21:17:47  <Brot6> Central European Train Set - Revision 239:90a5f694cda6: add test case for recolour maps (open wag... (Eddi) @
21:17:49  *** frosch123 has quit IRC
21:19:30  <Brot6> Central European Train Set - Bug #3144 (New): DevZone compile failed (compiler) @
21:27:04  <Brot6> Central European Train Set - Bug #3144 (Closed): DevZone compile failed (compiler) @
21:27:04  <Brot6> Central European Train Set - Revision 240:fbef80396bf1: should check in the right files (Eddi) @
21:27:04  <Brot6> Central European Train Set - Bug #3144 (Closed): DevZone compile failed (Eddi) @
21:29:12  <Brot6> Central European Train Set - Bug #3145 (New): DevZone compile failed (compiler) @
21:52:07  <Brot6> OpenGFX - Revision 803:1c826613441a: Codechange: Update a few pnfo files as they're slightly diff... (planetmaker) @
22:06:05  <Brot6> NewGRF Meta Language - Revision 1691:094e54fe4d04: Add: support for feature 5 (yexo) @
22:06:23  <Yexo> planetmaker: example:
22:06:30  <Yexo> now I want a complete nml version :p
22:08:29  <planetmaker> you'll get it :-)
22:09:45  <planetmaker> do you know what the override sprite overrides?
22:10:12  <Yexo> what override sprite?
22:11:30  <planetmaker> extra/extra-openttd-override.pnfo
22:11:40  <planetmaker> it's some legacy bullshit. But sadly required
22:14:06  <planetmaker> as it was added to openttd?.grf eons ago
22:14:15  <Yexo> it's an engine override
22:14:20  <Yexo> will give you the nml code very soon
22:16:07  <Hirundo> Yexo: Is varact2vars_aircraft duplicated in NML r-latest?
22:16:35  <Yexo> yes :(
22:17:06  <Yexo> planetmaker:
22:19:56  <planetmaker> thx, Yexo
22:21:12  <Brot6> NewGRF Meta Language - Revision 1692:053997c3e961: Fix r1691: accidentally duplicated varact2vars... (yexo) @
22:26:53  <planetmaker> ok, waterfeatures is next on my list of files :-) But before I address them, I guess, my bed is on the immediate list of things to look after
22:27:07  <planetmaker> i.e. good night :-)
22:38:31  *** ODM has quit IRC
23:02:53  <Brot6> NewGRF Viewer - Revision 5:716933fb1a5d: Added write functions for sprites and overall GRF (UnicycleBloke) @
23:05:44  <Brot6> MailAI - Revision 17:19fb040c3f2e: BUGFIX didn't copy orders when replacing train (Hephi) @
23:07:02  *** hanf has quit IRC
23:24:27  *** JVassie_ has quit IRC

Powered by YARRSTE version: svn-trunk