Log for #openttd on 17th October 2011:
Times are UTC Toggle Colours
00:27:15  *** hanf [] has quit [Read error: Connection reset by peer]
00:27:16  *** Devroush [] has quit []
01:00:49  <Eddi|zuHause> ooh... forum backup... didn't have that in quite a while...
01:31:26  *** glx [glx@2a01:e35:2f59:c7c0:1dc0:4b2d:a10f:a693] has quit [Quit: bye]
01:42:06  *** Horus [] has joined #openttd
01:55:36  *** Horus [] has left #openttd [Saindo]
03:49:39  *** pugi [] has quit [Quit: I reject your reality and substitute my own]
04:57:21  *** Eddi|zuHause2 [] has joined #openttd
05:03:58  *** Eddi|zuHause [] has quit [Ping timeout: 480 seconds]
05:28:20  *** Prof_Frink [] has quit [Ping timeout: 480 seconds]
05:48:22  *** Cybertinus [] has joined #openttd
06:03:45  <Terkhen> good morning
06:08:28  *** DayDreamer [] has joined #openttd
06:12:19  *** sla_ro|master [~slaco@] has joined #openttd
07:11:58  *** DayDreamer [] has quit [Read error: Connection reset by peer]
07:18:09  <dihedral> greetings
07:19:21  *** SirSquidness [] has quit [Ping timeout: 480 seconds]
07:24:02  <Terkhen> hi dihedral
07:26:38  <planetmaker> hello dihedral
07:31:53  *** SirSquidness [] has joined #openttd
07:40:54  *** Neon [] has joined #openttd
07:55:48  *** Elukka [] has joined #openttd
08:06:13  *** Eddi|zuHause2 is now known as Eddi|zuHause
08:19:01  *** Progman [] has joined #openttd
08:43:07  *** pjpe [] has quit [Quit: ajax IRC Client]
08:59:13  *** Neon [] has quit [Quit: Python is way too complicated... I prefer doing it quickly in C.]
09:01:07  *** Brianetta [] has joined #openttd
09:32:46  *** Bolt_ [] has joined #openttd
09:37:09  * Bolt_ waves and says 'howdy folks'
09:41:54  <Terkhen> hi Bolt_
09:42:06  *** TheMask96 [] has quit [Ping timeout: 480 seconds]
09:46:36  *** TheMask96 [] has joined #openttd
09:54:52  *** Bolt_ is now known as the
09:55:04  *** the is now known as the_bolt
10:00:04  *** sla_ro|master [~slaco@] has quit []
10:01:15  *** Eddi|zuHause [] has quit [Remote host closed the connection]
10:01:34  *** Eddi|zuHause [] has joined #openttd
10:15:40  <planetmaker> hello the_bolt
10:15:54  <planetmaker> maybe you could fix your too many white space in the op code patch?
10:16:26  <planetmaker> and dunno... maybe you just open an FS task about it, too
10:23:05  <the_bolt> maybe?
10:23:23  <the_bolt> gladly!!
10:23:41  <the_bolt> I posted into the forums as requested.
10:27:03  *** dageek [~dageek@2001:8b0:ff85:0:223:6cff:fe87:e49c] has joined #openttd
10:31:58  <the_bolt> the updated patch for the 'GetOpsTillSuspend() is available at   does it meet your requirements?
10:34:21  <planetmaker> I think so :-)
10:41:26  *** DayDreamer [] has joined #openttd
10:44:15  <the_bolt> patch added to FS>
10:44:44  <the_bolt> next - to document performance do's and don't for the wiki
10:53:19  <Arafangion> If you're so worried about performance, why don't you put the C++ classes entirely in the header?
11:00:40  <Terkhen> bbl
11:13:16  *** DayDreamer [] has quit [Read error: Connection reset by peer]
11:13:52  <the_bolt> the performance is for the AI script.
11:17:39  <Eddi|zuHause> even if not, what do headers have to do with performance?
11:25:23  <the_bolt> GTG.
11:25:30  *** the_bolt [] has quit [Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20110928134238]]
11:28:47  <Arafangion> Eddi|zuHause: Certain styles of implementation are much easier to inline.
11:30:02  <Eddi|zuHause> Arafangion: but apart from a few special cases, inlining has hardly any effect on performance
11:33:26  <Arafangion> Eddi|zuHause: Depends on what you mean by "special".
11:34:08  <Eddi|zuHause> Arafangion: "special" as in "that is currently already done"
11:49:04  *** pugi [] has joined #openttd
12:08:21  *** Arafangion [] has quit [Remote host closed the connection]
12:22:21  *** glx [glx@2a01:e35:2f59:c7c0:297e:9da0:34ca:b0f6] has joined #openttd
12:22:25  *** mode/#openttd [+v glx] by ChanServ
12:39:40  *** Neon [] has joined #openttd
12:40:03  *** SirSquidness [] has quit [Ping timeout: 480 seconds]
12:56:37  *** Arafangion [] has joined #openttd
12:57:11  *** DayDreamer [] has joined #openttd
13:01:38  <Arafangion> AdmiralAI seems to take ages to start (On a highly populated 64x64 map!)
13:02:14  *** Kurimus [] has joined #openttd
13:02:53  *** dageek [~dageek@2001:8b0:ff85:0:223:6cff:fe87:e49c] has quit [Ping timeout: 480 seconds]
13:05:40  *** dageek [] has joined #openttd
13:13:08  <Arafangion> Interesting - on my map, DictatorAI is making more money than gelignAlte.
13:19:54  <Belugas> hello
13:21:16  *** DayDreamer1 [] has joined #openttd
13:21:18  * Arafangion looks at Belugas suspiciously.
13:21:40  * planetmaker looks at Arafangion suspiciously and waves 'hello' to Belugas
13:22:55  * Belugas wonders what's wrong with Arafangion and waves a big smiley hello to planetmaker :)
13:23:02  *** DayDreamer [] has quit [Ping timeout: 480 seconds]
13:25:01  * Arafangion mumbles, looks inwards and returns to The Game.
13:27:19  <Belugas> crossed eyes Arafangion :)
13:27:39  * Arafangion implodes.
13:43:34  *** HerzogDeXtEr1 [] has joined #openttd
13:49:27  *** HerzogDeXtEr [] has quit [Ping timeout: 480 seconds]
14:00:00  *** fjb [] has joined #openttd
14:00:42  *** George is now known as Guest13802
14:00:46  *** George [~George@] has joined #openttd
14:01:39  <fjb> Moin
14:07:12  *** Guest13802 [~George@] has quit [Ping timeout: 480 seconds]
14:11:26  <Eddi|zuHause> Elukka: here is a tank wagon (ca. 1910):
14:12:11  <Elukka> i was drawing something very similar
14:12:14  <Elukka> think i'll do multiple color variants
14:13:32  <Eddi|zuHause> not entirely sure about the length, though
14:14:15  <Elukka> i figure it can't be too far off the length of the other freight cars
14:14:18  <Elukka> which both round off to 5 lu
14:14:50  <Eddi|zuHause> 8800m (4lu) is a common figure i found
14:15:02  *** Brianetta [] has quit [Quit: TschÌß]
14:15:07  <Eddi|zuHause> mm
14:15:09  <Eddi|zuHause> of course
14:25:51  <Eddi|zuHause> Elukka: we can also use recolouring for the wagons
14:31:31  *** Br33z4hSlut5 [] has quit [Remote host closed the connection]
14:37:20  *** Doorslammer [] has joined #openttd
14:39:05  <Elukka> at 8.8 / 24 x 12 it's 4 lu, at 8.8 / 24 x 12.5 it's barely 5
14:39:33  <Elukka> i suppose recoloring would be a bit easier
14:40:33  *** Pulec [~pulec@] has joined #openttd
14:58:46  <MNIM> hmmmh.
14:58:57  <MNIM> why is my overflow depot not working?
15:00:48  <planetmaker> why did the chicken cross the road?
15:01:46  <__ln__> i have a better question: if A and B are independent, and P(A)=P(B)=p>0, is it true that if P(A union B)=1 then p=1?  (i think it's false)
15:03:17  *** Adambean [] has joined #openttd
15:03:18  <planetmaker> I think it's false
15:03:24  <planetmaker> 50% of the people are women
15:03:30  <planetmaker> 50% of the people have black hair
15:03:38  <planetmaker> not 100% are black-haired women
15:05:00  <planetmaker> but that doesn't fit the assumptions... I see :-)
15:07:40  *** SirSquidness [] has joined #openttd
15:09:56  *** Prof_Frink [] has joined #openttd
15:11:13  <__ln__> today's exam question was to prove that one to be correct.
15:11:18  <b_jonas> __ln__: it's true
15:11:42  <b_jonas> __ln__: but if you want a proof, you might want to ask on another channel (eg. freenode #math )
15:13:39  <__ln__> b_jonas: but what if we choose p=1/2, and let A be the complement of B? P(A union B) = 1, but p != 1.
15:22:13  <Yexo> why is P(A union B) always 1 in that case/
15:23:04  <planetmaker> complement is always dependent. Not independent
15:25:50  *** Brianetta [] has joined #openttd
15:26:09  *** perk11 [~perk11@] has joined #openttd
15:27:42  <__ln__> that might be the key to why the magic fails
15:30:17  *** Doorslammer [] has quit [Quit: ajax IRC Client]
15:34:07  *** Pulec [~pulec@] has quit [Read error: Connection reset by peer]
15:35:01  <__ln__> thanks
15:35:47  *** sla_ro|master [~slaco@] has joined #openttd
15:50:46  *** dageek [] has quit [Quit: dageek]
16:09:03  *** Brianetta [] has quit [Quit: TschÌß]
16:09:27  *** fjb [] has quit [Remote host closed the connection]
16:11:09  *** TWerkhoven [] has joined #openttd
16:19:38  <Eddi|zuHause> __ln__: if A and B are independent, then P(A \cup B) = 1-P(¬(A \cup B)) = 1-P(¬A \cap ¬B) = 1-P(¬A)-P(¬B) = 1-2*(1-p)
16:20:16  <Eddi|zuHause> er
16:20:20  <Eddi|zuHause> wrong
16:20:34  <Eddi|zuHause> __ln__: if A and B are independent, then P(A \cup B) = 1-P(¬(A \cup B)) = 1-P(¬A \cap ¬B) = 1-P(¬A)*P(¬B) = 1-p^2
16:20:48  <Eddi|zuHause> still wrong
16:20:52  <Eddi|zuHause> 1-(1-p)^2
16:21:04  <Eddi|zuHause> anyway, 1 = 1-(1-p)^2 => p=1
16:22:17  <Eddi|zuHause> anyway, gtg
16:22:22  <__ln__> thnx
16:22:40  <Eddi|zuHause> the step 1-P(¬A \cap ¬B) = 1-P(¬A)*P(¬B) requires independence
16:39:06  <peter1138> ¬ is used
16:39:08  <peter1138> for the first time
16:47:30  <peter1138> you know, the more recent title screen games just don't feel right
16:48:03  <peter1138> it's really missing the level crossings and the fog horns
16:51:30  <Elukka> more recent title screens exist?
16:51:50  <peter1138> the one you get when you play a release
16:52:16  <peter1138> i don't know how often it changes
16:53:15  <Terkhen> the last two releases had a voting contest to select different title screen games
16:56:51  <peter1138> hmm, i should try the scott joplin pack through pianoteq
16:57:38  *** pjpe [] has joined #openttd
16:57:53  <planetmaker> each release branch probably gets its own title game
16:58:04  <Elukka> ooh
16:58:16  <Elukka> but nightlies still use the old one?
16:58:25  <planetmaker> they always will continue to use the same, yes
16:58:53  <Elukka> you can kinda tell it's not really made with modern screen resolutions in mind... since most of it is empty
16:59:00  <planetmaker> when the minor version number (the x in 1.x.y) changes, then we usually had at title screen contest the last two times
16:59:09  <planetmaker> yes
16:59:18  <planetmaker> but for nightly that's not important really ;-)
16:59:36  <planetmaker> the important property there is: it's a savegame of savegame version 4.
16:59:39  <Elukka> i suppose it's not vital
16:59:40  <planetmaker> And now we have 16x
16:59:52  <planetmaker> thus it's a savegame conversion test implicitly ;-)
16:59:59  <Elukka> clever
17:00:32  <planetmaker> but most people anyway use stable. They get nice starting screens. Or so at least the majority of people who voted thought ;-)
17:00:59  <planetmaker> So if you want... start making one. There'll be another contest around... December ... February or so
17:01:16  <Elukka> i'd never see it since i haven't played stables for years
17:01:24  <planetmaker> well :-)
17:01:28  <planetmaker> Doesn't need to stop you
17:01:53  *** pugi__ [] has joined #openttd
17:03:05  <peter1138> shame these midi pieces are too perfect :(
17:03:41  <planetmaker> :-D
17:03:55  <peter1138> exactly the same velocity for every note
17:04:00  <peter1138> exactly the same timing
17:04:00  <peter1138> etc
17:04:07  <peter1138> sounds... dull
17:04:23  <planetmaker> peter1138: don't you own a midi device?
17:04:41  <planetmaker> i.e. where are your midi files for a sound set? ;-)
17:05:24  <peter1138> urghgrgrhgrghrg
17:05:30  <peter1138> this piece is adjusting the master volume
17:05:39  <peter1138> instead of adjusting velocity :S
17:05:45  <peter1138> wrong wrong wrong :S
17:06:47  <peter1138> my midi files for a sound set? what do you mean?
17:07:27  *** pugi [] has quit [Ping timeout: 480 seconds]
17:07:28  *** pugi__ is now known as pugi
17:07:29  <planetmaker> I mean your music pieces. As midi files
17:07:43  <planetmaker> Dunno if it's feasible with your equipment
17:09:20  <peter1138> i never record the midi from the keyboard
17:09:24  * Belugas does not think peter1138's excessive use of digital effets can be recorded in midi :)
17:09:30  <peter1138> and indeed
17:09:44  <peter1138> i use a variety of midi synths
17:09:49  <peter1138> not usually a soundfont synth
17:09:55  <peter1138> (although i have done)
17:10:12  <peter1138> and the guitar isn't midi, heh
17:10:53  <Belugas> well... yours  and mine... Charles has 2 midi guitars
17:11:20  <peter1138> maybe
17:11:50  <peter1138> that would sound odd through a soundfont player :)
17:11:51  <Belugas> but granted, the idi part is only to grab the events on the guitars
17:12:21  <Belugas> as soon as his devise reads them, they are digiatlly processed and output as waves
17:12:51  <Belugas> i'l have to ask him, peter1138, but i doubt he'll waste tie on it ;)
17:14:35  <Belugas> #In the dead of nights
17:14:39  <Belugas> #Love Bites!
17:15:52  *** hanf [] has joined #openttd
17:19:07  *** TheMask96 [] has quit [Ping timeout: 480 seconds]
17:20:58  <Yexo> Elukka: you could still download the a stable version and just copy opntitle.dat from there to your nightly install
17:21:23  <peter1138> or not care
17:21:52  <peter1138> hey cool, some 32bpp graphics ;p
17:23:20  *** TheMask96 [] has joined #openttd
17:24:57  *** LordAro [] has joined #openttd
17:24:59  <b_jonas> thanks again for pointing me to the openttdcoop wiki. its examples will help me build better networks even if I'm not playing openttdcoop.
17:27:00  *** frosch123 [] has joined #openttd
17:28:23  <LordAro> evening
17:29:38  <Terkhen> hi LordAro
17:30:53  <LordAro> hi terkhen
17:31:02  <LordAro> *Terkhen :)
17:31:24  <Terkhen> no need to highlight me twice :P
17:33:00  <peter1138> Terkhen
17:33:02  <peter1138> Terkhen, sure?
17:33:36  <Terkhen> :P
17:34:46  <LordAro> :)
17:40:16  <b_jonas> though their complicated examples are over my head
17:40:21  *** Wolf01 [~wolf01@] has joined #openttd
17:40:22  <b_jonas> I might still learn a bit at a time
17:40:36  <Wolf01> hello
17:40:55  <Terkhen> hi Wolf01
17:42:36  <peter1138> some of it isn't relevant
17:43:19  <b_jonas> sure
17:43:35  <peter1138> actually none of it is, to my playing style :p
17:48:39  <frosch123> Terkhen: doesn't the second highlight cancel the first one?
17:49:03  <Terkhen> not if I already checked the first one and alt tabbed again
17:50:26  *** glx is now known as Guest13824
17:50:26  *** glx_ [glx@2a01:e35:2f59:c7c0:297e:9da0:34ca:b0f6] has joined #openttd
17:50:26  *** mode/#openttd [+v glx_] by ChanServ
17:50:26  *** glx_ is now known as glx
17:55:27  *** valhallasw [] has joined #openttd
17:56:37  *** Guest13824 [glx@2a01:e35:2f59:c7c0:297e:9da0:34ca:b0f6] has quit [Ping timeout: 480 seconds]
18:07:03  *** JVassie [~James@] has joined #openttd
18:09:45  *** DayDreamer1 [] has quit [Read error: Connection reset by peer]
18:19:12  *** TWerkhoven[l] [] has joined #openttd
18:23:10  *** DayDreamer [] has joined #openttd
18:23:26  *** DayDreamer [] has quit []
18:28:42  *** Brianetta [] has joined #openttd
18:37:42  *** DDR_ [~chatzilla@] has joined #openttd
18:44:49  <b_jonas> they're building logic gates from presignals! that's crazy.
18:45:25  <b_jonas> and they're actually deliberately using the bugs in the old signal behaviour
18:48:06  *** andythenorth [] has joined #openttd
18:50:29  <DDR_> b_jonas: OpenTTD Coop, right?
18:50:51  <b_jonas> DDR_: yes, I was looking at the openttdcoop wiki to learn a bit about track layouts
18:53:40  <b_jonas> hmm, I've got 64% station rating for this iron ore mine with a single slow ship that transmits to a station 60 tiles away
18:53:57  <b_jonas> I guess that's because ships get a bonus for station rating computation, right?
18:54:07  <b_jonas> should I be using feeder ships to fool stations into giving me better ratings?
18:54:07  <frosch123> yes
18:54:19  <Pinkbeast> Much as I respect the #coop people that is a bit like trying to learn how to sail a dinghy by close consideration of HMS Victory
18:54:43  <frosch123> well, the max speed of the last vehicle visiting a station also affects rating
18:55:15  <frosch123> which compensates the ship bonus usually :p
18:56:27  <DDR_> b_jonas: I've been playing openTTD for a few years, and I still have no freaking clue how most of the Coop's stuff works.
18:56:35  <DDR_> You're a brave, brave man.
18:56:53  *** Biolunar [] has joined #openttd
18:59:52  <b_jonas> DDR_: I don't wish to play coop, I just want to learn som things about the layouts for my single-player games. Their info about layouts sometimes seem fresher than the ones on openttd wiki.
19:00:10  <Pinkbeast> Really? Some of their stuff still used block signals last I looked.
19:00:25  <Pinkbeast> I think the wiki has pretty good information on normal stations and junctions.
19:00:32  <DDR_> Hm.
19:00:34  <b_jonas> Pinkbeast: true, and I did mention they seem to use old signal bugs as well
19:00:39  *** AcidWeb [] has joined #openttd
19:00:55  <frosch123> Pinkbeast: in case you did not notice, they use non-path signals intentionally
19:00:59  <AcidWeb> Hello
19:00:59  <b_jonas> Pinkbeast: but they're using pre-signals for exotic logic blocks that I'm not sure you can build from path signals
19:01:07  <frosch123> because they are more advanced than path signals when used correctly
19:01:31  <b_jonas> they're using pre-signals for priority thingy
19:01:43  <frosch123> path signals are for people with less than 7 platforms :p
19:02:00  <DDR_> Heh!
19:02:03  <Pinkbeast> What I'm saying is _the last time I looked_ there were still layouts that used block signals because they predated path signals.
19:02:56  <DDR_> I wouldn't put it past them to save old-but-impressive signal layouts.
19:03:17  <Pinkbeast> And that I don't think jonas will learn much about normal gameplay, just as any kind of "stunt flying" in videogames doesn't necessarily tell you much about normal play.
19:03:23  <AcidWeb> What may cause ppl randomly drop from multiplayer game? "Client dont respond in X days" error or something like that
19:03:37  <Yexo> bad internet connection
19:04:10  <b_jonas> Pinkbeast: I at least learnt how they build junctions that connect a sideline to a mainline
19:04:16  <b_jonas> I used something like that in my last game
19:04:38  <b_jonas> before reading their wiki that is
19:05:07  <AcidWeb> Hmm but all ppl are affected. Not only one drop randomly.
19:05:07  <DDR_> Hm, ... memory blank here, what's it called when trains exit by the same end of the station they entered, versus exiting by the other end of the station?
19:05:32  <b_jonas> DDR_: terminus, roro
19:05:42  <DDR_> AcidWeb: It might be the server's connection, or just wider hickups in the network...
19:05:47  <DDR_> Thanks.
19:05:52  <AcidWeb> DDR_: Server got 100/100 connection.
19:06:17  <AcidWeb> And some other services that working correctly.
19:06:51  <planetmaker> DDR_: I'd not argue that block signal layouts are all outdated
19:07:19  <b_jonas> planetmaker: how about pre-signal layouts for giving priority to a line over another one?
19:07:24  *** andythenorth is now known as Guest13836
19:07:24  *** andythenorth_ [] has joined #openttd
19:07:24  *** andythenorth_ is now known as andythenorth
19:07:54  <planetmaker> b_jonas: that's one place where path signals cannot help a lot
19:08:26  *** Guest13836 [] has quit [Read error: Connection reset by peer]
19:09:36  <b_jonas> hmm, which mode of transport should I use for this forest? road, train?
19:11:47  <DDR_> How far is it going?
19:12:21  <DDR_> How much wood do you have to transport?
19:12:29  <DDR_> What year is it?
19:12:36  <Rubidium> ships ofcourse
19:13:29  <Rubidium> specifically:
19:13:47  <andythenorth> lots of ships
19:14:00  <AcidWeb> Maybe i screwed network settings? net_frame_freq = 2 net_sync_freq = 50
19:14:00  <andythenorth> try using a river :P
19:15:08  <DDR_> b_jonas: ?
19:15:46  <Rubidium> the speed of a connection says nothing about the stability of said connection
19:16:31  <Rubidium> though it has to be said that OpenTTD doesn't cope very well with slightly unstable connections whereas other applications might have less trouble with that
19:16:40  <Terkhen> AcidWeb: what's the size of the map?
19:16:52  <AcidWeb> 512x512
19:17:20  <b_jonas> Rubidium: yes, I have FISH loaded
19:17:32  <Elukka> anyone know if YACD is still being actively developed?
19:17:34  <Rubidium> though that's mainly because we actively monitor the connection, i.e. we sort of "ping" the clients and if they don't reply within the 10 seconds they're dropped
19:17:46  <Elukka> i'm kinda on an ottd hiatus because i really want to play with yacd but it's not playable enough yet...
19:17:47  <b_jonas> I couldn't download BIRD though (the corresponding airplane GRF)
19:17:49  <AcidWeb> Im using AP+ it that change anything.
19:17:49  <Rubidium> Elukka: I think michi_cc knows
19:17:55  <Terkhen> Elukka: to my knowledge it is on hiatus right now but ^
19:18:05  <DDR_> What is YACD?
19:18:10  <Elukka> i hope it's not on a permanent hiatus!
19:18:38  <DDR_> b_jonas: I usually use road for travel distances under two feet of real screen-space, although I have been known to make longer roads if the mood takes me.
19:18:45  <Terkhen> I have seen connection problems when the map is too big or it has too many vehicles and either the server or the client can't keep up with execution
19:18:58  <Terkhen> DDR_: check the YACD thread at the development subforum
19:20:28  <michi_cc> Elukka: YACD is waiting on some inspiration on how to make the algorithms at least twice as fast (or for somebody to rewrite the core game loop with multi-core support).
19:20:53  <planetmaker> hm, so speed is the problem?
19:21:07  <Elukka> i see
19:21:16  <Terkhen> btw michi_cc, my approach to subsidies is using the part of YACD you suggested :)
19:21:25  <andythenorth> which bits are slow?
19:21:27  <Elukka> i hope you work on it in the future, it's such a great addition to the game :)
19:21:32  <Terkhen> I still have to fix subsidy creation, but the house acceptance/production code is done already
19:21:41  <Elukka> really i'd rather play on smaller maps with yacd than on large maps without it
19:21:45  <Elukka> if it was too slow to play on big maps
19:22:09  <Terkhen> hmm... and I was waiting on YACD for playing again too :P
19:22:40  <michi_cc> I have a test game that isn't that large (512x512 with a low number of towns and industries) but has a great number of cargo in flight and it is at 100% of my 3.2 GHz CPU. Over half the time in that game is purely spent inside "path"finding for cargo packets.
19:22:57  <Elukka> okay, that sounds like an issue
19:23:14  <Terkhen> what parts could be multithreaded?
19:23:37  <DDR_> oo, yacd looks nice. Seems to be the same idea behind cargo that Simutrans has, but without sucking like Simutrans does.
19:23:42  <andythenorth> YACD does use ~2x more CPU than non-YACD
19:23:45  <andythenorth> on my box
19:24:35  * Terkhen wouldn't even know how to start to add multicore support :P
19:24:50  *** Alberth [] has joined #openttd
19:24:53  *** mode/#openttd [+o Alberth] by ChanServ
19:24:53  <Terkhen> hi Alberth
19:24:55  *** Adambean [] has quit [Quit: Gone fishing]
19:24:59  <Alberth> hi
19:25:35  <planetmaker> Terkhen: the only thing I can vaguely imagine is to move drawing to a completely separate thread
19:25:45  <planetmaker> but how? No idea
19:25:47  <planetmaker> hi Alberth
19:26:01  <michi_cc> YACD speed is directly related to number of active cargo packets and number of cargo producers (which in practice means house count, in comparison those few industries don't really matter).
19:26:01  <Rubidium> planetmaker: doesn't help much
19:26:04  <andythenorth> how does simutrans handle cargo packets?
19:26:15  <Alberth> anything known about weird names for wagons in opengfx+trains?
19:26:17  <planetmaker> andythenorth: simutrans has no reall MP support
19:26:20  <planetmaker> -l
19:26:59  <Rubidium> planetmaker: the bits that determine which sprites to draw are heavily dependant on the game state, so those need a "lock" of that state
19:27:07  <planetmaker> Rubidium: Not? I wonder... My OpenTTD uses even on idle 15% CPU of the core it runs on
19:27:23  <Rubidium> and the rest is already in a seperate thread on SDL/Allegro
19:27:31  <planetmaker> Rubidium: yes... but redrawing once per tick... hm...
19:27:39  <Terkhen> I can't think of anything that is not tightly coupled with the rest of the code
19:28:03  <Rubidium> hmm, sorry... only on SDL
19:28:07  <Yexo> perhaps part of the tileloop could be threaded, although even that would be very tricky to get right
19:28:43  <planetmaker> I wonder whether it might start to become interesting to mulithread things even if it gives a penalty on single core systems
19:29:13  <DDR_> Probably, very few people have single-threaded systems anymore.
19:29:26  <planetmaker> single-threaded: hardly ;-)
19:29:39  <Rubidium> planetmaker: the game state is so interdependant on eachother and on the execution order that I don't think much can be achieved
19:29:40  <michi_cc> Terkhen: Most of the YACD cargo pathfinding could be done parallel if the events that modify link graph woudn't be all over the place. This especially means vehicle movement where movement, stopping, loading/unloading is all done serially on each vehicle instead of first moving all vehicles, then checking station state, then loading etc.
19:29:49  <b_jonas> it doesn't sound too probably, but I think someone has suggested to have multiple maps connected only very losely, with gates where vehicles can pass but where the pathfinder doesn't see past the gates so you have to use explicit orders to the gate.
19:30:11  <planetmaker> Rubidium: I seem to recall reading like 5 ... 10% somewhere?
19:30:12  <Terkhen> hmm...
19:30:22  <Terkhen> so it needs a huge amount of changes to how the tileloop works first :)
19:30:28  <Rubidium> planetmaker: yes, *without* any locking
19:30:33  <andythenorth> does each packet have to calculate a full path on each tick?
19:30:38  <Rubidium> i.e. desync heaven
19:30:41  <andythenorth> or just next hop? or what?
19:30:54  <Rubidium> andythenorth: only when loading/unloading
19:30:57  <planetmaker> hm, desync heaven. nice
19:31:58  <Rubidium> even then, profile the game to see what takes a lot of time
19:32:13  <Elukka> now i'm depressed that yacd might never get finished :(
19:32:16  <Rubidium> IIRC making/removing fences takes relatively much
19:32:47  <frosch123> on an empty map
19:33:00  <Alberth> <-- doesn't look like UK english names to me :p
19:33:17  <michi_cc> Example: In order to balance different routes the amount of waiting cargo is taken into account, which means that the link graph before a vehicle loads in different to the state after the vehicle loads. Ergo, the order of vehicle loading and cargo pathfinding has to be fixed.
19:33:40  <planetmaker> they look pretty Dutch, Alberth ;-)
19:34:01  <planetmaker> Did I mess up naming somewhere?
19:34:05  <Rubidium> and (in theory) you could remove that code from the tile loop and just build the fences when building farm tiles or when clearing tiles (in general)
19:34:30  <Alberth> I am quite sure "vogn" is not Dutch either :)
19:34:36  <Rubidium> they don't look Dutch to me
19:34:46  <Elukka> vogons!
19:34:50  <Alberth> it is supposed to be UK english
19:35:03  <Rubidium> it's rather Norwegian or some other Scandinavian language
19:35:33  * Alberth thinks so to
19:35:36  <frosch123> danish
19:35:36  <Alberth> *too
19:35:51  *** DDR_ [~chatzilla@] has quit [Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20110928224508]]
19:36:07  <planetmaker> hm... :-) I shall look into that. Thanks, Alberth
19:36:30  <Terkhen> michi_cc: let's see if I understood it correctly... it needs to group parts of the code that change the state such as vehicle load / unload and station handling, to avoid updating the cargo state more than necessary
19:36:31  <frosch123>
19:36:34  <andythenorth> michi_cc: what could you do less of (i.e. worse, but acceptable)?
19:36:42  <planetmaker> The trains anyway need to make use of michi's new cargo aging property :-)
19:36:57  <Alberth> aka, "not known" thus :)
19:38:05  <Alberth> planetmaker: do you want me to make an issue about it?
19:38:07  *** KritiK [] has joined #openttd
19:40:01  <AcidWeb> Can AP+ can cause cause that player drops?
19:40:54  <michi_cc> Terkhen: Yes, for example make records of loaded/unloaded cargo packets, added/removed cargo links during vehicle tick execution and only apply them after all vehicles where processed. (Obvious problem: how to make sure vehicles don't load more cargo than present; solution idea: maybe don't store packets, but only "has to (un)load".) Then you could do cargo routing in parallel to vehicle pathfinding.
19:41:06  <Yexo> Alberth / planetmaker: the grf is fine, it's a bug in openttd
19:41:17  <Yexo> in openttd 1.1.3 it works as expected
19:41:38  <Alberth> how nice :p
19:44:01  *** Brianetta [] has quit [Remote host closed the connection]
19:45:13  <planetmaker> he, interesting
19:45:14  <michi_cc> YACD profile: (created with KCachegrind, source data )
19:45:22  *** Kurimus [] has quit []
19:45:38  * Terkhen needs to learn to use that program :P
19:47:08  <frosch123> wow, three different chains ending in the same function :o
19:47:36  <michi_cc> That savegame is already with a seriously reduced cargo recalculation frequency, otherwise the StationCargoList::UpdateNextHop chain would be much bigger (and the game not playable anymore on my PC).
19:48:43  <michi_cc> The part below ChooseRouteLink "suffers" from inlining (adding a new node is not nearly as expensive as it seems :)
19:48:53  <Terkhen> so it expends most of the time calculating cargo paths again and again
19:48:59  <AcidWeb> Im new in this topic. But it seems to me that using only planes is very easy way to win company value goal on servers without any GRF. Im right?
19:49:24  <Terkhen> AcidWeb: yes
19:51:04  <AcidWeb> That is answer why most servers i see have them disabled.
19:51:17  <michi_cc> Terkhen: That game has about 100000 cargo packets or so, the time till the same packet is looked at again is quite big (which means there's not much that could be cached).
19:51:26  <AcidWeb> Need tweak server. Limit of 10 is to high.
19:52:07  <AcidWeb> Client #63 is dropped because the client did not respond for more than 4 game-days
19:52:09  <AcidWeb> sigh.
19:52:17  <AcidWeb> Also need find a reason of that ;p
19:52:47  <Alberth> too big map, too busy map, too fast server
19:53:10  <michi_cc> The chain starting at TileLoop is purely the time spent for initial routing of the cargo (i.e. find out if there's a route at all and if yes, which station to deliver to), something which can't be tricked away.
19:53:16  <AcidWeb> Alberth: To fast server?
19:53:49  <Alberth> or too slow client, depending on your point of view :p
19:54:01  <Yexo> AcidWeb: you get that when the map is very busy and the client is not fast enough
19:54:19  <AcidWeb> hmm
19:54:42  <AcidWeb> I cant call this map busy
19:54:49  <AcidWeb> Also it is only 512x512
19:55:33  <michi_cc> The chain over LoadUnloadStation is getting the new next hop upon unloading from a vehicle to a station.  The final chain(s) that end at UpdateCargoNextHop are for periodically rerouting cargo so cargo flow adapts to changes in the link graph.
19:55:46  *** Brianetta [] has joined #openttd
19:55:56  <AcidWeb> There is any option to "slow" the server?
19:57:18  <planetmaker> not for a client
19:58:10  <AcidWeb> Autopilot sending some additional commands every 30 seconds may cause ppl problems?
19:59:30  <glx> 512x512 is big
20:00:46  <glx> 4 times bigger than default size
20:01:41  <AcidWeb> Im just looking for answer on main question. If i screwed something? :D
20:01:57  <AcidWeb> And if yes how to fix it.
20:02:22  <AcidWeb> If it is client problem ok - i dont like it but i will live with that.
20:02:44  <Alberth> did you try pausing the game when a client connects?
20:03:17  <Terkhen> michi_cc: hmm... 23.95% is quite big... even if it can't be tricked away, that part could use some optimization
20:03:19  <AcidWeb> as i observer that is not connected.
20:04:15  *** DDR_ [~chatzilla@] has joined #openttd
20:04:51  <AcidWeb> also there are no pattern in that drops
20:05:00  <AcidWeb> It just sometime drop random ppl.
20:05:33  <Alberth> network connections are stochastic yes
20:07:19  <michi_cc> Terkhen: It already has a lot optimizations. For example the most expensive operation is pathfinding when the source is not connected to the destination as you'd potentially have to visit all nodes. To alleviate that problem I've locally implemented a station coverage cache so I can fail fast in case the target tile is not covered by any station. Obviously this optimization gets less and less effective the better connected the map is (which will als
20:07:19  <michi_cc> o be the time when this part uses more and more time due to town growth).
20:09:46  <andythenorth> how many graphs are there on any one map?
20:11:54  <michi_cc> andythenorth:
20:12:34  <Terkhen> I see...
20:12:35  <andythenorth> :)
20:12:38  <Terkhen> it's a complicated problem :(
20:13:31  <andythenorth> this would be easier if we limited the game to 1 cargo :P
20:13:48  <AcidWeb> Anyway thank you for help. Maybe that is just hickup.
20:13:52  <andythenorth> I think there's only one graph in that map for PAX
20:14:15  <andythenorth> with one graph, all you need to check is coverage
20:15:09  <andythenorth> with 2'd need to check coverage, and if the start / end nodes are in the same graph
20:15:20  * andythenorth is a newbie at network theory :P
20:16:04  <michi_cc> Yes, there's only one connected pax graph. At lot of the houses on the map are inside station coverage though, so most of the time there is a path from source to destination.
20:16:22  <andythenorth> and calculating the path is expensive?
20:17:11  * andythenorth wonders how Railroad Tycoon 3 solved this, on older machines, while running a 3D engine
20:17:39  <andythenorth> probably a different problem, for a different codebase
20:18:06  <Yexo> andythenorth: a lot smaller maps, so less vehicles, less cargo
20:18:10  <Yexo> did it have mp support?
20:18:11  <DDR_> Hm, I think if you did some tricky work with minimizing the track layout, it becomes a trivial problem.
20:18:15  <andythenorth> no mp support
20:18:18  <frosch123> night
20:18:21  <DDR_> Ah.
20:18:22  *** frosch123 [] has quit [Remote host closed the connection]
20:18:23  <Yexo> that is also a huge advantage
20:18:31  <andythenorth> RT3 had a different way of routing cargo
20:18:43  <Yexo> since without mp support you don't have to worry about desyncs
20:19:41  <andythenorth> how does the internet route packets?
20:19:50  <andythenorth> conceptually
20:20:07  <Alberth> non-deterministically
20:20:19  <andythenorth> I guess the computational load is handled by n devices too
20:20:25  <andythenorth> there is no 'the internet' device
20:20:30  <andythenorth> unless they're not telling us
20:20:40  <Alberth> it wouldn't be able to handle the load :)
20:21:35  <andythenorth> hmm
20:21:41  <andythenorth> YACD is rather nice to play with :)
20:21:54  <michi_cc> Expensive enough to matter. A single cargo pathfinding only takes 0,0017% of the total CPU time, but a single tick only gets 0,15% of total time in this specific test case.
20:21:59  <Alberth> I once heard a story where routers told each other cost of routing, and one router said 0. All traffic was routed to there and the network went down :)
20:22:19  *** welshdragon [] has joined #openttd
20:23:13  <andythenorth> michi_cc: do you have to calculate the entire path?
20:23:33  <michi_cc> andythenorth: The big difference of RRT3 is that it doesn't actually care about the destination of cargo. The routing choice is very simple: destination has higher price -> load onto train, finished.
20:23:40  <andythenorth> yes
20:23:49  <andythenorth> it made for a fun game, although many disagreed :)
20:23:57  <Terkhen> sounds more boring than YACD
20:24:32  *** Danio [Danio@] has joined #openttd
20:26:14  <michi_cc> andythenorth: On initial cargo generation the whole path has to be calculated to decide whether to generate the packet at all. After that, you don't necessarily have to do a full calculation, but then you might get the same problems the old train pathfinder had (like not managing a right turn for a destination on the left).
20:26:28  * andythenorth has ants in mind
20:26:39  <andythenorth> ants leave markers behind for other ants to follow....
20:28:02  <Alberth> Yexo / planetmaker: bisecting gives me r22970 to blame
20:28:08  <Terkhen> I don't think that ACO is appropiate for this problem
20:28:24  <michi_cc> Maybe A* just is very inefficient for this specific kind of problem and some other pathfinding algorithm would do a lot better, but I'm really not a specialist on pathfinder algorithms, so...
20:28:26  <Terkhen> too many paths, you'll need too many ants :P
20:28:33  <Yexo> Alberth: just found that out too :)
20:28:40  <andythenorth> a
20:29:04  <CIA-6> OpenTTD: yexo * r23036 /trunk/src/newgrf.cpp: -Fix (r22970): swapped parameters resulted in wrong vehicle names
20:29:11  <andythenorth>
20:30:01  <andythenorth> these are theories, not working code :)
20:30:20  <Terkhen> there must be a good method for a graph that changes a lot
20:30:26  <andythenorth> ant routing apparently performs badly in that case
20:30:28  <andythenorth>
20:30:31  <Terkhen> s/method/heuristic method/
20:30:43  <Terkhen> but then you are not getting optimal paths :)
20:30:48  <Alberth> Yexo: thanks for fixing :)
20:30:53  <andythenorth> does the graph change a lot?
20:30:59  <andythenorth> in a typical game?
20:31:01  <Yexo> you're welcome :)
20:31:34  <Rubidium> andythenorth: every time you change an order or change the time it takes a train to go from A to B
20:31:44  <andythenorth>
20:31:51  <Alberth> good night all
20:31:54  <Terkhen> andythenorth: if it is taking into account stuff such as "waiting cargo" then it is changing all the time
20:31:57  <Terkhen> good night Alberth
20:31:57  <Rubidium> night Alberth
20:33:39  *** Alberth [] has left #openttd []
20:34:05  *** AcidWeb [] has left #openttd []
20:34:10  <andythenorth>
20:34:12  <andythenorth> ok
20:34:17  <andythenorth> so it's a known difficult problem :P
20:34:44  <Terkhen> :)
20:35:50  <andythenorth> michi_cc: if we can solve it, maybe we can patent it :)
20:36:00  <andythenorth> and then license it to cisco et al
20:36:10  <andythenorth> and use the income to implement TTD 3D :P
20:36:12  <andythenorth> :D
20:36:25  * andythenorth is only partly fooling and is partly serious :o
20:36:54  <andythenorth> a large TTD map represents a moderately complex routing situation that needs solving with relatively few computing resources
20:37:25  <michi_cc> Somehow I get the feeling we're not the first humans trying to find a solution to this problem :)
20:37:36  <Terkhen> is an optimal path a requirement for cargo packets? because if it is, probably A* and its family are probably the only real option
20:37:53  <Rubidium> andythenorth: internet routing is "easier". You only got point-to-point connections.
20:38:45  <Rubidium> i.e. the packet will always be offloaded at the next station regardless of how it goes further
20:39:01  <planetmaker> traveling salesman problem ;-)
20:39:14  <andythenorth> Terkhen: what constitutes 'optimal' ?
20:39:34  <Terkhen> hmm... good question :)
20:39:35  <andythenorth> I was wondering earlier today (for non-related reasons) how real railroads solve this
20:39:43  <Rubidium> andythenorth: spread evenly over the capacity
20:39:47  <michi_cc> Terkhen: Optimal definitely not. It has to be good enough that nobody complains that cargo for A to B is going over a X that looks very inoptimal to a human.
20:40:06  <Terkhen> ok :)
20:40:09  <andythenorth> let them route their own packets :P
20:40:14  <andythenorth> think that was mentioned once :)
20:40:53  <Rubidium> I don't think real railroads have capacity issues when routing (at least passengers)
20:41:10  <Rubidium> they just say: the earliest/fastest connection is: XYZ
20:41:11  <Terkhen> then what we need is a method that works in a graph that changes frequently and also needs to repeat paths a lot because cargopackets tend to use the same source/destination and gives decent results
20:41:36  <Rubidium> even when a million people go via that route, when you could also take a route 10 minutes longer that's empty
20:41:39  <andythenorth> stepping back a bit - what if the packets are generated even if there is no route?
20:41:53  <michi_cc> An inoptimiality inside defined bounds would even be good because then some of the highly volatile routing variables used to balance links could be removed.
20:42:31  <planetmaker> inoptimal != non volatile
20:44:20  <michi_cc> Terkhen: Actually the tuple of (4x4 source map square, 4x4 destination map square, routing flags) does not repeat a lot. I tried a global (source, dest, flag) cache and even without any cache invalidation the benefit wasn't very great. With invalidation, there's almost no benefit left.
20:44:45  <Terkhen> hmm
20:44:52  <Terkhen> ok :)
20:45:00  <Rubidium> I think the major problem of cargo routing is the fact that it isn't point-to-point and it isn't "real time" (compared to internet routing)
20:45:47  <Rubidium> with internet routing you push packets to another host and you can just send X packets per second (which is more or less a constant)
20:46:17  <Terkhen> hmmm... I wonder if a certain algorithm could work in this case, let me check its name
20:46:21  * andythenorth suspects railroad manifest freight routing is point-to-point
20:46:25  <andythenorth> unit trains not
20:46:53  <michi_cc> Terkhen: I have a profile with a very limited cache that purely caches on cargo unloading (because there you often get several identical packets). The 51.07% of YapfChooseRouteLink shrink to 50.70%...
20:46:54  <Rubidium> with OTTD cargo routing you have a "container" for cargo coming in that has some remaining capacity (highly fluctuating) and departs every now and then
20:47:35  <Rubidium> so where for internet it would suffice for: 1 packet over link A, then two over link B, then one over link A, 2 over link B would suffice for spreading load in routing
20:48:29  <Rubidium> for cargo you would send relatively a lot in a train and then a relatively a lot in another taking a slightly longer route
20:49:36  <Rubidium> and as you don't know future capacity you have to guess: should I just fill this train take takes a slightly longer route till its max? Or can everything go in the faster train coming next?
20:50:04  <andythenorth> sounds like a 'know the future' problem
20:50:37  <Rubidium> yup
20:51:05  <andythenorth> how come humans know the future, but we can't teach software how we do it?
20:51:17  <Rubidium> and in the real world you can try some (or a lot of) permutations of routings to find an optimal one, but in OpenTTD you don't have the time for it
20:51:58  <andythenorth> in the real world, excepting PAX, vehicles are sent according to the need to route cargo
20:52:04  <andythenorth> in TTD we don't have that connection
20:52:27  <appe> a bird just told me
20:53:07  <appe> Markk:s circumference exceeds jupiter.
20:54:28  * Rubidium puts himself on a siding ;)
20:56:10  <appe> to explore Markks digestive systems, you would need fusion power.
20:58:32  <Terkhen> michi_cc: I see, I expected a lot more :/
20:59:01  <Terkhen> so that path is not good either
20:59:12  * Terkhen finds an optimal path for today
20:59:14  <Terkhen> good night :)
21:00:45  *** LordAro [] has quit [Quit: "Time is an illusion. Lunchtime doubly so."]
21:11:30  *** Neon [] has quit [Quit: Python is way too complicated... I prefer doing it quickly in C.]
21:15:32  *** tompaw_ [] has quit [Ping timeout: 480 seconds]
21:16:00  *** andythenorth [] has left #openttd []
21:20:49  *** FLHerne [] has joined #openttd
21:23:26  <planetmaker> good night
21:25:08  *** perk11 [~perk11@] has quit [Quit: Miranda IM! Smaller, Faster, Easier.]
21:38:02  *** FLHerne [] has left #openttd []
21:47:30  <Wolf01> 'night all
21:47:32  *** Wolf01 [~wolf01@] has quit [Quit: Once again the world is quick to bury me.]
21:57:27  <appe>
22:03:44  *** pjpe [] has quit [Quit: ajax IRC Client]
22:04:55  *** hanf [] has quit [Quit: Leaving]
22:07:49  *** sla_ro|master [~slaco@] has quit [Ping timeout: 480 seconds]
22:11:22  <Eddi|zuHause> <andythenorth> there is no 'the internet' device <-- ever seen the it crowd? ;)
22:11:53  <Eddi|zuHause> damn, he's gone
22:16:32  *** TWerkhoven[l] [] has quit [Remote host closed the connection]
22:21:30  *** JVassie [~James@] has quit [Read error: Connection reset by peer]
22:22:34  *** Biolunar [] has quit [Quit: All your IRC are belong to us!]
22:24:25  *** JVassie [~James@] has joined #openttd
22:25:46  *** TWerkhoven [] has quit [Quit: He who can look into the future, has a brighter future to look into]
22:31:30  *** sla_ro|master [~slaco@] has joined #openttd
22:32:03  *** sla_ro|master [~slaco@] has quit []
22:32:16  *** sla_ro|master [~slaco@] has joined #openttd
22:35:52  *** Strid__ [] has quit [Ping timeout: 480 seconds]
22:42:55  *** Danio [Danio@] has quit [Remote host closed the connection]
22:47:09  *** JVassie [~James@] has quit [Ping timeout: 480 seconds]
22:48:30  *** welshdragon [] has quit [Quit: This computer has gone to sleep]
22:49:05  *** welshdragon [] has joined #openttd
22:51:08  *** Cybertinus [] has quit [Remote host closed the connection]
23:00:52  *** sla_ro|master [~slaco@] has quit []
23:01:46  *** heffer_ [] has joined #openttd
23:01:51  *** Netsplit over, joins: Fuco, Katje, tty234
23:01:51  *** Netsplit <-> quits: KenjiE20, heffer, snorre_, Elukka, @peter1138, yorick, eQualizer, Noldo, Zeknurn, DabuYu,  (+5 more, use /NETSPLIT to show all of them)
23:01:52  *** Noldo [] has joined #openttd
23:01:57  *** Netsplit over, joins: DabuYu
23:01:57  *** snorre [] has joined #openttd
23:02:13  *** Netsplit over, joins: yorick, TrueBrain, eQualizer, KritiK
23:02:25  *** Netsplit over, joins: avdg
23:02:45  *** Netsplit over, joins: welterde
23:03:24  *** Netsplit over, joins: Zeknurn
23:06:15  *** Brianetta [] has quit [Quit: TschÌß]
23:06:49  *** peter1138 [] has joined #openttd
23:06:52  *** mode/#openttd [+o peter1138] by ChanServ
23:06:57  *** Sacro [~ben@] has joined #openttd
23:14:43  *** glx_ [glx@2a01:e35:2f59:c7c0:297e:9da0:34ca:b0f6] has joined #openttd
23:14:44  *** glx is now known as Guest13867
23:14:44  *** glx_ is now known as glx
23:15:20  *** Strid__ [] has joined #openttd
23:18:37  *** heyheyy [] has joined #openttd
23:21:06  *** Guest13867 [glx@2a01:e35:2f59:c7c0:297e:9da0:34ca:b0f6] has quit [Ping timeout: 480 seconds]
23:21:42  *** welshdragon [] has quit [Quit: This computer has gone to sleep]
23:25:32  *** heyhey [] has quit [Read error: Operation timed out]
23:25:38  *** mib_apmba8 [] has joined #openttd
23:26:05  *** mib_apmba8 [] has quit []
23:27:37  *** DOUK [] has quit [Read error: Connection reset by peer]
23:29:08  *** Progman [] has quit [Remote host closed the connection]
23:32:36  *** peter1139 [] has joined #openttd
23:34:04  *** Sacro_ [~ben@] has joined #openttd
23:34:10  *** Netsplit <-> quits: Sacro, @peter1138
23:46:45  *** heyheyy [] has quit []
23:46:48  *** heyhey [] has joined #openttd
23:58:04  *** pjpe [] has joined #openttd

Powered by YARRSTE version: svn-trunk