Back to Home / #openttd / 2013 / 12 / Prev Day | Next Day
#openttd IRC Logs for 2013-12-07

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