Log for #openttdcoop.devzone on 9th August 2010:
Times are UTC Toggle Colours
00:08:47  *** ODM has quit IRC
00:11:35  *** KenjiE20 has quit IRC
00:14:37  *** Seberoth has quit IRC
05:05:52  *** Webster has joined #openttdcoop.devzone
05:50:23  * Rubidium is happy my pure white detector has not been proven broken yet :)
06:05:21  *** frosch123 has joined #openttdcoop.devzone
06:13:13  <planetmaker> :-)
06:14:23  <Rubidium> 'lo planetmaker
06:15:02  <Rubidium> FYI: Dale kinda gave up on grfcodec and nforenum, i.e. "fork" acked although not really a fork but rather a sudden change of maintainership
06:18:31  <planetmaker> hey :-)
06:18:48  <planetmaker> oh, so he answered? And he threw down everything?
06:18:59  <Brot6> NewGRF Meta Language - Feature #1174: Action 14 support (planetmaker) @
06:19:41  <Rubidium> Anyway. Go for it; I don't see any reason to expect that I'll suddenly
06:19:44  <Rubidium> find the time and motivation to fix NFORenum & GRFCodec.....
06:19:45  <frosch123> hey, a planetmaker ! :)
06:20:09  <planetmaker> moin frosch also!
06:20:18  <frosch123> i still cannot parse your last comment on fs#3947
06:22:40  <planetmaker> frosch123: Reading it again I say, I must have failed to express properly "That screenshot you show (and which I linked again) looks like what I want"
06:23:01  <frosch123> i feared you meant option 3
06:23:17  <frosch123> which is the most troublesome for me due to undefined snowyness of the bridgehead itself
06:23:49  <planetmaker> :-)
06:26:44  <planetmaker> Well, ... I don't 100% recall tbh
06:27:10  <planetmaker> What I mean is that imho it should behave as if every bridge track would be on solid ground
06:27:23  <planetmaker> and it looks like bridgesnow2.png shows just that
06:28:34  <Rubidium> but... my tube bridge has snow on its tracks :)
06:29:27  <planetmaker> :-P
06:29:49  <planetmaker> it will, I guess.
06:30:23  <planetmaker> But that's not in the domain of railtypes but of bridges: a 'covered' bit, just like stations
06:30:54  <planetmaker> which then, granted, would play back the game to railtypes ;-)
06:31:32  <planetmaker> s/game/ball/
06:34:17  <planetmaker> frosch123: you don't by chance have an updated diff of fs3947?
06:34:36  <frosch123> i have
06:35:39  <frosch123>
06:36:25  <planetmaker> thanks. I'll test
06:45:20  <planetmaker> yes, that does imho the right thing [TM]
06:47:14  <planetmaker> <-- evil railtypes. Nasty to deal with such 'late minute' features everywhere
06:47:17  <Webster> Title: Transport Tycoon Forums • View topic - Canadian Base Graphics v2.0 (CanBase) Development (at
06:47:20  <frosch123> <- inconsistent are are third and fourth slope from left
06:47:47  <frosch123> under the bridge the tile is snowy, while the normal uphill track is not
06:47:58  <frosch123> that will cause trouble again, when we get snow densities
06:48:34  <planetmaker> that might be true. But comparing to the uphill track w/o bridge it's correct
06:49:59  <frosch123> well, noone said snow densities are easy :p
06:50:38  <planetmaker> 'snowy' currently is no black/white, except on track tiles. So as long as snow densities for track tiles are not considered, the best is to make the yes/no for tracks consistent
06:50:43  <planetmaker> which your patch does
06:53:03  <planetmaker> If there come snow densities for tracks, it might need review. Could one check for an equivalent ground track?
06:54:08  <frosch123> planetmaker: the problem are only newgrf which ask whether there is snow. you do no know whether they mean the track or the ground :)
06:54:44  <planetmaker> hm, yes
06:54:58  <planetmaker> *that* is a problem, true
07:03:57  <planetmaker> the only really sane solution I can think of is a function 'GetTrackHeight' used instead of 'GetTileHeight'
07:04:28  <planetmaker> or maybe not 'track' but some more generic term so it can apply to roads in principle as well
07:04:51  <frosch123> well, i guess at that point newgrfs will have to learn about snow density as well, and if they want to access the track, they have to deal with bridgeheads themself
07:09:06  <planetmaker> well, yes :-)
08:29:56  <frosch123> <- long standing bug :)
08:32:00  <frosch123> the one where encoded grfs had slanted sprites
08:32:40  <Rubidium> the... your pcx has to be a multiple of 4 pixels wide thing?
08:33:31  <frosch123> yeah, but actually it was a multiple of 2
08:33:49  <frosch123> (at least the one i can reproduce)
08:34:31  <frosch123> but it is totaly up to the encoder how many bytes to use per line
08:34:51  <frosch123> so maybe some also do 4 byte alignment
08:36:17  <Rubidium> would this allow sprites to read, in case of bpl != window[2] + 1, 1 pixel outside of the actual image?
08:36:51  <Rubidium> i.e. draw the garbage in the unused pixels, or is that handled somewhere else?
08:36:56  <frosch123> yes, in the rest only sx is used
08:37:30  <frosch123> so if you define a sprite extending over the width of the image it uses the undefined pixels
08:38:46  <Rubidium> do we care about that or not?
08:43:16  <frosch123> well, it seems to only check ysize anyway
08:43:59  <frosch123> so, no new bug :p
08:44:07  <Rubidium> good :)
08:48:00  <Brot6> GRFCodec - Revision 209:885a0afa08f2: Fix: reading of PCX files with more bytes per scanline than... (frosch) @
09:14:50  <Rubidium> frosch123 / Yexo / Ammler / planetmaker: are you aware of any remaining issues with grfcodec/nforenum code and/or package wise, or should we go on an create a release candidate for both?
09:17:00  <frosch123> nothing on my list :)
09:20:44  <Ammler> both built successful (nforenum with a very new boost)
09:26:03  <planetmaker> from my side there's no immediate concern blocking a release. But... I haven't tested anything the last 14 days :-)
09:35:34  <Rubidium> then go on and test :)
09:49:54  <Ammler> oh, wb planetmaker
09:52:16  <Brot6> GRFCodec - Revision 210:6f56821949f3: Codechange: use {} instead of ; for empty body for/while st... (Rubidium) @
10:15:28  <Brot6> GRFCodec - Revision 211:26083fe2b535: Add: -v to get the version number more easily (and sometime... (Rubidium) @
10:19:51  <planetmaker> hey Ammler :-)
10:21:54  *** KenjiE20 has joined #openttdcoop.devzone
10:24:36  <Brot6> NFORenum - Revision 447:bd0cfa0ee0b5: Add: -v to get the version more easily (Rubidium) @
10:24:36  <Brot6> NFORenum - Revision 448:64c9e855b231: Cleanup: remove trailing whitespace (Rubidium) @
10:24:36  <Brot6> NFORenum - Revision 449:29fa435b42f3: Cleanup: some lines started with spaces instead of tabs, ma... (Rubidium) @
10:25:36  <Brot6> NFORenum - Revision 450:2c548469951c: Fix: for some reason findversion wasn't executable anymore (Rubidium) @
10:29:18  <Brot6> GRFCodec - Revision 212:1bf801b5c1ad: Cleanup: some lines started with spaces instead of tabs (Rubidium) @
10:30:45  <Rubidium> <- what would that error actually mean?
10:36:30  <frosch123> offs is used twice in that line
10:37:36  <frosch123> so it does not know when to apply the ++
10:37:37  <Rubidium> so the order of "resolving" offs in that case isn't defined?
10:39:54  <Rubidium> doing an offs++ on the line before would be the "right" fix, right?
10:42:12  <frosch123> actually i would expect an ExtractByte in that lin
10:45:49  <Rubidium> it eats the 00 termination as well?
10:46:33  <frosch123> string code 9a 04 only takes a byte parameter
10:46:50  <Rubidium> yes, but it probably eats the 00 as well or something?
10:47:04  <frosch123> what 00?
10:47:22  <Rubidium> that is assumed to come after it
10:47:31  <Rubidium> (not by the spec, but by Dale)
10:48:02  <frosch123> where do you see that?
10:48:19  <Rubidium> it takes 2 bytes instead of 1
10:48:53  <frosch123> well, imo that is wrong :)
10:48:56  <Rubidium> given little endian the first byte being != 0 and the second == 0 would be a test case where it's "valid"
10:50:39  <Ammler> planetmaker: can I push?:
10:50:42  <Ammler> -NFORENUM       ?= $(shell [ `which nforenum 2>/dev/null` ] && echo "nforenum" || echo "renum")
10:50:44  <Ammler> +NFORENUM       ?= $(shell [ `which renum 2>/dev/null` ] && echo "renum" || echo "nforenum")
10:51:19  <frosch123> i think that line should be arg=data.ExtractQEscapeByte(++offs);
10:51:38  <frosch123> if(!arg&&!include_00_safe)IssueMessage(WARNING1,EMBEDDED_00,offs-1); <- and that line should have no -1
10:51:41  <Ammler> would make opengfx makeable without patch
10:54:59  <Rubidium> frosch123: can you commit/test that?
10:55:16  <frosch123> i can commit it, but testing?
10:55:38  <frosch123> i have no idea what that weird stringcode is meant for :)
10:55:53  <frosch123> but ok, one can test whether the offset is reported correctly
10:55:54  <Rubidium> ah well... if it's wrong, then we can always revert the change :)
10:56:09  <Rubidium> then at least we would have some test NewGRF :)
10:56:29  <frosch123> so, shall i commit?
10:57:28  <Rubidium> yep
11:00:31  <Ammler> hmm, better might be +NFORENUM       ?= "nforenum"
11:01:13  <Rubidium> Ammler: I would wait at least a month with that
11:02:45  <Ammler> well, it would help the package maintainer to detect if they still use old renum
11:03:18  <Rubidium> true, but are you about to release a new opengfx?
11:03:44  <Rubidium> and is the new nforenum actually officially released in any manner?
11:04:03  <Ammler> I don't think, we will release opengfx before that :-)
11:04:04  <planetmaker> <Ammler> planetmaker: can I push?: <-- referring to what?
11:04:32  <Ammler> newgrf_makefile
11:04:37  <Ammler> and opengfx
11:04:49  <planetmaker> ah. Yes
11:06:04  <Ammler> planetmaker: might not be worth anymore, we could also "force" to nforenum
11:06:09  <planetmaker> hm... Yes. Maybe we should wait for an official grfcodec / renum
11:06:19  <Ammler> yes
11:06:21  <planetmaker> but yes...
11:06:30  <planetmaker> let's wait a bit.
11:06:37  <planetmaker> Is it already an issue about it?
11:06:56  <Ammler> I need to patch opengfx because centos doesn't have which
11:07:34  <Ammler> could also simply add NFORENUM=nforenum
11:07:40  <planetmaker> It doesn't? That's bad.
11:08:05  <Ammler> not really important
11:08:55  <planetmaker> hm, yes, I think we should wait with the official change until renum is called nforenum
11:08:57  <planetmaker> Officially
11:09:01  <planetmaker> Then we follow that change
11:19:38  <planetmaker> <-- Ammler, can it be closed actually?
11:19:51  <Brot6> Example NewGRF Project - Code Review #1086: which is not installed on CentOS or RHEL (planetmaker) @
11:22:21  <Ammler> planetmaker: guide should be replaced/updated, that does still use win32text
11:23:00  <Ammler> but since your Makefile doesn't work on windows anymore, I am not sure, if it is required at all :-)
11:23:17  <Ammler> foobar might know
11:24:23  <Brot6> OpenGFX - Feature #957: forest (planetmaker) @
11:24:29  <Brot6> NFORenum - Revision 451:d5815326c945: Fix: String code 9A 04 takes a byte parameter. (frosch) @
11:24:29  <Brot6> NFORenum - Revision 452:e0955c6635a1: Change: Simplify parsing of stringcode 9A 03. (frosch) @
11:24:43  <planetmaker> not sure... using mingw doesn't change the EOL thing
11:25:30  <Ammler> mingw doesn't work anymore
11:25:48  <planetmaker> nor does cygwin change the used editors
11:26:06  <Ammler> I guess, Yexo has cygwin working, but not reproduceable
11:26:18  <planetmaker> well. what does FooBar use?
11:26:26  <Ammler> linux on vm
11:26:28  <planetmaker> He does use the makefile.
11:26:31  <planetmaker> oh
11:26:31  <Brot6> GRFCodec - Revision 213:6daf6d4ab052: Update: the changelog (Rubidium) @
11:26:31  <Brot6> GRFCodec - Revision 214:4463cf958c5f: Added tag 1.0.0-RC1 for changeset 6daf6d4ab052 (Rubidium) @
11:27:46  <Brot6> GRFCodec - Feature #1081 (Closed): Release 1.0.0 (Rubidium) @
11:27:52  <Ammler> \o/
11:36:02  <planetmaker> yippieh :-)
11:43:59  <Brot6> GRFCodec - GRFCodec 1.0.0-RC1 (Rubidium) @
11:44:53  <Brot6> GRFCodec - GRFCodec 1.0.0-RC1 (Rubidium) @
11:48:57  <Brot6> NFORenum - Revision 453:24a4fb47d16b: Update: the changelog (Rubidium) @
11:48:57  <Brot6> NFORenum - Revision 454:c28b41a4e2b7: Added tag 4.0.0-RC1 for changeset 24a4fb47d16b (Rubidium) @
11:51:00  <Brot6> NFORenum - Feature #1080 (Closed): New Version for distros (Rubidium) @
11:55:41  <Rubidium> I hope you don't mind having two quite similar post on your frontpage :)
11:55:45  <Brot6> NFORenum - NFORenum 4.0.0-RC1 (Rubidium) @
11:58:28  *** Seberoth has joined #openttdcoop.devzone
11:59:14  <planetmaker> that's quite fine
11:59:14  <frosch123> four a year :o
12:00:08  <Rubidium> frosch123: that's how often I reckon opengfx releases with new sprites as OpenTTD needs more sprites :)
12:00:22  <Rubidium> so release nforenum just before that so downstreams don't get warnings and such :)
12:01:00  <frosch123> i somehow doubt there is so much new stuff
12:01:02  <planetmaker> four a year for OpenGFX seems plenty. But yes :-)
12:01:31  <Rubidium> then we make it two releases :)
12:01:33  <Brot6> NFORenum - NFORenum 4.0.0-RC1 (Rubidium) @
12:02:04  <frosch123> :)
12:02:38  <Ammler> well, IMO, there is already enough to make a new release :-)
12:02:54  * Rubidium ponders whether frosch123 wants to make the forum post
12:03:03  <Rubidium> s/p/w/
12:03:33  <Rubidium> and I'm wondering whether we need two forum posts or just one
12:03:45  <Rubidium> s/posts/threads/
12:03:47  <frosch123> no, you talked with patchman an dalestan :)
12:04:13  <frosch123> i would ask a moderator to lock the two old topics and start two new
12:08:10  <planetmaker> maybe one of you should become graphics forum moderators, too.
12:08:28  <planetmaker> after all it became vastly an OpenTTD forum
12:09:00  <frosch123> you mean a moderator, or some fool with the right to sticky stuff?
12:11:58  <planetmaker> both :-P
12:12:09  <planetmaker> some person with the power to edit postings in that sub-forum
12:12:17  <planetmaker> e.g. a 2nd Pikka there
12:27:24  <Ammler> planetmaker: you?
12:27:58  <planetmaker> dunno. *some* dev would seem more proper to me
12:30:29  <Ammler> then they should simply add the Dev Group
12:32:43  * frosch123 would prefer some coop guy, but not my job to decide :)
12:37:14  <frosch123> wow, grfcodec is available for mac :)
12:37:38  <Rubidium> too lazy to remove that :)
12:47:37  <planetmaker> frosch123, there's no reason to remove that, or?
12:48:23  <frosch123> no, andy might be happy :)
12:48:42  <planetmaker> ^
12:49:07  <planetmaker> no gui issues anyway. And most (all?) of OpenTTD are gui of some sort
12:49:44  <Rubidium> yeah, or using APIs that aren't POSIX
13:02:59  <planetmaker> oh, what amiable postings in tt-forums, Rubidium :-)
13:06:38  <Rubidium> good... that you read the forum, now you can fix openmsx :)
13:07:09  <planetmaker> :-)
13:07:16  <planetmaker> it's on my list
13:07:50  <planetmaker> actually among the top5 of my todo
13:34:30  * andythenorth wants to moderate BROS :P
13:41:13  * planetmaker wants FIRS 0.4 ;-)
13:41:31  <andythenorth> andythenorth wants a pony
13:42:14  <planetmaker> :-)
13:42:18  <planetmaker> You got ponies!
13:42:59  <planetmaker> or maybe I did :-P
13:47:25  <planetmaker> oh, oh. oh. BROS. Have mercy
13:47:41  <planetmaker> blessed those who are ignorant
13:48:24  <andythenorth> three people have 1100 FIRS commits in 18 months.  BROS have nothing in about five years :P
13:49:09  <andythenorth> alongside full time jobs, university courses, global recessions, companies to run, houses to renovate and babies to feed :P
13:49:40  <andythenorth> community sets :|
13:50:04  * andythenorth wonders what happens when running the whole country is made the responsibility of the community :)
13:54:32  <planetmaker> a community is always a number of people. And as good as the people taking charge
13:54:40  <planetmaker> taking responsibility
13:55:02  <planetmaker> which... obviously BROS doesn't.
13:57:44  <frosch123> wallyweb needs glasses :)
13:58:20  <planetmaker> indeed ;-)
14:09:48  *** Seberoth has quit IRC
14:09:55  *** Seberoth has joined #openttdcoop.devzone
14:22:51  *** ODM has joined #openttdcoop.devzone
14:54:20  <Rubidium> stupid gentoo downstream...
14:54:50  <planetmaker> hm?
14:55:01  <Rubidium> ... they should start propagating their changes upstream, or at least try to instead of hide it in their own little corner and claim the world is just broken
14:58:03  <Rubidium> in any case there's a bunch of patches bitrotting in gentoo's repository, some for their insaneness about build flags and some for proper bugs
14:58:14  <Rubidium> but hell... no need to tell upstream about the bugs you find
14:59:10  <planetmaker> lol
15:00:36  <frosch123> <- that one?
15:00:38  <Webster> Title: Gentoo Bug 323249 - games-util/nforenum crashes when $HOME ends in a slash (at
15:00:47  <Rubidium> yes, that one
15:01:18  <planetmaker> apropos upstream:<-- has this been brought to the attention of... whoever supplies the driver? Microsoft?
15:02:53  <Rubidium> you've got to ask that to the Windows port maintainer :)
15:03:26  <planetmaker> whom? Yexo? glx? michi_cc?
15:03:41  <Rubidium> good question, ask them :)
15:03:49  <planetmaker> he
15:04:22  <Yexo> I've ignored that bug so far as I know next to nothing about the windows-specific code
15:06:00  <Rubidium> hmm, or did they send an email to Dale? Maybe that's it
15:06:00  *** frosch123 has quit IRC
15:06:14  <planetmaker> hu?
15:06:39  <planetmaker> different topic, eh :-)
15:06:53  *** Yexo has quit IRC
15:07:09  *** Yexo has joined #openttdcoop.devzone
15:10:30  <Rubidium> planetmaker: no, still the gentoo not talking to upstream topic
15:14:36  <planetmaker> :-) oki
15:16:43  <Ammler> why do you care about gentoo? Only geeks use it anyway...
15:18:03  <planetmaker> why care about <whatever>. <whoever> uses it only anyway... :-P
15:18:14  <Ammler> hehe
15:19:18  <Ammler> but you dedicate such things to the devs using it...
15:19:27  <Ammler> should*
15:20:41  <Rubidium> Ammler: because *they* fix a bug without telling us, which basically means that *you* are still running a buggy version
15:21:21  <Ammler> Rubidium: yes, but you should blame the openttd devs, which use gentoo
15:22:00  <Brot6> GRFCodec - Revision 215:bfe461b03575: Change: add readme and make it harder to accidentally conta... (Rubidium) @
15:22:00  <Brot6> NFORenum - Revision 455:72bd619df5c5: Change: add readme and make it harder to accidentally conta... (Rubidium) @
15:22:00  <Rubidium> why?
15:22:01  <Ammler> how many 2, 3 or more using it?
15:22:14  <Rubidium> I'd say 2, but why blame them?
15:22:29  <Ammler> why blame the unknown maintainer?
15:22:41  <Rubidium> Ammler: because THEY didn't tell "upstream"
15:22:58  <Ammler> :-) ok
15:23:24  <Rubidium> hmm... how to put this in a way that might be understandable
15:24:16  <planetmaker> a maintainer can only fix something s/he knows :-) It's not his/her fault, if s/he doesn't fix a bug s/he doesn't know about <-- like that?
15:24:18  <Rubidium> you are with a group going for a jump parachute. You notice the parachute is missing from the pack and fix that for yourself, but you don't mention this to the others. Now they all jump...
15:25:52  <Ammler> it is same stupid as debain using patches instead upstream updates
15:27:04  <Rubidium> Ammler: no, Debian gets their stuff from upstream, i.e. upstream knows about the bug and has fixed it. Furthermore upstream has done its best to notify the downstreams that there is a bug and given them a number of solutions to the issue.
15:28:12  <Ammler> how helpful is it for openttd, when debian sill spreads buggy 0.6 instead of 1.0
15:28:49  <Ammler> well, buggy 0.6 with some security patches
15:29:10  <Rubidium> Ammler: more helpful than Debian spreading an unbuggy 0.6 and we still shipping a buggy 1.0
15:30:01  <Rubidium> but then I guess you haven't ran any software for which you feared an update
15:30:28  <Ammler> please don't compare openttd with software like apache or bind or such
15:30:49  <Ammler> maybe debian does that :-)
15:31:25  <Rubidium> Ammler: where to draw the line between stuff that shouldn't be updated often and stuff that should?
15:31:29  <Ammler> that is the reason openttd isn't shipped with suse for example
15:31:46  <planetmaker> eh?
15:32:13  <Rubidium> let me say, video card drivers: if/once they work, preferably never
15:33:03  <Ammler> planetmaker: debian does ship openttd officially, opensuse only with constrib repo
15:33:35  <planetmaker> yes. But the reason to differ is... what exactly?
15:33:58  <planetmaker> It can only be a categorizing of importance to the distro maintainers.
15:34:58  <Ammler> the updates repo for suse is only for the main repos
15:35:22  <planetmaker> so... what is 'good' about that?
15:35:23  <Ammler> so if you like to fix openttd, you can't commit a update
15:35:46  <Ammler> what is good about running openttd 0.6?
15:36:18  <planetmaker> yeah, but the difference only is: buggy openttd vs. fixed openttd
15:36:51  <planetmaker> (ignoring differences in the length of the release-cycle)
15:36:51  <Ammler> no, it is about useable openttd vs. debian openttd
15:38:47  <Rubidium> actually using debian-backports you can get newer stuff compiled with the toolchain and libraries of the stable release
15:40:45  <Rubidium> in any case, stable in Debian stable points to the amount of change that'll happen, not to the actual stability of the individual packages
15:41:38  <Rubidium> even so, having it in the main repository makes OpenTTD findable for a lot more people and once they have installed and played with it (regardless of the version) they might want more and become part of the community
15:42:21  <Ammler> hmm, maybe
15:42:33  <Rubidium> and e.g. jumping from 1.0.2 to 1.0.3 because of the one security issue might be quite bad as 1.0.3 has some regressions w.r.t. NewGRFs and snow
15:42:57  <Rubidium> i.e. NewGRF industries and arctic don't go together in 1.0.3
15:43:53  <Ammler> hmm, and that is "allowed" for minor release update?
15:43:58  <Rubidium> just applying the patch would solve the security issue but won't add the regressions
15:44:34  <Rubidium> Ammler: what is "allowed" exactly?
15:44:49  <Ammler> from your own rules
15:45:42  <Ammler> changing game behavior
15:47:18  <Ammler> well, at least you supply own debian packages
15:48:22  <Ammler> you should include some "bigbrother" fetures, so you see what is really in use
15:48:45  <planetmaker> Ammler, it's called masterserver
15:48:46  <Rubidium> Ammler: fixing bugs == changing game behaviour
15:49:06  <Rubidium> adding features is a whole other thing
15:50:09  <Ammler> planetmaker: I don't think the masterserver does track such data
15:50:10  <Rubidium> planetmaker: actually... getting content over http is more big brothery
16:18:58  <Brot6> grfcodec: compile of r215 failed -
16:20:12  <Brot6> nforenum: update from r442 to r455 done -
16:20:56  <Brot6> swedishrails: update from r140 to r141 done -
16:20:59  <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r573), 32bpp-extra (r38), airportsplus (r52), basecosts (r20), comic-houses (r71), firs (r1121), fish (r386), heqs (r371), metrotrackset (r43), newgrf_makefile (r124), nml (r670), nutracks (r90), ogfxplus (r41), opengfx (r477), openmsx (r91), opensfx (r97), snowlinemod (r15), transrapidtrackset (r15), worldairlinersset (r659)
16:21:54  <Brot6> 2cctrainset: rebuild of r573 done (6 errors) -
16:22:38  <Brot6> 32bpp-extra: rebuild of r38 done (1 errors) -
16:22:49  <Brot6> OpenMSX - Bug #1210 (Closed): GPLv2+ vs GPLv2 (Rubidium) @
16:22:49  <Brot6> OpenMSX - Revision 92:5fca12cf5135: Fix #1210: Typo in readme (planetmaker) @
16:22:49  <Brot6> OpenMSX - Revision 93:33583a427883: Change: Add copyright information to build system (planetmaker) @
16:22:49  <Brot6> OpenMSX - Bug #1210 (Closed): GPLv2+ vs GPLv2 (planetmaker) @
16:23:03  <Brot6> airportsplus: rebuild of r52 done -
16:23:24  <Brot6> basecosts: rebuild of r20 done -
16:23:53  <Brot6> comic-houses: rebuild of r71 done (3 errors) -
16:24:33  <Brot6> firs: rebuild of r1121 done (142 errors) -
16:25:12  <Brot6> fish: rebuild of r386 done (6 errors) -
16:25:51  <Brot6> heqs: rebuild of r371 done -
16:26:15  <Ammler> mäh! :'-(
16:26:38  <Brot6> newgrf_makefile: rebuild of r124 done -
16:27:12  <Brot6> nutracks: rebuild of r90 done (13 errors) -
16:28:39  <Brot6> snowlinemod: rebuild of r15 done -
16:29:08  <Brot6> transrapidtrackset: rebuild of r15 done -
16:30:04  <Brot6> worldairlinersset: rebuild of r659 done -
16:30:05  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: metrotrackset, opengfx
16:34:32  *** frosch123 has joined #openttdcoop.devzone
16:35:48  <planetmaker> quak
16:36:03  <frosch123> moin :)
17:03:33  <Rubidium> Ammler: what happened with grfcodec? I'm missing the build logs
17:03:50  <Ammler> [18:26] <Ammler> mäh!
17:04:06  <Brot6> NFORenum - Revision 456:905477896f65: Fix: assert when $HOME ends with a slash (Rubidium) @
17:04:16  <Ammler> and also the Diffdiff seems not to work as expected
17:09:45  *** thgergo has joined #openttdcoop.devzone
17:13:55  <Brot6> NFORenum - Revision 457:67917b30cd34: Cleanup: make it a bit more clear everything is compiled as... (Rubidium) @
17:26:39  <Brot6> GRFCodec - Revision 216:29fb0e66a184: Cleanup: make it a bit more clear everything is compiled as... (Rubidium) @
17:26:40  <Brot6> NFORenum - Revision 458:5e4ee90afc3f: Fix: make rechecking of dependencies also depend on whether... (Rubidium) @
17:40:26  <Brot6> grfcodec: compile of r216 failed -
17:42:34  <Ammler> error: Installed (but unpackaged) file(s) found:
17:42:36  <Ammler>    /usr/share/doc/grfcodec/readme.txt
17:44:12  <Rubidium> you need to list all files one by one?
17:44:18  <Rubidium> damn... that's a lot of work
17:46:21  <Ammler> you could use wildcards
17:46:25  <Ammler> *
17:47:22  <Brot6> GRFCodec - Revision 217:c0ee2cada2d4: Fix: readme.txt was missing to be packed (Ammler) @
17:48:09  <Rubidium> you do for nforenum, don't you?
17:48:39  <Rubidium> otherwise that would have the same problem, or it doesn't install it properly
17:50:51  <Brot6> grfcodec: update from r206 to r217 done -
17:51:41  <Ammler> yes, nforenum didn't fail
17:51:51  <Ammler> but the readme for grfcodec seems new
17:52:45  <Rubidium> oh...
17:53:30  <Rubidium> two readme's... that's not good
17:54:02  <Brot6> 2cctrainset: rebuild of r573 done (6 errors) (Diffsize: 13) -
17:54:42  <Brot6> 32bpp-extra: rebuild of r38 done (1 errors) (Diffsize: 13) -
17:55:10  <Brot6> airportsplus: rebuild of r52 done (Diffsize: 13) -
17:55:32  <Brot6> basecosts: rebuild of r20 done (Diffsize: 11) -
17:57:09  <Brot6> nforenum: update from r455 to r458 done -
17:57:36  <Brot6> NFORenum - Revision 459:b091f04f4c2a: Fix: two readmes and only copying one... better merge both (Rubidium) @
17:58:16  <Brot6> 2cctrainset: rebuild of r573 done (6 errors) -
17:59:02  <Brot6> GRFCodec - Revision 218:5844cfce5112: Fix: some typos/misnumbering in the readme (Rubidium) @
18:00:30  <Brot6> airportsplus: rebuild of r52 done -
18:00:39  <Ammler> :-(
18:00:51  <Brot6> basecosts: rebuild of r20 done -
18:01:19  <Brot6> comic-houses: rebuild of r71 done (3 errors) -
18:07:00  <Brot6> OpenMSX - Revision 94:e4c68b02a01d: Fix #1202: Replace 'Keep on rolling' (temporarily) with 'Big ... (planetmaker) @
18:07:00  <Brot6> OpenMSX - Bug #1202 (Closed): Corrupt songs crashing MIDI playback (planetmaker) @
18:07:52  <Rubidium> yay++ :)
18:11:54  <planetmaker> hm, worth a bug fix release?
18:13:19  <Rubidium> anything for #1078?
18:13:50  <Rubidium> in any case, for blathijs to package OpenMSX into Debian it would be nice to at least get a release without the GPLv2+ :)
18:14:01  <planetmaker> that's commited
18:14:38  <planetmaker> there's an update by xryu(?) for 7 songs. But... I can't read that zip
18:15:41  <Rubidium>
18:16:43  <planetmaker> that's the same re-packed?
18:17:08  <Rubidium> yep
18:17:23  <Ammler> is there no 7zip for mac?
18:17:26  <Rubidium> unzipping it said bunzipping, so I think the bzip algorithm was used
18:17:38  <planetmaker> oh, it's a 7zip. There probably is
18:17:48  <planetmaker> but I haven't installed it
18:18:05  <Ammler> no, I mean with 7zip, you don't have issues with any archive
18:18:54  <Rubidium> yep, 7z opens it as well
18:19:03  <Rubidium> I just like unzip better :)
18:19:23  <Rubidium> although... yes, 7z is known for being to open an awful lot
18:19:26  <planetmaker> hm... I do you know for sure that these songs are corrupted?
18:19:44  <Rubidium> I don't
18:19:48  <Ammler> on linux not really needed, indeed
18:19:51  <planetmaker> Personally I feel like both, #1202 and #1078 are failures of the music driver
18:19:55  <planetmaker> not of OpenMSX
18:20:17  <planetmaker> as such I feel like I'm working largely around buggy hardware drivers here
18:20:32  <Rubidium> although... the songs in the zip are the same as the ones marked non ok in #1078
18:20:44  <planetmaker> yes.
18:20:52  <Rubidium> planetmaker: it's a bit of both
18:21:01  <Rubidium> the music driver not resetting itself completely
18:21:13  <Rubidium> and the midi not setting all variables it needs to the correct value
18:21:50  <Rubidium> it's like an application crashing because during development all uninitialised "garbage" was zeros and during "producting" it really is garbage
18:25:35  <planetmaker> yes. But the driver is crashing. Which it must not. Whatever is fed to it
18:26:06  <Rubidium> oh... that zip actually seems to fix the sound issue! :)
18:26:22  <planetmaker> So IMHO you should write in the know-bugs that people should complain to their music driver vendor.
18:27:17  <planetmaker> directing people for their crappy drivers to OpenMSX feels wrong
18:28:33  <Rubidium> planetmaker: we all know that complaining to either Apple or Windows isn't going to solve the issue on any short term
18:29:00  <Rubidium> *maybe* they fix it in the next major release, but given that they rather not have you using it even that is unlikely
18:29:00  <planetmaker> sure. But it is the only way to solve this issue for good
18:29:18  <planetmaker> And crashes are some incentive to fix it.
18:29:30  <planetmaker> if people actually report it.
18:29:54  <Ammler> well, but why does it work with original midi, but not with openmsx?
18:30:18  <Rubidium> because original midi wasn't "somewhat" broken
18:35:12  <planetmaker> you basically require from OpenMSX what you don't do with openttd: zero-out all memory every being used while you can leave that (rightfully) to stdlib
18:43:26  *** XeryusTC has quit IRC
18:43:26  *** planetmaker has quit IRC
18:43:26  *** tneo has quit IRC
18:43:26  *** SmatZ has quit IRC
19:31:39  *** Guest1394 has joined #openttdcoop.devzone
19:32:31  *** tneo has joined #openttdcoop.devzone
19:32:31  *** XeryusTC has joined #openttdcoop.devzone
19:32:41  *** Guest1394 is now known as planetmaker
19:33:00  *** SmatZ has joined #openttdcoop.devzone
19:34:36  <Rubidium> planetmaker: we don't leave zero-ing to stdlib; either we tell it to zero via calloc and/or memset or we tell it that we don't need it zeroed via malloc/alloca. The stack variables is something stdlib has no control over and we must set those as well.
19:35:04  <Rubidium> in the case of e.g. java there is basically no way to get non-zeroed memory; everything is initialised as zero/null
19:35:33  <Rubidium> but in C/C++ you always get garbage unless you specifically request zero-ed memory
19:36:32  <planetmaker> probably was a bad analogy then
19:37:41  <Rubidium> no, it's quite good at explaining my point :)
19:38:24  <planetmaker> he
19:38:50  <planetmaker> I still think it's more of a driver problem than one of the individual song
19:39:31  <planetmaker> a song should not need to reset the whole music driver.
19:39:45  <planetmaker> It should do that without specific request for a each song
19:40:10  <Rubidium> planetmaker: true, but *it* should set its own settings instead of assuming there is some default that is always the case
19:41:45  <Rubidium> i.e. if you, in OpenTTD, want to have drive on right you shouldn't assume that when starting it is always set to drive on right, you should check (read: set) that yourself
19:42:20  <Rubidium> ofcourse openttd.cfg / the savegame does that for you, but... long ago that wasn't quite the case
19:42:27  <Rubidium> remember the NewGRF settings stuff?
19:43:51  <planetmaker> I do
19:43:57  <Rubidium> was it a bug of OpenTTD that some users didn't set they NewGRF settings before joining your server?
19:44:35  <Rubidium> I'd say it was a missing feature / not well thought out at most
19:44:38  <planetmaker> hm, now I'm not sure what you mean ;-). I thought you referred to the parameter values of newgrfs
19:45:12  <Rubidium> no, long long ago NewGRF settings weren't stored in the savegame
19:45:26  <planetmaker> oh, I don't remember that really. I wasn't around then
19:45:37  <Rubidium> and NewGRF settings weren't propagated over the network in the server list
19:45:37  <planetmaker> I just know that it was that way, though
19:47:23  <planetmaker> well. I'd be happy if you amended you known bugs that players should (also) complain to their music driver manufacturer :-)
19:47:28  <planetmaker> +r
19:48:23  <planetmaker> any case: you say those 7 updated songs solve the issue for windoze with the sound?
19:48:38  <planetmaker> I listend here, I hear no difference
19:49:00  <Rubidium> I claim that the test case I used is solved
19:49:16  <Rubidium> which is theme -> busy schedule -> theme
20:24:31  <Brot6> FIRS Industry Replacement Set - Bug #1220 (New): Forest - unfinished (andythenorth) @
20:26:30  <frosch123> night
20:26:36  *** frosch123 has quit IRC
21:47:45  <Brot6> OpenMSX - Revision 95:6f8b36926c55: Fix #1078: Let songs set their assumed defaults (editing by X... (planetmaker) @
21:47:45  <Brot6> OpenMSX - Bug #1078 (Closed): songs causing pitch problems to tttheme2.mid using dmusic (planetmaker) @
22:09:46  <Brot6> OpenGFX - Feature #957: forest (athanasios) @
22:13:34  <Rubidium> planetmaker: is that commit going to be followed by a release anytime "soon" (next hour(s))?
22:13:57  <planetmaker> well...
22:14:06  <planetmaker> Might make sense
22:15:07  *** ODM has quit IRC
22:16:52  <planetmaker> so yes
22:19:09  <planetmaker> it will be 0.3.1
22:21:16  <planetmaker> also to satisfy Matthijs :-)
22:34:28  <Brot6> OpenMSX - Revision 96:3ed3cf8db9e8: Doc: Prepare changelog and readme for release (planetmaker) @
22:34:28  <Brot6> OpenMSX - Revision 97:83b3d6cd6b36: Added tag 0.3.1 for changeset 3ed3cf8db9e8 (planetmaker) @
22:34:47  <Brot6> openmsx: update from 0.3.0 to 0.3.1 done -
22:36:18  <Rubidium> are you happy with that tag?
22:36:38  <Rubidium> or in less crypto: can I put that onto the mirrors?
22:37:04  <planetmaker> :-) yes
22:41:21  *** thgergo has quit IRC
22:47:06  <Brot6> OpenMSX - OpenMSX 0.3.1 released (planetmaker) @
23:04:09  *** KenjiE20 has quit IRC
23:04:45  *** KenjiE20 has joined #openttdcoop.devzone

Powered by YARRSTE version: svn-trunk