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