Times are UTC Toggle Colours
00:26:47 *** Pikkaphone [~yaaic@58.108.147.20] has joined #openttd 00:55:20 *** shirish [~quassel@0001358e.user.oftc.net] has quit [Ping timeout: 480 seconds] 01:08:08 *** dreck [~oftc-webi@bas1-ottawa08-1176111865.dsl.bell.ca] has left #openttd [] 01:19:08 *** samu [~oftc-webi@a85-139-81-208.cpe.netcabo.pt] has quit [Quit: Page closed] 01:34:49 *** quorzom [~quorzom@cable-78-35-98-177.netcologne.de] has quit [Read error: Connection reset by peer] 02:05:10 *** Pikkaphone [~yaaic@58.108.147.20] has quit [Ping timeout: 480 seconds] 02:05:26 *** shirish [~quassel@117.195.111.167] has joined #openttd 02:18:31 *** shirish [~quassel@0001358e.user.oftc.net] has quit [Ping timeout: 480 seconds] 02:37:35 *** itsatacoshop247 [~itsatacos@c-76-102-167-252.hsd1.ca.comcast.net] has joined #openttd 03:58:09 *** glx [~glx@000128ec.user.oftc.net] has quit [Quit: Bye] 04:51:57 *** tokai|noir [~tokai@00012860.user.oftc.net] has joined #openttd 04:52:00 *** mode/#openttd [+v tokai|noir] by ChanServ 04:55:49 *** tokai|mdlx [~tokai@port-92-195-97-122.dynamic.qsc.de] has quit [Ping timeout: 480 seconds] 05:15:47 *** DDR [~david@S010600254bbe4e1c.vc.shawcable.net] has quit [Read error: Connection reset by peer] 05:16:09 *** DDR [~david@S010600254bbe4e1c.vc.shawcable.net] has joined #openttd 05:23:21 *** HerzogDeXtEr [~flex@i59F6B56B.versanet.de] has joined #openttd 05:24:23 *** HerzogDeXtEr [~flex@i59F6B56B.versanet.de] has quit [] 05:26:25 *** HerzogDeXtEr [~flex@i59F6B56B.versanet.de] has joined #openttd 05:56:01 *** Eddi|zuHause [~johekr@p5DC6687E.dip0.t-ipconnect.de] has quit [] 05:56:17 *** Eddi|zuHause [~johekr@p57BD491B.dip0.t-ipconnect.de] has joined #openttd 06:15:32 *** DDR [~david@S010600254bbe4e1c.vc.shawcable.net] has quit [Read error: Connection reset by peer] 06:15:54 *** DDR [~david@S010600254bbe4e1c.vc.shawcable.net] has joined #openttd 06:24:05 *** shirish [~quassel@117.202.206.229] has joined #openttd 06:50:11 *** Yotson [~Yotson@erpaderp.xs4all.nl] has joined #openttd 06:52:10 *** supermop [~supermop@d110-33-170-165.sun801.vic.optusnet.com.au] has quit [Ping timeout: 480 seconds] 07:17:35 *** shirish [~quassel@0001358e.user.oftc.net] has quit [Ping timeout: 480 seconds] 07:40:49 *** Celestar [~Celestar@mnch-5d85bcec.pool.mediaWays.net] has joined #openttd 08:27:25 *** DDR [~david@S010600254bbe4e1c.vc.shawcable.net] has quit [Read error: Connection reset by peer] 09:11:23 *** hsknz [~hsknz@0001f970.user.oftc.net] has joined #openttd 09:20:15 *** hsknz [~hsknz@0001f970.user.oftc.net] has quit [Quit: :)] 09:32:11 *** hsknz [~hsknz@0001f970.user.oftc.net] has joined #openttd 09:40:00 *** glevans2 [~glevans2@71-8-126-76.dhcp.ftwo.tx.charter.com] has quit [Ping timeout: 480 seconds] 09:40:27 *** liq3 [liq3@CPE-120-147-178-81.gdfw1.lon.bigpond.net.au] has quit [] 09:40:53 *** glevans2 [~glevans2@71-8-126-76.dhcp.ftwo.tx.charter.com] has joined #openttd 10:23:28 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 10:30:51 <andythenorth> o/ 10:33:37 <dihedral> hello 10:34:55 *** glevans2 [~glevans2@71-8-126-76.dhcp.ftwo.tx.charter.com] has quit [Ping timeout: 480 seconds] 10:35:58 *** glevans2 [~glevans2@71-8-126-76.dhcp.ftwo.tx.charter.com] has joined #openttd 11:06:37 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has left #openttd [] 11:14:40 *** smoke_fumus [~smoke_fum@188.35.176.90] has joined #openttd 11:14:45 *** itsatacoshop247 [~itsatacos@c-76-102-167-252.hsd1.ca.comcast.net] has quit [Ping timeout: 480 seconds] 12:08:45 *** zeknurn` [~sup@hd9483b0c.seveveb.dyn.perspektivbredband.net] has joined #openttd 12:12:46 *** zeknurn [~sup@hd9483b0c.seveveb.dyn.perspektivbredband.net] has quit [Ping timeout: 480 seconds] 12:12:46 *** zeknurn` is now known as zeknurn 12:26:21 *** DabuYu [DabuYu@128.250.79.238] has quit [Ping timeout: 480 seconds] 12:26:29 *** DabuYu [DabuYu@128.250.79.238] has joined #openttd 12:32:25 *** Supercheese is now known as Guest4831 12:32:29 *** Supercheese [~Superchee@cpe-76-178-136-186.natnow.res.rr.com] has joined #openttd 12:37:34 *** Guest4831 [~Superchee@cpe-76-178-136-186.natnow.res.rr.com] has quit [Ping timeout: 480 seconds] 12:41:50 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 12:55:25 <raincomplex> some of my trains are going right through their current destination station (full load) to the depot after it 12:56:12 <Eddi|zuHause> yes. put the depot before the station. 12:56:24 <Eddi|zuHause> or use a "service at depot" order 12:56:37 <andythenorth> or turn off breakdowns... 12:56:50 <raincomplex> hm 12:57:09 <raincomplex> with depots before the stations, i was having problems with other trains coming in there just to service 12:57:14 <raincomplex> and getting stuck 12:57:19 <raincomplex> e.g. behind a bunch of loading trains 12:57:43 <Eddi|zuHause> then put the depot at the mainline. 12:57:50 <Eddi|zuHause> or use a "service at depot" order 12:58:21 * Eddi|zuHause has a "... oder bei OBI" flashback 12:59:08 <raincomplex> i think service at depot order might be the best 12:59:14 <raincomplex> i did forget about those 12:59:34 <raincomplex> luckily my trains are all sharing orders... 12:59:40 <andythenorth> with breakdowns off, this becomes a non-issue 12:59:50 <andythenorth> although some people consider it cheating :) 13:01:28 <raincomplex> it is a neat mechanic though 13:01:40 <raincomplex> no pun intended 13:02:06 <raincomplex> my depot layout is regular enough that i think manual maintenance is probably a good option 13:03:47 <Eddi|zuHause> you can also do "pathfinder hacks", e.g. lowering the penalty threshold for finding depots, or increasing the penalty to this particular depot (e.g. by placing reverse path signals or road crossings) 13:04:29 <Eddi|zuHause> but this seems a bit fragile 13:06:26 <raincomplex> hm 13:15:32 *** sla_ro|master [slamaster@95.76.27.245] has joined #openttd 13:15:49 <raincomplex> is there a way to limit the capacity of a depot? 13:15:58 <V453000> XD 13:16:04 <V453000> why would you want to do that 13:16:21 <raincomplex> trains are stacking up in my depot 13:16:24 <raincomplex> heh 13:16:37 <andythenorth> invert the problem 13:16:40 <andythenorth> provide more depots 13:16:46 <V453000> ^ 13:17:06 <andythenorth> also build short trains 13:17:21 <V453000> you can even make it so that trains coming to the depot are less likely to enter it, if trains are leaving the depot 13:17:22 <raincomplex> my trains are all 3 tiles long 13:17:23 <andythenorth> due to the 38mph depot penalty speed 13:17:30 <andythenorth> 3 tiles is short :) 13:17:34 <raincomplex> :D 13:17:58 <raincomplex> they'll pick an emptier depot over a full one? 13:18:01 <andythenorth> no 13:18:10 <raincomplex> or just randomly if they're the same distance? 13:18:12 <b_jonas> raincomplex: give explicit service in depot orders 13:18:18 <b_jonas> different ones to each train 13:18:21 <raincomplex> ah to distribute them 13:18:40 <raincomplex> hm 13:18:42 <andythenorth> play it like TTD :P One track per train, one depot per track 13:18:45 <andythenorth> problem solved 13:18:52 <raincomplex> that might be painful in my case 13:19:01 <V453000> http://blog.openttdcoop.org/files/blog/V453000/Example_G.png 13:19:04 <V453000> priority at depot 13:19:04 <b_jonas> what? TTD doesn't play like that 13:19:06 <raincomplex> i've got 41 trains on this station 13:19:27 <V453000> explicit orders are bad 13:19:31 <andythenorth> b_jonas: eh? Did you play it? :) 13:19:33 <V453000> better do it by signals, you can easily expand that 13:19:35 <b_jonas> yes 13:19:46 <b_jonas> it has plain signals and one-way signals 13:19:53 <andythenorth> the winning strategy for trains is one track per train 13:20:06 <b_jonas> maybe, but I've ran two trains on a track in TTD 13:20:10 <andythenorth> ah, TTO 13:20:11 <andythenorth> my bad 13:20:16 <andythenorth> sorry 13:20:16 <b_jonas> or three trains on a double track 13:20:20 <b_jonas> oh, I haven't played TTO 13:20:29 <raincomplex> i haven't messed with priority yet 13:20:33 <raincomplex> i probably should learn that 13:21:27 <V453000> you can do a lot of stuff with depots 13:21:37 <b_jonas> does it have no signals? 13:21:55 <raincomplex> there's a one-way in and one-way out 13:22:09 <raincomplex> the out track tends to back up though 13:22:18 <V453000> http://blog.openttdcoop.org/2012/02/16/advanced-building-revue-11-refit-stations/ 13:22:21 <raincomplex> actually i bet if i can get the out track flowing better, the depot will clear itself up 13:22:24 <V453000> part about game 213 13:22:36 <V453000> http://blog.openttdcoop.org/files/blog/V453000/abr11_rorodepot_1.png 13:22:52 <V453000> signals like that will make depots empty up much easier 13:23:24 <raincomplex> can it be done path-only? 13:23:28 <V453000> it is because the entering train needs to get 2 green signals before it gets to the depot block, at which point the depotted train gets out earlier 13:23:30 <V453000> no 13:23:49 <raincomplex> so is that entry-combo-exit 13:23:52 <raincomplex> or rather 13:23:52 <V453000> yes 13:23:56 <raincomplex> entry-combo-depot-exit 13:24:06 <V453000> yes 13:24:07 <raincomplex> i'll give that a shot 13:24:33 <V453000> with the exit the depot basically has just capacity for 1 train I think even 13:24:40 <V453000> without it it just helps to empty depots 13:30:55 <V453000> so if you want to go ultra realistic or whatnot, you can make 3 tile long depots and place the exit signal there XD 13:31:50 <planetmaker> <andythenorth> or turn off breakdowns... <-- not necessarily. You can enable servicing with breakdown off :) 13:31:56 <planetmaker> hi hi also :) 13:32:04 <andythenorth> hi 13:32:26 <raincomplex> the entry/combo/exit signals seem to have done the trick :D 13:34:56 <V453000> sure they did :) 13:35:08 <V453000> hy pm 13:42:51 <Eddi|zuHause> <andythenorth> play it like TTD :P One track per train, one depot per track <-- i never played TTD this way. 13:45:01 <Eddi|zuHause> and also not TTO, after a few days of playing the demo. 13:45:18 <V453000> andythenorth is incompatible with playing the game 13:45:35 <Eddi|zuHause> in fact, i played one-way double track with TTO. 13:46:02 <andythenorth> was there some signal trick? 13:46:17 <andythenorth> after a few crashes in games with marginal profits, I stuck to one line per train 13:47:04 <planetmaker> making trains go in circles w/o having them getting stuck was very tricky. It worked marginally. And often not even that :P 13:47:37 <Eddi|zuHause> it was fragile, mostly due to the turn-around-when-waiting behaviour 13:48:07 <Eddi|zuHause> also, you can't have depots... 13:48:22 <Eddi|zuHause> or depots are very tricky 13:48:26 <andythenorth> one day Iâll figure out how to make TextWrangler run the python linter 13:48:34 <andythenorth> then I can stop compiling to find my syntax errors 13:49:47 <planetmaker> andythenorth, doesn't it have one by default? 13:49:59 <andythenorth> not afaict 13:50:12 <andythenorth> oh maybe it does 13:50:35 <andythenorth> ho, yes 13:50:36 <andythenorth> thanks 13:50:54 <andythenorth> I have been occasionally trying to make the pyflakes integration work for last year or so 13:50:57 <andythenorth> waste of time 13:51:48 <planetmaker> :) 13:53:25 <andythenorth> also one day Iâll stop trying to iterate None 14:00:06 <raincomplex> python <3 14:05:49 *** zeknurn [~sup@hd9483b0c.seveveb.dyn.perspektivbredband.net] has quit [Read error: Connection reset by peer] 14:07:07 *** zeknurn [~sup@hd9483b0c.seveveb.dyn.perspektivbredband.net] has joined #openttd 14:07:44 *** Pensacola [~quassel@c80094.upc-c.chello.nl] has joined #openttd 14:24:25 *** OsteHovel [~OsteHovel@90.149.87.140] has joined #openttd 14:25:19 *** Eddi|zuHause2 [~johekr@p57BD491B.dip0.t-ipconnect.de] has joined #openttd 14:26:38 *** sla_ro|master2 [slamaster@95.76.27.245] has joined #openttd 14:29:04 *** Klanticus_ [~quassel@179.234.179.109] has joined #openttd 14:29:42 *** yorick_ [~yorick@ip51cd0513.speed.planet.nl] has joined #openttd 14:30:16 *** Netsplit resistance.oftc.net <-> larich.oftc.net quits: luaduck, Klanticus, XeryusTC, __ln__, ^Spike^, yorick, sla_ro|master, CosmicRay, dihedral, TheIJ, (+4 more, use /NETSPLIT to show all of them) 14:30:24 *** yorick_ is now known as yorick 14:30:34 *** Netsplit over, joins: __ln__ 14:32:37 *** CosmicRay [~jgoerzen@glockenspiel.complete.org] has joined #openttd 14:32:46 *** ToBeFree [ToBeFree@00019d36.user.oftc.net] has joined #openttd 14:33:04 *** ^Spike^ [~Spike@188.cimarosa.openttdcoop.org] has joined #openttd 14:33:07 *** luaduck_zzz [~luaduck@0001c465.user.oftc.net] has joined #openttd 14:33:31 *** XeryusTC [~XeryusTC@000128e4.user.oftc.net] has joined #openttd 14:33:33 *** luaduck_zzz is now known as luaduck 14:33:34 *** tyteen4a03 [tyteen4a03@daedalusx.net] has joined #openttd 14:33:35 *** dihedral [~dih@znc.dihedral-server.de] has joined #openttd 14:33:45 *** Stimrol [~Stimrol@46-239-219-51.tal.is] has joined #openttd 14:34:21 *** TheIJ [~rita@188.226.187.103] has joined #openttd 14:53:04 *** DanMacK [~3fee8a84@188.cimarosa.openttdcoop.org] has joined #openttd 14:55:58 <raincomplex> does the pathfinder not take into account trains waiting on track up ahead? 14:57:57 <planetmaker> it does take them into account. But they're not a dead end, thus trains can wait for them to continue 14:59:21 *** Eddi|zuHause2 is now known as Eddi|zuHause 14:59:32 <raincomplex> maybe it's this bridge 14:59:38 <raincomplex> let me get a screenshot up 15:00:00 <planetmaker> basically everything has its own penalty. curves, bridges, tunnels, signals, trains, level crossings, waypoints, stations 15:00:39 <raincomplex> http://raincomplex.net/dump/trains.png 15:00:44 *** liq3 [liq3@CPE-120-147-178-81.gdfw1.lon.bigpond.net.au] has joined #openttd 15:00:59 <raincomplex> they're using those first four platforms almost exclusively 15:01:12 <raincomplex> is it that the entry path is just too long on the 5th and 6th perhaps? 15:01:23 *** liq3 [liq3@CPE-120-147-178-81.gdfw1.lon.bigpond.net.au] has quit [] 15:01:39 <raincomplex> maybe i need to just reorganize it to be cleaner 15:03:18 <planetmaker> they have very different paths lengths 15:07:21 <Flygon> planetmaker: The way you make the pathfinder sound makes it sound like it dislikes sexy woman 15:07:38 <Flygon> What with those curves, bridges, tunnels, signals... 15:08:03 <planetmaker> lol 15:08:16 <planetmaker> you'll also learn that those come with a penalty :P 15:09:04 <V453000> raincomplex: answer is waiting bays 15:09:06 <Flygon> Yeah. Most woman aren't bidirectional :( 15:09:23 <V453000> http://blog.openttdcoop.org/2010/09/28/advanced-building-revue-07-stations/ 15:09:57 <V453000> http://blog.openttdcoop.org/files/blog/V453000/ABR07_buffer_01.png 15:11:04 <raincomplex> i did this http://raincomplex.net/dump/trains2.png 15:14:13 <Flygon> Thank goodness I don't show #Openttd my train station designs 15:14:18 <raincomplex> do trains decide where they want to go when they reach a signal, or can they change their minds while they sit there 15:14:24 <Flygon> I'd be punched in the face then convicted of crimes against humanity 15:14:28 <raincomplex> haha 15:15:01 <raincomplex> i am just a newb 15:15:27 <raincomplex> in particular this merge on the outgoing tracks and then splitting to two depots isn't really working too well 15:15:28 <raincomplex> gotta fix that 15:20:05 *** liq3 [liq3@CPE-120-147-178-81.gdfw1.lon.bigpond.net.au] has joined #openttd 15:20:48 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth] 15:24:22 <planetmaker> raincomplex, at every junction a train evaluates its path anew 15:24:31 <planetmaker> signals have nothing to do with that 15:24:49 <planetmaker> though on a path signal they need to reserve a path to the next signal 15:25:02 <planetmaker> thus they won't proceed further in their path at that point 15:27:21 <raincomplex> when does a train sitting at a path signal pick its path? 15:29:15 <raincomplex> only when it arrives? or does it keep checking while things are changing up ahead / trains moving through etc 15:31:06 <planetmaker> it re-evaluates the path every so often 15:32:49 <raincomplex> cool 15:35:23 *** Kurimus [~stabbity@dsl-tkubrasgw2-54f816-197.dhcp.inet.fi] has quit [] 15:44:58 *** Kurimus [~stabbity@dsl-tkubrasgw2-54faa7-102.dhcp.inet.fi] has joined #openttd 15:51:01 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 15:56:41 *** roidal [~roland@cm140-210.liwest.at] has joined #openttd 15:57:19 * OsteHovel likes the new hirarcial grouping of vehicles ;-) 16:01:14 *** Quatroking [~Quatrokin@ip226-139-211-87.adsl2.static.versatel.nl] has joined #openttd 16:21:11 *** shirish [~quassel@117.195.116.42] has joined #openttd 16:26:57 *** Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has joined #openttd 16:27:00 *** mode/#openttd [+o Alberth] by ChanServ 16:28:15 *** Progman [~progman@p57A1831B.dip0.t-ipconnect.de] has joined #openttd 17:17:30 *** Progman [~progman@p57A1831B.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 17:25:05 * andythenorth runs pyflakes 17:25:10 <andythenorth> with interesting results 17:26:36 *** TheMask96 [martijn@pride.vhost.ne2000.nl] has quit [Ping timeout: 480 seconds] 17:27:39 *** TheMask96 [martijn@greed.vhost.ne2000.nl] has joined #openttd 17:30:30 <Alberth> you can also try pylint, except it checks for pep-8 style code byt default 17:30:43 <andythenorth> hah 17:30:49 <andythenorth> I would fall out with that a lot 17:30:57 <andythenorth> hmm pyflakes hates my FIRS by design 17:31:07 <andythenorth> I import a lot of modules as a way of âbuildingâ the app 17:31:11 <Alberth> you can configure pylint too :) 17:31:12 <andythenorth> but then I donât call them in any way 17:31:18 <andythenorth> so theyâre all reported 17:31:29 <Alberth> ah, yeah, pylint also doesn't like that :) 17:31:32 <andythenorth> in firs.py 17:31:34 *** roidal [~roland@cm140-210.liwest.at] has quit [Quit: WeeChat 1.0.1] 17:31:38 <andythenorth> change FIRS design? :P 17:32:24 <Alberth> the idea is that an import shouldn't do anything important 17:32:50 <Alberth> except perhaps initialization of the imported module itself 17:33:09 <andythenorth> apparently the âsolutionâ to this is to assert the module after import 17:33:12 <andythenorth> which isâŠinteresting 17:33:27 <Alberth> how do you find which modules are imported afterwards? 17:33:37 *** samu [~oftc-webi@a85-139-81-208.cpe.netcabo.pt] has joined #openttd 17:37:18 <andythenorth> they use that dubious self registering pattern I like so much 17:37:33 <andythenorth> so the imports just cause them to appear in a list 17:37:34 <samu> hello 17:37:40 <andythenorth> as instances 17:37:41 <Alberth> you register in some common module or so? 17:37:44 <andythenorth> yes 17:37:50 <Alberth> more imports :p 17:38:19 <andythenorth> so industries get stuffed into registered_industries for example 17:38:30 <andythenorth> I suspect itâs a highly wrong approach, but it works 17:38:34 <andythenorth> and it has few LOC 17:38:37 <andythenorth> and /me understands it 17:39:21 <andythenorth> I have a horrible feeling that trying to clean it up will result in loops that call __import__ 17:39:26 <andythenorth> which seemsâŠalso wrong 17:40:15 <andythenorth> but as I am doing a big rewrite of FIRS, now could be the time to fix it, if itâs broken 17:40:15 <samu> I plan to do some other NewGRF thingy, to prevent some vehicles expiring past 2050, such as helicopters, some ideas I had years ago 17:40:16 <Alberth> the simplest fix is to import all, and then register in a call into the module, or by pulling out some variable from the module 17:40:32 <samu> has anyone done such thing? 17:40:36 <andythenorth> registering the call seems to just double the LOC 17:40:40 <andythenorth> explicit is better I guess :P 17:40:44 <Alberth> but you need to list all module names twice at least 17:41:16 <andythenorth> samu: just turn on âvehicles never expire' 17:41:21 <andythenorth> solved 17:41:33 <samu> gah, horrible workaround 17:41:34 <Alberth> yep, the zen of python: https://www.python.org/dev/peps/pep-0020/ :) 17:42:05 <andythenorth> import this 17:42:13 <andythenorth> import this would fail pyflakes 17:42:18 <andythenorth> :P 17:42:41 <Alberth> the nicest imports are the from__future__ import .... :) 17:43:01 <Alberth> not sure if python 3 still has it 17:43:40 <andythenorth> I wish I could do import working_code 17:43:50 <Alberth> samu: you should check how you specify model life of a vehicle, I suspect it always has a finite length 17:44:07 <Alberth> you can, but you first have to write it :( 17:44:30 <andythenorth> I want to import it from the future though 17:44:32 <andythenorth> when itâs done already 17:44:37 <Alberth> :D 17:45:23 <DorpsGek> Commit by translators :: r27142 trunk/src/lang/turkish.txt (2015-02-10 17:45:15 UTC) 17:45:24 <DorpsGek> -Update from WebTranslator v3.0: 17:45:25 <DorpsGek> turkish - 77 changes by wakeup 17:45:35 <andythenorth> Alberth: so this is the prime offender http://dev.openttdcoop.org/projects/firs/repository/entry/src/firs.py 17:45:51 <andythenorth> after âfrom cargos import beans' 17:45:57 <andythenorth> I could just call âbeans.register()' 17:46:01 <andythenorth> which would be fine 17:46:09 <andythenorth> just seems a little redundant 17:46:21 <andythenorth> makes me tempted to put __import__ and register() into a loop 17:46:29 <andythenorth> and provide a list of modules 17:46:43 <Alberth> yeah, that would be better here, perhaps 17:46:54 <Alberth> having a double list is also bad 17:47:43 <Alberth> hmm, can't you generate each industry separately? 17:47:48 <andythenorth> maybe 17:47:57 <andythenorth> Iâm sure there are alternative ways to skin this cat 17:48:30 <Alberth> then you could solve this at OS level, by concatenating all output into one nml file 17:49:28 <Alberth> for fname in industries/*.py; do python $fname ; done > industries.nml 17:50:17 * andythenorth considers 17:50:32 <andythenorth> I think it obviates the point of using python 17:50:42 <andythenorth> might as well just write the nml in that case, I think 17:51:14 <andythenorth> canât render the docs 17:51:22 <andythenorth> canât have industries refer to each other 17:51:45 <Alberth> ok 17:51:55 <andythenorth> the âfoo.register()â method looks increasingly simple 17:51:56 <Alberth> was just a thought 17:52:02 <andythenorth> thoughts are useful :) 17:52:08 <andythenorth> always worth trying a new approach 17:56:53 *** glx [~glx@000128ec.user.oftc.net] has joined #openttd 17:56:56 *** mode/#openttd [+v glx] by ChanServ 17:57:41 <Alberth> cargoes look like a INI file to me 17:58:55 <andythenorth> maybe 17:59:07 <andythenorth> I kind of hated ini parsing when I built FISH that way 17:59:11 <andythenorth> I binned it in the end 17:59:36 <Alberth> ? import ConfigParser ? 17:59:39 <andythenorth> yeah 17:59:46 <andythenorth> and then split on magic characters 17:59:48 <andythenorth> etc 17:59:53 <Alberth> hmm, right 17:59:59 <andythenorth> I donât think Iâd ever use ConfigParser again 18:00:03 <andythenorth> json maybe 18:00:37 <andythenorth> cargos do look like python file is a bit overkill 18:00:42 <Alberth> that's mostly the same idea 18:00:59 <Alberth> industries have the sprite layouts, which is tricky 18:01:01 <andythenorth> but then again, the python markup is actually about as terse as the INI or json 18:01:08 <andythenorth> and thereâs no need for a parser 18:01:28 <Alberth> you could throw all cargoes together in one file 18:03:29 <andythenorth> yeah 18:03:43 <andythenorth> import cargos :P 18:04:03 <andythenorth> that has appeal 18:05:01 <Alberth> it's a lot of small little details, don't think you can do much 18:05:26 <andythenorth> cargos in one file is valid 18:05:37 <andythenorth> industries, I just need to explicitly call register() 18:05:39 <andythenorth> solved 18:05:42 <andythenorth> fewer magic 18:06:17 <andythenorth> magic registration is probably bad magic 18:06:45 <andythenorth> maybe I should write a code generator for the python files? 18:07:11 <Eddi|zuHause> there are probably worse things that autoregistering modules 18:07:19 <Eddi|zuHause> *than 18:07:30 <Alberth> the trouble is that somewhere you still need to specify all those little details 18:08:00 <Alberth> and it doesn't get much smaller then key = value stuff, which you already have, mostly 18:08:06 <Alberth> *than 18:09:18 <andythenorth> the thing is that it works, and itâs easy to maintain 18:09:23 <andythenorth> but pyflakes hates me 18:09:28 <andythenorth> :) 18:09:36 * andythenorth will think about it 18:09:43 <Alberth> the python syntax is a bit of useless here and there, but on the other hand, if you move it to eg INI, where you totally lack python power, it gets worse 18:10:02 <Alberth> so imho pyflakes is just wrong here :) 18:10:30 <Alberth> it's just that you write special python code, which doesn't follow usual code patterns :) 18:11:08 <andythenorth> Iâll drop auto-register 18:11:11 <andythenorth> itâs bad magic 18:11:14 <andythenorth> pyflakes will be happy 18:11:23 <Alberth> but you will be sad 18:11:29 <andythenorth> and Iâll commit bugs by forgetting to add an in industry in two places 18:11:39 <Alberth> so don't do it 18:12:27 <Alberth> you can also make pyflakes happy by writing loads of normal python code, and mingle that in your files :p 18:12:50 *** sla_ro|master2 [slamaster@95.76.27.245] has quit [Ping timeout: 480 seconds] 18:13:48 <andythenorth> Iâll think on, there will be a solution 18:14:28 <Alberth> comlain with the pyflakes authors, challenge them to come up with a good solution :p 18:14:33 <Alberth> *complain 18:14:33 <andythenorth> ha ha 18:14:54 <andythenorth> I think the solution would be âdonât let andythenorth write code" 18:17:10 <Alberth> total python lines is 18717, firs.nml is 379984 lines, you must be doing something right :) 18:17:45 <samu> in the nml wiki, what you call of ID, is that the same as identifier? 18:17:52 <samu> <identifier>? 18:18:33 <Alberth> can you give a page or the nml fragment you talk about? 18:18:35 <Eddi|zuHause> sometimes 18:18:43 <Alberth> "nml wiki" is very big 18:19:08 <Eddi|zuHause> ID can also refer to a number 18:19:16 <Eddi|zuHause> depending on context 18:20:10 <samu> http://newgrf-specs.tt-wiki.net/wiki/NML:Vehicles#Properties_common_to_all_vehicle_types 18:20:48 <samu> there is no page for engine_override? 18:21:23 <Alberth> in that table there is no "id" 18:22:07 * planetmaker considers editing that page and removing the section "TTDPatch / engine pool disabled" 18:22:17 <Eddi|zuHause> samu: that ID is a number that will be used for internal handling 18:22:21 <Alberth> http://newgrf-specs.tt-wiki.net/wiki/NML:Overriding_vehicles_in_other_NewGRFs <-- I must be blind then 18:22:50 <planetmaker> that page is even linked from the first page 18:23:16 *** sla_ro|master [slamaster@95.76.27.245] has joined #openttd 18:23:21 *** quorzom [~quorzom@cable-78-35-98-177.netcologne.de] has joined #openttd 18:23:53 <samu> i dont want to override an engine from another newgrf, but from the original openttd 18:23:55 <Alberth> planetmaker: move the entire engine pool to the bottom, or somewhere else? 18:23:59 * andythenorth puts in a load of asserts to shut up pyflakes, that will solve it 18:24:19 <samu> model_life: VEHICLE_NEVER_EXPIRES; 18:24:28 <samu> want to add this to some vehicles 18:24:32 <Alberth> so worried about a tool, eh, andy :) 18:24:33 <Eddi|zuHause> samu: then look at the list of original vehicles, and find the ID number there 18:24:43 <samu> but i'm trying to figure out their... that 18:24:46 <samu> ty 18:25:19 <andythenorth> Alberth: itâs silly I know, but I want to learn how to work with pyflakes 18:25:27 <andythenorth> and it is no use if the errors are long and spurious 18:25:54 <Alberth> ok, acknowledging is a good first step :p 18:26:00 <andythenorth> distorting the code to please the validator is stupid 18:26:17 <andythenorth> the other validators I use have suppression options, either in the config, or via comments in the code 18:26:25 <Alberth> I just ignore or delete the offending complaints :p 18:26:29 <Eddi|zuHause> samu: you did see this page, right? http://newgrf-specs.tt-wiki.net/wiki/NML:Additional_references 18:26:48 <planetmaker> Alberth, yeah, that likely is a good idea. Though the paragraph above explains how it usually works. Which is good info 18:26:59 <samu> oh, i haven't 18:27:00 <andythenorth> pyflakes may have suppression options, but as it has no docs, who knows eh? 18:27:02 <samu> very handy 18:27:51 <andythenorth> maybe I should try flake8 18:28:40 <andythenorth> that has suppression, and built in hooks for git and hg 18:29:06 <Alberth> euhm, why would it need git/hg? 18:29:44 <andythenorth> pre-commit 18:29:58 <Alberth> :O nice 18:30:08 <andythenorth> the reason I am learning it is that it has just become an obligatory tool for actual work 18:30:17 <andythenorth> anything failing pyflakes is automatic revert and yelling 18:30:23 <Eddi|zuHause> andythenorth: i think you are overreacting to that warning... 18:30:23 <andythenorth> so I have it set up on a git commit 18:31:01 <Alberth> sounds like a bit blind trust on a tool 18:31:24 <Alberth> in my experience, coding style is a guide, ignore it if there are good reasons 18:32:19 <andythenorth> well 18:32:40 <andythenorth> because itâs ultimately my company, I find it useful to find out how useful each validator is 18:32:47 *** jjavaholic [~jjavaholi@grahamg63.plus.com] has joined #openttd 18:32:56 <andythenorth> and how much shouting each one is worth 18:33:04 <Alberth> oh, there is nothing wrong with using them 18:33:05 <andythenorth> some are enforced more strictly than others 18:33:49 <Alberth> I just have some trouble with blindly accepting the idea of a tool as the one and only truth 18:34:17 <andythenorth> usually I wouldnât, and usually we find validators which can be carefully suppressed 18:34:25 <Alberth> you get these Java nanny ideas, thy shall not write dead code 18:34:33 <andythenorth> like the html validator we use which is plain wrong about some html 5 18:34:47 <andythenorth> and the accessibility validator we use which is plain wrong about specific cases 18:35:00 <Eddi|zuHause> *thou 18:35:14 <Alberth> fair enough eddi :) 18:35:22 <andythenorth> language validation 18:35:25 <andythenorth> as a service :P 18:35:26 <andythenorth> by Eddi|zuHause 18:35:34 <Eddi|zuHause> (thou/thy/... is much easier if you have german grammar in mind :p) 18:36:12 <Alberth> hmm, last german class was in 1983 or so, I think 18:36:40 <Eddi|zuHause> i don't know enough about dutch grammar to judge how it works there 18:36:55 <Eddi|zuHause> well, technically i know nothing about dutch grammar 18:37:04 <Alberth> no, even earlier, 1982 18:37:06 <andythenorth> technically 18:37:36 <Eddi|zuHause> Alberth: that was about when i spoke my first german word :p 18:42:24 <Alberth> I quite liked german, but I had to study french instead :( Total disaster, that language :p 18:43:23 *** frosch123 [~frosch@frnk-4d01a125.pool.mediaways.net] has joined #openttd 18:43:29 <Alberth> hi hi 18:44:30 <frosch123> hai 18:47:05 <andythenorth> quak 18:47:29 <jjavaholic> I have long had problems creating efficient road vehicle goods transportation I I thought one way roads would allow for two tracks of road vehicles and for more traffic down one road/carriage but this doesn't seem to work, I'm looking for ideas how to rectify this. to give you an idea I have a station with 600 vehicles all heading to the same end point 18:48:41 <jjavaholic> I thought one way roads were meant to deal with broken down road vehicles better 18:51:01 <Alberth> maybe with the default RVs 18:51:17 <Alberth> but all newgrf RVs are articulated, and cannot overtake 18:51:53 <samu> can i use these characters when defining a title? 18:51:55 <samu> TITLE :SH '125' (Diesel) 18:52:26 <Alberth> samu: in a .lng file? yes 18:52:36 <samu> on custom tags 18:53:07 <Alberth> hmm, don't know 18:53:23 <samu> ok i will try 18:53:26 <Alberth> you can try with a dummy name like TITLE: blabla 18:53:52 <Alberth> if that works, and your text doesn't, you know that the likely source is the text 18:55:53 <andythenorth> so I pleased pyflakes with lots of asserts :) http://dev.openttdcoop.org/projects/firs/repository/revisions/af90caa64ae3/entry/src/firs.py 18:56:01 <andythenorth> really Iâm going to rewrite the approach though 18:56:07 <samu> â[Knmlc ERROR: "expire.nml", line 9: Item parameter 2 'name' should be an identi 18:56:12 <samu> :( 18:56:20 <andythenorth> talking to someone somewhere else, Iâm violating the rule of âimports should change nothing' 18:56:27 <samu> item (FEAT_TRAINS, 22) { 18:56:32 <samu> what's wrong 18:56:52 <andythenorth> the import isnât even idempotent :P 18:57:01 <andythenorth> import industry multiple times, set will break 18:57:05 <andythenorth> I think 18:57:09 <Alberth> samu: "identifier" is a name, and 22 is not a name 18:57:21 <Alberth> andythenorth: imports are performed one time only 18:57:32 <samu> 22 is the ID of SH '125' (Diesel) 18:57:35 <andythenorth> oh 18:57:37 <samu> confused 18:57:37 <andythenorth> I see :) 18:57:54 <andythenorth> thatâs handy 18:58:29 <Alberth> ie on the first import, the file is loaded and stored, all next attempts to import it will return the stored reference 18:58:41 *** gelignite [~gelignite@i528C3792.versanet.de] has joined #openttd 18:58:53 <andythenorth> module registry seems to be a thing 18:59:36 <samu> hmm, then how do I mention the sh 125? 19:00:30 <Alberth> samu: http://newgrf-specs.tt-wiki.net/wiki/NML:Item, please read the first line of text too 19:01:03 <Alberth> there is a lot of information in the text :) 19:01:13 <planetmaker> hehe :) 19:04:49 *** Pensacola [~quassel@c80094.upc-c.chello.nl] has quit [Remote host closed the connection] 19:05:19 <samu> item (FEAT_TRAINS, sh_125_diesel, 22) { 19:05:21 <samu> this? 19:06:05 <NGC3982> So, what 32bpp NewGRF's should one include in a proper 32bpp server, except RAWR, YETI and the Pinapple trains? 19:06:22 <andythenorth> ho ho ho, this is now spectacularly ugly 19:06:23 <andythenorth> http://dev.openttdcoop.org/projects/firs/repository/revisions/12985214288e/entry/src/firs.py#L76 19:06:42 <andythenorth> that is absolutely going to increase my mistakes rate, itâs totally impenetrable 19:06:47 <planetmaker> egrvts 19:07:10 <andythenorth> compared to http://dev.openttdcoop.org/projects/firs/repository/revisions/97afa4ec9abc/entry/src/firs.py#L75 19:07:24 <andythenorth> still, itâs much more pythonic now :) 19:07:38 <planetmaker> samu, there's *loads* of example code available for the basics. Including a tutorial at tt-wiki.net 19:08:32 * andythenorth feels a loop against __import__ might appear in a forthcoming commit 19:09:26 <Alberth> I'd add an empty line after each pair 19:09:44 <Alberth> the question is how often do you change that file? :) 19:10:11 <Alberth> it may a bit long, but it's trivial to change 19:13:15 <samu> yay, it works, and i have no idea why exactly, but it works 19:13:30 <samu> SH '125' survived past 2050 19:14:25 *** Wolf01 [~wolf01@0001288e.user.oftc.net] has joined #openttd 19:14:50 <Wolf01> hello o/ 19:15:07 <raincomplex> andythenorth, i was about to say 19:15:19 <raincomplex> that really looks like it could use some automation (; 19:15:40 <samu> i need an opinion 19:15:55 <samu> what diesel engine should be kept past 2050? 19:16:20 <samu> Dash or SH 125? I did for SH 125, but the newest model is Dash 19:19:26 <samu> Personaly I'm more inclined towards SH 125 19:19:51 <andythenorth> Alberth: that file is changed for a few weeks per year :) 19:19:54 <samu> it's faster, and the 'successor' of dash is the Millenium Z1 19:19:58 <andythenorth> and the changes are to add a few lines 19:22:13 <samu> i have other question, about Asia star, sometimes it expires in 2050, and sometimes it doesn't and stays in-game forever 19:22:23 <samu> how come? 19:28:47 <samu> http://newgrf-specs.tt-wiki.net/wiki/NML:Vehicles#Engine_life_cycle 19:31:42 <samu> a random amount between 31 months and 17 years is added to the model life 19:31:54 <samu> explain me this better with an example 19:33:23 <peter1138> Well, see, a random value is added to the engine life cycle... 19:33:26 <peter1138> And it's random... 19:34:42 <samu> i need to know model_life value for AsiaStar, the default value 19:34:48 <samu> where can i find that 19:35:41 <peter1138> In one of the table files in the source code. 19:35:59 <samu> oh, good idea, will search 19:37:03 <planetmaker> https://wiki.openttd.org/Train_Comparison might be right. w/o guarantee 19:37:38 * NGC3982 looks for 32bpp station sets 19:39:13 <planetmaker> good luck, NGC3982 19:39:14 <samu> 502 Bad Gateway 19:39:43 <planetmaker> there was an isr-spin-off. but the original author didn't want that; thus it's only in the forums for now 19:39:55 <NGC3982> I see. 19:40:12 <NGC3982> I guess there are no particular reason to why such NewGRF does not exist properly yet? 19:40:29 <NGC3982> reasons*. 19:40:54 <planetmaker> dunno, possibly not 19:40:59 <frosch123> just noone did it 19:41:01 <planetmaker> maybe one though: nml doesn't do stations yet 19:41:03 * NGC3982 waits patiently 19:41:03 <samu> that comparison doesn't have model_life, but vehicle_life 19:41:14 <samu> it's not the same thing 19:41:14 <frosch123> and adding 32bpp to existing 8bpp sets is likely never going to work 19:41:39 <frosch123> it makes no sense if a grf features two different art styles 19:41:57 <samu> http://svn.openttd.org/ 19:42:01 <samu> doesn't open :( 19:42:05 <NGC3982> Ok. 19:43:05 <planetmaker> use http://hg.openttd.org, samu 19:43:20 <frosch123> and CATS is nowhere near done :) 19:44:18 <planetmaker> yeah, sadly 19:46:43 <V453000> more like dead 19:47:04 <V453000> I will try to make some more graphics and lure Elyon back again 19:47:18 <V453000> this time I at least have a reliable contact to do so, unlike last year :) 19:47:37 <planetmaker> doesn't sound dead then ;) 19:49:46 <samu> found it 19:49:48 <samu> http://hg.openttd.org/openttd/trunk.hg/file/25cce47a0745/src/table/engines.h 19:49:52 <samu> it's 50 19:50:34 <samu> becomes available in 26298 days after 1920-01-01 ... oh great :( 19:52:12 *** Celestar1 [~Celestar@mnch-5d85cf5f.pool.mediaWays.net] has joined #openttd 19:54:32 <samu> 1992? 19:56:47 <Alberth> @calc 26298 / 365 19:56:47 <DorpsGek> Alberth: 72.0493150685 19:56:51 *** Celestar [~Celestar@mnch-5d85bcec.pool.mediaWays.net] has quit [Ping timeout: 480 seconds] 19:57:05 <Alberth> looks like it 19:57:36 <samu> a random amount between 31 months and 17 years is added to the model life 19:58:38 <samu> 1992+50+(random value from 31 months to 17 years) 19:58:48 <samu> I see now 20:04:57 <andythenorth> pyflakes is sad about my python 2 code, because Iâm running it under python 3 :) 20:05:04 * andythenorth would like to convert 20:05:30 <Alberth> that fails? 20:06:43 <NGC3982> 20:41 <@NGCone> Now playing on NGCTTD #1 32bpp (use zBase) RAWR+YETI+Fruity Trains 1901>1960 (Version 1.4.4) 20:06:58 <V453000> :0 20:06:58 * NGC3982 solved the non-existance of 32bpp station NewGRF's. 20:07:12 <NGC3982> Let's hope players will understand. They usually don't. :( 20:08:13 <V453000> just add 8bpp stations :) 20:09:02 <andythenorth> Alberth: invalid syntax on prints ;P 20:09:19 <samu> i'm confused about these 3 phases 20:09:31 <Alberth> andythenorth: use 2to3? :) 20:09:37 <andythenorth> considering it 20:09:45 <andythenorth> but it had a lot of problems last time I tried 20:09:49 <andythenorth> in code I donât understand 20:10:20 <samu> i suck at math, especially when dates are involved 20:10:26 <andythenorth> oh it finds all the python in the templates iirc 20:10:30 <andythenorth> that trips it up :) 20:10:43 <samu> can someone explain me this part a bit? http://newgrf-specs.tt-wiki.net/wiki/NML:Vehicles#Engine_life_cycle 20:10:53 <Alberth> andythenorth: :) 20:11:00 <samu> model_life for AsiaStar is 50 20:11:12 <samu> and the vehicle is available in 1992 20:11:43 <samu> so, when will it retire? what would be the years which it can retire? 20:14:01 *** shirish [~quassel@0001358e.user.oftc.net] has quit [Read error: Connection reset by peer] 20:14:08 * andythenorth has stupid imports 20:14:39 <Alberth> samu http://imgur.com/Piqx2hr 20:16:20 <samu> what am i looking at? :o 20:17:06 <samu> okay, at the end of phase 3, the vehicle disappears from purchase list 20:17:15 <samu> but how do I calculate that 20:21:29 <samu> 1992 - asiastar is available for purchase 20:21:58 <samu> 1992 + 7 to 38 months = phase 1 20:24:33 <samu> phase 1 + (50+(31 months to 17 years)-8 = phase 2 20:24:42 <andythenorth> hmm 20:24:55 <andythenorth> FIRS render_pnml works under python 3 now 20:25:02 <andythenorth> without 2to3 touching it 20:25:09 <samu> phase 2 + (10 to 20.5 years) = phase 3 20:25:09 <andythenorth> render_docs is sulking 20:25:44 *** Progman [~progman@p57A1831B.dip0.t-ipconnect.de] has joined #openttd 20:26:17 <samu> 1992 + (7 to 38 months) + (50-8 years + (31 months to 17 years) + (10 to 20.5 years = retire date 20:26:35 <samu> 1992 + (7 to 38 months) + (50-8 years + (31 months to 17 years)) + (10 to 20.5 years) = retire date 20:26:40 <samu> terrible math 20:28:30 <Alberth> decide the end point, and decide something for phase 1 and 3 20:29:13 <Alberth> not that the newgrf doesn't take (31 months to 17 years) into account at all 20:29:16 <Alberth> *note 20:30:04 *** An_dz [~An_dz@177.156.3.225] has joined #openttd 20:30:28 *** An_dz [~An_dz@177.156.3.225] has left #openttd [] 20:37:56 <samu> 1992 + (0.583 to 3.166) + (50-8) + (10 to 20.5) = retire date 20:38:01 <samu> like that? 20:39:29 <samu> 2044.583 to 2057.666 = retire date 20:40:15 <samu> those 31 months to 17 years are not used in the formula? 20:41:28 * andythenorth nearly has a happy pyflakes 20:41:34 <andythenorth> and the project is slightly cleaner imho 20:41:43 <Alberth> I can only see the model_life property in the vehicle properties 20:42:22 <Alberth> all the other stuff seems out of your control 20:42:33 <Alberth> andythenorth: yay :) 20:42:37 <andythenorth> Eddi|zuHause has some code for model life stuff 20:42:40 <andythenorth> somewhere 20:42:49 <andythenorth> I gave up bothering about it 20:42:56 <andythenorth> I play âvehicles never expireâ anyway 20:43:42 <Eddi|zuHause> samu: the 17 years are in phase 3. early retirement applies relative to end of phase 2 20:43:45 <Alberth> just make sure a new vehicle arrives before the current one expires 20:44:33 <andythenorth> just use 30 or 40 year model life, and deliver a new vehicle every 20 years 20:44:36 <andythenorth> seems about right 20:46:00 <Eddi|zuHause> i set early retirement=vehicle life - 4 years, and model life = purchase time + vehicle life 20:46:15 <Eddi|zuHause> or so 20:46:31 <Eddi|zuHause> i don't want to bother looking this up 20:46:58 <samu> must make up my mind about AsiaStar retiring before 2051 or not 20:47:11 <samu> past that date it stays permanently 20:47:54 <Eddi|zuHause> if it stays with low reliability, what's the point? 20:48:17 <Eddi|zuHause> also, it might not stay if a NewGRF with planes or ships introduces vehicles after 2050 20:48:35 <samu> no, im not adding new vehicles 20:48:47 <Eddi|zuHause> but the other players might 20:48:48 <Alberth> the player might 20:52:22 <samu> what is the interval range? 20:52:37 <samu> just now it retired in Jun 2050 20:52:42 <samu> it's so random 20:54:29 <samu> now it stayed past 2051 20:54:41 <samu> if i could figure the minimum value 20:55:03 *** Quatroking [~Quatrokin@ip226-139-211-87.adsl2.static.versatel.nl] has quit [Read error: Connection reset by peer] 20:57:55 *** HerzogDeXtEr1 [~flex@i59F6A74D.versanet.de] has joined #openttd 20:57:59 <andythenorth> hmm 20:59:14 * andythenorth wants to import modules into the packages __init__.py 20:59:23 <andythenorth> from package import module works 20:59:28 <andythenorth> import module doesnât 20:59:28 <andythenorth> nvm 20:59:59 <Alberth> newer pythons allow relative import, never used it though 21:00:09 <andythenorth> it will keep 21:00:24 <andythenorth> just trying to improve readability by reducing redundant characters 21:00:40 <andythenorth> can I spam a âfromâ import across multiple lines without escapes? 21:00:52 <samu> strange, it retired in year 2052, I didn't expect that 21:01:03 <samu> what am I doing wrong 21:01:07 <Alberth> andythenorth: probably not 21:01:28 <andythenorth> ta 21:01:30 <samu> i thought vehicles could never expire past year 2051 21:01:38 <Alberth> python needs something around a list to keep it together without escapes 21:02:17 <Alberth> where did you find that samu? 21:03:02 <samu> my obvservations only 21:03:07 <samu> i guess im wrong 21:03:41 *** HerzogDeXtEr [~flex@i59F6B56B.versanet.de] has quit [Ping timeout: 480 seconds] 21:04:47 *** sla_ro|master [slamaster@95.76.27.245] has quit [] 21:05:02 * andythenorth moves industry imports to industries package, ditto for cargos 21:05:10 <andythenorth> seems to be a bit more appropriate 21:06:36 <Alberth> means less editing of firs.nml perhaps :) 21:06:53 <Alberth> euhm, firs.py, that is 21:07:15 <andythenorth> yup 21:07:23 <andythenorth> and proper separation of concerns 21:07:52 <samu> again, it expired in year 2052 21:07:56 *** oyvind [~oyvind@malin.network] has quit [Quit: leaving] 21:08:05 <samu> there's something I don't understand 21:08:27 <samu> when does the game sets that a vehicle won't expire? 21:08:29 <Alberth> lucky you, I don't understand lots of things 21:08:31 <samu> what year? 21:09:23 * andythenorth has a growing list of things not understood 21:09:27 <samu> reliability was still decaying past 2051 21:09:34 <andythenorth> there must surely have been an inflection point 21:09:41 <andythenorth> because at the beginning I understood nothing 21:09:52 <andythenorth> which might be akin to infinite list of not understanding 21:09:55 <samu> and sometimes the vehicle disappears in 2052, some other times it stays after that reliability 21:10:04 <samu> after that reliability decay 21:10:07 <andythenorth> at some point it became countable list of things not understood 21:10:12 <andythenorth> which now grows 21:10:29 <Alberth> your knowledge grows :p 21:10:43 <andythenorth> but in proportion to my confusion? 21:10:49 <andythenorth> linearly, or geometric? :P 21:11:11 <Alberth> linear to your knowledge? :p 21:11:13 <samu> Looks like I'm not gonna change asiastar. 21:11:30 <samu> I just wanted to garantee at least 1 engine type for each rail type 21:11:41 <samu> there's still the SH 40 which never expires 21:13:29 <samu> depending on luck, there's an asia star past 2050+ 21:13:34 <samu> looks okay 21:13:52 * andythenorth wonders what python 3 is stumbling on in render_docs.py 21:14:15 <andythenorth> did lambdas change? 21:14:24 * andythenorth never understands lambdas 21:14:48 <andythenorth> this is throwing a key error for cargo 21:14:49 <andythenorth> sorted(economy_schemas[economy].enabled_cargos, key=lambda cargo: doc_helper.get_cargo_name(cargo)) 21:15:16 <andythenorth> works under 2.6/2.7 21:16:00 *** Yotson [~Yotson@erpaderp.xs4all.nl] has quit [Quit: .] 21:17:15 <Alberth> key has changed iirc 21:18:19 *** HerzogDeXtEr1 [~flex@i59F6A74D.versanet.de] has quit [Quit: Leaving.] 21:18:20 <Alberth> oh, it hasn't 21:18:43 <Alberth> what does the error say? 21:19:22 <andythenorth> hmm itâs a big stack actually 21:19:24 * andythenorth pastes 21:19:47 <Alberth> just the last part is enough probably 21:19:49 <andythenorth> https://paste.openttdcoop.org/pl4tteuex 21:20:12 <andythenorth> I misread it as Key error, but itâs a Name error 21:23:36 <Alberth> did you commit your code? 21:24:21 <Alberth> parse blabla line worked for me 21:26:13 <Alberth> I have python 3.4, maybe that makes a difference? 21:26:23 <andythenorth> I have 3.3.0 21:26:37 <andythenorth> did you run python src/render_docs.py? 21:26:46 <andythenorth> the makefile runs it under python 2 21:27:05 <NGC3982> V453000: Hey! 21:27:34 <Alberth> no problem 21:28:10 <andythenorth> looks like I need a new python 21:28:30 <Alberth> you can change the "cargo" variable in the lambda line to something else to eliminate that as source 21:29:03 <Alberth> have a look at chameleon requirements? 21:30:15 <Alberth> lambda looks fine to me, and https://docs.python.org/3/library/functions.html?highlight=sorted#sorted claims that 'key' exists, so it should work 21:30:45 * andythenorth gets all the pythons 21:30:55 <Alberth> you have 'cargo' as key somewhere? 21:32:48 <Alberth> try key = doc_helper.get_cargo_name 21:32:59 <planetmaker> Now folks, come forward with a nice titlegame suggestion for OpenTTD 1.5.x :) 21:33:19 <planetmaker> http://www.openttd.org/en/ and http://www.tt-forums.net/viewtopic.php?f=29&t=72617 21:34:20 <Alberth> past winning entries were always city-ish, weren't they? 21:35:55 <planetmaker> http://devs.openttd.org/~planetmaker/titlegame-1.4/round2/ and 1.2 and 1.1 in the URL work, too 21:36:09 <planetmaker> (no 1.3 round2 - that was decreed :P ) 21:36:53 <Alberth> lol nightgfx baseset :p 21:37:00 <planetmaker> :) 21:37:10 <planetmaker> because we can :P 21:37:29 <planetmaker> I was actually thinking whether I make some screenies with rawr as static newgrf ;) 21:38:23 <Alberth> 1.1 has no index.html 21:38:43 <Alberth> but only 3 entries :) 21:39:05 <planetmaker> it's round2. It always only has 3 entries :) 21:39:27 <andythenorth> I broke all my pythons :) 21:39:28 <andythenorth> what fun 21:41:19 <Alberth> :( 21:41:21 <Alberth> gn 21:41:30 <planetmaker> g'night Alberth 21:41:38 *** Alberth [~alberth@2001:981:c6c5:1:be5f:f4ff:feac:e11] has left #openttd [] 21:41:46 * andythenorth forsees a trip to the backup drive cupboard :) 21:51:06 <jjavaholic> why have one way roads in game if road vehicles can't overtake? 21:52:09 <frosch123> to prevent road vehicles from taking certain routes 21:52:21 <frosch123> where they would block things or end up on level crossings and similar 21:57:55 <andythenorth> backups are useful 22:01:10 <jjavaholic> why do road vehicles avoid drive through stations by default? 22:03:29 <frosch123> because there may be vehicles loading 22:16:38 *** frosch123 [~frosch@frnk-4d01a125.pool.mediaways.net] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn] 22:18:52 <planetmaker> g'night 22:19:36 *** itsatacoshop247 [~itsatacos@c-76-102-167-252.hsd1.ca.comcast.net] has joined #openttd 22:23:27 *** gelignite [~gelignite@i528C3792.versanet.de] has quit [Quit: http://bit.ly/1kso8Ta] 22:23:52 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has left #openttd [] 22:44:05 <Wolf01> 'night 22:44:10 *** Wolf01 [~wolf01@0001288e.user.oftc.net] has quit [Quit: Once again the world is quick to bury me.] 22:55:36 *** Progman [~progman@p57A1831B.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 23:21:08 *** DanMacK [~3fee8a84@188.cimarosa.openttdcoop.org] has quit [Quit: Page closed] 23:53:58 <samu> i have a qustion 23:54:27 <samu> grfid - what do i put here if this is my 2nd newgrf? 23:54:45 <samu> RS -> RS or RS ? 23:55:08 <samu> it's a whole different thing than my first newgrf 23:55:16 <samu> but they can be together 23:56:15 <glx> it's up to the grf writer 23:56:24 <glx> so you can do as you want 23:56:49 <samu> they're independent of each other, they function on their own, but they can also be mixed, hmm 23:58:02 <glx> the only rule is the newgrf can't have the same grfid 23:59:41 <glx> the game doesn't care about the meaning inside the grfid