Times are UTC Toggle Colours
00:04:19 *** lugo [~lugo@mgdb-4db8c132.pool.mediaWays.net] has joined #openttd 00:04:51 *** llugo [~lugo@mgdb-4db8d681.pool.mediaWays.net] has quit [Ping timeout: 480 seconds] 00:09:11 *** KenjiE20 [~KenjiE20@92.19.165.204] has quit [Quit: WeeChat 0.3.3] 00:10:51 *** lllugo [~lugo@mgdb-4db8c8f9.pool.mediaWays.net] has quit [Ping timeout: 480 seconds] 00:23:28 *** Devroush [~dennis@94-225-67-91.access.telenet.be] has quit [] 00:27:28 <TruePikachu> FS#4079 00:27:49 <TruePikachu> ^^ that has the new files 00:30:01 <TruePikachu> I'm not sure if I got the category correct, though 00:37:43 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has quit [Quit: TschÃŒÃ] 00:42:00 *** avdg [~Adium@94-227-100-192.access.telenet.be] has quit [Read error: Connection reset by peer] 00:42:08 *** avdg [~Adium@94-227-100-192.access.telenet.be] has joined #openttd 00:44:47 *** avdg [~Adium@94-227-100-192.access.telenet.be] has quit [Read error: Connection reset by peer] 00:45:10 *** avdg [~Adium@94-227-100-192.access.telenet.be] has joined #openttd 00:50:17 *** lugo [~lugo@mgdb-4db8c132.pool.mediaWays.net] has quit [Quit: Leaving] 00:53:49 *** Westie [~westie@starfish.typefish.co.uk] has quit [Ping timeout: 480 seconds] 01:02:23 *** Fast2 [~Fast2@p57AF8A32.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 01:07:43 *** avdg [~Adium@94-227-100-192.access.telenet.be] has quit [Read error: Connection reset by peer] 01:07:56 *** avdg [~Adium@94-227-100-192.access.telenet.be] has joined #openttd 01:09:59 *** Westie [~westie@starfish.typefish.co.uk] has joined #openttd 01:13:36 <TruePikachu> Oh, so your server keeps kicking you? 01:20:23 *** TruePika1hu [~chris@cpe-67-49-42-88.socal.res.rr.com] has joined #openttd 01:21:25 *** TruePika1hu is now known as TruePika 01:21:37 * TruePika was not aware of connection loss 01:22:13 <ccfreak2k> Connection gain, connection loss. 01:22:34 * TruePika is wating for TruePikachu to ping timeout 01:22:38 *** zodttd2 [~me@24.144.92.44] has joined #openttd 01:22:57 <TruePika> No, I wasn't aware that my connection dropped 01:22:59 *** TruePikachu [~chris@cpe-67-49-42-88.socal.res.rr.com] has quit [Ping timeout: 480 seconds] 01:23:05 *** TruePika is now known as TruePikachu 01:29:09 *** zodttd [~me@user-0c90n1c.cable.mindspring.com] has quit [Ping timeout: 480 seconds] 01:32:32 *** Westie [~westie@starfish.typefish.co.uk] has quit [Read error: Operation timed out] 01:35:13 <TruePikachu> How much more processor-intensive is 32bpp verses 8bpp? 01:36:53 <ccfreak2k> Connection lost. 01:36:55 <ccfreak2k> Connection found. 01:37:05 *** perk11 [~perk11@94.233.249.111] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] 01:37:13 <ccfreak2k> TruePikachu, it was actually faster when I used the opengl blitter. 01:37:14 <ccfreak2k> B) 01:40:20 <TruePikachu> ? 01:40:54 <TruePikachu> nvm for right now, gtg 01:41:14 *** DDR [~DDR@66.183.112.102] has quit [Ping timeout: 480 seconds] 01:44:38 *** Yexo [~Yexo@77-88-ftth.onsneteindhoven.nl] has quit [Ping timeout: 480 seconds] 01:44:57 *** avdg [~Adium@94-227-100-192.access.telenet.be] has quit [Quit: Leaving.] 01:46:28 *** Fuco [~dota.keys@188.123.106.105] has quit [Ping timeout: 480 seconds] 01:48:49 *** Yexo [~Yexo@153-88-ftth.onsneteindhoven.nl] has joined #openttd 02:26:11 *** rhaeder1 [~quix0r@dslb-094-221-133-047.pools.arcor-ip.net] has joined #openttd 02:30:30 *** rhaeder [~quix0r@188.109.242.232] has quit [Ping timeout: 480 seconds] 02:56:47 *** glx [glx@2a01:e35:2f59:c7c0:754a:30b:df97:57ec] has quit [Quit: bye] 02:57:05 <TruePikachu> back 03:01:24 *** tokai [~tokai@port-92-195-98-91.dynamic.qsc.de] has quit [Ping timeout: 480 seconds] 03:03:26 *** tokai [~tokai@port-92-195-232-58.dynamic.qsc.de] has joined #openttd 03:03:29 *** mode/#openttd [+v tokai] by ChanServ 03:22:54 *** tokai [~tokai@port-92-195-232-58.dynamic.qsc.de] has quit [Ping timeout: 480 seconds] 03:25:05 *** tokai [~tokai@port-92-195-192-62.dynamic.qsc.de] has joined #openttd 03:25:08 *** mode/#openttd [+v tokai] by ChanServ 03:47:07 *** fmauneko [~fmauneko@88.166.241.226] has joined #openttd 03:50:42 *** Xrufuian [~Xrufuian@pool-98-119-100-207.lsanca.btas.verizon.net] has joined #openttd 04:11:17 *** Westie [~westie@starfish.typefish.co.uk] has joined #openttd 04:11:54 *** tokai [~tokai@port-92-195-192-62.dynamic.qsc.de] has quit [Ping timeout: 480 seconds] 04:14:07 *** tokai [~tokai@port-92-195-199-89.dynamic.qsc.de] has joined #openttd 04:14:10 *** mode/#openttd [+v tokai] by ChanServ 04:21:15 *** KouDy [~KouDy@ip-89-176-216-203.net.upcbroadband.cz] has joined #openttd 04:21:36 *** rtypo [rtypo@pc54.clicknet.iasi.rdsnet.ro] has joined #openttd 04:35:18 *** KouDy [~KouDy@ip-89-176-216-203.net.upcbroadband.cz] has quit [Ping timeout: 480 seconds] 04:43:20 *** a1270 [~a1270@72-24-233-98.cpe.cableone.net] has joined #openttd 04:56:02 *** Eddi|zuHause [~johekr@p54B761FE.dip.t-dialin.net] has quit [Remote host closed the connection] 04:56:24 *** Eddi|zuHause [~johekr@p54B761E0.dip.t-dialin.net] has joined #openttd 04:58:48 *** fmauneko [~fmauneko@88.166.241.226] has quit [Quit: fmauneko] 05:02:39 *** fmauneko [~fmauneko@88.166.241.226] has joined #openttd 05:48:25 *** Xrufuian [~Xrufuian@pool-98-119-100-207.lsanca.btas.verizon.net] has quit [Quit: zzz....] 06:01:04 *** fmauneko [~fmauneko@88.166.241.226] has quit [Quit: fmauneko] 06:09:39 *** Kurimus [Kurimus@dsl-tkubrasgw1-fe34dc00-202.dhcp.inet.fi] has joined #openttd 06:32:45 <Terkhen> good morning 06:33:23 <planetmaker> good morning 06:34:09 *** zodttd2 [~me@24.144.92.44] has quit [Ping timeout: 480 seconds] 06:35:19 *** TomyLobo [~foo@port-212-202-171-176.dynamic.qsc.de] has joined #openttd 06:37:17 *** Goulpy is now known as Muxy 06:38:17 *** ^Spike^ [~spike@d200003.upc-d.chello.nl] has joined #openttd 06:41:27 <Eddi|zuHause> new sports: "Duke Nukem Mikado" - "who releases first, looses" 06:41:37 <Eddi|zuHause> s/oo/o/ 06:42:21 <planetmaker> :-D 06:42:41 <planetmaker> George isn't that bad :-) 06:42:59 <planetmaker> And George clearly said that he stops LV5 until <something I forgot> 06:43:08 <planetmaker> Some FS entry he would like to see resolved 06:44:08 <Eddi|zuHause> yeah, improved curvature information 06:44:30 <Eddi|zuHause> i implemented that, but it wasn't included in trunk, afair... 06:44:35 <planetmaker> yeah, sounds like one of the things he likes 06:45:30 <Eddi|zuHause> fs#2521 it might be 06:48:29 <planetmaker> yes, I think 06:49:20 <planetmaker> and he's somewhat right: without anything new to add technically there's no point to up the version from LV4 to LV5. 06:49:35 <planetmaker> Might of course be that there are meanwhile other things which could be done 06:50:19 <Eddi|zuHause> well... the patch is there, it's just untested... 06:50:54 *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has joined #openttd 06:52:40 <Eddi|zuHause> "Systemmanager Server (m./w.) - Schwerpunkt Unix" <-- anyone think i should apply for such a job? 06:56:05 <planetmaker> If you like it and the company, its work-style and if the payment is ok 06:58:49 <Eddi|zuHause> i'm more a person of the theory, but i don't want to stay at the university, and it's difficult to find a job that matches that, if you also want to stay in the region... 07:04:02 <planetmaker> he. That's two limitations :-) 07:04:11 *** devilsadvocate [~devilsadv@202.3.77.41] has quit [Remote host closed the connection] 07:04:13 <planetmaker> That makes it more difficult indeed 07:08:11 <dihedral> good morning 07:08:14 *** keoz [~keikoz@pha75-8-82-230-2-115.fbx.proxad.net] has joined #openttd 07:08:20 <dihedral> looks like you had an interesting night :-P 07:08:51 *** devilsadvocate [~devilsadv@202.3.77.41] has joined #openttd 07:13:25 <Eddi|zuHause> http://www.heise.de/newsticker/meldung/iPod-vs-eiPOTT-Urteilsbegruendung-veroeffentlicht-1064220.html 07:15:06 <planetmaker> lol 07:16:12 *** JVassie [~James@92.27.149.231] has joined #openttd 07:16:26 *** DDR [~DDR@66.183.112.102] has joined #openttd 07:16:30 <Eddi|zuHause> "Apple hat die Wortmarke IPOD offenbar nicht nur fÃŒr MP3-Spieler und verwandte GerÀtschaften angemeldet, sondern unter anderem auch fÃŒr "GerÀte und BehÀlter fÃŒr Haushalt und KÃŒche"." 07:16:55 <dihedral> :-D 07:16:56 <planetmaker> That's indeed the most interesting sentence there and leaves one wondering 07:17:12 <dihedral> the company is allowed to name any other product "eiPOTT", just not that one :-P 07:17:47 <dihedral> i saw one here, and was wondering if i should buy one before they get banned :-P 07:19:13 <planetmaker> I definitely would 07:19:53 <dihedral> yeah, but not for 8 eur 07:20:13 <dihedral> it's an egg cup in the shape of an ipod :-P 07:21:04 <Eddi|zuHause> it's clearly one of the prime examples how patents "help" innovation 07:24:25 <planetmaker> dihedral: they make awesome presents 07:24:37 <planetmaker> like "Darling, I brought you a brand new eipott" ;-) 07:25:06 <dihedral> i think i'd only do that once with my darling :-P 07:25:12 <planetmaker> why? 07:25:25 <planetmaker> personally I'd laugh my head of 07:25:27 <planetmaker> *off 07:25:40 <planetmaker> both, giving it away and receiving it 07:25:42 <dihedral> well - if it were a birthday present :-P 07:25:51 <dihedral> hehe 07:26:02 <planetmaker> of course it doesn't work, if an iPod was asked for. But... 07:26:03 <dihedral> na, she'd laugh ^^ 07:26:15 <Eddi|zuHause> they'd be a cool "Prasselgeschenk" 07:26:22 <planetmaker> also :-) 07:26:26 <dihedral> jeah - junk-wichteln 07:27:07 <planetmaker> auch genannt "Schrottwichteln" ;-) 07:32:16 *** DDR_ [~DDR@66.183.112.102] has joined #openttd 07:35:35 * dihedral had fun reading the backlog from the night :-D 07:36:13 *** keoz [~keikoz@pha75-8-82-230-2-115.fbx.proxad.net] has quit [Quit: keoz] 07:37:23 <Eddi|zuHause> there wasn't really much going on, what was so funny? 07:37:54 *** DDR [~DDR@66.183.112.102] has quit [Ping timeout: 480 seconds] 07:37:56 *** DDR_ is now known as DDR 07:38:18 <planetmaker> hm, what was the (new) log URL? 07:39:53 <Eddi|zuHause> http://irclogs.qmsk.net/channels/openttd i believe 07:40:41 <Eddi|zuHause> i don't know what happened to mikegrb... i think we kicked him once... 07:47:06 *** Mucht [~Martin@chello084115143107.3.graz.surfer.at] has quit [Remote host closed the connection] 07:56:44 <Rubidium> so now we need to use a few hundred euro iPod to break an egg? Seems like a waste of money 08:06:19 *** lordaro [~lordaro@host86-132-24-126.range86-132.btcentralplus.com] has joined #openttd 08:07:53 <planetmaker> damn :-( One of my monitors died over night :S 08:09:03 <Rubidium> and you were too late for CPR? 08:10:10 * dihedral moans in silence :-P 08:10:51 <Rubidium> lordaro: you shouldn't have re-added the post requesting the sources of tb's tournament thingy after I read your post, you subsequently removed it and I added the sources to my post 08:11:48 *** lordaro [~lordaro@host86-132-24-126.range86-132.btcentralplus.com] has quit [Quit: Bye for now!] 08:11:53 <dihedral> not that they would cleanly apply i guess .... 08:12:07 <Rubidium> they will 08:12:11 <dihedral> uh? 08:12:18 <dihedral> that is interesting 08:12:25 <Rubidium> to r15254 08:12:31 <dihedral> ah :-) 08:12:41 <dihedral> i was not quite clear then i take it :-P 08:15:17 *** keoz [~keikoz@pha75-8-82-230-2-115.fbx.proxad.net] has joined #openttd 08:15:59 *** DDR [~DDR@66.183.112.102] has quit [Read error: Connection timed out] 08:16:19 *** TomyLobo [~foo@port-212-202-171-176.dynamic.qsc.de] has quit [Quit: A key, command, or action that tells the system to return to a previous state or stop a process.] 08:17:14 *** DDR [~DDR@66.183.112.102] has joined #openttd 08:23:11 *** Progman [~progman@p57A19C76.dip.t-dialin.net] has joined #openttd 08:24:35 *** lordaro [~lordaro@host86-132-24-126.range86-132.btcentralplus.com] has joined #openttd 08:28:09 *** trebuchet [~Trebuchet@69.51.104.87] has joined #openttd 08:29:15 *** DDR_ [~DDR@66.183.112.102] has joined #openttd 08:31:33 *** lordaro [~lordaro@host86-132-24-126.range86-132.btcentralplus.com] has quit [Quit: Bye for now!] 08:33:54 *** DDR [~DDR@66.183.112.102] has quit [Ping timeout: 480 seconds] 08:35:29 <TruePikachu> Someone should take a look at 4080 and contact the creater if they have not been contacted. 08:35:35 <TruePikachu> *FS#4080 08:36:42 <TruePikachu> The report takes second place for the prize for 'bug report with least amount if information given', first prize went to 2 identical photographs of a computer, 'before' and 'after' 08:37:15 <TruePikachu> I told them to attach crash.dmp - crash.sav doesn't seem to apply to server list problems 08:38:14 *** DDR_ [~DDR@66.183.112.102] has quit [Ping timeout: 480 seconds] 08:40:25 <Eddi|zuHause> people who report bugs automatically get an email when someone writes a comment 08:40:43 <Eddi|zuHause> but thanks for caring 08:40:46 * TruePikachu re-read the crash log, and thinks that McAfee may possibly be the problem 08:41:30 <TruePikachu> They may be using McAfee AV software; they are running McAfee SiteAdviser according to crash.log 08:42:33 <SmatZ> 3rd party tools sometimes cause problems in openttd, yes 08:42:34 <TruePikachu> On the XP+McAfee box here, McAfee has caused the majority of network problems, even with the firewall practically disabled 08:42:47 <TruePikachu> It even crashed Windows 3 times in a row! 08:43:13 <TruePikachu> boot->Login screen->5sec->reboot 08:43:37 <TruePikachu> Once in safe mode, I found the problem to be the antivirus scanner 08:44:33 <TruePikachu> (and SiteAdviser seems to never hook into IE/FireFox, therefore slowing the system by 2-3%) 08:45:04 <TruePikachu> (and when it does, you get 5-10 SiteAdviser icons in a row at the end of search results -_-) 08:47:05 <TruePikachu> For FS#4079, did anyone remove the attachments? 08:48:24 <SmatZ> TruePikachu: uploading of attachments sometimes fails for some reason 08:48:27 <dihedral> i hate it when plugins do not work as desired 08:48:40 <SmatZ> the dev team has decided it's user fault because we were never able to reproduce the problem 08:49:32 * TruePikachu will re-upload the images, but swears they uploaded correctly earlier today 08:50:08 <TruePikachu> O_o imagine if it failed on FS4080 08:51:46 <SmatZ> hmm why people love to upload crash.zip instead of separate files 08:52:03 <SmatZ> so I have to download the archive in order to view crash.log... 08:52:07 <TruePikachu> Especially as a zip; it is ugly compression 08:52:56 *** gynter [~gynter@ajavaras.pesa.veebike.net] has joined #openttd 08:53:07 <gynter> Hello, anyone compiled openttd on freebsd? 08:53:24 <TruePikachu> gynter: No, but I've compiled on Linux ;) 08:54:11 <SmatZ> @fs 1928 08:54:11 <DorpsGek> SmatZ: http://bugs.openttd.org/task/1928 08:54:24 <SmatZ> probably fixed some freebsd problem 08:54:33 <SmatZ> so at least the reported tried to compile openttd there 08:54:38 <SmatZ> *reporter 08:54:45 <TruePikachu> ^^ seems like a relativly useless @ command for me 08:55:18 <gynter> configure script is fine, gmake cries about missing lzo/lzo1x.h 08:55:25 <gynter> thou I have lzo installed 08:55:36 <gynter> lzo2 and lzop too 08:57:13 <gynter> freebsd 7.1 & latest openttd stable source 08:57:17 <Rubidium> does Debian/kfreebsd count? 08:57:19 <TruePikachu> Check your PATH 08:57:33 <SmatZ> gynter: do you have some lzo(2)-devel package installed? 08:57:38 <TruePikachu> Can you execute the command from '/'? 08:58:17 <TruePikachu> ^^ yes, I hate those kinds of package dependancies 08:58:59 <TruePikachu> If you have it all installed, sounds like the libUSB problem I've had when compiling TiLP 09:00:04 <gynter> does --enable-dedicated also require data files? 09:00:05 <TruePikachu> Stupid thing that 1.x and 0.x are not compatable :( 09:00:15 <gynter> eg Open* or original 09:00:16 <Eddi|zuHause> gynter: yes 09:00:18 <gynter> k 09:00:47 <Eddi|zuHause> there's some needed information e.g. for land generation in there 09:01:47 <Eddi|zuHause> sound and music is not needed 09:02:13 <gynter> header files are in /usr/local/include/lzo 09:02:26 <gynter> for lzo2 and in /usr/local/include for lzo 09:02:49 <TruePikachu> Is the missing file in there? 09:02:52 <Eddi|zuHause> and if you add that path to CFLAGS? 09:03:16 <Eddi|zuHause> gynter: mit be a bug in ./configure 09:03:19 <TruePikachu> I know it may seem like a dumb question, but it won't hurt to double-check 09:04:09 <gynter> lzo1x.h is in both dirs 09:04:34 * TruePikachu has no clue as to the problem then, as that has never happened to him 09:04:35 <Rubidium> it should just work with /usr/local/include/lzo/lzo1x.h 09:05:00 <Rubidium> maybe config.log can give a clue? 09:05:56 <TruePikachu> Are you able to read the file? If not, the problem could be with permissions...I've had that happen once, for some reason... 09:06:07 <gynter> trying /usr/local/include/lzo/lzo1x.h... found 09:06:07 <gynter> checking lzo2... found 09:06:13 <gynter> trying /usr/include/lzo/lzo1x.h... no 09:06:29 *** IPG [~chatzilla@dsl51B655BD.pool.t-online.hu] has joined #openttd 09:06:30 <gynter> in config.log 09:06:40 <gynter> that means it found the header thou 09:07:02 <TruePikachu> Well, then 'sudo cp /usr/local/include/lzo/lzo1x.h /usr/include/lzo/lzo1x.h' :) 09:07:24 <TruePikachu> Or, you could do a symbolic link, replacing 'cp' with 'ln -s' 09:07:26 <gynter> cannot 09:07:31 <TruePikachu> No root? 09:07:33 <gynter> i'm in freebsd jail 09:07:47 <gynter> and /usr/include is symlink to basejail 09:07:54 <gynter> eg base system 09:08:06 <Eddi|zuHause> TruePikachu: that is _definitely_ the wrong thing to do 09:08:28 <gynter> well but it did found it in /usr/local/include/lzo too as the logfile says 09:08:40 <gynter> afaik this should work fine 09:08:45 <TruePikachu> Well, all I know about FreeBSD is that the archetecture is similar to Linux 09:09:14 <TruePikachu> Try to prevent the check on /usr/include 09:11:27 <Rubidium> could you paste config.log somewhere? pastebin.com or so? 09:16:47 <gynter> sure, http://pastie.org/1114518 09:18:01 <peter1138> right... where's the RISC OS port? 09:18:54 <gynter> hmm, a what? 09:22:05 *** dfox [~dfox@ip-94-113-88-117.net.upcbroadband.cz] has joined #openttd 09:29:41 <Rubidium> hmm, that config log looks fine, so it fails somewhere during compilation? 09:33:24 *** sparr [sparr@c-24-98-228-62.hsd1.ga.comcast.net] has joined #openttd 09:33:33 <Rubidium> gynter: it sounds like /usr/local/include isn't a "search" path for your gcc 09:34:11 *** Fast2 [~Fast2@p57AF8573.dip0.t-ipconnect.de] has joined #openttd 09:34:42 <Rubidium> gynter: does ./configure --disable-builtin-depend help you 09:35:09 *** Mucht [~Martin@chello084115143107.3.graz.surfer.at] has joined #openttd 09:36:57 *** Mucht [~Martin@chello084115143107.3.graz.surfer.at] has quit [Remote host closed the connection] 09:37:06 <gynter> no 09:39:22 <Rubidium> gynter: does ./configure CFLAGS=/usr/local/include help? 09:39:42 <Rubidium> and it's gmake that is having the trouble and not gcc? 09:40:51 <gynter> http://pastie.org/1114557 09:40:53 <gynter> output 09:41:43 <Rubidium> so it's gcc that's not finding the file, i.e. the include path misses /usr/local/include 09:41:58 <Rubidium> and I (ofcourse) just gave you a wrong test 09:42:11 <Rubidium> gynter: ./configure CFLAGS=-I/usr/local/include 09:42:23 <Rubidium> slightly different than the previous, but I forgot the -I 09:42:34 <gynter> remove disable-builtin-depend? 09:43:05 <Rubidium> if that pasted error is the error you've always had, then you can remove the disable-builtin-depend 09:43:16 <Rubidium> though the strndup thing worries me a bit 09:47:02 <gynter> yea, lots of strndup stuff 09:49:20 <Rubidium> oh, they added strndup in FreeBSD 7.2 09:52:57 <VVG> hello 09:53:33 <Rubidium> this whole strndup stuff being "unreliably" available is just annoying. I guess configure needs to actively test for it's existance (yay for autotools/autoconf style :() 09:53:58 <gynter> hmm, is there a way to specify custom installation directory? 09:54:10 <dihedral> --prefix? 09:54:12 <Rubidium> gynter: see configure 09:54:15 <Rubidium> gynter: see configure --help 09:54:30 <gynter> thans, anyway, it compiled now 09:54:33 <gynter> thanks* 09:54:54 <Rubidium> it linked even due to those strndup warnings? No duplicate symbols or something? 09:55:29 <gynter> nope 09:58:21 <Rubidium> then one small test, does changing "#if defined(_GNU_SOURCE) || (defined(__NetBSD_Version__) && 400000000 <= __NetBSD_Version__)" to "#if 1" fix all the strndup warnings still make it link? 09:58:32 <Rubidium> that at the bottom of string_func.h 10:05:21 <gynter> sec 10:05:21 <gynter> icon-dir and icon-theme-dir are required for desktop icons etc? 10:05:50 <gynter> is it possible to disable creation of those? i only need it for dedicated server 10:16:25 <gynter> Rubidium, it fixed the warnings 10:20:46 <gynter> do I need all Open* stuff or only OpenGFX? 10:21:00 <gynter> for dedicated server 10:21:20 <Eddi|zuHause> only opengfx 10:36:35 <gynter> has configuration file changed alot, comparing to 0.6.3? 10:37:17 <Eddi|zuHause> 0.6 is a long time ago 10:37:52 <Eddi|zuHause> can you be more specific? 10:38:14 <Eddi|zuHause> openttd will load old config files and rewrite them 10:39:23 <gynter> nevermin, i'll just remake the server conf 10:41:03 *** TruePikachu [~chris@cpe-67-49-42-88.socal.res.rr.com] has quit [Read error: Operation timed out] 10:41:15 <dihedral> \o/ 10:41:58 <Eddi|zuHause> he asked me why i was calling him a troll 10:42:18 <Eddi|zuHause> i didn't have the heart to answer "because you're not exactly splurting of competence" 10:42:40 *** Sacro [~ben@adsl-87-102-115-110.karoo.KCOM.COM] has joined #openttd 10:44:41 *** Adambean [AdamR@82.hosts.reece-eu.net] has joined #openttd 10:47:38 <Eddi|zuHause> random thought: if you check the "related object" of a wagon (i.e. the engine). is the spec somehow extendible so you can submit a parameter to ask for the Nth vehicle in the chain instead? 10:48:01 <Eddi|zuHause> as a more generic approach to fs#2521 10:52:22 <Hirundo> The approach of random action2 type 84 should be applicable to varaction2 as well 10:55:27 <Eddi|zuHause> i think it should need 4 ways of addressing: {absolute, relative} and {whole chain, chain of same ID} 10:56:10 <Eddi|zuHause> ("and" standing for cartesic product here) 11:01:45 <Hirundo> Randomaction2 allows 3 of those (all except relative in chain of same ID) 11:02:26 <Hirundo> There are still some bits free, though 11:03:04 *** KenjiE20 [~KenjiE20@92.10.88.193] has joined #openttd 11:03:37 <Eddi|zuHause> crazy people might also want to address the end, but that could be done by providing negative numbers to "absolute", if that has at least 8 bits 11:04:00 <Eddi|zuHause> a chain may be up to 100 vehicles 11:04:43 <Hirundo> That does not work, currently (max count is 16) 11:06:27 <Eddi|zuHause> whoever wrote that spec... :p 11:06:58 *** fmauneko [~fmauneko@c3s13-1-82-228-108-97.fbx.proxad.net] has joined #openttd 11:12:28 *** Devroush [~dennis@94-225-67-91.access.telenet.be] has joined #openttd 11:19:42 <gynter> is there example dedicated server only config file somewhere for 1.0.3? 11:20:15 <dihedral> ./openttd will create a config file for you 11:20:23 <dihedral> you can then edit it 11:22:37 *** Celestar [~dax@89.204.153.101] has joined #openttd 11:23:06 <Eddi|zuHause> :o 11:24:34 <dihedral> hello Celestar 11:24:35 <dihedral> :-) 11:24:40 <Celestar> hi :) 11:24:44 <Celestar> how is life? 11:25:21 <dihedral> does openttd in the mean time support "Enhanced_Tunnels" as by this grf: http://users.tt-forums.net/ameecher/ben_k_tunnel.html 11:26:25 <dihedral> good, how's yours? 11:26:42 <Celestar> other than I'm ill ... not too shabby 11:26:58 <Celestar> and I'm having a fight with my ubuntu 11:27:36 <Eddi|zuHause> no, openttd does not support "enhanced tunnels" [as in rail over the tunnel entrance] 11:27:46 <Eddi|zuHause> and to my knowledge, also nobody is working on it 11:28:00 <Celestar> meh. 11:28:04 <Celestar> I had a branch for that. 11:28:08 <Celestar> but ran into probs 11:28:27 <Eddi|zuHause> it should be very similar to custombridgeheads 11:28:42 <Eddi|zuHause> with some graphical issues 11:28:44 <Rubidium> dihedral: you should know by now that a NewGRF can't implemented enhanced tunnels 11:29:02 <Celestar> yeah but cbh is hard with our virtual bridge thingy 11:29:25 <dihedral> Rubidium, the newgrf itself cannot - hence i am asking if it's in openttd in the meantime 11:29:40 <Eddi|zuHause> i remember the biggest issue was signal on the bridgehead, and maybe some stuff with turning around 11:30:04 <Celestar> yeah, in 1 out of 4 cases the train disconnected on turning around 11:30:19 <Rubidium> dihedral: ofcourse not, otherwise you'd've seen a commit log saying so 11:30:49 <dihedral> i recall not being around for a good few hundred revisions :-P could have checked the logs, true 11:31:36 <Eddi|zuHause> the logs might not be totally conclusive with regards to such features... e.g. try searching for "implement tram support" :) 11:33:39 <dihedral> it would have definately been marked with -[Ff]eature(?:ete|ish)? 11:34:07 <Celestar> hrhr 11:34:12 <Celestar> nice regex >P 11:39:40 *** wollollo [~martin@host86-175-29-209.wlms-broadband.com] has joined #openttd 11:42:43 *** fmauneko [~fmauneko@c3s13-1-82-228-108-97.fbx.proxad.net] has quit [Quit: leaving] 11:42:49 *** fmauneko [~fmauneko@c3s13-1-82-228-108-97.fbx.proxad.net] has joined #openttd 11:44:19 <Eddi|zuHause> @openttd commit 9923 11:44:21 <DorpsGek> Eddi|zuHause: Commit by rubidium :: r9923 /trunk (18 files in 5 dirs) (2007-05-25 22:07:40 UTC) 11:44:22 <DorpsGek> Eddi|zuHause: -Add: support for Action 0 Road vehicles, property 1C, bit 0. 11:44:39 <Eddi|zuHause> i don't think that matches ;) 11:45:54 <Rubidium> but name me what NewGRF bit is about rail on tunnelheads :) 11:46:18 <Eddi|zuHause> that should rather be a TTDP flag? 11:46:18 *** Vitus [~chatzilla@138.194.wms.cz] has joined #openttd 11:46:34 <Rubidium> good idea :) 11:50:30 *** devilsadvocate [~devilsadv@202.3.77.41] has quit [Ping timeout: 480 seconds] 11:57:34 *** glx [glx@2a01:e35:2f59:c7c0:3165:e98f:7a14:c06c] has joined #openttd 11:57:37 *** mode/#openttd [+v glx] by ChanServ 11:59:29 *** Netsplit synthon.oftc.net <-> weber.oftc.net quits: trebuchet, ^Spike^, sparr, @orudge, Westie 12:02:31 *** ar3k [~ident@87-239-75-101.internetia.net.pl] has quit [Read error: Connection reset by peer] 12:02:58 *** Netsplit over, joins: Westie, @orudge, sparr, trebuchet, ^Spike^ 12:02:59 *** mode/#openttd [+v orudge] by ChanServ 12:03:09 *** ar3k [~ident@87-239-75-101.internetia.net.pl] has joined #openttd 12:03:21 *** avdg [~Adium@94-227-100-192.access.telenet.be] has joined #openttd 12:04:34 *** Sacro [~ben@adsl-87-102-115-110.karoo.KCOM.COM] has quit [Remote host closed the connection] 12:05:42 *** Eddi|zuHause2 [~johekr@p54B761E0.dip.t-dialin.net] has joined #openttd 12:06:29 <Eddi|zuHause2> soo... who holds the plug in his hand? 12:07:50 <dihedral> it must be orudge, he just wanted to hide his join! 12:10:05 *** fmauneko [~fmauneko@c3s13-1-82-228-108-97.fbx.proxad.net] has quit [Quit: leaving] 12:12:04 *** Eddi|zuHause [~johekr@p54B761E0.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 12:12:43 *** Eddi|zuHause2 is now known as Eddi|zuHause 12:14:28 *** Sacro2 [~Sacro@adsl-87-102-115-110.karoo.KCOM.COM] has joined #openttd 12:16:09 *** devilsadvocate [~devilsadv@202.3.77.209] has joined #openttd 12:19:11 *** dfox [~dfox@ip-94-113-88-117.net.upcbroadband.cz] has quit [Remote host closed the connection] 12:22:05 *** Fuco [~dota.keys@188.123.106.105] has joined #openttd 12:23:54 *** fmauneko [~fmauneko@82.228.108.97] has joined #openttd 12:23:59 *** fmauneko [~fmauneko@82.228.108.97] has quit [] 12:24:03 *** fmauneko [~fmauneko@c3s13-1-82-228-108-97.fbx.proxad.net] has joined #openttd 12:25:26 *** Netsplit synthon.oftc.net <-> charm.oftc.net quits: @Rubidium, Kurimus, russell_h, a1270 12:27:04 *** fmauneko is now known as fmauNeko 12:28:36 *** ecke [~ecke@188.75.128.2] has joined #openttd 12:29:26 *** Netsplit over, joins: russell_h 12:29:57 *** Netsplit over, joins: Kurimus 12:31:18 *** Rubidium [~Rubidium@178.19.113.122] has joined #openttd 12:31:18 *** ServerMode/#openttd [+ov Rubidium Rubidium] by charm.oftc.net 12:36:51 *** avdg [~Adium@94-227-100-192.access.telenet.be] has quit [Read error: Connection reset by peer] 12:38:14 *** avdg [~Adium@94-227-100-192.access.telenet.be] has joined #openttd 12:43:15 * yorick thinks ludde would do that 12:46:14 *** Rubidium_ [~Rubidium@noiv.net] has joined #openttd 12:46:31 * roboboy pokes his head in 12:46:59 <Eddi|zuHause> what's a noiv? 12:48:14 *** Rubidium [~Rubidium@178.19.113.122] has quit [Ping timeout: 480 seconds] 12:48:54 <gynter> is ; comment in openttd.cfg? 12:49:28 <Eddi|zuHause> it's the same format as .ini files 12:49:48 <Eddi|zuHause> probably # works 12:50:16 <gynter> hmm ; works, but it removes the commented lines 12:50:17 <gynter> not good 12:53:04 <avdg> :) 12:53:15 <avdg> whoops wrong channel 12:53:50 *** fmauNeko_ [~fmauneko@c3s13-1-82-228-108-97.fbx.proxad.net] has joined #openttd 12:57:17 <Belugas> hey low 12:57:34 <planetmaker> moin Belugas 12:58:14 <Belugas> boing boing planetmaker :) 12:58:24 <dihedral> boing boing? ^^ 12:58:29 <dihedral> how cute ^^ 12:59:50 <Eddi|zuHause> i only know boeing, and they're not making planets, only planes, without t 13:00:48 *** fmauNeko [~fmauneko@c3s13-1-82-228-108-97.fbx.proxad.net] has quit [Ping timeout: 480 seconds] 13:00:49 <planetmaker> hehe :-) 13:01:13 *** fmauNeko_ is now known as fmauNeko 13:06:40 <Belugas> it's just a sound :) 13:08:01 <Eddi|zuHause> i know :) i was just making fun of the close spellings ;) 13:09:09 *** Rubidium_ is now known as Rubidium 13:13:26 <Rubidium> Eddi|zuHause: it's the rdns of rbijker.net (yes multiple things are hosted there) because it didn't connect over IPv6 to OFTC (in which case it should be getting rbijker.net as rnds) 13:14:22 <Rubidium> unless IPv6 rdns doesn't work, in which case I blame orudge 13:14:32 <Rubidium> though I can't be bothered that much by rdns-es anyhow 13:14:59 <VVG> Recent trunk gives me a warning about old opengfx. Where do i get a new one? 13:15:35 <Ammler> http://bundles.openttdcoop.org/opengfx/nightlies/LATEST 13:16:13 <gynter> is it possible to remove/add newgrf-s to existing scenario? 13:16:24 <VVG> oh, no new stable opengfx yet? 13:16:41 <gynter> nevermind 13:16:53 <Ammler> there was no stable opengfx yet at all 13:17:24 <VVG> what about the one on bananas? 13:17:41 <Eddi|zuHause> gynter: only in single player, and it's not recommended 13:17:57 <gynter> why it's not recommended? 13:18:33 <Eddi|zuHause> gynter: it may have bad side effects 13:18:36 <Rubidium> imagine the maglev changing in a steam train that's not able to run on maglev tracks 13:18:40 <planetmaker> <Ammler> there was no stable opengfx yet at all <-- I'd call 0.2.x 'stable' :-) 13:20:07 <Rubidium> or your sand quarry giving invalid cargo and looking like a part of a coal mine 13:20:28 <Ammler> I call 0.2 complete :-) 13:20:51 <Eddi|zuHause> hm... if anyone of you expected a delivery of ~2kg uranium from moldova, that shipment likely won't arrive... 13:20:55 <Rubidium> or a 1x1 becoming one tile of a 2x2 house, but the other parts not built at the right place 13:21:07 <Ammler> VVG: I just meant, contributions are still welcome :-P 13:21:08 <Eddi|zuHause> http://www.dnews.de/nachrichten/panorama/301106/moldawien-2-kilo-uran-sichergestellt-.html 13:22:29 <VVG> Ammler: i have nothing i could contribue to opengfx 13:22:32 *** valhallasw [~valhallas@132.229.39.107] has joined #openttd 13:22:36 <Rubidium> Ammler: under those premises OpenTTD isn't stable either 13:23:15 <VVG> but it has been complete :) 13:23:41 <Ammler> opengfx should at least have no bugs, so yes, it is stable 13:24:14 <Ammler> but it might have a lot glitches :-) 13:26:07 <dihedral> ... 13:27:38 *** fmauNeko [~fmauneko@c3s13-1-82-228-108-97.fbx.proxad.net] has quit [Ping timeout: 480 seconds] 13:30:55 <planetmaker> <VVG> but it has been complete :) <-- yes and no. It has no black boxes anymore 13:31:20 <planetmaker> But it has not yet fulfilled its mission: replace all original sprites by a unique sprite :-) 13:32:17 <Rubidium> even so, one could argue whether OpenGFX can ever be complete up to the moment OpenTTD dies a silent death (no more sprites needed from OpenTTD's point of view) 13:32:21 <VVG> planetmaker: that was reffering to ottd 13:32:37 <planetmaker> Though I'd rephrase the mission as "provide the graphics which make the best vanilla experience possible" 13:32:46 <planetmaker> oh, ok 13:33:02 <Rubidium> s/vanilla/out of the box/ 13:33:13 <planetmaker> yes :-) 13:33:21 <planetmaker> It's not written yet anywhere. But I should ;-) 13:33:31 <Ammler> mÀh :-P 13:34:20 <peter1138> hurr, rpcemu's source code mentions openttd 13:35:24 *** devilsadvocate [~devilsadv@202.3.77.209] has quit [Ping timeout: 480 seconds] 13:35:46 *** Timmaexx [~quassel@port-92-192-118-105.dynamic.qsc.de] has joined #openttd 13:38:29 <Belugas> can i have moka out of the box instead? not much a vanilla guy... 13:39:30 <Rubidium> peter1138: where? In its OSX specific code or something? 13:39:43 *** IPG [~chatzilla@dsl51B655BD.pool.t-online.hu] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716]] 13:40:38 <planetmaker> hm... dictionaries know neither "out of the box" nor "vanilla". But "no-frills" 13:42:14 <peter1138> OSX? 13:44:22 <Rubidium> peter1138: given commits like "Allow networking to be enabled on Mac OS X if built with the Cocoa GUI" I'd assume they've got some OS X specific code 13:44:32 <VVG> planetmaker: google's define knows 13:44:46 *** devilsadvocate [~devilsadv@202.3.77.41] has joined #openttd 13:45:05 <planetmaker> yeah. As does wiki 13:45:10 <planetmaker> But not meriam 13:45:19 <peter1138> nah, it's in the ARM emulator code, talking about a performance increase 13:45:21 <planetmaker> strange 13:45:41 <peter1138> can't get it to see sample.cat :( 13:46:35 *** tokai [~tokai@port-92-195-199-89.dynamic.qsc.de] has quit [Ping timeout: 480 seconds] 13:48:29 *** tokai [~tokai@port-92-195-15-222.dynamic.qsc.de] has joined #openttd 13:48:32 *** mode/#openttd [+v tokai] by ChanServ 13:49:25 <Rubidium> any idea whether it's trivial to spawn a few jobs from bash and wait for them to be done without looping over ps output and such? 13:49:45 <gynter> how can I make "restart" to restart my scenario what I specified with -g flag? 13:49:59 <Rubidium> you can't 13:50:04 <dihedral> load 13:50:14 <peter1138> something using fg? 13:50:21 <dihedral> alias restart "load %A" 13:50:43 <peter1138> working something like a pthread_create/pthread_join model 13:50:55 <dihedral> unless of course it's not possible to create aliases for existing commands :-P 13:51:26 <dihedral> Rubidium, map rotation list ^^ 13:51:50 <peter1138> Rubidium, their OSX build uses allegro 13:52:03 <peter1138> (as does linux & windows) 13:53:19 *** devilsadvocate [~devilsadv@202.3.77.41] has quit [Ping timeout: 480 seconds] 13:54:36 *** glx [glx@2a01:e35:2f59:c7c0:3165:e98f:7a14:c06c] has quit [Ping timeout: 480 seconds] 13:55:45 <gynter> why my server starts with one premade company called Unnamed? 13:55:53 <Rubidium> hmm, fg/bg don't seem to work from a script 13:56:13 <Rubidium> gynter: because there's a company without name in the scenario 13:57:10 <gynter> is there a way to remove it? 13:59:00 <avdg> hmm⊠seems there is a patch for bug 4070 13:59:39 *** Timmaexx [~quassel@port-92-192-118-105.dynamic.qsc.de] has quit [Remote host closed the connection] 13:59:42 * avdg gets busy 13:59:45 *** bryjen [~bryjen@63.147.94.149] has joined #openttd 14:01:09 *** Tennel [~Tennel@port-ip-213-211-212-60.reverse.mdcc-fun.de] has joined #openttd 14:02:49 <avdg> nope :( 14:03:16 <Eddi|zuHause> Rubidium: something like "command && good_beep || bad_beep;"? 14:03:50 * Rubidium wonders whether the server has beeps 14:04:12 <Eddi|zuHause> well, replace beep by sendmail or something ;) 14:04:44 <Rubidium> and then count the numbers of emails to determine whether to progress with a script? 14:05:58 <Rubidium> do some general stuff; for (xyz) { do real time expensive operation independent of others }; do some general other stuff 14:05:59 <avdg> hmm works now 14:06:19 <avdg> I probably did something wrong 14:06:22 <Rubidium> now that loop I want to "multithread" 14:06:57 <Rubidium> but I need to wait till all "threads" are finished like pthread_create + pthread_join 14:07:16 <Rubidium> though I think I've found the solution 14:07:56 <Eddi|zuHause> i'm fairly sure there are ways to do that 14:08:44 <Eddi|zuHause> i don't find one off the top of my head, though 14:09:26 <Rubidium> bah... looper isn't an option as it doesn't allow different rsync commands... unless... lets test something 14:10:43 *** glx [glx@2a01:e35:2f59:c7c0:2d3d:7802:ea48:45c8] has joined #openttd 14:10:46 *** mode/#openttd [+v glx] by ChanServ 14:14:15 <planetmaker> http://stackoverflow.com/questions/356100/how-to-wait-in-bash-for-several-subprocesses-to-finish-and-return-exit-code-0-w <-- does that maybe help, Rubidium ? 14:28:04 *** Gremnon [~gremnon@87.113.141.166] has joined #openttd 14:28:09 <Rubidium> maybe, though I've found some other solution already 14:28:23 *** Sacro2 is now known as Sacro 14:32:11 <avdg> :/ 14:33:36 <avdg> there are still bugs with the openttd windows here, but I have no time for fixing them now 14:33:51 <avdg> or tracing the error to say it in better words 14:34:20 <planetmaker> avdg, the minimum size error hasn't been fixed 14:34:28 <avdg> other window bugs 14:34:33 <avdg> segment fault 14:34:53 <planetmaker> when the main window is larger than 64^2? 14:34:59 <avdg> nope 14:35:04 <avdg> uh yes 14:35:04 <avdg> : 14:35:07 <avdg> :) 14:35:10 <planetmaker> :-) 14:35:18 <peter1138> 4096? 14:35:28 <avdg> hmm I do a few tries 14:35:48 * avdg backs up crash report 14:36:44 *** gynter [~gynter@ajavaras.pesa.veebike.net] has quit [Quit: Leaving] 14:37:00 <avdg> hmm 14:37:47 <avdg> its something about moving when the size of openttd's window is smaller then the openttd window itsself 14:37:59 <avdg> move -> crash 14:38:11 <avdg> I though someone had a segfault before, right? 14:40:46 <avdg> well I just put the report files online 14:44:54 * Rubidium wonders when we'll get reports about OpenTTD's days being too long 14:45:06 <avdg> :) 14:48:45 <avdg> k :) 14:48:45 *** a1270 [~a1270@72-24-233-98.cpe.cableone.net] has joined #openttd 14:48:49 <Rubidium> as as far as I can recall ticks take 27 ms in TTD(P), but 30 in OpenTTD 14:49:43 <planetmaker> :-D 14:50:12 <Eddi|zuHause> Rubidium: but that has been like this for over 5 years, and nobody reported it? 14:50:21 *** HerzogDeXtEr1 [~Flex@88.130.173.252] has joined #openttd 14:50:37 <Rubidium> yep, only that OpenTTD runs too fast 14:50:50 <peter1138> yup 14:50:59 <peter1138> wtih 27ms per tick, game days are 1998ms 14:51:30 <peter1138> i surmise that ticks are meant to be 27.027ms ;) 14:52:34 <avdg> well, cya 14:52:41 <Gremnon> what're grfcodec and nforenum coded in? C? 14:52:43 *** avdg [~Adium@94-227-100-192.access.telenet.be] has quit [Quit: Leaving.] 14:52:47 <peter1138> C++ 14:52:50 <Gremnon> ah 14:52:50 <Eddi|zuHause> didn't someone wonder about the significance of 74 recently? 14:52:53 <Gremnon> that eases that one 14:53:10 <Gremnon> now for the next one... is there an svn or similar accessible repo for each/either 14:53:42 <Rubidium> yes 14:53:42 <Eddi|zuHause> i think they are on coop devzone 14:53:58 <Gremnon> ah good, I know where to search now then 14:54:02 <Gremnon> I didn't think to check there 14:54:02 <planetmaker> did you even look? 14:54:06 <Rubidium> Gremnon: have you read the posts on the forum about nforenum/grfcodec? 14:54:09 <planetmaker> it's the 2nd hit on google 14:54:11 <Gremnon> no, actually, I haven't 14:54:21 <planetmaker> the 1st is the old one 14:54:22 <Gremnon> read the posts, that is 14:54:33 <Gremnon> I kinda forgot about them 14:54:48 <Rubidium> have you read (trunk's) readme.txt? 14:55:05 <Gremnon> .... people read files named readme? 14:55:29 <planetmaker> hm. who is minime? 14:55:31 <Rubidium> no, but we use them to point people to them under the pretense that they should have read them 14:55:39 *** ecke [~ecke@188.75.128.2] has quit [Ping timeout: 480 seconds] 14:55:50 <Rubidium> planetmaker: TTDP dev 14:55:55 <Gremnon> fair point 14:55:56 <planetmaker> ah :-) 14:55:58 *** HerzogDeXtEr [~Flex@88.130.154.6] has quit [Ping timeout: 480 seconds] 14:56:22 <Gremnon> found them now, now maybe I'll see if my new attempt to figure out the mysterious world of NFO actually works 14:56:25 <Gremnon> my guess is not 14:56:32 <Rubidium> planetmaker: also known for his work on tools such as GRFCodec and NFORenum 14:56:44 <planetmaker> :-) 14:56:45 *** glx [glx@2a01:e35:2f59:c7c0:2d3d:7802:ea48:45c8] has quit [Remote host closed the connection] 14:57:06 <planetmaker> I assume so. I just found the name as developer with access to both repos. 14:57:11 *** [hta]specx [~opera@ip94-126-210-87.adsl2.static.versatel.nl] has quit [Ping timeout: 480 seconds] 14:57:18 <planetmaker> so he worked on it before then 14:57:30 *** glx [glx@2a01:e35:2f59:c7c0:2d3d:7802:ea48:45c8] has joined #openttd 14:57:33 *** mode/#openttd [+v glx] by ChanServ 14:57:54 <Rubidium> planetmaker: also known as Dan Masek (see nforenum -h) 14:58:35 <Rubidium> planetmaker: yes, he worked on them before and asked for an account just before he went on vacation, so I hope to see him entering the IRC channel when he returns 14:58:53 <planetmaker> nice :-) 15:02:33 <Gremnon> okay, last question for the moment... both grfcodec and nforenum should compile and run okay on 64 bit gnu-linux, right? 15:03:08 <planetmaker> they do 15:03:19 <planetmaker> binaries for both are also readily available 15:03:31 <planetmaker> http://www.openttd.org/download-grfcodec 15:03:36 <planetmaker> and -nforenum 15:03:41 <Gremnon> that wouldn't work for what I'm attempting next, since my NFO attempt, predictably, failed 15:03:57 <Gremnon> I'm making a PKGBUILD for each for Arch's AUR 15:04:09 <Gremnon> there's ones for OpenTTD, OpenGFX, SFX and MSX, but not one for either 15:04:17 <Gremnon> so I thought I'd be the kind soul to give them 15:07:50 * andythenorth considers patching temperate so towns need food 15:08:14 <Gremnon> afaik, if an industry set defines it, they accept it 15:08:27 <Gremnon> unless you mean the same behaviour as above-snowline arctic towns 15:08:29 <andythenorth> I patched Tropic so all towns need food and water whether desert or not. But hauling water around is dull :P 15:08:33 <planetmaker> andythenorth, rather... add a newgrf feature: town growth cargo(s) configurable 15:08:39 <planetmaker> Gremnon, not really 15:08:40 <andythenorth> planetmaker: that I can't do 15:08:47 <planetmaker> andythenorth, yes, yet 15:08:57 <planetmaker> That's why I said: patch OpenTTD so that it becomes possible 15:08:59 <andythenorth> changing the string from Arctic to Temperate I can do 15:09:06 <planetmaker> Then it'd be a good patch instead of a hack ;-) 15:09:16 <Gremnon> that reminds me 15:09:16 <andythenorth> no, my thinking is all wrong for writing real code 15:09:23 <planetmaker> :-P 15:09:31 <andythenorth> I'll just end up wasting other people's time with stupid questions 15:09:34 <Gremnon> I seem to recall hearing something about a patch that turned toyland climate into a mix of temperate, tropic and arctic climates 15:09:37 <Gremnon> did it ever work? 15:09:46 <andythenorth> all climates in one? 15:09:50 <andythenorth> search the forum for it :P 15:10:18 <andythenorth> planetmaker: last time I tried to patch (for industry separation) it took me three days, and it was mostly 'code written by other people and sent to me on irc' 15:10:19 <Gremnon> I'm waiting for the search to load as I type 15:10:20 <planetmaker> sounds like suggestion forum stuff 15:10:32 <planetmaker> haha @ andythenorth :-) 15:11:00 <andythenorth> writing a spec for newgrf town growth we *could* do 15:11:23 <andythenorth> http://tt-foundry.com/misc/town_growth.txt 15:11:35 <Eddi|zuHause> Gremnon: i don't recall anything useful ever comming out of that patch attempt 15:12:06 <Gremnon> that's a shame, it'd be interesting to have all three in one, and replacing toyland... which no one really plays on AFAIK anyway 15:12:42 <Rubidium> Gremnon: then you haven't played much on OpenTTDcoop's stable server 15:13:00 <Gremnon> I haven't played OTTDcoop at all 15:13:09 <Gremnon> I don't have a reliable enough connection for it 15:13:24 <planetmaker> hm... indeed we should offer again a toyland one there :-) 15:13:51 <planetmaker> Rubidium, but we don't have a all-climates-in-one either ;-) 15:14:23 <Rubidium> Gremnon: if you're adding nforenum and grfcodec, please add catcodec as well. Then they won't have much reasons anymore to just compile opengfx/opensfx instead of taking the binary packages 15:14:56 <Rubidium> Gremnon: you can find the source at http://www.openttd.org/en/download-catcodec or svn://svn.openttd.org/extra/catcodec 15:15:40 <Gremnon> ah, that's useful too. I'm going to see if I can make a functional grfcodec PKGBUILD first though - I've never tried making something for the AUR before, so I don't want to try three, then find the all don't work 15:16:37 <Gremnon> problem though 15:16:56 <Belugas> all climates in one... 15:16:58 <Gremnon> checked out the source, ran make, all fine - but for it to be in a PKGBUILD, AFAIK it needs to work with 'make install' too 15:17:02 <Rubidium> for AUR you're probably better of using the "stable" releases of grfcodec and nforenum 15:17:05 <Belugas> it surely sounds appealing 15:17:21 <planetmaker> Belugas, sure :-) 15:17:36 <Gremnon> some packages have stables and development ones in there, the devel ones with -hg or similar on 15:17:41 <planetmaker> It would need a few more bits, though 15:18:14 <Gremnon> I also figure that the devel ones might be more worth putting there, since then one just needs to rebuild the package, and the user would have access to any newer callbacks, etc 15:19:03 <Gremnon> let me see if I can make a working PKGBUILD for grfcodec-hg first though, then I'll work from there 15:19:06 <Gremnon> one step at a time 15:21:46 <Belugas> a few, indeed, and quite a lot of work... 15:22:12 <planetmaker> indeed 15:23:08 *** Fast2 [~Fast2@p57AF8573.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 15:25:31 <planetmaker> http://vcs.openttd.org/svn/export/20612/trunk/docs/landscape_grid.html <-- hm... going by that I have three free bits in each landscape class. Which would be sufficient 15:25:39 *** Celestar [~dax@89.204.153.101] has quit [Ping timeout: 480 seconds] 15:26:52 <planetmaker> if one consideres the accessed bits without meaning for houses 15:26:56 <planetmaker> as free 15:27:50 *** KouDy [~koudy@ip-89-176-216-203.net.upcbroadband.cz] has joined #openttd 15:28:01 <Rubidium> planetmaker: sufficient for what? 15:29:51 <planetmaker> 3 bits for climate info 15:30:08 <planetmaker> though one can do with two 15:30:14 <planetmaker> maybe even one 15:30:31 <planetmaker> tropical zone info is free. So that can be thrown into the pool as well 15:30:44 <planetmaker> 'free' as in works towards similar things 15:30:46 <Rubidium> do towns have those bits? 15:30:49 <planetmaker> and could be unified with it 15:31:00 <Rubidium> s/towns/houses/ 15:31:18 <Rubidium> hmm, guess so as it's an all climate set of bits 15:31:22 <planetmaker> houses have three bits marked as "accessed but no real meaning" 15:31:33 <planetmaker> yes, they should have that 15:31:40 <planetmaker> the tile reverts after a house is deleted 15:32:13 <planetmaker> and houses can access it ;-) 15:32:19 <Rubidium> hmm, no snowy bits 15:32:50 <planetmaker> hm. no. no access to tropical zone 15:33:25 <Rubidium> 3 bits should be enough though; snow, arctic, temperate, tropic, rainforest, desert 15:33:27 * Belugas looks at his mental plan of regions... 15:33:27 <planetmaker> Rubidium, well, houses know their height and snowyness obviously works 15:33:55 <Belugas> planetmaker, not entirely true. it's a matter of houses id and snow level 15:33:57 <Rubidium> so you'd need only 1 bit there 15:33:58 <planetmaker> Rubidium, how does that work with varying snowline? 15:34:19 <planetmaker> snow yes/no needs somewhat its own bit 15:34:27 <Gremnon> and what would happen at the tiles where snow and desert meet, if that's allowed? 15:34:51 <Gremnon> plus you'd need unified grass styles - temperate and arctic to snow are alright, but tropic to snow, and temp/arc to desert aren't 15:35:22 <Rubidium> planetmaker: arctic gets snowy or not. Don't think deserts or rainforest should become snowy at any point 15:35:33 <planetmaker> ^ I agree 15:35:35 <Rubidium> I even doubt whether temperate should get snowy 15:35:37 <planetmaker> temperate might get snow 15:35:52 <planetmaker> but that's an option for sure 15:36:00 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has joined #openttd 15:36:03 <Rubidium> although you could implement that as well, but then you've got snow right up to the desert/tropics 15:36:27 <Belugas> which is possible. realistic 15:36:28 <planetmaker> yes. One might introduce two snow heights: arctic + temperate 15:36:29 <Belugas> brrrrrrrr 15:37:11 <Rubidium> planetmaker: that'd look possibly odd at the transition from arctic to temperate 15:37:32 <planetmaker> :-) as would the transition desert / temperate look odd 15:37:47 <planetmaker> or arctic/temperate with no snow in temperate without two snow lines 15:38:26 <planetmaker> So does it need 'transition' tiles? 15:38:36 * roboboy reboots for updates 15:38:56 *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has quit [Read error: Connection reset by peer] 15:42:23 <andythenorth> kilimanjaro is snowy :) 15:42:53 <planetmaker> still. How long? 15:43:28 *** nicfer [~nicfer@190.50.49.55] has joined #openttd 15:43:28 *** AnodA [~AnodA@95-90-0-250-dynip.superkabel.de] has joined #openttd 15:43:36 *** ecke [~ecke@188.75.128.2] has joined #openttd 15:43:36 <Eddi|zuHause> about as long as the aral sea has water in it ;) 15:43:46 *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has joined #openttd 15:43:58 <andythenorth> all climates in one is a nice project :) 15:44:07 <andythenorth> might put an end to TTD original base set though :( 15:44:16 <Eddi|zuHause> andythenorth: i wouldn't hold my breath for it 15:44:23 <planetmaker> :-) Nope 15:48:08 <roboboy> hm my "mousewheel" doesn't work anymore 15:48:25 <Gremnon> the grfcodec-hg PKGBUILD is now in the AUR for arch. it works for me, but 'works for me' and 'works for everyone else' are two different things 15:48:31 <Gremnon> next up is the NFOrenum package 15:48:41 <Gremnon> link for grfcodec-hg, in case anyone wants to look is http://aur.archlinux.org/packages.php?ID=40247 15:53:32 <Gremnon> nforenum-hg too now - http://aur.archlinux.org/packages.php?ID=40248 15:54:56 *** orudge` [~orudge@c-75-73-67-58.hsd1.mn.comcast.net] has joined #openttd 15:54:59 *** mode/#openttd [+o orudge`] by ChanServ 15:56:03 <Ammler> I would link to without "repository" 15:56:24 <Ammler> someone could think that is the url fro clone 15:56:35 <Gremnon> oops, didn't notice that 15:56:45 <Gremnon> I'll update that now, and give NFOrenum a better description too 15:57:06 * roboboy wonders if he should reboot again 15:57:56 <Ammler> Gremnon: wouldn't it be better to use nightlies? 15:58:02 <Ammler> or do you? 15:58:36 <Gremnon> I do. these packages, in theory, fetch the head revision and compile it 15:59:02 <Gremnon> my reason being that, this way one only has to recompile the package to get the latest updates to each, and therefore access to new callbacks etc 15:59:06 <Rubidium> and they won't compile when someone doesn't have a recent boost 15:59:19 <Gremnon> hmm 15:59:39 <Gremnon> for those using automated AUR tools, I can just bump the package version periodically, forcing an update 15:59:52 <Gremnon> those who do it manually should know to periodically recompile anyway 16:00:01 <Ammler> Rubidium: does it check for boost version? 16:00:15 <Rubidium> Ammler: it being? 16:00:27 <Rubidium> if it's GCC during compilation, then yes it does! 16:00:30 <Ammler> nforenum in speci 16:00:43 <Gremnon> ah, didn't realise it required boost, I'll add it as dependency 16:00:57 <Ammler> boost 1.4x 16:01:06 <Gremnon> specific or that or later? 16:01:10 <Rubidium> oh, you mean Gremmon's pkgbuilds? No, they don't specify a boost version... they don't specify it requires boost at all 16:01:18 <Gremnon> yes, I'm about to update that 16:01:20 <Ammler> something around that 16:01:31 *** Born_Acorn [~bornacorn@yoda.zernebok.com] has quit [Read error: Operation timed out] 16:01:45 <Rubidium> Gremnon: somewhere from boost 1.40-ish it works (not sure which exactly) 16:01:53 <Ammler> grfcodec works with every boost 16:02:00 <Ammler> nforenum needs a very recent version 16:02:29 <Ammler> min. 1.41 afaik 16:02:30 <Gremnon> the boost from the arch repositories is 1.43, so unless it needs a newer version, I'll leave both without a specific version check and specify just boost 16:02:54 <Rubidium> just say 1.43+ :) 16:02:57 <Ammler> doesn't arch have different releases? 16:03:25 <Gremnon> no, it's a rolling release 16:03:49 <Gremnon> Rubidium, I'll leave it without for now unless anyone else has trouble with it 16:03:50 *** Andel [~andel@owenrudge.net] has quit [Ping timeout: 480 seconds] 16:04:34 *** orudge [~orudge@owenrudge.net] has quit [Ping timeout: 480 seconds] 16:04:38 *** jpx_ [jpx_@a91-156-225-96.elisa-laajakaista.fi] has joined #openttd 16:05:08 <Gremnon> packages updated. same link as before for each 16:05:58 <Gremnon> I updated the descriptions for each with the ones on the overview page 16:06:46 <Gremnon> catcodec might take a little longer unless someone cares to help me add a 'make install' to it 16:06:59 <planetmaker> <Ammler> min. 1.41 afaik <-- 1.40 works, too 16:07:17 *** fmauneko [~fmauneko@93.29.187.142] has joined #openttd 16:08:37 <Eddi|zuHause> i needed to upgrade boost at least twice to compile renum in the past 16:09:45 <Eddi|zuHause> Gremnon: it might be useful to specify a version anyway, in case someone has not updated yet, or you need an updated boost in the future 16:10:36 <Gremnon> right, time to figure out how to specify a version then 16:13:18 <welshdragon> hmm 16:13:42 <welshdragon> OSX 10.5 won't run 2 instances of OpenTTD 16:13:47 <welshdragon> bugger 16:14:07 *** orudge [~orudge@owenrudge.net] has joined #openttd 16:14:10 *** mode/#openttd [+o orudge] by ChanServ 16:14:16 *** orudge` [~orudge@c-75-73-67-58.hsd1.mn.comcast.net] has quit [Quit: Goodbye.] 16:15:04 <welshdragon> ohrudge 16:15:07 <planetmaker> welshdragon, then it must be different from 10.4 and 10.6 16:15:15 <planetmaker> or you do something different ;-) 16:15:48 <planetmaker> you started it from the command line? 16:16:04 *** rtypo [rtypo@pc54.clicknet.iasi.rdsnet.ro] has quit [] 16:16:14 <welshdragon> planetmaker, ooh, no 16:16:21 <welshdragon> from the launcher 16:17:31 <welshdragon> er, how do i start it in the command line? 16:18:31 <Gremnon> packages updated again. They now specify boost 1.43 or higher 16:20:05 *** Born_Acorn [~bornacorn@yoda.zernebok.com] has joined #openttd 16:20:06 *** Andel [~andel@owenrudge.net] has joined #openttd 16:21:46 *** fmauneko [~fmauneko@93.29.187.142] has quit [Ping timeout: 480 seconds] 16:23:40 *** valhallasw [~valhallas@132.229.39.107] has quit [Quit: Lost terminal] 16:26:39 <CIA-2> OpenTTD: rubidium * r20613 /extra/catcodec/ (Makefile Makefile.bundle): [catcodec] -Change: make install and unify output 16:27:20 <Gremnon> thank you rubidium 16:27:37 <Gremnon> one catcodec package coming right up 16:35:55 <Gremnon> http://aur.archlinux.org/packages.php?ID=40253 16:36:35 <Gremnon> should work safely, unless there's a dependency that isn't mentioned 16:39:28 <CIA-2> OpenTTD: rubidium * r20614 /extra/catcodec/ (27 files in 3 dirs): [catcodec] -Change: make the layout look more like GRFCodec and NFORenum's layout; installation and such works in a similar way as well 16:40:51 <roboboy> does catcodec only produce sample.cat like .cats, or could it theoretically be used for creating .cats that contain the DOS music if it's format is ever cracked? 16:42:09 <Rubidium> it only supports the sample like cats 16:42:12 <Noldo> oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööö 16:42:40 <Rubidium> and actually, I don't think it writes TTDP acceptable cats 16:43:07 <roboboy> hm 16:43:23 * roboboy tries the OpenSFX .cat in TTDP 16:45:34 *** Lakie [~Lakie@91.84.251.149] has joined #openttd 16:45:45 <CIA-2> OpenTTD: rubidium * r20615 /extra/catcodec/ (Makefile.bundle changelog.txt findversion.sh): [catcodec] -Add: a changelog 16:46:22 <roboboy> TTDPatch crashed 16:46:40 <roboboy> what's special about catcodec cats? 16:47:01 <Gremnon> perhaps a better question would be what's special about TTD(P) cats 16:47:19 <roboboy> no 16:47:50 <roboboy> or from what ive read catcodec produces special cats so hacks in OpenTTD work 16:48:15 <planetmaker> roboboy, it has a slightly different internal format 16:48:19 <Ammler> it is better quality afaik 16:49:00 <planetmaker> And OpenTTD somehow knows how to distinguish old and new cat format 16:49:30 <Rubidium> Gremnon: besides that TTD(P) cats say they have samples played at X Hz with Y bits per sample when that information is ignored and always 11025Hz 8bps is used? 16:49:54 <Rubidium> and the "corrupt" sound that doesn't even have a proper WAV header? 16:50:46 <Rubidium> over the "new" cat format that always has a proper WAV header and where OpenTTD obeys the X Hz and Y bits per sample in the .cat instead of overriding it itself 16:52:05 <Rubidium> and as a side effect OpenSFX's samples have higher Hz and higher bps, so basically (potentially) higher quality 16:52:51 <Gremnon> hmm, I see 16:53:46 <Gremnon> so no way to add TTDP compatibility then 16:54:13 <planetmaker> oh, you could write a converter ;-) 16:54:44 <Rubidium> planetmaker: you mean one that downsamples the songs and removes the WAV header from the Nth song? 16:54:44 <roboboy> can catcodec decode? 16:55:10 <planetmaker> Rubidium, exactly ;-) 16:55:13 <Rubidium> roboboy: yes, but decode original sample.cat + encode that != original sample.cat. For OpenSFX it should hold though 16:55:55 <roboboy> so I could try and decode OpenSFX.cat and recode it with decat 16:56:02 <roboboy> http://www.ttdpatch.net/chris_becke_ttdlx.html 16:56:25 <Gremnon> theory - is it possible to have a parameter to pass to the encoder part of catcodec that would attempt to make it a TTDP compatible cat, or would that not work? 16:57:28 <planetmaker> roboboy, does "decat" allow re-encoding? 16:57:54 <roboboy> I think it does 16:58:11 <planetmaker> description only talks about decoding ;-) 16:58:59 <roboboy> yeah 16:59:49 <roboboy> I think I read about a tool or I could try and write myself one if I was so inclined 17:01:33 <roboboy> well gmorning as I need to go to sleep 17:02:32 <Rubidium> ofcourse it's possible to add such a parameter, but I'm never going to do that as it's simply too much work for way too little benefit 17:02:58 <Gremnon> I wasn't implying it should be added, just wanted to know if it could be aded 17:04:06 <Rubidium> it "just" requires downsampling the WAVs and not putting the WAV header of one of the files in 17:04:15 *** frosch123 [~frosch@frnk-590ff702.pool.mediaWays.net] has joined #openttd 17:05:22 <Gremnon> ah 17:05:28 <Gremnon> now I see just how much for too little 17:08:15 <planetmaker> quak :-) 17:09:27 <frosch123> moin :) 17:09:44 * dihedral pets the duck 17:09:50 <Rubidium> kwaaaaaaaaaaaaaaak 17:10:37 * dihedral pets another duck 17:11:06 <Gremnon> quack! 17:11:06 * Gremnon bites the hand that pets him 17:11:33 <dihedral> ducks cannot bite 17:11:54 <Gremnon> I'm just a wolf in very heavy disguies as a duck 17:12:27 <dihedral> fat duck i'd say 17:12:40 <CIA-2> OpenTTD: glx * r20616 /trunk/projects/ (6 files): -Change: disable .sbr/.bsc generation in MSVC project files 17:12:49 <Gremnon> you just need to have your eyes tested if you can't tell the difference 17:12:56 <Gremnon> the other ducks don't seem to have noticed 17:12:59 <Gremnon> (yet) 17:13:00 *** DDR [~DDR@d142-179-74-59.bchsia.telus.net] has joined #openttd 17:14:15 *** HerzogDeXtEr1 [~Flex@88.130.173.252] has quit [Read error: Connection reset by peer] 17:16:27 <frosch123> frogs have teeth, just ask Grover 17:18:08 <dihedral> http://www.break.com/pictures/queen-of-vuvuzelas1903906.html :-D 17:18:42 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has quit [Remote host closed the connection] 17:19:21 <yorick> dihedral: not currently 17:19:40 <dihedral> ok, thanks for the feedback :-) 17:21:28 *** nicfer [~nicfer@190.50.49.55] has quit [Read error: Connection reset by peer] 17:36:01 *** jonty-comp [~jonty@2a02:1680:0:1:2:1:1:6e01] has joined #openttd 17:37:36 *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has quit [Ping timeout: 480 seconds] 17:41:45 <VVG> http://imagebin.ca/view/eJc_uY.html 17:42:10 <VVG> There is a "default station" list item, which i can't select at all. In this game, i did add some station grf midgame. 17:42:45 *** perk11 [~perk11@94.233.249.111] has joined #openttd 17:43:15 <dihedral> adding grf in the middle of the game is not supported as far as i know 17:43:48 <VVG> yeah, i know 17:44:11 <Gremnon> by the image, that's MB's newstations... which I recall sometimes does that even before the game, there's a 'default station' tile at the end of the list for me, also unselectable 17:44:24 <Gremnon> I think it might be caused by loading multiple station grfs, but not certain 17:44:34 <VVG> them exactly 17:44:47 <planetmaker> VVG, if you load too many station sets, the default station category gets flooded with the excess stations 17:44:59 <planetmaker> Except if you have a very recent nightly 17:45:07 <Gremnon> or Chillcore's patchpack 17:45:13 <VVG> i have a bunch of them, preloaded from start, later midgame i noticed i lack void platforms, so i added them 17:45:31 <Gremnon> but this isn't the default station category getting flooded, this is the default station from the default station category appearing where it shouldn't 17:45:41 <Gremnon> as well as where it should 17:45:44 <CIA-2> OpenTTD: translators * r20617 /trunk/src/lang/ (9 files): (log message trimmed) 17:45:44 <CIA-2> OpenTTD: -Update from WebTranslator v3.0: 17:45:44 <CIA-2> OpenTTD: belarusian - 2 changes by KorneySan, Wowanxm 17:45:44 <CIA-2> OpenTTD: finnish - 2 changes by jpx_ 17:45:44 <CIA-2> OpenTTD: german - 2 changes by planetmaker 17:45:46 <CIA-2> OpenTTD: greek - 2 changes by fumantsu 17:45:46 <CIA-2> OpenTTD: hungarian - 1 changes by IPG 17:45:53 <VVG> thing is, it's not that it is flooded 17:46:01 <VVG> it's an item, that can't be selected 17:46:17 <VVG> the selecatable defaul station item is up there in the list, working 17:47:11 <VVG> so, in the end, two defaul station items, one properly working, one just occuping a line :) 17:47:16 *** DDR_ [~DDR@d142-179-74-59.bchsia.telus.net] has joined #openttd 17:48:08 <VVG> does the station list has to be made before the start of the game with this "very recent nightly" or it will be ok with older save games? 17:48:19 *** devilsadvocate [~devilsadv@202.3.77.41] has joined #openttd 17:48:43 <Gremnon> AFAIK, nightlies are always backward compatible with previous nightlies and stables except in rare cases 17:50:10 <Gremnon> if you're still not sure, get a nightly, and run it separate from your current version, or keep a backup just in case 17:50:45 <VVG> doing that right now 17:51:02 <VVG> but i didn't meant save game as a whole, just a station list 17:51:59 <VVG> save game was made some time ago with trunk, my custom 20612 build still have that void defaul station item if i load that save game. And while this build shouldn't have anything to do with station lists, i'm compiling clean trunk now to check it 17:52:14 <Gremnon> just done that for you 17:52:36 <Gremnon> with no other newGRFs loaded, I get 'Default Station' at the bottom of the 'Station Building (small) category 17:53:34 *** DDR [~DDR@d142-179-74-59.bchsia.telus.net] has quit [Ping timeout: 480 seconds] 17:53:35 * Gremnon smells a bug 17:53:38 *** Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has joined #openttd 17:53:46 <Gremnon> whether it's in MB's new stations or openttd though is another matter 17:54:31 <VVG> looks like grf's fault, start new game with just mbs, there is unselectable default station item 17:54:58 <planetmaker> well. Maybe it's still that the grf is incorrectly interpreted 17:55:15 <Gremnon> it could be the way openttd handles the grf, I've known some times when it's been a bit iffy where TTDP works fine, and vice versa 17:55:39 <planetmaker> :-) that happens when there are two implementation of the same specs 17:56:11 <Gremnon> so you think it could be openttd's handling of the grf, and not the grf itself? 17:56:38 <Rubidium> well, start by running the NewGRF's nfo through nforenum 17:57:42 <VVG> except for MB's newstations, are there station grf with platforms, that look like default grass? 18:00:10 <Gremnon> nforenum throws up quite a collection of warnings... haven't looked at said warnings yet though 18:00:53 <VVG> Haha, just noticed there is Museum of moder arts building in ttrs, greatest ttd build i have seen :) 18:01:18 <Gremnon> looking at the warnings, I'm going to go with it being an issue on the grf's part 18:02:00 *** ajmiles [~aj@78-86-188-187.zone2.bethere.co.uk] has joined #openttd 18:02:19 *** TheMask96 [martijn@sirius.ne2000.nl] has quit [Ping timeout: 480 seconds] 18:09:14 *** TheMask96 [martijn@lust.vhost.ne2000.nl] has joined #openttd 18:19:02 *** |Jeroen| [~jeroen@94-224-23-216.access.telenet.be] has joined #openttd 18:43:53 *** Mucht [~Martin@chello084115143107.3.graz.surfer.at] has joined #openttd 18:44:09 *** IPG [~chatzilla@dsl51B655BD.pool.t-online.hu] has joined #openttd 18:45:59 <Gremnon> I know a developer at one point said that OpenTTD wasn't going to support threading... but was any attempt ever made at it? 18:46:36 <Rubidium> yes, 5% faster on multicore, 10% slower on single core (or something like that) 18:46:57 <Rubidium> and that was *without* proper locking, so it wasn't multiplayer safe 18:47:52 <Gremnon> ah, I see... that leaves me with another question though... on win-vista on my laptop, which is dual-core, it somehow at least appears to use both cores when openttd is running 18:48:08 <Gremnon> yet while the same computer uses Arch, it doesn't do this, and I can't understand why Vista is doing it, or how 18:48:19 <Gremnon> both using clean trunk, in case it matters 18:49:10 <Rubidium> how does it appear to be using multiple cores? 18:49:43 <Rubidium> autosave definitely benefits from the second core 18:49:52 <Gremnon> I've got an applet on the vista sidebar that shows me the usage on both cores separately, with nothing else running, they both average 2% usage on each. Start OpenTTD and leave it on the title screen, and both cores go up to ~80% 18:50:06 <Gremnon> close it and they both go back down again 18:50:36 <Gremnon> at the very least, it seems to be using both, if there was less usage on one core, I'd just put it down to everything else being shifted to that core to make room for OpenTTD on the other 18:50:40 <Rubidium> might be that Windows does something fancy with its video driver 18:51:15 <Rubidium> like when OpenTTD put its graphics stuff there it'll quickly make a copy and then on the other core it actually draws it to the video card 18:51:40 <Gremnon> if both Arch and Windows are using the exact same version of their driver, shouldn't both be able to do it? 18:51:50 <Rubidium> also sound and music seem to be running in a different thread, so they could run on another core as well 18:52:12 <Rubidium> Gremnon: they can't be using the exact same version 18:52:14 <Gremnon> hmm, I see... so it could just be Windows shifting those parts that can be shifted, to the other core 18:52:31 <Gremnon> I'm fairly sure they show the same version number, that's what I meant 18:53:02 <Rubidium> ATI driver? 18:53:08 <Gremnon> Nvidia 18:53:22 <Rubidium> maybe they have a year-month version numbering as well 18:54:07 <Gremnon> I can check it, I'd have to go reboot into Win to do so, and see if I'm right about the versions, but even then, if both are using the nvidia driver, and it's that driver doing it, shouldn't both be able to? 18:54:14 <Gremnon> unless it's Windows that's actually doing it 18:54:34 <Rubidium> the API of Linux and Windows is so different they simply can't be the same driver 18:54:45 *** Chillosophy [~fu@82-170-139-109.ip.telfort.nl] has joined #openttd 18:54:48 <Gremnon> now I think I see another reason why multithreading isn't so simple... I'm starting to get confused 18:55:47 <Gremnon> I think I'm just going to leave it alone, maybe it won't run so well on linux, but better that, than open this can of worms, methinks 18:56:51 <Rubidium> Gremnon: did you fastforward when testing this? 18:56:57 <Rubidium> or just normal gameplay? 18:57:17 <Gremnon> just normal gameplay, I almost never use fastforward at all 18:57:18 <Rubidium> because if you didn't fast forward, then Linux is better as it's using way less CPU 18:57:44 <Rubidium> using 2 cores at 80% vs 1 core at (maybe?) 100% 18:58:15 <Gremnon> aye, I noticed that, but to get that to happen for me, I have to run it windowed at 800x600, on Windows because of whatever fancy thing it does, I can run it windows, but maximized to the available screen (which is about 1440x900) 18:58:36 *** Fast2 [~Fast2@p57AF8573.dip0.t-ipconnect.de] has joined #openttd 18:59:12 <Gremnon> I don't run it proper fullscreen on either, because I usually have other stuff going, but I can definitely get it maximized with only a minimal impact on Windows 18:59:24 <Gremnon> give me a moment, and I'll give you the CPU usage on Linux 19:01:19 <Gremnon> most of the load is actually on the xorg process instead of openttd itself, confirming that the video stuff is where it's probably happening, and it uses ~85-98% of one core only 19:03:03 <CIA-2> OpenTTD: rubidium * r20618 /trunk/src/main_gui.cpp: -Fix [FS#4081]: drawing the "OpenTTD" text in the intro game caused crashes with very low resolutions 19:05:46 <CIA-2> OpenTTD: rubidium * r20619 /trunk/src/video/cocoa/ (wnd_quartz.mm wnd_quickdraw.mm): -Fix [FS#4070]: [OSX] Limit minimum window size to 64x64 like all other platforms (matheweis) 19:06:30 <planetmaker> :-O 19:06:46 *** |Jeroen| [~jeroen@94-224-23-216.access.telenet.be] has quit [Quit: oO] 19:09:23 * Rubidium wonders when the next flame comes that I'm frustrating Mac OS X packagers 19:10:32 <Gremnon> I considered getting a mac once. It was about two days before OpenTTD stopped being officially supported for it. I stopped considering it at the same time 19:11:03 <Gremnon> If all of the OS I use can't do the same things in one way or another, I don't like it, it means rebooting from one to the other too much 19:11:49 * Rubidium doesn't have such good price-quality experience with Macs 19:12:24 <Rubidium> my brother has had 2 Macs and both had problems with some inverter or something. In any case, the (LCD) screen was flickering 19:12:26 <Gremnon> aye, I heard that about them too. like most apple things, they seem to be designed to look nice, not work well... 19:13:15 <Gremnon> once or twice I've considered creating a 'hackintosh' despite it's... dubious legality, to say the least. At least it doesn't cost, but it's always been it's legality that's put me off 19:13:21 <Rubidium> and if there's one thing I can't stand it's flickering screens. Give me a badly configured CRT and I'll be having headaches + vomit sessions for the next few hours 19:13:50 <Gremnon> which is odd, since I'll readily admit I pirate music because I'm often too skint to pay for it, and can't be bothered to make the trek into the neighbouring town just to buy an album I onlt want track from 19:13:57 <Gremnon> ah, yep, I know that one too 19:14:17 <Gremnon> try going between three screens, one at 50, one at 60 and one at 70hz 19:14:23 <Gremnon> (or whatever it is instead of hz) 19:14:31 <Gremnon> guaranteed to make you feel at least queasy 19:18:18 <Rubidium> and the cheapest Mac with my preferred (laptop) screen resolution is 2 inches bigger than the one I've got now, twice as expensive. That Mac has 200 GiB more HDD though (only using 50% of my current HDD, which has two full copies of previous installs including homedirs with openttd checkouts and such) 19:19:00 <Rubidium> (1.1 GiB for ~/.openttd, 5.5 for ~/openttd) 19:19:08 <VVG> The weight multiplier setting - does it affect all cargoes? Or are pax/mail an exception? 19:19:33 <frosch123> only freight 19:22:01 <frosch123> and yes, by default only passenger and mail are not freight 19:22:59 <VVG> Is there some special bit in newgrfs to set a particular cargo to freight/not freight? 19:23:08 <frosch123> yes, there is some property 19:24:57 <Gremnon> I manage to make do with a small 80gb hard drive when dual-booting, and I've made do with smaller before by tidying up regularly 19:24:59 <VVG> thanks 19:25:05 <Gremnon> but to each their own 19:31:03 <planetmaker> http://www.tt-forums.net/viewtopic.php?f=33&t=49830 <-- :-O 19:31:16 <planetmaker> someone really made some optimization runs it seems 19:32:16 <Gremnon> I noticed that too 19:32:19 <Gremnon> I'm just trying it out now 19:32:23 <andythenorth> Rubidium: why are you even looking at Mac prices? :P 19:32:49 <Gremnon> I thought I'd apply the first two against Chillcore's patch pack... the second doesn't apply, but the first does, so I'm trying that 19:32:52 <Rubidium> andythenorth: because I was doing a general search into 1920x1200 screen size laptops 19:33:38 <planetmaker> hm... links don't work for me :-( 19:33:47 *** KritiK [~Maxim@89-178-113-11.broadband.corbina.ru] has joined #openttd 19:33:52 <Gremnon> I just used the attached patches 19:34:04 <Gremnon> I didn't bother with the third 19:36:03 <Rubidium> the first mostly looks like stupid compiler... it should just fracking inline those things because we said it should do so 19:36:21 <Gremnon> apparently it doesn't then 19:39:29 * Rubidium wonders whether it actually compiles 19:39:44 <Rubidium> +if (not stationAndRadius.Intersects(location)){ <- that looks suspicious 19:39:59 <dihedral> not? :-P 19:40:03 <Gremnon> the first patch against chillcore's patchpack, with the matching trunk revision, compiles 19:40:10 <Gremnon> I haven't tried the first and second against trunk yet 19:40:21 <Alberth> does the new C++ standard not introduce 'and' for && etc ? 19:40:39 <dihedral> that would be nasty 19:40:48 <dihedral> and replace ( and ) with , ? 19:40:51 <SmatZ> Alberth: it does 19:41:02 <SmatZ> and or bitor bitand ... and now keywords :-p 19:41:05 <dihedral> and } with . 19:41:11 <dihedral> if, not funny, go home. 19:41:30 <SmatZ> sorry, Alberth :) 19:41:35 <SmatZ> I thought you were asking 19:41:59 <Rubidium> what C++ spec does add that? 19:42:45 <Alberth> oh, perhaps it is C99 19:44:00 <Gremnon> well, they seem to have applied almost cleanly against trunk, the second one just needed to be told to apply anyway, and it worked, now to see if it compiles 19:44:38 <Alberth> SmatZ: it was both a remark and a question :) 19:48:54 <Gremnon> compiling seems to have taken considerably longer, but there are no warnings, and it's compiled sucessfuly 19:52:07 <SmatZ> $ g++-4.6.0-pre9999 tstX.c -std=c89 19:52:08 <SmatZ> cc1plus: warning: command line option "-std=c89" is valid for C/ObjC but not for C++ [enabled by default] 19:52:13 <SmatZ> now what have I broken... 19:52:23 <SmatZ> why does it think it's a C++ file? 19:52:25 <SmatZ> :( 19:52:43 * SmatZ slaps SmatZ 19:52:50 <SmatZ> g++ instead of gcc 19:53:37 <SmatZ> Alberth: anyway, gcc -std=c99 doesn't accept "bitand", but it is accepted in C++98 mode 19:53:59 <SmatZ> either gcc is wrong, or it was already part of the "old" C++ standard... 19:54:12 <Gremnon> hmm, running unmodified openttd with 'time' and a build patched with those two performance ones does seem to have made an increase, but it's negligible - left on the title screen for 30 second each, there's less than 0.2s difference 19:54:47 * Gremnon wonders if the patches are really all that useful overall 19:54:56 <SmatZ> Gremnon: so do I :) 19:55:00 <Eddi|zuHause> "It might have been easier to fuly use your CPU in 1995, but then you generally wouldn't hit that limit until you're pretty far into the game anyway." <-- i first played TT on a 386DX25, and i hit the limit at about 5-10 trains. when i hit the train limit of 80 in the next 10 game years, game was hardly progressing at all... 19:55:07 <Rubidium> Gremnon: with music, video and sound enabled I reckon :) 19:55:40 <SmatZ> there is one strange thing in his benchmarking 19:55:42 <SmatZ> openttd -x -v null:ticks=10000 -s null -m null -g [SavegameName] 19:55:51 <SmatZ> he says he runs the game for 10000 ticks 19:55:54 <Gremnon> true... I'll try playing a game for a bit on the build of chillcore's pack where I added the first one in, and see if it differs 19:55:58 <SmatZ> and is finished in <2 minutes 19:55:59 <Eddi|zuHause> unfortunately, i lost that first savegame, due to the world editor overwriting it with the autosave :( 19:56:41 <Gremnon> probably not, but even so, maybe long-term usage under normal use situation will show some difference 19:56:43 <Alberth> SmatZ: I have a very thick book at work that should contain the answer. If I remember, I'll have a look. 19:57:02 <SmatZ> it that's true, then "1024x1024 map with huge cities and lots of trains:" isn't really "lots of trains" 19:57:15 <SmatZ> Alberth: thanks, it's probably not needed :) 19:59:30 <Rubidium> I count ~700 trains in that savegame 20:00:08 <Rubidium> roughly 300 stations 20:00:11 <SmatZ> or his CPU is much more powerful than mine :) 20:00:15 <SmatZ> which might be true... 20:01:13 <Rubidium> ~800 RVs 20:01:23 <Rubidium> ~100 ships 20:01:49 <Rubidium> still wonder whether he tested with or without exceptions 20:01:50 <Eddi|zuHause> that does sound like a lot ;) 20:02:08 <Eddi|zuHause> you mean asserts? 20:02:13 <Rubidium> yes 20:05:30 <Rubidium> real 2m9.767s <- that's how long 10k ticks of 1024x1024 takes for me (non debug, with asserts) 20:06:12 <Rubidium> @calc 7947339048/2830000000 20:06:12 <DorpsGek> Rubidium: 2.80824701343 20:06:41 <Gremnon> doesn't really seem like enough to make it worth it to me 20:09:25 <Rubidium> 1:58 without assertions 20:09:36 <Rubidium> @calc 118/129 20:09:36 <DorpsGek> Rubidium: 0.914728682171 20:10:14 <Rubidium> so OpenTTD's 8% faster without assertions :) 20:15:56 <Rubidium> real 1m39.918s without assertions, with patch 20:16:08 <SmatZ> nice :) 20:16:08 <Rubidium> @calc 99/118 20:16:09 <DorpsGek> Rubidium: 0.838983050847 20:16:20 <Rubidium> that's quite a serious amount 20:16:33 <SmatZ> yup 20:17:04 <SmatZ> load average: 15.75, 15.76, 12.77 20:17:14 <planetmaker> :-P 20:17:15 <SmatZ> I will do some testing when the system is not under load :) 20:18:05 <dihedral> i found Sacro: http://www.break.com/pictures/wheres-pedobear!!!1900053.html 20:19:22 <SmatZ> p 20:19:22 <Sacro> ? 20:19:30 <Sacro> wtf 20:19:44 <planetmaker> ... 20:19:48 <dihedral> sorry - just needed some odd remark :-P 20:25:22 <Rubidium> 2048x2048 populated from 52 -> 25 20:25:36 <planetmaker> :-O 20:25:56 <planetmaker> sounds like a useful patch then 20:26:39 <Rubidium> 2kx2k map with a gazillion towns and not much else 20:26:52 <planetmaker> well 20:26:57 <planetmaker> both patches or only one? 20:27:32 <Rubidium> both 20:28:23 *** perk111 [~perk11@178.34.182.32] has joined #openttd 20:28:43 <Rubidium> fewer towns: 43 -> 40 20:28:50 <Rubidium> still ~10% 20:28:55 *** Gremnon [~gremnon@87.113.141.166] has quit [Quit: Leaving] 20:29:23 <Terkhen> wow :) 20:29:53 <Rubidium> though the latter two are more the hypothetical kind I'd say 20:30:11 * Rubidium gets his "friends" 20:30:31 *** IPG [~chatzilla@dsl51B655BD.pool.t-online.hu] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716]] 20:30:54 <Rubidium> pile: 40 -> 36.5 20:31:14 <Eddi|zuHause> that's also ~10% 20:33:12 *** Sacro1 [~Sacro@adsl-87-102-115-110.karoo.KCOM.COM] has joined #openttd 20:33:43 <planetmaker> psgs 101, 180 and 186 might be interesting, too 20:33:48 *** perk11 [~perk11@94.233.249.111] has quit [Ping timeout: 480 seconds] 20:33:57 <Rubidium> oh, got PSG 132 now 20:35:27 <planetmaker> psg #180 is 3k trains 20:35:31 <planetmaker> on a logic network 20:36:00 *** Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has left #openttd [] 20:36:45 <Rubidium> trains won't matter that much; this primarily focusses on map accesses and cargo -> station stuff 20:36:54 <SmatZ> hmm 20:37:34 <planetmaker> then use psg101. 20:37:49 <planetmaker> there we have a 200k single cargo output record ;-) 20:37:57 <SmatZ> I used to have patch that cached all stations nearby for town/industry 20:38:02 <planetmaker> *cargo type 20:38:02 <SmatZ> but I can't find it anymore 20:38:11 <SmatZ> it would be interesting to compare those two patches 20:38:25 *** TomyLobo [~foo@port-212-202-171-176.dynamic.qsc.de] has joined #openttd 20:38:26 <planetmaker> oh, sorry. wrong. that's proZone game 13 20:38:55 <planetmaker> http://wiki.openttdcoop.org/ProZone:Archive_-_Games_11_-_20#gameid_13 20:39:21 <planetmaker> psg101 is many pax trains. 20:39:23 *** fonsinchen [~fonsinche@brln-4dbaad5c.pool.mediaWays.net] has joined #openttd 20:39:31 <planetmaker> in 4 towns covering the whole map. 20:39:36 <Rubidium> 132: 2:04 -> 2:03 20:39:41 <planetmaker> That will have lots of station accesses in many places 20:39:48 <planetmaker> that's little gain 20:39:50 *** Sacro [~Sacro@adsl-87-102-115-110.karoo.KCOM.COM] has quit [Ping timeout: 480 seconds] 20:40:04 <Eddi|zuHause> but at least no slowdown yet 20:40:36 <planetmaker> nope 20:42:46 <Eddi|zuHause> so three questions now: 1) is the implementation "correct", as in doesn't change gameplay? 2) is the style ok? 3) does this reduce maintainability or old compiler compatibility? 20:43:38 <SmatZ> Eddi|zuHause: 1) hope so :) 2) no, but it can be changed 3) in most cases, caching makes maintainability harder... 20:44:27 <Eddi|zuHause> well, 1) is also often a case of "how does it behave when someone joins the game, and the cache is not rebuilt simultaneously on the server and client? 20:44:38 <Eddi|zuHause> yapf cache had lots of problems witht hat 20:46:36 <Rubidium> 90: 1:12 -> 1:10.5 20:48:10 <planetmaker> :-) 20:50:34 <Rubidium> PSG96 is quite slow: 3:32 (same amount of ticks over 90 and 132) 20:50:39 <Rubidium> still waiting on the patched version 20:51:56 <Rubidium> if it's a cache it shouldn't be rebuilt upon joining; it should represent the "real" state correctly, but (much) faster 20:53:58 <Eddi|zuHause> i think the problem with YAPF cache was that it depended on the order of things being added 20:54:18 <Rubidium> oh... 3:33 for the patched version 20:54:39 <Rubidium> lets run that agin 20:54:39 <Eddi|zuHause> so the state differed between a slowly builtup cache, and a rebuilt cache 20:57:20 <Rubidium> now it's 1:06 vs 1:04 20:57:40 <planetmaker> uh? cache vs. not cache? 20:57:41 <Eddi|zuHause> i'd put that off as statistical variaton... 20:58:00 <Rubidium> planetmaker: unpatched vs patched 20:58:15 <planetmaker> yes but compared to 3:33 before? 20:58:49 <planetmaker> or 'just' another game? 20:59:01 <Rubidium> same game, 70% less ticks 20:59:27 <planetmaker> ah 20:59:46 <planetmaker> hm, psg#96 has many stations in many places indeed 20:59:52 <Eddi|zuHause> sounds like most of the time is spent in other parts of the code 20:59:57 <planetmaker> but the map is not really big 21:00:11 <Eddi|zuHause> like, pathfinder or acceleration 21:00:14 <planetmaker> Eddi|zuHause: that game has somewhat a grid of stations 21:00:24 <planetmaker> three big towns, each with a local network 21:00:34 <planetmaker> ice running between those towns' central stations 21:00:52 *** TruePikachu [~chris@cpe-67-49-42-88.socal.res.rr.com] has joined #openttd 21:00:59 <planetmaker> acceleration will matter there, sure 21:01:29 *** Chillosophy [~fu@82-170-139-109.ip.telfort.nl] has quit [] 21:01:43 <Eddi|zuHause> if path_backoff_intervall [or so] is low, a deadlock can kill the game 21:02:02 <Rubidium> Eddi|zuHause: true, though I'd expect a slightly bigger different; it's all 1 or 2 seconds in these (NewGRF) PSG savegames 21:02:14 <Rubidium> agains 4 seconds for a pre NewGRF PS savegame 21:02:19 <planetmaker> that is usually set to 1 21:02:36 <Eddi|zuHause> isn't the default like 30 or so? 21:02:50 <planetmaker> (the back-off interval) Yes, usually it's much higher 21:02:57 <Ammler> the logic excess is the only game, we found effect on changing that :-) 21:03:06 <planetmaker> or maybe it's 0. We don't want trains to turn 21:03:18 <Eddi|zuHause> that's a different setting 21:03:33 <Eddi|zuHause> backoff_interval is for retrying to reserve a path, when reserving a path failed 21:03:41 <Belugas> nightr all 21:04:04 <planetmaker> then it's 1. 21:04:27 <planetmaker> and I recalled correctly the setting but not its meaning ;-) 21:05:35 <Eddi|zuHause> i rembember the old PBS... i had ~100 trains, and every time a deadlock occured on a part of the network, the game got notably slower 21:05:57 *** Adambean [AdamR@82.hosts.reece-eu.net] has quit [Quit: Gone fishing] 21:06:47 <Eddi|zuHause> that was before a yapf-compatible pbs version appeared 21:06:57 <planetmaker> yes. But jams are more likely also, if trains slow down due to not having yet reserved a path :-) 21:07:03 <planetmaker> That's why we set it to a low value 21:07:28 <planetmaker> For heavy-duty lines the default value is a notable slow-down 21:07:45 <Eddi|zuHause> might be 21:08:06 <planetmaker> But by default we don't use much path signals 21:08:15 <planetmaker> only in some junctions and station entries 21:08:29 <planetmaker> so it's not a big issue on the PublicServer 21:08:36 <planetmaker> s/much/many/ 21:09:02 <Eddi|zuHause> "a lot of" ... saves most of the trouble ;) 21:09:30 <planetmaker> :-) 21:09:50 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has joined #openttd 21:15:00 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has quit [Remote host closed the connection] 21:15:06 <VVG> http://pastebin.ca/1925352 Does this piece of code look ok for rounding? 21:16:23 * andythenorth likes the 'found a town' feature :) 21:16:43 <TruePikachu> How does it work? I've never used it 21:17:00 <andythenorth> I don't know yet, I don't have enough money :( 21:17:02 * TruePikachu has never had enough money and the need to use it at the same time :( 21:17:22 <andythenorth> it would be nice if the game would occasionally found a town 21:17:33 <andythenorth> specifically, if it seeded them near busy transfer stations 21:17:37 <TruePikachu> I am especially interested in the 'custom layout' option; I'll look at source to try to decypher the operation 21:17:52 <TruePikachu> andythenorth: It would overflow eventually then 21:18:07 <andythenorth> I want all my grain elevator stations to get a little 2 horse town next to them :P 21:18:20 <TruePikachu> That's why you can found towns 21:18:30 <planetmaker> ;-) yet another adv. setting 21:19:00 * TruePikachu is also glad that Rubidium is getting along with me - FS#4080 21:19:30 <andythenorth> is there a good AI for running simple bus routes? I can't be bothered 21:19:42 <andythenorth> I need to grow towns... 21:19:46 <Ammler> CABsomething? 21:20:04 <Ammler> or Admiral iirc 21:20:43 * TruePikachu just accidentially discovered ^A in vim 21:20:54 <Ammler> I guess, I never played with AIs since noai is in trunk :-) 21:20:58 <planetmaker> NoCAB 21:21:02 <TruePikachu> andythenorth: SimpleAI, but it is an idiot and does more than that 21:21:07 <planetmaker> CluelessPlus 21:21:21 <planetmaker> both will spam you with bus routes 21:22:06 *** wollollo [~martin@host86-175-29-209.wlms-broadband.com] has quit [Quit: leaving] 21:23:06 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has joined #openttd 21:24:30 <TruePikachu> According to file "town_gui.cpp" lines 1046-1051, when founding a town, you can select size, layout (grid style), if it is a city, etc. just like in scenerio editor - I am not sure if this is the same window as called in-game 21:25:54 <TruePikachu> ShowFoundTownWindow() says it is the same window, though 21:26:11 <Rubidium> VVG: I doubt the TTU_HHMMSS rounding factor is right 21:27:09 <Rubidium> and N seconds are one tick, time_taken is in ticks, so if N = 4, you'd round to the nearest 16 seconds 21:27:23 <Rubidium> instead of the nearest 4 seconds 21:29:52 <TruePikachu> Are lines 256 and 257 in osk_gui.cpp fully customizable to no ill effects? 21:30:32 <TruePikachu> I may have to adjust it to help with the OttdKiosk project 21:32:42 <TruePikachu> Umm...never mind, won't adjust height, which is also important :( 21:32:53 *** wollollo [~martin@host86-175-29-209.wlms-broadband.com] has joined #openttd 21:33:51 *** KouDy [~koudy@ip-89-176-216-203.net.upcbroadband.cz] has quit [Ping timeout: 480 seconds] 21:37:31 <VVG> Rubidium: So, i can just use 1 for HHMMSS case and just let the gui time conversion do its job? 21:38:33 <Rubidium> yes; ticks aren't fractions 21:39:07 <TruePikachu> Would it ever be possible to have multiple airports allocated to the same station? 21:40:46 <VVG> may be it's better to use rounding only in case of days or HHMM? and just time_taken = time_taken if it's ticks or seconds? 21:42:17 <Rubidium> yep 21:43:05 <Rubidium> basically you've got second < tick < minute < day 21:43:45 <Eddi|zuHause> TruePikachu: it's not beyond technical practicability, but i have seen no attempts to implement that 21:43:54 <Rubidium> or in numbers, when N = vsec: 1/N < 1 < 60/N < 74 21:44:55 <TruePikachu> Hmmm...I'll put it into the FS 21:46:45 *** AnodA [~AnodA@95-90-0-250-dynip.superkabel.de] has quit [Quit: oO] 21:47:05 <VVG> what will be the result of 1/N in case of ints? 21:49:25 <Rubidium> 0 21:50:14 <Rubidium> but anyhow, if you have N=4 and 12:00:00, then there won't be a 12:00:01,02,03. The next will be 12:00:04 21:52:21 <VVG> from game playing point of view, 1tick=4 sec doesn't seem feasable, it goes by too fast 21:52:41 <VVG> http://pastebin.ca/1925387 compiling that now 21:57:17 <Eddi|zuHause> i always had 1tick=1second, but on small maps, that might be a different thing 21:57:22 <VVG> btw, from ottd coding style point of view, is using enum TTU_DAYS-TTU_HHMMS a good thing? 21:58:52 * Rubidium doesn't get that 21:59:09 <Eddi|zuHause> what do you mean? like grouping several related constants into an enum? 21:59:27 *** frosch123 [~frosch@frnk-590ff702.pool.mediaWays.net] has quit [Remote host closed the connection] 22:01:11 <VVG> enum TimetableUnit with those values is the only one enum in settings_type.h. It does makes reading code much easier for me. But i wondered, if it is proper to use such enum just for making reading the code easier? It is possible to use some comment in the code where switch is used 22:04:09 *** bryjen [~bryjen@63.147.94.149] has quit [Quit: Quit] 22:06:05 *** nicfer [~nicfer@190.50.49.55] has joined #openttd 22:07:17 <VVG> in other words, adding simple comment in the code renders this enum useless 22:07:47 * TruePikachu will play a game from 1830 to 2050 22:08:02 <TruePikachu> 220 years O_o 22:09:03 <TruePikachu> 1 tick is hardcoded as 30ms, correct? 22:09:51 *** Phoenix_the_II [ralph@f234099.upc-f.chello.nl] has quit [Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )] 22:09:52 <Rubidium> enums are better than comments for e.g. switch statements because the compiler is basically "spellchecking" whether you've written it the same everywhere 22:10:22 <Rubidium> whereas with comments you can much more easily make typos and as such you might not be able to find stuff back again 22:10:49 <Rubidium> likewise when it is an enum it's easier to rename or change the value 22:11:02 <TruePikachu> My game will take at least 49 hours 33 minuts 4.29 seconds O_o 22:11:24 <VVG> kinda got it, enum in this case is a good thing :) 22:11:53 <TruePikachu> About a week 22:17:31 *** Kurimus [Kurimus@dsl-tkubrasgw1-fe34dc00-202.dhcp.inet.fi] has quit [] 22:17:50 *** [hta]specx [~opera@ip94-126-210-87.adsl2.static.versatel.nl] has joined #openttd 22:19:28 <TruePikachu> Lol, no trains yet here in 1830 22:20:10 <TruePikachu> I will do intra-city operations until the trains are availible 22:20:34 <TruePikachu> Should take up to 18 months 22:20:42 <Terkhen> good night 22:20:57 <TruePikachu> Night 2 you 22:23:14 *** Goulpy [~Muxy@main.goulp.net] has joined #openttd 22:23:31 *** fonsinchen [~fonsinche@brln-4dbaad5c.pool.mediaWays.net] has quit [Remote host closed the connection] 22:30:14 *** Muxy [~Muxy@main.goulp.net] has quit [Ping timeout: 480 seconds] 22:34:45 *** last_evolution [~last_evol@ip-86-49-60-58.net.upcbroadband.cz] has joined #openttd 22:36:19 *** Xrufuian [~Xrufuian@pool-98-119-100-101.lsanca.btas.verizon.net] has joined #openttd 22:36:41 *** Sacro1 is now known as Sacro 22:37:34 *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has quit [Remote host closed the connection] 22:43:11 <TruePikachu> Xrufuian: I can't do multiplayer right now; I'm doing a week-long game I just started 22:43:21 <TruePikachu> 1830-2050 22:43:32 <Xrufuian> Who says I came here for that? 22:43:35 <TruePikachu> Oh :P 22:43:55 <TruePikachu> Well, I'm short k for the first year in running cost 22:44:03 <Xrufuian> Remember rule #1... 22:52:44 <Eddi|zuHause> you don't talk about it? 22:56:04 <Xrufuian> Right, my number one rule: Don't assume anything. 22:57:43 *** perk111 [~perk11@178.34.182.32] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] 23:00:04 *** ^Spike^ [~spike@d200003.upc-d.chello.nl] has quit [Ping timeout: 480 seconds] 23:05:36 *** KingJ [~KingJ-OFT@95.154.197.17] has quit [Remote host closed the connection] 23:06:10 *** perk11 [~perk11@178.34.182.32] has joined #openttd 23:09:01 *** KingJ [~KingJ-OFT@95.154.197.17] has joined #openttd 23:13:19 *** Tennel [~Tennel@port-ip-213-211-212-60.reverse.mdcc-fun.de] has quit [Quit: Verlassend] 23:19:05 *** Sacro1 [~Sacro@adsl-87-102-115-110.karoo.KCOM.COM] has joined #openttd 23:19:55 *** TomyLobo [~foo@port-212-202-171-176.dynamic.qsc.de] has quit [Quit: A key, command, or action that tells the system to return to a previous state or stop a process.] 23:20:19 *** Progman [~progman@p57A19C76.dip.t-dialin.net] has quit [Remote host closed the connection] 23:24:34 <TruePikachu> Lol, 2 years in, and I have 75 RVs 23:25:29 *** Sacro [~Sacro@adsl-87-102-115-110.karoo.KCOM.COM] has quit [Ping timeout: 480 seconds] 23:26:06 *** avdg [~Adium@94-227-100-192.access.telenet.be] has joined #openttd 23:26:14 <Eddi|zuHause> and you think that's an achievement? 23:26:46 <Eddi|zuHause> that's like two cities worth of tram networks... 23:28:00 *** Xrufuian [~Xrufuian@pool-98-119-100-101.lsanca.btas.verizon.net] has quit [Quit: HydraIRC -> http://www.hydrairc.com <- *I* use it, so it must be good!] 23:28:33 *** Wizzleby [~wizzleby@pool-108-16-114-12.phlapa.fios.verizon.net] has joined #openttd 23:30:03 *** JVassie [~James@92.27.149.231] has quit [Ping timeout: 480 seconds] 23:33:08 *** avdg [~Adium@94-227-100-192.access.telenet.be] has quit [Read error: Connection reset by peer] 23:33:33 *** avdg [~Adium@94-227-100-192.access.telenet.be] has joined #openttd 23:46:16 * avdg is happy with the fixes :) 23:46:37 <avdg> seems a lot was happening when I was gone 23:55:36 <Eddi|zuHause> it's weird... whenever i skim the graphics development forum, the title "[TTDX] NewObjects GRF Coding Guide * UPDATE" triggers my brain heuristics for detecting SQL statements ;) 23:55:37 *** last_evolution [~last_evol@ip-86-49-60-58.net.upcbroadband.cz] has quit [Quit: Leaving] 23:57:56 <avdg> +1 for UPDATE keyword :) 23:59:24 <Eddi|zuHause> yes, plus the "*" and uppercase text mixed with not-uppercase text 23:59:50 <Brianetta> night all 23:59:56 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has quit [Quit: TschÃŒÃ]