Times are UTC Toggle Colours
00:02:04 *** KenjiE20 [~KenjiE20@92.9.250.146] has quit [Quit: WeeChat 0.3.2] 00:09:54 *** zachanima [~zach@2506ds3-od.0.fullrate.dk] has quit [Quit: leaving] 00:11:41 *** Lakie [~Lakie@91.84.251.149] has quit [Quit: Thunder and lighting, very very frightening. ;)] 00:17:26 *** Eoin [eoin@cpc1-dund8-0-0-cust3.sgyl.cable.virginmedia.com] has joined #openttd 00:22:21 *** tokai|noir [~tokai@port-92-195-203-52.dynamic.qsc.de] has quit [Ping timeout: 480 seconds] 00:22:30 *** zachanima [~zach@2506ds3-od.0.fullrate.dk] has joined #openttd 00:37:57 <Eddi|zuHause> hm... is that a trick that my limited knowledge of slavic languages plays me or does "Belgrad" mean "Whitecastle"? 00:41:18 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has quit [Quit: TschÃŒÃ] 00:41:45 *** KritiK [~Maxim@95-26-11-146.broadband.corbina.ru] has quit [Quit: Leaving] 00:44:32 *** Fast2 [~Fast2@p57AF9FC4.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 00:56:17 *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has joined #openttd 01:03:23 *** Polygon [~Poly@x0581b.wh7.tu-dresden.de] has quit [Remote host closed the connection] 01:27:40 *** ajmiles [~aj@78-86-188-187.zone2.bethere.co.uk] has quit [Quit: Leaving] 01:48:57 *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has quit [Ping timeout: 480 seconds] 02:03:20 *** `Fuco` [~dota.keys@fuco.sks3.muni.cz] has quit [Ping timeout: 480 seconds] 02:24:23 *** rhaeder1 [~quix0r@dslb-094-221-137-135.pools.arcor-ip.net] has joined #openttd 02:25:20 *** Chillosophy^ [~fu@195-241-120-76.ip.telfort.nl] has quit [] 02:25:24 *** rhaeder [~quix0r@dslb-094-220-140-051.pools.arcor-ip.net] has quit [Read error: Connection reset by peer] 02:38:19 *** glx [glx@2a01:e35:2f59:c7c0:5053:b88f:6fe4:5c8b] has quit [Quit: bye] 03:38:56 *** llugo [~lugo@f055114098.adsl.alicedsl.de] has quit [Remote host closed the connection] 04:01:32 *** deghosty [~s@69-165-128-62.dsl.teksavvy.com] has joined #openttd 04:02:32 *** De_Ghosty [~s@69-165-128-62.dsl.teksavvy.com] has quit [Ping timeout: 480 seconds] 04:18:13 *** deghosty [~s@69-165-128-62.dsl.teksavvy.com] has quit [Remote host closed the connection] 04:19:35 *** De_Ghosty [~s@69-165-128-62.dsl.teksavvy.com] has joined #openttd 04:56:03 *** Eddi|zuHause [~johekr@p54B76A9C.dip.t-dialin.net] has quit [] 04:56:21 *** Eddi|zuHause [~johekr@p54B744A2.dip.t-dialin.net] has joined #openttd 05:20:09 *** Kurimus [Kurimus@dsl-tkubrasgw1-fe32dc00-253.dhcp.inet.fi] has joined #openttd 05:35:23 *** seirmubsa [~seirmubsa@166.82.121.120] has quit [Remote host closed the connection] 05:44:49 *** seirmubsa [~seirmubsa@h120.121.82.166.static.ip.windstream.net] has joined #openttd 05:50:45 *** Goulp [~Goulp@main.goulp.net] has quit [Read error: No route to host] 05:55:45 *** Muxy [~Muxy@main.goulp.net] has quit [Ping timeout: 480 seconds] 06:35:59 *** ^Spike^ [~spike@d200003.upc-d.chello.nl] has joined #openttd 06:49:48 *** einKarl [~einKarl@95-89-121-65-dynip.superkabel.de] has joined #openttd 06:52:58 *** KouDy [~KouDy@rb5ck203.net.upc.cz] has joined #openttd 07:19:46 *** devilsadvocate [~devilsadv@202.3.77.209] has quit [Ping timeout: 480 seconds] 07:28:22 *** devilsadvocate [~devilsadv@202.3.77.202] has joined #openttd 07:49:58 *** Muxy [~Muxy@main.goulp.net] has joined #openttd 07:57:02 *** frosch123 [~frosch@frnk-590f5bc3.pool.mediaWays.net] has joined #openttd 08:09:27 *** theholyduck [~holyduck@ip-62-139-106-77.eidsiva.net] has quit [Ping timeout: 480 seconds] 08:11:04 <planetmaker> good morning 08:19:15 <Yexo> good morning 08:25:49 <Yexo> TrueBrain / Rubidium: could either of you take a look at noai.openttd.org at lib-direction and lib-string? I've created those projects this morning but the svn repos don't work 08:26:04 <Yexo> when trying to checkout either of them I get "Could not open the requested SVN filesystem" 08:26:41 <Yexo> previously they were generated at *:18, has this been changed? 08:27:00 <Yexo> also trying to view the repository from the project page doesn't work for any project doesn't work, for example http://noai.openttd.org/repositories/show/ai-admiralai 08:40:54 <frosch123> hmm, posting news is somewhat monologueish 09:02:41 *** devilsadvocate [~devilsadv@202.3.77.202] has quit [Ping timeout: 480 seconds] 09:14:43 <TrueBrain> Yexo: fixed and fixed 09:15:10 <Yexo> thanks 09:15:17 <TrueBrain> at least, I hope :p 09:18:45 *** fonsinchen [~fonsinche@brln-4dba9c37.pool.mediaWays.net] has joined #openttd 09:34:07 *** woldemar [~maru@213.178.34.57] has joined #openttd 09:37:58 *** KenjiE20 [~KenjiE20@92.9.250.146] has joined #openttd 09:53:37 <fjb> Moin 10:03:51 *** einKarl [~einKarl@95-89-121-65-dynip.superkabel.de] has quit [Remote host closed the connection] 10:05:58 *** Fast2 [~Fast2@p57AF8166.dip0.t-ipconnect.de] has joined #openttd 10:13:25 *** woldemar [~maru@213.178.34.57] has quit [Quit: ã§ãã¯æ»çšœãããªãã§ããç§ã¯æ¬æ°ã§ãã] 10:22:34 *** KritiK [~Maxim@95-26-104-129.broadband.corbina.ru] has joined #openttd 10:26:15 *** heffer [~felix@static-87-78-98-150.netcologne.de] has joined #openttd 10:26:21 *** Progman [~progman@p57A1D33E.dip.t-dialin.net] has joined #openttd 10:33:52 <Rubidium> TrueBrain: should we celebrate the r10000 party's third anniversary? 10:34:18 <TrueBrain> hahahaha 10:35:01 <Rubidium> was it really on a wednesday?!? 10:35:23 <Rubidium> hmm, I guess because I went back to E'de at that day 10:39:21 *** Chillosophy [~fu@195-241-120-76.ip.telfort.nl] has joined #openttd 10:47:15 *** frosch123 [~frosch@frnk-590f5bc3.pool.mediaWays.net] has quit [Remote host closed the connection] 10:55:22 *** Polygon [~Poly@x0581b.wh7.tu-dresden.de] has joined #openttd 11:06:33 *** ecke [~ecke@188.75.128.2] has quit [Quit: more listen, more understand, more know] 11:12:45 *** lugo [~lugo@mgdb-4db8ce19.pool.mediaWays.net] has joined #openttd 11:15:26 *** [com]buster [~eternal@cust-03-55bf402e.adsl.scarlet.nl] has joined #openttd 11:21:17 *** Fast2 [~Fast2@p57AF8166.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 11:22:13 *** PeterT [~PeterT@peter.tarkoy.com] has quit [Quit: Goodbye] 11:22:39 *** PeterT [PeterT@peter.tarkoy.com] has joined #openttd 11:24:00 *** PeterT [PeterT@peter.tarkoy.com] has quit [] 11:24:49 *** PeterT [PeterT@peter.tarkoy.com] has joined #openttd 11:24:50 *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has joined #openttd 11:33:14 * andythenorth wonders if it's time to make the FIRS Aluminium Plant require electricity... 11:34:53 <andythenorth> think it will make gameplay too...brittle 11:36:12 <andythenorth> Eddi|zuHause, planetmaker any opinion? ^ 11:36:35 *** |Jeroen| [~jeroen@94-224-31-113.access.telenet.be] has joined #openttd 11:36:51 <planetmaker> require electricity = power plant nearby? 11:37:08 <andythenorth> yep, within n tiles 11:37:26 <andythenorth> 100% production if so, otherwise production 50% 11:38:01 <andythenorth> it would mean supplying the power plant with coal, so Aluminium would become very intensive on input cargos 11:38:21 <andythenorth> I can't think of a way to add a hydro plant to the game :P 11:38:52 <andythenorth> reality is most Aluminium Mills are near hydro, geo-thermal or nuclear generators 11:39:25 <planetmaker> hydroplant... and industry with water and land tiles 11:39:51 <andythenorth> needs to be on a river....wallyweb faked one once, but rivers are not exactly in common use 11:40:05 <andythenorth> (wallyweb faked a hydro plant that is) 11:40:08 <planetmaker> well, don't rely on it. But would be nice :-) 11:40:22 <planetmaker> it would only accept ENSP 11:40:35 <planetmaker> or water :-P 11:40:37 *** fonsinchen [~fonsinche@brln-4dba9c37.pool.mediaWays.net] has quit [Ping timeout: 480 seconds] 11:40:41 <andythenorth> :P 11:41:10 <andythenorth> rivers in world generator any time soon? Probably not....? 11:41:18 <planetmaker> if there's space... please add one :-) 11:41:29 <planetmaker> maybe even if it requires a river in the middle. I'd love that! 11:41:39 <planetmaker> It'd give scenario makers incentive ;-) 11:41:54 <andythenorth> I'd do it if the world generator provided rivers 11:41:56 <andythenorth> not otherwise 11:42:12 <planetmaker> it doesn't yet. But it's easily possible in the SE. 11:42:19 <andythenorth> I know, but who bothers :P 11:42:23 <planetmaker> I do 11:42:26 <andythenorth> ! 11:42:27 <andythenorth> :) 11:43:08 <andythenorth> hydro plant would need quite some thought 11:43:24 <planetmaker> it'd be IMHO a nice easter egg :-) 11:43:29 <planetmaker> for those who care :-) 11:43:39 <andythenorth> controlling placement would be a nightmare 11:43:52 <andythenorth> it would need a very precise difference in height levels 11:43:55 <planetmaker> not really. Just require one, two layouts, that's it. 11:44:00 <andythenorth> hmmm 11:44:01 <planetmaker> yes... 11:44:24 <planetmaker> or maybe four layouts. Each direction one 11:44:27 <andythenorth> if it was just 1 or so tiles across a river that would work 11:44:45 <planetmaker> that's what I thought with one, two adjacent tile left/right of the river 11:44:55 <andythenorth> work for another day though 11:45:10 <planetmaker> oh :-( 11:45:15 <andythenorth> sorry 11:45:22 <andythenorth> so much else to do on FIRS :) 11:48:16 <andythenorth> planetmaker: http://www.tt-forums.net/viewtopic.php?f=26&t=41607&p=881679#p881679 11:50:05 <planetmaker> yes, nicer :-) 11:51:57 *** tokai [~tokai@port-92-195-203-52.dynamic.qsc.de] has quit [Ping timeout: 480 seconds] 11:53:50 <andythenorth> I need to do something about empty tiles. My layouts look better with some tiles mostly empty. But Simon Foster didn't have empty industry tiles. 11:54:03 *** tycoondemon [~thok@cc64025-c.hnglo1.ov.home.nl] has quit [Ping timeout: 480 seconds] 11:54:16 *** tokai [~tokai@port-92-195-117-210.dynamic.qsc.de] has joined #openttd 11:54:19 *** mode/#openttd [+v tokai] by ChanServ 11:56:02 <planetmaker> add cargo there depending upon production 11:56:05 <planetmaker> and delivery 11:56:36 <planetmaker> possibly also upon how much is shipped 11:56:48 <Ammler> he, you you need them looking like Foster industries? 11:56:51 <Ammler> you replace all 11:56:55 <Ammler> why* 11:57:18 <andythenorth> hmm 11:57:47 <andythenorth> was metropolitan airport in the original game? 11:58:04 <Ammler> only small and city 11:58:26 <andythenorth> nvm 11:58:28 <Ammler> TTO, never placed TTD 11:58:34 <andythenorth> city airport has empty tiles 11:58:40 <andythenorth> so there is a precedent :P 12:00:07 <andythenorth> it would be nice if industries were fenced by default, but the fences were removed if a station tile is adjacent 12:00:18 <andythenorth> I think that's possible, but I don't know if I can be bothered to work it out :o 12:06:57 <planetmaker> I guess it's possible. You'd need to check adjacent tile type 12:10:00 <planetmaker> Rubidium: what's your view on introducing 32bpp replacements basically only via newgrf? 12:10:09 <planetmaker> where there's always a 8bpp fall-back? 12:10:21 *** ajmiles [~aj@78-86-188-187.zone2.bethere.co.uk] has joined #openttd 12:10:46 <planetmaker> the more I think about that approach the more I like it 12:11:08 <planetmaker> As it means that no other changes are needed than extending the newgrf specs 12:13:09 *** KouDy [~KouDy@rb5ck203.net.upc.cz] has quit [Read error: Connection reset by peer] 12:14:50 *** glx [glx@2a01:e35:2f59:c7c0:1437:4ee4:1943:ae23] has joined #openttd 12:14:53 *** mode/#openttd [+v glx] by ChanServ 12:19:29 *** KouDy [~KouDy@rb5ck203.net.upc.cz] has joined #openttd 12:21:09 *** Fast2 [~Fast2@p57AF8166.dip0.t-ipconnect.de] has joined #openttd 12:29:30 *** fonsinchen [~fonsinche@brln-4dba9c37.pool.mediaWays.net] has joined #openttd 12:30:57 *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has quit [Ping timeout: 480 seconds] 12:36:56 *** asilv [~as@dsl-lprbrasgw1-ff1ec100-158.dhcp.inet.fi] has joined #openttd 12:48:40 *** Kogut [~Kogut@225-kr1-4.acn.waw.pl] has joined #openttd 12:49:28 *** [com]buster [~eternal@cust-03-55bf402e.adsl.scarlet.nl] has quit [Remote host closed the connection] 13:05:39 *** Fuco [~dota.keys@fuco.sks3.muni.cz] has joined #openttd 13:08:14 *** frosch123 [~frosch@frnk-590f5bc3.pool.mediaWays.net] has joined #openttd 13:08:48 *** tokai [~tokai@port-92-195-117-210.dynamic.qsc.de] has quit [Ping timeout: 480 seconds] 13:11:02 *** tokai [~tokai@port-92-195-123-66.dynamic.qsc.de] has joined #openttd 13:11:05 *** mode/#openttd [+v tokai] by ChanServ 13:11:50 *** Polygon [~Poly@x0581b.wh7.tu-dresden.de] has quit [Quit: Flieht, ihr Narren!] 13:13:41 *** fonsinchen [~fonsinche@brln-4dba9c37.pool.mediaWays.net] has quit [Ping timeout: 480 seconds] 13:33:41 *** rhaeder1 [~quix0r@dslb-094-221-137-135.pools.arcor-ip.net] has quit [Quit: Leaving.] 13:35:08 *** rhaeder [~quix0r@dslb-094-221-137-135.pools.arcor-ip.net] has joined #openttd 13:40:53 <ccfreak2k> andythenorth, maybe investigating the fence code for railroad tracks is a good start. 13:45:11 <OwenS> planetmaker: I remember one of the Patch devs discussing 32-bpp in GRF a while back 13:48:05 *** Kogut [~Kogut@225-kr1-4.acn.waw.pl] has quit [Read error: Connection reset by peer] 13:52:23 <frosch123> including 32bpp directly into the grf is very stupid, as it makes the md5sum depend on 32bpp included 13:52:37 <frosch123> but, well, rb already wrote everything on the forum 13:54:09 *** asnoehu [~thok@cc64025-c.hnglo1.ov.home.nl] has joined #openttd 13:54:16 *** glx_ [glx@2a01:e35:2f59:c7c0:5da:2647:de83:b703] has joined #openttd 13:54:19 *** mode/#openttd [+v glx_] by ChanServ 13:54:52 *** asnoehu is now known as tycoondemon 13:55:47 <OwenS> frosch123: Would it not be sane for NewGRFs? The currrent separate system is rather unfriendly 13:56:21 <Eddi|zuHause> andythenorth: if grfcodec errors out with "Could not parse unquoted escape sequence. While reading sprite:1204" is that my fault, my ancient grfcodec's fault or your fault? (while compiling firs) 13:56:35 <andythenorth> Eddi|zuHause: let me see 13:56:35 <frosch123> OwenS: you can put the grf and the png in one tar, so it is not unfriendly at all 13:57:01 <frosch123> there is absolutely no difference for the user between downloading one grf or one tar 13:57:24 <frosch123> but there is a big technical advantage to not use grf for 32bpp 13:57:34 <Rubidium> OwenS: 32bpp seems to be about 50 to 100 times larger than 8bpp 13:57:39 <OwenS> frosch123: OK, so what is the technical downside of packing everything into the GRF? It changing the md5sum is a non-issue as I would expect that GRFs would come natively with 32bpp... 13:57:40 <andythenorth> Eddi|zuHause: I don't know....can you paste sprite 1204 (from compiled firs.nfo)? 13:57:56 <Rubidium> OwenS: would you like a NewGRF being that much larger if you only need/like 8bpp 13:58:18 <OwenS> Rubidium: GRF author's decision. Besides, if the author is shipping a tar, same issue. And its not like it takes time to download... 13:58:38 <frosch123> OwenS: can you name any advantage for putting them in the grf? i see only disadvantages 13:58:50 <Eddi|zuHause> andythenorth: http://paste.openttd.org/225867 13:58:54 <OwenS> frosch123: Lets see... Less fragile. The current system breaks if any sprites get renumbered 13:58:57 *** glx [glx@2a01:e35:2f59:c7c0:1437:4ee4:1943:ae23] has quit [Ping timeout: 480 seconds] 13:59:15 <frosch123> OwenS: that is no reason 13:59:16 <Rubidium> OwenS: but I proposed separating the 8bpp from the 32bpp in bananas, so if you need only 8bpp you need to download only the 8bpp part, not the 32bpp stuff 13:59:25 <frosch123> that is only a matter of the tool which creates the tar 13:59:37 <andythenorth> Eddi|zuHause: what rev FIRS do you have? That looks like experimental code which should be removed / commented out? 14:00:08 <OwenS> Rubidium: The average user doesn't understand 32bpp. "Why do I have to download *two* files to make the graphics fit together?" 14:00:27 <Eddi|zuHause> what's the hg equivalent to "svn info"? 14:00:31 <frosch123> OwenS: that is no reason either, you can include the grf into the tar 14:00:48 <frosch123> you could provide a tar without the 32bpp sprites, and one with 14:01:06 <frosch123> bananas already deliveres every grf in a tar 14:01:15 <OwenS> frosch123: OK, and now the user has to figure out which one to download 14:01:35 <OwenS> How many people really care about the extra few kilobytes that 32bpp graphics add? 14:01:37 <frosch123> great, the user also has to figure out whether to download the win32 or win64 build 14:01:38 <Eddi|zuHause> andythenorth: changeset: 868:33e592546dfe date: Sun May 30 18:13:26 2010 +0100 14:01:49 <Rubidium> OwenS: they can be represented as 1 "file" inside openttd 14:02:01 <frosch123> OwenS: the user just has to decide whether he wants to download the 1mb 8bpp graphics, or the 50mb 32bpp graphics 14:02:36 <OwenS> Rubidium: And on bannanas? 14:02:44 <OwenS> How does it decide which one too download? 14:02:45 <Rubidium> OwenS: same thing 14:03:11 <Rubidium> OwenS: if 32bpp, then download the 32bpp "extra" pack + the 8bpp 14:03:32 <Rubidium> upgrade selects all 32bpp graphics of already existing 8bpp graphics if 32bpp is chosen 14:03:34 <OwenS> Rubidium: OK. And then the user switches from 8bpp to 32bpp. How do you handle this? 14:04:12 <andythenorth> Eddi|zuHause: do you have a FIRS save game? I am going to fix that and commit - but FIRS is very *not* save game compatible at the moment :o 14:04:24 <Eddi|zuHause> no, i have not ;) 14:04:46 <planetmaker> I guess a good way would be a checkbox in the download window: [x] download 32bpp version 14:05:10 <OwenS> planetmaker: And now you need to teach users what 32bpp means 14:05:22 <frosch123> OwenS: you can imagine 3 types of files, 8bpp only, 32bpp+8bpp, and 32bpp-upgrade for already downloaded 8bpp 14:05:23 <planetmaker> [x] download true colour 14:05:28 <frosch123> all of them are tars, and single files 14:05:52 <planetmaker> frosch123, that sound unnecessary. Rather two is sufficient 14:05:53 <frosch123> though i doubt the 32bpp-upgrade is worth it, the 8bpp part likely does not matter 14:06:03 <andythenorth> Eddi|zuHause: try the newest FIRS - I've just pushed 14:06:10 <andythenorth> there are 3 known compile errors 14:06:52 <Eddi|zuHause> *mental note* "git fetch" won't work on a hg working copy :p 14:08:11 <Eddi|zuHause> andythenorth: now there are plenty of renum-errors 14:08:31 <Eddi|zuHause> but it did create a firs.grf 14:08:53 <andythenorth> I get two renum errors, both non-critical warnings, and also some white pixels 14:09:31 <andythenorth> my renum is old, I've tried to update it, but I can't figure out how to put it in the path for make :P 14:09:42 <Eddi|zuHause> andythenorth: http://paste.openttd.org/225868 14:10:06 <andythenorth> hmm 14:10:11 <Eddi|zuHause> andythenorth: yesterday it did have only the 2 warnings 14:10:17 <andythenorth> that's rather a lot. suspect I forgot to commit a file 14:10:21 <andythenorth> yup I can guess which one :P 14:10:24 <OwenS> I still think that its overcomplicating things 14:11:16 <andythenorth> Eddi|zuHause: I've pushed a fix for the missing file :0 14:11:45 <Rubidium> OwenS: agreed, just forget the whole 32bpp thing 14:12:11 <Eddi|zuHause> andythenorth: yup, better now 14:12:17 <OwenS> Rubidium: No. Just have one architve. Whether thats tar, or intergrated grf, doesn't matter :p 14:12:46 <Jupix> Rubidium: can I put that in my sig? 14:12:57 <andythenorth> Eddi|zuHause: what do you think of the revised Aluminium Plant? 14:13:28 <Eddi|zuHause> hm, why does renum return errorlevel 3 when warnings occured, but errorlevel 4 (higher=less severe) when errors occured? 14:14:37 <Rubidium> Jupix: feel free if you think that helps your cause 14:15:01 <__ln__> btw, it's spelled 'occurred' 14:15:24 <Eddi|zuHause> i have a feeling the 32bpp project is heading in the wrong general direction currently 14:15:36 <Eddi|zuHause> __ln__: whatever ;) 14:15:45 <Rubidium> Eddi|zuHause: so do I 14:15:50 <__ln__> Eddi|zuHause: i only figured that out a month ago myself :) 14:16:04 * andythenorth doesn't understand 32bpp 14:16:07 <frosch123> OwenS: fine, so give the tar a differen filextension 14:16:12 <andythenorth> what is it exactly? 14:16:13 <Eddi|zuHause> __ln__: any version i tried in the past did look kind of wrong... 14:16:19 <Jupix> feel free to post the "right" direction in the forums, that's why they're there 14:17:30 <Jupix> (in the org thread preferably) 14:18:51 <Jupix> also, it might be good if you put into words where you *think* it's heading, since it's most likely mistaken since you think it's a bad thing 14:19:04 <Eddi|zuHause> Jupix: there's a fundamental difference between noticing something is wrong, and determining what is right instead :p 14:19:05 * andythenorth reads forums 14:19:54 * andythenorth blew up the game 14:20:13 <Jupix> Eddi|zuHause: I know, but I can't do much if you just say something's "wrong" 14:20:33 <Eddi|zuHause> i'm not in the mood to discuss that right now... 14:20:34 <Jupix> whereas if you pitch an idea and it's a good one, I can try to steer things into that direction 14:20:48 <Eddi|zuHause> maybe some day... 14:21:06 <frosch123> andythenorth: basically there are two parties about 32bpp: those who want it, do not know how it works, and blame ottd to add support. and those who know how it works, know that ottd supports it for 3 years, and are not interested in it 14:21:14 <Eddi|zuHause> i could pull a MB and say "i have said that before" :p 14:21:49 * andythenorth goes back to compiling grfs that crash the game :P 14:21:55 <andythenorth> frosch123: thanks btw 14:21:59 <frosch123> Jupix: just read ammlers post frmo three days ago 14:22:38 <frosch123> the "rest" is just packaging 14:23:14 <OwenS> frosch123: Theres a thrid party: Those of us who want it, know OpenTTD supports it, and wishes the graphics were all combined together in some trunk-friendly package (Maybe they are now?) 14:24:18 * andythenorth finds another case in FIRS which could use 'field tiles' :) 14:24:19 <Jupix> frosch123: you're telling *me* to read the 32 bit forums? 14:24:30 <Rubidium> Jupix: bounding boxes are a bitch and designed for the current graphics. With correctly scaled (3-5? times as) long wagons/engines you'll end up in a hell of sprite ordering glitches because of the "crude" ordering 14:25:07 <Rubidium> which would mean totally rewriting the sprite ordering, possibly removing the hacks 14:25:18 <frosch123> oh, long vehicles again :p even more important there is fundamental design in ottd which requires a vehicle to be only on one tile at everytime 14:25:33 <Jupix> we're not pushing for that feature at this time 14:25:59 <frosch123> Rubidium: actually you have to trash sprite ordering and add z buffers instead 14:26:01 <Rubidium> which would mean bridges need to go higher and that implies bridge heads getting two tiles long 14:26:44 <Rubidium> and then "the slopes" are too steep, so they need to become less steep this the bridge head becomes 4 tiles long 14:27:07 <frosch123> :p 14:27:08 * Jupix is not listening and doesn't really care either 14:27:14 <Jupix> it's Ben's feature request 14:27:48 *** Chruker [~no@port113.ds1-vj.adsl.cybercity.dk] has joined #openttd 14:27:48 <Jupix> what I *do* care about is the packaging, as you so elegantly put it 14:28:08 <Jupix> as that makes all the difference in how the "32bpp thing" is perceived these days 14:28:49 <Jupix> as long as it's just a hack that *may* work after hours of newbie-hacking of the client, it has no chance, and I don't like that 14:29:47 <frosch123> Jupix: again, there are absolutely no changes required to ottd at the moment. 14:30:05 <Jupix> define "required" 14:30:25 <Jupix> yes, it boots and displays 32 bits without changes, but it sucks 14:30:32 <frosch123> you want a single file package which adds 32bpp sprites to the game in a toggleable form, right? 14:30:32 <Jupix> making changes would make it better for the player 14:30:49 <frosch123> independent of other grfs and their spritenumbering 14:31:05 <frosch123> right? 14:31:41 <Jupix> what I want is this: http://wiki.openttd.org/Base_graphics#Creating_a_base_graphics_set in 32 bits, and I was told that it's impossible without new code 14:31:51 <frosch123> who told you that? 14:31:51 <Rubidium> and something that works with upcoming (not yet released) grfs as well? 14:32:25 <Jupix> frosch123: I can look it up if you really care. :D 14:32:29 <Jupix> when I get home 14:32:46 <frosch123> Jupix: the link you gave me is about technical format details, not what you want to do 14:32:53 <Jupix> though a solution would be more useful than a "xxx's wrong" refuttal :D 14:33:40 <frosch123> so i put it like that: you want a 32bpp baseset selectable from the game options? 14:34:34 <Jupix> and downloadable next to ogfx in the content service, that's very important, and I thought it'd make sense if it was the same format used for 8 bit gfx 14:35:06 <frosch123> ok, content service won't work for now, and considering the bandwidth i do not favor it either 14:35:13 <Jupix> fewer sprite delivery methods to support and teach new artists 14:35:39 <frosch123> what? 14:35:44 <frosch123> i do not understand that 14:36:33 <Jupix> well, currently, if you want to distribute 8 bit gfx, you need to learn how to make them into .grfs... correct? 14:36:57 <frosch123> i doubt you can invent a format which does not require learning 14:37:05 <Jupix> just answer the question 14:37:24 <frosch123> ok, yes 14:37:28 * Rubidium wonders what is wrong about teaching NML about 32bpp graphics 14:37:43 <frosch123> Rubidium: nothing, just noone in interested yet to add it 14:38:06 <Jupix> and currently, if you want to distribute 32 bit gfx, you need to learn how tars work. if 32 bit gfx went into grfs, you'd only need to learn how *they* work 14:38:48 <Rubidium> Jupix: again, my suggestion should solve that 14:39:01 <Jupix> so if GRFs were the only sprite delivery method, it would make the ecosystem simpler for a newbie who wants to learn how to do things 14:39:04 <frosch123> "currently yes". but that is only a matter of tools. nml has the potential to replace nforenum, grfcodec and tar 14:39:13 <frosch123> it already combines the first two 14:39:52 <Rubidium> Jupix: consider that grfcodec and nforenum could be considered abandoned 14:40:00 <Jupix> I don't really care how it's solved. what I'm trying to say is that it's currently suboptimal and whatever the solution, would be an improvement, as long as it addresses to concerns that I've written up in the forums 14:40:25 <frosch123> fine, jupix, then think of nml as your solution. 14:42:14 <Ammler> basically, currently only basesets (without the extra) supports 32bpp replacement easy 14:42:43 *** pugi [~pugi@p4FCC4135.dip.t-dialin.net] has joined #openttd 14:43:24 <Ammler> the extra grf and newgrfs conflict with the static sprite number 14:44:00 <frosch123> Ammler: you are thinking in the way of an add-on. the method to release a 32bpp-addon which should work with any 8bpp replacement set is broken in itself 14:44:08 <frosch123> the 32bpp-one needs to be a baseset itself 14:44:33 <planetmaker> Jupix, you seem to have gotten me completely wrong 14:44:38 <Ammler> yes, with it's own extra grf, which they have 14:44:57 <Ammler> but still, you can't change sprite number that easy. 14:45:00 <frosch123> it should also have its own basic grfs 14:45:07 <Ammler> specially if you like to use 32bpp in newgrfs 14:45:16 <frosch123> even if they only contain pure black sprites with white text "activate 8bpp!" 14:45:20 <Jupix> planetmaker: please don't spin the forum discussion into an IRC discussion, that'll leave everyone else confused :) 14:45:20 <frosch123> err 32bpp 14:45:34 <planetmaker> Jupix, a base set needs to be per definition at least 8bpp. 14:45:49 *** elmz [~elmz@222.80-202-29.nextgentel.com] has quit [Read error: Connection reset by peer] 14:46:11 *** fonsinchen [~fonsinche@brln-4dba9c37.pool.mediaWays.net] has joined #openttd 14:46:11 <planetmaker> since 8bpp is _base_, the minimum requirement for OpenTTD to do anything 14:46:20 <planetmaker> 32bpp may be included on top. 14:46:25 <Ammler> maybe nml could beside the 8bpp sprites also have a path to the 32bpp graphics, with offsets 14:46:26 <planetmaker> You may that then call 32bpp base set 14:47:05 <frosch123> Ammler: it could also encode directly into a tar including readme and license and such 14:47:10 <frosch123> just someone has to do it :p 14:47:15 <Ammler> yep :-) 14:47:53 <planetmaker> frosch123, would it make sense to make OpenGFX 8bpp release and OpenGFX 8+32bpp release? 14:47:57 <Rubidium> Ammler: http://www.tt-forums.net/viewtopic.php?p=881674#p881674 <- I already proposed that 14:48:12 <planetmaker> should be moderately easy to sustain 14:48:16 <Jupix> planetmaker: I just don't get the "why" of that 14:48:26 <planetmaker> Jupix, _base_ set 14:48:42 <Jupix> yeah, but why can't the base be in 32 bits? 14:48:44 *** elmz [~elmz@222.80-202-29.nextgentel.com] has joined #openttd 14:48:45 <planetmaker> if you only have 32bpp any person having a 8bpp display would not be able to use the base set 14:48:54 <planetmaker> and a base set per definition runs on any platform 14:49:06 <Ammler> hmm, maybe geekto should simply change the 32bpp-extra to 32bpp-baseset 14:49:08 <planetmaker> so any 32bpp per definition has to ship 8bpp, too 14:49:37 <planetmaker> you'd break OpenTTD completely, if you don't have a 8bpp alternative to 32bpp 14:49:40 <Jupix> planetmaker: ok, so suppose someone has an 8 bit display. why is he downloading the 32 bit base set instead of the 8 bit options? 14:50:08 <planetmaker> Jupix, currently everything "just works". 14:50:14 <planetmaker> Changing that is IMHO not a good thing 14:50:19 <frosch123> it is not worth to discuss 32bpp only stuff, 8bpp can be included at zero cost 14:50:23 <Jupix> everything except 32 bit gfx 14:50:31 <frosch123> even if it is only black on white 14:50:46 <planetmaker> black boxes! 14:51:10 <planetmaker> Jupix, I don't get why you want to throw away compatibility only for the vanity of "32bpp only set" 14:51:21 <Ammler> does nml support Action5 already? 14:51:26 <planetmaker> Ammler, IIRC yes 14:52:10 <Jupix> planetmaker: what is it exactly that would remove compatibility? last I checked, ottd ships with NO base set 14:52:22 <Jupix> you've got a choice of 3 instead of 2 14:52:29 <Jupix> that's the only difference 14:52:35 <planetmaker> Jupix, yes. And then it breaks, if one switches blitter. BIG difference 14:53:02 <Jupix> why would you enable the 32 bit blitter if you have a 8 bit display, and why'd you program it to break? 14:53:42 <planetmaker> why wouldn't I want the possibility to chose either or - and why would I get an unusable OpenTTD, if I change to 8bpp when I used 32bpp before? 14:53:56 <planetmaker> meh... I guess this discussion is not worthwhile 14:55:07 <Jupix> how would the switch from 32 to 8 be any different from the one from 8 to 32 :| 14:55:16 <planetmaker> at least I cannot break OpenTTD easily right now by changing the config 14:55:27 <Jupix> I just don't see the breakage 14:55:29 <planetmaker> Jupix, both, blitter and base set are different settings 14:55:38 <planetmaker> I play 32bpp with your 32bpp only-base set. 14:55:56 <planetmaker> Then I change the blitter to 8bpp - and voila, OpenTTD is unusable if I didn't manually also switch the base set 14:56:04 <planetmaker> something I currently do comfortably ingame 14:56:24 <Jupix> make the feature, you know, not stupid? 14:56:41 <Jupix> it doesn't have to be that robust 14:56:45 <planetmaker> *sigh* 14:56:55 <planetmaker> if it doesn't need to be robust it doesn't have to be 14:57:24 <Jupix> besides, zephyris suggested a solution that would solve that 14:57:43 <Jupix> in essence, you'd generate 8 bit sprites on the fly 14:57:57 <Jupix> read his post 14:58:10 <frosch123> maybe we should link agains imagemagick and also scale the graphics on the fly 14:58:32 <Jupix> maybe not 14:58:47 <frosch123> we could also link against some pythonlib and read nml directly 14:59:24 <frosch123> we could also link some artificial intelligence which draws the graphics in the first place, or better, code ottd inself 14:59:59 <frosch123> Jupix: in other words, ottd does not need to include stuff, which are not needed by the average player, but can be done with an external toolo 15:01:04 <Jupix> do you consider 32bpp-ez "not needed by the average player"? 15:01:48 <frosch123> no, but i consider generting 8bpp on the fly in ottd sub omni canone stupid if you can do the same with an external tool and add it to the baseset 15:02:19 <frosch123> oh, i missed the "-ez" part 15:02:34 <frosch123> i am not interested in "-ez" at all 15:03:11 <frosch123> everything with > 2x zoom is unplayable 15:03:34 <Jupix> out of curiosity, have you played on a 30" tft screen? 15:04:03 <Ammler> frosch123: I sometimes use the zoom function of my WM 15:04:05 <Jupix> because in my experience anything *out* of -EZ is unplayable 15:04:43 <Jupix> anyway, what I also wanted to know is, do you also think that ottd should contain those features that you want, and those only? 15:04:52 <Jupix> because that's how you come across to me 15:05:13 <frosch123> Jupix: i will only spent work on stuff which am interested in 15:05:29 <Jupix> then don't work on it, instead of slamming it on IRC 15:05:32 <Ammler> Jupix: that is how opensouce works mostly 15:06:59 * andythenorth draws some pixels 15:07:01 *** egladil [~egladil@s83-191-244-232.cust.tele2.se] has joined #openttd 15:07:01 * Jupix loves patronising 15:09:24 <frosch123> Jupix: and i will also *vote* against stuff which breaks stuff i am intested in, or which is done *technically* wrong in my opinion. if that leads to unresolvable conflicts, the minority has to split off 15:10:35 *** Mazur [~mazur@53551A99.cable.casema.nl] has quit [Ping timeout: 480 seconds] 15:10:36 *** [com]buster [~eternal@cust-03-55bf402e.adsl.scarlet.nl] has joined #openttd 15:10:37 <frosch123> and usually i comments on *technically* wrong stuff as early as i notice 15:10:50 <frosch123> if that feedback is not welcome, i do not care 15:11:09 <Jupix> saying "do it my way or GTFO" isn't going to convince me to change my mind 15:11:46 *** mucht_home [~Martin@chello084115143107.3.graz.surfer.at] has quit [Remote host closed the connection] 15:12:20 <frosch123> also fine, but don't complain about that 15:12:36 <Jupix> what you need to understand is that I don't care about the technical stuff, blitters, GRFs, spriteloading or whatever, but I do care when people close to me say they'd like to try ottd-32bit but it's too confusing 15:12:52 <Jupix> I'm trying to solve that, not push a technical solution 15:12:59 *** NukeBuster [~wouter@80.101.115.82] has joined #openttd 15:13:13 *** mucht_home [~Martin@chello084115143107.3.graz.surfer.at] has joined #openttd 15:13:15 <frosch123> as i said before. there are two parties. those who are interested in it, and do not know how it works. and those who know how it works, but are not interested 15:13:22 <frosch123> i have no idea, how to solve that 15:14:11 <Jupix> I think there are a lot of people who have said before that if you generalise, you're always wrong :) 15:14:42 <frosch123> :p 15:14:57 <Mitch_1_2> Is it possible to resize a station? 15:15:31 <frosch123> Mitch_1_2: you can build additional tiles directly adjacent, resp. while holding ctrl also non-adjacent 15:15:46 <frosch123> and you can remove single tiles by selecting the "bulldozer" 15:21:07 *** Mazur [~mazur@53551A99.cable.casema.nl] has joined #openttd 15:22:08 * Rubidium wonders how well a "simple" downscale from over 16 million colours to less than 200 colours actually works 15:23:30 <frosch123> that depends on how colourful the image is 15:23:39 <frosch123> a colourramp will look awful 15:24:07 <frosch123> for a photo you will hardly notice if it applied to all images nearby 15:24:55 <frosch123> alpha channel is likely also very troublesome 15:26:57 <frosch123> otoh, artists would notice it in any case, just like musicians can hear whether their audio plugs are made of gold or not 15:27:27 <OwenS> frosch123: Blind trials have demonstrated they can't :p 15:27:50 <Rubidium> blind trials on 32bpp vs 8bpp graphics? :) 15:29:16 <Mitch_1_2> Hmm. Stupid station not accepting passengers. 15:29:21 <frosch123> double-blind-experiments are said to be very trustworhty 15:30:26 <OwenS> Rubidium: On gold vs nickel connectors :p 15:30:35 <andythenorth> Eddi|zuHause: any opinion on new FIRS aluminium plant graphics? 15:30:49 <Eddi|zuHause> haven't checked yet... 15:31:12 <OwenS> On the other hand, they can tell the difference between audio *cables*. And the best are the solid core copper used for mains wiring :p 15:31:58 *** Plimmer [~Plimmer@0x573ef885.lmvnqu1.dynamic.dsl.tele.dk] has joined #openttd 15:32:38 <Mitch_1_2> frosch123: Any idea why a train station wouldn't accept passengers? 15:33:12 <Sacro> it's closed? 15:34:11 <Plimmer> Hi, me and 2 friends are playind Openttd with alot of ECS vectors enabled on a reasonably hard setting. Our problem is that alot of the industries close down along time before we have the resources to build a decent network to actually transport alot of theese industries. Is there some setting that will allow me to extend the closure of theese industries? 15:34:57 <andythenorth> industry closure strikes again :P 15:35:31 <Plimmer> Heh, yeah. Kinda sucks to have to fund all you want to drive with. :) 15:42:14 <frosch123> Mitch_1_2: use the land are information tool on the very right of the menubar to discover which tiles accept what cargo 15:42:34 <Mitch_1_2> frosch123: Thanks. You're full of answers. :) 15:42:46 * Mitch_1_2 tries to find out himself. Honest. 15:47:33 *** glx_ is now known as glx 15:50:22 *** pugi_ [~pugi@p4FCC4135.dip.t-dialin.net] has joined #openttd 15:50:22 *** pugi [~pugi@p4FCC4135.dip.t-dialin.net] has quit [Read error: Connection reset by peer] 15:50:24 *** pugi_ is now known as pugi 15:50:27 <Eddi|zuHause> Plimmer: no, that is currently an unsolved problem 15:50:39 *** Chris_Booth [~chatzilla@cpc7-newt30-2-0-cust443.newt.cable.virginmedia.com] has joined #openttd 15:51:15 <andythenorth> I think there might be an ECS parameter to disable closure? 15:51:34 <Eddi|zuHause> andythenorth: only closure of serviced industries, not of unserviced industries 15:52:00 <Eddi|zuHause> oh, mine closure in all cases separately, which might help 15:52:43 <Eddi|zuHause> Plimmer: i generally set the "general behaviour" parameter to "12", not sure if that helps you... 15:59:57 *** tokai [~tokai@port-92-195-123-66.dynamic.qsc.de] has quit [Ping timeout: 480 seconds] 16:02:11 *** tokai [~tokai@port-92-195-31-86.dynamic.qsc.de] has joined #openttd 16:02:14 *** mode/#openttd [+v tokai] by ChanServ 16:02:14 *** Eddi|zuHause2 [~johekr@p54B7670D.dip.t-dialin.net] has joined #openttd 16:06:07 *** Eddi|zuHause [~johekr@p54B744A2.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 16:14:25 <asilv> grfcrawler has "Can't connect to TT-Forums Database" error again, who should I complain to? 16:14:52 <Ammler> to #tycoon 16:15:45 <SpComb> asilv: orudge and eis-os 16:15:52 <asilv> do they actually ever talk ttd related stuff at #tycoon 16:16:11 <SpComb> no 16:16:14 <Ammler> :-) 16:16:15 <orudge> occasionally 16:16:21 <frosch123> last time i got that error it worked nevertheless 16:16:43 <SpComb> it uses tt-forums usernames for logins 16:17:03 <frosch123> oh, ok, i did not had to login 16:18:05 <orudge> should be fixed again now 16:18:21 <asilv> works now thanks, orudge! 16:19:28 *** Eddi|zuHause2 is now known as Eddi|zuHause 16:26:52 * frosch123 pondered buying a ottd shirt for the party, but they are just too ugly :s 16:27:01 <welshdragon> ARGH 16:27:05 <welshdragon> OFF TOPIC!!! 16:28:54 *** DorpsGek changed the topic of #openttd to: 1.0.1, 1.0.2-RC1 16:29:03 <glx> arg fail 16:30:37 <glx> @op 16:30:40 *** mode/#openttd [+o glx] by DorpsGek 16:30:57 *** glx changed the topic of #openttd to: 1.0.1 | Website: *.openttd.org (translator: translator, server list: servers, wiki: wiki, patches & bug-reports: bugs, revision log: vcs, release info: finger) | UTF-8 please | No Unauthorised Bots | Continental breakfast only | Don't ask to ask, just ask 16:31:05 *** Lachie [whitey@creep.bur.st] has quit [Remote host closed the connection] 16:31:14 *** DorpsGek changed the topic of #openttd to: 1.0.1, 1.0.2-RC1 | Website: *.openttd.org (translator: translator, server list: servers, wiki: wiki, patches & bug-reports: bugs, revision log: vcs, release info: finger) | UTF-8 please | No Unauthorised Bots | Continental breakfast only | Don't ask to ask, just ask 16:31:24 <frosch123> \o/ 16:31:52 <glx> I forgot an arg in the command ;) 16:31:53 *** Lachie [whitey@creep.bur.st] has joined #openttd 16:32:20 <Sacro> mmm 16:32:25 <Sacro> continental breakfast sounds nice 16:32:53 *** mode/#openttd [-o glx] by DorpsGek 16:57:29 <PeterT> glx: lol :-) 17:17:47 *** bryjen [~bryjen@75.81.201.131] has joined #openttd 17:27:24 *** woldemar [~maru@213.178.34.57] has joined #openttd 17:31:10 *** DJNekkid [~DJ___Nekk@static128-249.mimer.net] has quit [Remote host closed the connection] 17:32:16 *** Mazur [~mazur@53551A99.cable.casema.nl] has quit [Ping timeout: 480 seconds] 17:38:44 *** Mazur [~mazur@53551A99.cable.casema.nl] has joined #openttd 17:45:32 <CIA-2> OpenTTD: translators * r19940 /trunk/src/lang/unfinished/ (maltese.txt urdu.txt): 17:45:32 <CIA-2> OpenTTD: -Update from WebTranslator v3.0: 17:45:32 <CIA-2> OpenTTD: maltese - 2 changes by kelinu 17:45:32 <CIA-2> OpenTTD: urdu - 1 changes by zohair 17:57:29 *** Eoin_ [eoin@cpc1-dund8-0-0-cust3.sgyl.cable.virginmedia.com] has joined #openttd 17:57:30 *** Eoin [eoin@cpc1-dund8-0-0-cust3.sgyl.cable.virginmedia.com] has quit [Read error: Connection reset by peer] 18:09:24 *** Eoin [eoin@cpc1-dund8-0-0-cust3.sgyl.cable.virginmedia.com] has joined #openttd 18:10:15 *** Eoin_ [eoin@cpc1-dund8-0-0-cust3.sgyl.cable.virginmedia.com] has quit [Read error: Connection reset by peer] 18:14:54 *** Kurimus [Kurimus@dsl-tkubrasgw1-fe32dc00-253.dhcp.inet.fi] has quit [] 18:19:14 *** bryjen [~bryjen@75.81.201.131] has quit [Quit: Leaving] 18:19:36 *** devilsadvocate [~devilsadv@202.3.77.202] has joined #openttd 18:37:23 *** fonsinchen [~fonsinche@brln-4dba9c37.pool.mediaWays.net] has quit [Ping timeout: 480 seconds] 18:39:20 *** Lakie [~Lakie@91.84.251.149] has joined #openttd 18:39:41 *** Wintersoldier [~davidclam@c-24-5-19-146.hsd1.ca.comcast.net] has joined #openttd 18:39:49 *** NukeBuster [~wouter@80.101.115.82] has quit [Read error: Connection reset by peer] 18:40:04 *** Wintersoldier [~davidclam@c-24-5-19-146.hsd1.ca.comcast.net] has left #openttd [] 18:59:40 <__ln__> how much money do i save by purchasing train tickets e.g. one day in advance? (if any) 19:03:12 <frosch123> in germany? iirc you can save 25% if you decide three days in advance for a specific train (you then should not miss) 19:05:27 <__ln__> does that apply to RE and IR and such too? 19:05:57 <frosch123> no, that is ice only (maybe ic) 19:06:33 <__ln__> ok, thanks 19:06:34 <frosch123> for re there are other tickets for a weekend or a state 19:06:47 <frosch123> and i guess IR does not exist anymore 19:07:01 <__ln__> yeah, i've even used lÀndertickets a couple of times. 19:08:53 <frosch123> oh, maybe you can even save 50% on ice on weekends 19:09:06 <frosch123> (but still for a specific train only) 19:09:41 <Rubidium> isn't/wasn't there some really cheap ticket which only lets you go in regional trains? 19:10:03 <planetmaker> yes. The "schöne Wochenende"-tickets 19:10:15 <planetmaker> but they're meanwhile only valide one day, not both :-( 19:10:23 <planetmaker> and cost like 25 or 30⬠19:10:32 <planetmaker> Not worthwhile for __ln__ from Hanover to BS 19:10:43 <planetmaker> that's only ~10⬠one-way 19:10:47 <planetmaker> in an RE 19:11:00 <Rubidium> they seem to be 37 euros 19:11:05 <Rubidium> http://www.bahn.de/p/view/angebot/regio/schoenes_wochenende_ticket.shtml 19:11:11 <planetmaker> even more expensive 19:11:21 <planetmaker> and then you share the train with a lot of drunken scum 19:11:38 <__ln__> yeah, and within the borders of niedersachsen-ticket anyway (~20â¬) 19:12:43 <Rubidium> oh, that ticket is for up to 5 persons 19:13:11 <planetmaker> yes :-) 19:13:18 <planetmaker> that's the pro, if you go in a group 19:13:21 <__ln__> for 5 persons it's ridiculously cheap 19:14:32 <__ln__> i'm more considering what to do after BS... go more or less directly to berlin, or explore some eastern city first. 19:21:39 <__ln__> (what a conversation killer) 19:23:54 <frosch123> when do you fly back? 19:24:14 <__ln__> tuesday 22nd 19:24:31 <frosch123> oh, so two days for other stuff 19:25:56 <planetmaker> __ln__: Berlin is in the East ;-) 19:26:13 <planetmaker> __ln__: when do you arrive? 19:26:27 <Rubidium> planetmaker: it's all west of Finland 19:26:49 <planetmaker> Rubidium: also East. Just more distant ;-) 19:27:11 <__ln__> friday 18th to hannover (unless a volcano blows up or something) 19:27:25 <planetmaker> you come over already on 18th? 19:27:38 <planetmaker> you're free to do so, if you like 19:28:12 <__ln__> no, i booked a cheap ho(s)tel thing in hannover for one night. 19:28:30 <planetmaker> ok 19:29:20 <__ln__> and a cheap hotel thing in BS for the next.. (sleeping bag accommodation would be ok as such, but i ain't carrying one halfway through europe :) ) 19:29:45 <planetmaker> whoot, you booked one here, too? 19:30:01 <planetmaker> but well, ok :-) 19:30:14 <planetmaker> which is it? 19:30:33 <__ln__> "Hotel am Park" 19:31:07 <planetmaker> ok, I don't know it. The location looks quite ok, though 19:31:24 <planetmaker> about where one of the bigger public viewing sites is located :-P 19:31:50 <planetmaker> *somewhere* in the BÃŒrgerpark 19:34:53 *** pugi [~pugi@p4FCC4135.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 19:35:02 <planetmaker> __ln__: what kind of touristic activities are you into? 19:36:02 <__ln__> walking around and photographing interesting things... :) 19:36:32 <planetmaker> if you feel like I can give on Sunday a free tour through town 19:37:03 <__ln__> that could be nice 19:37:06 <planetmaker> what's 'interesting' in your eyes, though? 19:37:18 *** pugi [~pugi@p4FCC6174.dip.t-dialin.net] has joined #openttd 19:37:39 <planetmaker> like history? Like architecture? arts? 19:37:48 <planetmaker> landscape? 19:38:27 <__ln__> buildings, trams, nice views, ... 19:39:59 <planetmaker> hm... So should I look whether there's on Sunday a ride through town in one of the historic trams ;-) 19:40:50 <__ln__> why not :) 19:55:39 *** |Jeroen| [~jeroen@94-224-31-113.access.telenet.be] has quit [Quit: oO] 20:02:10 <frosch123> night 20:02:14 *** frosch123 [~frosch@frnk-590f5bc3.pool.mediaWays.net] has quit [Remote host closed the connection] 20:16:38 *** asilv [~as@dsl-lprbrasgw1-ff1ec100-158.dhcp.inet.fi] has quit [] 20:21:41 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has joined #openttd 20:22:36 *** bryjen [~bryjen@75.81.201.131] has joined #openttd 20:35:13 *** HerzogDeXtEr1 [~Administr@89.246.162.73] has joined #openttd 20:41:45 *** HerzogDeXtEr [~Administr@89.246.189.43] has quit [Ping timeout: 480 seconds] 20:42:51 *** fjb [~frank@p5485D543.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 20:46:59 *** fjb [~frank@p5485D543.dip.t-dialin.net] has joined #openttd 21:02:03 *** fjb [~frank@p5485D543.dip.t-dialin.net] has quit [Read error: Connection reset by peer] 21:05:00 *** heffer [~felix@static-87-78-98-150.netcologne.de] has quit [Quit: heffer] 21:06:18 *** Polygon [~Poly@x0581b.wh7.tu-dresden.de] has joined #openttd 21:14:24 *** fonsinchen [~fonsinche@brln-4dba9c37.pool.mediaWays.net] has joined #openttd 21:30:38 *** theholyduck [~holyduck@77.106.154.107] has joined #openttd 21:44:22 *** theholyduck [~holyduck@77.106.154.107] has quit [Read error: Connection reset by peer] 21:49:32 *** KouDy [~KouDy@rb5ck203.net.upc.cz] has quit [Ping timeout: 480 seconds] 21:54:23 *** Polygon [~Poly@x0581b.wh7.tu-dresden.de] has quit [Remote host closed the connection] 21:55:14 <Eddi|zuHause> "Due to numerous complaints about the domain name" <- who would do that? :p 22:02:32 <FauxFaux> closedttd.com 22:03:34 <Eddi|zuHause> no, that's not the website in question ;) 22:15:54 *** wollollo [~martin@host109-152-199-30.range109-152.btcentralplus.com] has joined #openttd 22:17:47 *** theholyduck [~holyduck@77.106.154.107] has joined #openttd 22:18:46 *** yohann [~yohann@78.116.109.170] has joined #openttd 22:19:42 *** yohann [~yohann@78.116.109.170] has quit [Remote host closed the connection] 22:20:25 *** yohann [~yohann@78.116.109.170] has joined #openttd 22:20:41 *** wollollo [~martin@host109-152-199-30.range109-152.btcentralplus.com] has quit [] 22:20:55 *** wollollo [~martin@host109-152-199-30.range109-152.btcentralplus.com] has joined #openttd 22:22:52 <Rubidium> Eddi|zuHause: google doesn't know any website with that 22:23:34 <Eddi|zuHause> http://www.tt-forums.net/viewtopic.php?f=33&t=41992&p=881770#p881770 22:24:20 <Rubidium> lol 22:26:04 *** Chruker [~no@port113.ds1-vj.adsl.cybercity.dk] has quit [] 22:27:00 *** yohann [~yohann@78.116.109.170] has left #openttd [Leaving] 22:28:13 <Rubidium> Wizzleby: the 320797 sounds like a broken grfcodec 22:29:15 *** Fast2 [~Fast2@p57AF8166.dip0.t-ipconnect.de] has quit [Quit: <Nachricht>] 22:29:43 <Rubidium> I seem to remember the same problem occuring under SLES 12 or something 22:31:03 <Rubidium> Wizzleby: http://www.tt-forums.net/viewtopic.php?p=865695#p865695 22:31:58 *** [com]buster [~eternal@cust-03-55bf402e.adsl.scarlet.nl] has quit [Remote host closed the connection] 22:32:30 *** tokai [~tokai@port-92-195-31-86.dynamic.qsc.de] has quit [Ping timeout: 480 seconds] 22:34:27 *** tokai [~tokai@port-92-195-41-167.dynamic.qsc.de] has joined #openttd 22:34:30 *** mode/#openttd [+v tokai] by ChanServ 22:36:28 *** devilsadvocate [~devilsadv@202.3.77.202] has quit [Quit: Leaving] 22:36:34 *** devilsadvocate [~devilsadv@202.3.77.202] has joined #openttd 22:36:54 *** wollollo [~martin@host109-152-199-30.range109-152.btcentralplus.com] has quit [Quit: leaving] 22:40:33 *** jpm_ [~pekka@kone.suomen4g.fi] has joined #openttd 22:40:33 *** jpm [~pekka@kone.suomen4g.fi] has quit [Read error: Connection reset by peer] 22:40:52 *** bryjen [~bryjen@75.81.201.131] has quit [Quit: Leaving] 22:40:59 *** PeterT is now known as PeterT-ghost 22:41:21 *** PeterT-ghost is now known as PeterT 22:41:54 *** pugi [~pugi@p4FCC6174.dip.t-dialin.net] has quit [Quit: ALL YOUR BASE ARE BELONG TO US!] 22:51:48 <Wizzleby> Rubidium: thanks 22:53:30 *** Chillosophy [~fu@195-241-120-76.ip.telfort.nl] has quit [] 22:55:04 <Wizzleby> Rubidium: the thing that baffles me about it at the moment, is that so far, some have been unable to replicate it 22:55:48 *** fonsinchen [~fonsinche@brln-4dba9c37.pool.mediaWays.net] has quit [Ping timeout: 480 seconds] 22:55:53 <Rubidium> different gcc/libc? 22:56:22 <PeterT> the "graph" at the new site at github is nice, Eddi|zuHause 22:56:48 <Eddi|zuHause> why tell me? 22:57:53 <Wizzleby> Rubidium: well, both of us who have encountered it were using gcc-4.5.0, I'm preparing to test with 4.4.3 22:58:08 <Rubidium> Wizzleby: do you use glibc 2.11? 22:58:37 <PeterT> sorry, Eddi|zuHause, just cause you mentioned the link 22:58:39 *** Progman [~progman@p57A1D33E.dip.t-dialin.net] has quit [Remote host closed the connection] 22:58:42 <PeterT> I was looking at my buffer 22:58:47 <PeterT> never mind then :) 22:58:53 <Wizzleby> Rubidium: 2.11.1 23:00:50 <Rubidium> in any case, the test is correct as it caught that something is broken 23:02:42 *** ^Spike^ [~spike@d200003.upc-d.chello.nl] has quit [Ping timeout: 480 seconds] 23:04:43 <Rubidium> okay, seems to be gcc 4.5 23:06:03 <Rubidium> and gcc trunk of yesterday-ish has the problem too 23:06:23 <Wizzleby> I'm unsurprised, when I first made a grfcodec ebuild, it was lacking a patch (now applied upstream) to work with gcc-4.4 23:07:43 *** tokai [~tokai@port-92-195-41-167.dynamic.qsc.de] has quit [Ping timeout: 480 seconds] 23:09:06 <Rubidium> compiling with -O0 "solves" the problem 23:09:42 <Wizzleby> Ahh.. I was wondering if the gcc-4.5.0 optimization scheme was doing it 23:09:44 <Rubidium> what and how goes wrong I don't know though 23:09:58 *** tokai [~tokai@port-92-195-90-3.dynamic.qsc.de] has joined #openttd 23:10:00 *** mode/#openttd [+v tokai] by ChanServ 23:10:22 <Wizzleby> Well, its a combination of fairly old code (as I understand it), and a fairly new set of modifications to the compiler's optimization scheme 23:11:14 <Rubidium> old (valid) code shouldn't just stop working 23:11:39 <Wizzleby> Rubidium: I agree, however this is not the first example of that happening that I've seen with gcc-4.5.0 :/ 23:14:45 <Rubidium> so now the question is whether it's invalid code or invalid optimisation 23:17:26 <Rubidium> though there is an disturbing number of valgrind warnings on grfcodec 23:17:52 <Rubidium> even on my already patched for valgrind warnings binary 23:18:02 * Wizzleby nods 23:18:28 <Wizzleby> Pending the reason being worked out, this does at least gives me a better option than restricting tests in opengfx 23:19:42 *** Devedse [~Devedse@cable-213-34-232-56.zeelandnet.nl] has joined #openttd 23:19:45 <Rubidium> although there seem to be less warnings if compiled with -O0 23:20:02 <Rubidium> (valgrind warnings that is) 23:20:33 <Rubidium> problem is that grfcodec is a bit in limbo because the developer doesn't seem to be working on it and patches aren't applied 23:20:41 *** Fuco [~dota.keys@fuco.sks3.muni.cz] has quit [Quit: Quit] 23:21:01 <Rubidium> -O0 makes grfcodec considerably slower though 23:21:44 <Rubidium> Ammler: this discussion might help you with the grfcodec on opensuse factory problem 23:21:57 <Wizzleby> Well, I think I can use the toolchain-funcs eclass to only use -O0 if the user is using gcc 4.5 23:22:46 <Wizzleby> Rubidium: it may explain issues with Arch Linux users too (if/when those pop up), last I heard from a friend, they're using gcc-4.5.0 too 23:23:45 <Wizzleby> 4.5.0 is still hardmasked in Gentoo, so at least that also alleviates my concern about the test failure becoming widespread since the stabilization of grfcodec 23:28:05 *** Fuco [~dota.keys@fuco.sks3.muni.cz] has joined #openttd 23:30:31 *** Devedse [~Devedse@cable-213-34-232-56.zeelandnet.nl] has quit [Quit: Ik ga weg] 23:41:43 <Wizzleby> well it certainly is slower with -O0, but it works, and passes tests even under gcc-4.5.0