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) @ http://dev.openttdcoop.org/issues/1174#change-3062 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> http://devs.openttd.org/~frosch/diffs/fs3947.diff 06:36:25 <planetmaker> thanks. I'll test 06:45:20 <planetmaker> yes, that does imho the right thing [TM] 06:47:14 <planetmaker> http://www.tt-forums.net/viewtopic.php?p=895052#p895052 <-- 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 www.tt-forums.net) 06:47:20 <frosch123> https://secure.openttd.org/bugs/task/3947/getfile/6355/bridgesnow2.png <- 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> http://devs.openttd.org/~frosch/diffs/pcxbytesperline.diff <- 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) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/885a0afa08f2 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) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/6f56821949f3 10:15:28 <Brot6> GRFCodec - Revision 211:26083fe2b535: Add: -v to get the version number more easily (and sometime... (Rubidium) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/26083fe2b535 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) @ http://dev.openttdcoop.org/projects/nforenum/repository/revisions/bd0cfa0ee0b5 10:24:36 <Brot6> NFORenum - Revision 448:64c9e855b231: Cleanup: remove trailing whitespace (Rubidium) @ http://dev.openttdcoop.org/projects/nforenum/repository/revisions/64c9e855b231 10:24:36 <Brot6> NFORenum - Revision 449:29fa435b42f3: Cleanup: some lines started with spaces instead of tabs, ma... (Rubidium) @ http://dev.openttdcoop.org/projects/nforenum/repository/revisions/29fa435b42f3 10:25:36 <Brot6> NFORenum - Revision 450:2c548469951c: Fix: for some reason findversion wasn't executable anymore (Rubidium) @ http://dev.openttdcoop.org/projects/nforenum/repository/revisions/2c548469951c 10:29:18 <Brot6> GRFCodec - Revision 212:1bf801b5c1ad: Cleanup: some lines started with spaces instead of tabs (Rubidium) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/1bf801b5c1ad 10:30:45 <Rubidium> http://devs.openttd.org/~rubidium/cf/logs/windows-win32-error.log <- 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> http://dev.openttdcoop.org/issues/1052 <-- 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) @ http://dev.openttdcoop.org/issues/1086#change-3064 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) @ http://dev.openttdcoop.org/issues/957#change-3065 11:24:29 <Brot6> NFORenum - Revision 451:d5815326c945: Fix: String code 9A 04 takes a byte parameter. (frosch) @ http://dev.openttdcoop.org/projects/nforenum/repository/revisions/d5815326c945 11:24:29 <Brot6> NFORenum - Revision 452:e0955c6635a1: Change: Simplify parsing of stringcode 9A 03. (frosch) @ http://dev.openttdcoop.org/projects/nforenum/repository/revisions/e0955c6635a1 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) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/6daf6d4ab052 11:26:31 <Brot6> GRFCodec - Revision 214:4463cf958c5f: Added tag 1.0.0-RC1 for changeset 6daf6d4ab052 (Rubidium) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/4463cf958c5f 11:27:46 <Brot6> GRFCodec - Feature #1081 (Closed): Release 1.0.0 (Rubidium) @ http://dev.openttdcoop.org/issues/1081#change-3066 11:27:52 <Ammler> \o/ 11:36:02 <planetmaker> yippieh :-) 11:43:59 <Brot6> GRFCodec - GRFCodec 1.0.0-RC1 (Rubidium) @ http://dev.openttdcoop.org/news/40 11:44:53 <Brot6> GRFCodec - GRFCodec 1.0.0-RC1 (Rubidium) @ http://dev.openttdcoop.org/news/40 11:48:57 <Brot6> NFORenum - Revision 453:24a4fb47d16b: Update: the changelog (Rubidium) @ http://dev.openttdcoop.org/projects/nforenum/repository/revisions/24a4fb47d16b 11:48:57 <Brot6> NFORenum - Revision 454:c28b41a4e2b7: Added tag 4.0.0-RC1 for changeset 24a4fb47d16b (Rubidium) @ http://dev.openttdcoop.org/projects/nforenum/repository/revisions/c28b41a4e2b7 11:51:00 <Brot6> NFORenum - Feature #1080 (Closed): New Version for distros (Rubidium) @ http://dev.openttdcoop.org/issues/1080#change-3067 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) @ http://dev.openttdcoop.org/news/41 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) @ http://dev.openttdcoop.org/news/41 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> http://bugs.gentoo.org/show_bug.cgi?id=323249 <- that one? 15:00:38 <Webster> Title: Gentoo Bug 323249 - games-util/nforenum crashes when $HOME ends in a slash (at bugs.gentoo.org) 15:00:47 <Rubidium> yes, that one 15:01:18 <planetmaker> apropos upstream: https://secure.openttd.org/bugs/task/3941<-- 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) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/bfe461b03575 15:22:00 <Brot6> NFORenum - Revision 455:72bd619df5c5: Change: add readme and make it harder to accidentally conta... (Rubidium) @ http://dev.openttdcoop.org/projects/nforenum/repository/revisions/72bd619df5c5 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 - http://bundles.openttdcoop.org/grfcodec/nightlies/ERROR/r215 16:20:12 <Brot6> nforenum: update from r442 to r455 done - http://bundles.openttdcoop.org/nforenum/nightlies/r455 16:20:56 <Brot6> swedishrails: update from r140 to r141 done - http://bundles.openttdcoop.org/swedishrails/nightlies/r141 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) - http://bundles.openttdcoop.org/2cctrainset/nightlies/r573/log 16:22:38 <Brot6> 32bpp-extra: rebuild of r38 done (1 errors) - http://bundles.openttdcoop.org/32bpp-extra/nightlies/r38/log 16:22:49 <Brot6> OpenMSX - Bug #1210 (Closed): GPLv2+ vs GPLv2 (Rubidium) @ http://dev.openttdcoop.org/issues/1210 16:22:49 <Brot6> OpenMSX - Revision 92:5fca12cf5135: Fix #1210: Typo in readme (planetmaker) @ http://dev.openttdcoop.org/projects/openmsx/repository/revisions/5fca12cf5135 16:22:49 <Brot6> OpenMSX - Revision 93:33583a427883: Change: Add copyright information to build system (planetmaker) @ http://dev.openttdcoop.org/projects/openmsx/repository/revisions/33583a427883 16:22:49 <Brot6> OpenMSX - Bug #1210 (Closed): GPLv2+ vs GPLv2 (planetmaker) @ http://dev.openttdcoop.org/issues/1210#change-3068 16:23:03 <Brot6> airportsplus: rebuild of r52 done - http://bundles.openttdcoop.org/airportsplus/nightlies/r52/log 16:23:24 <Brot6> basecosts: rebuild of r20 done - http://bundles.openttdcoop.org/basecosts/nightlies/r20/log 16:23:53 <Brot6> comic-houses: rebuild of r71 done (3 errors) - http://bundles.openttdcoop.org/comic-houses/nightlies/r71/log 16:24:33 <Brot6> firs: rebuild of r1121 done (142 errors) - http://bundles.openttdcoop.org/firs/nightlies/r1121/log 16:25:12 <Brot6> fish: rebuild of r386 done (6 errors) - http://bundles.openttdcoop.org/fish/nightlies/r386/log 16:25:51 <Brot6> heqs: rebuild of r371 done - http://bundles.openttdcoop.org/heqs/nightlies/r371/log 16:26:15 <Ammler> mäh! :'-( 16:26:38 <Brot6> newgrf_makefile: rebuild of r124 done - http://bundles.openttdcoop.org/newgrf_makefile/nightlies/r124/log 16:27:12 <Brot6> nutracks: rebuild of r90 done (13 errors) - http://bundles.openttdcoop.org/nutracks/nightlies/r90/log 16:28:39 <Brot6> snowlinemod: rebuild of r15 done - http://bundles.openttdcoop.org/snowlinemod/nightlies/r15/log 16:29:08 <Brot6> transrapidtrackset: rebuild of r15 done - http://bundles.openttdcoop.org/transrapidtrackset/nightlies/r15/log 16:30:04 <Brot6> worldairlinersset: rebuild of r659 done - http://bundles.openttdcoop.org/worldairlinersset/nightlies/r659/log 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) @ http://dev.openttdcoop.org/projects/nforenum/repository/revisions/905477896f65 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) @ http://dev.openttdcoop.org/projects/nforenum/repository/revisions/67917b30cd34 17:26:39 <Brot6> GRFCodec - Revision 216:29fb0e66a184: Cleanup: make it a bit more clear everything is compiled as... (Rubidium) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/29fb0e66a184 17:26:40 <Brot6> NFORenum - Revision 458:5e4ee90afc3f: Fix: make rechecking of dependencies also depend on whether... (Rubidium) @ http://dev.openttdcoop.org/projects/nforenum/repository/revisions/5e4ee90afc3f 17:40:26 <Brot6> grfcodec: compile of r216 failed - http://bundles.openttdcoop.org/grfcodec/nightlies/ERROR/r216 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) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/c0ee2cada2d4 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 - http://bundles.openttdcoop.org/grfcodec/nightlies/r217 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) - http://bundles.openttdcoop.org/2cctrainset/nightlies/r573/log 17:54:42 <Brot6> 32bpp-extra: rebuild of r38 done (1 errors) (Diffsize: 13) - http://bundles.openttdcoop.org/32bpp-extra/nightlies/r38/log 17:55:10 <Brot6> airportsplus: rebuild of r52 done (Diffsize: 13) - http://bundles.openttdcoop.org/airportsplus/nightlies/r52/log 17:55:32 <Brot6> basecosts: rebuild of r20 done (Diffsize: 11) - http://bundles.openttdcoop.org/basecosts/nightlies/r20/log 17:57:09 <Brot6> nforenum: update from r455 to r458 done - http://bundles.openttdcoop.org/nforenum/nightlies/r458 17:57:36 <Brot6> NFORenum - Revision 459:b091f04f4c2a: Fix: two readmes and only copying one... better merge both (Rubidium) @ http://dev.openttdcoop.org/projects/nforenum/repository/revisions/b091f04f4c2a 17:58:16 <Brot6> 2cctrainset: rebuild of r573 done (6 errors) - http://bundles.openttdcoop.org/2cctrainset/nightlies/r573/log 17:59:02 <Brot6> GRFCodec - Revision 218:5844cfce5112: Fix: some typos/misnumbering in the readme (Rubidium) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/5844cfce5112 18:00:30 <Brot6> airportsplus: rebuild of r52 done - http://bundles.openttdcoop.org/airportsplus/nightlies/r52/log 18:00:39 <Ammler> :-( 18:00:51 <Brot6> basecosts: rebuild of r20 done - http://bundles.openttdcoop.org/basecosts/nightlies/r20/log 18:01:19 <Brot6> comic-houses: rebuild of r71 done (3 errors) - http://bundles.openttdcoop.org/comic-houses/nightlies/r71/log 18:07:00 <Brot6> OpenMSX - Revision 94:e4c68b02a01d: Fix #1202: Replace 'Keep on rolling' (temporarily) with 'Big ... (planetmaker) @ http://dev.openttdcoop.org/projects/openmsx/repository/revisions/e4c68b02a01d 18:07:00 <Brot6> OpenMSX - Bug #1202 (Closed): Corrupt songs crashing MIDI playback (planetmaker) @ http://dev.openttdcoop.org/issues/1202#change-3069 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> rbijker.net/openttd/foes.zip 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) @ http://dev.openttdcoop.org/issues/1220 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) @ http://dev.openttdcoop.org/projects/openmsx/repository/revisions/6f8b36926c55 21:47:45 <Brot6> OpenMSX - Bug #1078 (Closed): songs causing pitch problems to tttheme2.mid using dmusic (planetmaker) @ http://dev.openttdcoop.org/issues/1078#change-3072 22:09:46 <Brot6> OpenGFX - Feature #957: forest (athanasios) @ http://dev.openttdcoop.org/issues/957#change-3073 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) @ http://dev.openttdcoop.org/projects/openmsx/repository/revisions/3ed3cf8db9e8 22:34:28 <Brot6> OpenMSX - Revision 97:83b3d6cd6b36: Added tag 0.3.1 for changeset 3ed3cf8db9e8 (planetmaker) @ http://dev.openttdcoop.org/projects/openmsx/repository/revisions/83b3d6cd6b36 22:34:47 <Brot6> openmsx: update from 0.3.0 to 0.3.1 done - http://bundles.openttdcoop.org/openmsx/releases/0.3.1 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) @ http://dev.openttdcoop.org/news/42 23:04:09 *** KenjiE20 has quit IRC 23:04:45 *** KenjiE20 has joined #openttdcoop.devzone