Times are UTC Toggle Colours
00:01:09 *** Cybert1nus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has joined #openttd 00:01:26 *** Kurimus [~stabbity@dsl-tkubrasgw3-fe93dd00-34.dhcp.inet.fi] has quit [] 00:01:45 <Wolf01> 'night all 00:01:54 *** Wolf01 [~wolf01@host48-239-dynamic.16-79-r.retail.telecomitalia.it] has quit [Quit: Once again the world is quick to bury me.] 00:07:00 *** Cybert1nus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has quit [Remote host closed the connection] 00:22:30 *** Progman [~progman@p57A1D523.dip.t-dialin.net] has joined #openttd 00:24:05 *** Devroush [~dennis@178-119-153-135.access.telenet.be] has quit [] 00:42:46 *** Progman [~progman@p57A1D523.dip.t-dialin.net] has quit [Remote host closed the connection] 00:50:48 *** Neon [~Neon@dslb-178-004-177-046.pools.arcor-ip.net] has quit [Quit: Python is way too complicated... I prefer doing it quickly in C.] 01:10:39 *** pugi [~pugi@dyndsl-091-096-056-096.ewe-ip-backbone.de] has quit [Quit: I reject your reality and substitute my own] 01:20:26 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has quit [Read error: No route to host] 01:24:34 *** KritiK [~Maxim@95-28-81-182.broadband.corbina.ru] has quit [Quit: Leaving] 01:29:16 *** Pulec [~pulec@static-cl093181068250.unet.cz] has quit [] 01:33:47 *** JVassie [~James@2.25.210.119] has quit [Ping timeout: 480 seconds] 01:40:23 *** mahmoud [~KEM@ALyon-158-1-190-31.w109-212.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 01:43:49 *** hanf [~Klaus@host-78-146-187-199.as13285.net] has quit [Read error: Connection reset by peer] 02:01:41 *** Eddi|zuHause [~johekr@p54B736CD.dip.t-dialin.net] has quit [Remote host closed the connection] 02:01:58 *** Eddi|zuHause [~johekr@p54B736CD.dip.t-dialin.net] has joined #openttd 02:16:09 *** frosch123 [~frosch@frnk-590f5003.pool.mediaWays.net] has quit [Remote host closed the connection] 02:27:29 *** Biolunar_ [~mahdi@blfd-4db1a23b.pool.mediaWays.net] has joined #openttd 02:34:25 *** Biolunar [mahdi@blfd-5d8205df.pool.mediaWays.net] has quit [Read error: Operation timed out] 02:35:24 *** MNIM [~mBuntu@ip5452ffad.adsl-surfen.hetnet.nl] has joined #openttd 02:43:58 *** notsure [~notsure@31-151-104-170.dynamic.upc.nl] has quit [] 03:00:59 *** DDR [~chatzilla@142.179.78.88] has quit [Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20110928224508]] 03:24:27 *** rhaeder1 [~quix0r@dslb-094-221-159-233.pools.arcor-ip.net] has joined #openttd 03:24:39 <Eddi|zuHause> 7 Seek_Error_Rate 0x000b 200 001 051 Pre-fail Always In_the_past 0 03:24:49 <Eddi|zuHause> suddenly it's like nothing ever happened 03:28:58 *** rhaeder [~quix0r@dslb-094-221-205-069.pools.arcor-ip.net] has quit [Ping timeout: 480 seconds] 03:31:20 <Eddi|zuHause> Nov 19 21:44:39 johannes-i smartd[2774]: Device: /dev/sda [SAT], SMART Prefailure Attribute: 7 Seek_Error_Rate changed from 1 to 200 03:32:58 <__ln__> if you start the long smart test, does it complete? 03:32:59 <Eddi|zuHause> Nov 18 14:13:15 johannes-i smartd[2766]: Device: /dev/sda [SAT], SMART Prefailure Attribute: 7 Seek_Error_Rate changed from 200 to 100 03:33:00 <Eddi|zuHause> Nov 19 02:14:38 johannes-i smartd[2756]: Device: /dev/sda [SAT], SMART Prefailure Attribute: 7 Seek_Error_Rate changed from 100 to 1 03:33:36 <Eddi|zuHause> i think the last one didn't... i'll try another one... takes an hour 03:35:26 <Eddi|zuHause> # 1 Extended offline Completed: unknown failure 90% 1055 4294705486 03:35:40 <Eddi|zuHause> not entirely sure what that means 03:37:49 <__ln__> me neither, but doesn't sound good 03:40:15 <Eddi|zuHause> Nov 20 04:41:10 johannes-i kernel: [95391.463330] TCP: Possible SYN flooding on port *****. Sending cookies. <-- not sure what that means either 03:55:44 *** glx [glx@2a01:e35:2f59:c7c0:d02:26f5:e4dc:5a87] has quit [Quit: bye] 05:54:21 *** Eddi|zuHause [~johekr@p54B736CD.dip.t-dialin.net] has quit [Remote host closed the connection] 05:54:41 *** Eddi|zuHause [~johekr@p54B75156.dip.t-dialin.net] has joined #openttd 06:20:26 *** Adambean [~AdamR@82.hosts.reece-eu.net] has quit [Quit: Gone fishing] 06:52:15 *** andythenorth [~Andy@cpc1-aztw25-2-0-cust298.aztw.cable.virginmedia.com] has joined #openttd 07:12:22 *** andythenorth [~Andy@cpc1-aztw25-2-0-cust298.aztw.cable.virginmedia.com] has quit [Quit: andythenorth] 07:32:08 *** andythenorth [~Andy@cpc1-aztw25-2-0-cust298.aztw.cable.virginmedia.com] has joined #openttd 07:35:24 *** DayDreamer [~DayDreame@ip-86-49-59-25.net.upcbroadband.cz] has joined #openttd 07:39:06 *** sla_ro|master [~slaco@95.76.27.160] has joined #openttd 07:54:07 *** SmatZ- is now known as SmatZ 07:54:43 *** |Terkhen| is now known as Terkhen 07:54:46 <Terkhen> good morning 08:01:46 <Rubidium> moin Terkhen 08:06:33 <CIA-6> OpenTTD: rubidium * r23271 /trunk/src/ (fontcache.cpp fontcache.h openttd.cpp strings.cpp): -Codechange: don't repeatedly initialise and free the freetype library 08:12:41 *** Kurimus [~stabbity@dsl-tkubrasgw3-fe93dd00-34.dhcp.inet.fi] has joined #openttd 08:13:10 *** Pulec [~pulec@static-cl093181068250.unet.cz] has joined #openttd 08:27:56 *** Devroush [~dennis@178-119-153-135.access.telenet.be] has joined #openttd 08:28:58 <andythenorth> hola 08:50:58 <andythenorth> hmm 08:51:08 * andythenorth needs rack trams 08:51:14 <andythenorth> RoadTypes :P 08:51:54 <Rubidium> http://rbijker.net/openttd/mono/screenshot.png <- OpenTTD in mono ;) 08:54:11 <planetmaker> moin 08:54:45 <Rubidium> (mini)moni ;) 08:56:04 <Terkhen> nice :) 08:56:04 <andythenorth> +1 08:56:06 <Terkhen> hi planetmaker 08:56:24 <planetmaker> looks very nice 09:05:54 <peter1138> andythenorth, maybe you should delve into the code some time ;) 09:12:32 *** snack2 [~nn@dsl-prvbrasgw1-fe05dc00-37.dhcp.inet.fi] has joined #openttd 09:22:12 *** JVassie [~James@2.25.210.119] has joined #openttd 09:22:20 *** Progman [~progman@p57A1D87A.dip.t-dialin.net] has joined #openttd 09:24:09 *** Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has joined #openttd 09:24:13 *** mode/#openttd [+o Alberth] by ChanServ 09:28:47 *** Neon [~Neon@dslb-094-219-003-140.pools.arcor-ip.net] has joined #openttd 09:31:14 <andythenorth> peter1138: I started once... 09:31:54 <andythenorth> http://dev.openttdcoop.org/projects/roadtypes/issues 09:32:00 <andythenorth> got quite stuck quite soon 09:32:10 * andythenorth is not short of other distractions :P 09:49:05 *** pjpe [ade6a119@ircip3.mibbit.com] has quit [Quit: http://www.mibbit.com ajax IRC Client] 09:50:27 *** Arafangion [~Arafangio@220-244-108-23.static.tpgi.com.au] has quit [Read error: Connection reset by peer] 09:56:50 *** Arafangion [~Arafangio@220-244-108-23.static.tpgi.com.au] has joined #openttd 10:04:15 *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has joined #openttd 10:06:03 *** mahmoud [~KEM@ALyon-158-1-190-31.w109-212.abo.wanadoo.fr] has joined #openttd 10:32:36 *** snack2 [~nn@dsl-prvbrasgw1-fe05dc00-37.dhcp.inet.fi] has quit [] 10:33:18 *** DDR [~chatzilla@142.179.78.88] has joined #openttd 10:42:53 *** DDR [~chatzilla@142.179.78.88] has quit [Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20110928224508]] 10:44:40 *** TGYoshi [~TGYoshi@86.81.146.146] has joined #openttd 11:09:43 *** MNIM [~mBuntu@ip5452ffad.adsl-surfen.hetnet.nl] has quit [Remote host closed the connection] 11:13:28 <Eddi|zuHause> # 1 Extended offline Completed without error 00% 1082 - 11:13:33 <Eddi|zuHause> weird... 11:13:56 *** hanf [~Klaus@host-78-146-176-160.as13285.net] has joined #openttd 11:19:54 * andythenorth wonders if articulated vehicles can build articulated vehicles... 11:20:39 *** Wolf01 [~wolf01@host48-239-dynamic.16-79-r.retail.telecomitalia.it] has joined #openttd 11:21:20 <Wolf01> hello 11:25:54 <peter1138> andythenorth, no, obviously :) 11:26:06 <andythenorth> empiricism agrees with you :P 11:26:16 * andythenorth will have to write some actual code 11:32:46 *** APTX_ [APTX@89-78-217-144.dynamic.chello.pl] has quit [Ping timeout: 480 seconds] 11:48:31 <CIA-6> OpenTTD: rubidium * r23272 /trunk/src/ (gfx.cpp gfx_func.h): -Codechange: pass the initial font size to DrawString and friends 11:50:29 <CIA-6> OpenTTD: rubidium * r23273 /trunk/src/ (5 files): -Codechange: allow passing a MissingGlyphSearcher to CheckForMissingGlyphs (default to the language pack strings) 11:51:16 *** Elukka [Elukka@78-27-85-217.bb.dnainternet.fi] has quit [] 11:55:10 <CIA-6> OpenTTD: rubidium * r23274 /trunk/src/ (5 files in 2 dirs): -Add: internal support for a monospaced sprite font 11:57:54 <CIA-6> OpenTTD: rubidium * r23275 /trunk/src/ (fontcache.cpp fontcache.h openttd.cpp strings.cpp): -Codechange: allow loading of the monospace (freetype) font at another moment than the other fonts 11:58:32 <andythenorth> if a template has more #ifdef than nfo, is it a template any more? 11:59:06 <michi_cc> Eddi|zuHause: How much of CETS do I "break" with http://www.icosahedron.de/openttd/patches/something_like_fs3569.patch ? 11:59:59 <Eddi|zuHause> hm... let me check 12:00:03 <CIA-6> OpenTTD: rubidium * r23276 /trunk/src/ (strings.cpp strings_func.h): -Codechange: add the answer for the question whether we're looking for monospace fonts in the searcher 12:00:25 <CIA-6> OpenTTD: rubidium * r23277 /trunk/src/fontcache.cpp: -Codechange: fallback font support for fontcache 12:00:47 <Eddi|zuHause> michi_cc: if it "breaks" too much, could it be grfv8 only? 12:01:43 <michi_cc> No, because it isn't at all about NewGRFs but about OpenTTD internals (that are unfortunately exposed at some places). 12:02:28 <CIA-6> OpenTTD: rubidium * r23278 /trunk/ (8 files in 2 dirs): -Add: monospaced sprite font with the same characters as the normal font 12:09:00 <CIA-6> OpenTTD: rubidium * r23279 /trunk/src/fontcache.cpp: -Codechange: try to prevent slanted and skinny fonts with fontconfig. This should generally make the fallback choice better legible 12:11:50 <andythenorth> ow 12:12:05 * andythenorth tries to insert one extra vehicle into trams 12:12:10 <andythenorth> (articulated engine) 12:12:31 <andythenorth> this is stunningly complicated without splitting off a new template :P 12:21:35 <Eddi|zuHause> michi_cc: i think the movement of shorter wagons is better, but the longer wagons need some reviewing 12:23:23 <Eddi|zuHause> michi_cc: and i think the glitches near slopes got bigger 12:25:05 <andythenorth> Eddi|zuHause: I need to convert the tram wagons to count from rear of consist when handling change of properties etc :O 12:25:28 <Eddi|zuHause> andythenorth: what for? 12:25:51 <andythenorth> I think it's the easiest way to handle having 1 or 2 locomotives 12:26:00 <andythenorth> which I'm currently trying to implement 12:26:12 <andythenorth> or I could split templates, but that's bad for maintainability :P 12:28:22 <michi_cc> Eddi|zuHause: Yes, the result of var 62 will be slightly different with the patch. But as 62 is recent, CETS is the only GRF actively using it I'd guess, so not that much of a problem. 12:28:42 <michi_cc> It does fix that trains with an indicated length of 1.0 use more than one tile in stations for example. 12:28:50 <Eddi|zuHause> michi_cc: i think the russians may be using it 12:29:14 <CIA-6> OpenTTD: rubidium * r23280 /branches/1.1/ (7 files in 5 dirs): [1.1] -Prepare: 1.1.4-RC1 12:29:14 <andythenorth> in russia, var uses you 12:29:22 <planetmaker> een then, their code isn't old either, Eddi|zuHause 12:29:27 <michi_cc> 62, not 45? 12:29:59 <Eddi|zuHause> michi_cc: judgin from recent discussion in nml thread, i think so. 12:30:05 <michi_cc> var 45 isn't affected by that change, it's only 62, which is only ~6 week old. 12:30:49 <Eddi|zuHause> michi_cc: but what i mean is that the sprite sorter now more often does The Wrong Thing (tm) near slopes 12:31:02 <michi_cc> And if they really use it it's an argument to commit that stuff as fast as possible before anybody else starts using it. 12:31:03 <Eddi|zuHause> at least it appears to me like that 12:31:24 <michi_cc> In general or for CETS vehicles? 12:32:20 <Eddi|zuHause> i don't have any general vehicles 12:33:58 <CIA-6> OpenTTD: rubidium * r23281 /tags/1.1.4-RC1/ (. src/os/windows/ottdres.rc.in src/rev.cpp.in): -Release: 1.1.4-RC1 12:35:26 <michi_cc> That's probably because the bounding boxes now have the proper length and not 7/8 for every vehicle. So if CETS somehow relied on the longer bounding box to resolve the graphics better this would be different now (Side note: this only applies to the diagonal directions, the bounding box for the other directions is and was always 3x3 regardless of length or orientation). 12:36:30 <Eddi|zuHause> yeah... i'll need to think about that... 12:38:01 <andythenorth> hmm 12:38:15 * andythenorth ignores idea of articulated tram locomotive :P 12:38:20 <andythenorth> solved that differently 12:42:52 *** pugi [~pugi@dyndsl-091-096-056-096.ewe-ip-backbone.de] has joined #openttd 12:45:37 *** Zuu_ [~Zuu@2.71.33.247.mobile.tre.se] has joined #openttd 12:46:13 *** frosch123 [~frosch@frnk-590ff025.pool.mediaWays.net] has joined #openttd 12:47:50 *** hanf [~Klaus@host-78-146-176-160.as13285.net] has quit [Read error: Connection reset by peer] 12:50:20 *** DayDreamer [~DayDreame@ip-86-49-59-25.net.upcbroadband.cz] has quit [Quit: Leaving.] 12:57:59 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has joined #openttd 13:13:25 *** KritiK [~Maxim@95-25-61-199.broadband.corbina.ru] has joined #openttd 13:27:54 <Xaroth> frosch123: up again with heq 13:28:04 <Xaroth> i'll leave it in your good hands 13:28:09 <Xaroth> tb has rcon power if needed. 13:28:14 <planetmaker> fish and av8? 13:28:20 <Xaroth> not atm 13:28:25 <planetmaker> :S 13:28:26 <Xaroth> gotta run, already late 13:28:31 <frosch123> there is still only dutch trams set :s 13:29:17 * planetmaker starts to create a map 13:29:25 <frosch123> :) 13:31:10 <Xaroth> i'll fix it when I'm back. 13:31:55 <Rubidium> frosch123: just download some NewGRFs using rcon 13:32:38 * frosch123 is having fun reading the nogo topic :) 13:32:54 <frosch123> some did some awesome research :) 13:43:06 *** TomyLobo2 [~foo@p54946C45.dip.t-dialin.net] has joined #openttd 13:45:00 <planetmaker> hm... do I need the script during generation? Or how does that work? 13:45:33 <Yexo> you need it when playing the game 13:45:42 <Yexo> afaik the script can't save any state in the savegame yet 13:45:51 <frosch123> does nogo just always use the script, or does it already store it in the save? 13:45:59 <frosch123> (like ais) 13:46:15 <Yexo> I haven't seen code yet to store it in the savegame 13:48:56 *** TomyLobo [~foo@p54946BB5.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 13:48:56 *** TomyLobo2 is now known as TomyLobo 13:50:49 *** HerzogDeXtEr1 [~Flex@88.130.168.113] has joined #openttd 13:52:20 *** APTX [APTX@89-78-217-144.dynamic.chello.pl] has joined #openttd 13:56:16 *** HerzogDeXtEr [~Flex@i59F6B2C1.versanet.de] has quit [Ping timeout: 480 seconds] 13:56:49 <planetmaker> http://devs.openttd.org/~planetmaker/patches/nogo.sav <-- Xaroth 14:01:02 <planetmaker> slight update... missed the station NewGRFs 14:06:16 <frosch123> Xaroth is gone 14:06:22 <frosch123> we have to start our own server :p 14:07:34 <planetmaker> I could fire-up the dev server 14:13:03 * andythenorth should hang out and watch :) 14:20:52 *** Biolunar_ [~mahdi@blfd-4db1a23b.pool.mediaWays.net] has quit [Quit: All your IRC are belong to us!] 14:21:16 *** Zuu_ [~Zuu@2.71.33.247.mobile.tre.se] has quit [Ping timeout: 480 seconds] 14:21:39 *** snack2 [~nn@dsl-prvbrasgw1-fe05dc00-37.dhcp.inet.fi] has joined #openttd 14:31:18 *** glx [glx@2a01:e35:2f59:c7c0:158d:8bda:662a:17f0] has joined #openttd 14:31:21 *** mode/#openttd [+v glx] by ChanServ 14:37:31 <CIA-6> OpenTTD: frosch * r23282 /trunk/src/ (group_cmd.cpp group_gui.cpp): -Fix [FS#4844] (r23212): CmdRemoveAllVehiclesGroup() was not passed the vehicle type in all cases, but the type is actually not needed. 14:45:14 *** pugi [~pugi@dyndsl-091-096-056-096.ewe-ip-backbone.de] has quit [Ping timeout: 480 seconds] 14:45:40 *** pugi [~pugi@dyndsl-091-096-048-168.ewe-ip-backbone.de] has joined #openttd 14:48:22 <andythenorth> how do I provide smoke for a locomotive with two chimneys? 14:49:20 <Xaroth> planetmaker: if you wnt i can give you access to the machine 14:49:47 *** Adambean [~AdamR@82.hosts.reece-eu.net] has joined #openttd 14:49:47 <Xaroth> so you can change whatever is needed 14:51:31 <Eddi|zuHause> andythenorth: by implementing NewSmoke :p 14:51:41 <andythenorth> what's the spec? 14:51:52 <andythenorth> :P 14:51:54 <andythenorth> http://bugs.openttd.org/task/4263 15:05:02 *** Mazur [~mazur@5ED2BEAE.cm-7-3c.dynamic.ziggo.nl] has quit [Remote host closed the connection] 15:06:31 *** Mazur [~mazur@5ED2BEAE.cm-7-3c.dynamic.ziggo.nl] has joined #openttd 15:07:58 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has quit [Quit: TschÃŒÃ] 15:10:00 <appe_> ladida 15:15:55 <CIA-6> OpenTTD: rubidium * r23283 /trunk/src/newgrf.cpp: -Fix: [NewGRF] Prevent against writing data for unknown fonts 15:19:25 *** Eddi|zuHause [~johekr@p54B75156.dip.t-dialin.net] has quit [Read error: No route to host] 15:19:30 *** Eddi|zuHause [~johekr@p54B75156.dip.t-dialin.net] has joined #openttd 15:23:51 *** ptr [~peter@c213-89-142-179.bredband.comhem.se] has joined #openttd 15:27:45 *** ptr [~peter@c213-89-142-179.bredband.comhem.se] has quit [] 15:29:35 *** Maarten1 [~Maarten@c29061.upc-c.chello.nl] has joined #openttd 15:37:41 <CIA-6> OpenTTD: rubidium * r23284 /trunk/src/water_cmd.cpp: -Fix [FS#4845]: Pathfinders go haywire when you build a lock over a ship going perpendicular to the axis of the new lock 15:39:17 *** KritiK_ [~Maxim@95-25-61-199.broadband.corbina.ru] has joined #openttd 15:44:15 *** KritiK [~Maxim@95-25-61-199.broadband.corbina.ru] has quit [Ping timeout: 480 seconds] 15:44:28 *** KritiK_ is now known as KritiK 15:58:43 *** perk11 [~perk11@188.32.29.238] has joined #openttd 16:01:57 *** snack2 [~nn@dsl-prvbrasgw1-fe05dc00-37.dhcp.inet.fi] has quit [] 16:10:06 *** Pulec [~pulec@static-cl093181068250.unet.cz] has quit [] 16:27:32 <TrueBrain> there, published a new version of NoGo. It now detects scripts, instead of trying to open one :P It still has to be called 'test', but that are minor details ;) 16:27:36 <TrueBrain> Xaroth / planetmaker ^^ :P 16:27:57 <planetmaker> oi :-) 16:31:37 *** perk11 [~perk11@188.32.29.238] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] 16:34:30 *** Pixa [~pixa@85.210.74.36] has joined #openttd 16:35:16 *** TWerkhoven[l] [~turbulent@cpc12-linl7-2-0-cust144.sgyl.cable.virginmedia.com] has joined #openttd 16:36:05 <frosch123> so, can we get a server with the game pm prepared? 16:36:17 <TrueBrain> Xaroth is at the movies 16:36:23 <TrueBrain> you will have to wait till he is back I am afraid :) 16:36:40 <frosch123> then i continue trolling :) 16:36:43 <planetmaker> my autopilot fails for me. I could of course just start the server without 16:44:08 *** Zuu [~Zuu@h-114-141.a98.priv.bahnhof.se] has joined #openttd 16:55:34 <TrueBrain> shit, forgot to fix the bug where on pause, the growth updates are not getting through 16:55:35 <TrueBrain> bah :P 16:56:20 <frosch123> set the right setting then 16:57:25 <frosch123> but, did you actually post new binaries? just fix it now :p 16:57:50 <TrueBrain> fixed; I guess I can put the CF to work again yeah .. why not :) 16:57:52 <Zuu> There are binaries of today on finger. 17:02:09 <TrueBrain> compiling new version then 17:03:12 <frosch123> i guess toyland would be quite an annoying challenge 17:03:50 <frosch123> it has this nasty effect that small house accept sweets, while big houses accept fizzy drinks 17:04:02 <frosch123> so, if the town growths, it stops accepting sweets iirc 17:04:09 <TrueBrain> lol 17:05:53 <TrueBrain> http://paste.openttdcoop.org/show/tQ7azTjOUOQ3EDkAOK5t/ 17:05:56 <TrueBrain> oops 17:05:58 <TrueBrain> wrong channel :D 17:06:34 <frosch123> :p 17:06:37 <Zuu> :-) 17:06:46 <TrueBrain> now that my friends is a huge: FAIL :D 17:07:56 <panna> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 17:08:47 *** panna is now known as virrpanna 17:12:29 <andythenorth> bah 17:12:46 <andythenorth> so...if you have LH drive set, HEQS is just going to look dumb 17:18:18 <Eddi|zuHause> you can certainly duplicate the sprites with different offsets for LH drive 17:18:44 * planetmaker wondered what Lufthansa had to do with this... :-P 17:19:35 <Eddi|zuHause> if you had nml, you could do this calculation in the template 17:22:45 <z-MaTRiX> Eddi|zuHause<< actively hiding errors from users ;) 17:23:28 <z-MaTRiX> though there are anomalies 17:23:55 <z-MaTRiX> the'd need to not report, or double buffer the results to not show anything 17:26:08 <andythenorth> can we have a cb for offsets? 17:26:16 <andythenorth> then I can do the calculation 17:29:02 <Eddi|zuHause> maybe during graphics callback, one of the 0x100+ registers could contain an offset-adjustment 17:30:52 <andythenorth> shame cpp can't do arithmetic 17:31:07 <frosch123> m4 ! 17:31:41 <z-MaTRiX> asm can do anything 17:32:44 <frosch123> you first have to invent a preprocessor called "asm" to give that line any sense 17:33:55 <z-MaTRiX> FASM has one 17:34:08 <z-MaTRiX> and it compiles itself in 0.1 seconds 17:41:52 *** Progman_ [~progman@p57A1AD2A.dip.t-dialin.net] has joined #openttd 17:43:58 <Alberth> andythenorth: use a proper macro processor, like m4 17:44:33 <andythenorth> tbh, there's no gain from doing the arithmetic on the fly 17:44:57 <andythenorth> if every RV needs custom offsets for left-hand-drive-side, then I should just make more action 1s 17:45:06 <andythenorth> although it's twice the number of realsprites to make :( 17:46:10 *** Progman [~progman@p57A1D87A.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 17:46:11 *** Progman_ is now known as Progman 18:00:40 *** valhallasw [~valhallas@241.228.68.86.rev.sfr.net] has joined #openttd 18:13:40 *** DayDreamer [~DayDreame@ip-86-49-59-25.net.upcbroadband.cz] has joined #openttd 18:14:54 <andythenorth> TrueBrain: can scripts be bound to a specific map? i.e. mostly specific towns 18:15:10 <andythenorth> can / will / is it a good idea /s 18:15:31 <frosch123> you an 18:15:34 <frosch123> *can 18:15:39 <Zuu> It might be a good idea to allow a scenario to bind to a specific goal script. 18:15:53 <TrueBrain> savegames will store the script they used to run with 18:16:00 <frosch123> a scenario will bind a goal script just like ais 18:16:07 <frosch123> and scripts can read town names 18:16:09 <andythenorth> \o/ 18:16:17 <frosch123> so, unless you rename the towns, it should be fine :p 18:16:34 <frosch123> though the script could actualy catch the townid on start, before you rename it :p 18:16:46 <andythenorth> or bind to the id :P 18:17:20 <andythenorth> presumably bundling a newgrf + a script is insane? 18:18:19 <frosch123> industries are quite a newgrf derivate, not much a script can do about their production 18:18:27 <andythenorth> cases would be things like industry closure, which have proven unsolvable 18:18:32 <andythenorth> in newgrf 18:18:39 <Zuu> Probably not, but it depends on if scripts are going to be available as AIs on bananas and thus should be general purpose enough to survive any map. 18:18:47 <Zuu> probably not too insane* 18:19:04 <TrueBrain> I think a script should be able to 'suggest' newgrfs too, with which it works best 18:19:14 <frosch123> i was wondering whether it makes sense to load multiple scripts at once 18:19:19 <Eddi|zuHause> Zuu: you can make a script unavailable for general download, only as a dependency for the scenario 18:19:26 <Eddi|zuHause> frosch123: i do think so 18:19:27 <frosch123> i.e. one for the gameplay, and one for the statistics and admin stuff 18:19:35 <TrueBrain> frosch123: for now, we limit it to one 18:19:42 <TrueBrain> mostly because the implementation becomes so much easier ;) 18:19:44 <frosch123> TrueBrain: sure for now :) 18:19:45 <Eddi|zuHause> one may be too limited 18:19:46 <andythenorth> frosch123: how would they interact? Should a script be able to import another script? Sounds ...explodey :) 18:20:05 <TrueBrain> solving the implementation issue to allow more can be very tricky ;) 18:20:16 <andythenorth> in some respects, FIRS is doing things that are perhaps not best done in newgrf - industry clustering, open dates, and such 18:20:23 <frosch123> maybe since scripts are easy enough, we can just say: you have to combine the source 18:20:30 <frosch123> makes it easier for us: no conflicts 18:20:32 <andythenorth> possibly even some of the placement things - snowline, towns etc should not be in newgrf 18:20:33 <TrueBrain> libraries :P 18:20:57 <frosch123> yeah, the statistics stuff would suit a library 18:21:22 <andythenorth> industry handling library 18:21:38 <TrueBrain> but having 2 scripts active at the same time can be tricky, as you need to be sure they do not collide in settings etc ;) 18:21:45 <TrueBrain> so yeah, via libraries or what-ever is much easier :) 18:22:32 <Eddi|zuHause> hm, ok. 18:22:38 <Zuu> An interesting problem is if all current libraries will need to have a duplicate eddition that uses Goal* instead of AI* or if OpenTTD can handle that. 18:22:42 * andythenorth plots a FIRS library :P 18:23:01 <Eddi|zuHause> must teach the script authors properly 18:23:01 <TrueBrain> Zuu: there are no current libraries that are useful to Goal :) 18:23:09 <Xaroth> TrueBrain: so I should compile new version? 18:23:09 <andythenorth> hmm...could grfs specify certain libraries are needed via action 14? Again, could be explodey... 18:23:17 <TrueBrain> Xaroth: yes please :) 18:23:25 <Xaroth> righty-o then 18:23:27 <TrueBrain> and hurry, we want to play :P 18:23:43 <Zuu> hehe :-) 18:23:48 <andythenorth> what are the game rules? I haven't played MP for ages... 18:23:57 <andythenorth> I'm no good at hardcore coop styles :P 18:24:02 <Xaroth> andythenorth: don't be a dick. 18:24:09 <Xaroth> one rule to rule them all 18:24:11 <planetmaker> which server, TrueBrain? 18:24:28 <andythenorth> Xaroth: last time I played MP I wasn't too good at that :( 18:24:30 <planetmaker> and revision? 18:24:40 <andythenorth> I annoyed everyone else with my routes :P 18:24:55 <Xaroth> recompiling new version 18:24:56 <andythenorth> we should go all out, test NoGo, YAIM + YACD :P 18:25:01 <andythenorth> with FIRS tip 18:25:10 <Eddi|zuHause> "wine: could not find the Wine loader" <-- wth did i do wrong? 18:25:41 <planetmaker> Xaroth: which hash? 18:25:54 <Xaroth> no idea yet :P 18:25:58 <Xaroth> still compiling 18:26:13 <planetmaker> :-D 18:26:21 <planetmaker> Will the OpenTTD CF compile, too? 18:26:25 <planetmaker> For lazy people? 18:26:42 <Xaroth> knowing tb, yes 18:26:53 <planetmaker> :-) 18:26:53 <Eddi|zuHause> mÀh... i guess i should really finally try to figure out a real windows install... 18:27:03 <TrueBrain> the CF has been done for hours already 18:27:08 <planetmaker> h22? 18:27:09 <andythenorth> shame there's no way to distribute nightly grfs on bananas easily 18:27:18 <z-MaTRiX> Eddi|zuHause<< dd? :) 18:27:29 <TrueBrain> planetmaker: latest :P 18:27:32 <Zuu> the CF build is also now available through OTTDAU for the lazy people :-) 18:27:42 <planetmaker> oh... a refresh works wonders ;-) 18:27:46 <TrueBrain> planetmaker: http://finger.openttd.org/versions.txt 18:27:48 <TrueBrain> :P 18:27:58 <z-MaTRiX> my win98 install was 1 minutes 30 seconds fdrom a cd in 1998 18:28:00 *** Devroush [~dennis@178-119-153-135.access.telenet.be] has quit [Ping timeout: 480 seconds] 18:28:24 * andythenorth lost the binary server 18:28:59 * andythenorth found it 18:29:03 <Eddi|zuHause> z-MaTRiX: let me express my doubts that win98 runs CivV or HeroesVI 18:29:37 <z-MaTRiX> never heard ot those ;< 18:29:45 <z-MaTRiX> btw i had xp too 18:30:01 <z-MaTRiX> but after a full ntfs fail i installed linux 18:31:17 <Xaroth> right 18:31:21 <Xaroth> #1 is running 18:31:24 <Xaroth> WITH heqs this time 18:31:43 <planetmaker> Xaroth: I prepared a savegame 18:31:45 <frosch123> Xaroth: use pm's save? 18:32:08 <Xaroth> whats so special about the savegame? 18:32:13 <planetmaker> http://devs.openttd.org/~planetmaker/patches/nogo.sav 18:32:18 <planetmaker> it has a usable newgrf config 18:32:29 <Xaroth> and which newgrf might that be? 18:33:20 <planetmaker> some bananas newgrfs, like ogfx+airports, ogfx+industries, brazilian townnames to macht tropical climate, ISR, CHIPS, av8, heqs, fish, TRS 18:33:36 <Xaroth> some?!? 18:33:39 <planetmaker> some 18:33:40 <frosch123> trs? 18:33:45 <frosch123> isn't that damn ugly? 18:33:46 <planetmaker> tropical refurbishment set 18:33:49 <TrueBrain> why not save the newgrf, and give that to him? So he can also generate new maps etc? 18:33:49 <planetmaker> like we had before 18:33:57 <andythenorth> where is the filter widget on multiplayer window? 18:34:01 <frosch123> oh, i thought town renewal set 18:34:08 <frosch123> but that is ttrs :) 18:34:19 <Xaroth> planetmaker: I prefer randomly generated maps, so the server can just re-set itself over and over again 18:34:27 <Xaroth> .. and it won't break when tb (again) breaks saves :P 18:34:29 <planetmaker> Xaroth: it's randomly generated... 18:34:43 <TrueBrain> planetmaker: he wants to run it for more than one map ;) 18:35:03 *** JGR [~IRC@oriel-student-nat.oriel.ox.ac.uk] has joined #openttd 18:35:11 *** Illegal_Alien [~Illegal_A@ip4da39612.direct-adsl.nl] has joined #openttd 18:35:12 <CIA-6> OpenTTD: rubidium * r23285 /trunk/src/network/network_content_gui.cpp: -Fix: scanning of content after download didn't work 18:35:13 <planetmaker> ja, my god. grab the save, make a newgrf preset and save that 18:35:35 <planetmaker> one _can_ make it complicated 18:35:55 <TrueBrain> yes; you can also give the preset :D 18:35:56 <TrueBrain> hihi 18:35:57 <Xaroth> like providing a save instead of info, yes 18:36:10 <TrueBrain> works two ways, complications :D 18:36:13 <planetmaker> 19:33 planetmaker: http://devs.openttd.org/~planetmaker/patches/nogo.sav 18:36:17 <planetmaker> ^^ 18:36:22 <Xaroth> i want info, not a save :P 18:36:39 <TrueBrain> planetmaker: you seriously don't get that a savegame is just a one time thing? In the order of: giving a fish instead of learning to fish? :) 18:37:07 <frosch123> tb: there is no better way to specify grfs than using a savegame 18:37:11 <Rubidium> TrueBrain: but giving you a set of (unreadable) instructions doesn't work either 18:37:12 <TrueBrain> hihi: why dont we make newgrf presets uploadable to BaNaNaS? :D 18:37:15 <frosch123> it also contains the md5sums and all settings 18:37:22 <planetmaker> TrueBrain: and the parameters set... 18:37:25 <Xaroth> av8 1.81 or 2.0 18:37:39 <TrueBrain> a newgrf set should do that too, wouldn't it? Anyway, it is a clumpsy way of sharing settings ... 18:37:39 <planetmaker> ... load the damn savegame 18:37:50 <TrueBrain> I had that issue earlier when I asked you about some good settings a few weeks ago :) 18:38:07 <Eddi|zuHause> hm... what linux tool can mount .wim files? 18:38:28 <TrueBrain> would it be hard to make some kind of file which loads the preset like as with a savegame? 18:38:31 <TrueBrain> including parameters etc? 18:38:44 <TrueBrain> so you can easily share such (obvously complex) information? 18:39:02 <Rubidium> we should go from filenames in the config to grfid_md5sum = params I guess 18:39:28 <planetmaker> http://imagebin.org/184910 18:39:30 <Rubidium> then you can easily copy it between versions of OpenTTD, *and*... you can possibly download it with bananas when it's on there 18:39:51 <planetmaker> but that doesn't give you the parameters 18:40:10 <TrueBrain> newgrfs became too complex :D 18:40:11 <TrueBrain> hihi 18:40:18 <planetmaker> nor the landscape which I made sure fits our purpose 18:40:24 <planetmaker> they're dead easy 18:40:28 <planetmaker> load and use... 18:40:38 <Eddi|zuHause> Rubidium: but that still does not solve updating grfs from bananas 18:40:39 <TrueBrain> yet you have a hard time giving the information to someone else :D 18:40:44 <TrueBrain> so 'dead' easy is not thw word I would use ;) 18:40:49 <planetmaker> because you don't want the info 18:40:55 <planetmaker> I gave you all you can want 18:40:56 <TrueBrain> see my point? 18:41:00 <Eddi|zuHause> Rubidium: if i update a grf, it should be updated in all presets 18:41:03 <planetmaker> load. save. re-use 18:41:04 <planetmaker> done 18:41:12 <planetmaker> no better way THAN a savegame 18:41:15 <TrueBrain> planetmaker: you can keep repeating that, but clearly we (As users) want more than just that :) 18:41:20 <planetmaker> so, no, I don't see the point 18:41:25 <TrueBrain> so clearly there is a gap here between what you can supply, and we want to get 18:41:40 <planetmaker> I just see that I spend like looking for a good landscape and stuff for... nothing 18:41:46 <Xaroth> right 18:41:49 <Xaroth> nogo1 is running 18:41:51 <planetmaker> because of "I want to do it my way" 18:41:52 <Xaroth> with the specified newgrf 18:41:58 <TrueBrain> planetmaker: it is not about a single map; it is about a server running for a few weeks 18:42:01 <planetmaker> Xaroth: parameter for industries? 18:42:05 <TrueBrain> your map is not sufficient for that 18:42:07 <Xaroth> copied from your save 18:42:11 <planetmaker> good 18:42:14 <Xaroth> = 16 1 3 4 1 1 1 1 1 1 3 1 1 1 1 1 18:42:26 <planetmaker> dunno the numbers. Configuration ingame rulez 18:42:53 <Xaroth> frosch will be chuffed, no swedish rail o_O 18:42:54 <frosch123> another point why savegames are supiriour to any text info 18:43:06 <planetmaker> Xaroth: in tropical climate they're not that much of an advantage 18:43:08 <frosch123> Xaroth: why? pm pushed that 18:43:27 <planetmaker> and mostly I forgot them, but doesn't matter too much 18:43:28 <Xaroth> frosch123: because they weren't in the preset in the save 18:43:31 <Xaroth> so don't look at me. 18:43:44 <CIA-6> OpenTTD: translators * r23286 /trunk/src/lang/ (croatian.txt unfinished/basque.txt welsh.txt): 18:43:44 <CIA-6> OpenTTD: -Update from WebTranslator v3.0: 18:43:44 <CIA-6> OpenTTD: basque - 1 changes by Thadah 18:43:44 <CIA-6> OpenTTD: croatian - 8 changes by VoyagerOne 18:43:44 <CIA-6> OpenTTD: welsh - 4 changes by kazzie 18:43:52 * andythenorth ponders 18:44:19 <andythenorth> could I disable HEQS if game drive side is left? 18:45:18 <frosch123> andythenorth: there is at least one another set, giving a warning "this set is supposed to be used with rhs driving" 18:48:29 <andythenorth> but not disabling? 18:49:27 <frosch123> no, not so harsh :p 18:50:26 *** TWerkhoven [~twerkhove@cpc12-linl7-2-0-cust144.sgyl.cable.virginmedia.com] has quit [Quit: He who can look into the future, has a brighter future to look into] 18:51:15 <frosch123> TrueBrain: fix nogo 18:51:24 <TrueBrain> *bark* 18:51:30 <TrueBrain> (playing a dog :D) 18:51:45 <frosch123> the towns show no goal again 18:52:00 <TrueBrain> I am playing Saints Row Third 18:52:04 <TrueBrain> I really have to quit that game? :( 18:52:22 <andythenorth> I should update the newgrf wiki to indicate that offsets need to be different for LH drive and RH drive 18:52:38 <andythenorth> what's a good way to explain that? 18:52:59 <frosch123> enable the bounding boxes and make a screenshot? 18:54:16 <andythenorth> do I miss the flag for drive side here? 18:54:17 <andythenorth> http://newgrf-specs.tt-wiki.net/wiki/TTDPatchFlags 18:54:25 <andythenorth> I know there's a global varaction 2 for it 18:54:57 <frosch123> there is only that var 18:55:08 <frosch123> why should there be also a flag? 18:55:25 <andythenorth> I want to use action 7 for it 18:55:47 <frosch123> where's the problem? 18:56:42 <andythenorth> there isn't, I misunderstand action 7 :) 18:57:02 * andythenorth is wondering if an offset fix can be scripted by the devzone makefile 18:57:33 <Xaroth> right, nogo #1 is running 18:57:41 <andythenorth> is the required delta for the offset deterministic across all vehicles that have same length reduction? 18:58:41 <planetmaker> so... one company or many? 18:59:08 <Eddi|zuHause> IS!! 18:59:24 *** TWerkhoven [~twerkhove@cpc12-linl7-2-0-cust144.sgyl.cable.virginmedia.com] has joined #openttd 18:59:26 <Eddi|zuHause> nobody actually solved the payment in IS yet... 18:59:35 <TrueBrain> Rubidium: tbh, if only you could Export and Import prsets, which do it via md5, it would be sufficient I think ;) 18:59:39 <andythenorth> meh, version mismatch :P 18:59:59 <Eddi|zuHause> <andythenorth> is the required delta for the offset deterministic across all vehicles that have same length reduction? <-- i guess so 19:00:09 <Xaroth> andythenorth: http://master.binaries.openttd.org/custom/nogo/hdf3ddb06-nogo/index.html 19:00:59 <XeryusTC> oh, OTTDAU is already updated for NoGo :D 19:02:02 <Yexo> Xaroth: http://www.openttd.org/en/download-nogo 19:02:05 <TrueBrain> Zuu is that awesome yeah 19:02:15 <Xaroth> Yexo: potatoe potatoe :) 19:02:25 <TrueBrain> Xaroth: not really; his URL is better 19:02:27 * XeryusTC will try to get the El Kinky Negro Party to do some NoGo :o 19:02:29 <TrueBrain> goes via the load balancer 19:02:45 <Zuu> XeryusTC: Yep, why download manually instead of "just" updating it :-) 19:03:05 <Xaroth> right, i'll keep that in mind 19:03:08 * XeryusTC hands Zuu a free beer 19:03:39 <Zuu> thanks, but I got quite some beers yesterday night and doesn't really want a beer today :-) 19:04:09 <Eddi|zuHause> anybody has an idea about 3D-acceleration in combination with libvirt/kvm? 19:04:46 <CIA-6> OpenTTD: rubidium * r23287 /trunk/src/table/misc_settings.ini: -Fix (r23274): mono_size is a better name than large_mono for the size variable in the configuration file 19:06:12 <andythenorth> anybody like awk or some such, and want to help fix HEQS? :| :D :P 19:06:30 <andythenorth> or python 19:07:14 <Xaroth> I like python, but i'm too busy working on my admin-port lib. 19:07:32 <CIA-6> OpenTTD: rubidium * r23288 /trunk/src/newgrf_gui.cpp: -Feature: use the monospace font for the NewGRF text windows 19:11:10 *** ptr [~peter@c213-89-142-179.bredband.comhem.se] has joined #openttd 19:17:38 <Eddi|zuHause> ah... great... "this rescue/install DVD will only run flawlessly on HP systems. [cancel]" 19:18:08 <Eddi|zuHause> fuck everybody! 19:18:58 <peter1138> what? 19:19:40 <Eddi|zuHause> of course it tells that _after_ letting me wait to copy 5GB of data 19:19:40 <TrueBrain> Eddi|zuHause: that would take you a long time :( 19:24:03 <Eddi|zuHause> i hate days when nothing works... 19:25:39 <Eddi|zuHause> i have a game that doesn't run which ran before. i have a game that doesn't run and needs a wine patch. i have a wine patch that makes a game run but doesn't apply. i have a wine compile that doesn't run even without patch. i have a windows-install-cd which doesn't install 19:26:09 <__ln__> could be worse, it could rain 19:28:32 *** ptr [~peter@c213-89-142-179.bredband.comhem.se] has quit [Quit: Zzzzzz] 19:29:27 <XeryusTC> :( 19:29:32 *** ptr [~peter@c213-89-142-179.bredband.comhem.se] has joined #openttd 19:29:58 <Xaroth> up again. 19:30:08 *** ptr [~peter@c213-89-142-179.bredband.comhem.se] has quit [] 19:31:40 *** Devroush [~dennis@ip-83-134-169-23.dsl.scarlet.be] has joined #openttd 19:32:33 <planetmaker> devs.openttd.org/~planetmaker/patches/nogo3.sav <-- Xaroth 19:32:37 <planetmaker> nvm 19:33:21 <Xaroth> planetmaker: let me load it on the server 19:34:04 <Xaroth> it's on the server, will use it at some point 19:34:05 <Xaroth> thanks. 19:34:10 <planetmaker> it's the current savegame minus all trains 19:34:19 <planetmaker> at some point it's pointless 19:34:24 <planetmaker> either now or scrap it 19:34:51 <planetmaker> but I guess I'll never provide a savegame anymore 19:35:06 <planetmaker> seems pointless 19:35:52 <Xaroth> it also seems a bit pointless to have half a dozen people constantly reconnect and whatnot 19:35:59 <Xaroth> but if you want, you can have rcon access 19:36:22 <planetmaker> no, I don't 19:36:24 <TrueBrain> lol, planetmaker, you just loaded the game in SP and reloaded it on the seed, or? 19:36:29 <TrueBrain> kinda like that approach :D 19:36:31 <planetmaker> I fixed the trainset 19:36:40 <planetmaker> so that the game can be continued 19:36:55 <planetmaker> save -> fix in SP -> load back on server 19:37:02 <TrueBrain> I have to remember that :D 19:37:06 <planetmaker> standard procedure 19:37:39 <TrueBrain> hehe; you have played too many games :D:D (a positive thing) 19:37:57 <planetmaker> nah, but I care for the game being played on my servers 19:39:51 <TrueBrain> it is also the way you build etc :) 19:53:18 *** HerzogDeXtEr1 [~Flex@88.130.168.113] has quit [Read error: Connection reset by peer] 19:54:27 *** HerzogDeXtEr [~Flex@88.130.168.113] has joined #openttd 19:56:28 *** DayDreamer1 [~DayDreame@ip-86-49-59-25.net.upcbroadband.cz] has joined #openttd 20:01:14 *** DayDreamer [~DayDreame@ip-86-49-59-25.net.upcbroadband.cz] has quit [Ping timeout: 480 seconds] 20:18:07 *** Elukka [~Elukka@78-27-81-109.bb.dnainternet.fi] has joined #openttd 20:25:54 *** Maarten1 [~Maarten@c29061.upc-c.chello.nl] has quit [Ping timeout: 480 seconds] 20:28:57 *** DDR [~chatzilla@142.179.78.88] has joined #openttd 20:37:37 *** Kurimus [~stabbity@dsl-tkubrasgw3-fe93dd00-34.dhcp.inet.fi] has quit [] 21:00:17 *** DayDreamer1 [~DayDreame@ip-86-49-59-25.net.upcbroadband.cz] has left #openttd [] 21:08:01 *** valhallasw [~valhallas@241.228.68.86.rev.sfr.net] has quit [Read error: Connection reset by peer] 21:11:28 *** valhallasw [~valhallas@241.228.68.86.rev.sfr.net] has joined #openttd 21:14:33 *** Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has left #openttd [] 21:27:53 <frosch123> night 21:27:56 *** frosch123 [~frosch@frnk-590ff025.pool.mediaWays.net] has quit [Remote host closed the connection] 21:28:22 <XeryusTC> planetmaker: do you have skype? 21:39:12 <Terkhen> good night 21:44:22 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has joined #openttd 22:01:15 *** Illegal_Alien [~Illegal_A@ip4da39612.direct-adsl.nl] has quit [Quit: HydraIRC -> http://www.hydrairc.com <- It'll be on slashdot one day...] 22:02:26 *** hanf [~Klaus@host-2-101-48-65.as13285.net] has joined #openttd 22:14:30 *** andythenorth [~Andy@cpc1-aztw25-2-0-cust298.aztw.cable.virginmedia.com] has quit [Quit: andythenorth] 22:22:19 <TrueBrain> XeryusTC: OpenTTD needs a TS (Mumble?) server! Skype is for pussies :P 22:23:36 <XeryusTC> TrueBrain: i'm recording skype 22:23:57 *** ptr [~peter@c213-89-142-179.bredband.comhem.se] has joined #openttd 22:24:24 <TrueBrain> :s 22:24:26 <TrueBrain> why?! 22:24:44 *** valhallasw [~valhallas@241.228.68.86.rev.sfr.net] has quit [Quit: leaving] 22:26:23 *** Zuu [~Zuu@h-114-141.a98.priv.bahnhof.se] has quit [Ping timeout: 480 seconds] 22:27:39 <XeryusTC> making a let's play ;) 22:27:45 <XeryusTC> i'm kind of into recording OpenTTD atm 22:27:52 <XeryusTC> http://www.youtube.com/user/XeryusTC 22:31:30 *** welshdragon [~welshdrag@host217-42-195-16.range217-42.btcentralplus.com] has joined #openttd 22:33:18 *** mahmoud [~KEM@ALyon-158-1-190-31.w109-212.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 22:34:55 *** Prof_Frink [~proffrink@5e0a9627.bb.sky.com] has joined #openttd 22:40:16 *** TGYoshi [~TGYoshi@86.81.146.146] has quit [Quit: Poof] 22:44:38 <z-MaTRiX> what does openttd use for accurate timing? 22:45:43 <Arafangion> z-MaTRiX: openttd has accurate timing? 22:45:52 <z-MaTRiX> donno :) 22:46:07 <z-MaTRiX> framerate limit or game timebase? 22:46:29 <z-MaTRiX> lagchecker? 22:48:19 <Arafangion> I'm sure it uses something... I was questioning your claim that it was "accurate timing". 22:49:45 <z-MaTRiX> i believe gettimeofday() is our best option for now 22:50:29 <z-MaTRiX> since rdtsc is unstable on most cpus 22:51:22 <Arafangion> And this matters... how? 22:52:20 <z-MaTRiX> well i'm coding and was interested 22:52:29 *** JVassie [~James@2.25.210.119] has quit [Ping timeout: 480 seconds] 22:53:06 <Arafangion> Fair enough. :) 22:53:07 <z-MaTRiX> and instead of digging through all the openttd sources, was thinking about i may ask the developers 22:53:12 <z-MaTRiX> maybe they know 22:56:40 <TrueBrain> well, you started off with the assumption OpenTTD has one 22:56:46 <TrueBrain> no clue what makes you think it does :) 22:57:08 <z-MaTRiX> :) 22:57:17 <z-MaTRiX> btw SDL has a SDL_GetTicks 22:57:42 <z-MaTRiX> that should be millisecond resolution 22:57:51 <TrueBrain> and this matters ... how? 22:57:58 <TrueBrain> (hihi, sorry to steal your line Arafangion :D) 22:58:05 <z-MaTRiX> well for measuring fps a timer is needed 22:58:23 <TrueBrain> lol .. fps for OpenTTD .. that would be useful? 22:58:25 <TrueBrain> lolz 22:58:36 <michi_cc> For Windows QueryPerformanceCounter() is likely your best bet. 22:58:38 <z-MaTRiX> or updating the screen accurately timed 22:58:47 <z-MaTRiX> aham 22:58:50 <TrueBrain> wihch game would want to update its screen accurately? 22:58:50 <z-MaTRiX> im on linux 22:59:13 <z-MaTRiX> TrueBrain<< welll if i do animation i'd like it to go on constant rate 22:59:29 <TrueBrain> which is totally unrelated to screen updates 22:59:32 <TrueBrain> and, for that matter, to OpenTTD 22:59:53 <z-MaTRiX> ok well in openttd animation is not a real issue 23:00:09 <z-MaTRiX> thats mor elike some slideshow 23:00:37 <TrueBrain> I wonder what patch you are making that adds slideshows to OpenTTD 23:00:42 <z-MaTRiX> :) 23:01:41 <z-MaTRiX> well how about an animation for the background of the console window? or options menu? 23:01:50 <z-MaTRiX> like some moving fractals 23:01:51 <Arafangion> TrueBrain: You're welcome to it. :) 23:02:18 <TrueBrain> z-MaTRiX: sounds like a welcome improvement to OpenTTD ........ NOT (hihi, I just Boratted you :D:D) 23:02:28 <TrueBrain> sorry, that was not nice :) 23:02:57 <TrueBrain> I can't imagine something like that to be useful; but feel free to make us a patch and proof us wrong :) 23:03:11 <z-MaTRiX> ok maybe not :) 23:03:16 <z-MaTRiX> just to say something 23:03:38 <z-MaTRiX> its one thing that bothers me though 23:04:06 <z-MaTRiX> the good-old ttd in dos has much higher animation speed 23:04:40 <z-MaTRiX> i guess its related to the SDL_Flip framerate limit 23:04:46 <TrueBrain> you sure about that? 23:05:18 <z-MaTRiX> i'm somewhat sure if the video rendering would be a seperate thread, it would result in an instant speed-up 23:05:25 <z-MaTRiX> *separate 23:05:29 <TrueBrain> haha; that is just a lie :) 23:05:47 <TrueBrain> but how would that help animation speed? 23:06:04 <TrueBrain> I promise you, on the fastest machine you can find, OpenTTD will still run on the same speed as a new created map does 23:06:32 <z-MaTRiX> if the display function introduces an unwanted delay every refresh, then it cannot result in smooth animation 23:06:47 <Arafangion> TrueBrain: On my machine, actually, OPenTTD is much faster in multiplayer mode than it is in a single-player mode. 23:06:49 <TrueBrain> where do you see non-smooth animation in OpenTTD 23:06:59 <TrueBrain> Arafangion: lol; that is ... very ... weird :) 23:07:14 <Arafangion> TrueBrain: If the architecture was multithreaded, it would run faster. Then again, I run on an Atom D525 system. 23:07:26 <z-MaTRiX> TrueBrain<< like when i click a maglev, and make the viewfinder follow it 23:07:36 <TrueBrain> the assumption anything would run faster threaded, is a lie :) 23:07:43 <JGR> Multithreading would just move the bottleneck elsewhere, and make coding a nightmare 23:07:47 <TrueBrain> it is not a magic powder you can drip over software 23:07:56 <Arafangion> JGR: I'll agree with that. 23:08:00 <TrueBrain> z-MaTRiX: is that animation? 23:08:04 <TrueBrain> animation is the sea you see animating 23:08:07 <TrueBrain> (hence the word: animation) 23:08:09 <z-MaTRiX> ok 23:08:16 <z-MaTRiX> click the fast forward at top left 23:08:19 <z-MaTRiX> i was thinking about that 23:08:31 <z-MaTRiX> time goes slow compared to the dos ttd 23:08:32 <TrueBrain> increase the speed of the whole game? 23:08:37 <TrueBrain> no, it should be near identical 23:08:43 <TrueBrain> else someone fucked up something 8 years ago 23:09:03 <TrueBrain> or your DOS emulator is bad, that is also an option 23:09:03 <z-MaTRiX> or i dont have good-enough hardware ... 23:09:03 <Yexo> z-MaTRiX: and how are you comparing to dos ttd? 23:09:04 <z-MaTRiX> :P 23:09:18 <XeryusTC> planetmaker: it may actually not have recorded voice because of some fubar mess up :o 23:09:27 <Arafangion> z-MaTRiX: Move your map so that the far right corner is the only part that's visible... And disable the fancy graphics so that the water is not moving, and compare performance. 23:09:29 <TrueBrain> XeryusTC: lolz ..... 23:09:31 <z-MaTRiX> Yexo<< ok i know the whole thing differs 23:09:33 <XeryusTC> because it did record what i did before server reset xD 23:09:40 <z-MaTRiX> resolution is larger too 23:09:47 <XeryusTC> but the long 3 hour conversation is not on my hdd it seems xD 23:10:00 <TrueBrain> z-MaTRiX: well, your 'idea' of the speed of TTD (DOS) might be widly different then the reality 23:10:15 <TrueBrain> it happens a lot to people .. they remember old games differently than they really are 23:10:29 <TrueBrain> install DOSBox, install TTD, and play it. Then compare. 23:10:35 <Arafangion> Ha. 23:10:37 <TrueBrain> (without fast-forward, of course) 23:10:37 <z-MaTRiX> done that 23:10:47 <z-MaTRiX> why? 23:10:49 <TrueBrain> now press .. I think F3 in DOSBox 23:10:52 <TrueBrain> that is funny :D 23:10:54 <TrueBrain> or was it F5 .. 23:10:54 <Arafangion> z-MaTRiX's linux system may will have crappy graphics. 23:10:54 <z-MaTRiX> i was talking about fast forward 23:11:00 <TrueBrain> LOL! 23:11:09 <TrueBrain> okay, z-MaTRiX, that is something you cannot compare in any sane way :D 23:11:19 <TrueBrain> that is so silly, and has absolutely nothing to do with timing (accurate or not :)) 23:11:27 <Yexo> but dos ttd doesn't even have fast forward, right? 23:11:27 <z-MaTRiX> not timing 23:11:33 <z-MaTRiX> its a different question 23:11:39 <TrueBrain> huh? Where did you change the question? 23:11:50 <TrueBrain> [00:05] <z-MaTRiX> the good-old ttd in dos has much higher animation speed 23:11:55 <z-MaTRiX> that should only demonstrate the botleneck caused by displaying 23:11:55 <Arafangion> Yexo: It does. 23:11:56 <TrueBrain> that sounds like we are talking about timing .. 23:12:09 <TrueBrain> owh, so fast forward is limited by the display, in speed? 23:12:16 <z-MaTRiX> yes 23:12:18 <z-MaTRiX> i believe 23:12:20 <TrueBrain> and you know this .. how? 23:12:26 <TrueBrain> a magic bird told you, or did you do any profiling? 23:12:36 <Yexo> TrueBrain: the magic bird of course 23:12:39 <z-MaTRiX> well i just started to use SDL too 23:12:44 <Yexo> z-MaTRiX has yet to start looking at the source code 23:12:45 <TrueBrain> I thought I shot down that bird a while ago ... 23:12:45 <z-MaTRiX> and the birds were telling it 23:12:51 <Yexo> yet he knows everything about why it's limited in speed 23:13:09 <TrueBrain> z-MaTRiX: a piece of advise ... don't come with lies in this channel. They often die fast. Unless you can proof something is true, sure, feel free 23:13:14 <TrueBrain> but what you just said is just gibberish 23:13:21 <Arafangion> Hilariously, the reason is because OPenTTD makes bad decisions in code that gets the current time of day. 23:13:22 <z-MaTRiX> ok well im on it 23:13:28 <z-MaTRiX> currently doing testing and fps meter 23:13:44 <Arafangion> z-MaTRiX: What makes you think the fps is indicative? 23:13:45 <TrueBrain> so come back AFTER you have data, instead of 'guessing' before you do 23:13:54 <TrueBrain> next you are going to tell us we should use voxels, as they are epic! 23:14:38 * Arafangion ... must resist... talking about voxels... 23:14:38 <z-MaTRiX> i was not complaining 23:14:44 <z-MaTRiX> i was asking 23:14:45 <TrueBrain> no, but you are telling lies about the game 23:14:51 <TrueBrain> not in a question. You were stating 23:14:59 <TrueBrain> [00:13] <TrueBrain> owh, so fast forward is limited by the display, in speed? 23:15:01 <TrueBrain> [00:14] <z-MaTRiX> yes 23:15:02 <TrueBrain> that is not asking 23:15:04 <TrueBrain> that is saying you know something 23:15:08 <z-MaTRiX> i believe i did only reply to questions 23:15:11 <TrueBrain> asking is good. Lying is not. 23:15:22 * Arafangion rushes off to work. 23:15:29 <TrueBrain> Arafangion: have a nice working day 23:15:34 <TrueBrain> it is 0017 here .. lolz 23:15:47 <TrueBrain> means you are ... East of me! :P 23:15:49 <z-MaTRiX> [001417] TrueBrain it is 0017 here .. lolz 23:15:58 *** pjpe [ae5b514a@ircip1.mibbit.com] has joined #openttd 23:16:00 <Arafangion> GMT+10. 23:16:00 <z-MaTRiX> approxximately 23:16:05 <TrueBrain> Aussie :) 23:16:18 <TrueBrain> you can't go much further :P 23:16:33 <Arafangion> :) And with that, I must take my leave. :) 23:16:46 <TrueBrain> cya :) 23:18:56 <z-MaTRiX> so 23:19:21 <z-MaTRiX> im currently working on an sdl example program that does asynchronous display update 23:19:35 <z-MaTRiX> and comparing it to one that does not have it 23:22:19 *** TWerkhoven[l] [~turbulent@cpc12-linl7-2-0-cust144.sgyl.cable.virginmedia.com] has quit [Remote host closed the connection] 23:22:31 <z-MaTRiX> but since SDL_Flip is synchronized to vertical retrace, and SDL is not thread-safe, i guess the SDL_Flip will introduce a random forced delay in the mainloop 23:23:22 <z-MaTRiX> so putting the SDL dusplay update into a seperate thread/process will increase performance in all cases, 23:23:46 <JGR> You generally do not want a loop to run continuously with no delays 23:23:57 <z-MaTRiX> but at minimum, i can have a core function that runs at 10kHz while updating screen data at 60Hz 23:24:42 <JGR> If eeking out extra performance is that critical, investigate triple buffering 23:24:48 <TrueBrain> it is a bold statement, to say it will increase performance in _all_ cases 23:24:51 <TrueBrain> I know plenty in which it wouldn't 23:25:08 <TrueBrain> threads still aren't the holy cure 23:25:53 <z-MaTRiX> until you want to run the display on the second core :) 23:26:10 <JGR> It's not as simple as that 23:26:27 *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has quit [Remote host closed the connection] 23:26:37 <TrueBrain> switching threads is very expensive, so are mutexes ... there is so much more to it then 'just adding threads to make it faster' 23:26:47 <z-MaTRiX> yep 23:26:54 <JGR> Generally, for any useful display drawing function, it will need to access some data which is periodically modified by the "main" code 23:26:55 <TrueBrain> if it was so simple to increase performance of _all_ applications by threading it, tiw ould be done much more 23:27:11 <z-MaTRiX> JGR<< yes 23:27:19 <TrueBrain> in many cases it in fact slows down an application, if you are threading the display code .. 23:27:33 <z-MaTRiX> TrueBrain<< i don't care if its not simple, just coding 23:27:48 <TrueBrain> I am just complaining on your statements of 'all' and stuff like that :) 23:27:58 <z-MaTRiX> well i could do a process and have shared memory communication 23:28:10 <TrueBrain> shared memory requires a lock 23:28:17 <TrueBrain> which means the main thread freezes during display updates 23:28:18 <JGR> shared memory would be even worse 23:28:19 *** Wolf01 [~wolf01@host48-239-dynamic.16-79-r.retail.telecomitalia.it] has quit [Quit: Once again the world is quick to bury me.] 23:28:20 <TrueBrain> which makes them fibers 23:28:24 <z-MaTRiX> but i can use threads too... 23:28:29 <TrueBrain> which is juse a useless context switch 23:28:36 <JGR> Process swicthes are even more expensive than thread switches 23:29:11 <TrueBrain> JGR: lol, I missed he said processes, that is even worse yeah :D 23:29:18 <TrueBrain> an inter-process-lock, hehe :D 23:29:27 <z-MaTRiX> :) 23:29:33 <z-MaTRiX> inter-process-communication 23:29:43 <z-MaTRiX> now google will find this log on it 23:29:45 <TrueBrain> communication is fine, we have shit for that 23:29:50 <TrueBrain> OpenMP, OpenMPI, you name it 23:29:53 <TrueBrain> locks ... ieuw .... 23:30:09 <JGR> Having locks is better than having horrendous rae condition issues 23:30:11 <TrueBrain> hmm, OpenMP is in fact threading :P 23:30:12 <JGR> race* 23:30:19 <TrueBrain> JGR: haha, for that you have locks, yes :) 23:30:22 <TrueBrain> but they are very expensive :) 23:30:31 <TrueBrain> and in result, performance will degrade ;) 23:31:13 <z-MaTRiX> and if i just pipe the display data into the display process? 23:31:23 <z-MaTRiX> what will cause performance degradation? 23:31:25 <TrueBrain> 'display data'? 23:31:35 <TrueBrain> is that the prepared display, pixel by pixel? 23:31:43 <TrueBrain> as then you can just write it to the video memory directly, much faster 23:31:43 <z-MaTRiX> display command, or the whole buffer. 23:31:44 <JGR> That will cause horrendous performance slowdowns 23:31:57 <TrueBrain> otherwise, ^^ 23:32:22 <JGR> Piped data is buffered, marshalled, etc by the OS and that takes time and context switches 23:32:48 <TrueBrain> not to start about locks to avoid race conditions, bus-uses, cache-polution, ... 23:33:12 <JGR> I really don't see the problem with the wait in the loop, in the original question 23:33:25 <TrueBrain> JGR: which original question? :) 23:33:43 <JGR> [23:24:14] <z-MaTRiX> but since SDL_Flip is synchronized to vertical retrace, and SDL is not thread-safe, i guess the SDL_Flip will introduce a random forced delay in the mainloop 23:33:56 <TrueBrain> ah ;) 23:34:23 <TrueBrain> in general, how long does displaying really take? 23:34:29 <TrueBrain> 1% of the application? 2? 23:34:39 <JGR> A wait here implies that neither buffer is ready to be written to, and hence there's nothing to do anyway 23:34:44 <TrueBrain> so even if you thread it perfectly, the gain is to be noticed :) 23:34:56 <TrueBrain> +not 23:35:29 <TrueBrain> on another approach, if you want performance of your display, you don't use SDL :D 23:35:34 <TrueBrain> it has so many compatability layers, ugh 23:35:52 <z-MaTRiX> TrueBrain<< so you say it would have no benefits to have a continuously rolling mainloop, and a parallel snapshotting display thred? 23:35:53 * JGR is unfamiliar with SDL, to be honest 23:36:05 <TrueBrain> z-MaTRiX: for OpenTTD, I am very sure it won't help you 23:36:09 <TrueBrain> in general, it rarely does 23:36:17 <TrueBrain> as you need to lock down the main thread to access information to build your display 23:36:30 <TrueBrain> and those things are expensive like fuck 23:36:34 <z-MaTRiX> no i dont want to lock down my mainloop 23:36:45 <TrueBrain> JGR: SDL is a combination of layers to make it to work on all platforms. This costs a lot of performance :) 23:36:56 <TrueBrain> z-MaTRiX: you have no choice; else you get race conditions, which are worse 23:36:57 <JGR> @ z-MaTRiX, the majority of the main loop would be spent modifying the map/vehicle/etc arrays 23:37:16 <glx> TrueBrain: and may add some limits too 23:37:18 <TrueBrain> you cannot have a write in any area the display is trying to display, while it is displaying 23:37:21 <JGR> You can't reliably use those same arrays for drawing, when they're being modified 23:37:32 <TrueBrain> JGR: hence the locks ;) 23:37:44 <TrueBrain> there are some achitectures which introduce CoW in memory, which do allow it 23:37:55 <TrueBrain> but that is just really advanced fancy state-of-the-art shit, no user has ;) 23:38:31 <JGR> Those are generally quite trivial structures, and tend to involve things like CAS operations 23:38:42 <z-MaTRiX> TrueBrain<< i was thinking about double buffering... 23:38:44 <JGR> Which are also a bit nasty 23:38:50 <z-MaTRiX> rendering in a buffer 23:38:58 <z-MaTRiX> and then flip that 23:39:00 <TrueBrain> JGR: yup ;) 23:39:08 <TrueBrain> z-MaTRiX: double buffering is commonly used, yes 23:39:11 <Yexo> z-MaTRiX: before you render you need to know which sprites to render 23:39:13 <TrueBrain> but that is to avoid the user seeing a screen being drawn 23:39:27 <Yexo> I think that part is way more expensive than the actual rendering 23:39:54 <TrueBrain> but what Yexo says: you are talking about improving a piece of code that takes no time to execute in the first place 23:39:55 <glx> even dune 2 used double buffering at that time 23:40:07 <JGR> The main point of double-buffering is to have the buffer ready and waiting, as the re-trace occurs, to avoid screen-tearing 23:40:28 <TrueBrain> JGR: to avoid partial screens, yeah 23:41:10 <TrueBrain> can't remember a game which did not do double buffering tbh 23:41:31 <TrueBrain> Alleycat even did ... 23:41:32 <glx> pong ? 23:41:34 <JGR> Some do triple, but I'm not sure how common that is these days 23:41:44 <TrueBrain> these days it is all not that important anymore 23:41:52 <TrueBrain> 3D graphics is another can of shit :D 23:41:58 <TrueBrain> (which is what is used these days ;)) 23:42:12 <TrueBrain> AA 8x draws the screen many times for 1 screen :P 23:42:18 <JGR> The strategy seems to be to just let the card handle it 23:42:19 <TrueBrain> (hihi, now I am pushing it, I know :D) 23:42:34 <TrueBrain> nowedays you send: screen-done-building 23:42:37 <TrueBrain> and it does the swapping for you 23:43:24 * JGR has not done graphical coding for ages 23:43:33 <TrueBrain> but okay; the topic was threading the display part 23:43:45 <TrueBrain> then it heavily depends what you consider 'the display part' 23:43:59 <TrueBrain> in general, there is very little to gain there 23:44:15 <TrueBrain> unless you are doing some high-value up-scaling :P 23:44:24 <TrueBrain> but then you should be caching :D 23:44:31 <JGR> It makes sense if the front end and back end aren't really doing the same thing at all 23:44:40 <TrueBrain> JGR: but when does that happen? 23:44:53 <TrueBrain> well, webservers do, of course 23:44:54 <glx> progress bar ;) 23:45:07 <TrueBrain> a webserver is strictly seen the perfect example of threading the display 23:45:14 <TrueBrain> server sends it to the client, which renders it in its own thread 23:45:17 <z-MaTRiX> i don't get it why are you against multithreading 23:45:22 <TrueBrain> but I am pretty sure that is not what z-MaTRiX is looking for :) 23:45:26 <z-MaTRiX> there is more and more cores in the cpus 23:45:33 <JGR> @ z-MaTRiX, I've written multithreaded code, it's not trivial 23:45:35 <Xaroth> z-MaTRiX: multithreading is a myth 23:45:44 <TrueBrain> z-MaTRiX: who said anyone was against? 23:45:53 <glx> openttd is multithreaded :) 23:45:57 <z-MaTRiX> you are telling it would not be any improvement. 23:46:03 <JGR> Multithreading is useful for parrallelisable algorithms 23:46:04 <TrueBrain> we are just telling you that it is very unlikely you get a gain by threading the display. But for sure it is not _the_ cure in _all_ cases 23:46:09 <glx> but only where it's possible 23:46:16 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has quit [Quit: TschÃŒÃ] 23:46:25 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has joined #openttd 23:46:26 <z-MaTRiX> The drawing function, and the screen flip function can be threaded too 23:46:39 <JGR> No, they can't we just explained that 23:46:44 <TrueBrain> well, clearly we cannot convince you with words, so I wish you the best of luck making it :D 23:46:49 <TrueBrain> I am not telling you you shouldnt 23:46:56 <TrueBrain> I am just telling you it is unrealistic to expect any improvement 23:47:06 <z-MaTRiX> ahm ok :) 23:47:38 <TrueBrain> and I am very alergic to statements like: "will increase performance in all cases," 23:48:06 <z-MaTRiX> well its better than 640kB will be enough for everything ;> 23:48:16 <TrueBrain> which Bill Gates btw never said 23:48:25 <glx> IIRC multithreading experiments were done in openttd, the result was big slow down for single core for a very low improvement for multicore 23:48:41 <TrueBrain> glx: I remember the same :D So it has to be true :P 23:49:14 <TrueBrain> I see posibilities in YAPF to thread ... in Cargodest and stuff .. but in very restrictive ways :) 23:49:28 <z-MaTRiX> well things can be done various ways 23:49:29 <JGR> Hmm, even that is a bit dubious IMO 23:49:57 <z-MaTRiX> a circle's points can be calculated in parallel using 256 processors 23:49:58 <TrueBrain> caching often gives a better improvement (at the expensive of memory) 23:50:16 <TrueBrain> and where in OpenTTD do we do such math? 23:50:27 *** Swissfan91 [~Swissfan9@host-78-145-52-238.as13285.net] has joined #openttd 23:50:29 <z-MaTRiX> didnt say that 23:50:53 <glx> we don't even use floats 23:50:55 <TrueBrain> I calculated the coming and going of weather by using over 100 machines with each 16 cores ... 23:51:04 <JGR> I seem to recall that a previous attempt at improving OpenTTD's performance focused on caching things like height data for each tile corner 23:51:05 <TrueBrain> sure, threading can be very useful. But it doesn't apply to OpenTTD :) 23:51:10 <JGR> I forget where I read that though 23:51:19 <Swissfan91> hi everyone 23:51:19 <TrueBrain> JGR: most of the imrpvoements in OpenTTD come from caching :) 23:51:23 <TrueBrain> or better hash functions :) 23:51:25 *** TWerkhoven [~twerkhove@cpc12-linl7-2-0-cust144.sgyl.cable.virginmedia.com] has quit [Quit: He who can look into the future, has a brighter future to look into] 23:51:33 *** KritiK [~Maxim@95-25-61-199.broadband.corbina.ru] has quit [Quit: Leaving] 23:51:34 <TrueBrain> or just the plain old: improve the algorithm :) 23:51:36 <TrueBrain> hello Swissfan91 :) 23:51:44 <TrueBrain> JGR: some O(N**2) to O(N) goes a long way ;) 23:51:58 <glx> and then we added a VM for AIs ;) 23:52:05 <JGR> Indeed ^^ 23:52:16 <TrueBrain> now _those_ can be threaded .... with a lot of work :D 23:52:19 <JGR> Surely the AIs don't have that big an impact? 23:52:27 <TrueBrain> typical example of closely guarded input/output :) 23:52:29 <Yexo> JGR: they have a very big impact 23:52:32 <TrueBrain> JGR: lolz; they do :D 23:52:41 <JGR> Oh well, I always play without them :P 23:52:44 <TrueBrain> on my machine, 16 AIs can take up to 500ms per tick :D 23:52:55 <TrueBrain> (where a tick normally is 30ms, because of a Sleep of 30ms :P) 23:53:17 <TrueBrain> then again, I did alter the settings a bit :D:D 23:53:33 <z-MaTRiX> or a multithreaded pathfinder ? 23:53:42 <glx> you increased opcode limit TrueBrain ? 23:53:47 <TrueBrain> glx: :D:D 23:54:00 <Swissfan91> can anyone code NewObjects here? 23:54:15 <TrueBrain> z-MaTRiX: there are posibilities there; just VERY limited once. And all tests so far ahve been very negative in result (and by people who know a lot about threading) 23:54:15 <Yexo> z-MaTRiX: can't do that as long as every vehicle depends on on the pathfinding results of all previous vehicles 23:54:17 <JGR> Presumably the current OpenTTD AIs work better than the originals, given that they chew that many more cycles? 23:54:32 <Yexo> JGR: a lot better 23:54:43 <JGR> I've never used the OTTD AI, I must admit 23:54:44 <Yexo> and a lot more versatile 23:54:48 <TrueBrain> JGR: well, those two are strictly not in relation of course :) 23:54:55 <TrueBrain> but they are much more fun :) 23:55:15 <glx> and they don't cheat 23:55:15 <TrueBrain> more cycles does not imply better :D 23:55:27 <JGR> Well, I'd hope that the extra cycles were doing *something* useful :P 23:55:34 <Yexo> depending a lot upon the map type, but I've seen games were very good human players didn't have it easy to beat an AI 23:55:34 <TrueBrain> just they no longer randomly terraform and shit :D 23:55:48 <Xaroth> and hax 23:56:45 <JGR> Hmm, sounds promising 23:56:56 <TrueBrain> and now we are introducing NoGo, a script VM for goals in the game :P 23:57:00 <TrueBrain> even more cycles wasted :P 23:57:19 <JGR> As long as you can turn it off, it's not a problem 23:57:24 <TrueBrain> ^^ 23:57:29 <Yexo> TrueBrain: what was the reason the threading for AIs was removed? 23:57:33 <z-MaTRiX> and what is your opinion of removing the scripting engine from openttd and coding everything in C? 23:57:36 <TrueBrain> Yexo: data-access 23:57:44 <TrueBrain> Yexo: OTTD2SQ 23:57:48 <TrueBrain> Yexo: _current_company 23:57:53 <TrueBrain> want more? :D 23:57:57 <Yexo> nah,that's enough :) 23:58:02 <glx> OTTD2SQ is a nasty one :) 23:58:12 <TrueBrain> OpenTTD is not ready for threads like that. But for sur eit is possible, we have shown that :D 23:58:16 <glx> though if strdup it's result it's ok 23:58:20 <JGR> That one of the landscape arrays? 23:58:21 <TrueBrain> z-MaTRiX: possible; just not userfriendly :) 23:58:32 <TrueBrain> glx: but not 2 threads can do it at the same time ;) 23:58:34 <TrueBrain> so mutexes ;) 23:58:57 <glx> and deadlock risks 23:58:59 <Yexo> z-MaTRiX: when NoAI started you could chose between squirrel and C++ for AIs 23:59:09 <z-MaTRiX> deadlocks are your friend 23:59:11 <TrueBrain> strictly, you can still do an AI in C++ :) 23:59:16 <Yexo> but than we got rid of threads for AIs and the C++ option was no longer viable 23:59:18 <TrueBrain> just nobody can play it :P 23:59:38 <Yexo> you could run it as client in a multiplayer game