Times are UTC Toggle Colours
00:00:45 *** frosch123 [~frosch@frnk-4d0130c7.pool.mediaWays.net] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn] 00:03:54 <Wolf01> 'night 00:03:58 *** Wolf01 [~wolf01@0001288e.user.oftc.net] has quit [Quit: Once again the world is quick to bury me.] 00:17:10 <NGC3982> Hey __ln__. 00:17:13 <NGC3982> __ln__: https://scontent-b-ams.xx.fbcdn.net/hphotos-prn1/936633_539595949463361_1381708119_n.jpg 00:17:18 <NGC3982> This might be relevant. 00:18:00 *** gelignite [~gelignite@i528C3903.versanet.de] has quit [Quit: http://bit.ly/nkczDT] 00:28:21 *** adf88 [~Thunderbi@wis-zul.spine.pl] has quit [Quit: adf88] 00:29:03 *** Progman [~progman@p57A1875E.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 00:29:06 <__ln__> Hey NGC3982. 00:29:43 <__ln__> A nice one, but its facts are flawed. 00:44:49 *** KritiK [~Maxim@0001264a.user.oftc.net] has quit [Quit: Leaving] 00:58:45 *** Lo [~johannes@HSI-KBW-078-042-071-116.hsi3.kabel-badenwuerttemberg.de] has quit [Ping timeout: 480 seconds] 01:07:26 *** Stimrol [~Stimrol@46-239-219-51.tal.is] has quit [Quit: ZNC - http://znc.in] 01:09:25 *** Stimrol [~Stimrol@46-239-219-51.tal.is] has joined #openttd 01:34:30 *** KouDy [~koudy@188.75.190.58] has joined #openttd 01:57:47 *** Japa__ [~Japa@117.201.107.221] has quit [Read error: No route to host] 02:00:41 *** Japa [~Japa@117.201.107.221] has joined #openttd 02:07:03 *** KouDy [~koudy@188.75.190.58] has quit [Ping timeout: 480 seconds] 02:10:36 *** KouDy [~koudy@188.75.190.58] has joined #openttd 02:19:20 *** Japa_ [~Japa@117.201.107.221] has joined #openttd 02:25:15 *** Japa [~Japa@117.201.107.221] has quit [Read error: Operation timed out] 02:28:54 *** KouDy [~koudy@188.75.190.58] has quit [Ping timeout: 480 seconds] 02:30:58 *** Djohaal [~Djohaal@189.115.84.165] has quit [Read error: Connection reset by peer] 02:48:43 *** KouDy [~koudy@188.75.190.58] has joined #openttd 02:58:36 *** yorick [~yorick@ip51cd0513.speed.planet.nl] has quit [Remote host closed the connection] 03:00:26 *** roadt [~roadt@114.96.140.163] has joined #openttd 03:04:14 *** Japa__ [~Japa@117.201.107.221] has joined #openttd 03:10:33 *** Japa_ [~Japa@117.201.107.221] has quit [Ping timeout: 480 seconds] 03:16:12 *** glx [~glx@000128ec.user.oftc.net] has quit [Quit: Bye] 03:41:18 *** Japa_ [~Japa@117.201.107.221] has joined #openttd 03:48:04 *** Japa__ [~Japa@117.201.107.221] has quit [Read error: Operation timed out] 04:01:51 *** Japa__ [~Japa@117.201.107.221] has joined #openttd 04:08:36 *** Japa_ [~Japa@117.201.107.221] has quit [Ping timeout: 480 seconds] 04:16:55 *** Japa_ [~Japa@117.201.107.221] has joined #openttd 04:23:08 *** Japa__ [~Japa@117.201.107.221] has quit [Ping timeout: 480 seconds] 04:24:04 *** Midnightmyth [~quassel@93-167-84-102-static.dk.customer.tdc.net] has quit [Ping timeout: 480 seconds] 04:34:19 *** Hazzard [~oftc-webi@c-67-174-253-44.hsd1.ca.comcast.net] has joined #openttd 04:59:25 *** Japa__ [~Japa@117.214.4.31] has joined #openttd 04:59:25 *** Japa_ [~Japa@117.201.107.221] has quit [Read error: Connection reset by peer] 05:00:54 *** LeandroL [~leandro@190.189.0.224] has quit [Quit: Leaving] 05:11:00 *** Elukka [~Elukka@a91-152-213-89.elisa-laajakaista.fi] has joined #openttd 05:34:07 *** Pereba [~UserNick@179.177.173.106.dynamic.adsl.gvt.net.br] has quit [Quit: AdiIRC -> http://www.adiirc.com <- *I* use it, so it must be good!] 05:52:43 *** Hazzard [~oftc-webi@c-67-174-253-44.hsd1.ca.comcast.net] has quit [Quit: Page closed] 05:56:01 *** Eddi|zuHause [~johekr@p57BD480F.dip0.t-ipconnect.de] has quit [] 05:56:16 *** Eddi|zuHause [~johekr@p5DC678E1.dip0.t-ipconnect.de] has joined #openttd 05:59:55 *** retro|cz [~retro@ip-89-176-82-80.net.upcbroadband.cz] has joined #openttd 06:35:10 *** Virtual- [~Virtual@95.44.116.115] has quit [Quit: Leaving] 06:37:34 *** retro|cz [~retro@ip-89-176-82-80.net.upcbroadband.cz] has quit [Ping timeout: 480 seconds] 06:43:01 *** Gethiox [~gethiox@acug5.neoplus.adsl.tpnet.pl] has quit [Quit: WeeChat 0.4.2] 06:56:22 *** Japa_ [~Japa@117.214.4.31] has joined #openttd 06:59:31 *** LeandroL [~leandro@190.189.0.224] has joined #openttd 07:03:08 *** Japa__ [~Japa@117.214.4.31] has quit [Ping timeout: 480 seconds] 07:10:27 *** Lo [~johannes@HSI-KBW-078-042-071-116.hsi3.kabel-badenwuerttemberg.de] has joined #openttd 07:17:29 *** Lo [~johannes@HSI-KBW-078-042-071-116.hsi3.kabel-badenwuerttemberg.de] has quit [Quit: leaving] 07:34:53 *** Japa__ [~Japa@117.214.4.31] has joined #openttd 07:41:13 *** Japa_ [~Japa@117.214.4.31] has quit [Ping timeout: 480 seconds] 07:46:03 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 07:52:06 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth] 08:07:07 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has quit [Read error: Connection reset by peer] 08:07:28 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has joined #openttd 08:08:29 *** oskari89 [oskari89@62-241-226-106.bb.dnainternet.fi] has joined #openttd 08:12:37 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has quit [Read error: Connection reset by peer] 08:12:59 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has joined #openttd 08:15:15 *** adf88 [~Thunderbi@wis-zul.spine.pl] has joined #openttd 08:17:13 *** Japa [~Japa@117.201.99.164] has joined #openttd 08:23:11 *** Japa__ [~Japa@117.214.4.31] has quit [Ping timeout: 480 seconds] 08:41:52 *** Pensacola [~quassel@h220216.upc-h.chello.nl] has joined #openttd 08:49:20 *** Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has joined #openttd 08:49:23 *** mode/#openttd [+o Alberth] by ChanServ 08:49:37 <Alberth> more moin :) 08:56:44 <planetmaker> moin moin :) 09:09:03 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 09:12:31 <andythenorth> o/ 09:14:27 <planetmaker> o/ :) 09:17:51 *** Haube [~michi@77-20-40-44-dynip.superkabel.de] has quit [Read error: Connection reset by peer] 09:18:15 *** Haube [~michi@77-20-40-44-dynip.superkabel.de] has joined #openttd 09:19:19 <andythenorth> so did we solve compiling on OS X 10.9 ? o_O 09:27:22 *** valhallasw [~valhallas@s55978e11.adsl.online.nl] has joined #openttd 09:30:22 *** Japa [~Japa@117.201.99.164] has quit [Read error: Connection reset by peer] 09:32:11 <planetmaker> I think it was 09:32:46 <andythenorth> I had it working on my wife's mac, but there were some shenanigans 09:33:19 *** roadt [~roadt@114.96.140.163] has quit [Read error: Operation timed out] 09:34:47 <planetmaker> I think it should work if you compile/link against 10.8 sdk at least 09:35:07 <planetmaker> though: (svn r25913) -Fix: [OSX] Compilation under OSX 10.9. (zydeco) 09:35:56 *** sla_ro|master [slamaster@95.76.164.39] has joined #openttd 09:36:06 *** GriffinOneTwo [~oftc-webi@adsl-68-125-35-197.dsl.irvnca.pacbell.net] has joined #openttd 09:36:40 *** andythenorth is now known as Guest928 09:36:41 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 09:36:52 <andythenorth> :o 1680x1050 on a 13" screen is bonkers 09:37:16 *** andythenorth is now known as Guest929 09:37:17 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 09:37:24 <planetmaker> well... 4x zoom :D 09:37:36 <planetmaker> equivalent to normal ;) 09:37:56 *** Guest928 [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Read error: Connection reset by peer] 09:38:19 *** kero [~keikoz@202.4.69.86.rev.sfr.net] has joined #openttd 09:39:44 <Guest929> \o/ 09:39:51 <Guest929> OTTD still looks ok on retina 09:40:13 *** DDR [~kvirc@S010600254bbe4e1c.vc.shawcable.net] has quit [Quit: DDR is not Dance Dance Revolution.] 09:40:55 *** Guest929 [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [] 09:45:38 <andythenorth> ugh 09:45:45 <andythenorth> but the internet looks terrible :( 09:48:00 *** roadt [~roadt@114.96.140.163] has joined #openttd 09:50:58 *** Progman [~progman@p57A19113.dip0.t-ipconnect.de] has joined #openttd 10:07:15 *** Ristovski [~rafael@89.205.3.77] has joined #openttd 10:09:53 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth] 10:10:13 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 10:22:18 <andythenorth> 2 min 44s FIRS compile 10:22:21 <andythenorth> instead of > 6 mins 10:24:50 <planetmaker> new machine? 10:25:01 <planetmaker> (or old repaired)? 10:25:37 <Eddi|zuHause> using pypy i suppose 10:28:32 <andythenorth> new machine 10:28:45 *** GriffinOneTwo [~oftc-webi@adsl-68-125-35-197.dsl.irvnca.pacbell.net] has quit [Quit: Page closed] 10:28:50 <andythenorth> 'slower' than my broken mac 10:28:57 <andythenorth> but let's not discuss clock speed :P 10:33:21 <andythenorth> hmm 10:33:25 <andythenorth> compile fails 10:39:39 <Alberth> clock speed doesn't say everything :) 10:47:05 *** oskari89 [oskari89@62-241-226-106.bb.dnainternet.fi] has quit [] 10:52:40 <peter1138> andythenorth has a new toy? 10:53:14 <Eddi|zuHause> does "clock speed" refer to the actual clock speed nowadays or is it just a marketing number of "equivalent to the speed of <x>" 10:54:13 <peter1138> Hmm, did Intel ever do that? 10:54:16 <peter1138> I know AMD loved it. 10:55:33 <peter1138> Mind you they give them model names now, instead of just relying on the clock speed to distinguish them. 10:56:59 <Eddi|zuHause> i stopped following the cpu development at "pentium" 10:57:31 *** Virtual [~Virtual@95.44.116.115] has joined #openttd 10:58:22 <andythenorth> I can't make sense of it :) 10:58:41 <andythenorth> anyway, this one has a slower clock speed than my old one 10:58:45 <andythenorth> but benchmarks about the same 10:59:01 <andythenorth> it allegedly has a 10%-30% improvement in battery life 10:59:21 <andythenorth> but it ships with a new OS X that also offers a 10%-30% improvement in battery life, even on older systems 10:59:41 <andythenorth> but the total improvement to battery life is still 10%-30% in tests :P 10:59:43 <andythenorth> go figure :P 11:00:37 <Eddi|zuHause> i would have expected the optimisations to cancel each other out :p 11:01:16 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth] 11:04:05 *** gelignite [~gelignite@i528C39F9.versanet.de] has joined #openttd 11:09:07 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 11:10:44 *** Pinkbeas1 [damerell@chiark.greenend.org.uk] has joined #openttd 11:28:06 *** MNIM [~mBuntu@ip5452ffad.adsl-surfen.hetnet.nl] has quit [Remote host closed the connection] 12:01:07 <andythenorth> no gcc :P 12:01:52 <andythenorth> fixed :P 12:03:53 <andythenorth> hmm 12:03:57 <andythenorth> _nearly_ compiled :P 12:04:07 <andythenorth> clang: error: linker command failed with exit code 1 (use -v to see invocation) 12:05:34 <andythenorth> ho the wiki has answers 12:07:30 <andythenorth> hmm 12:07:31 <andythenorth> clang: error: no such file or directory: '/opt/X11/lib/libpng.a' 12:07:35 <andythenorth> I need to install some deps? 12:10:48 *** tokai|noir [~tokai@00012860.user.oftc.net] has joined #openttd 12:10:52 *** mode/#openttd [+v tokai|noir] by ChanServ 12:11:26 <planetmaker> you try to compile openttd? sure 12:12:19 <planetmaker> https://www.openttd.org/en/development lists all (or at least most :D ) 12:12:53 * andythenorth watches x11 slowly install 12:13:18 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd 12:16:07 *** yorick [~yorick@ip51cd0513.speed.planet.nl] has joined #openttd 12:17:00 *** tokai|mdlx [~tokai@port-92-195-50-155.dynamic.qsc.de] has quit [Ping timeout: 480 seconds] 12:17:06 <andythenorth> this is fun :) 12:28:11 * LordAro appears 12:28:16 <LordAro> moin 12:28:35 <andythenorth> so I need _BZ2_bzDecompress 12:28:39 <andythenorth> can't figure out what provides it 12:30:04 <andythenorth> also _libiconv 12:33:02 *** Japa [~Japa@117.214.3.189] has joined #openttd 12:39:24 *** Gethiox [~gethiox@host-2-121.24.net.pl] has joined #openttd 12:44:49 *** Midnightmyth [~quassel@93-167-84-102-static.dk.customer.tdc.net] has joined #openttd 12:58:15 <andythenorth> updating ports takes a while :o 13:02:10 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth] 13:10:01 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds] 13:16:46 *** Japa_ [~Japa@117.214.3.189] has joined #openttd 13:19:16 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 13:23:29 *** Japa [~Japa@117.214.3.189] has quit [Ping timeout: 480 seconds] 13:24:18 <andythenorth> which freetype version do I need to compile on OS X? 13:29:08 <andythenorth> compile failing with ld: symbol(s) not found for architecture x86_64 13:29:14 <andythenorth> suggested fix is downgrade freetype 13:31:53 <andythenorth> ah --without-freetype works 13:36:17 *** perk11 [~perk11@broadband-46-242-13-101.nationalcablenetworks.ru] has joined #openttd 13:42:29 * andythenorth updates wiki 13:45:14 <michi_cc> Without freetype you're limited to English and a few other European languages though. 13:55:00 <andythenorth> :( 13:56:35 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth] 13:56:55 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 14:01:53 *** Progman [~progman@p57A19113.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 14:04:54 <peter1138> Not if you make a sprite font grf 14:07:11 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd 14:08:19 *** LeandroL [~leandro@190.189.0.224] has quit [Ping timeout: 480 seconds] 14:09:41 *** LeandroL [~leandro@190.189.0.224] has joined #openttd 14:15:20 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds] 14:34:49 *** adf88 [~Thunderbi@wis-zul.spine.pl] has quit [Ping timeout: 480 seconds] 14:44:14 *** retro|cz [~retro@ip-89-176-82-80.net.upcbroadband.cz] has joined #openttd 14:47:22 *** Japa_ [~Japa@117.214.3.189] has quit [Read error: Operation timed out] 14:57:19 *** roadt [~roadt@114.96.140.163] has quit [Ping timeout: 480 seconds] 15:08:06 *** KritiK [~Maxim@0001264a.user.oftc.net] has joined #openttd 15:08:44 *** Pereba [~UserNick@179.177.173.106.dynamic.adsl.gvt.net.br] has joined #openttd 15:13:10 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth] 15:17:35 *** frosch123 [~frosch@frnk-5f74148d.pool.mediaWays.net] has joined #openttd 15:22:08 <George> I'd suggest to change colours on cargo flow graph 15:24:47 <George> white (empty cargo wgons back from industries to production points) lines overshadows all the others, because they are too bright than the others 15:25:27 <George> I'd suggest to make dark green for unused up to bright red for overloaded 15:26:13 <George> providuing the rule "The most overloaded line is the the mnost bright" 15:31:26 <planetmaker> so black instead of white for unused? 15:31:36 <George> or so 15:31:39 <planetmaker> (black being the darkest green available :D ) 15:31:44 <George> Yes 15:32:13 <George> I just want to say that white makes all other colours invisible 15:32:32 <George> and the graph becomes useless 15:32:54 <frosch123> hmm, i forgot... are the colours toggleable like the industries? 15:33:02 <George> I had to use magnifier to understand what this graph is 15:33:10 <planetmaker> I didn't see it as overshadowing, but I agree that it breaks the continuity of the colours, George 15:33:40 <frosch123> unused lines are kind of: either you want to see them to add unload orders everywhere, or you do not want to see them at all 15:33:57 <frosch123> so, i am not sure about changing the shade comparing to adding an option to hide them entirely 15:34:08 <George> It is not lines graph 15:34:18 <George> it is cargo flow graph 15:35:40 <George> adding a other cargo to the line would fill the line, but not the flow 15:36:18 <George> I suppose it is impossible to see free lines on such a graph 15:36:49 <George> free in contest "it is possible to add more trains" 15:37:14 *** retro|cz [~retro@ip-89-176-82-80.net.upcbroadband.cz] has quit [Ping timeout: 480 seconds] 15:37:27 <George> because, for example, 10 trins goes full to one side, and empty to the other 15:37:48 <George> the graph shows a way back as unused 15:38:26 <George> In such contest the only profit is to see overloaded lines, but not the unused ones 15:39:35 <fonsinchen> You may want to see the places where you've provided way too much capacity. That's expensive after all ... 15:40:18 <planetmaker> ^ that's a very good argument :) 15:51:20 <George> then we need a kew to toggle between bright-dark and dark-bright varianths 15:51:39 <George> I mean a button 15:57:19 *** andythenorth_ [~andytheno@genkt-049-013.t-mobile.co.uk] has joined #openttd 16:00:53 *** andythenorth_ [~andytheno@genkt-049-013.t-mobile.co.uk] has quit [Remote host closed the connection] 16:01:32 *** andythenorth_ [~andytheno@genkt-049-013.t-mobile.co.uk] has joined #openttd 16:06:10 *** andythenorth_ [~andytheno@genkt-049-013.t-mobile.co.uk] has quit [Remote host closed the connection] 16:06:44 *** andythenorth_ [~andytheno@genkt-049-013.t-mobile.co.uk] has joined #openttd 16:07:21 * andythenorth_ considers a 'no supplies' option for FIRS 16:07:28 <andythenorth_> For cdist 16:08:22 <andythenorth_> The intention of supplies was to give player influence over industry production directly 16:08:51 <andythenorth_> But that's incompatible with cargo distribution mechanics 16:10:03 <andythenorth_> Player shouldn't choose anything when distribution is used 16:10:49 <Alberth> make sense 16:11:46 <andythenorth_> Revert to traditional station rating to control production? 16:12:32 <Alberth> not much else you can do, I think 16:13:22 <andythenorth_> Give dist control over production directly? 16:13:35 <andythenorth_> As it is running the economy... 16:19:56 *** gelignite [~gelignite@i528C39F9.versanet.de] has quit [Quit: http://bit.ly/nkczDT] 16:20:35 <andythenorth_> Maybe station rating is best proxy for that 16:21:21 <andythenorth_> Can newgrf detect use of cdist? 16:26:39 <planetmaker> they can't 16:28:56 <andythenorth_> Would be unwise anyway :p 16:34:53 *** adf88 [~Thunderbi@wis-zul.spine.pl] has joined #openttd 16:37:17 <andythenorth_> So why should an industry increase production? 16:37:17 <andythenorth_> Good service? 16:37:31 <planetmaker> yes 16:37:55 <planetmaker> by default there's two influence components: service and random 16:38:24 <planetmaker> the random change is a random walk with average 0. The service component can give an offset in either direction 16:38:56 <planetmaker> That's IMHO a quite decent behaviour actually 16:39:26 <andythenorth_> I find it hard to think of a better one 16:40:13 <andythenorth_> One idea was to keep supplies, but have the amounts required be determined by the cdist allocations 16:41:14 <andythenorth_> So if cdist allocates 900t to a destination industry, boost is proportional to amount delivered/900 16:41:47 <andythenorth_> Would need a new industry var, amount allocated this month, with cargo as param 16:43:33 <planetmaker> or again back to binary delivered yes/no 16:44:18 <andythenorth_> You mean >1t ? o_O 16:44:42 <planetmaker> yeah, simple check for delivery at all 16:46:15 <andythenorth_> Loses the proportional aspect :) 16:48:38 <planetmaker> yes. The proportion of deliverable to one industry to globally available per cargotype is already defined by cargodist 16:49:00 <planetmaker> so you could scale production simply by the amount of actually delivered cargo and treat the supplies simply like other cargos 16:49:04 <planetmaker> for industries 16:49:13 *** andythenorth_ [~andytheno@genkt-049-013.t-mobile.co.uk] has quit [Remote host closed the connection] 16:49:21 <planetmaker> meh 16:50:30 *** andythenorth_ [~andytheno@genkt-049-013.t-mobile.co.uk] has joined #openttd 16:53:59 <andythenorth_> Could supplies just act like inputs at secondary industry? 16:54:30 <andythenorth_> So simply some ratio like 1t in gives 4t out? 16:56:07 <planetmaker> <planetmaker> yes. The proportion of deliverable to one industry to globally available per cargotype is already defined by cargodist 16:56:07 <planetmaker> <planetmaker> so you could scale production simply by the amount of actually delivered cargo and treat the supplies simply like other cargos 16:56:07 <planetmaker> <planetmaker> for industries 16:56:38 <planetmaker> ^ dunno whether you read my reply :) 16:56:49 <andythenorth_> I did :) 16:56:53 <planetmaker> so: yes, they could 16:56:59 *** zeknurn [~sup@hd9483b0c.seveveb.dyn.perspektivbredband.net] has quit [Remote host closed the connection] 16:57:24 <andythenorth_> Wonder if it would be good? 16:57:41 *** zeknurn [~sup@hd9483b0c.seveveb.dyn.perspektivbredband.net] has joined #openttd 16:58:26 <andythenorth_> Anyway it has one attraction: no longer my problem :) let cdist sort the economy out 17:04:50 *** tokai|mdlx [~tokai@port-92-195-44-235.dynamic.qsc.de] has joined #openttd 17:05:51 <planetmaker> would simplify code, too ;) 17:06:02 <planetmaker> but supplies wouldn't be special anymore 17:06:36 <planetmaker> though they still would be required everywhere - opposed to other cargos. So still a bit different 17:07:15 <andythenorth_> Might be better just removed 17:08:00 <planetmaker> nah, wouldn't do that. 17:08:21 <andythenorth_> I knew this might be an issue, but I didn't want to work on it until we knew cdist was in trun 17:08:29 <andythenorth_> Trunk * 17:09:58 *** tokai|noir [~tokai@00012860.user.oftc.net] has quit [Ping timeout: 480 seconds] 17:12:34 <andythenorth_> What's the goal of increasing primary production? 17:12:56 <andythenorth_> Mostly to screw up network, creating a challenge? 17:15:53 *** Japa [~Japa@117.201.96.136] has joined #openttd 17:22:52 <andythenorth_> o_O maybe it's time for a new industry set? 17:23:09 <andythenorth_> Designed for cdist 17:29:29 <andythenorth_> Only one type of each secondary industry per map 17:29:55 <andythenorth_> Hmm 17:30:07 <andythenorth_> Secondaries would be black holes 17:38:00 <Eddi|zuHause> that sounds totally stupid 17:39:45 <andythenorth_> Maybe the 1 per map limit is unnecessary 17:41:16 <andythenorth_> I don't like the behaviour of town cargos with cdist 17:41:42 <andythenorth_> They would be better removed 17:42:40 <Eddi|zuHause> remove passengers 17:43:12 <andythenorth_> Pax is pretty good with cdist though 17:44:16 <Eddi|zuHause> remove mail, i never transport it anyway 17:44:50 <Eddi|zuHause> but if you want to design an economy "for cargodist", then have many small industries and few cargo types 17:46:03 <Eddi|zuHause> maybe a "car parts" economy 17:46:34 <Eddi|zuHause> one big assembly plant per map, and many industries producing various parts 17:47:19 <andythenorth_> Also needs quite stable production 17:47:42 <Eddi|zuHause> scale the production by date? 17:47:47 <Eddi|zuHause> screw randomness? 17:47:48 <andythenorth_> Big fluctuations are not fun 17:48:07 <Eddi|zuHause> increase by 20% every 5 years 17:49:30 <andythenorth_> I have only played 2 games with cdist but it serms to favour many-to-one for cargos 17:50:05 <Eddi|zuHause> yes 17:50:13 <Eddi|zuHause> hence my above suggestion 17:50:28 <andythenorth_> Agreed 17:51:37 <Eddi|zuHause> question is what to do with the cars. it would be a "town cargo" in that aspect 17:52:49 <andythenorth_> Dunno 17:53:23 <Eddi|zuHause> so: cargos: rubber->tyres, sand->glass, coal,ore->metal (->cars) 17:53:45 <Eddi|zuHause> some basic stuff to provide food and water 17:54:06 <Eddi|zuHause> no feedback mechanism 17:54:25 <Eddi|zuHause> steady growth 17:55:15 <Eddi|zuHause> only one assembly plant per map, other industries can be multiple 17:55:57 <Eddi|zuHause> sounds like a plan? 17:56:47 <andythenorth_> Think so 17:57:11 <andythenorth_> Shame we need coal for metal 17:57:23 <Eddi|zuHause> can leave it out? 17:57:27 <andythenorth_> I think cdist would suit power plants also 17:57:33 <Eddi|zuHause> coal->power plant 17:57:50 <Eddi|zuHause> only one power plant per map 17:57:53 *** glx [~glx@000128ec.user.oftc.net] has joined #openttd 17:57:56 *** mode/#openttd [+v glx] by ChanServ 17:58:21 <andythenorth_> Yup 17:58:22 <Eddi|zuHause> both assembly plant and power plant must be huge (like 8x10 or 10x15) 17:58:55 <Alberth> what's the point of cdist with 1 destination? 17:59:02 <Eddi|zuHause> feeder services 17:59:34 <Alberth> you don't need cdist for that 18:00:12 <Eddi|zuHause> i agree with andythenorth_, for "asymmetric" cargos, many-to-many or one-to-many services don't work well 18:00:34 <Eddi|zuHause> YACD is better suited for those 18:08:15 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 18:08:27 <andythenorth> also with only one destination, you avoid complex effects 18:08:56 <andythenorth> like unexpected backloading etc 18:09:14 <andythenorth> ideally there is only one closed link graph per destination 18:09:43 <andythenorth> hmm 18:10:16 <andythenorth> with sufficient spacing, there could be more than one of each secondary type - space then out and let the distance algorithm deal with it 18:10:38 <andythenorth> divide the map into 256x256 sections? 18:11:02 <Eddi|zuHause> one on 512x512, two on 1024x1024, three on 2048x2048? 18:11:10 <andythenorth> something like that yes 18:11:13 <andythenorth> I think it's worth trying 18:11:16 <andythenorth> cdist is fun 18:11:19 <andythenorth> FIRS with cdist isn't 18:12:18 *** retro|cz [~retro@ip-89-176-82-80.net.upcbroadband.cz] has joined #openttd 18:14:06 <andythenorth> Eddi|zuHause: no boost effects due combining cargo at secondaries? (causes unwanted network fluctuations) 18:14:40 *** andythenorth_ [~andytheno@genkt-049-013.t-mobile.co.uk] has quit [Remote host closed the connection] 18:16:16 <Eddi|zuHause> andythenorth: unsure 18:16:56 <andythenorth> my judgement is that fluctuations are unwanted for cdist, but you have played it more than me... 18:19:53 <andythenorth> biab 18:19:55 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth] 18:28:58 *** andythenorth_ [~andytheno@genkt-049-013.t-mobile.co.uk] has joined #openttd 18:29:25 <andythenorth_> So why is one-to-many currently not good with cdist? 18:29:45 <andythenorth_> Specifically for town cargos 18:30:43 <andythenorth_> I couldn't understand the allocation behaviour so I can't suggest improvements :p 18:31:28 <Alberth> with asymmetric, it's mostly distance, in my experience 18:31:38 <andythenorth_> Afaict the ideal is that either all destinations within catchment get same allocation 18:31:49 <andythenorth_> Or proportional to popularion 18:31:56 <andythenorth_> Population* 18:31:58 *** LeandroL [~leandro@190.189.0.224] has quit [Ping timeout: 480 seconds] 18:33:10 <andythenorth_> Also connecting another node shouldn't screw the existing routes 18:33:27 <andythenorth_> Sounds more yacd-like? 18:35:11 <Eddi|zuHause> let's take "goods" for example: with cargodist, there is absolutely no incentive to distribute them across the town, just build a station at the edge, and dump everything there 18:35:46 <Eddi|zuHause> distributing them across town with a truck will only diminish your income, but not get you more cargo to transport, so you won't have any benefits 18:35:57 <andythenorth_> Yup 18:36:50 <andythenorth_> Adding more nodes to that network is just a boring headache with no upside except realism :) 18:37:25 <Eddi|zuHause> that is the key difference between cargodist and YACD 18:37:43 <andythenorth_> Fundamentally can't be solved if routing is only to connected nodes 18:38:07 <andythenorth_> Whereas primary cargos, every node added is good 18:38:31 <andythenorth_> and consolidating with feeders is easy 18:38:47 <andythenorth_> So utilisation of backbones can be high 18:38:58 <Eddi|zuHause> exactly, cargodist works well for primary or "symmetric" cargos 18:40:59 <Eddi|zuHause> andythenorth_: in the "car parts" economy, you should give cars the "TE_GOODS" flag, then people can use town growth gamescripts to define a use for them 18:41:24 <Eddi|zuHause> then at least you have the need to deliver them to more than one town 18:44:31 <andythenorth_> But the GS must not prescribe required amounts... 18:44:41 <andythenorth_> As cdist controls that 18:49:36 *** LeandroL [~leandro@190.189.0.224] has joined #openttd 18:59:00 *** Djohaal [~Djohaal@186.212.212.98] has joined #openttd 19:06:20 <andythenorth_> So we have two mechanics not in harmony :) 19:07:43 <andythenorth_> We have newgrf and gs (town growth etc) trying to provide reasons for player to choose cargo routing 19:07:49 *** retro|cz [~retro@ip-89-176-82-80.net.upcbroadband.cz] has quit [Ping timeout: 480 seconds] 19:08:11 <andythenorth_> And we have distribution mechanics attempting to remove need for player to choose :) 19:12:12 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd 19:20:14 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 19:21:17 *** retro|cz [~retro@ip-89-176-82-80.net.upcbroadband.cz] has joined #openttd 19:22:02 <andythenorth> Eddi|zuHause: food - same many-to-one issue...? 19:23:02 <frosch123> andythenorth: why are you not happy about the choices? 19:23:12 <frosch123> you can play with a gs, or with a newgrf, or with cdist 19:23:28 <frosch123> if you would combine them together, you would only have one choice 19:23:32 <frosch123> now you have 3 19:23:39 *** andythenorth_ [~andytheno@genkt-049-013.t-mobile.co.uk] has quit [Remote host closed the connection] 19:23:49 <andythenorth> cdist is too fundamentally useful to see it as a choice 19:23:58 <andythenorth> just the transfers alone make it worth having 19:24:45 <andythenorth> (is my opinion, ymmv) :) 19:25:26 <andythenorth> and if I've understood correctly, the cdist calculation demand is modular and could be swapped out per cargo? 19:26:21 <andythenorth> I think newgrf is the worst of the 3 ways to provide demand 19:26:36 <andythenorth> FIRS has tried pretty hard, but is quite limited 19:32:11 *** Progman [~progman@p57A19113.dip0.t-ipconnect.de] has joined #openttd 19:38:58 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth] 19:39:27 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 19:51:18 *** Elukka [~Elukka@a91-152-213-89.elisa-laajakaista.fi] has quit [] 19:53:39 <Eddi|zuHause> no, newgrf is a good way to define demand, but first you need to define a proper interface 19:54:23 *** Zuu [~chatzilla@46.195.136.22] has joined #openttd 19:54:33 <andythenorth> where did we get to on the idea of tiles as the interface? 19:54:59 *** Zuu is now known as Guest980 20:03:57 <Eddi|zuHause> no idea 20:04:54 *** adf88 [~Thunderbi@wis-zul.spine.pl] has quit [Ping timeout: 480 seconds] 20:08:59 *** Guest980 is now known as Zuu 20:11:14 <Taede> +- 20:13:36 *** kero [~keikoz@202.4.69.86.rev.sfr.net] has quit [Ping timeout: 480 seconds] 20:16:43 *** adf88 [~Thunderbi@wis-zul.spine.pl] has joined #openttd 20:23:31 *** Pensacola [~quassel@h220216.upc-h.chello.nl] has quit [Remote host closed the connection] 20:28:14 <fonsinchen> The tiles interface to demand already exists. It should probably be removed if we follow the arguments of our last discussion. 20:28:26 <andythenorth> what was the conclusion of that? 20:28:31 <andythenorth> I missed some of it :) 20:29:42 *** oskari89 [oskari89@62-241-226-106.bb.dnainternet.fi] has joined #openttd 20:32:20 <Eddi|zuHause> well afair the main point was "demand should be industry-based and not industrytile based" 20:32:50 *** Zuu [~chatzilla@46.195.136.22] has quit [Quit: ChatZilla 0.9.90.1 [Firefox 26.0/20131205075310]] 20:37:25 <fonsinchen> Removal of that interface would just mean truncating the currently used values to booleans somewhere. 20:43:39 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has quit [Ping timeout: 480 seconds] 20:43:45 *** alluke [~oftc-webi@cs181208223.pp.htv.fi] has joined #openttd 20:43:59 <andythenorth> so what was the case for industry based demand? 20:44:07 <andythenorth> actually I think I recall 20:44:32 <andythenorth> I still see that as tile based 20:44:40 <andythenorth> we just store the demand on the industry N tile 20:45:05 <andythenorth> no that wouldn't work quite right for stations 20:45:19 <planetmaker> industries have persistant storage 20:46:29 <andythenorth> isn't the issue how to represent the demand correctly to cdist? 20:46:44 <fonsinchen> What does the persistent storage have to do with it? 20:47:11 <andythenorth> we want the station to treat covering any tile as covering the whole industry 20:47:26 <andythenorth> but we want also demand per tile for cases like houses 20:47:30 <andythenorth> iirc 20:47:31 <Eddi|zuHause> the problem was that "industrytile-based demand" violated the rule of "it doesn't matter whether you cover one or all tiles of the industry with your station" 20:47:59 <Taede> isnt each house its an 'industry' on its own? 20:48:09 <Eddi|zuHause> Taede: not really 20:48:13 <andythenorth> I wanted demand-per-tile as the general principle because there's something pure and simple about it, it's like having a demand based economy 20:48:20 <andythenorth> that might collide with reality of our implementation though :) 20:48:52 <Eddi|zuHause> Taede: "industry" and "industrytile" are two separate entities in the code, but there is no distinction between "house" and "housetile" 20:54:59 <andythenorth> hmm 20:56:11 <andythenorth> so only industries and houses provide demand? 20:56:17 <andythenorth> ah, also HQs 20:56:37 <frosch123> i would file hq under houses 20:57:00 <andythenorth> and there's no case for allowing arbitrary demand on a tile? 20:57:06 <andythenorth> railroad tycoon 3 used that method 20:57:18 <andythenorth> it provided a demand gradient towards destinations 20:57:25 <Eddi|zuHause> what would you use that for? 20:57:38 <andythenorth> even if a station didn't cover an industry or town, you could still deliver to the station if demand existed 20:57:46 <andythenorth> it modeled price gradients 20:58:19 <andythenorth> not really TTD-style 20:58:24 <Eddi|zuHause> a) i don't think that is a good mathod, and b) do not overload features 20:58:54 <Eddi|zuHause> we've made that mistake so many times in TTD history 20:59:16 <andythenorth> he he 20:59:26 <andythenorth> but it's fun dealing with the consequences :) 20:59:49 <Eddi|zuHause> for certain values of "fun" 20:59:58 <andythenorth> well it's endlessly puzzling :P 21:00:17 <andythenorth> conditional orders anyone? :P 21:00:21 <andythenorth> anyway 21:01:02 <alluke> hnggggggggggggh 21:01:05 <andythenorth> fonsinchen: (so because I am pretty clueless about cdist) - if we can get a demand value at a station for a specific cargo, that is useful? 21:01:25 <andythenorth> or maybe it needs to know indidivual destinations? 21:01:30 <alluke> why can ogfx+ industries disable only oil wells and rigs building restrictions and not all industries 21:01:39 <andythenorth> it has to move packets to the destination I assume? 21:02:27 <Eddi|zuHause> alluke: because nobody implemented it? 21:02:50 *** Myhorta [~Myhorta@00018fad.user.oftc.net] has joined #openttd 21:03:06 <fonsinchen> I don't understand the question. Useful in what sense? And what is a "demand value at a station"? 21:03:42 *** gelignite [~gelignite@i528C39F9.versanet.de] has joined #openttd 21:04:21 <fonsinchen> OK, I probably understand the part about demand value. But the problem was _how_ to get that, not if it's useful, wasn't it? 21:04:47 <andythenorth> let me rephrase 21:05:19 <andythenorth> cdist spreads cargo across destinations according to relative demand at each destination? 21:06:17 <fonsinchen> At the moment it treats the tile demands as scale factor for the distribution, but also takes distance (if set to do so) and possibly supply at the other station into account 21:06:45 <fonsinchen> The tile demand thing came under critique lately 21:07:27 <andythenorth> so routing is station to station, but the demand is provided by the tile, so presumably there is some calculation summing all the tiles in a catchment, for demand? 21:08:39 <fonsinchen> yes, that's done by some tile loop calculating supply and demand for each station. It's not my invention. I just added a line in there to retain the absolute tile demand sum. 21:09:26 <Eddi|zuHause> it's the same function that searches for whether you have enough x/8 around the station to accept the cargo 21:09:41 <fonsinchen> yes, that thing. 21:10:00 <fonsinchen> previously it discarded the sum in the end and only checked for >8. 21:10:32 <Eddi|zuHause> the thing is, "x" is probably a good estimate for houses, but not for industries 21:11:14 *** jrambo [~jrambo@93-86-92-138.dynamic.isp.telekom.rs] has quit [Read error: Connection reset by peer] 21:11:36 *** jrambo [~jrambo@93-86-92-138.dynamic.isp.telekom.rs] has joined #openttd 21:11:50 <fonsinchen> The only viable argument against it is that it's confusing to the player if they cover only one tile of some industry and 12 tiles of another. 21:11:55 <Eddi|zuHause> because some industries have 8/8 for all tiles, and some others only 8/8 for one tile, and almost no industies have something less than 8/8 21:12:07 <fonsinchen> Then the second industry gets 12 times as much cargo. 21:13:01 <fonsinchen> On the other hand: 1. people are used to cover as much as possible of an industry already. Several industries require you to do that so that the station accepts at all 21:13:27 <fonsinchen> and 2. One could change the tile demands of industries of course. 21:13:30 <Eddi|zuHause> even if they are "conditioned" to do that, it's difficult for the industry set to use that for scaling 21:14:09 <fonsinchen> It's not difficult. Just only use the values above 8. That leaves enough room. 21:14:45 <Eddi|zuHause> and the user doesn't get to know this value, so it's difficult for him to use that to influence stuff 21:14:54 <fonsinchen> (there may be the odd bug coming up when doing that as no one has probably done tile demands >8, yet) 21:15:11 <andythenorth> tile demands are one of the more tedious bits of coding industry newgrfs 21:15:17 <fonsinchen> They can of course use the tile query function. 21:15:54 <andythenorth> in principle, the ability to set tile demand per-tile in an industry could be used for clever things 21:16:03 <andythenorth> in reality, that's an annoying anti-pattern 21:16:17 <fonsinchen> Also one could just say: "Cargodist assigns the demands. It has decided that industry 1 gets 12 times as much cargo. That's part of the challenge" 21:16:37 <andythenorth> fonsinchen: I don't think that's a terrible idea 21:16:51 <andythenorth> I just don't know if it's a good idea either :) 21:17:14 <andythenorth> it wasn't a bad feature of YACD 21:17:28 <Eddi|zuHause> that's why i suggested: simply introduce a property of industry, which defines the demand 21:17:38 <fonsinchen> What does it have to do with YACD? 21:17:48 <Eddi|zuHause> so by default all industries will get the same amount of cargo 21:17:55 <Eddi|zuHause> unless the newgrf author defines differently 21:18:13 <andythenorth> Eddi|zuHause: so that's completely decoupled from tile acceptance props? 21:18:18 <Eddi|zuHause> yes 21:19:07 <Eddi|zuHause> so in the postmedieval economy, all the smithy forges will get the same amount of iron ore, until the first steel mill is built and catches 95% of the ore 21:19:22 <fonsinchen> I'd say you either get what we already have or the code gets messy. At least I can't think of an elegant way to implement it. 21:19:24 <andythenorth> if I cover 1 industry with 2 stations on the same linkgraph, what would that do? 21:19:32 <fonsinchen> If anyone knows better, feel free to do it... 21:20:17 <fonsinchen> Both of the stations will get cargo for the industry. The demand is counted twice 21:20:23 <andythenorth> ok 21:20:47 <andythenorth> that's worth knowing, for in-game hax :) 21:20:56 <Eddi|zuHause> it could get debated that the industry-demand-value would get divided by the amount of stations covering it 21:21:10 <Eddi|zuHause> but that may screw up dropoff and pickup stations 21:21:13 <andythenorth> yeah 21:21:16 <andythenorth> and easy griefing 21:21:29 <andythenorth> I know we don't consider griefing :P 21:21:36 <andythenorth> but even accidental, unintentional griefing 21:21:45 <andythenorth> player 1 can bork player 2's network 21:22:47 <andythenorth> I asked deliberately about the case of 2 stations on same graph 21:22:51 <Eddi|zuHause> exactly, so just leave it alone, and let the player use "two stations will double the cargo for that industry" as balance mechanism 21:23:02 <andythenorth> plausible 21:23:18 <andythenorth> but if they are on same graph, demand could be divided between stations? 21:23:28 <andythenorth> player 1 and player 2 have different graphs... 21:24:30 <andythenorth> complicated isn't it :D 21:24:52 <fonsinchen> If the link graph behaviour should depend on industries served by the stations it all boils down to carrying an m-to-n association between industries and stations around. 21:24:57 <fonsinchen> That's no fun. 21:25:45 *** tokai|noir [~tokai@00012860.user.oftc.net] has joined #openttd 21:25:49 *** mode/#openttd [+v tokai|noir] by ChanServ 21:25:52 <fonsinchen> I'm just hitting that problem while trying to reimplement YACD-style destinations on top of Cargodist. 21:26:31 <andythenorth> 'no fun' = very hard, or 'boring to play' ? 21:26:47 <fonsinchen> not very hard, but messy to implement. 21:27:08 <andythenorth> k 21:27:18 <fonsinchen> It either wastes memory or CPU time 21:28:39 <andythenorth> graph is calculated from actual vehicle orders, not just connected stations? 21:30:06 <Eddi|zuHause> there is no such thing as a connection between stations 21:30:36 <Eddi|zuHause> just vehicles travelling from A to B (either via explicit or implicit orders) 21:30:52 <andythenorth> ok 21:31:39 *** tokai|mdlx [~tokai@port-92-195-44-235.dynamic.qsc.de] has quit [Ping timeout: 480 seconds] 21:32:17 <andythenorth> I had an idea some while ago about giving each source-destination pair its own graph 21:32:23 <andythenorth> probably hideously impossible :P 21:32:42 <fonsinchen> It's connected from orders at first but then updated by actual measured capacities. 21:32:48 <Eddi|zuHause> those would be very boring graphs 21:33:20 <Eddi|zuHause> andythenorth: you can do that, by not reusing existing stations when you open up a new line 21:33:30 <andythenorth> Eddi|zuHause: it wouldn't be cdist style, it would be like YACD. It's theoretical, I have no idea how it would be implemented :P 21:33:35 <fonsinchen> You need to calculate a link graphs distribution in conjunction in order not to needlessly overload routes. 21:34:36 <Eddi|zuHause> andythenorth: it's definitely not the way to reach YACD-style destinations 21:36:29 <andythenorth> the goal was to avoid having to route each packet completely. Just calculate a gradient backwards from the destination. Each node gets a number corresponding to min number of links to destination. Cargo gets on the first vehicle going to a node with lower number than current one. It has multiple flaws 21:36:41 <andythenorth> but it would have been amusing 21:37:11 <andythenorth> it was trivial to show that cargo would take very stupid routes some times 21:37:20 <andythenorth> and that nodes could get flooded easily 21:40:12 <andythenorth> so forget that :P 21:40:36 <andythenorth> demand is relative, not absolute quantities? something like 0-255? 21:42:22 <fonsinchen> Demand is relative. The more supply there is in a network the more cargo every accepting node gets. 21:42:40 <fonsinchen> But the distribution depends on the demands. 21:42:57 <andythenorth> ok thanks 21:43:48 <andythenorth> would it be horrible if an industry changed relative demand by large amount on a monthly basis? 21:43:58 <fonsinchen> no 21:44:14 <fonsinchen> The link graph might miss the change as it only runs so often 21:44:57 <fonsinchen> But depending on your definition of "horrible" that may or may fall into it. 21:45:08 <andythenorth> it's scheduled according to player preference? So it can't be slaved to say industry monthly prod. change cb? 21:45:55 <fonsinchen> It's even nastier: The player says how many link graphs may run in parallel and how long each is allowed to run. 21:46:00 <andythenorth> he :) 21:46:12 <fonsinchen> The more link graphs there are the longer it takes until each one is scheduled. 21:47:04 <andythenorth> makes me wary of having industries do much with a demand property 21:47:06 <fonsinchen> In most cases that's not a problem. If you have a lot of link graphs and a lot of spare CPU cycles you can set the run time to 1 day after all. 21:47:43 <fonsinchen> Well, you can use the tile demands. Just don't expect changes to take effect immediately. 21:47:48 <fonsinchen> It may take some time. 21:49:05 <andythenorth> I was puzzling how to have an industry recieve an absolute quantity when demand is relative 21:49:29 <andythenorth> I thought maybe increase demand by 1 each month that quantity is not recieved 21:49:42 <andythenorth> and decrease by some amount if quantity is recieved 21:49:46 <andythenorth> until some level is reached 21:49:52 <andythenorth> but there could be horrible feedbacks 21:50:04 <andythenorth> all industries in the linkgraph would be doing this 21:50:13 <andythenorth> otoh, it's just like real economy :P 21:53:25 <fonsinchen> Why do you want to deal with absolute quantities? You have to couple that with production somehow. Otherwise you may end up with cargo that isn't accepted anywhere. 21:53:40 <andythenorth> I understand the not accepted problem 21:53:52 <andythenorth> that actually happens in FIRS games without cdist 21:54:08 <andythenorth> hmmm...if supply was stable, and number of industries constant, industry could 'bid' by offering demand values until it got close to correct amount 21:54:18 <andythenorth> but that is not the case :P 21:55:03 <fonsinchen> Why not do it the other way around: An industry that produces a lot of stuff will have a high demand for engineering supplies. 21:55:16 <andythenorth> it's worth considering 21:55:32 <andythenorth> the current mechanic is incompatible with most forms of dist we can think of 21:56:03 <andythenorth> so what dictates that the industry produces a lot of stuff? 21:56:24 <fonsinchen> Cargo rating and random, just like with default industries 21:56:42 <andythenorth> could be done 21:57:03 <andythenorth> rewrite some code to use production multiplier, make the supply delivery another multiplying factor on that 21:57:22 <andythenorth> I wanted to do that anyway, in the hope that GS could be allowed to manipulate industry production 21:58:03 <andythenorth> so industry then expresses demand 21:58:09 <andythenorth> cdist takes care of routing 21:59:30 <andythenorth> scale production in line with % of supply demand met 21:59:31 <andythenorth> ? 21:59:49 <andythenorth> ugh no, demand is relative 21:59:51 <andythenorth> that won't work 22:00:02 <andythenorth> interesting problem 22:00:09 <andythenorth> need an absolute value somewhere 22:01:43 <fonsinchen> You could just make that a binary thing: Either any engineering supplies were delivered last month or not. 22:01:55 <fonsinchen> If not, production declines next month. 22:02:23 <andythenorth> yup 22:02:26 <fonsinchen> However, that's a negative feedback loop. You probably don't want that. 22:02:39 <andythenorth> supplies could just be removed 22:02:39 *** Devroush [~dennis@dD5765BAC.access.telenet.be] has joined #openttd 22:03:03 <andythenorth> I don't know if they're a worthwhile problem 22:04:14 <fonsinchen> I'm gone for now. Good night 22:05:29 <andythenorth> bye :) 22:09:19 *** Djohaal [~Djohaal@186.212.212.98] has quit [Read error: Connection reset by peer] 22:09:32 *** Djohaal [~Djohaal@186.212.212.98] has joined #openttd 22:12:44 *** adf88 [~Thunderbi@wis-zul.spine.pl] has quit [Ping timeout: 480 seconds] 22:12:44 *** Djohaal [~Djohaal@186.212.212.98] has quit [Read error: Connection reset by peer] 22:13:13 *** Djohaal [~Djohaal@186.212.212.98] has joined #openttd 22:23:49 *** Djohaal [~Djohaal@186.212.212.98] has quit [Read error: Connection reset by peer] 22:24:02 *** Djohaal [~Djohaal@186.212.212.98] has joined #openttd 22:27:20 *** Djohaal [~Djohaal@186.212.212.98] has quit [Read error: Connection reset by peer] 22:27:31 *** Djohaal [~Djohaal@186.212.212.98] has joined #openttd 22:32:13 *** frosch123 [~frosch@frnk-5f74148d.pool.mediaWays.net] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn] 22:32:13 *** Djohaal [~Djohaal@186.212.212.98] has quit [Read error: Connection reset by peer] 22:32:34 *** Djohaal [~Djohaal@186.212.212.98] has joined #openttd 22:33:02 *** Super_Random [~kvirc@75-102-176-79.d2.itctel.com] has quit [Read error: Connection reset by peer] 22:33:19 *** Super_Random [~kvirc@75-102-176-79.d2.itctel.com] has joined #openttd 22:33:56 *** adf88 [~Thunderbi@wis-zul.spine.pl] has joined #openttd 22:36:27 <andythenorth> so I'm still confused about whether cdist assigns cargo according to capacity 22:36:27 *** Djohaal [~Djohaal@186.212.212.98] has quit [Read error: Connection reset by peer] 22:36:37 <andythenorth> problem for another day :P 22:37:03 *** Djohaal [~Djohaal@186.212.212.98] has joined #openttd 22:37:49 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth] 22:38:34 *** Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has left #openttd [] 22:38:56 *** kero [~keikoz@202.4.69.86.rev.sfr.net] has joined #openttd 22:39:18 *** alluke [~oftc-webi@cs181208223.pp.htv.fi] has quit [Quit: Page closed] 22:41:08 *** Djohaal [~Djohaal@186.212.212.98] has quit [] 22:46:48 *** andythenorth_ [~andytheno@genkt-049-013.t-mobile.co.uk] has joined #openttd 22:51:07 *** sla_ro|master [slamaster@95.76.164.39] has quit [] 22:54:49 *** andythenorth_ [~andytheno@genkt-049-013.t-mobile.co.uk] has quit [Ping timeout: 480 seconds] 23:00:51 *** haxx [~Rob@135-23-80-105.cpe.pppoe.ca] has joined #openttd 23:07:50 *** GriffinOneTwo [~oftc-webi@adsl-68-125-35-197.dsl.irvnca.pacbell.net] has joined #openttd 23:19:42 *** valhallasw [~valhallas@s55978e11.adsl.online.nl] has quit [Remote host closed the connection] 23:20:35 *** valhallasw [~valhallas@s55978e11.adsl.online.nl] has joined #openttd 23:20:57 *** valhallasw [~valhallas@s55978e11.adsl.online.nl] has quit [Remote host closed the connection] 23:24:44 *** valhallasw [~valhallas@s55978e11.adsl.online.nl] has joined #openttd 23:28:23 *** Gethiox [~gethiox@host-2-121.24.net.pl] has left #openttd [WeeChat 0.4.2] 23:29:59 *** Midnightmyth [~quassel@93-167-84-102-static.dk.customer.tdc.net] has quit [Read error: Connection reset by peer] 23:30:11 *** Midnightmyth [~quassel@93-167-84-102-static.dk.customer.tdc.net] has joined #openttd 23:35:24 *** ProfFrink [~proffrink@169.73.208.46.dyn.plus.net] has joined #openttd 23:35:58 *** Prof_Frink [~proffrink@169.73.208.46.dyn.plus.net] has quit [Read error: Connection reset by peer] 23:35:58 *** ProfFrink is now known as Prof_Frink 23:37:01 *** Pinkbeas1 [damerell@chiark.greenend.org.uk] has quit [Ping timeout: 480 seconds] 23:37:24 *** Pinkbeast [damerell@chiark.greenend.org.uk] has quit [Ping timeout: 480 seconds] 23:37:56 *** Super_Random [~kvirc@75-102-176-79.d2.itctel.com] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/] 23:40:02 *** Progman [~progman@p57A19113.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 23:57:34 *** Ristovski [~rafael@89.205.3.77] has quit [Quit: Leaving]