Back to Home / #openttd / 2011 / 10 / Prev Day | Next Day
#openttd IRC Logs for 2011-10-17

---Logopened Mon Oct 17 00:00:46 2011
00:57-!-Eddi|zuHause2 [~johekr@p54B73FDD.dip.t-dialin.net] has joined #openttd
01:03-!-Eddi|zuHause [~johekr@p54B7269A.dip.t-dialin.net] has quit [Ping timeout: 480 seconds]
01:28-!-Prof_Frink [~proffrink@5e0a9627.bb.sky.com] has quit [Ping timeout: 480 seconds]
01:48-!-Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has joined #openttd
02:03<@Terkhen>good morning
02:08-!-DayDreamer [~DayDreame@ip-86-49-59-175.net.upcbroadband.cz] has joined #openttd
02:12-!-sla_ro|master [~slaco@95.76.27.160] has joined #openttd
03:11-!-DayDreamer [~DayDreame@ip-86-49-59-175.net.upcbroadband.cz] has quit [Read error: Connection reset by peer]
03:18<dihedral>greetings
03:19-!-SirSquidness [~sirsquidn@zomg.dongues.com] has quit [Ping timeout: 480 seconds]
03:24<@Terkhen>hi dihedral
03:26<@planetmaker>hello dihedral
03:31-!-SirSquidness [~sirsquidn@zomg.dongues.com] has joined #openttd
03:40-!-Neon [~Neon@dslb-094-219-031-138.pools.arcor-ip.net] has joined #openttd
03:55-!-Elukka [~Elukka@89-166-103-135.bb.dnainternet.fi] has joined #openttd
04:06-!-Eddi|zuHause2 is now known as Eddi|zuHause
04:19-!-Progman [~progman@p57A1BCB4.dip.t-dialin.net] has joined #openttd
04:43-!-pjpe [ade6a119@ircip4.mibbit.com] has quit [Quit: http://www.mibbit.com ajax IRC Client]
04:59-!-Neon [~Neon@dslb-094-219-031-138.pools.arcor-ip.net] has quit [Quit: Python is way too complicated... I prefer doing it quickly in C.]
05:01-!-Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has joined #openttd
05:32-!-Bolt_ [~chatzilla@124-168-110-10.dyn.iinet.net.au] has joined #openttd
05:37*Bolt_ waves and says 'howdy folks'
05:41<@Terkhen>hi Bolt_
05:42-!-TheMask96 [~martijn@greed.vhost.ne2000.nl] has quit [Ping timeout: 480 seconds]
05:46-!-TheMask96 [~martijn@gluttony.vhost.ne2000.nl] has joined #openttd
05:54-!-Bolt_ is now known as the
05:55-!-the is now known as the_bolt
06:00-!-sla_ro|master [~slaco@95.76.27.160] has quit []
06:01-!-Eddi|zuHause [~johekr@p54B73FDD.dip.t-dialin.net] has quit [Remote host closed the connection]
06:01-!-Eddi|zuHause [~johekr@p54B73FDD.dip.t-dialin.net] has joined #openttd
06:15<@planetmaker>hello the_bolt
06:15<@planetmaker>maybe you could fix your too many white space in the op code patch?
06:16<@planetmaker>and dunno... maybe you just open an FS task about it, too
06:23<the_bolt>maybe?
06:23<the_bolt>gladly!!
06:23<the_bolt>I posted into the forums as requested.
06:27-!-dageek [~dageek@2001:8b0:ff85:0:223:6cff:fe87:e49c] has joined #openttd
06:31<the_bolt>the updated patch for the 'GetOpsTillSuspend() is available at http://paste.openttdcoop.org/show/648/ does it meet your requirements?
06:34<@planetmaker>I think so :-)
06:41-!-DayDreamer [~DayDreame@ip-86-49-59-175.net.upcbroadband.cz] has joined #openttd
06:44<the_bolt>patch added to FS>
06:44<the_bolt>next - to document performance do's and don't for the wiki
06:53<Arafangion>If you're so worried about performance, why don't you put the C++ classes entirely in the header?
07:00<@Terkhen>bbl
07:13-!-DayDreamer [~DayDreame@ip-86-49-59-175.net.upcbroadband.cz] has quit [Read error: Connection reset by peer]
07:13<the_bolt>the performance is for the AI script.
07:17<Eddi|zuHause>even if not, what do headers have to do with performance?
07:25<the_bolt>GTG.
07:25-!-the_bolt [~chatzilla@124-168-110-10.dyn.iinet.net.au] has quit [Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20110928134238]]
07:28<Arafangion>Eddi|zuHause: Certain styles of implementation are much easier to inline.
07:30<Eddi|zuHause>Arafangion: but apart from a few special cases, inlining has hardly any effect on performance
07:33<Arafangion>Eddi|zuHause: Depends on what you mean by "special".
07:34<Eddi|zuHause>Arafangion: "special" as in "that is currently already done"
07:49-!-pugi [~pugi@dyndsl-091-096-006-139.ewe-ip-backbone.de] has joined #openttd
08:08-!-Arafangion [~Arafangio@220-244-108-23.static.tpgi.com.au] has quit [Remote host closed the connection]
08:22-!-glx [glx@2a01:e35:2f59:c7c0:297e:9da0:34ca:b0f6] has joined #openttd
08:22-!-mode/#openttd [+v glx] by ChanServ
08:39-!-Neon [~Neon@dslb-094-219-187-110.pools.arcor-ip.net] has joined #openttd
08:40-!-SirSquidness [~sirsquidn@zomg.dongues.com] has quit [Ping timeout: 480 seconds]
08:56-!-Arafangion [~Arafangio@220-244-108-23.static.tpgi.com.au] has joined #openttd
08:57-!-DayDreamer [~DayDreame@ip-86-49-59-175.net.upcbroadband.cz] has joined #openttd
09:01<Arafangion>AdmiralAI seems to take ages to start (On a highly populated 64x64 map!)
09:02-!-Kurimus [~stabbity@dsl-tkubrasgw3-fe93dd00-34.dhcp.inet.fi] has joined #openttd
09:02-!-dageek [~dageek@2001:8b0:ff85:0:223:6cff:fe87:e49c] has quit [Ping timeout: 480 seconds]
09:05-!-dageek [~dageek@11.74.155.90.in-addr.arpa] has joined #openttd
09:13<Arafangion>Interesting - on my map, DictatorAI is making more money than gelignAlte.
09:19<@Belugas>hello
09:21-!-DayDreamer1 [~DayDreame@ip-86-49-59-175.net.upcbroadband.cz] has joined #openttd
09:21*Arafangion looks at Belugas suspiciously.
09:21*planetmaker looks at Arafangion suspiciously and waves 'hello' to Belugas
09:22*Belugas wonders what's wrong with Arafangion and waves a big smiley hello to planetmaker :)
09:23-!-DayDreamer [~DayDreame@ip-86-49-59-175.net.upcbroadband.cz] has quit [Ping timeout: 480 seconds]
09:25*Arafangion mumbles, looks inwards and returns to The Game.
09:27<@Belugas>crossed eyes Arafangion :)
09:27*Arafangion implodes.
09:43-!-HerzogDeXtEr1 [~Flex@i59F6BEFD.versanet.de] has joined #openttd
09:49-!-HerzogDeXtEr [~Flex@i59F6D0DB.versanet.de] has quit [Ping timeout: 480 seconds]
10:00-!-fjb [~frank@p5DDFD497.dip.t-dialin.net] has joined #openttd
10:00-!-George is now known as Guest13802
10:00-!-George [~George@212.113.107.39] has joined #openttd
10:01<fjb>Moin
10:07-!-Guest13802 [~George@212.113.107.39] has quit [Ping timeout: 480 seconds]
10:11<Eddi|zuHause>Elukka: here is a tank wagon (ca. 1910): http://www.hafenbahnhof.de/vorbild/farben/sachsen/imggut/feher548x282.jpg
10:12<Elukka>i was drawing something very similar
10:12<Elukka>think i'll do multiple color variants
10:13<Eddi|zuHause>not entirely sure about the length, though
10:14<Elukka>i figure it can't be too far off the length of the other freight cars
10:14<Elukka>which both round off to 5 lu
10:14<Eddi|zuHause>8800m (4lu) is a common figure i found
10:15-!-Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has quit [Quit: Tschüß]
10:15<Eddi|zuHause>mm
10:15<Eddi|zuHause>of course
10:25<Eddi|zuHause>Elukka: we can also use recolouring for the wagons
10:31-!-Br33z4hSlut5 [~static.kp@92.68.154.34] has quit [Remote host closed the connection]
10:37-!-Doorslammer [7da86216@ircip1.mibbit.com] has joined #openttd
10:39<Elukka>at 8.8 / 24 x 12 it's 4 lu, at 8.8 / 24 x 12.5 it's barely 5
10:39<Elukka>i suppose recoloring would be a bit easier
10:40-!-Pulec [~pulec@193.84.36.96] has joined #openttd
10:58<MNIM>hmmmh.
10:58<MNIM>why is my overflow depot not working?
11:00<@planetmaker>why did the chicken cross the road?
11:01<__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)
11:03-!-Adambean [AdamR@82.hosts.reece-eu.net] has joined #openttd
11:03<@planetmaker>I think it's false
11:03<@planetmaker>50% of the people are women
11:03<@planetmaker>50% of the people have black hair
11:03<@planetmaker>not 100% are black-haired women
11:05<@planetmaker>but that doesn't fit the assumptions... I see :-)
11:07-!-SirSquidness [~sirsquidn@zomg.dongues.com] has joined #openttd
11:09-!-Prof_Frink [~proffrink@5e0a9627.bb.sky.com] has joined #openttd
11:11<__ln__>today's exam question was to prove that one to be correct.
11:11<b_jonas>__ln__: it's true
11:11<b_jonas>__ln__: but if you want a proof, you might want to ask on another channel (eg. freenode #math )
11:13<__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.
11:22<@Yexo>why is P(A union B) always 1 in that case/
11:23<@planetmaker>complement is always dependent. Not independent
11:25-!-Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has joined #openttd
11:26-!-perk11 [~perk11@188.32.29.238] has joined #openttd
11:27<__ln__>that might be the key to why the magic fails
11:30-!-Doorslammer [7da86216@ircip1.mibbit.com] has quit [Quit: http://www.mibbit.com ajax IRC Client]
11:34-!-Pulec [~pulec@193.84.36.96] has quit [Read error: Connection reset by peer]
11:35<__ln__>thanks
11:35-!-sla_ro|master [~slaco@95.76.27.160] has joined #openttd
11:50-!-dageek [~dageek@11.74.155.90.in-addr.arpa] has quit [Quit: dageek]
12:09-!-Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has quit [Quit: Tschüß]
12:09-!-fjb [~frank@p5DDFD497.dip.t-dialin.net] has quit [Remote host closed the connection]
12:11-!-TWerkhoven [~twerkhove@cpc14-linl7-2-0-cust28.sgyl.cable.virginmedia.com] has joined #openttd
12:19<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)
12:20<Eddi|zuHause>er
12:20<Eddi|zuHause>wrong
12:20<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
12:20<Eddi|zuHause>still wrong
12:20<Eddi|zuHause>1-(1-p)^2
12:21<Eddi|zuHause>anyway, 1 = 1-(1-p)^2 => p=1
12:22<Eddi|zuHause>anyway, gtg
12:22<__ln__>thnx
12:22<Eddi|zuHause>the step 1-P(¬A \cap ¬B) = 1-P(¬A)*P(¬B) requires independence
12:39<@peter1138>¬ is used
12:39<@peter1138>for the first time
12:47<@peter1138>you know, the more recent title screen games just don't feel right
12:48<@peter1138>it's really missing the level crossings and the fog horns
12:51<Elukka>more recent title screens exist?
12:51<@peter1138>the one you get when you play a release
12:52<@peter1138>i don't know how often it changes
12:53<@Terkhen>the last two releases had a voting contest to select different title screen games
12:56<@peter1138>hmm, i should try the scott joplin pack through pianoteq
12:57-!-pjpe [ade6a119@ircip4.mibbit.com] has joined #openttd
12:57<@planetmaker>each release branch probably gets its own title game
12:58<Elukka>ooh
12:58<Elukka>but nightlies still use the old one?
12:58<@planetmaker>they always will continue to use the same, yes
12:58<Elukka>you can kinda tell it's not really made with modern screen resolutions in mind... since most of it is empty
12:59<@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
12:59<@planetmaker>yes
12:59<@planetmaker>but for nightly that's not important really ;-)
12:59<@planetmaker>the important property there is: it's a savegame of savegame version 4.
12:59<Elukka>i suppose it's not vital
12:59<@planetmaker>And now we have 16x
12:59<@planetmaker>thus it's a savegame conversion test implicitly ;-)
12:59<Elukka>clever
13:00<@planetmaker>but most people anyway use stable. They get nice starting screens. Or so at least the majority of people who voted thought ;-)
13:00<@planetmaker>So if you want... start making one. There'll be another contest around... December ... February or so
13:01<Elukka>i'd never see it since i haven't played stables for years
13:01<@planetmaker>well :-)
13:01<@planetmaker>Doesn't need to stop you
13:01-!-pugi__ [~pugi@dyndsl-095-033-157-068.ewe-ip-backbone.de] has joined #openttd
13:03<@peter1138>shame these midi pieces are too perfect :(
13:03<@planetmaker>:-D
13:03<@peter1138>exactly the same velocity for every note
13:04<@peter1138>exactly the same timing
13:04<@peter1138>etc
13:04<@peter1138>sounds... dull
13:04<@planetmaker>peter1138: don't you own a midi device?
13:04<@planetmaker>i.e. where are your midi files for a sound set? ;-)
13:05<@peter1138>urghgrgrhgrghrg
13:05<@peter1138>this piece is adjusting the master volume
13:05<@peter1138>instead of adjusting velocity :S
13:05<@peter1138>wrong wrong wrong :S
13:06<@peter1138>my midi files for a sound set? what do you mean?
13:07-!-pugi [~pugi@dyndsl-091-096-006-139.ewe-ip-backbone.de] has quit [Ping timeout: 480 seconds]
13:07-!-pugi__ is now known as pugi
13:07<@planetmaker>I mean your music pieces. As midi files
13:07<@planetmaker>Dunno if it's feasible with your equipment
13:09<@peter1138>i never record the midi from the keyboard
13:09*Belugas does not think peter1138's excessive use of digital effets can be recorded in midi :)
13:09<@peter1138>and indeed
13:09<@peter1138>i use a variety of midi synths
13:09<@peter1138>not usually a soundfont synth
13:09<@peter1138>(although i have done)
13:10<@peter1138>and the guitar isn't midi, heh
13:10<@Belugas>well... yours and mine... Charles has 2 midi guitars
13:11<@peter1138>maybe
13:11<@peter1138>that would sound odd through a soundfont player :)
13:11<@Belugas>but granted, the idi part is only to grab the events on the guitars
13:12<@Belugas>as soon as his devise reads them, they are digiatlly processed and output as waves
13:12<@Belugas>i'l have to ask him, peter1138, but i doubt he'll waste tie on it ;)
13:14<@Belugas>#In the dead of nights
13:14<@Belugas>#Love Bites!
13:15-!-hanf [~Klaus@host-89-242-67-211.as13285.net] has joined #openttd
13:19-!-TheMask96 [~martijn@gluttony.vhost.ne2000.nl] has quit [Ping timeout: 480 seconds]
13:20<@Yexo>Elukka: you could still download the a stable version and just copy opntitle.dat from there to your nightly install
13:21<@peter1138>or not care
13:21<@peter1138>hey cool, some 32bpp graphics ;p
13:23-!-TheMask96 [~martijn@sloth.vhost.ne2000.nl] has joined #openttd
13:24-!-LordAro [~lordaro@host86-156-236-122.range86-156.btcentralplus.com] has joined #openttd
13:24<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.
13:27-!-frosch123 [~frosch@frnk-590ffcc0.pool.mediaWays.net] has joined #openttd
13:28<LordAro>evening
13:29<@Terkhen>hi LordAro
13:30<LordAro>hi terkhen
13:31<LordAro>*Terkhen :)
13:31<@Terkhen>no need to highlight me twice :P
13:33<@peter1138>Terkhen
13:33<@peter1138>Terkhen, sure?
13:33<@Terkhen>:P
13:34<LordAro>:)
13:40<b_jonas>though their complicated examples are over my head
13:40-!-Wolf01 [~wolf01@95.237.235.128] has joined #openttd
13:40<b_jonas>I might still learn a bit at a time
13:40<Wolf01>hello
13:40<@Terkhen>hi Wolf01
13:42<@peter1138>some of it isn't relevant
13:43<b_jonas>sure
13:43<@peter1138>actually none of it is, to my playing style :p
13:48<frosch123>Terkhen: doesn't the second highlight cancel the first one?
13:49<@Terkhen>not if I already checked the first one and alt tabbed again
13:50-!-glx_ [glx@2a01:e35:2f59:c7c0:297e:9da0:34ca:b0f6] has joined #openttd
13:50-!-glx is now known as Guest13824
13:50-!-mode/#openttd [+v glx_] by ChanServ
13:50-!-glx_ is now known as glx
13:55-!-valhallasw [~valhallas@vpn91.ext.espci.fr] has joined #openttd
13:56-!-Guest13824 [glx@2a01:e35:2f59:c7c0:297e:9da0:34ca:b0f6] has quit [Ping timeout: 480 seconds]
14:07-!-JVassie [~James@2.25.206.0] has joined #openttd
14:09-!-DayDreamer1 [~DayDreame@ip-86-49-59-175.net.upcbroadband.cz] has quit [Read error: Connection reset by peer]
14:19-!-TWerkhoven[l] [~turbulent@cpc14-linl7-2-0-cust28.sgyl.cable.virginmedia.com] has joined #openttd
14:23-!-DayDreamer [~DayDreame@ip-86-49-59-175.net.upcbroadband.cz] has joined #openttd
14:23-!-DayDreamer [~DayDreame@ip-86-49-59-175.net.upcbroadband.cz] has quit []
14:28-!-Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has joined #openttd
14:37-!-DDR_ [~chatzilla@142.179.78.88] has joined #openttd
14:44<b_jonas>they're building logic gates from presignals! that's crazy.
14:45<b_jonas>and they're actually deliberately using the bugs in the old signal behaviour
14:48-!-andythenorth [~Andy@cpc15-aztw25-2-0-cust3.aztw.cable.virginmedia.com] has joined #openttd
14:50<DDR_>b_jonas: OpenTTD Coop, right?
14:50<b_jonas>DDR_: yes, I was looking at the openttdcoop wiki to learn a bit about track layouts
14:53<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
14:53<b_jonas>I guess that's because ships get a bonus for station rating computation, right?
14:54<b_jonas>should I be using feeder ships to fool stations into giving me better ratings?
14:54<frosch123>yes
14:54<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
14:54<frosch123>well, the max speed of the last vehicle visiting a station also affects rating
14:55<frosch123>which compensates the ship bonus usually :p
14:56<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.
14:56<DDR_>You're a brave, brave man.
14:56-!-Biolunar [mahdi@blfd-4d086e2f.pool.mediaWays.net] has joined #openttd
14:59<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.
15:00<Pinkbeast>Really? Some of their stuff still used block signals last I looked.
15:00<Pinkbeast>I think the wiki has pretty good information on normal stations and junctions.
15:00<DDR_>Hm.
15:00<b_jonas>Pinkbeast: true, and I did mention they seem to use old signal bugs as well
15:00-!-AcidWeb [~AcidWeb@vulturis.eu] has joined #openttd
15:00<frosch123>Pinkbeast: in case you did not notice, they use non-path signals intentionally
15:00<AcidWeb>Hello
15:01<b_jonas>Pinkbeast: but they're using pre-signals for exotic logic blocks that I'm not sure you can build from path signals
15:01<frosch123>because they are more advanced than path signals when used correctly
15:01<b_jonas>they're using pre-signals for priority thingy
15:01<frosch123>path signals are for people with less than 7 platforms :p
15:02<DDR_>Heh!
15:02<Pinkbeast>What I'm saying is _the last time I looked_ there were still layouts that used block signals because they predated path signals.
15:02<DDR_>I wouldn't put it past them to save old-but-impressive signal layouts.
15:03<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.
15:03<AcidWeb>What may cause ppl randomly drop from multiplayer game? "Client dont respond in X days" error or something like that
15:03<@Yexo>bad internet connection
15:04<b_jonas>Pinkbeast: I at least learnt how they build junctions that connect a sideline to a mainline
15:04<b_jonas>I used something like that in my last game
15:04<b_jonas>before reading their wiki that is
15:05<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?
15:05<AcidWeb>Hmm but all ppl are affected. Not only one drop randomly.
15:05<b_jonas>DDR_: terminus, roro
15:05<DDR_>AcidWeb: It might be the server's connection, or just wider hickups in the network...
15:05<DDR_>Thanks.
15:05<AcidWeb>DDR_: Server got 100/100 connection.
15:06<AcidWeb>And some other services that working correctly.
15:06<@planetmaker>DDR_: I'd not argue that block signal layouts are all outdated
15:07<b_jonas>planetmaker: how about pre-signal layouts for giving priority to a line over another one?
15:07-!-andythenorth is now known as Guest13836
15:07-!-andythenorth_ [~Andy@cpc15-aztw25-2-0-cust3.aztw.cable.virginmedia.com] has joined #openttd
15:07-!-andythenorth_ is now known as andythenorth
15:07-!-andythenorth_ is "(unknown)" on (unknown)
15:07<@planetmaker>b_jonas: that's one place where path signals cannot help a lot
15:08-!-Guest13836 [~Andy@cpc15-aztw25-2-0-cust3.aztw.cable.virginmedia.com] has quit [Read error: Connection reset by peer]
15:09<b_jonas>hmm, which mode of transport should I use for this forest? road, train?
15:11<DDR_>How far is it going?
15:12<DDR_>How much wood do you have to transport?
15:12<DDR_>What year is it?
15:12<Rubidium>ships ofcourse
15:13<Rubidium>specifically: http://www.tt-forums.net/download/file.php?id=120065
15:13<andythenorth>lots of ships
15:14<AcidWeb>Maybe i screwed network settings? net_frame_freq = 2 net_sync_freq = 50
15:14<andythenorth>try using a river :P
15:15<DDR_>b_jonas: ?
15:15<Rubidium>the speed of a connection says nothing about the stability of said connection
15:16<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
15:16<@Terkhen>AcidWeb: what's the size of the map?
15:16<AcidWeb>512x512
15:17<b_jonas>Rubidium: yes, I have FISH loaded
15:17<Elukka>anyone know if YACD is still being actively developed?
15:17<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
15:17<Elukka>i'm kinda on an ottd hiatus because i really want to play with yacd but it's not playable enough yet...
15:17<b_jonas>I couldn't download BIRD though (the corresponding airplane GRF)
15:17<AcidWeb>Im using AP+ it that change anything.
15:17<Rubidium>Elukka: I think michi_cc knows
15:17<@Terkhen>Elukka: to my knowledge it is on hiatus right now but ^
15:18<DDR_>What is YACD?
15:18<Elukka>i hope it's not on a permanent hiatus!
15:18<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.
15:18<@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
15:18<@Terkhen>DDR_: check the YACD thread at the development subforum
15:20<+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).
15:20<@planetmaker>hm, so speed is the problem?
15:21<Elukka>i see
15:21<@Terkhen>btw michi_cc, my approach to subsidies is using the part of YACD you suggested :)
15:21<andythenorth>which bits are slow?
15:21<Elukka>i hope you work on it in the future, it's such a great addition to the game :)
15:21<@Terkhen>I still have to fix subsidy creation, but the house acceptance/production code is done already
15:21<Elukka>really i'd rather play on smaller maps with yacd than on large maps without it
15:21<Elukka>if it was too slow to play on big maps
15:22<@Terkhen>hmm... and I was waiting on YACD for playing again too :P
15:22<+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.
15:22<Elukka>okay, that sounds like an issue
15:23<@Terkhen>what parts could be multithreaded?
15:23<DDR_>oo, yacd looks nice. Seems to be the same idea behind cargo that Simutrans has, but without sucking like Simutrans does.
15:23<andythenorth>YACD does use ~2x more CPU than non-YACD
15:23<andythenorth>on my box
15:24*Terkhen wouldn't even know how to start to add multicore support :P
15:24-!-Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has joined #openttd
15:24-!-mode/#openttd [+o Alberth] by ChanServ
15:24<@Terkhen>hi Alberth
15:24-!-Adambean [AdamR@82.hosts.reece-eu.net] has quit [Quit: Gone fishing]
15:24<@Alberth>hi
15:25<@planetmaker>Terkhen: the only thing I can vaguely imagine is to move drawing to a completely separate thread
15:25<@planetmaker>but how? No idea
15:25<@planetmaker>hi Alberth
15:26<Rubidium>planetmaker: doesn't help much
15:26<+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).
15:26<andythenorth>how does simutrans handle cargo packets?
15:26<@Alberth>anything known about weird names for wagons in opengfx+trains?
15:26<@planetmaker>andythenorth: simutrans has no reall MP support
15:26<@planetmaker>-l
15:26<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
15:27<@planetmaker>Rubidium: Not? I wonder... My OpenTTD uses even on idle 15% CPU of the core it runs on
15:27<Rubidium>and the rest is already in a seperate thread on SDL/Allegro
15:27<@planetmaker>Rubidium: yes... but redrawing once per tick... hm...
15:27<@Terkhen>I can't think of anything that is not tightly coupled with the rest of the code
15:28<Rubidium>hmm, sorry... only on SDL
15:28<@Yexo>perhaps part of the tileloop could be threaded, although even that would be very tricky to get right
15:28<@planetmaker>I wonder whether it might start to become interesting to mulithread things even if it gives a penalty on single core systems
15:29<DDR_>Probably, very few people have single-threaded systems anymore.
15:29<@planetmaker>single-threaded: hardly ;-)
15:29<Rubidium>planetmaker: the game state is so interdependant on eachother and on the execution order that I don't think much can be achieved
15:29<+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.
15:29<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.
15:30<@planetmaker>Rubidium: I seem to recall reading like 5 ... 10% somewhere?
15:30<@Terkhen>hmm...
15:30<@Terkhen>so it needs a huge amount of changes to how the tileloop works first :)
15:30<Rubidium>planetmaker: yes, *without* any locking
15:30<andythenorth>does each packet have to calculate a full path on each tick?
15:30<Rubidium>i.e. desync heaven
15:30<andythenorth>or just next hop? or what?
15:30<Rubidium>andythenorth: only when loading/unloading
15:30<@planetmaker>hm, desync heaven. nice
15:31<Rubidium>even then, profile the game to see what takes a lot of time
15:32<Elukka>now i'm depressed that yacd might never get finished :(
15:32<Rubidium>IIRC making/removing fences takes relatively much
15:32<frosch123>on an empty map
15:33<@Alberth>http://devs.openttd.org/~alberth/non-english-wagons.png <-- doesn't look like UK english names to me :p
15:33<+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.
15:33<@planetmaker>they look pretty Dutch, Alberth ;-)
15:34<@planetmaker>Did I mess up naming somewhere?
15:34<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)
15:34<@Alberth>I am quite sure "vogn" is not Dutch either :)
15:34<Rubidium>they don't look Dutch to me
15:34<Elukka>vogons!
15:34<@Alberth>it is supposed to be UK english
15:35<Rubidium>it's rather Norwegian or some other Scandinavian language
15:35*Alberth thinks so to
15:35<frosch123>danish
15:35<@Alberth>*too
15:35-!-DDR_ [~chatzilla@142.179.78.88] has quit [Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20110928224508]]
15:36<@planetmaker>hm... :-) I shall look into that. Thanks, Alberth
15:36<@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
15:36<frosch123>http://da.wikipedia.org/wiki/Vogn
15:36<andythenorth>michi_cc: what could you do less of (i.e. worse, but acceptable)?
15:36<@planetmaker>The trains anyway need to make use of michi's new cargo aging property :-)
15:36<@Alberth>aka, "not known" thus :)
15:38<@Alberth>planetmaker: do you want me to make an issue about it?
15:38-!-KritiK [~Maxim@95-28-34-176.broadband.corbina.ru] has joined #openttd
15:40<AcidWeb>Can AP+ can cause cause that player drops?
15:40<+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.
15:41<@Yexo>Alberth / planetmaker: the grf is fine, it's a bug in openttd
15:41<@Yexo>in openttd 1.1.3 it works as expected
15:41<@Alberth>how nice :p
15:44-!-Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has quit [Remote host closed the connection]
15:45<@planetmaker>he, interesting
15:45<+michi_cc>YACD profile: http://www.icosahedron.de/openttd/patches/YACD-gameloop.png (created with KCachegrind, source data http://www.icosahedron.de/openttd/patches/openttd-base.callgrind )
15:45-!-Kurimus [~stabbity@dsl-tkubrasgw3-fe93dd00-34.dhcp.inet.fi] has quit []
15:45*Terkhen needs to learn to use that program :P
15:47<frosch123>wow, three different chains ending in the same function :o
15:47<+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).
15:48<+michi_cc>The part below ChooseRouteLink "suffers" from inlining (adding a new node is not nearly as expensive as it seems :)
15:48<@Terkhen>so it expends most of the time calculating cargo paths again and again
15:48<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?
15:49<@Terkhen>AcidWeb: yes
15:51<AcidWeb>That is answer why most servers i see have them disabled.
15:51<+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).
15:51<AcidWeb>Need tweak server. Limit of 10 is to high.
15:52<AcidWeb>Client #63 is dropped because the client did not respond for more than 4 game-days
15:52<AcidWeb>sigh.
15:52<AcidWeb>Also need find a reason of that ;p
15:52<@Alberth>too big map, too busy map, too fast server
15:53<+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.
15:53<AcidWeb>Alberth: To fast server?
15:53<@Alberth>or too slow client, depending on your point of view :p
15:54<@Yexo>AcidWeb: you get that when the map is very busy and the client is not fast enough
15:54<AcidWeb>hmm
15:54<AcidWeb>I cant call this map busy
15:54<AcidWeb>Also it is only 512x512
15:55<+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.
15:55-!-Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has joined #openttd
15:55<AcidWeb>There is any option to "slow" the server?
15:57<@planetmaker>not for a client
15:58<AcidWeb>Autopilot sending some additional commands every 30 seconds may cause ppl problems?
15:59<+glx>512x512 is big
16:00<+glx>4 times bigger than default size
16:01<AcidWeb>Im just looking for answer on main question. If i screwed something? :D
16:01<AcidWeb>And if yes how to fix it.
16:02<AcidWeb>If it is client problem ok - i dont like it but i will live with that.
16:02<@Alberth>did you try pausing the game when a client connects?
16:03<@Terkhen>michi_cc: hmm... 23.95% is quite big... even if it can't be tricked away, that part could use some optimization
16:03<AcidWeb>as i observer that is not connected.
16:04-!-DDR_ [~chatzilla@142.179.78.88] has joined #openttd
16:04<AcidWeb>also there are no pattern in that drops
16:05<AcidWeb>It just sometime drop random ppl.
16:05<@Alberth>network connections are stochastic yes
16:07<+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
16:07<+michi_cc>o be the time when this part uses more and more time due to town growth).
16:09<andythenorth>how many graphs are there on any one map?
16:11<+michi_cc>andythenorth: http://www.icosahedron.de/openttd/patches/YACD-graph.png
16:12<@Terkhen>I see...
16:12<andythenorth>:)
16:12<@Terkhen>it's a complicated problem :(
16:13<andythenorth>this would be easier if we limited the game to 1 cargo :P
16:13<AcidWeb>Anyway thank you for help. Maybe that is just hickup.
16:13<andythenorth>I think there's only one graph in that map for PAX
16:14<andythenorth>with one graph, all you need to check is coverage
16:15<andythenorth>with 2 graphs...you'd need to check coverage, and if the start / end nodes are in the same graph
16:15*andythenorth is a newbie at network theory :P
16:16<+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.
16:16<andythenorth>and calculating the path is expensive?
16:17*andythenorth wonders how Railroad Tycoon 3 solved this, on older machines, while running a 3D engine
16:17<andythenorth>probably a different problem, for a different codebase
16:18<@Yexo>andythenorth: a lot smaller maps, so less vehicles, less cargo
16:18<@Yexo>did it have mp support?
16:18<DDR_>Hm, I think if you did some tricky work with minimizing the track layout, it becomes a trivial problem.
16:18<andythenorth>no mp support
16:18<frosch123>night
16:18<DDR_>Ah.
16:18-!-frosch123 [~frosch@frnk-590ffcc0.pool.mediaWays.net] has quit [Remote host closed the connection]
16:18<@Yexo>that is also a huge advantage
16:18<andythenorth>RT3 had a different way of routing cargo
16:18<@Yexo>since without mp support you don't have to worry about desyncs
16:19<andythenorth>how does the internet route packets?
16:19<andythenorth>conceptually
16:20<@Alberth>non-deterministically
16:20<andythenorth>I guess the computational load is handled by n devices too
16:20<andythenorth>there is no 'the internet' device
16:20<andythenorth>unless they're not telling us
16:20<@Alberth>it wouldn't be able to handle the load :)
16:21<andythenorth>hmm
16:21<andythenorth>YACD is rather nice to play with :)
16:21<+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.
16:21<@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 :)
16:22-!-welshdragon [~welshdrag@client-86-31-15-90.midd.adsl.virginmedia.com] has joined #openttd
16:23<andythenorth>michi_cc: do you have to calculate the entire path?
16:23<+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.
16:23<andythenorth>yes
16:23<andythenorth>it made for a fun game, although many disagreed :)
16:23<@Terkhen>sounds more boring than YACD
16:24-!-Danio [Danio@83.101.65.8] has joined #openttd
16:26<+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).
16:26*andythenorth has ants in mind
16:26<andythenorth>ants leave markers behind for other ants to follow....
16:28<@Alberth>Yexo / planetmaker: bisecting gives me r22970 to blame
16:28<@Terkhen>I don't think that ACO is appropiate for this problem
16:28<+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...
16:28<@Terkhen>too many paths, you'll need too many ants :P
16:28<@Yexo>Alberth: just found that out too :)
16:28<andythenorth>ahttp://wiki.squeak.org/squeak/5633
16:29<CIA-6>OpenTTD: yexo * r23036 /trunk/src/newgrf.cpp: -Fix (r22970): swapped parameters resulted in wrong vehicle names
16:29<andythenorth>http://www.cs.virginia.edu/~wz5r/cs655/proposal.htm
16:30<andythenorth>these are theories, not working code :)
16:30<@Terkhen>there must be a good method for a graph that changes a lot
16:30<andythenorth>ant routing apparently performs badly in that case
16:30<andythenorth>http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4438316
16:30<@Terkhen>s/method/heuristic method/
16:30<@Terkhen>but then you are not getting optimal paths :)
16:30<@Alberth>Yexo: thanks for fixing :)
16:30<andythenorth>does the graph change a lot?
16:30<andythenorth>in a typical game?
16:31<@Yexo>you're welcome :)
16:31<Rubidium>andythenorth: every time you change an order or change the time it takes a train to go from A to B
16:31<andythenorth>http://www.google.com/url?sa=t&source=web&cd=1&ved=0CBkQFjAA&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.75.8808%26rep%3Drep1%26type%3Dpdf&rct=j&q=routing%20for%20a%20topology%20that%20changes%20often&ei=mpCcTuWvIYvVsgbDx4CBBA&usg=AFQjCNHdVKlObKqRwZrQvnpfiSByQEwMlg
16:31<@Alberth>good night all
16:31<@Terkhen>andythenorth: if it is taking into account stuff such as "waiting cargo" then it is changing all the time
16:31<Rubidium>night Alberth
16:31<@Terkhen>good night Alberth
16:33-!-Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has left #openttd []
16:34-!-AcidWeb [~AcidWeb@vulturis.eu] has left #openttd []
16:34<andythenorth>http://ceng.usc.edu/~bkrishna/research/papers/RoutingWithoutRoutes_IPSN10.pdf
16:34<andythenorth>ok
16:34<andythenorth>so it's a known difficult problem :P
16:34<@Terkhen>:)
16:35<andythenorth>michi_cc: if we can solve it, maybe we can patent it :)
16:36<andythenorth>and then license it to cisco et al
16:36<andythenorth>and use the income to implement TTD 3D :P
16:36<andythenorth>:D
16:36*andythenorth is only partly fooling and is partly serious :o
16:36<andythenorth>a large TTD map represents a moderately complex routing situation that needs solving with relatively few computing resources
16:37<+michi_cc>Somehow I get the feeling we're not the first humans trying to find a solution to this problem :)
16:37<@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
16:37<Rubidium>andythenorth: internet routing is "easier". You only got point-to-point connections.
16:38<Rubidium>i.e. the packet will always be offloaded at the next station regardless of how it goes further
16:39<@planetmaker>traveling salesman problem ;-)
16:39<andythenorth>Terkhen: what constitutes 'optimal' ?
16:39<@Terkhen>hmm... good question :)
16:39<andythenorth>I was wondering earlier today (for non-related reasons) how real railroads solve this
16:39<Rubidium>andythenorth: spread evenly over the capacity
16:39<+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.
16:40<@Terkhen>ok :)
16:40<andythenorth>let them route their own packets :P
16:40<andythenorth>think that was mentioned once :)
16:40<Rubidium>I don't think real railroads have capacity issues when routing (at least passengers)
16:41<Rubidium>they just say: the earliest/fastest connection is: XYZ
16:41<@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
16:41<Rubidium>even when a million people go via that route, when you could also take a route 10 minutes longer that's empty
16:41<andythenorth>stepping back a bit - what if the packets are generated even if there is no route?
16:41<+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.
16:42<@planetmaker>inoptimal != non volatile
16:44<+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.
16:44<@Terkhen>hmm
16:44<@Terkhen>ok :)
16:45<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)
16:45<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)
16:46<@Terkhen>hmmm... I wonder if a certain algorithm could work in this case, let me check its name
16:46*andythenorth suspects railroad manifest freight routing is point-to-point
16:46<andythenorth>unit trains not
16:46<+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%...
16:46<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
16:47<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
16:48<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
16:49<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?
16:50<andythenorth>sounds like a 'know the future' problem
16:50<Rubidium>yup
16:51<andythenorth>how come humans know the future, but we can't teach software how we do it?
16:51<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
16:51<andythenorth>in the real world, excepting PAX, vehicles are sent according to the need to route cargo
16:52<andythenorth>in TTD we don't have that connection
16:52<appe>a bird just told me
16:53<appe>Markk:s circumference exceeds jupiter.
16:54*Rubidium puts himself on a siding ;)
16:56<appe>to explore Markks digestive systems, you would need fusion power.
16:58<@Terkhen>michi_cc: I see, I expected a lot more :/
16:59<@Terkhen>so that path is not good either
16:59*Terkhen finds an optimal path for today
16:59<@Terkhen>good night :)
17:00-!-LordAro [~lordaro@host86-156-236-122.range86-156.btcentralplus.com] has quit [Quit: "Time is an illusion. Lunchtime doubly so."]
17:11-!-Neon [~Neon@dslb-094-219-187-110.pools.arcor-ip.net] has quit [Quit: Python is way too complicated... I prefer doing it quickly in C.]
17:15-!-tompaw_ [~tompaw@slave30.tesserakt.eu] has quit [Ping timeout: 480 seconds]
17:16-!-andythenorth [~Andy@cpc15-aztw25-2-0-cust3.aztw.cable.virginmedia.com] has left #openttd []
17:20-!-FLHerne [~francis_h@dsl-217-155-24-22.zen.co.uk] has joined #openttd
17:23<@planetmaker>good night
17:25-!-perk11 [~perk11@188.32.29.238] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
17:38-!-FLHerne [~francis_h@dsl-217-155-24-22.zen.co.uk] has left #openttd []
17:47<Wolf01>'night all
17:47-!-Wolf01 [~wolf01@95.237.235.128] has quit [Quit: Once again the world is quick to bury me.]
17:57<appe>http://fac.dndr.se/poo/new_dump/appe-himlans%20ont_i_h%c3%a4nderna.mp3
18:03-!-pjpe [ade6a119@ircip4.mibbit.com] has quit [Quit: http://www.mibbit.com ajax IRC Client]
18:04-!-hanf [~Klaus@host-89-242-67-211.as13285.net] has quit [Quit: Leaving]
18:07-!-sla_ro|master [~slaco@95.76.27.160] has quit [Ping timeout: 480 seconds]
18:11<Eddi|zuHause><andythenorth> there is no 'the internet' device <-- ever seen the it crowd? ;)
18:11<Eddi|zuHause>damn, he's gone
18:16-!-TWerkhoven[l] [~turbulent@cpc14-linl7-2-0-cust28.sgyl.cable.virginmedia.com] has quit [Remote host closed the connection]
18:21-!-JVassie [~James@2.25.206.0] has quit [Read error: Connection reset by peer]
18:22-!-Biolunar [mahdi@blfd-4d086e2f.pool.mediaWays.net] has quit [Quit: All your IRC are belong to us!]
18:24-!-JVassie [~James@2.27.86.140] has joined #openttd
18:25-!-TWerkhoven [~twerkhove@cpc14-linl7-2-0-cust28.sgyl.cable.virginmedia.com] has quit [Quit: He who can look into the future, has a brighter future to look into]
18:31-!-sla_ro|master [~slaco@95.76.27.160] has joined #openttd
18:32-!-sla_ro|master [~slaco@95.76.27.160] has quit []
18:32-!-sla_ro|master [~slaco@95.76.27.160] has joined #openttd
18:35-!-Strid__ [~Strid@c-4cc7e455.04-372-6c6b701.cust.bredbandsbolaget.se] has quit [Ping timeout: 480 seconds]
18:42-!-Danio [Danio@83.101.65.8] has quit [Remote host closed the connection]
18:47-!-JVassie [~James@2.27.86.140] has quit [Ping timeout: 480 seconds]
18:48-!-welshdragon [~welshdrag@client-86-31-15-90.midd.adsl.virginmedia.com] has quit [Quit: This computer has gone to sleep]
18:49-!-welshdragon [~welshdrag@client-86-31-15-90.midd.adsl.virginmedia.com] has joined #openttd
18:51-!-Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has quit [Remote host closed the connection]
19:00-!-sla_ro|master [~slaco@95.76.27.160] has quit []
19:01-!-Netsplit reticulum.oftc.net <-> kilo.oftc.net quits: heffer, avdg, tty234, eQualizer, Noldo, Elukka, Zeknurn, TrueBrain, snorre_, @peter1138, (+8 more, use /NETSPLIT to show all of them)
19:01-!-heffer_ [~felix@hyperion.fetzig.org] has joined #openttd
19:01-!-Netsplit over, joins: Fuco, Katje
19:01-!-Netsplit over, joins: tty234
19:01-!-Noldo [vheino@jumi.lut.fi] has joined #openttd
19:01-!-Netsplit over, joins: DabuYu
19:01-!-snorre [~snorre@c1A0FBF51.dhcp.bluecom.no] has joined #openttd
19:01-!-Netsplit over, joins: yorick
19:02-!-Netsplit over, joins: TrueBrain
19:02-!-Netsplit over, joins: eQualizer
19:02-!-Netsplit over, joins: KritiK
19:02-!-Netsplit over, joins: avdg
19:02-!-Netsplit over, joins: welterde
19:03-!-Netsplit over, joins: Zeknurn
19:06-!-Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has quit [Quit: Tschüß]
19:06-!-peter1138 [~petern@lachesis.fuzzle.org] has joined #openttd
19:06-!-mode/#openttd [+o peter1138] by ChanServ
19:06-!-Sacro [~ben@150.237.48.99] has joined #openttd
19:14-!-glx_ [glx@2a01:e35:2f59:c7c0:297e:9da0:34ca:b0f6] has joined #openttd
19:14-!-glx is now known as Guest13867
19:14-!-glx_ is now known as glx
19:15-!-Strid__ [~Strid@c-4cc7e455.04-372-6c6b701.cust.bredbandsbolaget.se] has joined #openttd
19:18-!-heyheyy [~heyhey@modemcable043.42-176-173.mc.videotron.ca] has joined #openttd
19:21-!-Guest13867 [glx@2a01:e35:2f59:c7c0:297e:9da0:34ca:b0f6] has quit [Ping timeout: 480 seconds]
19:21-!-welshdragon [~welshdrag@client-86-31-15-90.midd.adsl.virginmedia.com] has quit [Quit: This computer has gone to sleep]
19:25-!-heyhey [heyhey@modemcable043.42-176-173.mc.videotron.ca] has quit [Read error: Operation timed out]
19:25-!-mib_apmba8 [ae589eca@ircip3.mibbit.com] has joined #openttd
19:26-!-mib_apmba8 [ae589eca@ircip3.mibbit.com] has quit []
19:27-!-DOUK [~KEM@ALyon-158-1-72-17.w90-29.abo.wanadoo.fr] has quit [Read error: Connection reset by peer]
19:29-!-Progman [~progman@p57A1BCB4.dip.t-dialin.net] has quit [Remote host closed the connection]
19:32-!-peter1139 [~petern@lachesis.fuzzle.org] has joined #openttd
19:34-!-Sacro_ [~ben@150.237.48.99] has joined #openttd
19:34-!-Netsplit reticulum.oftc.net <-> kilo.oftc.net quits: @peter1138, Sacro
19:46-!-heyheyy [~heyhey@modemcable043.42-176-173.mc.videotron.ca] has quit []
19:46-!-heyhey [heyhey@modemcable043.42-176-173.mc.videotron.ca] has joined #openttd
19:58-!-pjpe [ade6a119@ircip4.mibbit.com] has joined #openttd
20:08-!-valhallasw [~valhallas@vpn91.ext.espci.fr] has quit [Ping timeout: 480 seconds]
20:52-!-pugi [~pugi@dyndsl-095-033-157-068.ewe-ip-backbone.de] has quit [Quit: I reject your reality and substitute my own]
20:57-!-KritiK [~Maxim@95-28-34-176.broadband.corbina.ru] has quit [Quit: Leaving]
21:43-!-Eddi|zuHause2 [~johekr@p54B73FDD.dip.t-dialin.net] has joined #openttd
21:45-!-glx [glx@2a01:e35:2f59:c7c0:297e:9da0:34ca:b0f6] has quit [Quit: bye]
21:48-!-Eddi|zuHause [~johekr@p54B73FDD.dip.t-dialin.net] has quit [Ping timeout: 480 seconds]
22:01-!-heyhey [heyhey@modemcable043.42-176-173.mc.videotron.ca] has quit [Ping timeout: 480 seconds]
22:21-!-Belugas [~belugas@216.191.111.237] has quit [Ping timeout: 480 seconds]
22:29-!-supermop__- [~daniel_er@cpe-67-243-25-39.nyc.res.rr.com] has joined #openttd
---Logclosed Tue Oct 18 00:00:46 2011