Back to Home / #openttd / 2014 / 07 / Prev Day | Next Day
#openttd IRC Logs for 2014-07-09

---Logopened Wed Jul 09 00:00:42 2014
00:01-!-Guest1746 [~George@185.43.94.91] has quit [Ping timeout: 480 seconds]
00:03-!-tokai [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds]
00:20-!-jrambo [~jrambo@178-222-93-92.dynamic.isp.telekom.rs] has joined #openttd
00:24-!-KWKdesign [~KWKdesign@216.155.131.74] has quit [Read error: Connection reset by peer]
00:24-!-KWKdesign [~KWKdesign@216.155.131.74] has joined #openttd
00:25-!-tokai|mdlx [~tokai@port-92-195-28-53.dynamic.qsc.de] has quit [Ping timeout: 480 seconds]
00:29-!-tokai [~tokai@00012860.user.oftc.net] has joined #openttd
00:29-!-mode/#openttd [+v tokai] by ChanServ
00:38-!-tokai [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds]
00:42-!-tokai [~tokai@00012860.user.oftc.net] has joined #openttd
00:42-!-mode/#openttd [+v tokai] by ChanServ
00:43-!-George|2 [~George@185.43.94.91] has joined #openttd
00:43-!-George is now known as Guest1752
00:43-!-George|2 is now known as George
00:43-!-George|2 is "(unknown)" on (unknown)
00:47-!-Guest1752 [~George@185.43.94.91] has quit [Ping timeout: 480 seconds]
00:53-!-sla_ro|master [slamaster@89.137.74.191] has quit []
00:53-!-DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has quit [Read error: Connection reset by peer]
00:56-!-Eddi|zuHause [~johekr@p5DC67110.dip0.t-ipconnect.de] has quit []
00:56-!-Eddi|zuHause [~johekr@p57BD471D.dip0.t-ipconnect.de] has joined #openttd
01:14-!-George is now known as Guest1757
01:14-!-George [~George@185.43.94.91] has joined #openttd
01:19-!-Guest1757 [~George@185.43.94.91] has quit [Ping timeout: 480 seconds]
01:33-!-George|2 [~George@185.43.94.91] has joined #openttd
01:33-!-George is now known as Guest1761
01:33-!-George|2 is now known as George
01:35-!-Guest1761 [~George@185.43.94.91] has quit [Ping timeout: 480 seconds]
01:53-!-tokai|mdlx [~tokai@port-92-195-101-57.dynamic.qsc.de] has joined #openttd
01:56-!-tokai|noir [~tokai@00012860.user.oftc.net] has joined #openttd
01:56-!-mode/#openttd [+v tokai|noir] by ChanServ
01:57-!-tokai [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds]
02:01-!-Hazzard_ [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has quit [Ping timeout: 480 seconds]
02:02-!-tokai|mdlx [~tokai@port-92-195-101-57.dynamic.qsc.de] has quit [Ping timeout: 480 seconds]
02:22-!-tokai [~tokai@00012860.user.oftc.net] has joined #openttd
02:22-!-mode/#openttd [+v tokai] by ChanServ
02:24-!-tokai|noir [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds]
02:25-!-chrswk [~chrswk@213.188.55.189] has joined #openttd
02:25-!-tokai|mdlx [~tokai@port-92-195-3-214.dynamic.qsc.de] has joined #openttd
02:32-!-tokai [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds]
02:35-!-George|2 [~George@185.43.94.91] has joined #openttd
02:35-!-George is now known as Guest1770
02:35-!-George|2 is now known as George
02:35-!-George|2 is "(unknown)" on (unknown)
02:38-!-tokai|mdlx [~tokai@port-92-195-3-214.dynamic.qsc.de] has quit [Ping timeout: 480 seconds]
02:39-!-Guest1770 [~George@185.43.94.91] has quit [Ping timeout: 480 seconds]
02:43-!-tokai [~tokai@00012860.user.oftc.net] has joined #openttd
02:43-!-mode/#openttd [+v tokai] by ChanServ
02:44-!-Nothing4You [N4Y@Nothing4You.w.tf-w.tf] has quit [Ping timeout: 480 seconds]
02:48-!-Nothing4You [N4Y@Nothing4You.w.tf-w.tf] has joined #openttd
02:48-!-jonty-comp [~jonty@000128f3.user.oftc.net] has quit [Read error: Connection reset by peer]
02:49-!-Flygon_ [~Flygon@147.18.214.218.sta.commander.net.au] has quit [Read error: Connection reset by peer]
02:52-!-jonty-comp [~jonty@000128f3.user.oftc.net] has joined #openttd
02:53-!-tneo [~tneo@188.cimarosa.openttdcoop.org] has quit [Ping timeout: 480 seconds]
02:54-!-tneo [~tneo@188.cimarosa.openttdcoop.org] has joined #openttd
02:54-!-Osai^2 [~Osai@188.cimarosa.openttdcoop.org] has quit [Ping timeout: 480 seconds]
02:54-!-Yexo [~Yexo@188.cimarosa.openttdcoop.org] has quit [Ping timeout: 480 seconds]
02:55-!-Yexo [~Yexo@188.cimarosa.openttdcoop.org] has joined #openttd
02:55-!-Osai [~Osai@188.cimarosa.openttdcoop.org] has joined #openttd
03:00-!-Flygon [~Flygon@147.18.214.218.sta.commander.net.au] has joined #openttd
03:01-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd
03:21-!-JerikTelorian [~Jerik@c-68-80-55-194.hsd1.pa.comcast.net] has quit [Read error: Connection reset by peer]
03:21-!-Jerik [~Jerik@c-68-80-55-194.hsd1.pa.comcast.net] has quit [Read error: Connection reset by peer]
03:25-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds]
03:28-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd
03:30-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has quit []
03:36<@planetmaker>moin
04:01-!-guru3_ is now known as guru3
04:03-!-DigitalFox [~DigitalFo@bl17-61-74.dsl.telepac.pt] has joined #openttd
04:03<DigitalFox>morning :)
04:04<DigitalFox>Ok this is driving nuts and I need help...
04:04<@planetmaker>o/
04:04<V453000>mooin
04:04<DigitalFox>I'm compiling zbase in nml
04:04<DigitalFox>no errors
04:04<@planetmaker>I also heard that nuts trains usually are driving. Except when using wetrail ;)
04:04<DigitalFox>i change the md5 of zbase
04:05<DigitalFox>i start openttd and it says it's corrupt :\
04:05<DigitalFox>no graphics are missing, sprites corruption, just like any nnormal game
04:05<@planetmaker>DigitalFox, the "md5sum" in the zbase.obg is not a real md5sum but the value obtained by grfid -m
04:05<@planetmaker>grfid is part of the grfcodec package
04:06<DigitalFox>ok, so I get md5 value from there?
04:06<@planetmaker>grfid is a programme. Which will give you the value
04:07<DigitalFox>I'm doing a fun project, merging zbase + biggui + 32 ez build :o
04:07<@planetmaker>how did you compile zbase, btw? If you call make, it should automatically (try to) call grfid.
04:07<DigitalFox>I'm in Windows ;)
04:07<@planetmaker>and thus properly re-generate zbase.obg
04:08<@planetmaker>well, the build process does not lend itself well to windows
04:08<@planetmaker>the makefile explains what you got to do. Step by step :P
04:08<DigitalFox>Well it's more time consuming, but it's working :)
04:10<DigitalFox>So licenses? A bit mess hum? I mean if I would like to share my project with someone on the forum, how sharable are the the sprites from EZ? I'm asking because I know most artists left or are "piss*d" over png loading :\
04:11<@planetmaker>all "md5sums" for grfs are md5sums only over the pseudosprite part. Thus grfid programme is kinda a 'must have'
04:11<@planetmaker>zbase has absolutely no license mess. Nice and clean gpl v2
04:11<DigitalFox>planetmaker: trying grfid right now, major thank you!
04:12<@planetmaker>basically everything on devzone has no license mess. Every project ships with a license file and makes clear as to how and under which conditions it can be shared
04:13<DigitalFox>yeah zbase and biggui fine, but EZ? I'm really not sure what to do after I'm done, it's coming great, the best of the 3 worlds in my eyes, we'll see :)
04:13<DigitalFox>Again thank you planetmaker :)
04:14<@planetmaker>what is "EZ"? Zoom levels are nothing special really. Just bigger sprites
04:14<DigitalFox>http://dev.openttdcoop.org/projects/32bpp-ez-build/
04:15<@planetmaker>interesting. The license part 2 is not covered by the terms of usage of the DevZone ;)
04:17<@planetmaker>I agree, that is a total mess there
04:18<DigitalFox>yeah + the fact I hate licenses, I mean I know they are required but just pain the ass :\
04:19<@planetmaker>DigitalFox, no licenses basically means it applies what is listed in section2 of *that* copying file
04:19<@planetmaker>i.e.: you may do nothing. No copying, no distribution, no modification
04:20<@planetmaker>a license *always* means: "here, I give you more rights than you would have without this license"
04:22<@peter1138>"Before release 1.2.0 of OpenTTD, an official patch to OpenTTD named "Extra zoom" existed"
04:22<@peter1138>"official patch"
04:22<@peter1138>What makes a patch official?
04:24<DigitalFox>Oh man I thought you guys were aware of that project, I didn't mean to "raise" questions about it. The sprites are really amazing, many but not all are finished ofcourse, nor are there so many like Zbase.
04:25<@planetmaker>it's one of those projects which try to 'rescue' the 32bpp sprites which existed before zoom sprites entered NewGRFs. That usually fails as people did not license their files
04:25<@planetmaker>Thus no-one may (re-)use them
04:25<@planetmaker>like that very project you linked obviously...
04:25<DigitalFox>And why I refereed the licenses fiasco ;)
04:26<DigitalFox>I jump in search of 32bpp sprites from coop to http://jupix.info/openttd/gfxdev-repo/index.php?act=browse
04:26<@planetmaker>thus I always say: make it gpl v2. That's like OpenTTD. And all will be fine, if everyone used it
04:26<@planetmaker>yeah. That path lies pain. License pain
04:27<@planetmaker>those sprites you found in the 32bpp-ez-project are taken from there, if not all, then at least in parts
04:29<DigitalFox>But I think given most artists just abandon ship and never return or respond to contacts, that until notification most of the sprites publicly shared on TT Forums should be used, ofcourse if anyone complaints they should immediately removed and full credits given. Cause then "shit" like this happens... You amazing art, stuck in a repo that no ones use or most are even aware...
04:30<DigitalFox>*You have
04:31<DigitalFox>If they shared the art in public with the intention of being used by everyone then why not use it?
04:31<V453000>because they did not state that intention in a license file
04:31<V453000>simple
04:32<DigitalFox>But V453000 I understand what you're saying, but doesn't it make little sense to share even the source on public and then no one can use it?
04:32<@peter1138>The consequences of being a dick about licensing your work...
04:33<V453000>sadly it is a thing to easily forget about, especially back in those times when people did not care about licencing as a whole, but yes, this is the result
04:33<blathijs>That's how copyright law works, though.
04:33<@peter1138>What's the timespan for public domain these days?
04:33<V453000>70yrs?
04:33<blathijs>In the old days of US copyright you had to include "All rights reserved" to assert your copyright AFAIU, but that has since then be changed to be automatic (as it should be, I think)
04:34<@peter1138>Another problem with those sprites is generally it's just sprites, no source. Editing them to actually make it all work as a coherent set is going to be impossible.
04:34<@peter1138>Patchwork spritesets look terrible...
04:34<V453000>+ that
04:35<@peter1138>Big trick with 32bpp: you still need a palette.
04:35<@peter1138>Just, not in the 8bpp sense.
04:35<V453000>myeah, or rendering with the same/similar materials and same light settings
04:36<@peter1138>Same thing really, your materials are your palette.
04:36<V453000>not exactly but yeah :)
04:43<@planetmaker>70 years past death of creator
04:43<V453000>AHA
04:43<V453000>:D
04:43<V453000>so even if you kill them quickly you will still have to wait :P
04:44<V453000>tleast you can spend the first XX years of waiting in jail
04:44<V453000>good time killer
04:46<@planetmaker>well. In principle you can draw 32bpp just fine. 32bpp does not imply rendering :)
04:47<@peter1138>planetmaker, "or" ;)
04:47<V453000>well sure :)
04:48<@peter1138>Line-art OpenTTD...
04:49<@peter1138>http://www.rabbleboy.com/wp-content/uploads/2014/02/Eboy-ville-pixel-art-Cologne.png
04:49<@peter1138>heh
04:50<V453000>exactly the kind of pixel art I find wtf
04:51<V453000>also am not sure if it is compatible with the size of x1 vehicles in openttd :P
04:51<@peter1138>:D
04:53<@peter1138>http://static.fjcdn.com/large/pictures/88/ea/88eaab_4469884.jpg
04:53<@peter1138>Ehhhh
04:54<DigitalFox>For someone like me that didn't sleep, that previous image on my 27" screen just melted my eyes
04:54<V453000>thats better :D
04:55<@planetmaker>https://plus.google.com/u/0/photos/113825442692250582467/albums/5848557196477543889?sqi=107993743924374455416&sqsi=54384611-2fe7-4cc2-b36a-6c41e923b5c4
04:56<V453000>:)
04:56<V453000>is that openttd sizes?
04:57<@planetmaker>sadly not directly 192px
04:57<@planetmaker>instead of 64/128/256
04:57<DigitalFox>planetmaker: GRFid did the trick. Now I can go to bed dreaming with offsets :o
04:58<@planetmaker>V453000, but maybe I talk to him (again). He's the guy I got the sprites for the comic houses from. So... maybe :)
04:58<@planetmaker>More time needed, though .(
04:58<V453000> : D
05:33-!-MJP [~mjp@hq.z77.fr] has joined #openttd
05:37-!-Yotson [~Yotson@2001:980:6ac8:1:c9e3:31c1:9fa6:48e6] has joined #openttd
05:45<DigitalFox>Alright, thanks guys. bye!
05:45-!-DigitalFox [~DigitalFo@bl17-61-74.dsl.telepac.pt] has quit [Quit: ChatZilla 0.9.90.1 [Firefox 30.0/20140605174243]]
06:37-!-Kurimus [~stabbity@dsl-tkubrasgw2-54f816-197.dhcp.inet.fi] has quit []
06:47-!-TheMask96 [martijn@pride.vhost.ne2000.nl] has quit [Ping timeout: 480 seconds]
06:51-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd
06:52-!-TheMask96 [martijn@gluttony.vhost.ne2000.nl] has joined #openttd
07:21<@peter1138>Hmm, fail2ban can be handy... and can also be a pain in the bum...
07:22<V453000>bum bum
07:23-!-tokai|mdlx [~tokai@port-92-195-24-230.dynamic.qsc.de] has joined #openttd
07:26-!-tokai [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds]
07:26-!-pthagnar [~pthagnar@cpc7-pres17-2-0-cust28.18-3.cable.virginm.net] has joined #openttd
07:31-!-Supercheese [~Superchee@76.178.136.186] has quit [Read error: Connection reset by peer]
07:31-!-Supercheese [~Superchee@76.178.136.186] has joined #openttd
07:36-!-xintron [~xintron@2a02:c200:0:10:2:1:5488:1] has joined #openttd
07:37<xintron>I have a vague memory of it being possible to disable aircrafts on a server but can't seem to find it in the settings (wiki) or any information about it. Is it possible?
07:37-!-tokai|noir [~tokai@00012860.user.oftc.net] has joined #openttd
07:37-!-mode/#openttd [+v tokai|noir] by ChanServ
07:42<Taede>set max_aircraft to 0
07:42<Taede>using rcon
07:42<Taede>set
07:43-!-tokai|mdlx [~tokai@port-92-195-24-230.dynamic.qsc.de] has quit [Ping timeout: 480 seconds]
07:46<xintron>Ah, that's right yeah.
07:46<xintron>Thanks!
07:51-!-KWKdesign [~KWKdesign@216.155.131.74] has quit [Read error: Connection reset by peer]
07:52-!-KWKdesign [~KWKdesign@216.155.131.74] has joined #openttd
07:53-!-yorick [~yorick@ip51cd0513.speed.planet.nl] has joined #openttd
08:03-!-KWKdesign [~KWKdesign@216.155.131.74] has quit [Read error: Connection reset by peer]
08:03-!-KWKdesign [~KWKdesign@216.155.131.74] has joined #openttd
09:23-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds]
09:27-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd
09:28<xintron>Isn't there a config "generator" online as well somewhere? :)
09:30<Taede>used to be, not sure if it still works
09:30<xintron>Is the normal way to go about it to start a game locally, copy the config and then put it on the server?
09:31<Taede>normal is subjective
09:31<Taede>personally, i'd create a map (config newgrf et all), save, then transfer the savegame to the server
09:32-!-xT2 [~ST2@118.107.136.95.rev.vodafone.pt] has joined #openttd
09:33<MTsPony>is there a known problem when running multiple (differerent) openttd.exe's in the same folder and all use the same datasets and config?
09:34<xintron>Taede, hrmm.. couldn't find the "max_aircraft" in the advanced settings. Maybe that's only available to set directly in the config file (or rcon)?
09:37<Taede>MTsPony, they'll all try to listen on the same port, so only the first will work
09:37<Taede>the 2nd and after will refuse to run (assuming dedicated) telling the port is already in use afaik
09:37<MTsPony>i ment client wise
09:37<MTsPony>kinda
09:38-!-ST2 [~ST2@118.107.136.95.rev.vodafone.pt] has quit [Ping timeout: 480 seconds]
09:38-!-xT2 is now known as ST2
09:39<Taede>xintron, adv settings -> vehicles shows it for me
09:39<Taede>make sure you have 'all setting stypes' selected
09:40<xintron>Taede, Oh, how did I manage to not see that? :S
09:40<xintron>Thanks :)
09:43<@planetmaker>xintron, also the adv. settings have a search box :)
09:44<@planetmaker>MTsPony, they might try to create a savegame concurrently. Maybe even the same filename. Not sure whether that's an issue and if so how it would manifest
09:44<MTsPony>kk thx
09:45<MTsPony>another Q, what would cause it to crash if you turn on full,anmations? lol
09:46<MTsPony>could that be sprite cache related?
09:46<@planetmaker>the crash.log would maybe tell you?
09:46<@planetmaker>you know, this is not a quiz channel
09:47<@planetmaker>where we guess how you possibly could create a crash under not fully described circumstances, software versions and settings
09:48<@planetmaker>if you have actual crash data, that's something way more interesting
09:49<@planetmaker>especially if you can describe a way so that anyone can reproduce it
09:50-!-HerzogDeXtEr [~flex@i59F6D352.versanet.de] has joined #openttd
09:50<MTsPony>odd. it only does it when i use a specific openttd.cfg
09:51<MTsPony>so i guess that knda solves the problem
09:51<@planetmaker>not really. Would be interesting to see what causes it to crash
09:51<@planetmaker>it's a workaround at best ;)
09:52-!-luaduck_zzz is now known as luaduck
09:53<MTsPony>well
09:53<MTsPony>what file do u,want to,check?
09:54<MTsPony>sorrymabout the crappy typing im on a tabletn:p
09:54<@planetmaker>those which openttd tells you to communicate: crash*
09:55<@planetmaker>or do you use an iPad or android version?
09:55<MTsPony>ipad, im connected to my desktop tho,with remote desktop
09:56<MTsPony>were talking desktop version, r26335 to br exact
09:57<MTsPony>im always getting these spritecache errors tho
09:57<MTsPony>i tried increasing to 256 or 512 it still gives me the same :/
09:57<Diablo-D3>wait, openttd crashes?
09:57<Diablo-D3>bullshit
10:02<MTsPony>ok lets forget all what happenee here, fresh question, ane somethint which happens on all cersions of openttd. whats this 'out of memory' warning about, failed to allocate etc spritecache, reduced to xxx mb
10:02<MTsPony>trying to increase it gives the same error.
10:02<MTsPony>i got plenty of memory
10:03<MTsPony>and im just usin 8bpp anim blitter
10:04<@planetmaker>lol. It's just that: too little memory
10:06<MTsPony>really now.
10:06<MTsPony>i have 4-5gb of free mem.
10:09<Diablo-D3>heh
10:09<Diablo-D3>I have
10:09<Diablo-D3>about 29.5gb of free mem
10:10<MTsPony>lol.
10:11<MTsPony>either way it should not fail while trying to allocate 512mb or 1gb for spritecache
10:11<Diablo-D3>31030064
10:11<Diablo-D3>bytes :D
10:12<@planetmaker>you realize that you err by a factor of 1000, Diablo-D3 ?
10:12<Diablo-D3>er, maybe thats kb
10:13<Diablo-D3>yeah free does kb
10:15<Xaroth|Work>or just free -m for mb
10:17<Diablo-D3>or -g apparently
10:18<Diablo-D3>I dont remember those flags existing
10:18<Diablo-D3>dear god how old am I =/
10:21<@planetmaker>13?
10:22<Diablo-D3>old enough to remember when free didnt have fancy flags like that
10:25-!-Hazzard [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has joined #openttd
10:55-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds]
11:27-!-chrswk [~chrswk@213.188.55.189] has quit [Read error: Connection reset by peer]
11:43-!-TheMask96 [martijn@gluttony.vhost.ne2000.nl] has quit [Ping timeout: 480 seconds]
11:43<xintron>Why are graphics needed to run a dedicated server?
11:44-!-TheMask96 [martijn@wrath.vhost.ne2000.nl] has joined #openttd
11:44<xintron>And can the server run one set and the clients whatever they please?
11:44<@planetmaker>xintron, the grfs contain more than graphics. e.g. some height map snippets for map creation
11:44<@planetmaker>and yes, doesn't matter who uses which base set
11:45<xintron>Ok, that makes sense. Thanks!
11:47-!-KWKdesign [~KWKdesign@216.155.131.74] has quit [Read error: Operation timed out]
11:47-!-KWKdesign [~KWKdesign@216.155.131.74] has joined #openttd
11:47-!-Progman [~progman@p57A1B7A2.dip0.t-ipconnect.de] has joined #openttd
11:58<Eddi|zuHause>man i raised my highscore from 150k to 170k, but still no 16384 :(
12:13-!-Kurimus [~stabbity@dsl-tkubrasgw2-54f816-197.dhcp.inet.fi] has joined #openttd
12:29-!-Stimrol [~Stimrol@46-239-219-51.tal.is] has quit [Ping timeout: 480 seconds]
12:30-!-Stimrol [~Stimrol@46-239-219-51.tal.is] has joined #openttd
12:59-!-efess [~Efess@c-24-61-64-170.hsd1.ct.comcast.net] has quit [Read error: Operation timed out]
13:09-!-Netsplit magnet.oftc.net <-> resistance.oftc.net quits: Diablo-D3, dfox, davidstrauss_, lobster, @Belugas, +tokai|noir, joho, Nothing4You, Vadtec, funnel, (+34 more, use /NETSPLIT to show all of them)
13:10-!-Netsplit over, joins: tparker, dyrim, Sacro, Xaroth|Work, Vadtec, ccfreak2k, davidstrauss_, eQualizer
13:10-!-Netsplit over, joins: brambles
13:10-!-Netsplit over, joins: funnel, ivan`, Nothing4You, Ttech, @Belugas, Speedy, luaduck, mist__, jinks, MTsPony (+25 more)
13:18-!-Alberth [~hat@2001:981:c6c5:1:be5f:f4ff:feac:e11] has joined #openttd
13:18-!-mode/#openttd [+o Alberth] by ChanServ
13:34-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd
13:36-!-Wolf01 [~wolf01@0001288e.user.oftc.net] has joined #openttd
13:36-!-Midnightmyth [~quassel@93-167-84-102-static.dk.customer.tdc.net] has joined #openttd
13:36<Wolf01>hello
13:37<Eddi|zuHause>you destroyed the green!
13:37<Wolf01>:(
13:37<@Alberth>luckily, eddi is green :)
13:38<Eddi|zuHause>moderately :p
13:39<@planetmaker>alberth is greener than turquoise Eddi|zuHause ;)
13:40<@Alberth>oh :)
13:40<Eddi|zuHause>Alberth is clearly red
13:40<@planetmaker>hi hi :)
13:40*Alberth feels very green, does that count?
13:42<@planetmaker>http://devs.openttd.org/~planetmaker/patches/green.png ;)
13:42<@planetmaker>feeling green counts, too, yes
13:42-!-tycoondemon [~ashnohoe@ip503d7ac1.speed.planet.nl] has quit []
13:43<@planetmaker>luckily and strangely enough, the colours are nicely persistent :)
13:44-!-frosch123 [~frosch@frnk-4d00d083.pool.mediaWays.net] has joined #openttd
13:44<@planetmaker>now yellow joined ;) quak :)
13:44<@Alberth>hai yellow :)
13:44<frosch123>yellow? green!
13:45<@Alberth>blue here!
13:45<frosch123>your clients are wrong
13:45-!-Haube [~michi@37-4-140-17-dynip.superkabel.de] has joined #openttd
13:45<@DorpsGek>Commit by translators :: r26681 /trunk/src/lang (gaelic.txt polish.txt) (2014-07-09 17:45:26 UTC)
13:45<@planetmaker>your colour perception is! ;)
13:45<@DorpsGek>-Update from WebTranslator v3.0:
13:45<@DorpsGek>polish - 48 changes by Kilian
13:45<@DorpsGek>gaelic - 4 changes by GunChleoc
13:46<@Alberth>tbh as long as everybody has a different colour, I am happy
13:46<@planetmaker>yeah :)
13:49-!-oskari89 [oskari89@83-102-63-32.bb.dnainternet.fi] has joined #openttd
13:50<@Alberth>oskari89 never says anything, no idea what his colour is
13:50<@planetmaker>where did you find juanjo's patches yesterday, frosch123 ?
13:52<oskari89>Never says anything? :)
13:52<frosch123>planetmaker: flyspray
13:52<Rubidium>pff... it's all one shade of grey
13:52<frosch123>opened 2 days ago
13:52<@planetmaker>oh. I thought elsewhere as there was no FS#
13:53<@planetmaker>missed it on FS
13:53<frosch123>yeah, missed the fs :)
13:53<frosch123>but there was nothing interesting in the task either, except the bare patches
13:53<@Alberth>hi oskari89 :)
13:53-!-MJP [~mjp@hq.z77.fr] has quit [Read error: Connection reset by peer]
13:53<frosch123>but bugs the fs reference is important, so you get the test case in the future :)
13:53<oskari89>hi Alberth :)
13:54<@planetmaker>yeah, no worries :)
13:54<@planetmaker>just curious whether you found a new secret patch source :)
13:54<frosch123>shall i link you to some? :p
13:55<@planetmaker>:D
13:55<@Alberth>all those are definitely not the secret one :p
13:55<frosch123>he, it's quite a secret what i bookmarked
13:56-!-andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd
13:59<@planetmaker>frosch123, that's what you want to believe
13:59<andythenorth>o/
13:59<andythenorth>whatever you believe, snopes it
13:59<andythenorth>just in case
13:59<@planetmaker>Shall I ask the National Storage Association for the backup?
14:00-!-MJP [~mjp@hq.z77.fr] has joined #openttd
14:00<@planetmaker>\o
14:04-!-DigitalFox [~DigitalFo@bl17-61-74.dsl.telepac.pt] has joined #openttd
14:04<DigitalFox>Hi :)
14:04<andythenorth>are we making anything?
14:05<andythenorth>oops http://www.railpictures.net/viewphoto.php?id=488739&nseq=1
14:05<@Alberth>conversation at least, and probably tea
14:06<andythenorth>consists?
14:06<andythenorth>faster nml?
14:06<andythenorth>Squid?
14:06<@Alberth>it looks like a few toy trains, so small, compared to the mountain
14:06<andythenorth>a new GS?
14:07*Alberth takes #2
14:07<@Alberth>but it's not going anywhere fast I suspect
14:07<andythenorth>wondered about that
14:08<andythenorth>I’m not very +1 to continuing my hacky speed up approach
14:08<andythenorth>more -1
14:08<andythenorth>as it requires a patched nml
14:08<andythenorth>but it did look promising
14:08<@Alberth>we have one forked nml, you can add another one :p
14:09<@Alberth>I started a conversation last sunday morning in #openttdcoop.devzone, but that didn't end in anything useful either
14:10<andythenorth>no logs there :)
14:10<@Alberth>other than V getting happy about his yetis :)
14:11<@Alberth>andythenorth: oh??? look what I found then! http://webster.openttdcoop.org/index.php?channel=openttdcoop.devzone&date=1404604800
14:11<andythenorth>:o
14:12<andythenorth>oh deep clones :)
14:12<andythenorth>I see
14:14<andythenorth>did you get anywhere with faster parser?
14:16<@Alberth>I wrote a faster scanner, and scanning is now reduced to 8 seconds with FIRS
14:16<andythenorth>previously was?
14:16<@Alberth>parsing takes 16 seconds
14:16<@Alberth>scanning was 30 iirc
14:16<@Alberth>it does 1.6E06 python calls in that 8 seconds
14:17<@Alberth>total execution time is 1:17 iirc
14:17<andythenorth>I wonder how acceptable my crazy ‘extend global constants’ patch is?
14:17<@Alberth>thus, if you manage to completely drop scanning and parsing, you'll end up just below the 1:00
14:18<andythenorth>if I also only compile changed files...
14:18-!-Mrucux7 [~oftc-webi@adcz50.neoplus.adsl.tpnet.pl] has joined #openttd
14:18<andythenorth>there are 62 industries...
14:18<@Alberth>then any scanning and parsing is fine, I think
14:19<andythenorth>I’d rather solve the tractable problem than wait for the perfect solution
14:19<andythenorth>but I don’t know if my approach sucks :)
14:19<andythenorth>compiling 1 industry not 62 suggests up to 62x improvement - overhead of setup
14:20<@Alberth>yep, which means a few seconds
14:20<@Alberth>rather than just < 1:00
14:21<andythenorth>so I have been manually pushing constants into json, and then extending global_constants
14:21<andythenorth>which seems wrong but works
14:21<@Alberth>only minor issue is the total lack of underlying tools and file format
14:21<@Alberth>not to mention that nml is not designed for partial translation
14:22<andythenorth>I am treating translation separately
14:22<andythenorth>admittedly it is 100% unsolved :P
14:24<DigitalFox>So I'm changing the faces sprites to 32bpp (not all are yet changed). Here's what I'm getting now: http://s28.postimg.org/lx1ng7ial/Faces_Wrong.png and here's how it should look like: http://s10.postimg.org/e28aqfl09/Faces_Right.png
14:24<DigitalFox>My code:
14:24<DigitalFox>base_graphics spr805( 805, "sprites/gui/small_gui.png") { [ 354, 1000, 92, 119, 0, 0] }
14:24<DigitalFox>alternative_sprites(spr805, ZOOM_LEVEL_NORMAL, BIT_DEPTH_32BPP, "sprites/gui/faces/805_z1.png") { [0, 0, 134, 125, 0, 0] }
14:25<DigitalFox>134, 125 is the real dimension of the png. Original PNG: http://s28.postimg.org/rfhok3dcp/805_z1.png
14:25<DigitalFox>So where am I messing this up? It's huge :o
14:27<frosch123>ZOOM_LEVEL_NORMAL?
14:30<frosch123>i have no idea what weird zoom level your original sprite is
14:30<@planetmaker>Alberth, you mean the conversation which essence (in my words) was that the expression parser written in C/C++ probably would speed up things but is nearly as much work as a complete re-write?
14:31<@Alberth>s/expression parser/expression handling rewriting/ probably, but close enough :)
14:31<andythenorth>it also reduces the pool of maintainers imo
14:31<andythenorth>maybe not
14:32<@planetmaker>sorry, you're right, yes
14:32-!-Mrucux7 [~oftc-webi@adcz50.neoplus.adsl.tpnet.pl] has quit [Quit: Page closed]
14:33<@planetmaker>I was not sure what conclusion to draw. I only see two alternatives, both not exactly satisfactorily:
14:34<@planetmaker>a) keep it in principle like it is. Maybe work towards some better modularized code in that respect. But that won't give us any speed gain
14:34<@planetmaker>b) basically rewrite NML in C. Oh well...
14:35<@Alberth>c) rewrite nml in python is also an option, but arguably not better than b)
14:35<andythenorth>same work, slower?
14:35<@Alberth>although it's finished much sooner probably :)
14:35<@Alberth>you can write Python more quickly
14:36<andythenorth>whatever the implementation, partial compiles will always be faster? Do we think?
14:36<Rubidium>what part of NML is the real bottleneck?
14:36<Rubidium>is it the parsing/making the AST, or is it something else?
14:37-!-jinks [~jinks@172.245.35.67] has quit [Quit: ZNC - http://znc.in]
14:37<@Alberth>Rubidium: expression tree reduction, it seems; if you ignore parsing
14:38<@Alberth>(scanner in C 8 seconds, parsing in Python 16 seconds, expression.reduce lots of small calls in the order of 1.5-2 seconds
14:38-!-jinks [~jinks@172.245.35.67] has joined #openttd
14:38<@Alberth>total 1:10-1:15 or so
14:38<@Alberth>and a HUGE amount of memory used
14:39<@Alberth>which is perhaps the deep-copying of the expressions while reducing them
14:39<@planetmaker>Alberth, would it get better maybe, if the deep cloning would be replaced by references?
14:39<@planetmaker>s/cloning/copying/
14:39<@Alberth>planetmaker: it would probably, as you also reduce garbage collection stuff
14:39<Rubidium>so try that approach ;)
14:39<@planetmaker>hm :)
14:39<@Alberth>however, you must be sure the shared objects are not modified
14:40<@planetmaker>which is the tricky bit here
14:40<Rubidium>why can't shared objects be reduced?
14:40<@Alberth>to establish that with 100% certainty, it is
14:40<Rubidium>shouldn't reducing yield the same?
14:41<@Alberth>Rubidium: you can, but you should not do in-place modifications in them, or you crate havoc with the other uses
14:41<@Alberth>which is not easy to establish whether or not that happens in the code
14:42<@Alberth>as far as I know, at least
14:42<Rubidium>also, why so many calls to reduce. Isn't it needed just once?
14:42<@Alberth>it's a recursive method, over all nodes in the expressions
14:43<@Alberth>as most of nml is expressions, that a lot of calls
14:43<@Alberth>also, the compiler constructs rewrites as expressions, and reduces those
14:45<@Alberth>https://dev.openttdcoop.org/projects/nml/repository/entry/nml/actions/action0properties.py#L236 for example
14:45-!-Chrill [Chrill@c83-255-31-85.bredband.comhem.se] has joined #openttd
14:46<@Alberth>ie it uses expression as basic notion instead of "number"
14:46<Rubidium>can't you cache everything that has been reduced? An then prevent a second attempt?
14:47<@Alberth>while the code may make in-place modifications?
14:47<Rubidium>don't know... I'm just throwing stupid ideas in the air. Maybe one sticks
14:48<Rubidium>the .reduce() does return some expression, right?
14:48<@Alberth>it makes deep copies. Either because there is a reason like in-place modification, or because deep-copying seemed like a good idea at the time, I don't know which one
14:49<@Alberth>.reduce returns an expression indeed
14:49<@Alberth>which is eventually translated to a sequence of actions
14:50<Rubidium>then you don't need to do the reduce in the cargolist function, if... and only if you just run reduce once at the end of everything. At that moment you'd just create one clone/deep copy of the initial AST
14:50<@Alberth>you do need to do it; it reduces to see what case it has, and how to rewrite
14:51<Rubidium>so then it is to be considered "constant", and it should *never* be reduced again. In that case you could simply mark the expression instance as such and just return 'this' for reduce
14:51<@Alberth>but tbh I don't have a clue what it is computing. I can read the Python code and see what it does, but I have no clue why
14:52-!-Supercheese [~Superchee@76.178.136.186] has quit [Quit: Valete omnes]
14:52<@Alberth>ConstantNumeric does exactly that
14:52-!-Pereba [~UserNick@179.180.222.76] has joined #openttd
14:52<frosch123>what does it need to change the deep-copy into a shallow-copy?
14:53<frosch123>is it something one can try to see what breaks?
14:53<frosch123>is it 10 lines or 1000 lines? :p
14:54<@Alberth>hard to say, you'd need to check every if case, and see whether a new value is created or whether the old value is kept
14:54<Rubidium>hmm... deep copy of an expression. Does that mean that the complete subtree is cloned?
14:54<@Alberth>so it may be a few lines in the end, but you need to check every "new" call
14:55<@Alberth>Rubidium: yes, recursively, bottom up
14:55-!-efess [~Efess@c-24-61-64-170.hsd1.ct.comcast.net] has joined #openttd
14:55<@Alberth>https://dev.openttdcoop.org/projects/nml/repository/entry/nml/expression/binop.py#L72 <-- at every binary operator: first step, reduce the childs
14:56<Rubidium>so that's quite O(2^n)-ish; it doubles in amount of work for every extra level in the AST
14:56<@Alberth>very much so
14:57<@Alberth>the walk in itself is not that bad, if you would not actually create a new node on the way back
14:58<@Alberth>although if you examine a node, do a rewrite by adding a few nodes, and call .reduce again... :)
14:58<@Alberth>heaps and heaps of time that you can save there :p
14:58<Rubidium>is the AST really a tree, or is it rather a DAG (I hope there's no recursion allowed)
14:59<Rubidium>i.e. is a helper function cloned or referenced?
15:00<@Alberth>don't know the answer to that
15:00<Rubidium>if it is referenced, then I can imagine using deep copies. Otherwise (in the pure AST case) those deep copies are just pointless
15:01<@Alberth>parser doesn't hand out the same object twice, as the position is different each time
15:02<@Alberth>indeed, the question is thus how to decide what case we have
15:03<@Alberth>it's not simple to find all write operations to a class
15:03<@Alberth>at many points, it's not even clear what object types are possible there
15:03<Rubidium>https://dev.openttdcoop.org/projects/nml/repository/entry/nml/expression/functioncall.py#L384 <- what?!?
15:04<@Alberth>:D
15:04<@planetmaker>:)
15:04<@Alberth>wanted a sinus snowline curve, anyone? :D
15:04<@planetmaker>snowlinemod
15:04*planetmaker whistles
15:04-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds]
15:04<@Alberth>oh, I guessed right, apparently :)
15:05<@Alberth>I can also imagine uses for that in the multi-angle sprites of eddi
15:08<@Alberth>but from a compiler point of view, it's a harmless constant
15:09<Rubidium>yeah
15:09<Rubidium>it just amazed me though
15:10<Rubidium>but... then I have a suggestion for NML, especially needed by V453000: random(<min>,<max>). For a compiler point of view it is just a harmless constant, but you can make NUTS really nuts
15:10<@planetmaker>:P
15:11<Rubidium>my English is crap today
15:11<frosch123>compile time randomness? :p
15:12<@planetmaker>here's the compile-time random const number: 42
15:13<Rubidium>planetmaker: rather 4 -> http://xkcd.com/221/
15:13<frosch123>hmm, rb was faster
15:13<@planetmaker>or that :)
15:14<@Alberth>part of the problem is perhaps also the cpp pre-processing
15:14<@planetmaker>in what way, Alberth ?
15:14<@planetmaker>that it adds several types of comment lines?
15:14<@Alberth>you cannot do calculations in cpp, so expressions get expanded fully, and thrown into nml
15:15<@Alberth>at every point where the value is needed
15:15<@planetmaker>ok, but... how is that a cpp preprocessing problem? You mean, cpp should just place it there as constant?
15:15<@Alberth>so nml has to perform the same reduction many times
15:15<@planetmaker>had I no cpp or other pre-processor I'd also write it such. Just preceeding it by like
15:15<@planetmaker>global_var1 = 4
15:15<@planetmaker>global_var2 = 1950
15:15<frosch123>where does firs copy those constants?
15:16<frosch123>where does it have constant expressions in macros?
15:16<frosch123>(non-trivial expressions, that is)
15:18<andythenorth>hmm Alberth where are those in FIRS?
15:18-!-Chrill [Chrill@c83-255-31-85.bredband.comhem.se] has left #openttd []
15:19<@Alberth>it's all expressions or part of expressions, that you see twice or more often
15:19<@Alberth>if you'd write that manually, you would do the computation one time, and re-use the stored result
15:20<@Alberth>tbh I don't know if nml does such reductions
15:20<@planetmaker> hide_sprite: (climate != CLIMATE_TROPIC) || ((climate == CLIMATE_TROPIC) && (nearby_tile_terrain_type(0, 0) == TILETYPE_DESERT)) || ((climate == CLIMATE_TROPIC) && (nearby_tile_terrain_type(0, 0) == TILETYPE_NORMAL) && ((nearby_tile_terrain_type( 1, 0) != TILETYPE_DESERT) && (nearby_tile_terrain_type(-1, 0) != TILETYPE_DESERT) && (nearby_tile_terrain_type( 0, 1) != TILETYPE_DESERT) && (nearby_tile_terrain_type( 0,-1) != T
15:20<@planetmaker>ILETYPE_DESERT) ) );
15:20<andythenorth>that’s one of the more simple ones :P
15:20<@planetmaker>that's mostly inserted by a cpp macro, I recon. Coming from a template with a few parameters
15:21<@Alberth>at the very least it parses and reduces the same expressions over and over again
15:21<andythenorth>and over and over
15:21<@Alberth>if you want to eliminate double calculations, that's more work
15:21<andythenorth>doesn’t nfo have some way to share varaction 2?
15:21*andythenorth ponders
15:22<frosch123>there is nothing in that expresion, that could be evaluated with a preprocessor
15:22<@Alberth>maybe nml is wrong?
15:22<andythenorth>http://newgrf-specs.tt-wiki.net/wiki/VarAction2Advanced procedures....
15:22<@Alberth>I don't know enough of the target language to see other solutions
15:22<@planetmaker>ah... the nml I look at is already the output of gcc. So...
15:22<andythenorth>all the terrain crap could be one procedure, instead of repeated in every spritelayout...
15:23<frosch123>i thought you meant stuff like "2 * 3 + 5"
15:23<frosch123>but in above example, there are variables in every node
15:23<@Alberth>that too, but it doesn't happen much, probably :)
15:23<frosch123>so, nothing that can be evaluated at compile time
15:24<@Alberth>if you throw that into nml enough times, it will also be slow, but it takes more work :)
15:24<@planetmaker>switch (FEAT_INDUSTRIES, SELF, THIS_ID(check_availability), current_date) {
15:24<@planetmaker> date(THIS_MIN_YEAR,1,1) .. date(THIS_MAX_YEAR,12,31): THIS_ID(available_game_mode);
15:24<@planetmaker> return CB_RESULT_IND_NO_CONSTRUCTION;
15:24<@planetmaker>}
15:25<@Alberth>you wouldn't want to build anything before the start of the world nor after it! :D
15:26-!-Brumi [~quassel@78-131-41-191.pool.digikabel.hu] has joined #openttd
15:26<@planetmaker>yep :P
15:26<@planetmaker>the constant defined indeed make that check *slightly* pointless
15:26<@Alberth>I do wonder why the name of the switch etc is in the parameter list instead of in front of it
15:27<@Alberth>ie THIS_ID(check_availability) = switch ( ...)
15:27<@Alberth>this is mostly just wasting openttd time rather than nml time
15:27<andythenorth>all of that CPP could be fixed by me (convert to python templates)
15:27<@planetmaker>hm?
15:27<andythenorth>I’ve been leaving it alone, on the basis “it ain’t broke"
15:28<@Alberth>technically it ain't, it just a big 13MB pile of stuff to work through
15:28<andythenorth>changing things = new bugs
15:28<andythenorth>especially on a slow compile :P
15:29<@planetmaker>the check for availability between 0 and 5000000 also shows there might be cases with bit rot ;)
15:29<@Alberth>and whether this is caused by bad use of cpp or nml lacking some feature, I don't know
15:30<andythenorth>it is a blunt use of CPP imo
15:30<@Alberth>planetmaker: such things happen when you introduce a concept like availability over time
15:30<@Alberth>you get new edge cases where the check is not useful
15:30<@planetmaker>of course, I know :)
15:30<@Alberth>and you never find them unless you read the generated code :)
15:31<@planetmaker>hard to avoid, if you want to spare time programming and not special-case everything
15:31<@Alberth>yep
15:31<andythenorth>it was a mass conversion from nfo too
15:32<andythenorth>historical raisins
15:32<@planetmaker>oh, there's nothing left of that origin, I think
15:32<@Alberth>I am not sure whether this is a cause for the slow compile, it looks like duplicate work, but no idea if it really is, or whether you can even avoid it
15:32<@planetmaker>it really has been re-written completely in NML. And now partily in pynml :)
15:34<@Alberth>obviously, if you can cache reductions, you can detect such duplicates too
15:35<@planetmaker>more memory usage :)
15:35<@Alberth>if you make every expression and sub-expression unique, yes
15:36-!-Yotson [~Yotson@2001:980:6ac8:1:c9e3:31c1:9fa6:48e6] has quit [Quit: .]
15:36<@Alberth>I don't believe you manage that in a real newgrf :)
15:38<@Alberth>every sprite at a different position :p
15:39-!-DigitalFox [~DigitalFo@bl17-61-74.dsl.telepac.pt] has left #openttd []
15:40<@planetmaker>hm :)
15:40<@planetmaker>I don't want to try for any non-trivial NewGRF
15:41<@Alberth>it would be very unique, every engine its own stats + rules :p
15:43-!-KWKdesign [~KWKdesign@216.155.131.74] has quit [Read error: Operation timed out]
15:43-!-KWKdesign [~KWKdesign@108.61.152.243] has joined #openttd
15:44<@Alberth>so in practice, it'll work out, what you gain on less expression duplicates against more cache + detection data
15:52<andythenorth>so for string IDs
15:52<andythenorth>- look in a cache file for the string ID, if not present, assign new random ID
15:52<andythenorth>- cache ID in cache file
15:52<andythenorth>- on exit of compile, garbage collect any dead strings (check the output)
15:52<andythenorth>??
15:53-!-glx [~glx@000128ec.user.oftc.net] has joined #openttd
15:53-!-mode/#openttd [+v glx] by ChanServ
16:01-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd
16:01<@Alberth>just give every string a number? you know what strings you have don't you?
16:03<andythenorth>I do yes
16:03<andythenorth>so I can see two routes
16:03<andythenorth>have nmlc cache known strings for a grf (similar to the sprite cache we already have)
16:03<andythenorth>or I can pass in string IDs manually
16:03<andythenorth>either seems fine
16:08<Rubidium>how would you handle strings being removed (not sure how it currently handles sprites are not used anymore)
16:09<andythenorth>walk the output somehow, look for dead strings in the cache (not used in the output)
16:09<andythenorth>(the linked output)
16:09<andythenorth>seems clunky
16:10<andythenorth>or just wait until we run out of IDs, then explode
16:10<andythenorth>let the user delete the cache file :P
16:12<frosch123>make the id a checksum of the string, and hope that no two match :p
16:15<andythenorth>ha
16:15<andythenorth>"what could go wrong?”
16:16<andythenorth>currently IDs are random
16:16<andythenorth>I don’t see much harm in caching them
16:17-!-tycoondemon [~ashnohoe@ip503d7ac1.speed.planet.nl] has joined #openttd
16:20*andythenorth -> bed
16:20<andythenorth>bye
16:20-!-Aristide [~quassel@tok69-5-82-235-150-75.fbx.proxad.net] has joined #openttd
16:21-!-andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth]
16:44-!-Progman [~progman@p57A1B7A2.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
17:05-!-Alberth [~hat@2001:981:c6c5:1:be5f:f4ff:feac:e11] has left #openttd []
17:13<Rubidium>got to love dumping a huge load of numbers into discussions about things "rarely" happening in real life
17:17<frosch123>so, you are visiting rome?
17:17<Rubidium>nope... been there... twice ;)
17:21<frosch123>i assume not for that route though :p
17:23<Rubidium>I once kinda considered taking the Moscow route from Berlin to Amsterdam
17:23<Rubidium>but the layover was way way too long
17:30-!-tokai|mdlx [~tokai@port-92-195-0-5.dynamic.qsc.de] has joined #openttd
17:34-!-tokai|noir [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds]
17:42<frosch123>night
17:42-!-frosch123 [~frosch@frnk-4d00d083.pool.mediaWays.net] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
17:44-!-silenz [~silenz@h88-206-139-26.vokby.se] has joined #openttd
17:44-!-silenz [~silenz@h88-206-139-26.vokby.se] has left #openttd []
17:58-!-Aristide [~quassel@tok69-5-82-235-150-75.fbx.proxad.net] has quit [Remote host closed the connection]
18:10-!-Haube [~michi@37-4-140-17-dynip.superkabel.de] has quit [Ping timeout: 480 seconds]
18:22-!-oskari89 [oskari89@83-102-63-32.bb.dnainternet.fi] has quit []
18:27<Wolf01>'night
18:27-!-Wolf01 [~wolf01@0001288e.user.oftc.net] has quit [Quit: Once again the world is quick to bury me.]
18:33-!-Brumi [~quassel@78-131-41-191.pool.digikabel.hu] has quit []
18:38-!-Pereba [~UserNick@179.180.222.76] has quit [Quit: AdiIRC is updating to v1.9.3 Beta Build (2014/07/08) 64 Bit]
18:39-!-Pereba [~UserNick@179.180.222.76] has joined #openttd
18:47-!-Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Remote host closed the connection]
18:49-!-Midnightmyth [~quassel@93-167-84-102-static.dk.customer.tdc.net] has quit [Ping timeout: 480 seconds]
19:19-!-MTsPony [~marctraid@008-086-128-083.dynamic.caiway.nl] has quit []
19:21-!-HerzogDeXtEr [~flex@i59F6D352.versanet.de] has quit [Quit: Leaving.]
19:54-!-Supercheese [~Superchee@76.178.136.186] has joined #openttd
19:59-!-yorick [~yorick@ip51cd0513.speed.planet.nl] has quit [Remote host closed the connection]
20:06-!-KWKdesign [~KWKdesign@108.61.152.243] has quit [Read error: Operation timed out]
20:06-!-KWKdesign [~KWKdesign@108.61.152.243] has joined #openttd
20:09-!-Supercheese [~Superchee@76.178.136.186] has quit [Read error: Connection reset by peer]
20:09-!-Supercheese [~Superchee@76.178.136.186] has joined #openttd
20:13-!-Supercheese [~Superchee@76.178.136.186] has quit [Read error: Connection reset by peer]
20:13-!-Supercheese [~Superchee@76.178.136.186] has joined #openttd
20:17-!-Supercheese [~Superchee@76.178.136.186] has quit [Read error: Connection reset by peer]
20:17-!-Supercheese [~Superchee@76.178.136.186] has joined #openttd
20:21-!-Supercheese [~Superchee@76.178.136.186] has quit [Read error: Connection reset by peer]
20:21-!-Supercheese [~Superchee@76.178.136.186] has joined #openttd
20:24-!-Supercheese [~Superchee@76.178.136.186] has quit [Read error: Connection reset by peer]
20:24-!-Supercheese [~Superchee@76.178.136.186] has joined #openttd
20:27-!-HerzogDeXtEr [~flex@i59F6D352.versanet.de] has joined #openttd
20:33-!-Supercheese [~Superchee@76.178.136.186] has quit [Quit: Valete omnes]
20:45-!-MTsPony [~marctraid@008-086-128-083.dynamic.caiway.nl] has joined #openttd
20:49-!-KWKdesign [~KWKdesign@108.61.152.243] has quit [Read error: Connection reset by peer]
20:49-!-KWKdesign [~KWKdesign@108.61.152.243] has joined #openttd
20:55-!-Supercheese [~Superchee@76.178.136.186] has joined #openttd
20:59-!-glx [~glx@000128ec.user.oftc.net] has quit [Quit: Bye]
20:59-!-Pereba [~UserNick@179.180.222.76] has quit [Quit: AdiIRC is updating to v1.9.3 Beta Build (2014/07/10) 64 Bit]
21:00-!-Pereba [~UserNick@179.180.222.76] has joined #openttd
21:27-!-HerzogDeXtEr [~flex@i59F6D352.versanet.de] has quit [Quit: Leaving.]
21:30-!-pthagnar [~pthagnar@cpc7-pres17-2-0-cust28.18-3.cable.virginm.net] has quit [Quit: Leaving]
21:53-!-MJP [~mjp@hq.z77.fr] has quit [Ping timeout: 480 seconds]
22:00-!-luaduck is now known as luaduck_zzz
22:18-!-KWKdesign [~KWKdesign@108.61.152.243] has quit [Ping timeout: 480 seconds]
22:18-!-KWKdesign [~KWKdesign@108.61.152.243] has joined #openttd
22:25-!-Hazzard_ [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has joined #openttd
22:32-!-Hazzard [~quassel@c-67-174-253-44.hsd1.ca.comcast.net] has quit [Read error: Operation timed out]
23:27-!-Supercheese [~Superchee@76.178.136.186] has quit [Quit: Valete omnes]
---Logclosed Thu Jul 10 00:00:43 2014