Log for #openttd on 9th July 2014:
Times are UTC Toggle Colours
00:10:26  *** guru3 [] has quit [Read error: Connection reset by peer]
00:10:39  *** guru3 [] has joined #openttd
00:20:50  *** George is now known as Guest1717
00:20:52  *** George [~George@] has joined #openttd
00:26:28  *** Guest1717 [~George@] has quit [Ping timeout: 480 seconds]
00:34:13  *** MJP [] has quit [Ping timeout: 480 seconds]
00:51:09  *** DDR [] has joined #openttd
00:51:34  *** MTsPony [] has quit []
00:52:09  *** MTsPony [] has joined #openttd
00:59:28  *** KWKdesign [] has quit [Ping timeout: 480 seconds]
01:33:45  *** Jerik [] has joined #openttd
01:34:41  *** JerikTelorian [] has joined #openttd
01:50:40  *** glx is now known as Guest1728
01:50:40  *** glx [] has joined #openttd
01:50:43  *** mode/#openttd [+v glx] by ChanServ
01:56:45  *** Guest1728 [] has quit [Ping timeout: 480 seconds]
02:12:03  *** bdavenport [] has joined #openttd
02:12:27  *** glx [] has quit [Quit: Bye]
02:14:11  *** bdavenport [] has quit []
02:19:03  *** luaduck is now known as luaduck_zzz
02:21:47  *** George is now known as Guest1732
02:21:49  *** George [~George@] has joined #openttd
02:22:43  *** KWKdesign [~KWKdesign@] has joined #openttd
02:27:00  *** Guest1732 [~George@] has quit [Ping timeout: 480 seconds]
02:38:04  *** George is now known as Guest1734
02:38:06  *** George [~George@] has joined #openttd
02:43:28  *** Guest1734 [~George@] has quit [Ping timeout: 480 seconds]
02:44:32  *** guru3_ [] has joined #openttd
02:45:18  *** guru3 [] has quit [Read error: Connection reset by peer]
03:02:09  *** HerzogDeXtEr [] has quit [Read error: Connection reset by peer]
03:25:34  *** George is now known as Guest1741
03:25:36  *** George [~George@] has joined #openttd
03:26:14  *** sla_ro|master [slamaster@] has joined #openttd
03:30:53  *** Guest1741 [~George@] has quit [Ping timeout: 480 seconds]
03:35:46  *** Hazzard_ [] has joined #openttd
03:36:05  *** pthug [] has quit [Quit: Leaving]
03:42:12  *** tokai|mdlx [] has joined #openttd
03:42:23  *** tokai|noir [] has quit [Ping timeout: 480 seconds]
03:42:28  *** Hazzard [] has quit [Ping timeout: 480 seconds]
03:55:29  *** tokai [] has joined #openttd
03:55:32  *** mode/#openttd [+v tokai] by ChanServ
03:56:20  *** George is now known as Guest1746
03:56:22  *** George [~George@] has joined #openttd
03:56:22  *** tokai|mdlx [] has quit [Ping timeout: 480 seconds]
03:58:25  *** tokai|mdlx [] has joined #openttd
04:01:53  *** Guest1746 [~George@] has quit [Ping timeout: 480 seconds]
04:03:53  *** tokai [] has quit [Ping timeout: 480 seconds]
04:20:38  *** jrambo [] has joined #openttd
04:24:03  *** KWKdesign [~KWKdesign@] has quit [Read error: Connection reset by peer]
04:24:28  *** KWKdesign [~KWKdesign@] has joined #openttd
04:25:22  *** tokai|mdlx [] has quit [Ping timeout: 480 seconds]
04:29:34  *** tokai [] has joined #openttd
04:29:37  *** mode/#openttd [+v tokai] by ChanServ
04:38:22  *** tokai [] has quit [Ping timeout: 480 seconds]
04:42:34  *** tokai [] has joined #openttd
04:42:37  *** mode/#openttd [+v tokai] by ChanServ
04:43:21  *** George|2 [~George@] has joined #openttd
04:43:21  *** George is now known as Guest1752
04:43:21  *** George|2 is now known as George
04:47:18  *** Guest1752 [~George@] has quit [Ping timeout: 480 seconds]
04:53:12  *** sla_ro|master [slamaster@] has quit []
04:53:12  *** DDR [] has quit [Read error: Connection reset by peer]
04:56:02  *** Eddi|zuHause [] has quit []
04:56:16  *** Eddi|zuHause [] has joined #openttd
05:14:19  *** George is now known as Guest1757
05:14:21  *** George [~George@] has joined #openttd
05:19:40  *** Guest1757 [~George@] has quit [Ping timeout: 480 seconds]
05:33:08  *** George|2 [~George@] has joined #openttd
05:33:08  *** George is now known as Guest1761
05:33:08  *** George|2 is now known as George
05:35:58  *** Guest1761 [~George@] has quit [Ping timeout: 480 seconds]
05:53:10  *** tokai|mdlx [] has joined #openttd
05:56:33  *** tokai|noir [] has joined #openttd
05:56:36  *** mode/#openttd [+v tokai|noir] by ChanServ
05:57:22  *** tokai [] has quit [Ping timeout: 480 seconds]
06:01:52  *** Hazzard_ [] has quit [Ping timeout: 480 seconds]
06:02:22  *** tokai|mdlx [] has quit [Ping timeout: 480 seconds]
06:22:46  *** tokai [] has joined #openttd
06:22:49  *** mode/#openttd [+v tokai] by ChanServ
06:24:52  *** tokai|noir [] has quit [Ping timeout: 480 seconds]
06:25:26  *** chrswk [~chrswk@] has joined #openttd
06:25:52  *** tokai|mdlx [] has joined #openttd
06:32:03  *** tokai [] has quit [Ping timeout: 480 seconds]
06:35:44  *** George|2 [~George@] has joined #openttd
06:35:44  *** George is now known as Guest1770
06:35:44  *** George|2 is now known as George
06:38:42  *** tokai|mdlx [] has quit [Ping timeout: 480 seconds]
06:39:43  *** Guest1770 [~George@] has quit [Ping timeout: 480 seconds]
06:43:38  *** tokai [] has joined #openttd
06:43:41  *** mode/#openttd [+v tokai] by ChanServ
06:44:48  *** Nothing4You [] has quit [Ping timeout: 480 seconds]
06:48:09  *** Nothing4You [] has joined #openttd
06:48:55  *** jonty-comp [] has quit [Read error: Connection reset by peer]
06:49:41  *** Flygon_ [] has quit [Read error: Connection reset by peer]
06:52:25  *** jonty-comp [] has joined #openttd
06:53:53  *** tneo [] has quit [Ping timeout: 480 seconds]
06:54:46  *** tneo [] has joined #openttd
06:54:48  *** Osai^2 [] has quit [Ping timeout: 480 seconds]
06:54:48  *** Yexo [] has quit [Ping timeout: 480 seconds]
06:55:16  *** Yexo [] has joined #openttd
06:55:16  *** Osai [] has joined #openttd
07:00:16  *** Flygon [] has joined #openttd
07:01:13  *** Myhorta [] has joined #openttd
07:21:16  *** JerikTelorian [] has quit [Read error: Connection reset by peer]
07:21:16  *** Jerik [] has quit [Read error: Connection reset by peer]
07:25:33  *** Myhorta [] has quit [Ping timeout: 480 seconds]
07:28:07  *** Myhorta [] has joined #openttd
07:30:08  *** Myhorta [] has quit []
07:36:57  <planetmaker> moin
08:01:07  *** guru3_ is now known as guru3
08:03:50  *** DigitalFox [] has joined #openttd
08:03:58  <DigitalFox> morning :)
08:04:13  <DigitalFox> Ok this is driving nuts and I need help...
08:04:15  <planetmaker> o/
08:04:17  <V453000> mooin
08:04:30  <DigitalFox> I'm compiling zbase in nml
08:04:35  <DigitalFox> no errors
08:04:41  <planetmaker> I also heard that nuts trains usually are driving. Except when using wetrail ;)
08:04:43  <DigitalFox> i change the md5 of zbase
08:05:00  <DigitalFox> i start openttd and it says it's corrupt :\
08:05:27  <DigitalFox> no graphics are missing, sprites corruption, just like any nnormal game
08:05:27  <planetmaker> DigitalFox, the "md5sum" in the zbase.obg is not a real md5sum but the value obtained by grfid -m
08:05:48  <planetmaker> grfid is part of the grfcodec package
08:06:17  <DigitalFox> ok, so I get md5 value from there?
08:06:43  <planetmaker> grfid is a programme. Which will give you the value
08:07:11  <DigitalFox> I'm doing a fun project, merging zbase + biggui + 32 ez build :o
08:07:22  <planetmaker> how did you compile zbase, btw? If you call make, it should automatically (try to) call grfid.
08:07:40  <DigitalFox> I'm in Windows ;)
08:07:41  <planetmaker> and thus properly re-generate zbase.obg
08:08:16  <planetmaker> well, the build process does not lend itself well to windows
08:08:28  <planetmaker> the makefile explains what you got to do. Step by step :P
08:08:40  <DigitalFox> Well it's more time consuming, but it's working :)
08:10:41  <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 :\
08:11:03  <planetmaker> all "md5sums" for grfs are md5sums only over the pseudosprite part. Thus grfid programme is kinda a 'must have'
08:11:17  <planetmaker> zbase has absolutely no license mess. Nice and clean gpl v2
08:11:37  <DigitalFox> planetmaker: trying grfid right now, major thank you!
08:12:31  <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
08:13:37  <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 :)
08:13:43  <DigitalFox> Again thank you planetmaker :)
08:14:07  <planetmaker> what is "EZ"? Zoom levels are nothing special really. Just bigger sprites
08:14:38  <DigitalFox>
08:15:46  <planetmaker> interesting. The license part 2 is not covered by the terms of usage of the DevZone ;)
08:17:17  <planetmaker> I agree, that is a total mess there
08:18:54  <DigitalFox> yeah + the fact I hate licenses, I mean I know they are required but just pain the ass :\
08:19:16  <planetmaker> DigitalFox, no licenses basically means it applies what is listed in section2 of *that* copying file
08:19:38  <planetmaker> i.e.: you may do nothing. No copying, no distribution, no modification
08:20:24  <planetmaker> a license *always* means: "here, I give you more rights than you would have without this license"
08:22:09  <peter1138> "Before release 1.2.0 of OpenTTD, an official patch to OpenTTD named "Extra zoom" existed"
08:22:15  <peter1138> "official patch"
08:22:31  <peter1138> What makes a patch official?
08:24:23  <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.
08:25:17  <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
08:25:26  <planetmaker> Thus no-one may (re-)use them
08:25:37  <planetmaker> like that very project you linked obviously...
08:25:53  <DigitalFox> And why I refereed the licenses fiasco ;)
08:26:14  <DigitalFox> I jump in search of 32bpp sprites from coop to
08:26:27  <planetmaker> thus I always say: make it gpl v2. That's like OpenTTD. And all will be fine, if everyone used it
08:26:45  <planetmaker> yeah. That path lies pain. License pain
08:27:09  <planetmaker> those sprites you found in the 32bpp-ez-project are taken from there, if not all, then at least in parts
08:29:46  <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...
08:30:01  <DigitalFox> *You have
08:31:01  <DigitalFox> If they shared the art in public with the intention of being used by everyone then why not use it?
08:31:25  <V453000> because they did not state that intention in a license file
08:31:26  <V453000> simple
08:32:23  <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?
08:32:51  <peter1138> The consequences of being a dick about licensing your work...
08:33:12  <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
08:33:13  <blathijs> That's how copyright law works, though.
08:33:19  <peter1138> What's the timespan for public domain these days?
08:33:25  <V453000> 70yrs?
08:33:55  <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)
08:34:03  <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.
08:34:24  <peter1138> Patchwork spritesets look terrible...
08:34:27  <V453000> + that
08:35:00  <peter1138> Big trick with 32bpp: you still need a palette.
08:35:09  <peter1138> Just, not in the 8bpp sense.
08:35:40  <V453000> myeah, or rendering with the same/similar materials and same light settings
08:36:09  <peter1138> Same thing really, your materials are your palette.
08:36:36  <V453000> not exactly but yeah :)
08:43:38  <planetmaker> 70 years past death of creator
08:43:43  <V453000> AHA
08:43:45  <V453000> :D
08:43:59  <V453000> so even if you kill them quickly you will still have to wait :P
08:44:29  <V453000> tleast you can spend the first XX years of waiting in jail
08:44:34  <V453000> good time killer
08:46:42  <planetmaker> well. In principle you can draw 32bpp just fine. 32bpp does not imply rendering :)
08:47:03  <peter1138> planetmaker, "or" ;)
08:47:24  <V453000> well sure :)
08:48:00  <peter1138> Line-art OpenTTD...
08:49:54  <peter1138>
08:49:57  <peter1138> heh
08:50:22  <V453000> exactly the kind of pixel art I find wtf
08:51:32  <V453000> also am not sure if it is compatible with the size of x1 vehicles in openttd :P
08:51:43  <peter1138> :D
08:53:16  <peter1138>
08:53:17  <peter1138> Ehhhh
08:54:07  <DigitalFox> For someone like me that didn't sleep, that previous image on my 27" screen just melted my eyes
08:54:17  <V453000> thats better :D
08:55:16  <planetmaker>
08:56:17  <V453000> :)
08:56:34  <V453000> is that openttd sizes?
08:57:19  <planetmaker> sadly not directly 192px
08:57:25  <planetmaker> instead of 64/128/256
08:57:41  <DigitalFox> planetmaker: GRFid did the trick. Now I can go to bed dreaming with offsets :o
08:58:39  <planetmaker> V453000, but maybe I talk to him (again). He's the  guy I got the sprites for the comic houses from. So... maybe :)
08:58:44  <planetmaker> More time needed, though .(
08:58:49  <V453000>  : D
09:33:48  *** MJP [] has joined #openttd
09:37:20  *** Yotson [~Yotson@2001:980:6ac8:1:c9e3:31c1:9fa6:48e6] has joined #openttd
09:45:20  <DigitalFox> Alright, thanks guys. bye!
09:45:39  *** DigitalFox [] has quit [Quit: ChatZilla [Firefox 30.0/20140605174243]]
10:37:27  *** Kurimus [] has quit []
10:47:53  *** TheMask96 [] has quit [Ping timeout: 480 seconds]
10:51:06  *** Myhorta [] has joined #openttd
10:52:22  *** TheMask96 [] has joined #openttd
11:21:30  <peter1138> Hmm, fail2ban can be handy... and can also be a pain in the bum...
11:22:12  <V453000> bum bum
11:23:33  *** tokai|mdlx [] has joined #openttd
11:26:43  *** tokai [] has quit [Ping timeout: 480 seconds]
11:26:58  *** pthagnar [] has joined #openttd
11:31:06  *** Supercheese [~Superchee@] has quit [Read error: Connection reset by peer]
11:31:37  *** Supercheese [~Superchee@] has joined #openttd
11:36:17  *** xintron [~xintron@2a02:c200:0:10:2:1:5488:1] has joined #openttd
11:37:03  <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?
11:37:16  *** tokai|noir [] has joined #openttd
11:37:19  *** mode/#openttd [+v tokai|noir] by ChanServ
11:42:02  <Taede> set max_aircraft to 0
11:42:08  <Taede> using rcon
11:42:12  <Taede> set
11:43:13  *** tokai|mdlx [] has quit [Ping timeout: 480 seconds]
11:46:46  <xintron> Ah, that's right yeah.
11:46:47  <xintron> Thanks!
11:51:54  *** KWKdesign [~KWKdesign@] has quit [Read error: Connection reset by peer]
11:52:28  *** KWKdesign [~KWKdesign@] has joined #openttd
11:53:15  *** yorick [] has joined #openttd
12:03:05  *** KWKdesign [~KWKdesign@] has quit [Read error: Connection reset by peer]
12:03:16  *** KWKdesign [~KWKdesign@] has joined #openttd
13:23:48  *** Myhorta [] has quit [Ping timeout: 480 seconds]
13:27:25  *** Myhorta [] has joined #openttd
13:28:20  <xintron> Isn't there a config "generator" online as well somewhere? :)
13:30:29  <Taede> used to be, not sure if it still works
13:30:55  <xintron> Is the normal way to go about it to start a game locally, copy the config and then put it on the server?
13:31:23  <Taede> normal is subjective
13:31:43  <Taede> personally, i'd create a map (config newgrf et all), save, then transfer the savegame to the server
13:32:57  *** xT2 [] has joined #openttd
13:33:44  <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?
13:34:20  <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)?
13:37:00  <Taede> MTsPony, they'll all try to listen on the same port, so only the first will work
13:37:22  <Taede> the 2nd and after will refuse to run (assuming dedicated) telling the port is already in use afaik
13:37:47  <MTsPony> i ment client wise
13:37:53  <MTsPony> kinda
13:38:58  *** ST2 [] has quit [Ping timeout: 480 seconds]
13:38:58  *** xT2 is now known as ST2
13:39:04  <Taede> xintron, adv settings -> vehicles shows it for me
13:39:18  <Taede> make sure you have 'all setting stypes' selected
13:40:01  <xintron> Taede, Oh, how did I manage to not see that? :S
13:40:04  <xintron> Thanks :)
13:43:22  <planetmaker> xintron, also the adv. settings have a search box :)
13:44:35  <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
13:44:57  <MTsPony> kk thx
13:45:36  <MTsPony> another Q, what would cause it to crash if you turn on full,anmations? lol
13:46:05  <MTsPony> could that be sprite cache related?
13:46:20  <planetmaker> the crash.log would maybe tell you?
13:46:31  <planetmaker> you know, this is not a quiz channel
13:47:23  <planetmaker> where we guess how you possibly could create a crash under not fully described circumstances, software versions and settings
13:48:31  <planetmaker> if you have actual crash data, that's something way more interesting
13:49:03  <planetmaker> especially if you can describe a way so that anyone can reproduce it
13:50:03  *** HerzogDeXtEr [] has joined #openttd
13:50:59  <MTsPony> odd. it only does it when i use a specific openttd.cfg
13:51:10  <MTsPony> so i guess that knda solves the problem
13:51:30  <planetmaker> not really. Would be interesting to see what causes it to crash
13:51:49  <planetmaker> it's a workaround at best ;)
13:52:16  *** luaduck_zzz is now known as luaduck
13:53:48  <MTsPony> well
13:53:55  <MTsPony> what file do u,want to,check?
13:54:11  <MTsPony> sorrymabout the crappy typing im on a tabletn:p
13:54:55  <planetmaker> those which openttd tells you to communicate: crash*
13:55:30  <planetmaker> or do you use an iPad or android version?
13:55:52  <MTsPony> ipad, im connected to my desktop tho,with remote desktop
13:56:08  <MTsPony> were talking desktop version, r26335 to br exact
13:57:13  <MTsPony> im always getting these spritecache errors tho
13:57:29  <MTsPony> i tried increasing to 256 or 512 it still gives me the same :/
13:57:49  <Diablo-D3> wait, openttd crashes?
13:57:50  <Diablo-D3> bullshit
14:02:14  <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
14:02:46  <MTsPony> trying to increase it gives the same error.
14:02:52  <MTsPony> i got plenty of memory
14:03:09  <MTsPony> and im just usin 8bpp anim blitter
14:04:04  <planetmaker> lol. It's just that: too little memory
14:06:30  <MTsPony> really now.
14:06:40  <MTsPony> i have 4-5gb of free mem.
14:09:42  <Diablo-D3> heh
14:09:43  <Diablo-D3> I have
14:09:54  <Diablo-D3> about 29.5gb of free mem
14:10:33  <MTsPony> lol.
14:11:05  <MTsPony> either way it should not fail while trying to allocate 512mb or 1gb for spritecache
14:11:14  <Diablo-D3> 31030064
14:11:16  <Diablo-D3> bytes :D
14:12:05  <planetmaker> you realize that you err by a factor of 1000, Diablo-D3 ?
14:12:58  <Diablo-D3> er, maybe thats kb
14:13:14  <Diablo-D3> yeah free does kb
14:15:27  <Xaroth|Work> or just free -m for mb
14:17:58  <Diablo-D3> or -g apparently
14:18:04  <Diablo-D3> I dont remember those flags existing
14:18:08  <Diablo-D3> dear god how old am I =/
14:21:39  <planetmaker> 13?
14:22:30  <Diablo-D3> old enough to remember when free didnt have fancy flags like that
14:25:15  *** Hazzard [] has joined #openttd
14:55:30  *** Myhorta [] has quit [Ping timeout: 480 seconds]
15:27:46  *** chrswk [~chrswk@] has quit [Read error: Connection reset by peer]
15:43:15  *** TheMask96 [] has quit [Ping timeout: 480 seconds]
15:43:45  <xintron> Why are graphics needed to run a dedicated server?
15:44:09  *** TheMask96 [] has joined #openttd
15:44:24  <xintron> And can the server run one set and the clients whatever they please?
15:44:28  <planetmaker> xintron, the grfs contain more than graphics. e.g. some height map snippets for map creation
15:44:48  <planetmaker> and yes, doesn't matter who uses which base set
15:45:05  <xintron> Ok, that makes sense. Thanks!
15:47:17  *** KWKdesign [~KWKdesign@] has quit [Read error: Operation timed out]
15:47:53  *** KWKdesign [~KWKdesign@] has joined #openttd
15:47:57  *** Progman [] has joined #openttd
15:58:21  <Eddi|zuHause> man i raised my highscore from 150k to 170k, but still no 16384 :(
16:13:07  *** Kurimus [] has joined #openttd
16:29:38  *** Stimrol [] has quit [Ping timeout: 480 seconds]
16:30:34  *** Stimrol [] has joined #openttd
16:59:48  *** efess [] has quit [Read error: Operation timed out]
17:09:05  *** Netsplit <-> quits: tparker, eQualizer, Extrems, Ttech, Eddi|zuHause, @Belugas, Xaroth, @orudge, Xaroth|Work, jonty-comp,  (+34 more, use /NETSPLIT to show all of them)
17:10:41  *** Netsplit over, joins: Sacro, jonty-comp, lobster, @orudge, dyrim, Xaroth|Work, Vadtec, ccfreak2k, davidstrauss_, eQualizer (+34 more)
17:18:16  *** Alberth [~hat@2001:981:c6c5:1:be5f:f4ff:feac:e11] has joined #openttd
17:18:20  *** mode/#openttd [+o Alberth] by ChanServ
17:34:55  *** Myhorta [] has joined #openttd
17:36:22  *** Wolf01 [] has joined #openttd
17:36:41  *** Midnightmyth [] has joined #openttd
17:36:50  <Wolf01> hello
17:37:28  <Eddi|zuHause> you destroyed the green!
17:37:36  <Wolf01> :(
17:37:54  <Alberth> luckily, eddi is green :)
17:38:08  <Eddi|zuHause> moderately :p
17:39:51  <planetmaker> alberth is greener than turquoise Eddi|zuHause ;)
17:40:09  <Alberth> oh :)
17:40:17  <Eddi|zuHause> Alberth is clearly red
17:40:18  <planetmaker> hi hi :)
17:40:38  * Alberth feels very green, does that count?
17:42:01  <planetmaker> ;)
17:42:14  <planetmaker> feeling green counts, too, yes
17:42:15  *** tycoondemon [] has quit []
17:43:37  <planetmaker> luckily and strangely enough, the colours are nicely persistent :)
17:44:18  *** frosch123 [] has joined #openttd
17:44:40  <planetmaker> now yellow joined ;) quak :)
17:44:58  <Alberth> hai yellow :)
17:44:59  <frosch123> yellow? green!
17:45:08  <Alberth> blue here!
17:45:24  <frosch123> your clients are wrong
17:45:33  *** Haube [] has joined #openttd
17:45:35  <DorpsGek> Commit by translators :: r26681 /trunk/src/lang (gaelic.txt polish.txt) (2014-07-09 17:45:26 UTC)
17:45:35  <planetmaker> your colour perception is! ;)
17:45:36  <DorpsGek> -Update from WebTranslator v3.0:
17:45:37  <DorpsGek> polish - 48 changes by Kilian
17:45:38  <DorpsGek> gaelic - 4 changes by GunChleoc
17:46:06  <Alberth> tbh as long as everybody has a different colour, I am happy
17:46:26  <planetmaker> yeah :)
17:49:51  *** oskari89 [] has joined #openttd
17:50:21  <Alberth> oskari89 never says anything, no idea what his colour is
17:50:28  <planetmaker> where did you find juanjo's patches yesterday, frosch123 ?
17:52:03  <oskari89> Never says anything? :)
17:52:10  <frosch123> planetmaker: flyspray
17:52:11  <Rubidium> pff... it's all one shade of grey
17:52:26  <frosch123> opened 2 days ago
17:52:50  <planetmaker> oh. I thought elsewhere as there was no FS#
17:53:06  <planetmaker> missed it on FS
17:53:16  <frosch123> yeah, missed the fs :)
17:53:29  <frosch123> but there was nothing interesting in the task either, except the bare patches
17:53:31  <Alberth> hi oskari89 :)
17:53:38  *** MJP [] has quit [Read error: Connection reset by peer]
17:53:50  <frosch123> but bugs the fs reference is important, so you get the test case in the future :)
17:53:59  <oskari89> hi Alberth :)
17:54:18  <planetmaker> yeah, no worries :)
17:54:40  <planetmaker> just curious whether you found a new secret patch source :)
17:54:58  <frosch123> shall i link you to some? :p
17:55:21  <planetmaker> :D
17:55:24  <Alberth> all those are definitely not the secret one :p
17:55:47  <frosch123> he, it's quite a secret what i bookmarked
17:56:52  *** andythenorth [] has joined #openttd
17:59:17  <planetmaker> frosch123, that's what you want to believe
17:59:31  <andythenorth> o/
17:59:36  <andythenorth> whatever you believe, snopes it
17:59:38  <andythenorth> just in case
17:59:42  <planetmaker> Shall I ask the National Storage Association for the backup?
18:00:16  *** MJP [] has joined #openttd
18:00:32  <planetmaker> \o
18:04:13  *** DigitalFox [] has joined #openttd
18:04:33  <DigitalFox> Hi :)
18:04:42  <andythenorth> are we making anything?
18:05:25  <andythenorth> oops
18:05:31  <Alberth> conversation at least, and probably tea
18:06:37  <andythenorth> consists?
18:06:38  <andythenorth> faster nml?
18:06:42  <andythenorth> Squid?
18:06:43  <Alberth> it looks like a few toy trains, so small, compared to the mountain
18:06:45  <andythenorth> a new GS?
18:07:15  * Alberth takes #2
18:07:33  <Alberth> but it's not going anywhere fast I suspect
18:07:39  <andythenorth> wondered about that
18:08:09  <andythenorth> I’m not very +1 to continuing my hacky speed up approach
18:08:13  <andythenorth> more -1
18:08:19  <andythenorth> as it requires a patched nml
18:08:32  <andythenorth> but it did look promising
18:08:38  <Alberth> we have one forked nml, you can add another one :p
18:09:59  <Alberth> I started a conversation last sunday morning in #openttdcoop.devzone, but that didn't end in anything useful either
18:10:22  <andythenorth> no logs there :)
18:10:23  <Alberth> other than V getting happy about his yetis :)
18:11:17  <Alberth> andythenorth: oh???  look what I found then!
18:11:26  <andythenorth> :o
18:12:00  <andythenorth> oh deep clones :)
18:12:01  <andythenorth> I see
18:14:08  <andythenorth> did you get anywhere with faster parser?
18:16:01  <Alberth> I wrote a faster scanner, and scanning is now reduced to 8 seconds with FIRS
18:16:09  <andythenorth> previously was?
18:16:14  <Alberth> parsing takes 16 seconds
18:16:20  <Alberth> scanning was 30 iirc
18:16:45  <Alberth> it does 1.6E06 python calls in that 8 seconds
18:17:11  <Alberth> total execution time is 1:17  iirc
18:17:18  <andythenorth> I wonder how acceptable my crazy ‘extend global constants’ patch is?
18:17:49  <Alberth> thus, if you manage to completely drop scanning and parsing, you'll end up just below the 1:00
18:18:11  <andythenorth> if I also only compile changed files...
18:18:33  *** Mrucux7 [] has joined #openttd
18:18:34  <andythenorth> there are 62 industries...
18:18:37  <Alberth> then any scanning and parsing is fine, I think
18:19:02  <andythenorth> I’d rather solve the tractable problem than wait for the perfect solution
18:19:10  <andythenorth> but I don’t know if my approach sucks :)
18:19:33  <andythenorth> compiling 1 industry not 62 suggests up to 62x improvement - overhead of setup
18:20:22  <Alberth> yep, which means a few seconds
18:20:31  <Alberth> rather than just < 1:00
18:21:07  <andythenorth> so I have been manually pushing constants into json, and then extending global_constants
18:21:13  <andythenorth> which seems wrong but works
18:21:15  <Alberth> only minor issue is the total lack of underlying tools and file format
18:21:55  <Alberth> not to mention that nml is not designed for partial translation
18:22:12  <andythenorth> I am treating translation separately
18:22:22  <andythenorth> admittedly it is 100% unsolved :P
18:24:53  <DigitalFox> So I'm changing the faces sprites to 32bpp (not all are yet changed). Here's what I'm getting now: and here's how it should look like:
18:24:55  <DigitalFox> My code:
18:24:57  <DigitalFox> base_graphics spr805( 805, "sprites/gui/small_gui.png") { [ 354, 1000, 92, 119, 0, 0] }
18:24:58  <DigitalFox> alternative_sprites(spr805, ZOOM_LEVEL_NORMAL, BIT_DEPTH_32BPP, "sprites/gui/faces/805_z1.png") { [0, 0, 134, 125, 0,  0] }
18:25:00  <DigitalFox> 134, 125 is the real dimension of the png.     Original PNG:
18:25:01  <DigitalFox> So where am I messing this up? It's huge :o
18:27:57  <frosch123> ZOOM_LEVEL_NORMAL?
18:30:09  <frosch123> i have no idea what weird zoom level your original sprite is
18:30:51  <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?
18:31:52  <Alberth> s/expression parser/expression handling rewriting/  probably, but close enough :)
18:31:55  <andythenorth> it also reduces the pool of maintainers imo
18:31:59  <andythenorth> maybe not
18:32:05  <planetmaker> sorry, you're right, yes
18:32:25  *** Mrucux7 [] has quit [Quit: Page closed]
18:33:39  <planetmaker> I was not sure what conclusion to draw. I only see two alternatives, both not exactly satisfactorily:
18:34:10  <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
18:34:21  <planetmaker> b) basically rewrite NML in C. Oh well...
18:35:13  <Alberth> c) rewrite nml in python is also an option, but arguably not better than b)
18:35:37  <andythenorth> same work, slower?
18:35:37  <Alberth> although it's finished much sooner probably :)
18:35:53  <Alberth> you can write Python more quickly
18:36:05  <andythenorth> whatever the implementation, partial compiles will always be faster?  Do we think?
18:36:20  <Rubidium> what part of NML is the real bottleneck?
18:36:33  <Rubidium> is it the parsing/making the AST, or is it something else?
18:37:05  *** jinks [~jinks@] has quit [Quit: ZNC -]
18:37:06  <Alberth> Rubidium: expression tree reduction, it seems; if you ignore parsing
18:38:00  <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
18:38:03  *** jinks [~jinks@] has joined #openttd
18:38:19  <Alberth> total 1:10-1:15 or so
18:38:38  <Alberth> and a HUGE amount of memory used
18:39:01  <Alberth> which is perhaps the deep-copying of the expressions while reducing them
18:39:06  <planetmaker> Alberth, would it get better maybe, if the deep cloning would be replaced by references?
18:39:13  <planetmaker> s/cloning/copying/
18:39:39  <Alberth> planetmaker: it would probably, as you also reduce garbage collection stuff
18:39:54  <Rubidium> so try that approach ;)
18:39:59  <planetmaker> hm :)
18:39:59  <Alberth> however, you must be sure the shared objects are not modified
18:40:10  <planetmaker> which is the tricky bit here
18:40:34  <Rubidium> why can't shared objects be reduced?
18:40:39  <Alberth> to establish that with 100% certainty, it is
18:40:57  <Rubidium> shouldn't reducing yield the same?
18:41:17  <Alberth> Rubidium: you can, but you should not do in-place modifications in them, or you crate havoc with the other uses
18:41:42  <Alberth> which is not easy to establish whether or not that happens in the code
18:42:03  <Alberth> as far as I know, at least
18:42:13  <Rubidium> also, why so many calls to reduce. Isn't it needed just once?
18:42:54  <Alberth> it's a recursive method, over all nodes in the expressions
18:43:07  <Alberth> as most of nml is expressions, that a lot of calls
18:43:37  <Alberth> also, the compiler constructs rewrites as expressions, and reduces those
18:45:03  <Alberth>  for example
18:45:10  *** Chrill [] has joined #openttd
18:46:23  <Alberth> ie it uses expression as basic notion instead of "number"
18:46:24  <Rubidium> can't you cache everything that has been reduced? An then prevent a second attempt?
18:47:00  <Alberth> while the code may make in-place modifications?
18:47:51  <Rubidium> don't know... I'm just throwing stupid ideas in the air. Maybe one sticks
18:48:12  <Rubidium> the .reduce() does return some expression, right?
18:48:49  <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
18:49:03  <Alberth> .reduce returns an expression indeed
18:49:35  <Alberth> which is eventually translated to a sequence of actions
18:50:05  <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
18:50:48  <Alberth> you do need to do it; it reduces to see what case it has, and how to rewrite
18:51:54  <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
18:51:55  <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
18:52:16  *** Supercheese [~Superchee@] has quit [Quit: Valete omnes]
18:52:30  <Alberth> ConstantNumeric does exactly that
18:52:31  *** Pereba [~UserNick@] has joined #openttd
18:52:57  <frosch123> what does it need to change the deep-copy into a shallow-copy?
18:53:08  <frosch123> is it something one can try to see what breaks?
18:53:26  <frosch123> is it 10 lines or 1000 lines? :p
18:54:13  <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
18:54:38  <Rubidium> hmm... deep copy of an expression. Does that mean that the complete subtree is cloned?
18:54:41  <Alberth> so it may be a few lines in the end, but you need to check every "new" call
18:55:05  <Alberth> Rubidium: yes, recursively, bottom up
18:55:54  *** efess [] has joined #openttd
18:55:55  <Alberth>   <-- at every binary operator: first step, reduce the childs
18:56:19  <Rubidium> so that's quite O(2^n)-ish; it doubles in amount of work for every extra level in the AST
18:56:47  <Alberth> very much so
18:57:25  <Alberth> the walk in itself is not that bad, if you would not actually create a new node on the way back
18:58:13  <Alberth> although if you examine a node, do a rewrite by adding a few nodes, and call .reduce again...  :)
18:58:30  <Alberth> heaps and heaps of time that you can save there :p
18:58:54  <Rubidium> is the AST really a tree, or is it rather a DAG (I hope there's no recursion allowed)
18:59:27  <Rubidium> i.e. is a helper function cloned or referenced?
19:00:19  <Alberth> don't know the answer to that
19:00:44  <Rubidium> if it is referenced, then I can imagine using deep copies. Otherwise (in the pure AST case) those deep copies are just pointless
19:01:02  <Alberth> parser doesn't hand out the same object twice, as the position is different each time
19:02:31  <Alberth> indeed, the question is thus how to decide what case we have
19:03:11  <Alberth> it's not simple to find all write operations to a class
19:03:38  <Alberth> at many points, it's not even clear what object types are possible there
19:03:50  <Rubidium> <- what?!?
19:04:10  <Alberth> :D
19:04:24  <planetmaker> :)
19:04:33  <planetmaker> snowlinemod
19:04:33  <Alberth> wanted a sinus snowline curve, anyone?  :D
19:04:43  * planetmaker whistles
19:04:48  *** Myhorta [] has quit [Ping timeout: 480 seconds]
19:04:58  <Alberth> oh, I guessed right, apparently :)
19:05:34  <Alberth> I can also imagine uses for that in the multi-angle sprites of eddi
19:08:02  <Alberth> but from a compiler point of view, it's a harmless constant
19:09:11  <Rubidium> yeah
19:09:16  <Rubidium> it just amazed me though
19:10:36  <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
19:10:58  <planetmaker> :P
19:11:01  <Rubidium> my English is crap today
19:11:04  <frosch123> compile time randomness? :p
19:12:20  <planetmaker> here's the compile-time random const number: 42
19:13:24  <Rubidium> planetmaker: rather 4 ->
19:13:35  <frosch123> hmm, rb was faster
19:13:48  <planetmaker> or that :)
19:14:12  <Alberth> part of the problem is perhaps also the cpp pre-processing
19:14:29  <planetmaker> in what way, Alberth ?
19:14:40  <planetmaker> that it adds several types of comment lines?
19:14:41  <Alberth> you cannot do calculations in cpp, so expressions get expanded fully, and thrown into nml
19:15:01  <Alberth> at every point where the value is needed
19:15:22  <planetmaker> ok, but... how is that a cpp preprocessing problem? You mean, cpp should just place it there as constant?
19:15:36  <Alberth> so nml has to perform the same reduction many times
19:15:41  <planetmaker> had I no cpp or other pre-processor I'd also write it such. Just preceeding it by like
19:15:48  <planetmaker> global_var1 = 4
19:15:55  <planetmaker> global_var2 = 1950
19:15:56  <frosch123> where does firs copy those constants?
19:16:21  <frosch123> where does it have constant expressions in macros?
19:16:39  <frosch123> (non-trivial expressions, that is)
19:18:25  <andythenorth> hmm Alberth where are those in FIRS?
19:18:30  *** Chrill [] has left #openttd []
19:19:06  <Alberth> it's all expressions or part of expressions, that you see twice or more often
19:19:46  <Alberth> if you'd write that manually, you would do the computation one time, and re-use the stored result
19:20:09  <Alberth> tbh I don't know if nml does such reductions
19:20:22  <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
19:20:22  <planetmaker> ILETYPE_DESERT) ) );
19:20:47  <andythenorth> that’s one of the more simple ones :P
19:20:47  <planetmaker> that's mostly inserted by a cpp macro, I recon. Coming from a template with a few parameters
19:21:00  <Alberth> at the very least it parses and reduces the same expressions over and over again
19:21:09  <andythenorth> and over and over
19:21:22  <Alberth> if you want to eliminate double calculations, that's more work
19:21:35  <andythenorth> doesn’t nfo have some way to share varaction 2?
19:21:43  * andythenorth ponders
19:22:01  <frosch123> there is nothing in that expresion, that could be evaluated with a preprocessor
19:22:16  <Alberth> maybe nml is wrong?
19:22:37  <andythenorth> procedures....
19:22:43  <Alberth> I don't know enough of the target language to see other solutions
19:22:47  <planetmaker> ah... the nml I look at is already the output of gcc. So...
19:22:54  <andythenorth> all the terrain crap could be one procedure, instead of repeated in every spritelayout...
19:23:16  <frosch123> i thought you meant stuff like "2 * 3 + 5"
19:23:30  <frosch123> but in above example, there are variables in every node
19:23:37  <Alberth> that too, but it doesn't happen much, probably :)
19:23:42  <frosch123> so, nothing that can be evaluated at compile time
19:24:34  <Alberth> if you throw that into nml enough times, it will also be slow, but it takes more work  :)
19:24:44  <planetmaker> switch (FEAT_INDUSTRIES, SELF, THIS_ID(check_availability), current_date) {
19:24:44  <planetmaker> 	date(THIS_MIN_YEAR,1,1) .. date(THIS_MAX_YEAR,12,31): THIS_ID(available_game_mode);
19:24:44  <planetmaker> 	return CB_RESULT_IND_NO_CONSTRUCTION;
19:24:44  <planetmaker> }
19:25:55  <Alberth> you wouldn't want to build anything before the start of the world nor after it!  :D
19:26:00  *** Brumi [] has joined #openttd
19:26:06  <planetmaker> yep :P
19:26:38  <planetmaker> the constant defined indeed make that check *slightly* pointless
19:26:40  <Alberth> I do wonder why the name of the switch etc is in the parameter list instead of in front of it
19:27:08  <Alberth> ie THIS_ID(check_availability) = switch ( ...)
19:27:35  <Alberth> this is mostly just wasting openttd time rather than nml time
19:27:44  <andythenorth> all of that CPP could be fixed by me (convert to python templates)
19:27:44  <planetmaker> hm?
19:27:58  <andythenorth> I’ve been leaving it alone, on the basis “it ain’t broke"
19:28:39  <Alberth> technically it ain't, it just a big 13MB pile of stuff to work through
19:28:50  <andythenorth> changing things = new bugs
19:28:58  <andythenorth> especially on a slow compile :P
19:29:17  <planetmaker> the check for availability between 0 and 5000000 also shows there might be cases with bit rot ;)
19:29:19  <Alberth> and whether this is caused by bad use of cpp or nml lacking some feature, I don't know
19:30:00  <andythenorth> it is a blunt use of CPP imo
19:30:09  <Alberth> planetmaker: such things happen when you introduce a concept like availability over time
19:30:22  <Alberth> you get new edge cases where the check is not useful
19:30:42  <planetmaker> of course, I know :)
19:30:59  <Alberth> and you never find them unless you read the generated code :)
19:31:13  <planetmaker> hard to avoid, if you want to spare time programming and not special-case everything
19:31:36  <Alberth> yep
19:31:43  <andythenorth> it was a mass conversion from nfo too
19:32:03  <andythenorth> historical raisins
19:32:25  <planetmaker> oh, there's nothing left of that origin, I think
19:32:39  <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
19:32:51  <planetmaker> it really has been re-written completely in NML. And now partily in pynml :)
19:34:43  <Alberth> obviously, if you can cache reductions, you can detect such duplicates too
19:35:01  <planetmaker> more memory usage :)
19:35:37  <Alberth> if you make every expression and sub-expression unique, yes
19:36:18  *** Yotson [~Yotson@2001:980:6ac8:1:c9e3:31c1:9fa6:48e6] has quit [Quit: .]
19:36:21  <Alberth> I don't believe you manage that  in a real newgrf :)
19:38:23  <Alberth> every sprite at a different position :p
19:39:40  *** DigitalFox [] has left #openttd []
19:40:15  <planetmaker> hm :)
19:40:25  <planetmaker> I don't want to try for any non-trivial NewGRF
19:41:26  <Alberth> it would be very unique, every engine its own stats + rules :p
19:43:18  *** KWKdesign [~KWKdesign@] has quit [Read error: Operation timed out]
19:43:54  *** KWKdesign [~KWKdesign@] has joined #openttd
19:44:41  <Alberth> so in practice, it'll work out, what you gain on less expression duplicates against more cache + detection data
19:52:04  <andythenorth> so for string IDs
19:52:21  <andythenorth> - look in a cache file for the string ID, if not present, assign new random ID
19:52:25  <andythenorth> - cache ID in cache file
19:52:41  <andythenorth> - on exit of compile, garbage collect any dead strings (check the output)
19:52:42  <andythenorth> ??
19:53:14  *** glx [] has joined #openttd
19:53:17  *** mode/#openttd [+v glx] by ChanServ
20:01:31  *** Myhorta [] has joined #openttd
20:01:53  <Alberth> just give every string a number?  you know what strings you have don't you?
20:03:00  <andythenorth> I do yes
20:03:06  <andythenorth> so I can see two routes
20:03:26  <andythenorth> have nmlc cache known strings for a grf (similar to the sprite cache we already have)
20:03:32  <andythenorth> or I can pass in string IDs manually
20:03:38  <andythenorth> either seems fine
20:08:50  <Rubidium> how would you handle strings being removed (not sure how it currently handles sprites are not used anymore)
20:09:33  <andythenorth> walk the output somehow, look for dead strings in the cache (not used in the output)
20:09:44  <andythenorth> (the linked output)
20:09:47  <andythenorth> seems clunky
20:10:08  <andythenorth> or just wait until we run out of IDs, then explode
20:10:16  <andythenorth> let the user delete the cache file :P
20:12:25  <frosch123> make the id a checksum of the string, and hope that no two match :p
20:15:25  <andythenorth> ha
20:15:30  <andythenorth> "what could go wrong?”
20:16:14  <andythenorth> currently IDs are random
20:16:20  <andythenorth> I don’t see much harm in caching them
20:17:42  *** tycoondemon [] has joined #openttd
20:20:16  * andythenorth -> bed
20:20:19  <andythenorth> bye
20:20:37  *** Aristide [] has joined #openttd
20:21:00  *** andythenorth [] has quit [Quit: andythenorth]
20:44:59  *** Progman [] has quit [Remote host closed the connection]
21:05:46  *** Alberth [~hat@2001:981:c6c5:1:be5f:f4ff:feac:e11] has left #openttd []
21:13:33  <Rubidium> got to love dumping a huge load of numbers into discussions about things "rarely" happening in real life
21:17:12  <frosch123> so, you are visiting rome?
21:17:56  <Rubidium> nope... been there... twice ;)
21:21:07  <frosch123> i assume not for that route though :p
21:23:14  <Rubidium> I once kinda considered taking the Moscow route from Berlin to Amsterdam
21:23:31  <Rubidium> but the layover was way way too long
21:30:27  *** tokai|mdlx [] has joined #openttd
21:34:50  *** tokai|noir [] has quit [Ping timeout: 480 seconds]
21:42:05  <frosch123> night
21:42:08  *** frosch123 [] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
21:44:40  *** silenz [] has joined #openttd
21:44:50  *** silenz [] has left #openttd []
21:58:13  *** Aristide [] has quit [Remote host closed the connection]
22:10:03  *** Haube [] has quit [Ping timeout: 480 seconds]
22:22:54  *** oskari89 [] has quit []
22:27:34  <Wolf01> 'night
22:27:37  *** Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
22:33:38  *** Brumi [] has quit []
22:38:57  *** Pereba [~UserNick@] has quit [Quit: AdiIRC is updating to v1.9.3 Beta Build (2014/07/08) 64 Bit]
22:39:16  *** Pereba [~UserNick@] has joined #openttd
22:47:34  *** Myhorta [] has quit [Remote host closed the connection]
22:49:20  *** Midnightmyth [] has quit [Ping timeout: 480 seconds]
23:19:38  *** MTsPony [] has quit []
23:21:09  *** HerzogDeXtEr [] has quit [Quit: Leaving.]
23:54:01  *** Supercheese [~Superchee@] has joined #openttd
23:59:46  *** yorick [] has quit [Remote host closed the connection]

Powered by YARRSTE version: svn-trunk