Back to Home / #openttd / 2011 / 12 / Prev Day | Next Day
#openttd IRC Logs for 2011-12-31

---Logopened Sat Dec 31 00:00:37 2011
00:05-!-Snail_ [] has quit [Quit: Snail_]
00:56-!-Eddi|zuHause [] has quit [Remote host closed the connection]
00:56-!-Eddi|zuHause [] has joined #openttd
01:06-!-eberon [] has quit [Quit: Leaving.]
02:08-!-Vadtec [~Vadtec@2001:470:1f06:13e0::1337] has quit [Read error: Operation timed out]
02:11-!-Vadtec [~Vadtec@2001:470:1f06:13e0::1337] has joined #openttd
03:13-!-KouDy [~KouDy@] has joined #openttd
03:19-!-pugi [] has joined #openttd
03:30-!-DayDreamer [] has joined #openttd
03:31-!-Neon [] has joined #openttd
03:31-!-Wolf01 [] has joined #openttd
03:34<Mazur>Moar ning.
03:36-!-Scuddles [] has joined #openttd
03:48-!-DDR [~chatzilla@] has quit [Ping timeout: 480 seconds]
03:50-!-Alberth [] has joined #openttd
03:50-!-mode/#openttd [+o Alberth] by ChanServ
03:53<@peter1138>planetmaker, how many people use the original generator? :)
03:57-!-andythenorth [] has joined #openttd
03:57<@Terkhen>good morning
03:58<@peter1138>it is, indeed
04:08<encoded>buenos dias!!
04:08-!-Chris_Booth [] has joined #openttd
04:14<andythenorth>mornington crescent
04:16-!-KritiK [] has joined #openttd
04:30-!-|Jeroen| [] has joined #openttd
04:36-!-TGYoshi [~TGYoshi@] has joined #openttd
04:37-!-DDR [~chatzilla@] has joined #openttd
04:54-!-Mark [] has quit [Ping timeout: 480 seconds]
04:54-!-Guest22060 is now known as Mark
04:54-!-Progman [] has joined #openttd
05:08<CIA-6>OpenTTD: rubidium * r23690 /trunk/src/window.cpp: -Fix: massive typo ;)
05:08<encoded>MASSIVE TYPO!!!
05:09<encoded>why does your cia page not contain a link to a diff or something?
05:10<@Terkhen>check the topic of this IRC channel
05:11<Rubidium>encoded: because whatever the CIA does is unsourced, or in wikipedia speak: "citation needed"
05:11<Rubidium>e.g. the WMD in Iraq ;)
05:11-!-JVassie_ [~James@] has joined #openttd
05:19-!-sla_ro|master [~slaco@] has joined #openttd
05:21<Eddi|zuHause>in german we say "aus für gewöhnlich gut informierten Kreisen" when we want to hide the actual source :p
05:24-!-pjpe [] has quit [Quit: ajax IRC Client]
05:27<lordnokon>my wish for the new year, is to have my own personal programmer to make me newgrf's 100 euro's per custom grf
05:30<andythenorth>add one order of magnitude to the amount and I'll consider it
05:30<andythenorth>still GPL though - so no warranty
05:30<andythenorth>and no customer service
05:31<@Alberth>andythenorth: change-requests == a new custom grf :)
05:31<andythenorth>money will be divided as follows: 30% openttd / coop; 30% charity; 30% lego
05:40<lordnokon>im serious
05:40<@Alberth>what makes you think andy is not?
05:41<@planetmaker>moin andythenorth :-)
05:41<@planetmaker>you forgot 10% rattle :-P
05:42<andythenorth>lordnokon: I am serious
05:42<@Terkhen>and given that andy is one of the few who can both draw and code he's one of your few options if you want to keep things small :)
05:42<andythenorth>you just need 9 other people who also pay €100
05:42<andythenorth>what grf do you need
05:42<Ammler>andythenorth: only 30% lego, then you need a lot money :-)
05:42<Ammler>lego is damn expensive
05:42<@Terkhen>10% more lego? :P
05:42<@planetmaker>Ammler: you get the Imperial shuttle for 150€
05:42<@planetmaker>so... "just" a few 100€ contracts ;-)
05:44<@Alberth>lordnokon: or you need about 10 custom grfs :)
05:46<lordnokon>ill even go 5000 euro, for the programmer, who can resolve the problem of openttd slowing down the more vehicles you have, because if there is something that pee's me off when playing opentdd is that, and thats playing on a system with 16cores, 96gb memory, and running 3 way sli with ssd drive
05:46<andythenorth>lordnokon: trade in your computer
05:46<andythenorth>you'll get a better effect
05:46<TrueBrain>impossible to ever solve that more vehicles make the game go slower
05:46<andythenorth>your computer is completely unsuited to openttd
05:47<TrueBrain>more == slower, always, no matter what, no matter where :P
05:47<@planetmaker>TrueBrain: if you set a limit, make the computation steps big enough (tick length = 2 minutes), then more vehicles will not slow things down by a long shot ;-)
05:47<@Terkhen>and for making OpenTTD multicore you would need more than that... for example I don't have the time for such a huge project
05:47<lordnokon>with so many clever people (programmers) out there i refuse to except that answer
05:47<@planetmaker>I'm not talking about playability, though ;-)
05:48<@Terkhen>programmers that have other things to do too :)
05:48<TrueBrain>planetmaker: on which ever level, it always slows down a tiny bit :)
05:48<TrueBrain>either because of cache-time
05:48<TrueBrain>or whatever :)
05:48-!-DDR [~chatzilla@] has quit [Ping timeout: 480 seconds]
05:48<@Terkhen>and you can't change more == slower, you can just make it a bit better
05:48<andythenorth>lordnokon: you just need a better computer
05:48<@Alberth>lordnokon: multi-core implies losing multi-player
05:48<TrueBrain>planetmaker: but I guess it depends how you define "slowing down" ;)
05:49<@planetmaker>probably ;-)
05:49<TrueBrain>I of course talk about CPU ticks ;)
05:49<TrueBrain>you talk about real-time ;)
05:49<@planetmaker>yeah, I talked game ticks :-)
05:49<TrueBrain>so even if we write such patch, and want to get the 5000 euro, he can always say: no no :P
05:50<lordnokon>i want to be able to play 5000 of each bloody vehicle :p
05:50<@planetmaker>nah, we just need the contract "openttd does not slow down with max vehicle setting".
05:50<@planetmaker>we just make a special edition ;-)
05:50<@Terkhen>lordnokon: OpenTTD only uses a single core, therefore the other 15 do not help at all
05:50<lordnokon>ill demote that money to the main account
05:50<@planetmaker>which is snake-openttd or so
05:50<@Terkhen>you need a computer with a single core that is more powerful
05:51<@Alberth>lordnokon: 5000 of each vehicle, wtf ?
05:51<@Terkhen>you should not enter that money into the account until one of us agrees to code that :P
05:51<lordnokon>getting a single core cpu is hardly possible these days
05:51<@planetmaker>Terkhen: of course he should. We accept donations ;-)
05:51<@Alberth>as long as I don't have to promise a working result :p
05:51<lordnokon>yes why have the option of playing so many vechiles then if you cant?
05:51<@Terkhen>lordnokon: the limit is configurable
05:52<@planetmaker>lordnokon: why would we limit it to a level where it will work?
05:52<@Terkhen>by default it is set to lower, sane values
05:52<@planetmaker>default is 500
05:52<lordnokon>yes i know that, but why have it in the first place he you wont be able to use it to its max
05:52<@planetmaker>and 5000 is for the people with ueber-computers or those who don't mind a lag
05:52<@Terkhen>we don't limit freedom, you can try if you want to :)
05:52<@planetmaker>lordnokon: do you honestly suggest that we should limit it to, say 1000 vehicles?
05:53<andythenorth>so there are about 27 ships in FISH....
05:53<@planetmaker>for no reason other than insufficiently fast hardware?
05:53<andythenorth>@calc 5000*27
05:53<@DorpsGek>andythenorth: 135000
05:54-!-Devroush [] has joined #openttd
05:54<andythenorth>lot of ships :P
05:54<@Terkhen>I had a game once with about 4000 road vehicles, and almost no vehicles of the other types
05:54<@Terkhen>if the limit was set to 1000 it would not have been possible
05:55<CIA-6>OpenTTD: truebrain * r23691 /trunk/src/network/network_gui.cpp: -Fix: signed/unsigned issues, causing asserts for some languages in relation to the serverlist
05:55<andythenorth>lordnokon: what should the limit be? :)
05:57<TrueBrain>btw, when talking about threading we always consider trains. But we can thread RVs, ships and planes, not?
05:57<TrueBrain>trains need to reserve paths, which is much harder
05:57<TrueBrain>but RVs dont really care about other RVs :P
05:58<andythenorth>multi-threaded ships?
05:58<TrueBrain>overtaking is done on a local level
05:58<TrueBrain>RVs rather go through eachother than collide :P
05:59<TrueBrain>and ships are even obviouser about collision :D
05:59<@Alberth>until we get RV-wagons :p
06:00<Rubidium>yeah, start by threading the aircraft pathfinding and see how much that speed "up" the game
06:00<TrueBrain>and planes ... no clue if planes have collision detection :P
06:00<andythenorth>nobody's doing rv-wagons :D
06:00<andythenorth>please don't
06:00<@planetmaker>TrueBrain: not entirely. trains and RV interact at level crossings
06:00<TrueBrain>Rubidium: what would your guestimate be on that?
06:00<TrueBrain>planetmaker: well, RVs do with the level crossing tile
06:00<@planetmaker>ships and planes would work in parallel to those two. Except loading
06:01<TrueBrain>there is no bi-directional interaction between those 2, if I remember correctly :)
06:01<Rubidium>TrueBrain: it gets worse
06:01<TrueBrain>Rubidium: reasoning?
06:01<@planetmaker>loading at stations ;-)
06:01<TrueBrain>well, pathfinding for planes is not really pathfinding :P
06:01<TrueBrain>I guess ships is a better example :)
06:01<Rubidium>TrueBrain: aircraft pathfinding is roughly: determine angle to destination, round to nearest 45 degrees and *go*
06:02<TrueBrain>yeah; you are just being mean :P
06:02<TrueBrain>those things in the water :P
06:03<@planetmaker>could work in parallel except interaction at stations and of course terraforming. But that applies to all
06:03<TrueBrain>the PF is not called at stations I would hope :D
06:04<Rubidium>no, but... if it arrives at the station it does some station stuff
06:04-!-fjb|tab is now known as Guest22282
06:04-!-fjb|tab [] has joined #openttd
06:04<Rubidium>which is basically called from the path follower
06:04-!-Guest22282 [~frank@] has quit [Read error: Connection reset by peer]
06:04<Rubidium>oh darn it... the path follower can't be async
06:05<Rubidium>it moves vehicles, thus updates the 'where is vehicle X' cache
06:05<TrueBrain>the pathfinder itself can still run
06:05<TrueBrain>the cache update has to be done afterwards
06:05<Rubidium>unless it's a fast ship going multiple units a tick. Then it would move, pathfind, move in a single tick
06:06<Rubidium>instead of pathfind, move
06:06<TrueBrain>move for ships is cheap; the pathfinder is mostly the one that can take forever (at least, it can scan all the water tiles on the map I guess, minus one :P)
06:06<TrueBrain>so it would be just a matter of splitting the moving, and th epathfinding
06:07<@Alberth>would it make sense to order ship path-finding by destination?
06:07<TrueBrain>Alberth: what do you mean?
06:08<@Alberth>if you have 2 ships for the same destination, do them together, so you can re-use computed distances
06:08<Rubidium>I think it'd be even faster/more efficient if you were to just insert virtual pathfinding waypoints and always go straight from waypoint to waypoint
06:08<TrueBrain>only works if they are at the same tile I guess?
06:08<Rubidium>together with some meta information at those nodes you should be able to reduce the amount of pathfinding significantly
06:09<TrueBrain>Rubidium: CPU vs memory :D
06:10<Rubidium>but multicore CPUs are most efficient when doing lots of computing on little memory
06:11<TrueBrain>and for RV I guess a similar story holds (in many ways I guess)
06:11<Rubidium>doing pathfinding on the map requires randomly accessing loads and loads of memory
06:11<TrueBrain>but it always comes down to, in the end, trains consume the most CPU on large games :P
06:11<Rubidium>TrueBrain: true-ish, but RVs do have a much more limited amount of infrastructure (graph wise)
06:12<TrueBrain>so they are much faster
06:12<TrueBrain>so threading that would give insignificant benefits I guess
06:12<TrueBrain>RVs mostly move very locally
06:12<TrueBrain>and there it would be easier to just cache the path from station A to station B, and reuse it I guess :P
06:12<Rubidium>likewise ships with well placed buoys can be very efficient
06:13<TrueBrain>very true
06:14<TrueBrain>but, I guess if someone really would like to add threads, that would be a good starting point
06:14<CIA-6>OpenTTD: rubidium * r23692 /trunk/src/network/network_gui.cpp: -Fix: use smallest_x of your children only when you let the children update it
06:14<TrueBrain>doesn't help with trains (at all), but meh :P
06:16<andythenorth>can ships auto-bouy?
06:17-!-[1]Mark [] has joined #openttd
06:17-!-Mark is now known as Guest22283
06:17-!-[1]Mark is now known as Mark
06:18<@Terkhen>what is that?
06:19<TrueBrain>andythenorth: basically what Rubidium suggested ;)
06:23-!-leroot [] has quit []
06:23<andythenorth>can the game place bouys on map gen?
06:24<TrueBrain>if we tell it to, why not? :)
06:26<andythenorth>can we then pathfind once to bouys when setting orders?
06:26<andythenorth>inserting the bouys?
06:26<andythenorth>would also solve the incredibly boring 'set bouys for the way back' bit of orders
06:26<TrueBrain>I dont see why not; the pathfinder can get a very nice bonus for using bouys, and then add them as silent orders
06:27<andythenorth>or explicit
06:27<andythenorth>it's possible the pathfinder could screw up and choose bouys either side of a piece of land
06:27<andythenorth>also - terraforming....
06:28<TrueBrain>it has to revalidate once in a while of course
06:28<@Alberth>and getting loads of bouys close together
06:28<TrueBrain>but short (Straight) legs are easy to validate
06:30-!-sup [] has joined #openttd
06:30-!-valhallasw [] has joined #openttd
06:36-!-Pixa [] has joined #openttd
06:49-!-tokai|mdlx [] has joined #openttd
06:55-!-tokai|noir [] has quit [Ping timeout: 480 seconds]
06:55-!-Elukka [] has joined #openttd
07:21-!-snack2 [] has joined #openttd
07:25-!-Jogio [] has joined #openttd
07:26-!-andythenorth [] has quit [Read error: Connection reset by peer]
07:26-!-andythenorth [] has joined #openttd
07:27<Jogio>hi Truebrain
07:30<Jogio>hmm, I come back another time
07:30-!-Jogio [] has quit []
07:31-!-fjb|tab [] has quit [Ping timeout: 480 seconds]
07:32-!-andythenorth [] has quit [Read error: Connection reset by peer]
07:32-!-andythenorth [] has joined #openttd
07:33-!-andythenorth [] has quit [Read error: Connection reset by peer]
07:33-!-andythenorth [] has joined #openttd
07:35-!-andythenorth is now known as Guest22291
07:35-!-andythenorth [] has joined #openttd
07:35-!-Guest22291 [] has quit [Read error: Connection reset by peer]
07:40-!-Brianetta [] has joined #openttd
07:43<TrueBrain>lol; guess he only has eye for me :D:D
07:48<+michi_cc>Rubidium: You can't even thread the ship ticks without splitting off effect generation.
07:48*Rubidium blames andy ;)
07:49<TrueBrain>oeh, can I join? :D
07:49*Rubidium blames TrueBrain ;)
07:50-!-Pixa [] has quit [Ping timeout: 480 seconds]
07:51<andythenorth>effect generation...
07:51<andythenorth>reminds me of something
07:52<TrueBrain>but you dont know what yet :P
07:52<andythenorth>smoke :)
07:52<TrueBrain>reminds me of something
07:52<andythenorth>there's a FS for it, but my DNS won't resolve :P
07:55<andythenorth>I will pay €5,000 for it
07:55<andythenorth>(subject to terms) :P
07:59-!-nazcafan [] has joined #openttd
07:59<nazcafan>I am trying run the 32bpp mode, to no avail for noz
08:01<nazcafan>I have edited the line to blitter = 32bpp-simple in the openttd.cfg file
08:01<nazcafan>and added a data dir in my docs/openTTD/
08:01<nazcafan>pasted a couple of tar files in there
08:02<nazcafan>I don't see any difference and the line gets changed by the program into blitter = "32bpp-simple"
08:02<nazcafan>(the program adds double quotes)
08:02<nazcafan>did I forget anything?
08:03<@Terkhen>hmm... sounds right at first glance but I have not used 32bpp for a long time
08:04<Rubidium>what version of OpenTTD are you using?
08:04<Rubidium>and where did you get the 32bpp graphic tars from?
08:05<nazcafan>I downloaded the graphic files from:
08:05<nazcafan>and the version seems to be 1.1.4
08:06<Rubidium>nazcafan: you need the original Transport Tycoon Deluxe graphics for those
08:07<Rubidium>and even then quite a few won't work due to utter ancientness
08:07<TrueBrain>we need some method to put them in GRFs .... if only someone had written something like that (/me looks at michi_cc :D) :D:D :)
08:07<nazcafan>Rubidium: can't use the the free version?
08:07<SmatZ>nazcafan: prefer 32bpp-anim or 32bpp-optimized, they are faster, and less buggy (32bpp-simple has problems with transparency, iirc)
08:08<+michi_cc>TrueBrain: Make our resident quaking export come back :p
08:08<+michi_cc>s/export/expert/ :)
08:08*TrueBrain summons frosch
08:08<TrueBrain>did it work?
08:08<Rubidium>TrueBrain: putting them in GRFs doesn't really help here, as you can't easily add stuff to the original graphics
08:09<TrueBrain>Rubidium: in a GRF they can take over 8bpp like ogfx does, not?
08:09<Rubidium>nazcafan: no, those graphics were 'coded' before the free graphics were developed and as such they are not coded to support them as well
08:10<Rubidium>TrueBrain: yes, but then you're as good/bad off writing an action A sprite replacement with seperate 32bpp pngs next to it
08:10<TrueBrain>which goes in a grf, not? :)
08:10<TrueBrain>well, the pngs dont have to
08:10<TrueBrain>but my point is exactly that
08:10<TrueBrain>1 file you can download and then it "just works"
08:10<+michi_cc>With 32bpp in GRF, someone™ could simply fork OpenGFX and slowly start adding 32bpp sprites.
08:10<TrueBrain>no matching another 3rdparty 8bpp set
08:10<nazcafan>ah, in that case, I may just forget about 32bpp for a while; seems too much of a hassle for now
08:11-!-fjb|tab [] has joined #openttd
08:12-!-eberon [] has joined #openttd
08:13<TrueBrain>michi_cc: would there really be a need to fork it? Cant' you just load 2 GRFs, 1 ogfx, the other overwriting them with 32bpp sprites?
08:13<TrueBrain>or would that conflict too much?
08:13<Rubidium>TrueBrain: you can't override sprites of another NewGRF
08:13<+michi_cc>I though about creating a real base set that you can select in the game options.
08:13<TrueBrain>that sucks :(
08:15<+michi_cc>The "surplus" 8bpp sprites wouldn't matter compared with how big a full set of 32bpp extra zoom graphics would be.
08:15<Rubidium>but I think the "best" solution to getting it all working would be the 32bpp graphics in the GRF and OpenGFX making two builds: a small (stable) 8bpp version, and a larger (currently experimental/unfinished) 8bpp + 32bpp version
08:15<TrueBrain>michi_cc: very very true
08:15<@planetmaker>michi_cc: a 'real' base set imho makes most sense
08:16<@planetmaker>as otherwise 8bpp authors get bug reports about stuff broken by bad 32bpp stuff thrown on top (been there, seen that)
08:16<Rubidium>the above just needs a param to NML to not export the 32bpp graphics for the simple set
08:16<andythenorth>frosch had some ideas on [yxyz]
08:16<@planetmaker>thus I agree with Rubidium
08:16<andythenorth>^ usually works
08:17<@planetmaker>I guess we can add this 2nd build relatively easily, Rubidium
08:17<@planetmaker>we could do that even via gcc with #ifdef
08:20<+michi_cc>And a third variant for 8bpp extra zoom? :p
08:20<Rubidium>doing it in NML would be more durable I'd say; especially as you don't need to copy code around for it to be used in other sets
08:20<@planetmaker>of course, that's preferential
08:20<@planetmaker>michi_cc: well... I'll be happy to start including EZ sprites... but that'll be a LOOOONG walk, I fear
08:20-!-vargadanis [] has joined #openttd
08:21<TrueBrain>well, we have seen that the 32bpp -> 8bpp gives very good results
08:21<TrueBrain>at least, so far
08:21<TrueBrain>so maybe you end up with a 32bpp base set, which generates into EZ 32bpp, 8bpp (normal) and 8bpp EZ :P
08:21<TrueBrain>would be a lovely uniform set :D
08:27<TrueBrain>wow, callgrind can analyze cache hits/misses on line-by-line base ....
08:30<+michi_cc>callgrind is awsome, but sloooooooooow :)
08:30<TrueBrain>it simulates it, no wonder :D
08:30<TrueBrain>I used to work on a FPGA, there the hardware does this shit for you
08:30<TrueBrain>now that is fast :D
08:30-!-Snail_ [] has joined #openttd
08:31<+michi_cc>ItsS the only tool I know though that can do profiling on assembly instruction level.
08:31<TrueBrain>I mostly used gprof; so when you talked about this yesterday, and now reading the manual .. I am truly amased what it can track :P
08:31<TrueBrain>of course it 'estimates' how a real computer works
08:32<TrueBrain>but omg :D
08:32<+michi_cc>Yeah, callgrind is for analysing algorithms bascially, not for finding out how to tune your program to the newest Core 785XXY Pro 45K :)
08:32<TrueBrain>I like how it can start recording when you enter a certain function
08:33<TrueBrain>makes me wonder if the graph you showed, if that 50% is really 50% CPU time of the whole application, or only of that tree :P
08:34<+michi_cc>I'm not totally sure, but I think I set it to show percentage of total time. The other numbers are 'times called', where you can see I simulated 500 ticks.
08:35<+michi_cc>If it was relative time the root node (StateGameLoop() in that graph) would have 100%.
08:35<TrueBrain>so it really is insane much :D
08:36<+michi_cc>And children bewlow 0.5% or so absolute time are trimmed.
08:37<+michi_cc>The profiled save game is a bit of a worst case scenario though, because it has *a lot* cargo in transport and at stations.
08:37<TrueBrain>a good scenario is a worst case :)
08:38<TrueBrain>an empty map is the best case, but not really helping ;)
08:39<TrueBrain>still compiling KCacheGrid ... from what I read, many things dont work from CLI .. but I have a XFCE based Linux machine :P
08:39<TrueBrain>takes a bit of time (Gentoo :P)
08:40-!-glx [glx@2a01:e35:2f59:c7c0:391a:2a38:3ae4:284c] has joined #openttd
08:40-!-mode/#openttd [+v glx] by ChanServ
08:42<saua>Hi, on the front page it says that openttd 1.2 beta includes game scripts, are there any documentation on how to write theese?
08:45<Rubidium>saua: basically like AIs, and there is a bit about that on the wiki. Whether something has been written about writing game scripts I don't know
08:45<@planetmaker>get some examples. And read the api specs on
08:45<@planetmaker>examples = via online content download
08:52<CIA-6>OpenTTD: rubidium * r23693 /trunk/src/saveload/afterload.cpp: -Fix [FS#4859]: hardcode the original defaults for loading old savegames if they could totally mess with the game's behaviour
08:55-!-Snail_ [] has quit [Quit: Snail_]
08:57<CIA-6>OpenTTD: rubidium * r23694 /trunk/src/saveload/afterload.cpp: -Fix (rprev): somehow compilers didn't understand what I meant...
09:12-!-nazcafan [] has quit [Quit: ChatZilla 0.9.88 [Firefox 8.0/20111104165243]]
09:15-!-HerzogDeXtEr [~Flex@] has joined #openttd
09:20-!-HerzogDeXtEr1 [~Flex@] has quit [Ping timeout: 480 seconds]
09:45-!-Rezt [] has joined #openttd
09:56<CIA-6>OpenTTD: rubidium * r23695 /trunk/src/ (lang/english.txt screenshot.cpp screenshot.h toolbar_gui.cpp): -Fix/Feature [FS#4916]: make a distinction between fully zoomed in and default zoomed in screenshots
10:02<CIA-6>OpenTTD: rubidium * r23696 /trunk/src/toolbar_gui.cpp: -Fix (r23695): 5 <-> 6... today is not my day
10:02<TrueBrain>Rubidium: I hope next year is your year :D
10:04-!-Rezt [] has quit [Quit: Textual IRC Client:]
10:19-!-Biolunar [] has joined #openttd
10:19-!-DayDreamer [] has left #openttd []
10:22-!-fjb|tab is now known as Guest22304
10:22-!-fjb|tab [] has joined #openttd
10:25-!-Guest22304 [] has quit [Ping timeout: 480 seconds]
10:40<kais58>is there anything relativly simple that needs doing to openttd? I can code to an acceptable standard in java and know my way around code though never messed with a large project such as this?
10:43<@Alberth>there is no list of simple things to do, but you could browse the flyspray bugtracker for open problems
10:43<@Alberth>but the best is usually something that you like to change
10:44<@Alberth>also, it depends on what kind of thing you like
10:45<@Alberth>ie GUI stuff, of deep path finder stuff
10:50<Wolf01>bye, happy new year!
10:51-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
10:51<andythenorth>new year
10:51*andythenorth is grump
10:54<Rubidium>kais58: if you're on OSX then there are many OSX specific bugs to be fixed, otherwise the "easy" tasks are basically limited to documenting stuff
10:54<kais58>afraid not, never used any Mac really
10:55-!-Adambean [] has joined #openttd
10:58<Elukka>kais58 sounds familiar
10:58<kais58>so you are that elukka
10:58<Elukka>yup :D
10:58-!-Progman [] has quit [Remote host closed the connection]
11:00<Elukka>i wanted to do some stuff too so i ended up making pixels
11:01<lordnokon>have a wonderful new years eve people enjoy it
11:04<kais58>yeah, I heard some people complaining about one of them being one pixel too long/short :D
11:07<Elukka>yeah but a compromise was reached :P
11:07<kais58>the changed it by half a pixel? :D
11:08<appe_>how cute.
11:09<Elukka>wanna draw some trains? :P there's a lot to do
11:11<kais58>I like trains
11:12<kais58>but no thanks, I'm at the stage where the profesional programmers I know don't scream in horror at the code I've written anymore, so I'll stick to trying that ;)
11:12<kais58>I was more referring to: vut that works too ;)
11:14<Elukka>hm. i'm sure someone needs something coded
11:15<andythenorth>kais58: either browse flyspray - or existing patches in the development forum
11:15<andythenorth>or play the game, then find something that bugs you :P
11:15<Elukka>can you figure out cargo destinations like yacd without killing the cpu :(
11:16<kais58>elukka, that's easy, get a beefier cpu :D
11:17<Elukka>it's a single threaded game with software rendering
11:17<Elukka>someone was working on an opengl graphics engine
11:17<Elukka>maybe they still are
11:17<Elukka>it'd be awesome to just have an opengl graphics engine with a locked camera that rendered existing sprites as flat textures
11:18<Elukka>the game would look the same but ought to run a lot better
11:18<Elukka>because you have a humongous processing unit in your computer that's devoted to running graphics
11:18<Rubidium>does it support thousands of different textures?
11:19<Elukka>with openttd it's not being used for anything
11:19<Elukka>why wouldn't it?
11:20<Elukka>if your cpu is capable of rendering the game (while doing everything else too) then it follows it would run better if graphics were offloaded to the gpu
11:20<Rubidium>do you know what OpenGL does and what its limitations are?
11:21<Elukka>it's a graphics API, like directx
11:21<Elukka>it isn't an engine
11:22<Elukka>seems extremely unlikely to me it would have some hard limit on textures
11:23<kais58>if it does I imagine it's more than what you need, I know it can certainly render massive images
11:23<kais58>wait openttd is software rendered?
11:24<Rubidium>also... OpenTTD's world isn't like the real world;
11:24<Rubidium>for example, a train is 8 high. Then the catenary (lines) are added on top of that, and then the catenary poles
11:24<Elukka>the gpu is sitting there doing nothing and the cpu doing graphics doesn't do any good for cpu heavy patches like cargo destinations
11:24<Rubidium>over that comes the bridge
11:25<Elukka>why's that an issue?
11:25<Rubidium>interestingly the top of the bridge level is 8 above the previous height level
11:25<Rubidium>similar things happen with tunnels (where it's even worse)
11:28<Rubidium>what's especially interesting are recolouring sprites
11:29-!-JoeyJo0 [] has quit [Ping timeout: 480 seconds]
11:30<Elukka>not sure how that's an issue either
11:31<Rubidium>what I remember with the previous opengl attempts was that they ran into many limitations
11:31<Elukka>someone did make the game run on an opengl engine, though it had rudimentary placeholder graphics and i'm not sure how functional it is
11:31-!-JoeyJo0 [] has joined #openttd
11:36*andythenorth knows not much about OpenGL
11:37<andythenorth>but guesses it's best for rendering into a 3 dimensional space
11:37<andythenorth>not a dimetric projection
11:37<Rubidium>reading back there seem to be issues with sprites not being a power of two in size
11:37<Elukka>i think most modern 2D games use 3D engines because it's that much more efficient
11:37<Elukka>can't you have them be a power of two in size and simply have alpha channel for the empty area
11:38<Rubidium>ofcourse you can
11:38<andythenorth>it would take a lot of work to sort out those sprites
11:38<andythenorth>assume top left locked?
11:38<Rubidium>but you have to do it in the code that 'generates' these sprites
11:39<Elukka>yeah there'd have to be some sorting of the sprites
11:39<Elukka>but nothing as huge as opengfx since you could still use the same art
11:39<Rubidium>oh yes... no partial updates
11:40<Rubidium>so we need to send the whole screen every time, instead of only the bits that changed
11:40<Elukka>yup. our computers have a very powerful gpu in them made for just that, though
11:40<Elukka>most do, anyway
11:40<Elukka>actually i'm guessing even integrated gpus are better at it than the cpu
11:41<Rubidium>Elukka: but OpenTTD needs to 'render' the windows before passing it to the GPU
11:42<Elukka>what do you mean?
11:42<Rubidium>imagine you have the 'toolbar' window opened
11:43<Rubidium>then OpenTTD needs to determine what button to draw where exactly, how big it is and where to draw the lines
11:43<Rubidium>all this information then needs to be passed to the GPU to do the actual drawing
11:44<Rubidium>oh, and let me quote the first lines of the post about someone that made a opengl blitter:
11:44<Rubidium>"Here comes a hardware-assisted OpenGL blitter for OpenTTD!
11:44<Rubidium>Why not hardware-'accelerated' you say? Because it's not necessarily faster"
11:45<Elukka>i'm not sure what hardware-assisted means exactly, but surely it's a lot faster than no hardware rendering at all
11:45<Elukka>as it is currently
11:45<Rubidium>have you completely NOT read the second line?
11:46<TWerkhoven[l]>not if the cpu needs to do more work to get stuff ready for the hw-assisted bit
11:46<Elukka>but openttd isn't a special case, and hardware rendering is more efficient for every other game
11:46<Elukka>yes, rubidium, he says hardware accelerated isn't necessarily faster than hardware assisted, whatever that means
11:47<Elukka>he doesn't say not using hardware at all if faster than using it
11:47-!-Chris_Booth [] has quit [Quit: ChatZilla 0.9.88 [Firefox 10.0/20111221135037]]
11:47<Rubidium>Elukka: he says he calls it "hardware-assisted" because he can't call it "hardware-accelarated" because it does NOT necessarily accelarate it
11:48<Rubidium>if the person that wrote the OpenGL "blitter" says it's not faster, then who are you to claim it is?
11:48<Elukka>can you link to where he's saying it? it doesn't seem to me that he's saying software rendering is faster (which it isn't in any game)
11:49<Elukka>hard to say without context, though
11:49<kais58>he does say it is much faster
11:50<Rubidium>I don't understand you anymore, or English...
11:50<andythenorth>it took years for Photoshop to acquire (minimal) OpenGL acceleration, and that's flakey
11:50<Elukka>photoshop is an image editor, not a game
11:50<Elukka>okay, the way i read the quote is that he said "here's a hardware-assisted blitter, it's not really hardware-accelerated but that wouldn't necessarily be faster than this"
11:51<Elukka>it doesn't seem to me to say "here's a hardware-assisted blitter, i can't call it hardware accelerated because it's actually slower than software rendering'
11:51<andythenorth>how is it different? hmm. z index is different in photoshop
11:51<Rubidium>Elukka: that's not what he meant: "here is an opengl blitter that I cannot call hardware accelerated because it is not necessarily faster"
11:51<Elukka>well, could you link it?
11:52<Elukka>as i said it's hard to get it without context
11:52<Rubidium> <- there is no other context
11:53<Elukka>he isn't saying his blitter is slower than the current software rendering near as i can tell
11:54<Elukka>he says his geforce 7600 gt made the game run at 700 fps with the 32 bit animated palette!
11:54<Elukka>sounds a heck of a lot faster to me
11:54<Rubidium>yes, he isn't saying it is slower, but he is saying it isn't necessarily faster
11:54<Rubidium>Elukka: and what are 700 fps?
11:55<Elukka>he says whether it's faster depends on your computer, and also that it's a fairly experimental implementation
11:55<Elukka>that 700 fps is the gpu finding it absolutely trivial to draw the game's graphics, and they're not bogging down the cpu
11:55<Rubidium>it's easy to 'fake' FPS
11:56<Elukka>are you saying he's faking his results
11:56<Elukka>it does not mean time steps are going hundreds of times faster, because the cpu handles that
11:56<Rubidium>no, I'm saying that FPS is ambiguous
11:56<Elukka>it means, however, that it does not need to handle the graphics
11:56<Elukka>and the gpu finds the graphics extremely easy to draw because it's what it's built for
11:57<Rubidium>but lovely the GPU can draw the frame in 1/700ths of a second, but how much time is spent with sending the data to the GPU?
11:57<Elukka>almost certainly a fraction of the time the cpu would require to draw it
11:57<Elukka>as i said, it works like this in every other game
11:58<Elukka>it's why we have gpus
11:58<Rubidium>doesn't have it...
11:58<Elukka>it's easier to send data to them to have them draw stuff than it is to have the cpu do it
11:59<Elukka>by 'every game' i mean it's a general truth that it's easier to send data to the gpu, and this is why gpus are a huge industry and why everyone has one in their computer
12:00<Rubidium>it's not easier if the game hasn't been developed to use it
12:00<andythenorth>how much stuff actually gets drawn? not a lot
12:00<Elukka>erm. all the sprites in the entire screen
12:00*andythenorth suspects drawing is not the slow part
12:01<Rubidium>as I mentioned earlier... OpenTTD uses tricks w.r.t. perspective that you can't model in the opengl world
12:01<TWerkhoven[l]>openttd runs fine on a singlecore 1.6GHz laptop-cpu, the limiting factor is pathfinding which saturates cpu
12:01<Rubidium>so OpenTTD *still* has to do the sprite sorting and such
12:01<andythenorth>composing the scene is probably significantly slower than drawing it
12:01<Elukka>you make it use the same projection, you use the same sprites, you place them the same way
12:01<Rubidium>but I'll see how many redraws the 32bpp-anim blitter can do in a newly started game
12:01<TWerkhoven[l]>it uses virtually no cpu at all if all there are few to none vehicles
12:02<Rubidium>and the sprite sorting is the expensive bit in OpenTTD (that's O(n^3), where n is the number of visible sprites)
12:02-!-Chrill [] has joined #openttd
12:03<Rubidium>hmm... 32bpp-anim with animation enabled goes up to a mere 5000 FPS with an empty map and fast forward
12:04<Rubidium>paused it does 'only' 900 FPS, but that's because of the 1ms sleeping (which gets disabled with fast forward)
12:04<kais58>is it not possible to offload pathfinding to another thread?
12:05<Rubidium>yes it is
12:05<Rubidium>at the cost of multiplayer
12:05<Elukka>i think that's one of the things that's possible yet difficult
12:05<kais58>why at the cost of multiplayer?
12:05<andythenorth>Rubidium: need a topic item for this :)
12:06<Rubidium>because then the order in which vehicles more differs on the different clients/server
12:06<andythenorth>it's a valid question, but asked twice daily... :P
12:07-!-TomyLobo2 [] has joined #openttd
12:09<Rubidium>oh boy... that version of OpenTTD is "trolly" old ;(
12:12*andythenorth bbl
12:12<andythenorth>new year will consist of baby nursing for me
12:13-!-andythenorth [] has quit [Quit: andythenorth]
12:13-!-TomyLobo [~foo@] has quit [Ping timeout: 480 seconds]
12:13-!-TomyLobo2 is now known as TomyLobo
12:13<Elukka>Eddi|zuHause: calling this finished i think
12:21<Rubidium>with the same method of 'reproduction' in r14405
12:21<kais58>Rub: ?
12:22<Rubidium>sdl + 32bpp-anim -> ~500-700 FPS, sdlgl + opengl -> ~60 FPS
12:22<Rubidium> <- method for determining FPS
12:23<kais58>does it not go over 60 fps at all?
12:23<Rubidium>basic idea: every 1000 ticks = ms print the counter and reset the counter to 0
12:23<Rubidium>kais58: exactly
12:23<kais58>then turn off vsync
12:23<Elukka>yeah, that limits it to your monitor's refresh rate
12:24<Rubidium>more interesting is that with current trunk sdl + 32bpp-anim gives ~900 FPS, and ~5000 FPS in fast forward (yes, SmatZ and others have improved its performance significantly)
12:25*Rubidium has no clue how to turn off vsync
12:25<kais58>depends on how it's enabled, maybe nivdia control panel/catalyst control centre?
12:25-!-Chrill [] has quit []
12:26<Rubidium>I don't have that crappy driver
12:27<kais58>opengl menu in control panel then
12:27-!-encoded [] has quit [Ping timeout: 480 seconds]
12:30<Rubidium>okay... glxgears jumped from ~60 to ~1400 FPS, but for the GL thing in OpenTTD it didn't do much at all
12:32-!-|Jeroen| [] has quit [Remote host closed the connection]
12:32<Rubidium>it's telling me that it that the vblank mode has been changed just like when starting glxgears, so I assume that it worked right
12:32<+glx>grr stupid hl
12:37-!-Pixa [] has joined #openttd
12:39<@Alberth>the x is somewhat rare but random TLAs are quite often used in conversations :)
12:52-!-luv [] has joined #openttd
12:55-!-andythenorth [] has joined #openttd
12:57-!-Chris_Booth [] has joined #openttd
12:57-!-Lakie [~Lakie@] has joined #openttd
12:59-!-LordPixaII [~pixa@] has joined #openttd
13:04-!-LordPixaII [~pixa@] has quit [Read error: Connection reset by peer]
13:05-!-LordPixaII [~pixa@] has joined #openttd
13:05-!-Pixa [] has quit [Ping timeout: 480 seconds]
13:09-!-Pixa [~pixa@] has joined #openttd
13:09-!-LordPixaII [~pixa@] has quit [Read error: Connection reset by peer]
13:11-!-Devroush [] has quit [Ping timeout: 480 seconds]
13:15-!-LordPixaII [~pixa@] has joined #openttd
13:15-!-Pixa [~pixa@] has quit [Read error: Connection reset by peer]
13:19-!-Pixa [~pixa@] has joined #openttd
13:19-!-LordPixaII [~pixa@] has quit [Read error: Connection reset by peer]
13:26<@peter1138>my blitter did partial updates
13:27<@peter1138>but it wasn't too efficient
13:27<@peter1138>problem with ottd is so much game state changes things cosmetically every tick
13:27-!-luv [] has quit [Quit: Saliendo]
13:28<@peter1138>if you used display lists to hold a chunk of landscape, you'd have to update each one every tick
13:28<@peter1138>if you use display lists for each tile, you need x*y of them :S
13:30<@Terkhen>time to go with the family, happy new year everyone :)
13:31<@peter1138>ta ra
13:34-!-Pixa [~pixa@] has quit [Read error: Connection reset by peer]
13:34-!-Pixa [~pixa@] has joined #openttd
13:34-!-Markavian [] has joined #openttd
13:40-!-mkv` [] has quit [Ping timeout: 480 seconds]
13:41<andythenorth>nothing says 'new year' like a release :)
13:43-!-Progman [] has joined #openttd
13:45<CIA-6>OpenTTD: translators * r23697 /trunk/src/lang/ (11 files): (log message trimmed)
13:45<CIA-6>OpenTTD: -Update from WebTranslator v3.0:
13:45<CIA-6>OpenTTD: belarusian - 1 changes by Wowanxm
13:45<CIA-6>OpenTTD: czech - 2 changes by SmatZ
13:45<CIA-6>OpenTTD: dutch - 1 changes by Yexo
13:45<CIA-6>OpenTTD: english_US - 13 changes by Rubidium
13:45<CIA-6>OpenTTD: french - 2 changes by glx
13:50<@Alberth>andy in about an hour we have a fresh nightly release :p
13:51<Rubidium>more like half an hour ;)
13:51<Rubidium>the build + public takes less than 20 minutes
13:52*andythenorth is trading in new year for child maintenance
13:52-!-Chris_Booth [] has quit [Ping timeout: 480 seconds]
13:52<@Alberth>such a fast service nowadays :)
13:52<andythenorth>new year is over-rated anyway
14:11-!-Biolunar [] has quit [Quit: All your IRC are belong to us!]
14:18-!-KritiK [] has quit [Quit: Leaving]
14:25-!-Scuddles [] has quit []
14:26<appe_>there is a setting i hate.
14:26<appe_>the let's-allow-trains-to-break-down-alot option.
14:35*Alberth ♥ breakdowns
14:36<appe_>"hi there, im a happy little BROKEN DOWN coal train. ill be happy to BROKEN DOWN get your coal from destination A to BROKEN DOWN destination B!"
14:37<@Alberth>that's why you have to pick a reliable engine, and have enough depots for servicing
14:38<andythenorth>or just turn off breakdowns :P
14:38<andythenorth>appe_: what is this non-issue you're moaning about ? :)
14:50-!-JVassie [~James@] has joined #openttd
14:56-!-JVassie_ [~James@] has quit [Ping timeout: 480 seconds]
15:02-!-pjpe [] has joined #openttd
15:12-!-valhallasw [] has quit [Ping timeout: 480 seconds]
15:14-!-valhallasw [] has joined #openttd
15:30-!-valhallasw [] has quit [Ping timeout: 480 seconds]
15:31<andythenorth>I should release a new FIRS?
15:43-!-maz0r [] has joined #openttd
15:45-!-fjb|tab [] has quit [Ping timeout: 480 seconds]
15:45<andythenorth>no then? :D
15:49<@Alberth>nobody is here :)
15:49<@Alberth>besides, as father you should be old enough to decide for yourself :)
15:55-!-Markavian` [] has joined #openttd
16:03-!-Markavian [] has quit [Ping timeout: 480 seconds]
16:04<Rubidium>Alberth: yeah, only nobodies are here ;)
16:04<Rubidium>andythenorth: ofcourse you should release, but at 00:00 UTC ;)
16:05<andythenorth>who stays up that late? :o
16:05<Rubidium>what? aren't you forced to do that due to the noise outside?
16:06<andythenorth>not in deepest surburbia
16:06<andythenorth>maybe if I was at home in the city :P
16:35-!-LordPixaII [~pixa@] has joined #openttd
16:38-!-DDR [~chatzilla@] has joined #openttd
16:41-!-Pixa [~pixa@] has quit [Ping timeout: 480 seconds]
17:03-!-JVassie [~James@] has quit [Read error: Connection reset by peer]
17:03-!-JVassie [~James@] has joined #openttd
17:04-!-eberon [] has quit [Quit: Leaving.]
17:23-!-Alberth [] has left #openttd []
17:24<jonty-comp>whee, the yogscast are playing openttd over new years
17:37-!-andythenorth [] has quit [Read error: Connection reset by peer]
17:37-!-andythenorth [] has joined #openttd
17:41<__ln__>zomg, happy birthday €uro!
17:42<Sacro>So my new year's eve sat watching yogscast play openttd
17:44-!-encoded [] has joined #openttd
17:44<Sacro>eesh, using presignlas
17:45<andythenorth>xUSSR set on bananas looks nice
17:55<@peter1138>are they playing it again?
17:56<andythenorth>new FIRS time :)
17:57<andythenorth>done, done, onto the next one...
17:57<andythenorth>can /me complete BANDIT before 2012?
17:57<Rubidium>still 13 hours to go ;)
17:57-!-snack2 [] has quit []
17:58<andythenorth>I'll have to code really fast :P
17:58<andythenorth>mostly templated though
17:59<andythenorth>no FIRS downloads
17:59<andythenorth>what is everyone doing? :o
17:59<andythenorth>are they busy?
17:59-!-DDR [~chatzilla@] has quit [Ping timeout: 480 seconds]
18:00<HerzogDeXtEr>Happy New Year
18:00<Rubidium>lies andythenorth! ;)
18:00<andythenorth>well that's better
18:00<andythenorth>my work here is done then :)
18:02<@peter1138>ah, can't talk on there
18:02<@peter1138>gotta purchase a subscription
18:04<Mazur>Happy nwe beer, everyone!
18:12<Elukka>well i'm making pixels
18:12<Elukka>andy, what's changed in firs?
18:13<andythenorth>just tweaked a few buildings
18:13<andythenorth>nothing big :)
18:23<Rubidium>true, the differences between 0.7.0 and the previous version are minimal at best
18:24-!-pjpe [] has quit [Quit: ajax IRC Client]
18:24<Rubidium>only a bit of readme tweaking and changing the minimum (compatible) versions ;)
18:30-!-sup [] has quit []
18:37-!-Neon [] has quit [Quit: Python is way too complicated... I prefer doing it quickly in C.]
18:38-!-sup [] has joined #openttd
18:43-!-Zeknurn [] has joined #openttd
18:46<andythenorth>bye :)
18:46-!-andythenorth [] has quit [Quit: andythenorth]
18:51-!-Lakie [~Lakie@] has quit [Quit: Happy New Year.]
18:53-!-supermop_ [] has joined #openttd
18:54-!-DDR [~chatzilla@] has joined #openttd
19:04-!-Maarten_ [] has joined #openttd
19:04-!-Strid_ [] has joined #openttd
19:05<CIA-6>OpenTTD: rubidium * r23698 /trunk/src/ (55 files in 3 dirs): -Fix (r21685): small, apparantly yearly reoccuring, typo
19:07<encoded>ah, good one Rubidium
19:07-!-LordPixaII [~pixa@] has quit [Ping timeout: 480 seconds]
19:07-!-Adambean [] has quit [Quit: Gone fishing]
19:08-!-Strid [] has quit [Ping timeout: 480 seconds]
19:08-!-Maarten [] has quit [Ping timeout: 480 seconds]
19:20<__ln__>end of discussion
19:22-!-TGYoshi [~TGYoshi@] has quit [Quit: Popidopidopido]
19:22-!-Pixa [~pixa@] has joined #openttd
19:34-!-Progman [] has quit [Remote host closed the connection]
20:02-!-sla_ro|master [~slaco@] has quit [Quit: Sla Mutant Co-Op for Renegade - coming back soon]
20:08-!-pugi [] has quit [Ping timeout: 480 seconds]
20:11-!-pugi [] has joined #openttd
20:26-!-pugi [] has quit []
20:32-!-JVassie [~James@] has quit [Ping timeout: 480 seconds]
20:37-!-valhallasw [] has joined #openttd
20:41-!-TomyLobo [] has quit [Quit: Standby mode...]
20:52-!-valhallasw [] has quit [Ping timeout: 480 seconds]
21:18-!-FLHerne [] has joined #openttd
21:30-!-LordPixaII [~pixa@] has joined #openttd
21:30-!-Pixa [~pixa@] has quit [Read error: Connection reset by peer]
21:35-!-DDR [~chatzilla@] has quit [Ping timeout: 480 seconds]
21:36-!-Chris_Booth[ph] [] has joined #openttd
21:36<Eddi|zuHause>so... party's over
21:37<FLHerne>It is?
21:39<Eddi|zuHause>can't the year be extracted from an svn keyword?
21:41<+glx>Eddi|zuHause: a free commit is good :)
21:45-!-Brianetta [] has quit [Remote host closed the connection]
21:45<Hawson>Eddi|zuHause: the commit time is in the ID tag
21:48-!-Chris_Booth[ph] [] has quit [Quit: Colloquy for iPhone -]
21:51-!-Pixa [~pixa@] has joined #openttd
21:51-!-LordPixaII [~pixa@] has quit [Read error: Connection reset by peer]
21:52-!-KouDy [~KouDy@] has quit [Quit: Leaving.]
21:55-!-Pixa [~pixa@] has quit [Read error: Connection reset by peer]
21:55-!-Pixa [~pixa@] has joined #openttd
21:58<Eddi|zuHause>Hawson: that wasm't really the question
21:59-!-LordPixaII [~pixa@] has joined #openttd
21:59-!-Pixa [~pixa@] has quit [Read error: Connection reset by peer]
22:00-!-LordPixaII [~pixa@] has quit [Read error: Connection reset by peer]
22:01-!-Pixa [~pixa@] has joined #openttd
22:05-!-LordPixaII [~pixa@] has joined #openttd
22:05-!-Pixa [~pixa@] has quit [Read error: Connection reset by peer]
22:11-!-LordPixaII [~pixa@] has quit [Read error: Connection reset by peer]
22:11-!-Pixa [~pixa@] has joined #openttd
22:15-!-LordPixaII [~pixa@] has joined #openttd
22:15-!-Pixa [~pixa@] has quit [Read error: Connection reset by peer]
22:21-!-Pixa [~pixa@] has joined #openttd
22:21-!-LordPixaII [~pixa@] has quit [Read error: Connection reset by peer]
22:24-!-LordPixaII [~pixa@] has joined #openttd
22:24-!-Pixa [~pixa@] has quit [Read error: Connection reset by peer]
22:30-!-fjb|tab [] has joined #openttd
22:30-!-LordPixaII [~pixa@] has quit [Read error: Connection reset by peer]
22:31-!-Pixa [~pixa@] has joined #openttd
22:34-!-FLHerne [] has quit [Quit: Leaving]
22:34-!-Pixa [~pixa@] has quit [Read error: Connection reset by peer]
22:35-!-Pixa [~pixa@] has joined #openttd
22:41-!-LordPixaII [~pixa@] has joined #openttd
22:41-!-Pixa [~pixa@] has quit [Read error: Connection reset by peer]
22:43-!-Chris_Booth [] has joined #openttd
22:43-!-LordPixaII [~pixa@] has quit [Read error: Connection reset by peer]
22:44-!-leroot [] has joined #openttd
22:44-!-Pixa [~pixa@] has joined #openttd
22:47-!-sup [] has quit [Ping timeout: 480 seconds]
22:50-!-Chris_Booth [] has quit [Quit: ChatZilla 0.9.88 [Firefox 10.0/20111228055358]]
22:50-!-Pixa [~pixa@] has quit [Read error: Connection reset by peer]
22:57-!-Pixa [~pixa@] has joined #openttd
23:01-!-LordPixaII [~pixa@] has joined #openttd
23:01-!-Pixa [~pixa@] has quit [Read error: Connection reset by peer]
23:06-!-LordPixaII [~pixa@] has quit [Read error: Connection reset by peer]
23:06-!-Pixa [~pixa@] has joined #openttd
23:10-!-glx [glx@2a01:e35:2f59:c7c0:391a:2a38:3ae4:284c] has quit [Quit: bye]
23:10-!-Pixa [~pixa@] has quit [Read error: Connection reset by peer]
23:16-!-Pixa [~pixa@] has joined #openttd
23:21-!-Pixa [~pixa@] has quit [Read error: Connection reset by peer]
23:22-!-Pixa [~pixa@] has joined #openttd
23:26-!-LordPixaII [~pixa@] has joined #openttd
23:26-!-Pixa [~pixa@] has quit [Read error: Connection reset by peer]
23:31-!-LordPixaII [~pixa@] has quit [Read error: Connection reset by peer]
23:34-!-Elukka [] has quit []
23:36-!-Pixa [~pixa@] has joined #openttd
23:41-!-Pixa [~pixa@] has quit [Read error: Connection reset by peer]
23:42-!-Pixa [~pixa@] has joined #openttd
23:46-!-LordPixaII [~pixa@] has joined #openttd
23:46-!-Pixa [~pixa@] has quit [Read error: Connection reset by peer]
23:51-!-LordPixaII [~pixa@] has quit [Read error: Connection reset by peer]
23:56-!-Pixa [~pixa@] has joined #openttd
---Logclosed Sun Jan 01 00:00:37 2012