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

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