Times are UTC Toggle Colours
00:03:25 <planetmaker> Eddi|zuHause, 'blooming' is a hardware property of CCDs - charged *coupled* devices. If too many charges are gathered in the well of one pixel they "spill over" to the adjacent pixels; typically only in one line as CCDs read-out hardware usually operates on lines of the device 00:05:52 <glx> planetmaker: like the green line when a powerfull light is in the field ? 00:07:08 <planetmaker> http://astronomyonline.org/Astrophotography/Images/Blooming.jpg <-- like that 00:07:42 <glx> ha yes I had something similar on a video 00:08:07 <planetmaker> if it happens on a CCD which uses a Bayer colour pattern, it might give the impression that the line is coloured with red/green or green/blue, thus green 00:08:32 <glx> it was a full vertical line 00:08:46 *** Devroush367 [~dennis@dD5765BAC.access.telenet.be] has quit [] 00:08:58 <planetmaker> well, blooming goes in single lines typically 00:09:47 <planetmaker> The colour of adjacent pixels is typically alternating between blue/green and red/green and shown is an interpolation of intensities of the vicinity to get a value for each of the 3 colour channels 00:09:51 <planetmaker> so... might be green 00:10:01 <planetmaker> http://en.wikipedia.org/wiki/Bayer_filter 00:10:11 <glx> I can't remember the exact color 00:10:16 <glx> maybe it was purple 00:13:20 <planetmaker> yeah, well :) The colour depends on the applied colour pattern and algorithm used to make-up colour from the grayscale values of the individual pixels which were gathered with a colour band-pass filter in front of the actual sensitive area... 00:13:57 <planetmaker> Though in a complete video I'd not expect that to be a case of blooming but rather some other hardware fault 00:14:13 <planetmaker> blooming only occurs when you really have way too much light input 00:14:53 <planetmaker> and only for CCDs. Video cameras might as well be CMOS due to a slight speed advantage there - and which doesn't suffer from this drawback 00:15:38 <planetmaker> (but CCDs are more light sensitive than CMOS - so depends what you want. And engineering made both sort of sensors nearly identical wrt performance for usual applications) 00:34:39 <glx> it was only for a sequence 00:38:30 *** Myhorta [~Myhorta@10.87.37.188.rev.vodafone.pt] has joined #openttd 00:40:36 <planetmaker> well :) hard to tell without actually seeing it and better knowing which camera it was made with. Many things can go wrong :) 00:42:46 <glx> sony handycam 00:43:18 <glx> but it was clearly caused by the powerfull light in the field 00:46:52 *** bdavenport [~davenport@chronos.rpi.mindlesstux.com] has joined #openttd 00:48:20 *** treaki_ [059fbc4377@p4FDF751E.dip0.t-ipconnect.de] has joined #openttd 00:49:12 <planetmaker> yeah, then it's likely the cause. Though you can have a similar optical effect. Like when outside in the dark and you squint at a street light. It will also have streaks of light extending from the source up and downward (perpendicular to your eye lids) 00:54:01 *** geoffreybeene [~gbeene@99-101-183-194.lightspeed.cicril.sbcglobal.net] has joined #openttd 00:55:23 *** treaki [50db6f1cd7@p4FF4AE47.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds] 01:01:15 *** KritiK [~Maxim@0001264a.user.oftc.net] has quit [Quit: Leaving] 01:01:43 *** Virtual- [~Virtual@46.7.241.30] has quit [Quit: Leaving] 01:21:09 *** Japa__ [~Japa@117.214.62.193] has joined #openttd 01:27:39 *** Japa_ [~Japa@117.214.62.193] has quit [Ping timeout: 480 seconds] 01:35:07 *** Japa__ [~Japa@117.214.62.193] has quit [Quit: Leaving] 01:35:27 *** Japa [~Japa@117.214.62.193] has joined #openttd 01:44:31 *** yorick_ [~yorick@ip51cd0513.speed.planet.nl] has joined #openttd 01:48:41 *** yorick [~yorick@ip51cd0513.speed.planet.nl] has quit [Ping timeout: 480 seconds] 01:55:14 *** LordAro [~LordAro@sns61-83.york.ac.uk] has quit [Remote host closed the connection] 02:00:27 *** glx [~glx@000128ec.user.oftc.net] has quit [Quit: Bye] 02:04:13 *** yorick_ [~yorick@ip51cd0513.speed.planet.nl] has quit [Remote host closed the connection] 02:14:50 *** Hazzard [~oftc-webi@c-67-174-253-44.hsd1.ca.comcast.net] has joined #openttd 02:16:01 *** Hazzard [~oftc-webi@c-67-174-253-44.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 02:37:53 *** wakou2 [~stephen@host86-150-26-69.range86-150.btcentralplus.com] has quit [Ping timeout: 480 seconds] 02:39:43 *** Endymion_Mallorn [~pplgoldbl@ool-457cd50b.dyn.optonline.net] has joined #openttd 02:50:44 *** Myhorta [~Myhorta@10.87.37.188.rev.vodafone.pt] has quit [Read error: Connection reset by peer] 03:47:26 *** Elukka [~Elukka@a91-152-213-89.elisa-laajakaista.fi] has quit [Ping timeout: 480 seconds] 04:32:31 *** Endymion_Mallorn [~pplgoldbl@ool-457cd50b.dyn.optonline.net] has left #openttd [] 04:33:15 <Eddi|zuHause> orudge: i think the forum is broken (eternally in "backup" mode) 04:35:39 *** onezero [~user@0001c18e.user.oftc.net] has joined #openttd 04:38:27 <SpComb> paging! 04:38:40 <SpComb> teh forums are teh br0ken 05:20:34 *** HerzogDeXtEr [~flex@i59F6D11B.versanet.de] has joined #openttd 05:27:19 <Supercheese> indeed 05:55:35 *** Tom_Soft [~id@37.140.121.231] has joined #openttd 05:56:02 *** Eddi|zuHause [~johekr@p57BD5BB4.dip0.t-ipconnect.de] has quit [] 05:56:17 *** Eddi|zuHause [~johekr@p5DC66D12.dip0.t-ipconnect.de] has joined #openttd 06:01:42 *** Super_Random [~kvirc@75-102-176-79.d2.itctel.com] has joined #openttd 06:06:52 *** Randominty [~Randomint@CPE-124-176-57-127.lns3.dea.bigpond.net.au] has joined #openttd 06:13:16 *** Japa_ [~Japa@117.214.62.193] has joined #openttd 06:20:04 *** Japa [~Japa@117.214.62.193] has quit [Ping timeout: 480 seconds] 06:53:53 *** Japa__ [~Japa@117.214.62.193] has joined #openttd 06:57:53 *** LuHa [~LuHa@175.203.104.96] has joined #openttd 06:58:52 *** Japa_ [~Japa@117.214.62.193] has quit [Read error: Operation timed out] 06:58:54 *** Japa [~Japa@117.214.62.193] has joined #openttd 07:01:29 *** Super_Random [~kvirc@75-102-176-79.d2.itctel.com] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/] 07:04:29 *** Japa__ [~Japa@117.214.62.193] has quit [Ping timeout: 480 seconds] 07:07:55 *** Japa_ [~Japa@117.214.62.193] has joined #openttd 07:14:32 *** Japa [~Japa@117.214.62.193] has quit [Ping timeout: 480 seconds] 07:22:17 *** sla_ro|master [slamaster@78.97.205.68] has joined #openttd 07:48:18 *** Tom_Soft [~id@37.140.121.231] has quit [Ping timeout: 480 seconds] 07:49:41 *** Tom_Soft [~id@37.140.121.231] has joined #openttd 07:58:03 *** Japa__ [~Japa@117.214.62.193] has joined #openttd 08:03:28 *** GriffinOneTwo [~oftc-webi@adsl-68-125-34-172.dsl.irvnca.pacbell.net] has joined #openttd 08:04:42 *** Japa_ [~Japa@117.214.62.193] has quit [Ping timeout: 480 seconds] 08:14:20 *** Tom_Soft [~id@37.140.121.231] has quit [Read error: Connection reset by peer] 08:14:54 *** Tom_Soft [~id@37.140.121.231] has joined #openttd 08:18:54 *** Tom_Soft [~id@37.140.121.231] has quit [Read error: Connection reset by peer] 08:19:48 *** Tom_Soft2 [~id@37.140.121.231] has joined #openttd 08:41:33 *** Progman [~progman@p57A1A508.dip0.t-ipconnect.de] has joined #openttd 08:56:33 *** Endymion_M [~Endymion_@184.20.141.255] has joined #openttd 08:57:38 <Endymion_M> h 08:57:58 *** Randominty [~Randomint@CPE-124-176-57-127.lns3.dea.bigpond.net.au] has quit [Ping timeout: 480 seconds] 08:58:25 <Endymion_M> Hi, I was wondering, why are there no highways for RVs to use? 08:58:42 *** Randominty [~Randomint@CPE-124-176-57-127.lns3.dea.bigpond.net.au] has joined #openttd 08:58:52 <V453000> nobody coded them, presumably 08:59:23 <planetmaker> Endymion_M, have a look at the DutchRoadFurniture set 08:59:33 <planetmaker> good morning everyone :) 08:59:55 <Supercheese> good night ;) 09:00:04 <planetmaker> :) sleep well, Supercheese 09:00:22 <Supercheese> I shall, farewell 09:00:26 *** Supercheese [~Superchee@98.145.153.186] has quit [Quit: ChatZilla 0.9.90.1 [Firefox 25.0.1/20131112160018]] 09:01:13 *** Pensacola [~quassel@h220216.upc-h.chello.nl] has joined #openttd 09:05:07 <Endymion_M> Planetmaker, I shall. I will admit that I just recently upgraded to 1.3.2 from 1.2.3, I was playing with RVs without any NewGRFS, and then I looked and found none. also, is there anything like path signals for roads"? 09:05:14 *** Endymion_M [~Endymion_@184.20.141.255] has left #openttd [] 09:05:34 *** Endymion_M [~Endymion_@184.20.141.255] has joined #openttd 09:06:27 <Endymion_M> Silly thing booted me. 09:08:28 <V453000> just use trains. :) 09:09:08 <Endymion_M> Housevppp 09:09:59 <Endymion_M> sorry, cat on tablet keyboard. House rules required RVs for Goods. 09:10:12 <V453000> house rules? 09:11:29 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 09:11:33 <andythenorth> o/ 09:11:37 <Endymion_M> Yeah. I upgraded to LAN with the wife and a friend. 09:11:40 <V453000> o/ 09:11:58 <V453000> well obviously but the house rules generally need to have a reason :) 09:12:06 <V453000> and having RVs for goods is not a very enlightened idea 09:12:28 <Endymion_M> The wife likes her buses, etc. 09:12:37 <planetmaker> Endymion_M, well, RV don't need path signals, they can just drive and in the worst of circumstances even teleport :D 09:12:55 <V453000> :D 09:12:59 <andythenorth> RVs should be implemented as trains 09:13:04 <andythenorth> I keep meaning to do that :P 09:13:09 <V453000> ^ 09:13:17 <planetmaker> and the roadfurniture is just visual, nothing really changes except that you can build the impression of having highways 09:13:18 <Endymion_M> well, I just kept seeing them get clobbered by trains. 09:13:28 <andythenorth> I noticed in our MP games, only me and alberth use RVs 09:13:38 *** George [~George@212.113.107.39] has joined #openttd 09:13:51 <V453000> well yeah because RVs are worthless :P 09:13:55 <andythenorth> I think other people described them variously as 'cheating' 'fiddly and pointless' 'rubbish' 'low capacity' 'uninteresting' 09:14:25 <planetmaker> andythenorth, this game "enforces" a sensible mixture of transport modes: long-distance: train. short-distance: RV, water: ships :) 09:14:34 <Endymion_M> Heh. That's about it for 'em. but... loss 09:14:55 <andythenorth> planetmaker: you missed air transport :P 09:15:06 <planetmaker> damn, I hoped no-one would notice :D 09:15:08 <andythenorth> so could anyone patch cdist for me? 09:15:21 <Endymion_M> Either way. thank you. I'm gonna go sleep now. 09:15:30 <andythenorth> specifically, I want to put certain cargo labels in the openttd.cfg, and have them ignored by cdist 09:15:31 <planetmaker> air transport is good for helicopters transporting bags of valuables from bank to bank 09:15:40 <andythenorth> ^^ this is just a hack to test gameplay 09:15:52 *** Endymion_M [~Endymion_@184.20.141.255] has quit [Quit: Endymion_M] 09:15:53 <andythenorth> air transport is also good for FIRS supplies :P 09:15:56 <andythenorth> but not with cdist 09:16:18 <V453000> nothing is good with cdist :) 09:16:27 <andythenorth> I have a game going to test FIRS, Iron Horse and Squid. But cdist ruins it. 09:16:32 <andythenorth> and I can't be bothered to start another 09:16:40 <V453000> turn cdist off? 09:16:45 <andythenorth> that will also ruin it 09:16:45 <planetmaker> just switch cdist off, andythenorth ? 09:17:02 <andythenorth> then all the elaborate transfers will stop working 09:17:06 <andythenorth> I'll have to go fix them :P 09:17:15 <andythenorth> and reengineer my pax network completely 09:17:21 <andythenorth> cdist is mostly good ;) 09:17:55 <andythenorth> so I guess these grfs might end up untested by me until Christmas time or such :) 09:18:27 <andythenorth> maybe I can find the cdist special case handling for armoured and extend it 09:19:37 <andythenorth> wonder what happens if I just set armoured class on supplies cargos? o_O 09:30:49 *** adf88 [~Thunderbi@wis-zul.spine.pl] has joined #openttd 09:33:44 *** LordAro [~LordAro@sns61-83.york.ac.uk] has joined #openttd 09:36:58 *** Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has joined #openttd 09:37:01 *** mode/#openttd [+o Alberth] by ChanServ 09:42:58 *** Ristovski [~rafael@89.205.3.77] has joined #openttd 09:58:11 *** skyem123 [~skyem123@cpc1-walt4-0-0-cust432.13-2.cable.virginm.net] has joined #openttd 09:58:16 *** Japa_ [~Japa@117.214.57.29] has joined #openttd 10:01:19 *** valhallasw [~valhallas@s55978e11.adsl.online.nl] has joined #openttd 10:02:46 *** oskari89 [oskari89@62-241-226-106.bb.dnainternet.fi] has joined #openttd 10:04:10 *** LuHa [~LuHa@175.203.104.96] has quit [Quit: Leaving.] 10:04:57 *** Japa__ [~Japa@117.214.62.193] has quit [Ping timeout: 480 seconds] 10:07:24 *** gelignite [~gelignite@i528C358C.versanet.de] has joined #openttd 10:07:38 *** adf88 [~Thunderbi@wis-zul.spine.pl] has quit [Quit: adf88] 10:17:33 *** Wolf01 [~wolf01@0001288e.user.oftc.net] has joined #openttd 10:18:06 <Wolf01> hi hi o/ 10:19:25 <LordAro> /o 10:24:41 *** frosch123 [~frosch@frnk-4d008233.pool.mediaWays.net] has joined #openttd 10:30:10 <Wolf01> moin frosch123 10:31:47 <frosch123> ciao 10:33:19 *** Randominty [~Randomint@CPE-124-176-57-127.lns3.dea.bigpond.net.au] has quit [] 10:34:34 <LordAro> quak 10:39:52 *** tokai|noir [~tokai@00012860.user.oftc.net] has joined #openttd 10:39:55 *** mode/#openttd [+v tokai|noir] by ChanServ 10:44:04 *** skyem123 [~skyem123@cpc1-walt4-0-0-cust432.13-2.cable.virginm.net] has quit [Read error: Connection reset by peer] 10:45:59 <michi_cc> andythenorth: There are some bits about the standardized track scheme in yesterday mornings backlog which you might want to check out. 10:46:02 *** tokai|mdlx [~tokai@port-92-195-242-65.dynamic.qsc.de] has quit [Ping timeout: 480 seconds] 10:46:32 <planetmaker> michi_cc, I made a note following your remarks in the ticket andythenorth created :) 10:47:15 <michi_cc> Didn't see that. 10:47:43 <planetmaker> hard to see if you don't know the issue existed in his project. Nor did I mention it :) 10:48:18 <planetmaker> http://dev.openttdcoop.org/issues/6625 10:51:52 <andythenorth> planetmaker: thanks :) 10:53:42 <andythenorth> most useful 10:55:31 <michi_cc> andythenorth: Read the last section on the wiki page (summary for vehicle sets), it hopefully clearly states how to construct the appropriate label and in which cases you need to have fallbacks. 10:56:10 <andythenorth> nml or nfo spec? 10:56:12 <michi_cc> If anything is unclear, ask so I (or somebody else) can improve it. 10:56:25 <andythenorth> or the railtypes page? 10:56:40 <michi_cc> The wiki page about the standardized scheme. 10:56:43 <andythenorth> ok ta 10:58:24 <andythenorth> gauge, energy source and speed are all clear 10:58:48 <andythenorth> if the train set doesn't care about axle weights, what is the correct approach? 10:58:53 <andythenorth> define all A-E? 10:59:15 <michi_cc> You pick one. 10:59:43 * andythenorth considers new 'number of axles' property :P 10:59:47 <andythenorth> let the game sort it out 11:01:14 <michi_cc> Or better, still assign them relative to some metric, i.e. If you have some heavy engines and some very lightweight ones, put the heavy ones as e.g. D and the light ones as A. The track set is required to sort it out how it wants to map the axle weights the the tracks it provides. 11:01:53 <andythenorth> in the case of this set, I'm ignoring it :) 11:01:58 <andythenorth> so I'll just set them all as A 11:02:13 <andythenorth> I don't really agree with axle weight as an interesting gameplay property :) 11:03:04 <andythenorth> hmm 11:03:09 * andythenorth considers loading gauge :P 11:04:31 *** flaa [~flaa@89.100.79.103] has joined #openttd 11:07:45 <michi_cc> Would IMHO be part of the gauge as a specialized subtype (e.g. like n currently is defined as second, narrower narrow gauge for sets that need two narrow gauges). So s could be the British loading gauge subtype to S. Vehicles for s can run on S, but S not on s. 11:09:25 <michi_cc> For this you would need to provide fallbacks from s to S though, unless it's okay for vehicles to be unavailable. 11:16:00 * andythenorth wonders how metro should be implemented 11:16:27 <andythenorth> that's probably solved already 11:17:15 <andythenorth> hmm 11:17:16 <andythenorth> not 11:17:29 <planetmaker> usually metro is standard gauge and possibly 3rd-rail power 11:17:32 <andythenorth> the current implentation in Iron Horse grf is not compliant with the scheme 11:17:34 <planetmaker> at least in this country 11:18:16 <andythenorth> also the standard scheme reserves M for monorail 11:18:23 <andythenorth> so the current implementation violates the scheme :P 11:18:44 <planetmaker> it's not yet released... :) ^ 11:19:00 <andythenorth> needs a solution :( 11:19:10 <andythenorth> could declare metro a special class of NG 11:19:42 <planetmaker> the question is: are metro tracks really different from other tracks - or is it simply different use cases for the same track? 11:20:23 <andythenorth> I am not really approaching it that way 11:20:39 <andythenorth> for gameplay reasons metro is incompatible with standard trains 11:20:48 <planetmaker> why? 11:20:50 <andythenorth> it causes player to have to make interesting choices 11:21:00 <planetmaker> good enough reason 11:21:02 <andythenorth> the goal of IH is to only have to make interesting choices 11:21:13 <andythenorth> most train grfs have gotten too big, and are full of boring choices 11:21:16 <andythenorth> it's like going to IKEA 11:21:20 <planetmaker> :) 11:21:35 <michi_cc> The scheme doesn't really "reserve" anything. A label that starts with M but where the three other letters are not defined in the scheme is "free". 11:21:51 <andythenorth> so metro is super high capacity, not very fast, high acceleration, and incompatible with standard trains 11:22:24 <Alberth> most train grfs are not designed from game play perspective 11:22:28 <andythenorth> nope :) 11:22:43 <andythenorth> we have made ourselves a nice model train simulator though :) 11:22:52 <planetmaker> quite so 11:23:13 * andythenorth proposes changing newgrf spec to reflect actual model trains :P 11:23:22 <andythenorth> so instead of axle load, track is code 75 or code 100 11:23:25 <planetmaker> andythenorth, from that perspective, any track gauge type class would do which none of your other vehicles uses 11:23:27 <andythenorth> and some trains don't work on code 75 11:23:31 <planetmaker> which could be monorail 11:23:40 <Alberth> numbers change for each country 11:24:22 * planetmaker has no idea what the numbers refer to which andy mentioned 11:24:45 <planetmaker> is it like order numbers? 11:25:44 <andythenorth> it's height of the actual rail 11:26:04 <andythenorth> cheap / older trains have wheel flanges too deep, so they bump along the sleepers 11:26:24 <andythenorth> model train world is full of details :P 11:26:32 <planetmaker> omg... :D 11:26:53 <Alberth> not unlike the real train world :p 11:36:09 <andythenorth> then there are different coupling types, different electrical systems, variations in scale etc 11:36:23 <andythenorth> we should definitely extend newgrf to support it 11:36:31 <andythenorth> some authors would absolutely love it 11:36:40 <andythenorth> it would be detail-freak-fest 11:36:44 <andythenorth> imagine the spec wars we could have 11:36:59 <Alberth> maybe we can turn it into a honey pot? :p 11:39:37 <andythenorth> my thought too :P 11:40:15 <andythenorth> meanwhile....michi_cc I can't tempt you to write some cargo routing module for cdist? o_O 11:40:22 <andythenorth> optimised for FIRS supplies? 11:40:32 <andythenorth> fonso said it was likely possible 11:40:47 *** flaa [~flaa@89.100.79.103] has quit [Read error: Connection reset by peer] 11:44:38 *** wakou2 [~stephen@host86-150-26-69.range86-150.btcentralplus.com] has joined #openttd 11:50:17 *** Alice3 [~Alice@cpc18-grim14-2-0-cust478.12-3.cable.virginm.net] has joined #openttd 11:56:06 * andythenorth looks for a way to find position of vehicle in an *articulated consist* 11:56:12 <andythenorth> I can't see a var for that :) 11:56:35 <andythenorth> I can make the compiler sort it out, but I don't want to re-invent stuff already in newgrf spec... 11:57:13 <andythenorth> I can't trivially use the counter on the articulated callback - I need something for a sprite-drawing time switch 12:00:59 *** Elukka [~Elukka@a91-152-213-89.elisa-laajakaista.fi] has joined #openttd 12:08:18 <fonsinchen> andythenorth: ARMOURED isn't really a special case in cargodist 12:08:29 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Read error: Connection reset by peer] 12:08:38 <fonsinchen> It's just a UI thing 12:09:27 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has joined #openttd 12:11:52 <fonsinchen> The choice of cargos shown as separate entries in the cargodist settings is pretty arbitrary 12:13:28 <fonsinchen> Internally it keeps a setting for each cargo. 12:13:49 <andythenorth> interesting 12:14:33 <fonsinchen> I just didn't want to make a list of 32 entries in the settings menu 12:14:41 <andythenorth> no 12:14:44 <andythenorth> good choice :) 12:14:56 <andythenorth> but could it be exposed in openttd.cfg or such? 12:15:02 <andythenorth> even if this is just a hack to test? 12:15:17 <Alberth> a bit in the cargo description? 12:15:35 <andythenorth> wondered about that 12:15:38 <planetmaker> I wonder about that. How much would it confuse users, though? 12:15:45 <andythenorth> is it right for the newgrf to be making choices about cidst though? 12:15:47 <andythenorth> cdist * 12:15:48 <planetmaker> It definitely has pros 12:15:53 <planetmaker> but cons as well 12:15:57 <andythenorth> I'm confused about what the proper domain is for control of this 12:16:47 <planetmaker> maybe it needs a setting like "use always cargodist" "use cargodist unless newgrf disagrees" 12:16:47 <Alberth> isn't it always? :) 12:16:58 <planetmaker> "don't use cargodist" 12:17:18 <planetmaker> so in the 2nd case the bit from newgrf is heeded. But meh... combinatoric settings explosion :D 12:17:20 <Alberth> it's too realistic :p 12:18:00 <andythenorth> :P 12:18:00 <fonsinchen> Actually I was wrong. I've changed that at some point. The linkgraph settings only have entries for pax, mail, armoured and default. However, that could easily be extended as all access goes through GetDistributionType(CargoID cargo), 12:18:42 <andythenorth> I think the 'correct' solution is to allow destinations (industries, houses or maybe towns) to express demand :P 12:18:47 <andythenorth> but that is a big project 12:18:59 <andythenorth> easier to kludge a load of things together that mostly work :) 12:18:59 <planetmaker> hm... cargo property which defines the cargodist treatment of it (assigns class for cargodist to pax/mail/armoured/other)? 12:21:48 <fonsinchen> andythenorth: They already do express demand. It's just very coarse grained: either "has demand" or "has no demand" 12:22:12 <fonsinchen> By adding a number to that we could easily improve things 12:22:33 <andythenorth> interesting :) 12:22:59 <andythenorth> I can think of ways (for example) for newgrf industry to modify a demand amount 12:23:07 <andythenorth> houses might better depend on the town :P 12:24:04 <andythenorth> I would be concerned about responsiveness / latency though :) 12:24:46 <Alberth> would be useful for ECS if the cargo itself would manage the flow 12:24:52 <andythenorth> industries trying to set demand every production cycle (8 or 9 times / month) would be ummm....bad I think 12:25:11 <andythenorth> the routing wouldn't keep up 12:25:14 <Alberth> although not everybody may share my pov :) 12:25:30 <andythenorth> industries expressing a longer term demand might be better 12:25:36 <andythenorth> maybe in a scale free way :P 12:25:42 <fonsinchen> Latency is definitely a problem. You shouldn't completely stop accepting cargo, but instead reduce the amount accepted to 1. 12:26:22 <fonsinchen> If everything works ok that should lead to "practically no cargo" being planned for that route, but existing cargo already on its way can still be delivered. 12:26:30 <Alberth> fonsinchen: just don't promise you will do what the industry says? 12:26:35 <andythenorth> I would never stop accepting anyway :) 12:26:57 <fonsinchen> Well, FIRS does that, doesn't it? Or was that ECS? 12:27:10 <Alberth> ECS does 12:27:11 <andythenorth> PBI 12:27:18 <andythenorth> it's an anti-pattern 12:28:09 <Alberth> if you interpret 0 as "long term", then the current cargo on route can still be delivered 12:29:02 <Alberth> can't you program industry to accept but not pay? 12:29:36 <Alberth> or accept but not stockpile? 12:30:14 <planetmaker> in principle you can accept cargo if the industry says 'no' but the tile says 'yes' 12:30:26 <planetmaker> but that's a very very bad hack 12:33:35 <fonsinchen> Well, technically the demand is expressed by the added "tile demands" divided by 8 and passed to the link graph like that 12:33:48 <frosch123> scan all newgrfs for all existing cargo labels, and then put a setting for each into adv. settings? :p 12:34:08 <fonsinchen> By increasing tile demands you can make the link graph route more cargo to that place (theoretically, no one has tested that, probably) 12:34:29 <fonsinchen> See station_cmd.cpp:576 12:37:05 <fonsinchen> There is probably a limit on the amount of acceptance you can define per tile 12:37:22 <fonsinchen> Someone should look that up in the newgrf docs 12:37:51 <fonsinchen> But you can definitely change the cargo acceptance while the game is running 12:37:59 <frosch123> so industries which use more tiles have higher demands? 12:38:32 <frosch123> resp. covering a bigger area of a industry in station catchment area increases demand? 12:39:04 <fonsinchen> That is probably a side effect of this technique 12:41:26 <fonsinchen> It only works like that for asymmetric, though. See demands.cpp lines 65 and 123 12:44:04 <andythenorth> does it seem more correct to go by demand than arse around modifying the cargo? 12:44:43 <andythenorth> the routing of cargo has more to do with the behaviour of the destination than the attributes of the cargo imho 12:45:35 <andythenorth> if demand was expressed for each cargo, for every tile of the map...then GS could also modify it 12:45:49 <andythenorth> allowing more interesting challenge-based gameplay 12:45:57 <fonsinchen> It already is expressed like that 12:46:05 <andythenorth> handy :) 12:46:24 <fonsinchen> You can specify the amount of "acceptance" per tile in industries and houses somehow 12:46:41 <fonsinchen> There must be a newgrf function for that 12:46:54 <frosch123> i am not convince that it makes sense to do that "per tile" 12:47:11 *** Devroush [~dennis@dD5765BAC.access.telenet.be] has joined #openttd 12:48:37 <fonsinchen> Well, we could add something on top of this, but that's what we already have. Someone should try if it works. 12:49:03 *** GriffinOneTwo [~oftc-webi@adsl-68-125-34-172.dsl.irvnca.pacbell.net] has quit [Quit: Page closed] 12:51:44 <MNIM> 107 cities... 12:52:22 <MNIM> one day my freeciv empire is just going to collapse on its' own weight 12:54:02 *** zeknurn [~sup@hd9483b0c.seveveb.dyn.perspektivbredband.net] has quit [Remote host closed the connection] 12:54:44 *** zeknurn [~sup@hd9483b0c.seveveb.dyn.perspektivbredband.net] has joined #openttd 12:54:51 <fonsinchen> http://newgrf-specs.tt-wiki.net/wiki/Action0/Industry_Tiles#Tile_acceptance_.280A.2C_0B.2C_0C.29 would suggest you can specify tile acceptance numbers between 0 and 255, where 0-7 might make the cargo totally unaccepted. 12:55:17 <fonsinchen> That should be enough to steer the distribution. 12:57:47 <andythenorth> ok so I could patch FIRS to try and set that 12:57:59 <andythenorth> could just set static demand amounts initially 12:58:25 <andythenorth> if I set different values for different industry types, but same accepted cargo...we can test 12:58:52 <andythenorth> can't do it now - going to a wedding :) 12:59:00 <andythenorth> but when I next have time :) 12:59:11 <frosch123> your own? :p 12:59:16 <andythenorth> not so much :) 12:59:24 <andythenorth> done that 12:59:27 <andythenorth> or if someone else wanted to adjust FIRS and compile.... :P 13:01:38 <andythenorth> bye ;) 13:01:41 *** andythenorth [~Andy@cpc10-aztw26-2-0-cust867.18-1.cable.virginm.net] has quit [Quit: andythenorth] 13:08:46 <fonsinchen> http://newgrf-specs.tt-wiki.net/wiki/Callbacks#Decide_cargo_acceptance_.282B.29 suggests that when you want to change cargo acceptance later on you can only specify numbers between 0 and 8, though. 13:09:53 <fonsinchen> However, the presence of 4 bits for each would technically let you specify 0 to 15. 13:10:26 <fonsinchen> Also, there are 4 unused bits in the end which we could define as "multiplier" 13:12:51 <frosch123> it feels weird that demand would depend on how much of the industry the station covers. shouldn't it rather be a thing of the industry instance? 13:13:06 <frosch123> would also make it accessible to gs then 13:15:09 <Kjetil> it is not very realistic at least 13:15:44 <Kjetil> I mean a factory usually only accepts cargo at a specific location 13:16:37 <planetmaker> where an industry accepts or supplies cargo does not matter on our scale 13:16:41 <frosch123> yes, that may define whether an industry accepts cargo, but not how much it accepts 13:16:53 <planetmaker> doing differently is unrealistic and not adding anything to gameplay 13:17:43 <fonsinchen> But how would you implement it? 13:18:05 <fonsinchen> Stations don't really know the industries surrounding them. They do know the tiles, though. 13:18:07 <frosch123> a factor in the Industry instance 13:19:00 <Kjetil> planetmaker: I totally agree. I was just making an argument for that the amount of cargo accepted shouldn't be dependent on the station coverage 13:19:01 <frosch123> fonsinchen: there is Station::industries_near 13:19:10 <fonsinchen> The amount of tiles covered does already decide upon acceptance of a station, btw. 13:19:29 <fonsinchen> It's just a yes/no type decision so far. Not a number 13:19:34 <frosch123> a newgrf could define an initial demand factor per cargo, which defaults to 1 (all industries accepting a cargo have the same demand) 13:19:42 <Kjetil> fonsinchen: as it should be :) 13:19:50 <frosch123> a gs could defnie an addtional multiplier 13:20:05 <frosch123> so, a newgrf could set 5, a gs could set 2, and the product 10 is what matters 13:20:41 <frosch123> this number could also be displayed in the industry gui, or reported to ais 13:22:11 <frosch123> we can also change cb 3d to dynamically change the demand 13:22:48 <frosch123> maybe that would fix industry stockpiles 13:23:14 <frosch123> industires would no longer hard-stop accepting cargo, but just lower their demand weight 13:23:19 <fonsinchen> So, for each tile in GetAcceptanceAroundTiles you'd check which industry it belongs to and then apply that factor? 13:23:41 <fonsinchen> That's basically the same as having the industry specify the tile acceptances. 13:23:57 <fonsinchen> It's just slower. 13:24:03 <frosch123> no, not per tile 13:24:13 <frosch123> tiles decide whether a industry accepts a cargo just now 13:24:25 <frosch123> once it accepts the cargo, it is added to the Station structure in some list 13:24:31 <frosch123> maybe the same as industry_near 13:24:44 <frosch123> and then instance defines the demand for that cargo, independent of the amoutn of tiles covered 13:25:44 *** Midnightmyth [~quassel@93-167-84-102-static.dk.customer.tdc.net] has joined #openttd 13:26:03 <frosch123> industries_near is already used today to deliver cargo to industries 13:26:10 <frosch123> though i am not sure how it considers different cargo types 13:26:25 <fonsinchen> What about funny people who cover 3 tiles of each of two power plants with one station and thus get coal accepted without covering enough of one power plant to get coal accepted "normally"? 13:27:57 <frosch123> that's already the case today 13:28:01 <frosch123> houses also add to acceptance 13:28:16 <frosch123> a station accepting a cargo does not affect which industry is delivered 13:28:57 <frosch123> ah, DeliverGoodsToIndustry does not differ per cargo_type 13:29:07 <fonsinchen> But what would that mean for demand? 13:29:16 <frosch123> it delivers the cargo to the best industry which is somehow in the catchment area 13:29:20 <frosch123> independent of the tiles involved 13:29:49 <frosch123> fonsinchen: demand is defined by the average or the sum of the demands of the industries in Station::industry_near 13:30:00 <frosch123> using the same logic as DeliverGoodsToIndustry 13:30:24 <frosch123> possible changing IndustryTemporarilyRefusesCargo to return a scaling factor instead of yes/no 13:31:28 <frosch123> currently tile acceptance and deciding which industry is delivered are completely independent 13:32:13 <frosch123> unifying that is one case (which belongs into the area of unifying acceptance and pickup areas) 13:32:28 <frosch123> but demand should depend on the industries being delivered 13:32:39 <frosch123> imho :) 13:35:47 <fonsinchen> The whole thing seems unnecessarily complex to me. Why is there an IndustryTemporarilyRefusesCargo after all? 13:36:01 <frosch123> stockpiles ala pbi 13:36:19 <fonsinchen> They could have used that tile acceptances for that, too 13:36:25 <frosch123> but i don't get your argument 13:36:33 <frosch123> demand per instance feels way easier than per tile 13:36:52 <frosch123> fonsinchen: tile acceptance has nothing to do with industry delivery 13:37:18 <frosch123> they are independent, and updated asynchronously 13:37:26 <frosch123> sometimes they are inconsistent 13:37:44 <fonsinchen> That's the problem. The tiles could specify acceptance without any industry actually accepting cargo and the industry could specify acceptance without any tiles doing so. 13:37:51 <fonsinchen> That should be unified 13:37:55 <frosch123> btw. various industries also accept passengers according to tile acceptance 13:37:59 <frosch123> e.g. oilrig and steel mill 13:38:10 <Alberth> at least tile acceptance is not considered input for the industry, in eg the industry chain window 13:38:24 <fonsinchen> That should be written in their industry windows as normal cargo then. 13:38:37 <frosch123> well, that's how ttd is 13:39:21 <planetmaker> what would break if we simply kill tile acceptance for industries? 13:39:21 *** LordAro [~LordAro@sns61-83.york.ac.uk] has quit [Read error: Connection reset by peer] 13:39:23 <fonsinchen> OK, we can just shrug it off like that. However, then there is no inherently preferable way to implement demands. 13:39:25 *** LordAro [~LordAro@sns61-83.york.ac.uk] has joined #openttd 13:39:31 <frosch123> planetmaker: oilrigs 13:39:49 <planetmaker> passengers there, which could be changed, no? 13:39:51 <frosch123> well, i am convided. making demand depend on tile acceptance is plain wrong :p 13:39:53 <Alberth> pax acceptance of default industries (coal mine iirc) 13:40:14 <frosch123> industry production is not controlled by tile acceptance 13:40:24 <fonsinchen> Oilrigs, coal mines, ... should just specify passengers as normal accepted cargo then. 13:40:31 <frosch123> no 13:40:40 <planetmaker> would really anything break, if those few tiles did not accept anymore 1/8 passengers or so? 13:40:58 <frosch123> well, you can remove the heliport from oilrigs then :p 13:41:29 <frosch123> anyway, are we now down to that original ttd is wrong, and we should redo the game into something different? 13:42:37 <frosch123> you cannot just redefine what tile acceptance means 13:46:38 <fonsinchen> Well, I can add a second meaning to tile acceptance. It's not so far off to say that the more cargo is accepted by each tile the more cargo the link graph will try to route there. 13:48:13 <frosch123> i guess tile acceptance works for houses and oilrigs 13:48:32 <frosch123> but i think it is really weird for processing industries 13:48:55 <frosch123> considering houses, gs may set it per town? 13:49:01 <frosch123> or per tile area? 13:49:06 <frosch123> s/tile area/region/ 13:50:20 <planetmaker> town makes sense 13:50:31 <planetmaker> we have already local authority zones 13:50:36 <planetmaker> so no new concept there really 13:52:51 <frosch123> hmm, so demand could be defined by ("house tile acceptance" + "industry tile acceptance if industry does not process cargo") * "town factor" + "industry factor if industry processes the cargo" 13:53:38 <frosch123> newgrf can set tile acceptance for houses, and factor for industry types 13:53:43 <fonsinchen> Just stick to the tiles for industries, too. Everything becomes so much simpler then. 13:53:45 <frosch123> gs can set factor for towns and industry instances 13:54:08 <fonsinchen> A GS setting the factor would just trigger a loop over all involved tiles 13:54:36 <frosch123> well, one can try. maybe tile accepance for industries is simpler, but it is also very intuitive when playing imo 13:55:13 <frosch123> but, ok, if you display the demand during station construction, it could replace the current yes/no decision 13:55:43 <frosch123> but newgrf have to very carefully scale the demand per tile depending on how many tiles the industry has in total 13:55:49 <frosch123> which makes it weird for default industries 13:55:57 <frosch123> though they have about the same size 13:56:18 *** sla_ro|master [slamaster@78.97.205.68] has quit [] 13:56:20 <fonsinchen> People already know that they have to cover as much as possible of the industry to get acceptance. 13:56:26 <frosch123> but firs has very differently sized industries, so i guess current firs would be very broken 13:57:03 <fonsinchen> And by allowing values >8 everywhere one could model the demand without fearing loss of acceptance at nearby stations. 13:57:36 <fonsinchen> What would change for current firs? 13:58:00 <frosch123> you either have to make only some tiles accept the cargo, or you have to scale the acceptance per tile with industry size 13:58:21 <fonsinchen> No, just let the newgrf specify tile acceptance. 13:58:27 <frosch123> there are industries with size 1x1 or 2x2, and ones with 16x10 13:58:43 <fonsinchen> Well for the small industry you specify a high acceptance then 13:58:57 <frosch123> yes, thus current firs would be broken 13:59:01 <fonsinchen> And btw, if all industries accepting the same cargo have low acceptance, that's no problem 13:59:07 <frosch123> while default industries may be lucky 13:59:31 <fonsinchen> The demands are relative to total sum of demands in link graph after all 13:59:48 <frosch123> yes, the problem only exists for industries accepting the same cargo 14:00:20 <fonsinchen> So there are industries of 1x1 and others of 16x10 which accept the same cargo in firs? 14:00:29 <planetmaker> in principle 14:00:39 <frosch123> the supplies are accepte by very different industries 14:01:25 <fonsinchen> Now I see the problem. However, that would just mean: Don't use cargodist with firs until the acceptances are fixed. 14:02:19 <frosch123> yeah, i tried to keeping it compatible. but considering that the default industries are not affected, actively deciding to break firs might work :p 14:04:11 <frosch123> but the station gui need to display the demand somehow 14:05:28 <frosch123> demand: manufacturing supplies (low), steel (medium), coal (high) 14:05:32 <frosch123> or something like that 14:05:33 <fonsinchen> It could pull it from the link graph 14:05:43 <frosch123> i mean during construction 14:05:50 <frosch123> so you can better figure out which tiles to cover 14:06:10 <fonsinchen> There we can probably afford looping over the tiles 14:06:30 <frosch123> i think currently firs accepts the cargo on almost all tiles 14:06:48 <frosch123> while i would expect that to change, so only some tiles accept the cargo 14:07:14 <frosch123> if the industry is bigger than the usual catchment area, you would otherwise have to build the station around the industry, instead of next to it 14:07:20 <frosch123> which i would consider bad gameplay :p 14:07:49 *** MrShell [~mrshell@HSI-KBW-134-3-127-103.hsi14.kabel-badenwuerttemberg.de] has joined #openttd 14:08:02 <frosch123> i.e. making it possible to cover all tiles with acceptance with a single station 14:08:22 <fonsinchen> It doesn't really depend on size of the industry, but rather on tile acceptance. You could increase the tile acceptances of small industries and leave the ones of large industries as they are. 14:08:45 <frosch123> if the industry is 16x10, you cannot cover it with a normal station 14:08:53 <frosch123> you have to station-walk around the industry to cover all tiles 14:08:55 <fonsinchen> You don't have to cover the whole industry 14:09:20 <frosch123> to get maximum demand, i would have to 14:09:31 <fonsinchen> But why would you want maximum demand? 14:09:44 <fonsinchen> To artificially increase cargo flow to that industry? 14:09:51 <frosch123> yes 14:10:00 <fonsinchen> Then just build multiple stations next to it 14:10:07 <frosch123> assuming you play coop style with always station walking 64x64 stations 14:10:17 <frosch123> you would get very different demand flows than a normal palyer 14:10:27 <frosch123> so, firs has a hard time to balance that 14:10:32 <fonsinchen> But if you do that you know what you're doing 14:10:36 <frosch123> unless it restrict the tilearea of acceptance 14:11:23 <fonsinchen> For the normal player hardly anything would change. And the coop players will have to come up with new strategies to deal with it. 14:11:34 <fonsinchen> That's their "job" after all. 14:11:47 <Kjetil> So.. are you planning to implement variable size industries as well ? 14:12:00 <fonsinchen> That's something else 14:12:06 <frosch123> also normal players would like to know whether they cover the industry properly 14:12:30 <frosch123> currently the construction gui displays yes/no for acceptance 14:12:32 <fonsinchen> The demand should be shown in the station building gui and in the station window, yes 14:12:45 <fonsinchen> How does it do that? 14:12:46 <frosch123> if it suddenly becomes low/high demand, it should display that 14:13:06 <fonsinchen> It must be tile-looping already. It could as well retrieve the exact number 14:13:33 <fonsinchen> I have to leave, unfortunately 14:13:37 <fonsinchen> See you 14:14:37 <frosch123> DrawStationCoverageAreaText just checks for >= 8 currently 14:14:47 <frosch123> so, yeah, it would just be changing that function 14:18:07 *** MrShell [~mrshell@HSI-KBW-134-3-127-103.hsi14.kabel-badenwuerttemberg.de] has quit [Quit: Leaving] 14:22:12 *** George [~George@212.113.107.39] has quit [Ping timeout: 480 seconds] 14:27:05 *** skyem123 [~skyem123@cpc1-walt4-0-0-cust432.13-2.cable.virginm.net] has joined #openttd 14:29:41 *** wakou2 [~stephen@host86-150-26-69.range86-150.btcentralplus.com] has quit [Remote host closed the connection] 14:33:24 *** montalvo [~montalvo@host109-151-42-35.range109-151.btcentralplus.com] has quit [Ping timeout: 480 seconds] 14:48:43 *** kais58 [~kais58@cpc8-cwma7-2-0-cust113.7-3.cable.virginm.net] has quit [Ping timeout: 480 seconds] 15:03:16 *** KritiK [~Maxim@0001264a.user.oftc.net] has joined #openttd 15:15:38 *** kdsa [~kdsa@184.75.221.3] has quit [Ping timeout: 480 seconds] 15:21:09 *** kais58 [~kais58@cpc8-cwma7-2-0-cust113.7-3.cable.virginm.net] has joined #openttd 15:46:54 *** retro|cz [~retro@ip-89-176-82-80.net.upcbroadband.cz] has joined #openttd 15:52:43 *** DanMacK [~453f3a69@188.cimarosa.openttdcoop.org] has joined #openttd 15:53:02 *** skyem123 [~skyem123@cpc1-walt4-0-0-cust432.13-2.cable.virginm.net] has quit [Quit: Leaving] 15:53:08 <DanMacK> hey all 15:53:18 <DanMacK> @seen andythenorth 15:53:18 <DorpsGek> DanMacK: andythenorth was last seen in #openttd 2 hours, 51 minutes, and 39 seconds ago: <andythenorth> bye ;) 16:01:56 *** sla_ro|master [slamaster@78.97.205.68] has joined #openttd 16:08:31 *** George [~George@212.113.107.39] has joined #openttd 16:17:44 *** Progman [~progman@p57A1A508.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 16:53:24 *** Gethiox3 is now known as Gethiox 17:11:33 *** Hazzard [~oftc-webi@c-67-174-253-44.hsd1.ca.comcast.net] has joined #openttd 17:20:51 *** Super_Random [~kvirc@75-102-176-79.d2.itctel.com] has joined #openttd 17:24:40 *** alluke [~oftc-webi@cs181208223.pp.htv.fi] has joined #openttd 17:35:16 *** valhalla1w [~valhallas@s55978e11.adsl.online.nl] has joined #openttd 17:37:04 *** valhallasw [~valhallas@s55978e11.adsl.online.nl] has quit [Ping timeout: 480 seconds] 17:51:04 *** Myhorta [~Myhorta@10.87.37.188.rev.vodafone.pt] has joined #openttd 17:56:55 *** Superuser [~superuser@cpc11-lewi15-2-0-cust98.2-4.cable.virginm.net] has joined #openttd 17:58:46 *** bdavenport [~davenport@chronos.rpi.mindlesstux.com] has quit [Quit: ZNC - http://znc.in] 18:04:40 <NGC3982> It seems like the reload_config parameter actually works out fine. 18:04:58 <Hazzard> ? 18:15:43 <frosch123> why are people always making fun of ottd's cve reports? :p 18:16:03 <planetmaker> hm? 18:16:06 <frosch123> "Denial of service using aircraft that are forcefully crashed." <- no idea what is funny about that :p 18:18:57 <frosch123> they already made fun last time when we used a ship for a dos attack 18:20:27 <planetmaker> twitter or somewhere specific? 18:20:47 <frosch123> yeah, twitter in this case 18:21:04 <frosch123> i think last time it was here in irc :) 18:22:32 <planetmaker> well :) 18:24:09 <alluke> some kids threw a snowball into my window 18:24:49 <alluke> if the police hadnt seized my elephant rifle last week i would had shot them 18:24:52 <planetmaker> time to close it :) 18:27:48 *** abchirk_ [~abchirk@f052230072.adsl.alicedsl.de] has joined #openttd 18:34:13 *** Tom_Soft2 [~id@37.140.121.231] has quit [Ping timeout: 480 seconds] 18:34:53 *** Jomann [~abchirk@e178187046.adsl.alicedsl.de] has quit [Ping timeout: 480 seconds] 18:37:04 <Hazzard> lol what 18:45:21 <DorpsGek> Commit by translators :: r26146 /trunk/src/lang (luxembourgish.txt turkish.txt) (2013-12-07 18:45:13 UTC) 18:45:22 <DorpsGek> -Update from WebTranslator v3.0: 18:45:23 <DorpsGek> luxembourgish - 40 changes by Phreeze 18:45:24 <DorpsGek> turkish - 56 changes by wakeup 18:52:31 *** jonty-comp [~jonty@borealis.jontysewell.net] has quit [Remote host closed the connection] 18:53:50 *** jonty-comp [~jonty@borealis.jontysewell.net] has joined #openttd 19:13:24 *** Super_Random [~kvirc@75-102-176-79.d2.itctel.com] has quit [Read error: Connection reset by peer] 19:17:20 *** Gethiox2 [~gethiox@actf6.neoplus.adsl.tpnet.pl] has joined #openttd 19:23:49 *** Gethiox [~gethiox@actg241.neoplus.adsl.tpnet.pl] has quit [Ping timeout: 480 seconds] 19:33:24 *** Progman [~progman@p57A1A508.dip0.t-ipconnect.de] has joined #openttd 19:35:21 *** bdavenport [~davenport@chronos.rpi.mindlesstux.com] has joined #openttd 20:21:01 *** retro|cz [~retro@ip-89-176-82-80.net.upcbroadband.cz] has quit [Ping timeout: 480 seconds] 20:34:26 <frosch123> @seen zuu 20:34:26 <DorpsGek> frosch123: zuu was last seen in #openttd 2 weeks, 5 days, 23 hours, 21 minutes, and 39 seconds ago: <Zuu> frosch123: The only good about that is if someone re-order the settings it has the ability to recover from that. 20:37:48 *** Super_Random [~kvirc@75-102-176-79.d2.itctel.com] has joined #openttd 20:39:58 *** Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has left #openttd [] 20:43:19 *** Super_Random [~kvirc@75-102-176-79.d2.itctel.com] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/] 20:45:32 *** alluke [~oftc-webi@cs181208223.pp.htv.fi] has quit [Quit: Page closed] 20:53:38 *** retro|cz [~retro@ip-89-176-82-80.net.upcbroadband.cz] has joined #openttd 21:14:05 *** DanMacK_ [~63f9c362@188.cimarosa.openttdcoop.org] has joined #openttd 21:21:15 *** HerzogDeXtEr [~flex@i59F6D11B.versanet.de] has quit [Read error: Connection reset by peer] 21:22:20 *** HerzogDeXtEr [~flex@i59F6D11B.versanet.de] has joined #openttd 21:23:18 *** retro|cz [~retro@ip-89-176-82-80.net.upcbroadband.cz] has quit [Ping timeout: 480 seconds] 21:31:52 *** DanMacK_ [~63f9c362@188.cimarosa.openttdcoop.org] has quit [Quit: Page closed] 21:46:58 <__ln__> i wish to register a complaint 21:52:30 <__ln__> all the new windows open on the left, and i need to turn my head to see them. 21:55:45 <frosch123> lies 21:55:53 <frosch123> the ottd window is always on the right screen 21:56:34 *** Pensacola [~quassel@h220216.upc-h.chello.nl] has quit [Remote host closed the connection] 21:59:38 <__ln__> also, i need to run ottd in windowed mode to be able to use it on three physical screens. 22:00:14 <frosch123> that's the fault of your os 22:01:24 *** LeandroL [~leandro@190.189.0.224] has quit [Ping timeout: 480 seconds] 22:02:48 <frosch123> if it is a fault at all, i would consider it intentional 22:03:12 <Sacro> __ln__: you shouldfile a bug with the devs 22:03:22 <Sacro> Get Eddi|zuHause to fix it 22:03:36 *** Myhorta [~Myhorta@10.87.37.188.rev.vodafone.pt] has quit [Ping timeout: 480 seconds] 22:03:36 <frosch123> you always have the game only on one screen 22:03:48 <Sacro> MS-DOS only supports one screen 22:03:49 <frosch123> the other screens are used for social networks and streaming 22:04:37 <__ln__> actually, years ago on Linux, using GeForce FX 5200, i was able to run ottd in fullscreen on two physical displays, which was actually pretty cool. 22:05:39 *** oskari89 [oskari89@62-241-226-106.bb.dnainternet.fi] has quit [] 22:13:37 *** LeandroL [~leandro@190.189.0.224] has joined #openttd 22:13:43 <__ln__> "Glactar le: PaisinéirÃ, Post, EarraÃ" 22:17:33 *** onezero [~user@0001c18e.user.oftc.net] has quit [Ping timeout: 480 seconds] 22:36:21 *** sla_ro|master [slamaster@78.97.205.68] has quit [] 22:49:01 *** DanMacK [~453f3a69@188.cimarosa.openttdcoop.org] has quit [Quit: Page closed] 23:15:03 *** FLHerne [~FLHerne@dsl-217-155-24-22.zen.co.uk] has joined #openttd 23:18:16 *** gelignite [~gelignite@i528C358C.versanet.de] has quit [Quit: http://bit.ly/nkczDT] 23:26:51 *** frosch123 [~frosch@frnk-4d008233.pool.mediaWays.net] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn] 23:41:53 *** KritiK [~Maxim@0001264a.user.oftc.net] has quit [Quit: Leaving] 23:50:08 *** Ristovski [~rafael@89.205.3.77] has quit [Ping timeout: 480 seconds] 23:50:18 *** Alice3 [~Alice@cpc18-grim14-2-0-cust478.12-3.cable.virginm.net] has quit [] 23:50:23 *** onezero [~user@0001c18e.user.oftc.net] has joined #openttd 23:56:50 <NGC3982> Evening. 23:57:20 <NGC3982> __ln__: From the sound of it, that does not seem odd. 23:57:50 *** Progman [~progman@p57A1A508.dip0.t-ipconnect.de] has quit [Remote host closed the connection]