Times are UTC Toggle Colours
00:10:02 *** Absurd-Mind [~peter@p54959D5D.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 00:27:39 *** dfox [~dfox@ip-94-113-17-246.net.upcbroadband.cz] has joined #openttd 00:28:06 *** Zuu [~Zuu@h-114-141.A98.priv.bahnhof.se] has quit [Ping timeout: 480 seconds] 00:29:22 *** frosch [~frosch@frnk-590fcd20.pool.mediaWays.net] has quit [Remote host closed the connection] 00:34:34 *** KenjiE20 [~KenjiE20@92.8.73.122] has quit [Quit: WeeChat 0.3.4] 00:36:06 *** DDR [~DDR@d142-179-79-208.bchsia.telus.net] has quit [Read error: Operation timed out] 01:01:06 *** DDR [~DDR@d142-179-79-208.bchsia.telus.net] has joined #openttd 01:05:40 *** DOUK [~KEM@ALyon-158-1-124-69.w90-29.abo.wanadoo.fr] has joined #openttd 01:10:41 *** douknoukem [~KEM@ALyon-158-1-124-69.w90-29.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 01:18:24 *** Intexon [~Intexon@blk-222-147-135.eastlink.ca] has quit [Ping timeout: 480 seconds] 01:18:27 *** Chris_Booth [~Chris_Boo@cpc7-newt30-2-0-cust37.newt.cable.virginmedia.com] has quit [Remote host closed the connection] 01:35:09 *** DanMacK [~DanMacK@206.191.69.149] has quit [Quit: Bye for now!] 01:42:55 *** TinoDidriksen [~TinoDidri@alpha.visl.sdu.dk] has quit [Ping timeout: 480 seconds] 01:43:21 *** TinoDidriksen [~TinoDidri@alpha.visl.sdu.dk] has joined #openttd 02:00:47 *** dfox [~dfox@ip-94-113-17-246.net.upcbroadband.cz] has quit [Ping timeout: 480 seconds] 02:18:12 *** glx [glx@2a01:e35:2f59:c7c0:61ca:4ce:a778:9503] has quit [Quit: bye] 02:44:25 *** Intexon [~Intexon@blk-222-147-135.eastlink.ca] has joined #openttd 03:07:55 *** Intexon [~Intexon@blk-222-147-135.eastlink.ca] has quit [Read error: Operation timed out] 03:30:11 *** elmz [~elmz@184.213-167-126.customer.lyse.net] has quit [Read error: Connection reset by peer] 03:54:28 *** a1270 [~a1270@72-24-233-98.cpe.cableone.net] has quit [Quit: Leaving] 03:58:00 *** Chillosophy [~Chillosop@ip91350749.adsl-surfen.hetnet.nl] has quit [] 03:59:48 *** a1270 [~a1270@72-24-233-98.cpe.cableone.net] has joined #openttd 04:28:25 *** gartral [~gareth@cpe-184-59-169-244.neo.res.rr.com] has joined #openttd 04:28:50 <gartral> is the svn/hg server down or something? or is it just REALLY slow 04:56:02 *** Eddi|zuHause [~johekr@p54B7718A.dip.t-dialin.net] has quit [Remote host closed the connection] 04:56:17 *** Eddi|zuHause [~johekr@p54B77C8A.dip.t-dialin.net] has joined #openttd 04:58:31 *** sla_ro|master [slaco@95.76.27.160] has joined #openttd 05:06:13 *** bryjen [~bryjen@76.92.85.169] has quit [Remote host closed the connection] 05:27:28 *** gartral [~gareth@cpe-184-59-169-244.neo.res.rr.com] has quit [Ping timeout: 480 seconds] 05:28:53 *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has joined #openttd 05:57:41 *** seanbotv20 [~nettles@c122-107-105-232.blktn5.nsw.optusnet.com.au] has joined #openttd 06:11:04 <seanbotv20> Are there any pros out there 06:11:11 <seanbotv20> I can't seem to turn a profit 06:22:33 *** KouDy [~KouDy@ip-94-112-27-160.net.upcbroadband.cz] has joined #openttd 06:35:55 *** Absurd-Mind [~peter@p549582B5.dip0.t-ipconnect.de] has joined #openttd 06:39:38 *** Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has joined #openttd 06:39:42 *** mode/#openttd [+o Alberth] by ChanServ 06:41:14 *** JVassie [~James@92.27.149.231] has joined #openttd 07:07:16 *** Neon [~Neon@dslb-094-219-030-031.pools.arcor-ip.net] has joined #openttd 07:10:16 *** fonsinchen [~fonsinche@brln-4d0cd09c.pool.mediaWays.net] has joined #openttd 07:11:49 *** |Jeroen| [~jeroen@d5152B25B.access.telenet.be] has joined #openttd 07:12:27 *** Chrill [Chrill@ip68-8-120-178.sd.sd.cox.net] has joined #openttd 07:18:54 *** seanbotv20 [~nettles@c122-107-105-232.blktn5.nsw.optusnet.com.au] has quit [Quit: Leaving] 07:51:21 <planetmaker> hm, is there a way to place an object on steep slopes? 08:00:15 *** Absurd-Mind [~peter@p549582B5.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 08:05:56 *** LordAro [~kvirc@host86-149-31-152.range86-149.btcentralplus.com] has joined #openttd 08:17:32 *** LordAro [~kvirc@host86-149-31-152.range86-149.btcentralplus.com] has quit [Ping timeout: 480 seconds] 08:17:38 <Rubidium> planetmaker: prop10 |= 20h + prop15 |= 01h? 08:20:25 <planetmaker> I use both, the flag and callback 08:21:01 <planetmaker> i.e. both bits you suggest are set. But I still get 'slope not suitable' 08:21:27 <planetmaker> and the CB never fails 08:22:42 <Rubidium> I see no checks for slope when callbacks succeed 08:23:17 <Rubidium> have you tried tracing it in OpenTTD? 08:24:08 <planetmaker> not yet. 08:24:32 <planetmaker> I shall dig further. 08:25:19 <Rubidium> I at least didn't implement (or did but took out later) anything to limit steep slopes 08:27:00 *** |Jeroen| [~jeroen@d5152B25B.access.telenet.be] has quit [Quit: oO] 08:27:13 <planetmaker> hm... maybe I've forgotten one slope. I need to check :-) 08:28:42 <planetmaker> hm, yes. Thanks for putting me on the right track 08:29:11 *** Pulec [~pulec@static-cl093181068250.unet.cz] has joined #openttd 08:29:59 <Alberth> slope 08:30:45 <planetmaker> :-) 08:32:04 *** Zuu [~Zuu@h-114-141.A98.priv.bahnhof.se] has joined #openttd 08:32:05 *** Chrill [Chrill@ip68-8-120-178.sd.sd.cox.net] has quit [] 08:46:16 *** Kurimus [Kurimus@dsl-tkubrasgw1-fe21dc00-138.dhcp.inet.fi] has joined #openttd 08:56:48 *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has joined #openttd 09:05:42 *** douknoukem [~KEM@ALyon-158-1-124-69.w90-29.abo.wanadoo.fr] has joined #openttd 09:09:31 *** DOUK [~KEM@ALyon-158-1-124-69.w90-29.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 09:09:33 <Terkhen> good morning 09:12:13 *** frosch123 [~frosch@frnk-590fe594.pool.mediaWays.net] has joined #openttd 09:20:22 <Zuu> good morning Terkhen 09:24:45 <CIA-1> OpenTTD: rubidium * r22396 /trunk/src/ai/ (18 files in 2 dirs): -Document: some AI doxygen stuff 09:31:40 <planetmaker> moin Zuu & Terkhen 09:43:42 *** DDR [~DDR@d142-179-79-208.bchsia.telus.net] has quit [Ping timeout: 480 seconds] 09:46:38 *** Progman [~progman@p57A1BF92.dip.t-dialin.net] has joined #openttd 09:55:36 <planetmaker> is ok to define child sprites for ground tiles (for NewObjects)? 09:55:45 *** DayDreamer [~DayDreame@94.142.234.1] has joined #openttd 09:56:13 <planetmaker> I get some funky glitches: http://imagebin.org/151123 09:58:21 *** DayDreamer [~DayDreame@94.142.234.1] has left #openttd [] 10:02:00 *** Progman [~progman@p57A1BF92.dip.t-dialin.net] has quit [Remote host closed the connection] 10:03:54 *** Progman [~progman@p57A1BF92.dip.t-dialin.net] has joined #openttd 10:15:49 <CIA-1> OpenTTD: rubidium * r22397 /trunk/src/ (20 files in 2 dirs): -Document: some tidbits of the blitter code 10:21:18 *** yorick [~yorick@ip51cd0513.speed.planet.nl] has joined #openttd 10:26:47 *** Chillosophy [~Chillosop@ip91350749.adsl-surfen.hetnet.nl] has joined #openttd 10:30:12 <planetmaker> I still don't quite follow why I get that glitch. Test GRF: http://devs.openttd.org/~planetmaker/patches/ogfx-landscape-nightly-r62M.zip NML-source: http://devs.openttd.org/~planetmaker/patches/company_land.pnml and NFO: http://devs.openttd.org/~planetmaker/patches/ogfx-landscape.nfo 10:30:44 <planetmaker> the specs tell me that a child sprite gets the same bounding box as the parent sprite - which in case of a ground tile should cover the whole ground tile 10:30:57 <planetmaker> But it seems only to cover the extend of a plain ground tile without slope 10:31:55 <planetmaker> On the other hand: specs also tell that I may not set the x and y extend for ground sprites 10:32:00 <planetmaker> nor for child sprites 10:36:52 *** tycoondemon [~ashnohoe@524B73C2.cm-4-4b.dynamic.ziggo.nl] has quit [Ping timeout: 480 seconds] 10:40:00 <Alberth> planetmaker: "..For example increasing the production of the power at the power station?" <-- I would have answered 'yes, the citizens of openttd are very happy with the extra power'. :D 10:40:21 <planetmaker> hu? 10:40:33 <planetmaker> err_no_context ;-) 10:40:35 <Alberth> http://www.tt-forums.net/viewtopic.php?p=944023#p944023 10:41:12 <planetmaker> ah :-) 10:41:59 <Alberth> oh, I should have pasted a bit more. sorry 10:42:40 *** tycoondemon [~ashnohoe@524B73C2.cm-4-4b.dynamic.ziggo.nl] has joined #openttd 10:43:06 <planetmaker> two, three days ago I wrote that, how should I remember when I have even trouble to recall what I wrote yesterday? :-P 10:43:16 * planetmaker hugs Alberth 10:49:03 *** dfox [~dfox@ip-94-113-17-246.net.upcbroadband.cz] has joined #openttd 10:50:05 *** KenjiE20 [~KenjiE20@92.8.73.122] has joined #openttd 10:53:24 <fonsinchen> distyacd works nice. 10:55:11 <fonsinchen> only the destination lists in the town an industry GUIs need some care so that they don't overflow ... 10:55:26 <fonsinchen> but that should be a problem with plain YACD, too. 11:02:12 <CIA-1> OpenTTD: rubidium * r22398 /trunk/src/network/ (4 files in 2 dirs): -Codechange: remove some defines from the tcp/admin code, so doxygen can create better documentation 11:04:55 *** KritiK [~Maxim@95-24-157-8.broadband.corbina.ru] has joined #openttd 11:05:18 *** Chris_Booth [~Chris_Boo@cpc7-newt30-2-0-cust37.newt.cable.virginmedia.com] has joined #openttd 11:09:27 <michi_cc> fonsinchen: Yes, some scrollbar and/or collapsible entries are definitely required for compatibility with smaller screens. 11:09:50 <fonsinchen> Or with excessively long lists of destinations ;) 11:10:32 <fonsinchen> You might want to have a look at my repository. Especially the refactoring of link weight modifiers would look good in yacd, too. 11:12:20 * Zuu thinks about a generic filter for lists in OpenTTD. Or perhaps something SQL-ish. :-) 11:13:05 <Zuu> To start, each object type (eg. vehicles, towns, industries etc) would need a list of properties that can be filtered. 11:13:26 <CIA-1> OpenTTD: rubidium * r22399 /trunk/src/network/ (4 files in 2 dirs): -Codechange: replace some defines in the tcp/content code so doxygen can create better documentation 11:13:47 <Zuu> Operations like SUM(col_name) etc. would also be useful :-) 11:14:22 *** Wolf01 [~wolf01@host41-233-dynamic.14-87-r.retail.telecomitalia.it] has joined #openttd 11:14:33 <Zuu> But a simple SQL implementation might be to advanced for the average OpenTTD player? 11:14:41 <Zuu> too* 11:14:58 * Alberth proposes to replace OpenTTD with a spreadsheet with numbers 11:15:14 * Zuu likes 11:15:46 <Rubidium> Alberth: OpenTTD's output can easily be put into a spreadsheet 11:16:17 <Alberth> indeed, and the iterative simulation can be done too, no need to display any graphics 11:16:22 <Zuu> In my last game I had problem keeping track of all different routes (shared orders groups) that served each station. 11:16:41 <Rubidium> just make the cells as small as possible while still visible (preferably square), and then color the cells appropriately. Maybe you need to zoom out for the required effect. 11:16:42 <Wolf01> hello 11:17:38 <Alberth> hello Wolf01 11:18:09 <Alberth> Rubidium: good exercise for the office, make a row of 1's that travel in a circle in your spread sheet 11:18:59 <Zuu> With a lot of vehicles serving a station, it is non-trivial to figure out which stations/vehicle routes that service that station. 11:19:04 <michi_cc> fonsinchen: Indeed, most of it makes sense. I'm going to include that into the matching commits if you don't mind. And probably some of your minimap graph stuff as well (or maybe from the old cargodest, have to see what is easier to reuse). 11:19:30 <fonsinchen> I don't mind at all. Go ahead 11:20:12 <fonsinchen> Also you might want to look at the "capacities" branch. That's where I do my version of prefilling orders/routes. 11:20:27 <fonsinchen> I think there are some corner cases you haven't covered yet. 11:21:01 *** romazoon [romazoon@84.102.63.81.cust.bluewin.ch] has joined #openttd 11:21:13 <fonsinchen> and eventually people will ask for something like my ext-rating. But maybe that shouldn't be part of yacd. 11:23:56 *** ndh [~opera@dslb-088-074-006-199.pools.arcor-ip.net] has joined #openttd 11:25:45 <michi_cc> Yeah, I could handle deterministic conditional orders, even if the route links will still be created when the vehicle actually travels. 11:26:16 <ndh> hello, is there a specific channel for developers? i'm trying to port the old Train Counter patch to 1.1.0 11:26:55 <Yexo> feel free to ask any questions you have in this channel 11:27:06 <ndh> ok 11:27:29 <fonsinchen> Another thing people were complaining about in cargodist was that links timed out while a vehicle was still full loading. 11:28:16 <fonsinchen> I solved that with the "Refresh" thing where I periodically reset the timeout while vehicles are loading. 11:28:40 <fonsinchen> That would translate to setting the timeout to some "max_timeout - X" for yacd. 11:28:52 <fonsinchen> But maybe you should wait until the problem arises ... 11:30:15 <CIA-1> OpenTTD: rubidium * r22400 /trunk/src/network/ (6 files in 2 dirs): -Codechange: replace some defines in the tcp/game code so doxygen can create better documentation 11:30:21 <ndh> in rail_cmds.cpp there's a vehicle_enter_tile_proc callback, VehicleEnter_Track. i'm trying to set increment the counter of the waypoint when a train enters there, but IsRailWaypointTile(tile) apparently never returns true. here's the code http://pastebin.com/QP0PkSvP 11:30:48 *** pugi [~pugi@p4FCC1F29.dip.t-dialin.net] has joined #openttd 11:30:56 <Rubidium> waypoints aren't rail tiles anymore 11:31:52 <ndh> i don't know what that means... how do i find out if a tile is a waypoint? 11:32:28 <ndh> i tried IsRailWaypoint(), but the assertion in GetStationType() failed 11:33:14 <Alberth> there are different tile types, depending on that type a different callback is called. Perhaps look at what tile type is used when building a waypoint? 11:33:28 <Terkhen> check the preconditions of IsRailWaypoint() 11:33:40 <Yexo> waypoints use MP_STATION, not MP_RAIL 11:33:42 <Alberth> better :) 11:34:09 <Yexo> IsRailWaypoint has as precondition that the tile is of the type MP_STATION, IsRailWaypointTile has that check included in the function 11:34:28 *** Adambean [AdamR@82.hosts.reece-eu.net] has joined #openttd 11:34:42 <ndh> oh ok, do you mean that the vehicle_enter_tile_proc isnt even called for waypoints, since the type is station? 11:35:00 <Yexo> indeed, it's only called for tiles with tile type MP_RAIL 11:35:11 <Rubidium> at least not the one in rail_cmd.cpp 11:35:12 <ndh> alright, thanks 11:35:19 <Yexo> VehicleEnter_Station in station_cmd.cpp is the correct function 11:36:05 <ndh> cool, thanks 11:36:27 *** glx [glx@2a01:e35:2f59:c7c0:f1f7:c0f6:f53c:c79e] has joined #openttd 11:36:30 *** mode/#openttd [+v glx] by ChanServ 11:39:15 <ndh> yay it works :) thanks guys 11:41:13 *** DOUK [~KEM@ALyon-158-1-124-69.w90-29.abo.wanadoo.fr] has joined #openttd 11:42:06 *** Mazur [~mazur@5ED2BEAE.cm-7-3c.dynamic.ziggo.nl] has quit [Remote host closed the connection] 11:45:07 *** ZirconiumX [561b9caa@ircip4.mibbit.com] has joined #openttd 11:45:36 *** douknoukem [~KEM@ALyon-158-1-124-69.w90-29.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 11:49:12 <ndh> btw, vehicle_enter_tile_proc isn't called only once when a vehicle enters a tile, is it? 11:54:23 <Yexo> IIRC you're right, it's called multiple times per tile 11:54:33 <Yexo> but I'm not really sure, didn't check just now 11:56:30 *** fonsinchen [~fonsinche@brln-4d0cd09c.pool.mediaWays.net] has quit [Ping timeout: 480 seconds] 11:57:52 <ZirconiumX> What is the maximum number of towns a map can have? 11:58:24 <Zuu> Try to write a huge number in custom town amount :-) 11:59:17 *** romazoon [romazoon@84.102.63.81.cust.bluewin.ch] has quit [Ping timeout: 480 seconds] 11:59:44 <Yexo> ZirconiumX: limited by the minimum distance between towns and the map size 12:00:18 <Yexo> the actual limit in the code is 64000 towns, but you won't be able to reach that on a 2048x2048 map 12:02:30 *** frosch123 [~frosch@frnk-590fe594.pool.mediaWays.net] has quit [Ping timeout: 480 seconds] 12:04:05 <ZirconiumX> Is there an <easy> way to optimise the A* pathfinder 12:04:19 <ZirconiumX> I think WmDOT did it with a Fibbonacci heap 12:05:09 <planetmaker> :-) A* is already an optimized PF. The question is by which criteria you want a PF optimized 12:05:25 <ZirconiumX> speed 12:05:48 <Yexo> do you want a perfect path or does that not matter so much? 12:05:48 <Zuu> You can reduce how much it will search for different paths. 12:05:52 <planetmaker> then use 'drive straight unless not possible' 12:06:27 <ZirconiumX> Yexo: as long as it connects the towns - I don't care 12:06:31 <planetmaker> but it might not find the destination then ;-) 12:06:31 <Alberth> ZirconiumX: didn't you have a fast D* ? 12:06:35 <Zuu> Original Clueless had a pathfinder that drove stright until it hit an obstacle, turned 90 degrees and continued. :-) 12:06:54 <ZirconiumX> I haven't finished it yet - you could barely say I've started it 12:07:36 <ZirconiumX> I've heard you can play around with the _Cost function of the RoadPF 12:08:10 <Zuu> I've experimented slightly with a pathfinder that would use a straight line between the origin and destination and identify obstacles that this line hit and generate a path around these obstacles. This can be found in wayfinder.nut in CluelessPlus, but I've not reall come very far with it. 12:08:17 *** frosch123 [~frosch@frnk-4d008758.pool.mediaWays.net] has joined #openttd 12:08:28 <Alberth> yes, by overestimating costs, it explores less alternatives but paths may be less optimal 12:08:29 <Zuu> really* 12:09:13 <Yexo> ZirconiumX: simplifying the Cost function might give some speedup, also making Estimate return a higher value that necessary 12:09:44 <Zuu> Its a good idea to play around both with _Cost and the function that creates neighbours. For example to find paths that use a bridge to cross railway, canals etc. 12:10:38 *** Intexon [~Intexon@blk-222-147-135.eastlink.ca] has joined #openttd 12:10:58 <Zuu> Though, these kind of things will make the pf slightly slower per iteration - though in some cases it might find a path in less iterations. 12:11:17 <ZirconiumX> Yexo & Zuu: local cost = RoadPathFinder._Cost x 1.1 <---- Will that help? 12:11:23 *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has quit [Remote host closed the connection] 12:11:42 <Zuu> (bridging canals that is - bridging rail is not faster as in terms of building, just makes your trucks survive better ;-) ) 12:12:58 <Alberth> ZirconiumX: http://www-cs-students.stanford.edu/~amitp/gameprog.html#paths 12:13:11 <Zuu> ZirconiumX: I don't know as I don't keep those details in my memory. I would have to read up on the different costs in a documentation before fiddeling with them. 12:13:55 <Alberth> ZirconiumX: it's a very useful site imho, in the past I have found it fun reading it 12:14:48 <ZirconiumX> what is the DorpsGek function for factorials? 12:15:18 <Yexo> @calc 5! 12:15:18 <DorpsGek> Yexo: Error: unexpected EOF while parsing (<string>, line 1) 12:15:26 <Yexo> no idea 12:15:34 *** aber [~Adium@HSI-KBW-091-089-050-150.hsi2.kabelbw.de] has joined #openttd 12:15:50 <Zuu> Why not use stand-alone calculator program or physical calculator? 12:16:28 <ZirconiumX> Hmmm 12:16:42 * ZirconiumX uses the built in calculator called the Brain 12:16:56 <planetmaker> @calc factorial(5) 12:16:56 <DorpsGek> planetmaker: Error: 'factorial' is not a defined function. 12:17:50 <Alberth> planetmaker: 120 12:17:56 <planetmaker> :-) 12:18:12 <ZirconiumX> number of calculations possible = 64000 ^ 63999 + 64000 ^ 63998 + 64000 ^ 63997 ... - 1 12:18:24 <ZirconiumX> Zuu: that's why 12:18:35 <planetmaker> @albert sin(sqrt(exp(i**sqrt(2)))) 12:18:43 * planetmaker wonders if that works :-P 12:18:47 <CIA-1> OpenTTD: rubidium * r22401 /trunk/src/network/ (core/packet.h core/udp.cpp core/udp.h network_udp.cpp): -Codechange: replace some defines in the udp code so doxygen can create better documentation 12:19:17 <ZirconiumX> @calc sin(sqrt(exp(i**sqrt(2)))) 12:19:17 <DorpsGek> ZirconiumX: 0.655543174835+0.225407719727i 12:19:33 <ZirconiumX> planetmaker: there's your answer 12:20:50 <Zuu> I usually hit Win+R and type calc whenever I need a calculator. So at the end of the day I may end up with 3-5 calculator instances :-) 12:21:26 <ZirconiumX> @myself 4**(4**(4**(4**9))) 12:21:34 <ZirconiumX> ZirconiumX: I don't know 12:21:46 <ZirconiumX> the brain needs improving it seems 12:21:52 <CIA-1> OpenTTD: rubidium * r22402 /extra/masterserver_updater/src/ (7 files in 3 dirs): [MSU] -Fix: compilation after changes in trunk 12:22:58 *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has joined #openttd 12:23:07 <ZirconiumX> lol 12:23:11 <ZirconiumX> bc:Runtime error (func=(main), adr=18): exponent too large in raise 12:23:14 <ndh> http://www.google.com/search?q=5%21 12:23:15 <ZirconiumX> too big 12:24:12 <ZirconiumX> you can't ! the answer to life the universe and everything 12:24:14 <ZirconiumX> 42 ! = 1.40500612 Ã 1051 12:24:27 <ZirconiumX> 10^51 12:26:03 * Alberth helps ZirconiumX a little bit: 4**(4**9) is http://devs.openttd.org/~alberth/number.txt 12:26:17 <ndh> http://www.wolframalpha.com/input/?i=42%21 12:27:16 <ZirconiumX> I'm trying to see if bc can do it 12:28:26 <ZirconiumX> it failed at the last hurdle 12:30:51 * ZirconiumX is going to kill my computer 12:35:00 * Alberth provides a sledge hammer to assist 12:35:26 <ZirconiumX> I'm computing pi to 10000 places 12:35:43 <ZirconiumX> and I only have 1Ghz to do it with 12:36:18 <ndh> does it even make sense to increment the SAVEGAME_VERSION by 1 in a patch? 12:36:58 <ndh> shouldnt it be set to something special like SL_MAX_VERSION or sth? 12:39:07 <Alberth> ZirconiumX: but the computer already knows the value: ð <-- see? 12:39:46 <ZirconiumX> 01D6D1 is all that it says 12:40:04 <Alberth> you are missing a few fonts then :) 12:41:45 <Alberth> ndh: several values make sense afaik, although SL_MAX_VERSION is unlikely to be one of them 12:41:55 <ndh> xD 12:41:58 <Alberth> +1 are steps done in trunk 12:42:39 <Alberth> +more can be used to maintain compability between your patch and several trunk versions 12:42:40 <ndh> yea exactly, but if someone uses a patch, it's probably not going to be compatible with the next version used in trunk 12:43:06 <Ammler> Zuu: on KDE, you don't need a calc, you just type the formula and get the answer ;-) 12:43:49 <Alberth> ndh: that even holds for patches that do not increment save game versions :) 12:43:52 <Zuu> sounds useful as the calc keyboard UI sucks. 12:44:11 <Zuu> It can't for example handle / if it is on a Alt+Gr key. 12:44:36 <Ammler> wow, it is in your layout? 12:44:44 <Zuu> Yep 12:44:50 <Zuu> Alt Gr + o 12:45:11 <Zuu> (O is on qwerty S) 12:46:26 <ndh> if someone saves a game from a patched exe, it shouldn't be possible to load that game from an official version, so wouldnt SL_MAX_VERSION make the most sense? 12:46:48 <Ammler> sometimes, I wonder, why it is alt gr and not just alt 12:47:00 <Ammler> so you could use the left one too 12:47:06 <Rubidium> ndh: eventually SL_MAX_VERSION will get increased as well 12:47:12 <Zuu> But then you would lose Alt for menues etc. 12:47:27 <ZirconiumX> Ammler: because it's angry 12:47:40 <ndh> Rubidium, yea, it seems kinda low 12:48:32 *** romazoon [romazoon@84.102.63.81.cust.bluewin.ch] has joined #openttd 12:48:56 <Alberth> ndh: and it doesn't help, if you have 2 patched exes (with different patches applied), they would both accept each others save games 12:49:06 <Zuu> But yes, one of the main criterias I use when buying a laptop is that the alt + gr key is not to far to the right as that would mean bending your thumb in a way to akward position. 12:52:05 <ndh> Alberth, true, but at least it wouldn't be possible to crash an official version with it :) 12:52:35 <planetmaker> ndh: OpenTTD should not crash but just complain about invalid chunks 12:53:23 *** amkoroew1 [~Heinz@p5B1042E6.dip.t-dialin.net] has joined #openttd 12:55:12 <ndh> ^^ 12:58:36 *** amkoroew [~Heinz@p5B104D42.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 13:02:02 *** sla_ro|master [slaco@95.76.27.160] has quit [Quit: Mutant Co-Op - C&C Renegade] 13:08:00 <Markk> Can't you transport oil i planes anymore? 13:08:44 <planetmaker> could you ever? 13:09:02 <Markk> I think so. :o 13:10:23 <xQR> i think i remember it was possible in the past to refit planes for oil, but that got removed a quite long time ago 13:10:39 <xQR> maybe it was 0.6.3 or something where that still was possible 13:10:46 <Markk> Oh, that sucks then. :D 13:10:50 <Markk> Too oldskool here. 13:11:53 <Markk> I remember 0.4.7. 13:11:57 <xQR> hey planetmaker my C# implementation of the admin interface is making progress :) 13:12:05 <planetmaker> good :-) 13:12:06 <xQR> http://www.boxxor.net/pics/ottdi.png 13:12:09 <xQR> http://www.boxxor.net/pics/ottdi-company.png 13:12:50 <xQR> though that program is only to test the classes, so i can see whether utilizing it from an application really works 13:14:09 <xQR> in the end i went with just reading the openttd source, imho it has a better documentation than joan or that python implementation 13:19:51 <Rubidium> yeah, especially tcp_admin.h's documentation is meant for those trying to implement the protocol 13:20:10 <xQR> yep, i found the info in there is absolutely sufficient 13:20:48 <xQR> and if in doubt you can still always check the source to see what he really expects when receiving a packet or what he does when sending one 13:26:05 <ndh> does openttd use threading? 13:26:47 <Rubidium> ndh: yes 13:27:20 * Rubidium now expects some question why something doesn't happen while it's being said that OpenTTD uses threading 13:28:22 <ndh> well i was just wondering if i have to pay attention to synchronize stuff 13:29:19 <ndh> does the GUI run in a different thread than e.g. the pathfinder or sth? 13:30:03 <CIA-1> OpenTTD: rubidium * r22403 /trunk/src/network/core/ (9 files): -Document: some more network/core code 13:31:55 *** douknoukem [~KEM@ALyon-158-1-124-69.w90-29.abo.wanadoo.fr] has joined #openttd 13:32:31 <planetmaker> mostly not 13:35:01 * Rubidium loves meta questions 13:37:40 <planetmaker> hehe 13:38:21 *** DOUK [~KEM@ALyon-158-1-124-69.w90-29.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 13:39:04 <ndh> :) it's just that from work i'm used to have the GUI run in a different thread, so special care has to be taken when displaying stuff so that it won't get changed during a drawing call 13:40:41 <Rubidium> it's just that if you asked whether a particular part requires synchronisation we could give a better answer 13:41:38 <Rubidium> e.g. drawing sometimes runs in a different thread: but... that's only during map generation when there's only a single window on the screen. Thus for all other windows it doesn't happen 13:42:44 <ndh> is that what _draw_threaded is for? 13:44:03 <Rubidium> on the other hand... on at least Linux the blitting happens in another thread. However, that prepares everything synchronised and then does the drawing while the other thread runs the game state and that has no influence on the stuff that's going to be drawn 13:44:29 <ndh> i see 13:44:34 <Rubidium> and as such the *actual* drawing code the you're working on runs in the same thread as the code that modifies the game state 13:45:19 <ndh> ok, thank you 13:46:23 <Rubidium> likewise with savegame stuff. It quickly makes a snapshot and then starts a thread for compressing that, so it doesn't burden any other code with threading issues 13:46:58 <Rubidium> (well, except a bit of the networking code but that's by design as it means it can start sending the savegame sooner so joins are significantly faster now) 13:49:19 *** APTX_ [APTX@89-77-188-241.dynamic.chello.pl] has joined #openttd 13:50:46 *** APTX [APTX@89-77-188-241.dynamic.chello.pl] has quit [Remote host closed the connection] 13:51:42 *** sla_ro|master [~slaco@95.76.27.160] has joined #openttd 14:11:46 *** ZirconiumX [561b9caa@ircip4.mibbit.com] has quit [Quit: http://www.mibbit.com ajax IRC Client] 14:23:07 *** andythenorth [~Andy@213.99.112.87.dyn.plus.net] has joined #openttd 14:41:15 *** aber1 [~Adium@HSI-KBW-091-089-050-150.hsi2.kabelbw.de] has joined #openttd 14:41:15 *** aber [~Adium@HSI-KBW-091-089-050-150.hsi2.kabelbw.de] has quit [Read error: Connection reset by peer] 14:54:26 <ndh> does the generate project recreate the .vcxproj file? 14:54:59 <ndh> and unset my include/lib dir? 14:56:09 <glx> include/lib dir should not be in vcxproj 14:56:53 <ndh> it kinda does 14:57:12 <glx> that's a VC2010 feature I don't like 14:57:13 <ndh> where should it be then? 14:57:23 <ndh> it does make sense though 14:57:36 <glx> yes it does 14:57:41 <ndh> anyways 14:58:00 <ndh> is there a global setting in 2010? 14:58:19 <glx> but previous version used to have vcproj.user for that 15:00:02 <glx> check property manager 15:00:05 <Terkhen> ndh: http://www.tt-forums.net/viewtopic.php?f=33&t=54292 15:05:03 *** Vadtec_ [vadtec@i.am.vadtec.net] has joined #openttd 15:06:07 *** Vadtec [vadtec@i.am.vadtec.net] has quit [Remote host closed the connection] 15:06:07 *** Vadtec_ is now known as Vadtec 15:06:50 *** sigue [contempt@stole.ur.cc-number.info] has quit [Remote host closed the connection] 15:09:56 <ndh> ok got it, thanks 15:10:34 <ndh> the files in projects/ don't need to be included in patches, right? 15:11:54 *** Chris_Booth [~Chris_Boo@cpc7-newt30-2-0-cust37.newt.cable.virginmedia.com] has quit [Read error: Connection reset by peer] 15:12:28 *** Chris_Booth [~Chris_Boo@cpc7-newt30-2-0-cust37.newt.cable.virginmedia.com] has joined #openttd 15:13:16 <Yexo> ndh: doesn't matter much, but feel free to include also those changes 15:13:48 *** DOUK [~KEM@ALyon-158-1-124-69.w90-29.abo.wanadoo.fr] has joined #openttd 15:19:25 *** fonsinchen [~fonsinche@brln-4d0cd09c.pool.mediaWays.net] has joined #openttd 15:19:28 *** douknoukem [~KEM@ALyon-158-1-124-69.w90-29.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 15:19:38 *** sigue [contempt@stole.ur.cc-number.info] has joined #openttd 15:22:05 *** KenjiE20 [~KenjiE20@92.8.73.122] has quit [Remote host closed the connection] 15:22:59 *** KenjiE20 [~KenjiE20@92.8.73.122] has joined #openttd 15:23:20 *** pugi [~pugi@p4FCC1F29.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 15:23:37 *** pugi [~pugi@p4FCC5E35.dip.t-dialin.net] has joined #openttd 15:25:36 *** HerzogDeXtEr1 [~Flex@i59F6CBA5.versanet.de] has joined #openttd 15:30:58 *** HerzogDeXtEr [~Flex@88.130.191.179] has quit [Ping timeout: 480 seconds] 15:33:10 *** KouDy1 [~KouDy@ip-94-112-27-160.net.upcbroadband.cz] has joined #openttd 15:33:50 *** KouDy1 [~KouDy@ip-94-112-27-160.net.upcbroadband.cz] has quit [] 15:44:06 *** Devroush [~dennis@178-119-81-33.access.telenet.be] has joined #openttd 16:00:45 *** andythenorth [~Andy@213.99.112.87.dyn.plus.net] has quit [Quit: andythenorth] 16:01:09 *** benj014 [~benj014@cpc2-shep7-0-0-cust198.8-3.cable.virginmedia.com] has joined #openttd 16:02:25 <benj014> Hi everyone 16:03:09 <planetmaker> hi 16:04:05 <benj014> hope your ok :-) 16:04:33 <benj014> im new to all this and im looking for some help 16:05:30 <benj014> or direction :-) 16:06:07 <benj014> with regards to downloads and update 16:07:09 <planetmaker> in what way? 16:07:30 *** andythenorth [~Andy@213.99.112.87.dyn.plus.net] has joined #openttd 16:07:31 <ndh> http://www.openttd.org/en/download-stable 16:07:38 <planetmaker> Get the installer from openttd.org and then extensions, if you want some mods, via ingame content download 16:08:16 <planetmaker> I suggest though, to start first without mods 16:08:24 <planetmaker> and get a feel of how the game works 16:09:02 <benj014> oh sorry had the game for ages -- lookin for help with mods and 32bpp update lol 16:09:15 <benj014> im on a mac tho 16:10:11 <Yexo> openttd supports 32bpp graphics out of the box, if you're looking for the extra-zoom project you should say so 16:10:42 <Yexo> also: when you say "mods", are you talking about patches to the source code or about NewGRFs? 16:11:26 <benj014> i got the extra zoom working - but could not use any NewGRFs 16:11:52 <Yexo> you can only change newgrfs in the main menu 16:12:19 <benj014> it would not find any on the 32bpp 16:12:29 <Yexo> 32bpp tars are not newgrfs 16:13:57 * andythenorth wonders if there's a better term than "Engineering Supplies" 16:14:10 <andythenorth> english is quite flexible...other languages apparently less so 16:15:21 <Alberth> what are they? 16:15:33 <benj014> when i was on the 32bpp i could not use any GRF's - so had all the old trains and stuff - im looking to get better trains and graphics if that makes sence 16:15:37 <andythenorth> stuff you need to dig stuff up mostly 16:15:54 <andythenorth> machinery, parts, fabricated structures, fuel, wooden structures 16:15:59 <frosch123> "Heavy Equipment" 16:16:14 <planetmaker> oh, hi andythenorth 16:16:21 <Yexo> benj014: where is your openttd.cfg? 16:16:54 <Yexo> if it's in the installation directory of your old installation, move it to "Documents/OpenTTD" 16:17:24 <Yexo> all newgrfs/savegames/scenarios/AIs should go there too, that way they can be used by all installations you have 16:18:45 *** supermop [~daniel_er@cpe-67-243-25-39.nyc.res.rr.com] has joined #openttd 16:19:00 <Alberth> andythenorth: I'd call it mining equipment 16:19:32 * andythenorth ponders 16:19:38 <benj014> Yexo - sorry wots a cfg 16:19:45 <planetmaker> andythenorth: supplies is a generic word as can be. That is intrinsically difficult to translate 16:19:55 <Zuu> benj014: A file with the .cfg extension. 16:19:59 <Yexo> benj014: just search for a file called "openttd.cfg" 16:20:12 *** fonsinchen [~fonsinche@brln-4d0cd09c.pool.mediaWays.net] has quit [Ping timeout: 480 seconds] 16:20:13 <planetmaker> But IMHO it should not be your (main) concern, but spark the creativity of the translators 16:20:30 * andythenorth returns to current main concern 16:20:33 <andythenorth> playing YACD 16:20:37 <planetmaker> it would either be, benj014 with your openttd.app or in ~/Documents/OpenTTD 16:20:54 <planetmaker> usually at least :-) 16:21:25 <supermop> hello 16:22:25 <planetmaker> hi supermop 16:22:43 <Eddi|zuHause> what's the town size that a town accepts noise level 4 (with 'tolerant')? 16:22:53 <benj014> its with my original ttd folder 16:23:28 <Yexo> is openttd.app also there? 16:23:43 <benj014> yeah 16:23:47 <Eddi|zuHause> a large city near a small town should influence their noise level 16:24:08 <benj014> then the 32bpp is in a new folder - called ttd2 16:24:11 <Yexo> and also directories called "save", "scenario", "downloaded_content" and "data"? 16:24:24 <benj014> yeah 16:24:38 <Yexo> move openttd.cfg and those directories to ~/Documents/OpenTTD/ 16:24:48 <Yexo> that way they are shared between all your openttd installations 16:25:20 <Yexo> also move "gm" if you have it and want the music to work 16:25:40 <benj014> yeah moved that already 16:27:13 <supermop> I am thinking of buying a bonsai tree. 16:27:31 <supermop> I was reflecting on how it is similar to my current long running game 16:28:54 <benj014> still no grfs 16:29:25 <Yexo> benj014: and if you download a few newgrfs via the online content system in your 32bpp version, do those show up? 16:29:51 * andythenorth thinks mail in YACD is much like real life 16:30:02 <andythenorth> a postal service is only truly useful if every node is connected 16:30:17 *** frosch [~frosch@frnk-590fe28e.pool.mediaWays.net] has joined #openttd 16:30:25 <benj014> no :-( - i go onto new grfs .. look for new content but nothing there 16:30:25 <supermop> does intra-city bus and metro service work in yacd? 16:30:34 <andythenorth> better than before 16:30:44 <supermop> better than in CD? 16:30:50 <andythenorth> didn't try CD 16:32:13 * andythenorth wishes towns didn't shrink when serviced 16:32:24 <andythenorth> I thought I raised a FS about that months ago, but can't find it 16:32:45 <supermop> people using your great service to get the hell out of town 16:32:47 <Rubidium> might it be the town newgrf you're using that's causing that? 16:32:50 <andythenorth> no 16:33:15 <andythenorth> providing service causes the town to start rebuilding, but it rebuilds with smaller buildings 16:33:29 <andythenorth> I can reproduce it I reckon 16:33:43 <andythenorth> it seems worse < 1900 16:33:46 <andythenorth> or maybe 1930 16:33:53 <benj014> and then on the 32bpp the GFX graphic option also is not there 16:33:53 <andythenorth> and it seems worse with ships, but can't be sure 16:34:09 <supermop> everyone migrating away, call it realism 16:34:19 <Yexo> <benj014> and then on the 32bpp the GFX graphic option also is not there <- which gfx graphic option? 16:34:38 <Yexo> benj014: where did you download your 32bpp version? what is the version number? 16:36:01 <andythenorth> last time I got interested in the town problem, I tried to figure out why town-growth mechanism is selecting different buildings to map gen 16:36:06 <andythenorth> but I didn't find an obvious answer 16:36:17 <benj014> on my original game - in game options i can choose the graphics set - GFX gives me better looking roads and tracks etc 16:36:38 *** frosch123 [~frosch@frnk-4d008758.pool.mediaWays.net] has quit [Ping timeout: 480 seconds] 16:37:18 <Yexo> ah, you mean "OpenGFX" 16:37:30 <Yexo> benj014: again, which version is your 32bpp build? 16:37:53 <Yexo> just giving a link to the location you downloaded it from is also ok 16:38:12 <benj014> got it from www.lemonamiga.com - for mac's - version r9538-32bpp 16:38:24 <Yexo> r9538 is ancient 16:38:37 <Yexo> that's 4 year old or something like that 16:38:38 <andythenorth> http://tt-foundry.com/misc/ship_towns_1870.png/ 16:38:42 <andythenorth> http://tt-foundry.com/misc/ship_towns_1878.png/ 16:38:43 <__ln__> it's pre-cake1 16:38:48 <benj014> oh thats the only mac one i could find 16:38:48 <Yexo> yes :o 16:39:01 <andythenorth> ^^^^ basically the large blocks of flats are replaced with smaller buildings 16:39:03 <Yexo> it'll be hard to find any newgrfs that work in that version 16:40:05 <benj014> cool thanks 16:40:06 <Yexo> benj014: download a newer version here: http://bundles.openttdcoop.org/32bpp-ez/LATEST/ 16:40:51 <Yexo> and more in general you'll find updated information on the forum: http://www.tt-forums.net/viewforum.php?f=36 16:41:14 <Yexo> and the relevant wiki page: http://wiki.openttd.org/32bpp_Extra_Zoom_Levels 16:41:38 <planetmaker> andythenorth: that's just the normal fluctuation 16:41:38 <andythenorth> bbl 16:41:45 <planetmaker> replace one house by another, that's it 16:41:49 <andythenorth> planetmaker: I think it's unhelpful 16:41:57 <andythenorth> but got to go :) 16:42:00 <andythenorth> bbl 16:42:02 *** andythenorth [~Andy@213.99.112.87.dyn.plus.net] has left #openttd [] 16:43:13 <benj014> so do i just down load the ones for mac ? 16:43:35 <Yexo> only this one: http://bundles.openttdcoop.org/32bpp-ez/LATEST/openttd-32bpp-ez-1.1.0-macosx-universal.zip 16:43:36 <benj014> and then what do i do with them ? sorry im not the most techincal person 16:43:53 <Yexo> you extract the zip and run whatever you find inside 16:45:41 <benj014> cool thank you 16:45:49 <benj014> just downloaded 16:46:38 <benj014> so take it i have to copy all the data folders and the gm again 16:46:53 <Yexo> no 16:47:11 <Yexo> as long as they are in ~/Documents/OpenTTD/ they can be used by every version of OpenTTD you install 16:47:24 <planetmaker> if you kept it in ~/Documents/OpenTTD you can keep it forever for all versions 16:47:36 <planetmaker> at least which exist so far ;-) 16:48:21 <benj014> ahhh im confussed 16:52:00 *** Mazur [~mazur@5ED2BEAE.cm-7-3c.dynamic.ziggo.nl] has joined #openttd 16:54:59 <benj014> yay got it workin .. thank you very much 16:55:21 <supermop> Ok, weather is too nice, I am going outside 16:56:22 <ndh> there's no list window with all waypoints in the game, is there? 16:57:18 <Yexo> benj014: your post on the forum was removed because on www.lemonamiga.com it's not clear where to find anything related to openttd 16:57:38 <Yexo> also next time please state more clear was you actually tried and _what exactly_ does not work 16:58:40 <benj014> found new trains on www.amitrains.co.uk wot do i do with the down loads ... sorry yexo i will try to be more specific 16:58:56 <welshdragon> benj014, they're not for OpenTTD 16:59:01 *** Sacro [~ben@cpc2-mfld9-0-0-cust880.13-1.cable.virginmedia.com] has joined #openttd 16:59:03 <benj014> ah 16:59:19 <benj014> thank you 17:00:19 <benj014> so you know when people say they have made a new set of trains on the forums .. can they be found in NewGRFs ? 17:00:26 <welshdragon> yes 17:00:48 <Yexo> usually those same people will also upload a grf file to the forums 17:01:38 <benj014> cool 17:01:47 <benj014> thanks for the help 17:05:49 *** benj014 [~benj014@cpc2-shep7-0-0-cust198.8-3.cable.virginmedia.com] has quit [Quit: Bye for now!] 17:10:25 *** Devroush [~dennis@178-119-81-33.access.telenet.be] has quit [] 17:19:57 * Zuu just gave CluelessPlus a slightly more human behaviour by limiting new connections to be constructed near existing ones. 17:20:48 <Zuu> In a first test with two CluelessPlus instances against eachother, the one with this limitation performs not as good in terms of profit, but is still working good. 17:22:16 <Zuu> So the question is, shall the AI default settings be for AI battles (no limit) or for humans (limits on) 17:22:56 <Zuu> The AI without limits is about 40-60% better than the limited one. 17:23:25 <Zuu> (on a 256x2048 map) 17:23:49 <Zuu> (or if it was even 128x2048) 17:27:59 * Zuu decides to have the limit enabled for easy, medium and disabled for hard and custom. Most AI-battles will probably use custom dificulty. 17:31:52 <planetmaker> I wonder how many games actually are rather custom difficulty over one of the other difficulties 17:32:22 <planetmaker> Zuu: I'd choose one option for all difficulty levels 17:32:40 <planetmaker> makes it easier to configure 17:33:07 <planetmaker> IMHO nothing is worse, if a behaviour changes, just because I changed something somewhere totally unrelated ;-) 17:33:17 <planetmaker> (without need for that behaviour change, of course) 17:34:10 <planetmaker> unless you 'unexpose' it and just include it in the difficulty setting 17:34:14 <Zuu> I would assume that if you had set any settings for an AI they will not change when you change dificulty. Only the "defaults" will be based on your current difficulty. 17:35:29 <planetmaker> Well, yes. But that would come to me at a surprise, if the AI behaviour other than 'difficulty' changes with difficulty 17:36:21 <planetmaker> though maybe not, but... feels at least initially slightly awkward 17:37:38 <Zuu> I would say the AI is easier if it does have some kind of fog-of-war limitation than not. 17:38:12 <planetmaker> well, possibly 17:43:50 *** tokai|mdlx [~tokai@port-92-195-17-4.dynamic.qsc.de] has joined #openttd 17:45:42 <CIA-1> OpenTTD: translators * r22404 /trunk/src/lang/brazilian_portuguese.txt: 17:45:42 <CIA-1> OpenTTD: -Update from WebTranslator v3.0: 17:45:42 <CIA-1> OpenTTD: brazilian_portuguese - 4 changes by Tucalipe 17:47:48 *** DanMacK [~DanMacK@206.191.69.149] has joined #openttd 17:49:47 *** douknoukem [~KEM@ALyon-158-1-124-69.w90-29.abo.wanadoo.fr] has joined #openttd 17:50:01 *** tokai|noir [~tokai@port-92-195-120-254.dynamic.qsc.de] has quit [Ping timeout: 480 seconds] 17:52:17 <DanMacK> Hey all 17:54:10 *** DOUK [~KEM@ALyon-158-1-124-69.w90-29.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 17:57:45 <Eddi|zuHause> Zuu: isn't there an AI intelligence setting for such stuff? 17:58:48 <Eddi|zuHause> i would say most people play custom... 17:58:53 <Zuu> Yes 18:00:04 <Zuu> But I guses there is at least some that just want to set the dificulty level and go. 18:00:42 <Zuu> (I know there are vast amount of settings in adv. settings that don't change when you change dificulty.) 18:03:11 <Zuu> as AI you could write a setting-layer so that all your settings are [via intelligence setting, ON, OFF] in the GUI, and then you have a middle-layer in your AI that tell if the setting ON/OFF to the AI logic layer depending on the intelligence if that GUI-setting has been selected. 18:04:31 <Zuu> However, it is not done automatically and as far as I know, no AI use this. The different defaults for each difficulty-level on the other hand is something that is supported in the API. 18:07:19 *** andythenorth [~Andy@213.99.112.87.dyn.plus.net] has joined #openttd 18:07:31 <DanMacK> Hey Andy 18:12:33 *** dfox [~dfox@ip-94-113-17-246.net.upcbroadband.cz] has quit [Ping timeout: 480 seconds] 18:17:55 <andythenorth> hi 18:32:01 <Eddi|zuHause> Zuu: not all things that are supported are a good idea... 18:34:06 <__ln__> http://www.bbc.co.uk/news/world-europe-13255673 18:37:25 <andythenorth> planetmaker: the town growth could be normal fluctuation 18:37:41 <andythenorth> it's possible that I only notice the ones that shrink, and not the ones that grwo 18:37:48 <andythenorth> like confirmation bias 18:44:01 <planetmaker> I suppose so, yes 18:44:35 <andythenorth> I think there's a problem though 18:44:44 <andythenorth> I'd have to read src I guess 18:48:13 * andythenorth ponders 18:48:46 <andythenorth> YACD can switch amounts-per-destination for industry cargo quite brutally 18:50:09 *** fonsinchen [~fonsinche@brln-4d0cd09c.pool.mediaWays.net] has joined #openttd 18:52:33 *** douknoukem [~KEM@ALyon-158-1-124-69.w90-29.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds] 18:53:14 *** ar3k [~ident@ebt214.neoplus.adsl.tpnet.pl] has quit [Quit: âI-n-v-i-s-i-o-nâ 3.2 (July '10)] 18:59:53 *** Sacro [~ben@cpc2-mfld9-0-0-cust880.13-1.cable.virginmedia.com] has quit [Ping timeout: 480 seconds] 19:01:19 *** andythenorth_ [~Andy@cpc18-aztw25-2-0-cust185.aztw.cable.virginmedia.com] has joined #openttd 19:05:28 *** Sacro [~ben@cpc2-mfld9-0-0-cust880.13-1.cable.virginmedia.com] has joined #openttd 19:08:35 *** andythenorth [~Andy@213.99.112.87.dyn.plus.net] has quit [Ping timeout: 480 seconds] 19:14:06 <Yexo> Zuu: when the difficulty level is not set to custom you can't change any AI settings. As soon as you change the setting of any AI the difficulty level is reset to custom 19:14:18 *** ar3k [~ident@ebt214.neoplus.adsl.tpnet.pl] has joined #openttd 19:14:20 *** ar3k is now known as ar3kaw 19:14:25 <Yexo> so there really is no need to handle the difficulty level separately in an AI 19:14:26 <CIA-1> OpenTTD: rubidium * r22405 /trunk/src/ (35 files in 3 dirs): -Document: some more "random-ish" tidbits 19:17:36 *** andythenorth_ [~Andy@cpc18-aztw25-2-0-cust185.aztw.cable.virginmedia.com] has quit [Read error: Connection reset by peer] 19:18:41 *** andythenorth [~Andy@cpc18-aztw25-2-0-cust185.aztw.cable.virginmedia.com] has joined #openttd 19:31:25 <andythenorth> ho 19:31:33 * andythenorth needs to change FIRS to support YACD 19:41:40 <devilsadvocate> andythenorth: FIRS already works with YACD, doesnt it? 19:41:55 <andythenorth> not very well in some respects 19:41:56 <devilsadvocate> there are some wierd bits, but in general it seems to be ok 19:42:08 <devilsadvocate> the major issue is stuff like engineering supplies 19:42:12 <andythenorth> there's that 19:42:21 <devilsadvocate> but even that can sort of be handled 19:42:29 <andythenorth> the split of primary cargo production makes some routes almost impossibe 19:42:52 <andythenorth> and I have an issue with secondary industry closing that isn't YACD specific, but is worse with YACD 19:43:33 <devilsadvocate> hm 19:43:59 <devilsadvocate> i probably never had that issue since my primary industries always supplied a single secondary industry 19:44:16 <devilsadvocate> it takes some time to switch, but in general its ok 19:44:55 <devilsadvocate> also, i usually end up having to drop things off / pick stuff up by train a bit away from primaries, and use trucks to space the deliveries 19:46:21 <andythenorth> there's a lot of people doing that it seems 19:47:10 <devilsadvocate> thats the only way to get the primary to stay open 19:47:27 <andythenorth> oh 19:47:30 <andythenorth> how interesting 19:47:39 <devilsadvocate> they take too little supplies at a time, and cargodist makes it a bit... harder 19:47:53 <andythenorth> I always play with primary closure off 19:47:59 *** Twerkhoven[L] [~twerkhove@cpc14-linl7-2-0-cust28.sgyl.cable.virginmedia.com] has joined #openttd 19:48:18 <andythenorth> I provide the option for people who like the challenge of primary closure, but it bugs me 19:49:09 <devilsadvocate> i've found that doing that (stations far away, smallest trucks available pacing deliveries) works almost always 19:50:09 <devilsadvocate> that usually means the supplies routes operate in the red, but thats fine since the primaries more than pay for them 19:50:43 <devilsadvocate> and the manufacturing sites for the supplies always have wierd stations on them, with 20 or 30 tiny platofrms 19:51:17 *** Mucht [~Martin@chello084115143107.3.graz.surfer.at] has joined #openttd 19:51:28 <Eddi|zuHause> feature request: in the vehicle list, make right click do the same as in depot: view statistics about capacity 19:52:06 <CIA-1> OpenTTD: rubidium * r22406 /trunk/ (33 files in 7 dirs): -Document: some more "random-ish" tidbits 19:52:49 <andythenorth> devilsadvocate: that gameplay is fun? It doesn't annoy you? 19:53:25 <devilsadvocate> andythenorth: well, i like intricate networks 19:53:35 <devilsadvocate> every so often it, um, breaks 19:53:48 <andythenorth> ok 19:53:58 <andythenorth> so long as it's fun ;) 19:54:00 <devilsadvocate> one train stopping at the wrong station totally messes up cargodist 19:54:14 <devilsadvocate> but otherwise its fun 19:59:06 *** sla_ro|master [~slaco@95.76.27.160] has quit [Quit: Mutant Co-Op - C&C Renegade] 20:04:21 <CIA-1> OpenTTD: rubidium * r22407 /trunk/src/ (driver.cpp driver.h): -Document: the "root" driver related stuff 20:05:26 <__ln__> http://bombardier.com/en/corporate/media-centre/press-releases/details?docID=0901260d8016ee96 20:11:10 *** Biolunar [~mahdi@blfd-4d0832f3.pool.mediaWays.net] has joined #openttd 20:11:21 <Eddi|zuHause> what's DB Regio doing with diesel engines? 20:11:39 <Eddi|zuHause> i'd assumed DB Cargo would rather use those 20:12:16 *** Devroush [~dennis@ip-213-49-88-29.dsl.scarlet.be] has joined #openttd 20:22:49 *** Absurd-Mind [~peter@p549582B5.dip0.t-ipconnect.de] has joined #openttd 20:31:47 *** tokai|noir [~tokai@port-92-195-118-231.dynamic.qsc.de] has joined #openttd 20:33:04 <frosch> night 20:33:07 *** frosch [~frosch@frnk-590fe28e.pool.mediaWays.net] has quit [Remote host closed the connection] 20:35:23 *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has joined #openttd 20:37:40 *** tokai|mdlx [~tokai@port-92-195-17-4.dynamic.qsc.de] has quit [Ping timeout: 480 seconds] 20:46:52 <CIA-1> OpenTTD: yexo * r22408 /trunk/src/ (newgrf.cpp newgrf.h): -Cleanup: remove unused variable GRFFile::sprite_offset 20:49:04 *** douknoukem [~KEM@ALyon-158-1-124-69.w90-29.abo.wanadoo.fr] has joined #openttd 20:49:06 *** Juo [~Juo@cpc16-lewi15-2-0-cust395.2-4.cable.virginmedia.com] has quit [Quit: Juo] 20:49:58 *** Juo [~Juo@cpc16-lewi15-2-0-cust395.2-4.cable.virginmedia.com] has joined #openttd 20:50:37 *** Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has left #openttd [] 20:51:03 *** fonsinchen [~fonsinche@brln-4d0cd09c.pool.mediaWays.net] has quit [Ping timeout: 480 seconds] 20:52:34 <andythenorth> night 20:52:35 *** andythenorth [~Andy@cpc18-aztw25-2-0-cust185.aztw.cable.virginmedia.com] has left #openttd [] 20:53:11 *** Juo [~Juo@cpc16-lewi15-2-0-cust395.2-4.cable.virginmedia.com] has quit [] 20:55:17 *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has quit [Read error: Operation timed out] 20:58:35 *** DanMacK [~DanMacK@206.191.69.149] has quit [Read error: Connection reset by peer] 21:02:31 <CIA-1> OpenTTD: yexo * r22409 /trunk/src/newgrf.cpp: -Fix: [NewGRF] make sure the action2 ID of a generic feature callback is valid 21:08:12 <Terkhen> good night 21:28:56 *** ar3k [~ident@ecl198.neoplus.adsl.tpnet.pl] has joined #openttd 21:33:49 *** Mucht [~Martin@chello084115143107.3.graz.surfer.at] has quit [Remote host closed the connection] 21:36:19 *** ar3kaw [~ident@ebt214.neoplus.adsl.tpnet.pl] has quit [Ping timeout: 480 seconds] 21:39:07 *** KouDy [~KouDy@ip-94-112-27-160.net.upcbroadband.cz] has quit [Quit: Leaving.] 21:45:22 *** ndh [~opera@dslb-088-074-006-199.pools.arcor-ip.net] has left #openttd [] 22:11:46 *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has quit [Remote host closed the connection] 22:14:25 *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has joined #openttd 22:17:47 *** Kurimus [Kurimus@dsl-tkubrasgw1-fe21dc00-138.dhcp.inet.fi] has quit [] 22:21:19 *** Twerkhoven[L] [~twerkhove@cpc14-linl7-2-0-cust28.sgyl.cable.virginmedia.com] has quit [Read error: Connection reset by peer] 22:27:33 *** lasershock` [~lasershoc@hd9483b29.seveveb.dyn.perspektivbredband.net] has joined #openttd 22:27:39 *** lasershock` [~lasershoc@hd9483b29.seveveb.dyn.perspektivbredband.net] has quit [] 22:27:45 *** bryjen [~bryjen@76.92.85.169] has joined #openttd 22:28:27 <Wolf01> 'night 22:28:35 *** Wolf01 [~wolf01@host41-233-dynamic.14-87-r.retail.telecomitalia.it] has quit [Quit: Once again the world is quick to bury me.] 22:30:41 *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has quit [Remote host closed the connection] 22:30:54 *** Chillosophy [~Chillosop@ip91350749.adsl-surfen.hetnet.nl] has quit [] 22:31:27 *** TWerkhoven [~twerkhove@cpc14-linl7-2-0-cust28.sgyl.cable.virginmedia.com] has quit [Quit: He who can look into the future, has a brighter future to look into] 22:38:00 *** Pulec [~pulec@static-cl093181068250.unet.cz] has quit [] 22:52:04 *** Zuu [~Zuu@h-114-141.A98.priv.bahnhof.se] has quit [Ping timeout: 480 seconds] 22:55:40 *** Adambean [AdamR@82.hosts.reece-eu.net] has quit [Quit: Gone fishing] 22:59:03 *** DDR [~DDR@d142-179-79-208.bchsia.telus.net] has joined #openttd 23:03:43 *** Absurd-Mind [~peter@p549582B5.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 23:34:57 *** Biolunar [~mahdi@blfd-4d0832f3.pool.mediaWays.net] has quit [Quit: All your IRC are belong to us!] 23:36:22 *** Sacro_ [~ben@cpc2-mfld9-0-0-cust880.13-1.cable.virginmedia.com] has joined #openttd 23:41:55 *** Xaroth_ [~Xaroth@86.92.135.101] has joined #openttd 23:42:03 *** Sacro [~ben@cpc2-mfld9-0-0-cust880.13-1.cable.virginmedia.com] has quit [Ping timeout: 480 seconds] 23:44:28 *** Sacro_ [~ben@cpc2-mfld9-0-0-cust880.13-1.cable.virginmedia.com] has quit [Ping timeout: 480 seconds] 23:48:13 *** Xaroth [~Xaroth@86.92.135.101] has quit [Ping timeout: 480 seconds] 23:53:17 *** romazoon [romazoon@84.102.63.81.cust.bluewin.ch] has quit [] 23:57:01 *** aber1 [~Adium@HSI-KBW-091-089-050-150.hsi2.kabelbw.de] has quit [Quit: Leaving.]