IRC logs for #openttd on OFTC at 2013-12-07
⏴ go to previous day
00:03:25 <planetmaker> Eddi|zuHause, 'blooming' is a hardware property of CCDs - charged *coupled* devices. If too many charges are gathered in the well of one pixel they "spill over" to the adjacent pixels; typically only in one line as CCDs read-out hardware usually operates on lines of the device
00:05:52 <glx> planetmaker: like the green line when a powerfull light is in the field ?
00:07:42 <glx> ha yes I had something similar on a video
00:08:07 <planetmaker> if it happens on a CCD which uses a Bayer colour pattern, it might give the impression that the line is coloured with red/green or green/blue, thus green
00:08:32 <glx> it was a full vertical line
00:08:58 <planetmaker> well, blooming goes in single lines typically
00:09:47 <planetmaker> The colour of adjacent pixels is typically alternating between blue/green and red/green and shown is an interpolation of intensities of the vicinity to get a value for each of the 3 colour channels
00:09:52 <planetmaker> so... might be green
00:10:11 <glx> I can't remember the exact color
00:13:20 <planetmaker> yeah, well :) The colour depends on the applied colour pattern and algorithm used to make-up colour from the grayscale values of the individual pixels which were gathered with a colour band-pass filter in front of the actual sensitive area...
00:13:57 <planetmaker> Though in a complete video I'd not expect that to be a case of blooming but rather some other hardware fault
00:14:13 <planetmaker> blooming only occurs when you really have way too much light input
00:14:53 <planetmaker> and only for CCDs. Video cameras might as well be CMOS due to a slight speed advantage there - and which doesn't suffer from this drawback
00:15:38 <planetmaker> (but CCDs are more light sensitive than CMOS - so depends what you want. And engineering made both sort of sensors nearly identical wrt performance for usual applications)
00:34:39 <glx> it was only for a sequence
00:38:30 *** Myhorta has joined #openttd
00:40:36 <planetmaker> well :) hard to tell without actually seeing it and better knowing which camera it was made with. Many things can go wrong :)
00:43:18 <glx> but it was clearly caused by the powerfull light in the field
00:46:52 *** bdavenport has joined #openttd
00:48:20 *** treaki_ has joined #openttd
00:49:12 <planetmaker> yeah, then it's likely the cause. Though you can have a similar optical effect. Like when outside in the dark and you squint at a street light. It will also have streaks of light extending from the source up and downward (perpendicular to your eye lids)
00:54:01 *** geoffreybeene has joined #openttd
01:44:31 *** yorick_ has joined #openttd
02:14:50 *** Hazzard has joined #openttd
02:39:43 *** Endymion_Mallorn has joined #openttd
04:32:31 *** Endymion_Mallorn has left #openttd
04:33:15 <Eddi|zuHause> orudge: i think the forum is broken (eternally in "backup" mode)
04:35:39 *** onezero has joined #openttd
04:38:40 <SpComb> teh forums are teh br0ken
05:20:34 *** HerzogDeXtEr has joined #openttd
05:55:35 *** Tom_Soft has joined #openttd
05:56:17 *** Eddi|zuHause has joined #openttd
06:01:42 *** Super_Random has joined #openttd
06:06:52 *** Randominty has joined #openttd
07:22:17 *** sla_ro|master has joined #openttd
07:49:41 *** Tom_Soft has joined #openttd
08:03:28 *** GriffinOneTwo has joined #openttd
08:14:54 *** Tom_Soft has joined #openttd
08:19:48 *** Tom_Soft2 has joined #openttd
08:41:33 *** Progman has joined #openttd
08:56:33 *** Endymion_M has joined #openttd
08:58:25 <Endymion_M> Hi, I was wondering, why are there no highways for RVs to use?
08:58:42 *** Randominty has joined #openttd
08:58:52 <V453000> nobody coded them, presumably
08:59:23 <planetmaker> Endymion_M, have a look at the DutchRoadFurniture set
08:59:33 <planetmaker> good morning everyone :)
09:00:04 <planetmaker> :) sleep well, Supercheese
09:00:22 <Supercheese> I shall, farewell
09:01:13 *** Pensacola has joined #openttd
09:05:07 <Endymion_M> Planetmaker, I shall. I will admit that I just recently upgraded to 1.3.2 from 1.2.3, I was playing with RVs without any NewGRFS, and then I looked and found none. also, is there anything like path signals for roads"?
09:05:14 *** Endymion_M has left #openttd
09:05:34 *** Endymion_M has joined #openttd
09:06:28 <Endymion_M> Silly thing booted me.
09:09:59 <Endymion_M> sorry, cat on tablet keyboard. House rules required RVs for Goods.
09:11:29 *** andythenorth has joined #openttd
09:11:37 <Endymion_M> Yeah. I upgraded to LAN with the wife and a friend.
09:11:58 <V453000> well obviously but the house rules generally need to have a reason :)
09:12:06 <V453000> and having RVs for goods is not a very enlightened idea
09:12:28 <Endymion_M> The wife likes her buses, etc.
09:12:37 <planetmaker> Endymion_M, well, RV don't need path signals, they can just drive and in the worst of circumstances even teleport :D
09:12:59 <andythenorth> RVs should be implemented as trains
09:13:04 <andythenorth> I keep meaning to do that :P
09:13:17 <planetmaker> and the roadfurniture is just visual, nothing really changes except that you can build the impression of having highways
09:13:19 <Endymion_M> well, I just kept seeing them get clobbered by trains.
09:13:27 <andythenorth> I noticed in our MP games, only me and alberth use RVs
09:13:51 <V453000> well yeah because RVs are worthless :P
09:13:55 <andythenorth> I think other people described them variously as 'cheating' 'fiddly and pointless' 'rubbish' 'low capacity' 'uninteresting'
09:14:25 <planetmaker> andythenorth, this game "enforces" a sensible mixture of transport modes: long-distance: train. short-distance: RV, water: ships :)
09:14:34 <Endymion_M> Heh. That's about it for 'em. but... loss
09:14:55 <andythenorth> planetmaker: you missed air transport :P
09:15:06 <planetmaker> damn, I hoped no-one would notice :D
09:15:08 <andythenorth> so could anyone patch cdist for me?
09:15:21 <Endymion_M> Either way. thank you. I'm gonna go sleep now.
09:15:30 <andythenorth> specifically, I want to put certain cargo labels in the openttd.cfg, and have them ignored by cdist
09:15:31 <planetmaker> air transport is good for helicopters transporting bags of valuables from bank to bank
09:15:39 <andythenorth> ^^ this is just a hack to test gameplay
09:15:53 <andythenorth> air transport is also good for FIRS supplies :P
09:15:55 <andythenorth> but not with cdist
09:16:18 <V453000> nothing is good with cdist :)
09:16:27 <andythenorth> I have a game going to test FIRS, Iron Horse and Squid. But cdist ruins it.
09:16:32 <andythenorth> and I can't be bothered to start another
09:16:44 <andythenorth> that will also ruin it
09:16:45 <planetmaker> just switch cdist off, andythenorth ?
09:17:02 <andythenorth> then all the elaborate transfers will stop working
09:17:06 <andythenorth> I'll have to go fix them :P
09:17:15 <andythenorth> and reengineer my pax network completely
09:17:21 <andythenorth> cdist is mostly good ;)
09:17:55 <andythenorth> so I guess these grfs might end up untested by me until Christmas time or such :)
09:18:27 <andythenorth> maybe I can find the cdist special case handling for armoured and extend it
09:19:37 <andythenorth> wonder what happens if I just set armoured class on supplies cargos? o_O
09:33:44 *** LordAro has joined #openttd
09:36:58 *** Alberth has joined #openttd
09:36:58 *** ChanServ sets mode: +o Alberth
09:42:58 *** Ristovski has joined #openttd
09:58:11 *** skyem123 has joined #openttd
10:01:19 *** valhallasw has joined #openttd
10:02:46 *** oskari89 has joined #openttd
10:07:24 *** gelignite has joined #openttd
10:24:41 *** frosch123 has joined #openttd
10:39:52 *** tokai|noir has joined #openttd
10:39:52 *** ChanServ sets mode: +v tokai|noir
10:45:59 <michi_cc> andythenorth: There are some bits about the standardized track scheme in yesterday mornings backlog which you might want to check out.
10:46:32 <planetmaker> michi_cc, I made a note following your remarks in the ticket andythenorth created :)
10:47:43 <planetmaker> hard to see if you don't know the issue existed in his project. Nor did I mention it :)
10:51:52 <andythenorth> planetmaker: thanks :)
10:55:31 <michi_cc> andythenorth: Read the last section on the wiki page (summary for vehicle sets), it hopefully clearly states how to construct the appropriate label and in which cases you need to have fallbacks.
10:56:10 <andythenorth> nml or nfo spec?
10:56:12 <michi_cc> If anything is unclear, ask so I (or somebody else) can improve it.
10:56:25 <andythenorth> or the railtypes page?
10:56:40 <michi_cc> The wiki page about the standardized scheme.
10:58:24 <andythenorth> gauge, energy source and speed are all clear
10:58:48 <andythenorth> if the train set doesn't care about axle weights, what is the correct approach?
10:59:42 * andythenorth considers new 'number of axles' property :P
10:59:47 <andythenorth> let the game sort it out
11:01:14 <michi_cc> Or better, still assign them relative to some metric, i.e. If you have some heavy engines and some very lightweight ones, put the heavy ones as e.g. D and the light ones as A. The track set is required to sort it out how it wants to map the axle weights the the tracks it provides.
11:01:53 <andythenorth> in the case of this set, I'm ignoring it :)
11:01:58 <andythenorth> so I'll just set them all as A
11:02:13 <andythenorth> I don't really agree with axle weight as an interesting gameplay property :)
11:03:09 * andythenorth considers loading gauge :P
11:07:45 <michi_cc> Would IMHO be part of the gauge as a specialized subtype (e.g. like n currently is defined as second, narrower narrow gauge for sets that need two narrow gauges). So s could be the British loading gauge subtype to S. Vehicles for s can run on S, but S not on s.
11:09:25 <michi_cc> For this you would need to provide fallbacks from s to S though, unless it's okay for vehicles to be unavailable.
11:16:00 * andythenorth wonders how metro should be implemented
11:16:27 <andythenorth> that's probably solved already
11:17:29 <planetmaker> usually metro is standard gauge and possibly 3rd-rail power
11:17:32 <andythenorth> the current implentation in Iron Horse grf is not compliant with the scheme
11:17:34 <planetmaker> at least in this country
11:18:16 <andythenorth> also the standard scheme reserves M for monorail
11:18:23 <andythenorth> so the current implementation violates the scheme :P
11:18:44 <planetmaker> it's not yet released... :) ^
11:19:00 <andythenorth> needs a solution :(
11:19:09 <andythenorth> could declare metro a special class of NG
11:19:42 <planetmaker> the question is: are metro tracks really different from other tracks - or is it simply different use cases for the same track?
11:20:23 <andythenorth> I am not really approaching it that way
11:20:39 <andythenorth> for gameplay reasons metro is incompatible with standard trains
11:20:49 <andythenorth> it causes player to have to make interesting choices
11:21:00 <planetmaker> good enough reason
11:21:01 <andythenorth> the goal of IH is to only have to make interesting choices
11:21:13 <andythenorth> most train grfs have gotten too big, and are full of boring choices
11:21:16 <andythenorth> it's like going to IKEA
11:21:35 <michi_cc> The scheme doesn't really "reserve" anything. A label that starts with M but where the three other letters are not defined in the scheme is "free".
11:21:51 <andythenorth> so metro is super high capacity, not very fast, high acceleration, and incompatible with standard trains
11:22:24 <Alberth> most train grfs are not designed from game play perspective
11:22:43 <andythenorth> we have made ourselves a nice model train simulator though :)
11:23:13 * andythenorth proposes changing newgrf spec to reflect actual model trains :P
11:23:22 <andythenorth> so instead of axle load, track is code 75 or code 100
11:23:25 <planetmaker> andythenorth, from that perspective, any track gauge type class would do which none of your other vehicles uses
11:23:27 <andythenorth> and some trains don't work on code 75
11:23:32 <planetmaker> which could be monorail
11:23:40 <Alberth> numbers change for each country
11:24:22 * planetmaker has no idea what the numbers refer to which andy mentioned
11:24:45 <planetmaker> is it like order numbers?
11:25:44 <andythenorth> it's height of the actual rail
11:26:04 <andythenorth> cheap / older trains have wheel flanges too deep, so they bump along the sleepers
11:26:24 <andythenorth> model train world is full of details :P
11:26:53 <Alberth> not unlike the real train world :p
11:36:09 <andythenorth> then there are different coupling types, different electrical systems, variations in scale etc
11:36:22 <andythenorth> we should definitely extend newgrf to support it
11:36:31 <andythenorth> some authors would absolutely love it
11:36:39 <andythenorth> it would be detail-freak-fest
11:36:44 <andythenorth> imagine the spec wars we could have
11:36:59 <Alberth> maybe we can turn it into a honey pot? :p
11:39:37 <andythenorth> my thought too :P
11:40:14 <andythenorth> meanwhile....michi_cc I can't tempt you to write some cargo routing module for cdist? o_O
11:40:21 <andythenorth> optimised for FIRS supplies?
11:40:32 <andythenorth> fonso said it was likely possible
11:56:06 * andythenorth looks for a way to find position of vehicle in an *articulated consist*
11:56:12 <andythenorth> I can't see a var for that :)
11:56:35 <andythenorth> I can make the compiler sort it out, but I don't want to re-invent stuff already in newgrf spec...
11:57:13 <andythenorth> I can't trivially use the counter on the articulated callback - I need something for a sprite-drawing time switch
12:08:18 <fonsinchen> andythenorth: ARMOURED isn't really a special case in cargodist
12:08:37 <fonsinchen> It's just a UI thing
12:09:27 *** andythenorth has joined #openttd
12:11:52 <fonsinchen> The choice of cargos shown as separate entries in the cargodist settings is pretty arbitrary
12:13:28 <fonsinchen> Internally it keeps a setting for each cargo.
12:14:33 <fonsinchen> I just didn't want to make a list of 32 entries in the settings menu
12:14:56 <andythenorth> but could it be exposed in openttd.cfg or such?
12:15:02 <andythenorth> even if this is just a hack to test?
12:15:18 <Alberth> a bit in the cargo description?
12:15:35 <andythenorth> wondered about that
12:15:38 <planetmaker> I wonder about that. How much would it confuse users, though?
12:15:45 <andythenorth> is it right for the newgrf to be making choices about cidst though?
12:15:48 <planetmaker> It definitely has pros
12:15:57 <andythenorth> I'm confused about what the proper domain is for control of this
12:16:47 <planetmaker> maybe it needs a setting like "use always cargodist" "use cargodist unless newgrf disagrees"
12:16:58 <planetmaker> "don't use cargodist"
12:17:18 <planetmaker> so in the 2nd case the bit from newgrf is heeded. But meh... combinatoric settings explosion :D
12:17:20 <Alberth> it's too realistic :p
12:18:00 <fonsinchen> Actually I was wrong. I've changed that at some point. The linkgraph settings only have entries for pax, mail, armoured and default. However, that could easily be extended as all access goes through GetDistributionType(CargoID cargo),
12:18:43 <andythenorth> I think the 'correct' solution is to allow destinations (industries, houses or maybe towns) to express demand :P
12:18:47 <andythenorth> but that is a big project
12:18:59 <andythenorth> easier to kludge a load of things together that mostly work :)
12:18:59 <planetmaker> hm... cargo property which defines the cargodist treatment of it (assigns class for cargodist to pax/mail/armoured/other)?
12:21:48 <fonsinchen> andythenorth: They already do express demand. It's just very coarse grained: either "has demand" or "has no demand"
12:22:12 <fonsinchen> By adding a number to that we could easily improve things
12:22:59 <andythenorth> I can think of ways (for example) for newgrf industry to modify a demand amount
12:23:07 <andythenorth> houses might better depend on the town :P
12:24:04 <andythenorth> I would be concerned about responsiveness / latency though :)
12:24:46 <Alberth> would be useful for ECS if the cargo itself would manage the flow
12:24:52 <andythenorth> industries trying to set demand every production cycle (8 or 9 times / month) would be ummm....bad I think
12:25:11 <andythenorth> the routing wouldn't keep up
12:25:14 <Alberth> although not everybody may share my pov :)
12:25:30 <andythenorth> industries expressing a longer term demand might be better
12:25:36 <andythenorth> maybe in a scale free way :P
12:25:42 <fonsinchen> Latency is definitely a problem. You shouldn't completely stop accepting cargo, but instead reduce the amount accepted to 1.
12:26:22 <fonsinchen> If everything works ok that should lead to "practically no cargo" being planned for that route, but existing cargo already on its way can still be delivered.
12:26:30 <Alberth> fonsinchen: just don't promise you will do what the industry says?
12:26:35 <andythenorth> I would never stop accepting anyway :)
12:26:57 <fonsinchen> Well, FIRS does that, doesn't it? Or was that ECS?
12:27:18 <andythenorth> it's an anti-pattern
12:28:09 <Alberth> if you interpret 0 as "long term", then the current cargo on route can still be delivered
12:29:03 <Alberth> can't you program industry to accept but not pay?
12:29:36 <Alberth> or accept but not stockpile?
12:30:15 <planetmaker> in principle you can accept cargo if the industry says 'no' but the tile says 'yes'
12:30:26 <planetmaker> but that's a very very bad hack
12:33:35 <fonsinchen> Well, technically the demand is expressed by the added "tile demands" divided by 8 and passed to the link graph like that
12:33:48 <frosch123> scan all newgrfs for all existing cargo labels, and then put a setting for each into adv. settings? :p
12:34:08 <fonsinchen> By increasing tile demands you can make the link graph route more cargo to that place (theoretically, no one has tested that, probably)
12:34:29 <fonsinchen> See station_cmd.cpp:576
12:37:04 <fonsinchen> There is probably a limit on the amount of acceptance you can define per tile
12:37:22 <fonsinchen> Someone should look that up in the newgrf docs
12:37:51 <fonsinchen> But you can definitely change the cargo acceptance while the game is running
12:37:59 <frosch123> so industries which use more tiles have higher demands?
12:38:32 <frosch123> resp. covering a bigger area of a industry in station catchment area increases demand?
12:39:04 <fonsinchen> That is probably a side effect of this technique
12:41:26 <fonsinchen> It only works like that for asymmetric, though. See demands.cpp lines 65 and 123
12:44:04 <andythenorth> does it seem more correct to go by demand than arse around modifying the cargo?
12:44:43 <andythenorth> the routing of cargo has more to do with the behaviour of the destination than the attributes of the cargo imho
12:45:35 <andythenorth> if demand was expressed for each cargo, for every tile of the map...then GS could also modify it
12:45:49 <andythenorth> allowing more interesting challenge-based gameplay
12:45:57 <fonsinchen> It already is expressed like that
12:46:24 <fonsinchen> You can specify the amount of "acceptance" per tile in industries and houses somehow
12:46:41 <fonsinchen> There must be a newgrf function for that
12:46:54 <frosch123> i am not convince that it makes sense to do that "per tile"
12:47:11 *** Devroush has joined #openttd
12:48:37 <fonsinchen> Well, we could add something on top of this, but that's what we already have. Someone should try if it works.
12:52:23 <MNIM> one day my freeciv empire is just going to collapse on its' own weight
12:54:44 *** zeknurn has joined #openttd
12:55:16 <fonsinchen> That should be enough to steer the distribution.
12:57:47 <andythenorth> ok so I could patch FIRS to try and set that
12:57:59 <andythenorth> could just set static demand amounts initially
12:58:25 <andythenorth> if I set different values for different industry types, but same accepted cargo...we can test
12:58:52 <andythenorth> can't do it now - going to a wedding :)
12:59:01 <andythenorth> but when I next have time :)
12:59:27 <andythenorth> or if someone else wanted to adjust FIRS and compile.... :P
13:09:53 <fonsinchen> However, the presence of 4 bits for each would technically let you specify 0 to 15.
13:10:25 <fonsinchen> Also, there are 4 unused bits in the end which we could define as "multiplier"
13:12:51 <frosch123> it feels weird that demand would depend on how much of the industry the station covers. shouldn't it rather be a thing of the industry instance?
13:13:06 <frosch123> would also make it accessible to gs then
13:15:09 <Kjetil> it is not very realistic at least
13:15:44 <Kjetil> I mean a factory usually only accepts cargo at a specific location
13:16:37 <planetmaker> where an industry accepts or supplies cargo does not matter on our scale
13:16:41 <frosch123> yes, that may define whether an industry accepts cargo, but not how much it accepts
13:16:53 <planetmaker> doing differently is unrealistic and not adding anything to gameplay
13:17:43 <fonsinchen> But how would you implement it?
13:18:05 <fonsinchen> Stations don't really know the industries surrounding them. They do know the tiles, though.
13:18:07 <frosch123> a factor in the Industry instance
13:19:00 <Kjetil> planetmaker: I totally agree. I was just making an argument for that the amount of cargo accepted shouldn't be dependent on the station coverage
13:19:01 <frosch123> fonsinchen: there is Station::industries_near
13:19:10 <fonsinchen> The amount of tiles covered does already decide upon acceptance of a station, btw.
13:19:29 <fonsinchen> It's just a yes/no type decision so far. Not a number
13:19:35 <frosch123> a newgrf could define an initial demand factor per cargo, which defaults to 1 (all industries accepting a cargo have the same demand)
13:19:42 <Kjetil> fonsinchen: as it should be :)
13:19:50 <frosch123> a gs could defnie an addtional multiplier
13:20:05 <frosch123> so, a newgrf could set 5, a gs could set 2, and the product 10 is what matters
13:20:41 <frosch123> this number could also be displayed in the industry gui, or reported to ais
13:22:11 <frosch123> we can also change cb 3d to dynamically change the demand
13:22:48 <frosch123> maybe that would fix industry stockpiles
13:23:14 <frosch123> industires would no longer hard-stop accepting cargo, but just lower their demand weight
13:23:19 <fonsinchen> So, for each tile in GetAcceptanceAroundTiles you'd check which industry it belongs to and then apply that factor?
13:23:41 <fonsinchen> That's basically the same as having the industry specify the tile acceptances.
13:24:13 <frosch123> tiles decide whether a industry accepts a cargo just now
13:24:25 <frosch123> once it accepts the cargo, it is added to the Station structure in some list
13:24:31 <frosch123> maybe the same as industry_near
13:24:44 <frosch123> and then instance defines the demand for that cargo, independent of the amoutn of tiles covered
13:25:44 *** Midnightmyth has joined #openttd
13:26:03 <frosch123> industries_near is already used today to deliver cargo to industries
13:26:11 <frosch123> though i am not sure how it considers different cargo types
13:26:25 <fonsinchen> What about funny people who cover 3 tiles of each of two power plants with one station and thus get coal accepted without covering enough of one power plant to get coal accepted "normally"?
13:27:57 <frosch123> that's already the case today
13:28:02 <frosch123> houses also add to acceptance
13:28:16 <frosch123> a station accepting a cargo does not affect which industry is delivered
13:28:57 <frosch123> ah, DeliverGoodsToIndustry does not differ per cargo_type
13:29:07 <fonsinchen> But what would that mean for demand?
13:29:16 <frosch123> it delivers the cargo to the best industry which is somehow in the catchment area
13:29:20 <frosch123> independent of the tiles involved
13:29:49 <frosch123> fonsinchen: demand is defined by the average or the sum of the demands of the industries in Station::industry_near
13:30:01 <frosch123> using the same logic as DeliverGoodsToIndustry
13:30:25 <frosch123> possible changing IndustryTemporarilyRefusesCargo to return a scaling factor instead of yes/no
13:31:28 <frosch123> currently tile acceptance and deciding which industry is delivered are completely independent
13:32:13 <frosch123> unifying that is one case (which belongs into the area of unifying acceptance and pickup areas)
13:32:28 <frosch123> but demand should depend on the industries being delivered
13:35:47 <fonsinchen> The whole thing seems unnecessarily complex to me. Why is there an IndustryTemporarilyRefusesCargo after all?
13:36:18 <fonsinchen> They could have used that tile acceptances for that, too
13:36:25 <frosch123> but i don't get your argument
13:36:33 <frosch123> demand per instance feels way easier than per tile
13:36:52 <frosch123> fonsinchen: tile acceptance has nothing to do with industry delivery
13:37:18 <frosch123> they are independent, and updated asynchronously
13:37:26 <frosch123> sometimes they are inconsistent
13:37:43 <fonsinchen> That's the problem. The tiles could specify acceptance without any industry actually accepting cargo and the industry could specify acceptance without any tiles doing so.
13:37:50 <fonsinchen> That should be unified
13:37:55 <frosch123> btw. various industries also accept passengers according to tile acceptance
13:37:59 <frosch123> e.g. oilrig and steel mill
13:38:10 <Alberth> at least tile acceptance is not considered input for the industry, in eg the industry chain window
13:38:23 <fonsinchen> That should be written in their industry windows as normal cargo then.
13:38:37 <frosch123> well, that's how ttd is
13:39:21 <planetmaker> what would break if we simply kill tile acceptance for industries?
13:39:22 <fonsinchen> OK, we can just shrug it off like that. However, then there is no inherently preferable way to implement demands.
13:39:25 *** LordAro has joined #openttd
13:39:31 <frosch123> planetmaker: oilrigs
13:39:49 <planetmaker> passengers there, which could be changed, no?
13:39:51 <frosch123> well, i am convided. making demand depend on tile acceptance is plain wrong :p
13:39:53 <Alberth> pax acceptance of default industries (coal mine iirc)
13:40:15 <frosch123> industry production is not controlled by tile acceptance
13:40:24 <fonsinchen> Oilrigs, coal mines, ... should just specify passengers as normal accepted cargo then.
13:40:40 <planetmaker> would really anything break, if those few tiles did not accept anymore 1/8 passengers or so?
13:40:59 <frosch123> well, you can remove the heliport from oilrigs then :p
13:41:29 <frosch123> anyway, are we now down to that original ttd is wrong, and we should redo the game into something different?
13:42:37 <frosch123> you cannot just redefine what tile acceptance means
13:46:37 <fonsinchen> Well, I can add a second meaning to tile acceptance. It's not so far off to say that the more cargo is accepted by each tile the more cargo the link graph will try to route there.
13:48:13 <frosch123> i guess tile acceptance works for houses and oilrigs
13:48:33 <frosch123> but i think it is really weird for processing industries
13:48:55 <frosch123> considering houses, gs may set it per town?
13:49:06 <frosch123> s/tile area/region/
13:50:31 <planetmaker> we have already local authority zones
13:50:36 <planetmaker> so no new concept there really
13:52:51 <frosch123> hmm, so demand could be defined by ("house tile acceptance" + "industry tile acceptance if industry does not process cargo") * "town factor" + "industry factor if industry processes the cargo"
13:53:38 <frosch123> newgrf can set tile acceptance for houses, and factor for industry types
13:53:43 <fonsinchen> Just stick to the tiles for industries, too. Everything becomes so much simpler then.
13:53:45 <frosch123> gs can set factor for towns and industry instances
13:54:08 <fonsinchen> A GS setting the factor would just trigger a loop over all involved tiles
13:54:36 <frosch123> well, one can try. maybe tile accepance for industries is simpler, but it is also very intuitive when playing imo
13:55:14 <frosch123> but, ok, if you display the demand during station construction, it could replace the current yes/no decision
13:55:43 <frosch123> but newgrf have to very carefully scale the demand per tile depending on how many tiles the industry has in total
13:55:50 <frosch123> which makes it weird for default industries
13:55:58 <frosch123> though they have about the same size
13:56:20 <fonsinchen> People already know that they have to cover as much as possible of the industry to get acceptance.
13:56:26 <frosch123> but firs has very differently sized industries, so i guess current firs would be very broken
13:57:03 <fonsinchen> And by allowing values >8 everywhere one could model the demand without fearing loss of acceptance at nearby stations.
13:57:36 <fonsinchen> What would change for current firs?
13:58:00 <frosch123> you either have to make only some tiles accept the cargo, or you have to scale the acceptance per tile with industry size
13:58:21 <fonsinchen> No, just let the newgrf specify tile acceptance.
13:58:27 <frosch123> there are industries with size 1x1 or 2x2, and ones with 16x10
13:58:43 <fonsinchen> Well for the small industry you specify a high acceptance then
13:58:57 <frosch123> yes, thus current firs would be broken
13:59:01 <fonsinchen> And btw, if all industries accepting the same cargo have low acceptance, that's no problem
13:59:07 <frosch123> while default industries may be lucky
13:59:31 <fonsinchen> The demands are relative to total sum of demands in link graph after all
13:59:48 <frosch123> yes, the problem only exists for industries accepting the same cargo
14:00:20 <fonsinchen> So there are industries of 1x1 and others of 16x10 which accept the same cargo in firs?
14:00:39 <frosch123> the supplies are accepte by very different industries
14:01:25 <fonsinchen> Now I see the problem. However, that would just mean: Don't use cargodist with firs until the acceptances are fixed.
14:02:19 <frosch123> yeah, i tried to keeping it compatible. but considering that the default industries are not affected, actively deciding to break firs might work :p
14:04:11 <frosch123> but the station gui need to display the demand somehow
14:05:28 <frosch123> demand: manufacturing supplies (low), steel (medium), coal (high)
14:05:32 <frosch123> or something like that
14:05:33 <fonsinchen> It could pull it from the link graph
14:05:43 <frosch123> i mean during construction
14:05:50 <frosch123> so you can better figure out which tiles to cover
14:06:10 <fonsinchen> There we can probably afford looping over the tiles
14:06:30 <frosch123> i think currently firs accepts the cargo on almost all tiles
14:06:48 <frosch123> while i would expect that to change, so only some tiles accept the cargo
14:07:15 <frosch123> if the industry is bigger than the usual catchment area, you would otherwise have to build the station around the industry, instead of next to it
14:07:20 <frosch123> which i would consider bad gameplay :p
14:07:49 *** MrShell has joined #openttd
14:08:02 <frosch123> i.e. making it possible to cover all tiles with acceptance with a single station
14:08:22 <fonsinchen> It doesn't really depend on size of the industry, but rather on tile acceptance. You could increase the tile acceptances of small industries and leave the ones of large industries as they are.
14:08:45 <frosch123> if the industry is 16x10, you cannot cover it with a normal station
14:08:54 <frosch123> you have to station-walk around the industry to cover all tiles
14:08:55 <fonsinchen> You don't have to cover the whole industry
14:09:20 <frosch123> to get maximum demand, i would have to
14:09:31 <fonsinchen> But why would you want maximum demand?
14:09:44 <fonsinchen> To artificially increase cargo flow to that industry?
14:10:00 <fonsinchen> Then just build multiple stations next to it
14:10:07 <frosch123> assuming you play coop style with always station walking 64x64 stations
14:10:17 <frosch123> you would get very different demand flows than a normal palyer
14:10:27 <frosch123> so, firs has a hard time to balance that
14:10:32 <fonsinchen> But if you do that you know what you're doing
14:10:36 <frosch123> unless it restrict the tilearea of acceptance
14:11:23 <fonsinchen> For the normal player hardly anything would change. And the coop players will have to come up with new strategies to deal with it.
14:11:34 <fonsinchen> That's their "job" after all.
14:11:47 <Kjetil> So.. are you planning to implement variable size industries as well ?
14:12:00 <fonsinchen> That's something else
14:12:06 <frosch123> also normal players would like to know whether they cover the industry properly
14:12:31 <frosch123> currently the construction gui displays yes/no for acceptance
14:12:31 <fonsinchen> The demand should be shown in the station building gui and in the station window, yes
14:12:45 <fonsinchen> How does it do that?
14:12:46 <frosch123> if it suddenly becomes low/high demand, it should display that
14:13:06 <fonsinchen> It must be tile-looping already. It could as well retrieve the exact number
14:13:33 <fonsinchen> I have to leave, unfortunately
14:14:37 <frosch123> DrawStationCoverageAreaText just checks for >= 8 currently
14:14:47 <frosch123> so, yeah, it would just be changing that function
14:27:05 *** skyem123 has joined #openttd
15:46:54 *** retro|cz has joined #openttd
15:52:43 *** DanMacK has joined #openttd
15:53:18 <DorpsGek> DanMacK: andythenorth was last seen in #openttd 2 hours, 51 minutes, and 39 seconds ago: <andythenorth> bye ;)
16:01:55 *** sla_ro|master has joined #openttd
16:53:24 *** Gethiox3 is now known as Gethiox
17:11:33 *** Hazzard has joined #openttd
17:20:51 *** Super_Random has joined #openttd
17:35:16 *** valhalla1w has joined #openttd
17:51:04 *** Myhorta has joined #openttd
17:56:55 *** Superuser has joined #openttd
18:04:40 <NGC3982> It seems like the reload_config parameter actually works out fine.
18:15:43 <frosch123> why are people always making fun of ottd's cve reports? :p
18:16:07 <frosch123> "Denial of service using aircraft that are forcefully crashed." <- no idea what is funny about that :p
18:18:57 <frosch123> they already made fun last time when we used a ship for a dos attack
18:20:27 <planetmaker> twitter or somewhere specific?
18:20:47 <frosch123> yeah, twitter in this case
18:21:04 <frosch123> i think last time it was here in irc :)
18:24:09 <alluke> some kids threw a snowball into my window
18:24:49 <alluke> if the police hadnt seized my elephant rifle last week i would had shot them
18:24:52 <planetmaker> time to close it :)
18:27:48 *** abchirk_ has joined #openttd
18:45:21 <DorpsGek> Commit by translators :: r26146 /trunk/src/lang (luxembourgish.txt turkish.txt) (2013-12-07 18:45:13 UTC)
18:45:22 <DorpsGek> -Update from WebTranslator v3.0:
18:45:23 <DorpsGek> luxembourgish - 40 changes by Phreeze
18:45:24 <DorpsGek> turkish - 56 changes by wakeup
18:53:50 *** jonty-comp has joined #openttd
19:17:20 *** Gethiox2 has joined #openttd
19:33:24 *** Progman has joined #openttd
19:35:20 *** bdavenport has joined #openttd
20:34:26 <DorpsGek> frosch123: zuu was last seen in #openttd 2 weeks, 5 days, 23 hours, 21 minutes, and 39 seconds ago: <Zuu> frosch123: The only good about that is if someone re-order the settings it has the ability to recover from that.
20:37:49 *** Super_Random has joined #openttd
20:53:38 *** retro|cz has joined #openttd
21:14:05 *** DanMacK_ has joined #openttd
21:22:20 *** HerzogDeXtEr has joined #openttd
21:46:58 <__ln__> i wish to register a complaint
21:52:30 <__ln__> all the new windows open on the left, and i need to turn my head to see them.
21:55:53 <frosch123> the ottd window is always on the right screen
21:59:38 <__ln__> also, i need to run ottd in windowed mode to be able to use it on three physical screens.
22:00:14 <frosch123> that's the fault of your os
22:02:48 <frosch123> if it is a fault at all, i would consider it intentional
22:03:12 <Sacro> __ln__: you shouldfile a bug with the devs
22:03:22 <Sacro> Get Eddi|zuHause to fix it
22:03:37 <frosch123> you always have the game only on one screen
22:03:48 <Sacro> MS-DOS only supports one screen
22:03:50 <frosch123> the other screens are used for social networks and streaming
22:04:37 <__ln__> actually, years ago on Linux, using GeForce FX 5200, i was able to run ottd in fullscreen on two physical displays, which was actually pretty cool.
22:13:37 *** LeandroL has joined #openttd
22:13:43 <__ln__> "Glactar le: Paisinéirí, Post, Earraí"
23:15:03 *** FLHerne has joined #openttd
23:50:23 *** onezero has joined #openttd
23:57:20 <NGC3982> __ln__: From the sound of it, that does not seem odd.
continue to next day ⏵
