Log for #openttdcoop.devzone on 19th August 2011:
Times are UTC Toggle Colours
06:56:00  *** andythenorth has joined #openttdcoop.devzone
06:58:27  *** LordAro has joined #openttdcoop.devzone
07:02:11  <Brot6> FIRS Industry Replacement Set - Code Review #2986: Merge tiles of industries with more than one t... (andythenorth) @
07:05:02  <Brot6> DictatorAI - Revision 149:7e23b0243112: - Now connect the station directly when building the IN p... (krinn) @
07:51:13  *** Brot6 is now known as Guest6358
07:51:25  *** Brot6 has joined #openttdcoop.devzone
07:52:19  *** Brot6 has quit IRC
07:53:04  *** Brot6 has joined #openttdcoop.devzone
07:57:07  *** Guest6358 has quit IRC
07:59:21  *** andythenorth has quit IRC
08:48:33  *** andythenorth has joined #openttdcoop.devzone
09:25:00  <Brot6> FIRS Industry Replacement Set - Bug #2989 (New): Define all spritelayouts correctly (Terkhen) @
09:26:31  <Brot6> FIRS Industry Replacement Set - Bug #2989: Define all spritelayouts correctly (planetmaker) @
09:28:50  <Terkhen> planetmaker: ^ do you mean splitting ground and building sprites?
09:34:23  <planetmaker> yes
09:35:48  <Brot6> FIRS Industry Replacement Set - Revision 2469:dd6fa9b7885c: Codechange: Smithy Forge uses advance... (Terkhen) @
09:36:38  <Terkhen> ok :)
09:37:45  <planetmaker> ^ I like those diffs with many removed lines :-)
09:38:20  <planetmaker> I meanwhile redact my statement that spritelayout templates are complicated :-)
09:38:23  <Terkhen> it's a shame that only a few remain :)
10:12:38  <Brot6> FIRS Industry Replacement Set - Revision 2470:7dea52ba415a: Codechange: Stockyard uses advanced s... (Terkhen) @
10:18:45  <Brot6> FIRS Industry Replacement Set - Revision 2471:77628e3c4682: Codechange: Sugar Refinery uses advan... (Terkhen) @
10:21:03  <Terkhen> <--- I'm not sure, but I think that this switch is not doing anything at all
10:23:13  <planetmaker> I thought the same when I saw it. But I was / am not sure :-)
10:24:42  <Terkhen> the animation is a simple smoke cycle so I'm guessing that it is not needed
10:27:14  *** andythenorth has quit IRC
10:34:04  <Terkhen> hmm... the forest makes no sense at all
10:34:18  <Yexo> that can be rewritten to this:
10:34:45  <planetmaker> is it even needed at all?
10:34:55  <Yexo> don't know, I don't have any context at all
10:35:02  <planetmaker> next animation frame
10:35:14  <Yexo> which callback number?
10:35:20  <Yexo> nvm
10:35:36  <Yexo> always returning FE might work
10:35:56  <Terkhen> but isn't that what is done by default if you don't use animation control?
10:36:07  <Yexo> I think so
10:36:43  <Terkhen> yes, smoke works fine after removing that switch
10:37:32  <Brot6> FIRS Industry Replacement Set - Revision 2472:647bd3ca6ea4: Codechange: Textile Mill uses advance... (Terkhen) @
10:37:39  <Terkhen> well, that was the last one, I'm going to see if I can understand the forest code
10:37:50  <planetmaker> uhm, Terkhen:
10:37:58  <planetmaker> that is a random animation frame, IIRC
10:38:10  <Terkhen> the forest?
10:38:12  <planetmaker> extra_callback_info1 carries random bits
10:38:42  <Terkhen> well, in that case it is the only smoke animation that is randomized
10:38:55  <Terkhen> if we want that, it should be done for all industries in the smoke templates
10:39:37  <planetmaker> not sure it makes sense though... smoke has a defined sequence, hasn't it?
10:39:51  <Terkhen> yes
10:39:53  <Yexo> which industry is it?
10:39:56  <Terkhen> textile mill
10:40:08  <Terkhen> check the last FIRS commit, I removed the switch in that one
10:40:52  <planetmaker> but... it might be that the random bits are not enabled or so...
10:40:59  <Yexo> in which file are the tiles defined?
10:41:02  <planetmaker> <-- anim_next_frame
10:41:12  <planetmaker> industries/textile_mill.pnml
10:41:24  <planetmaker> sprites/nml/industries/textile_mill.pnml
10:41:32  <Yexo> ah, right
10:41:49  <planetmaker> each industry has its own tile, so it can stay in one file
10:42:12  <Yexo> CB_RESULT_START_ANIMATION is not even valid for anim_next_frame
10:42:32  <Terkhen> var[0x60, 0, 31, 0] <--- what is the meaning of each field?
10:42:34  <Yexo> although since the value is the same as CB_RESULT_NEXT_FRAME it will work
10:43:58  <Yexo> planetmaker: I don't see any "special_flags" property in textile_mill.pnml, so the random bits are not enabled
10:44:14  <planetmaker> yes, that's what I suspected
10:44:15  <Yexo> which means that extra_callback_info1 will probably contain zero
10:44:28  <planetmaker> I've seen that by pure chance on one industry, but I don't recall which
10:44:39  <Yexo> did the animation actually work?
10:44:44  <planetmaker> As I didn't do spritelayout templates... I let it be then. dunno
10:44:51  <Yexo> since if it really was zero the result would always be "go to animation frame 0"
10:45:01  <Terkhen> the animation works with the switch and without it
10:46:48  <Terkhen> <--- regarding the forest, the only thing that seems possible is templating each of the results of this switch; they seem to be identical besides changing sprites
10:46:53  <Yexo> ah, it was "anim_control", not "anim_next_frame"
10:46:55  <Terkhen> but I wonder if it is worth the effort
10:47:17  <Terkhen> same for fruit plantation
10:47:46  <Yexo> and the only enabled trigger was ANIM_TRIGGER_INDTILE_CONSTRUCTION_STATE
10:48:03  <Yexo> so it was intended so set a random animation state when the tile was build
10:48:16  <Yexo> it didn't influence the animation at all after building the tile
10:48:22  <Terkhen> hmm...
10:48:39  <Yexo> however since the random bit flag in special_flags was not enabled, it wasn't randomized
10:48:55  <planetmaker> Terkhen, you might want to borrow the tile height check macro I already wrote
10:49:02  <Terkhen> but maybe it is a good way of randomizing smoke so all industries don't look the same
10:49:16  <planetmaker> seeing it queries the snowline height there
10:49:37  <Yexo> a better solution would be adding just: anim_control: return extra_callback_info1 & 7;
10:49:46  <Terkhen> planetmaker: I'm wondering if it is worth the effort first, as it is a one time template of a code that is already implemented
10:49:48  <Yexo> and enabling the correct bit so there are random bits
10:50:01  <Terkhen> Yexo: I'm going to try it, if it works I'll add it to all industrytiles with smoke :)
10:50:39  <planetmaker> The purpose of this height switch is to have more or less snowy trees for the transition regions
10:50:52  <planetmaker> Might not be worth templating... Though... maybe :-)
10:51:23  <planetmaker> one name and 4 result switch names as template input
10:51:37  <Terkhen> but the code is already implemented and working
10:51:45  <planetmaker> :-)
10:51:57  <Terkhen> if we need to change it in the future, or to add more stuff
10:52:01  <Terkhen> then it can be templated IMO
10:52:13  <planetmaker> I just meant like fruit plantation, forest and maybe could need it. But you're right
10:52:23  <planetmaker> *and whatever
10:52:29  <Terkhen> :P
10:52:37  <Terkhen> spritelayouts are done then :)
10:52:56  <planetmaker> cool
10:53:10  <planetmaker> Now we can start to really enhance FIRS. Transition done, I think
10:53:52  <Terkhen> there are a few ugly looking industry tile names because I did not bother to edit industries that use default sprites / layouts, that's the last thing in my todo list after I check this smoke thing
10:53:59  <Terkhen> the smoke randomization is more of a feature, though :)
10:54:31  <planetmaker> yup, but I'm there actually quite sure it must be in sequence, if I look at the smoke bubbles rise from the industry
10:55:15  <Terkhen> randomization would only be for the BUILDING_SMOKE_BIG template
10:55:35  <Terkhen> bubbles would need an alternative method, probably a randomized delay before starting the animation
10:55:39  <planetmaker> I've no idea about those templates yet :-)
10:55:51  <planetmaker> sounds good, yes
10:55:53  <Terkhen> the "big" smoke is the default smoke column
10:56:03  <Terkhen> there is always smoke present, it just moves a bit
10:56:12  <Terkhen> then we have two "small" smoke templates, one dark and another white
10:56:20  <planetmaker> <-- I'm somewhat bothered by this task wrt fences
10:56:22  <Terkhen> those produce a small puff of smoke that rises and dissapears
10:56:44  <planetmaker> ah, ok, yes, the big one could be more variable, more sizes or so
10:57:01  <Terkhen> more sizes?
10:57:11  <planetmaker> depending on production_level ;-)
10:58:59  <planetmaker> except those fence glitches, I have fences completely templated... I don't have the code here right now, though
10:59:01  <Terkhen> sounds quite complicated :P
10:59:13  <Terkhen> the smoke on production thing
10:59:45  <planetmaker> dunno... production_level is an industry variable. It simply needs reading
11:00:07  <Terkhen> but the smoke needs sprites
11:00:11  <planetmaker> yep :-P
11:00:35  <Terkhen> the current long column of smoke has a problem, in some industries it is drawn outside of the current tile and glitches a lot
11:00:39  <Terkhen> andy has mentioned this a lot of times
11:00:53  <Terkhen> if we had different smoke sprites they could be made more straight so they don't glitch
11:01:04  <Terkhen> but IIRC andy also mentioned he wasn't interested in new smoke sprites
11:01:16  <planetmaker> solution found ;-)
11:01:38  <Terkhen> which one?
11:01:57  <planetmaker> "andy draws new smoke sprites" ;-)
11:02:02  <planetmaker> sounds easy - for me ;-)
11:02:36  <Terkhen> :)
11:02:51  <Yexo> there are two solutions possible: 1. draw new smoke sprites and make sure they don't cross the tile boundaries 2. Split the existing smoke graphics in two parts and draw them on neighboring tiles
11:06:52  <Terkhen> 2 sounds better but complicated :P
11:06:57  <planetmaker> :-)
11:07:08  <planetmaker> 1 could actually also benefit OpenGFX
11:08:42  <Terkhen> I don't think this bug happens with default industries
11:10:10  <planetmaker> different topic, supplies: what about the idea that primary industries consume supplies monthly, according to their production level?
11:10:21  <planetmaker> thus a stockpile (but no stockpile limit)
11:10:49  <planetmaker> to avoid an overflow of the stockpile, I'd always consume max(half stockpile, production_level)
11:10:52  <Terkhen> I'm not sure
11:11:14  <planetmaker> it wouldn't change the supply effect, but make reaching higher output levels require more supply input
11:11:34  <Terkhen> you will need to convince andy first that supplies are right
11:11:44  <planetmaker> and decay of production_level only very slowly
11:11:48  <Terkhen> no supplies kill the set IMO
11:12:00  <planetmaker> yeah... I'm kinda shocked he even considers removing them
11:12:19  <Terkhen> he's been telling that for a while
11:12:24  <planetmaker> without it'd be yet another opengfx+industries
11:12:24  <Terkhen> s/telling/saying/
11:12:43  <planetmaker> yes, I know...
11:12:49  <planetmaker> it saddens me
11:31:54  *** Webster has joined #openttdcoop.devzone
11:32:01  <Rubidium> oh... when are you going to use a bouncer? :)
11:32:19  <Terkhen> I was saying that his change of opinion regarding supplies started with YACD, although I mentioned twice or so that YACD is unfinished and might change in the future
11:32:36  <Terkhen> maybe it is called bouncer because we bounce from connected to disconnected :P
11:33:45  <planetmaker> Terkhen, I keep telling, too, that yacd should not yet play a design role in FIRS...
11:33:50  <planetmaker> seems to be hard to comprehend
11:33:57  <Terkhen> yes, that's what I think too :P
11:34:24  <planetmaker> <planetmaker> it shows, though, that yacd needs a flag newgrfs can query
11:34:24  <planetmaker> <planetmaker> probably a cargo flag which is of the kind "don't use yacd for me" would do the trick - and the supply cargos would get it
11:34:24  <planetmaker> <planetmaker> then the economy could continue as is
11:34:24  <planetmaker> <planetmaker> alternatively it would need a less volatile and maybe slightly more volume distribution pattern so that one can supply an industry somewhat more consistently
11:34:25  <planetmaker> <planetmaker> supplies and yacd don't work well unless you have a near-finished network
11:34:27  <planetmaker> <planetmaker> When FIRS consolidates a bit... maybe we should have another joint game again?
11:34:29  <planetmaker> <planetmaker> But maybe end of August?
11:34:31  <planetmaker> <planetmaker> maybe also michi_cc updates yacd ;-) - though we possibly should play a normal game, for a
11:34:34  <planetmaker> ^^ did that get through?
11:35:28  <Terkhen> planetmaker: that's exactly the same I suggested
11:35:39  <Terkhen> and no, I did not read that
11:35:44  <planetmaker> ok and ok :-)
11:35:57  <planetmaker> I already wondered why I met utter silence ;-)
11:36:06  <Terkhen> :)
11:36:18  <Terkhen> a non YACD test game :P
11:36:26  <Terkhen> more boring but... :P
11:37:16  <planetmaker> :-)
11:37:30  <Brot6> FIRS Industry Replacement Set - Revision 2473:989ddb29faa0: Codechange: Rename all missing indust... (Terkhen) @
11:37:32  <Terkhen> ^ with that my todo list is cleared
11:37:53  <michi_cc> YACD behavior can change, if somebody demonstrates how supplies should behave with YACD.
11:38:32  <Terkhen> yes, but that does not mean that he should remove supplies
11:38:46  <Terkhen> there must be a nice way :)
11:41:11  <michi_cc> A lot can probably be changed by the existing config settings already, but to make that nice somebody™ should patch the set console command to work with list settings :)
11:42:14  <planetmaker> first we have to find out / define what we want supplies to do, I guess
11:42:31  <michi_cc> I do have an idea for nicer industry handling though that will result in smoother cargo amount changes.
11:43:09  <planetmaker> that might go already quite a way with supplies
11:44:06  <michi_cc> Still, andy/somebody else should describe the ideal YACD supply behaviour.
11:44:43  <planetmaker> I guess no one really knows :-)
11:45:42  <planetmaker> supplies are generally low-volume... having more than one destination would be somewhat a fundamental change
11:46:16  <Terkhen> the simplest alternative is "do nothing"; that way players still can decide which industries they want to supply
11:46:40  <planetmaker> yes, like current behaviour w/o yacd
11:49:41  <Terkhen> hmm... maybe choosing destinations but letting the player decide how much he wants to send to each industry
11:49:46  <Terkhen> I don't know, this is complex :)
11:50:16  <Terkhen> maybe NewGRF cargos should have a way to decide between different behaviours
11:50:29  <Terkhen> but then, we still have to think which ones make sense at all
11:50:38  <planetmaker> that's what I meant earlier with a cargo flag "yacd/non-yacd" behaviour
12:10:22  *** XeryusTC has quit IRC
12:10:58  *** XeryusTC has joined #openttdcoop.devzone
12:12:35  <planetmaker> michi_cc, what about a cargo property for yacd: "distribution_type: default / normal / yacd / yacd_as_industry_type"
12:13:10  <planetmaker> where default means use normal or yacd whatever the game setting is and yacd_as_industry_type means that cargo for example wants to got to _a_ arable farm, but not _this_
12:13:32  <planetmaker> probably a difficult concept, especially the last ;-)
12:14:07  <Yexo> I don't really get the last property
12:14:39  <Yexo> and what is the difference between "default" and "normal"?
12:14:54  <Hirundo> You mean, that the cargo doesn't have a specific destination industry but only a destination industry type?
12:14:55  <planetmaker> openttd must have a setting to use normal or yacd economy
12:15:00  <planetmaker> default = use what the user chose
12:15:13  <planetmaker> while normal = use what we have now, no matter what
12:15:37  <planetmaker> Hirundo, yes, I mean that
12:15:53  <planetmaker> where industry type could also be town, maybe specific town
12:15:57  <planetmaker> not sure
12:15:58  <Yexo> ok, so basically: users_choice / cargo_goes_anywhere / yacd / something_i_dont_understand
12:16:11  <planetmaker> yes :-P
12:16:19  <michi_cc> I'm not sure I would want my choice of destination overridden by a newgrf.
12:16:55  <Yexo> ^^ with michi
12:17:30  <planetmaker> you have the same for a lot of things...
12:17:50  <planetmaker> (which is no argument, I know)
12:17:55  <Yexo> also currently while in practice only industry newgrfs set cargo properties, cargo and industries are still separate features
12:18:20  <Yexo> your proposal would break that separation and bind them together even more tightly than they currently are
12:19:02  <michi_cc> One thing that would probably make sense is a property to specify the destination class, i.e. currently YACD distinguishes between normal, town and symmetric industry cargos for base number of links, link weight scale etc.
12:19:13  <planetmaker> Hm... could also be an industry property. Good point, yexo
12:19:43  <planetmaker> can you remind me, symmetric == ?
12:20:07  <planetmaker> like passengers, n go from A to B, thus n from B to A?
12:20:27  <michi_cc> Town for example (cargos with a town effect) has a higher base number of links than other industry cargo, which would probably also benefit supplies.
12:21:00  <michi_cc> Symmetric right now is everything with TE_PASSENGERS set, i.e. everything that returns from the destination to the source.
12:21:14  <planetmaker> ah... town effect means more recipients?
12:21:53  <planetmaker> hm... but that exactly is somewhat the issue with supplies... they're few and they're distributed wildly
12:23:16  <michi_cc> Well, it means take economy.cargodest.base_" target="_blank">economy.cargodest.base_ind_links[1] instead of economy.cargodest.base_" target="_blank">economy.cargodest.base_ind_links[0] for the base number of links. The current defaults have the former number higher than the latter number, because for example if food is required for town growth it has to be distributed to all towns and not just some.
12:23:26  <planetmaker> michi_cc, maybe a cargo (or industry?) property like number of destinations
12:23:46  <planetmaker> and possibly another of a type like "volatility of destinations"
12:30:27  <Brot6> FIRS Industry Replacement Set - Feature #1236: 1 tile buffer should be ignored when player / scen... (planetmaker) @
12:31:31  <Brot6> FIRS Industry Replacement Set - Feature #2296: Supplying Mechanism (planetmaker) @
12:55:22  *** Lakie has joined #openttdcoop.devzone
12:57:45  *** FooBar has joined #openttdcoop.devzone
13:07:03  <Brot6> repository /home/hg/dutchroadfurniture registered in Redmine with url /home/hg/dutchroadfurniture
13:07:03  <Brot6> repository /home/hg/dutchroadfurniture created
13:08:53  <Brot6> feed NewGRFs had 12 updates, showing the latest 10
13:08:53  <Brot6> Dutch Road Furniture - Revision 4:c36336135362: Feature: OpenTTD version check (foobar) @
13:08:53  <Brot6> Dutch Road Furniture - Revision 5:9bf81107629d: Feature: 4-way fingerposts (foobar) @
13:08:53  <Brot6> Dutch Road Furniture - Revision 6:1f4484defb7a: Feature: 1-way fingerposts (foobar) @
13:08:57  <Brot6> Dutch Road Furniture - Revision 7:ef7e243f4dfd: Feature: 2-way fingerposts (foobar) @
13:09:01  <Brot6> Dutch Road Furniture - Revision 8:f0e4d6d1f353: Doc: add documentation for release (foobar) @
13:09:02  <FooBar> heh :)
13:09:05  <Brot6> Dutch Road Furniture - Revision 9:19a1daf44d24: Change: enable DevZone nightly and release builds (foobar) @
13:09:09  <Brot6> Dutch Road Furniture - Revision 10:f23e5cad96aa: Change: add changelog.txt to .hgignore (foobar) @
13:09:13  <Brot6> Dutch Road Furniture - Revision 11:89bad89f39e2: Update: note that fingerposts are Dutch in objec... (foobar) @
13:09:14  *** andythenorth has joined #openttdcoop.devzone
13:09:17  <Brot6> Dutch Road Furniture - Revision 12:b1e59569f937: Release: 0.1.0 (foobar) @
13:09:20  <Brot6> FIRS Industry Replacement Set - Feature #2289 (Closed): String IDs could be refactored (planetmaker) @
13:10:27  <Terkhen> that's a fast release
13:10:57  <FooBar> yes it is :)
13:11:18  <FooBar> Started working on it only yesterday
13:11:46  <FooBar> Quite a small set right now, but worth a release (or a teaser if you like) I think
13:11:52  <andythenorth> yay
13:11:56  <andythenorth> another ticket closed
13:11:57  <planetmaker> "read furniture"?
13:12:09  <FooBar> where does it say that?
13:12:11  <Brot6> Dutch Road Furniture - Bug #2990 (New): DevZone compile failed (compiler) @
13:12:17  <FooBar> it should say "road"
13:12:30  <Ammler> maybe we should change default type to nml :-)
13:12:31  <planetmaker> I meant "road furniture"
13:12:46  <planetmaker> Ammler, good idea, I guess. Yes
13:13:03  <FooBar> hmm, what did I do wrong there :S
13:13:13  <FooBar> what NML is the devzone running?
13:13:22  <planetmaker> nightly
13:13:23  <FooBar> 1625 or older?
13:13:32  <Ammler> FooBar: you run nfo building
13:13:41  <Yexo> FooBar: see
13:13:45  <Yexo> r1624
13:13:54  <FooBar> ah, I need 1625 :P
13:14:14  <Ammler> hmm, didn't you?
13:14:43  <FooBar> I'll just wait for tonight then, no problem
13:15:28  <Ammler> hmm
13:15:40  <Ammler> the error is not clear
13:16:04  <FooBar> no, not quite
13:16:18  <Ammler> accoring to build log, it worked
13:16:19  <FooBar> I was expecting an "unknown property" or something
13:16:38  <Hirundo> FooBar: You noticed, that I slightly changed the naming of the prop/var?
13:16:54  <Ammler> just a bad exit from make
13:16:57  <FooBar> Hirundo: yes, that's alright. Thanks for the quick implementation!
13:17:29  <Hirundo> No, thank you for the patch :)
13:17:33  <FooBar> The names I chose weren't too brilliant, but they worked :)
13:17:47  <Hirundo> If every feature request would come with one, NML'd get to twice as fast
13:17:53  <planetmaker> :-D
13:17:53  <Ammler> is it possible to make such error more verbose?
13:18:38  <FooBar> heh, I have no clue about python or anything, but I figured "how hard can it be to add a property and variable" :)
13:19:27  <andythenorth> that's how python starts :P
13:21:23  <Brot6> Dutch Road Furniture - Bug #2990 (Rejected): DevZone compile failed (compiler) @
13:21:23  <Brot6> Dutch Road Furniture - Bug #2990 (Rejected): DevZone compile failed (foobar) @
13:23:03  <andythenorth> grr
13:23:10  <FooBar> oh, can anybody move the project to NewGRFs > Dutch?
13:23:11  <andythenorth> one day FIRS will get < 90 open tickets
13:23:37  <andythenorth> #2989
13:23:37  <Brot6> andythenorth: #2989 is "FIRS Industry Replacement Set - Bug #2989: Define all spritelayouts correctly - #openttdcoop Development Zone"
13:23:46  <andythenorth> ^ is this a problem?  Or just untidy?
13:25:03  <Terkhen> it's not a bug, just confusing code
13:25:20  <andythenorth> it could be amended
13:25:23  <FooBar> if the building is "hideable" through the transparency settings and then no ground tile is shown at all it is. Otherwise it's just untidy
13:25:38  <Terkhen> yes, it's just a note to not forget about it, but it is really low priority :)
13:25:46  <andythenorth> so not in 0.7?
13:26:10  <Terkhen> IMO not needed
13:26:40  <andythenorth> do we ship new translations along with 0.7?
13:26:48  <andythenorth> there are several waiting to be added
13:26:55  <andythenorth> #2455
13:26:55  <Brot6> andythenorth: #2455 is "FIRS Industry Replacement Set - Bug #2455: Updated Polish translation. - #openttdcoop Development Zone"
13:27:07  <andythenorth> #2744
13:27:07  <Brot6> andythenorth: #2744 is "FIRS Industry Replacement Set - Feature #2744: Esperanto translation - #openttdcoop Development Zone"
13:27:12  <andythenorth> #2736
13:27:12  <Brot6> andythenorth: #2736 is "FIRS Industry Replacement Set - Feature #2736: Hungarian Translation - #openttdcoop Development Zone"
13:27:20  <andythenorth> #2662
13:27:20  <Brot6> andythenorth: #2662 is "FIRS Industry Replacement Set - Bug #2662: German translation - #openttdcoop Development Zone"
13:27:28  <michi_cc> andythenorth: [13:43] <michi_cc> Still, andy/somebody else should describe the ideal YACD supply behaviour.
13:27:50  <andythenorth> michi_cc: that's a Hard Problem
13:28:58  <michi_cc> I'm perfectly willing to optimize YACD, but for that I need to know what to optimize for :)
13:29:11  <Ammler> FooBar: made you admin of Dutch
13:29:18  <andythenorth> michi_cc how do you handle food for towns in tropic?
13:29:28  <andythenorth> as FIRS supplies model same behaviour
13:29:58  <FooBar> Ammler: thanks. That might be useful in the future as well. Chances are I'll invent some other Dutch stuff in the future :)
13:30:15  <Terkhen> yes, all translations should be added
13:30:16  <michi_cc> By using a different set of constants/settings for cargoes with town effect, e.g. a higher number of base links.
13:30:16  <Ammler> thought so
13:30:23  <Terkhen> hmm...
13:30:42  <Terkhen> was the language script being run automatically or something like that before the nfo conversion?
13:31:00  <planetmaker> andythenorth, I doubt that the supplied translations are usable, if they build on the NFO code
13:31:06  <andythenorth> I wondered that
13:31:14  <andythenorth> can they be parsed and migrated?
13:31:16  <michi_cc> andythenorth: If you want to try the difference yourself, define supplies as having TE_WATER (that town effect is only used for subsidies and nothing else in plain OpenTTD).
13:31:24  <planetmaker> in other words: no, they aren't usable and I can't migrate it either.
13:31:31  <planetmaker> too much work for too little gain
13:31:36  <Ammler> FooBar: XeryusTC might also not mind, if you become manager in the station set too
13:31:48  <Terkhen> we should give a week at least for translators to finish them
13:31:54  <andythenorth> planetmaker: so they should be rejected?
13:32:05  <andythenorth> and told in the forums?
13:32:30  <planetmaker> I didn't actually look at any so far. But in the forums the current lang file might need to be attached and asked to translate that
13:32:42  <planetmaker> I'm just adding a few fund menu strings...
13:32:49  <FooBar> Ammler: I don't mind either :)
13:33:09  <Terkhen> what about the script? was it running automated or not?
13:33:17  <Terkhen> it is something I missed but the conversion should be easy
13:33:27  <andythenorth> michi_cc: it's hard because (1) should YACD have special cases for some cargos?
13:33:28  <planetmaker> <-- andythenorth that's how the players currently can place farms
13:33:36  <Ammler> Terkhen: I run your script with nighyl build
13:33:38  <andythenorth> (2) FIRS has to handle YACD and non-YACD cases
13:33:40  <planetmaker> it's not quite consistent, but doesn't matter really
13:33:53  <planetmaker> andythenorth, forget yacd when thinking FIRS
13:34:02  <Terkhen> Ammler: ok, so the name and parameters should be kept the same :)
13:34:07  <Terkhen> thanks, I'll get to it
13:34:12  <Ammler> Terkhen: not really
13:34:19  <andythenorth> planetmaker: or forget FIRS when thinking yacd?
13:34:22  <Ammler> needs to be added again anyway
13:34:27  <Ammler> hmm
13:34:29  <michi_cc> Just describe how you would like supplies to behave with YACD, then I can see how that could be achieved.
13:34:33  <Ammler> or not
13:34:42  <michi_cc> Regardless of any technical arguments.
13:35:14  <andythenorth> 'is problem' :)
13:35:24  <Ammler> 29
13:35:26  <andythenorth> desired behaviour of supplies is not known
13:35:26  <Ammler> for i in $(ls -1 sprites/nfo/lang/ | grep '.pnfo$' | grep -v '.new.' | grep -v 'cleanup' | grep -v 'nfo_lang' | grep -v 'untranslated' | grep -v 'remove'); do
13:35:27  <Ammler> 30
13:35:29  <Ammler>   ./scripts/ $i >$i.log
13:35:30  <Ammler> 31
13:35:32  <Ammler>   [[ $(cat $i.log | wc -l) -lt 4 ]] && rm $i.log
13:35:33  <Ammler> 32
13:35:35  <Ammler> done
13:35:36  <Ammler> that is useless
13:35:49  <planetmaker> I didn't yet update it, I guess
13:36:20  <Terkhen> Ammler: yes, as I said it needs conversion
13:36:26  <Terkhen> I was asking only about parameters / script name :)
13:36:39  <planetmaker> andythenorth, FIRS works quite well with yacd as is... the rough edges are not to be solved on FIRS side now
13:36:42  <michi_cc> Maybe asked differently: What do you dislike right now with YACD abd supplies.
13:36:51  <Ammler> would be nice if you get rid of ".sh" :-)
13:37:00  <Terkhen> hmm... ok, but why?
13:37:08  <Ammler> use shebang
13:37:13  <Ammler> and chmod +x
13:37:14  <andythenorth> michi_cc: multiple things
13:37:27  <andythenorth> 1. waste - FIRS only requires 1 unit delivered / month
13:37:37  <Terkhen> yes, I know what you mean, but it is the same IMO
13:37:46  <planetmaker> that's a FIRS issue which is general
13:37:52  <Terkhen> I don't mind the change, I'm curious about the reason :)
13:38:07  <planetmaker> not yacd specific. nor an argument against supplies really
13:38:08  <andythenorth> 2. supplies are a good case for 'local' distribution, i.e. nearest sources (forget reality, for gameplay shuttling supplies across the map sucks)
13:38:14  <Ammler> well, in that case, it is a bash script afaik, not a shell script, what ever that is
13:38:23  <planetmaker> ho.... it does?
13:38:27  <Ammler> and if you ever decide to change it to a python script
13:38:40  <Ammler> you do not need change the extension again
13:39:00  <Terkhen> ok, I see your point now :)
13:39:00  <andythenorth> michi_cc: I should possibly just play a yacd game and pm you my complaints as I go
13:39:01  <andythenorth> :P
13:39:18  <Ammler> I should not run .sh scripts directly
13:39:32  <Ammler> then it would be clear :-)
13:39:43  <michi_cc> 2 is something I can improve respectively where the currently available settings are enough to tinker.
13:39:48  <andythenorth> planetmaker: the waste of supplies in a YACD game is not the same issue as players wanting to deliver ten bazillion units to one industry
13:40:09  <andythenorth> there are only n units available on the map.  I want them spread to as many industries as possible
13:40:26  <planetmaker> ok. And where is that an argument in favour of local delivery?
13:40:31  <andythenorth> it's not
13:40:36  <andythenorth> they're separate arguments :
13:40:38  <andythenorth> :)
13:40:43  <andythenorth> that's why I numbered them :)
13:40:57  <Ammler> Terkhen: [15:40] <greybot> Don't use extensions for your scripts. Scripts define new commands that you can run, and commands are generally not given extensions. Also: bash scripts are *not* sh script (so don't use .sh) and the extension will only cause dependencies headaches if the script gets rewritten in another language.
13:41:14  <michi_cc> That would mean more demand links (like cargoes with town effect currently have).
13:41:28  <andythenorth> that's easy enough?
13:41:33  <planetmaker> andythenorth, 'local' delivery is IMHO a play-preference and not something which needs enforcement. Just do it, if you like
13:41:39  <Ammler> not just .sh,. al
13:41:45  <Ammler> also .py btw. :-)
13:41:46  <andythenorth> planetmaker: but it is enforced by yacd
13:42:01  <planetmaker> yes, so?
13:42:11  <andythenorth> it's not fun, for these cargos
13:42:11  <Ammler> there should be no .py with chmod +x
13:42:17  <michi_cc> You can try the town effect easily enough, just make the supplies have TE_WATER (only affects subsidies in plain OpenTTD)
13:42:38  <planetmaker> that might be a nice try :-)
13:42:47  * andythenorth ponders test game
13:43:16  <planetmaker> michi_cc, and town growth, not?
13:43:40  <michi_cc> No, TE_WATER specifically is only used to chose the destination of subsidies.
13:44:05  <planetmaker> hm... but deserts towns w/o water grow?
13:44:07  <michi_cc> Bah, sorry, disregard that :) It's TE_GOODS
13:44:14  <planetmaker> ah
13:44:15  <michi_cc> and not TE_WATER
13:44:22  <planetmaker> ok :-)
13:45:32  <Terkhen> planetmaker: <--- I'm planning to rename the lang files so you can search by name too using the script, what do you think?
13:45:38  <michi_cc> If a cargo has TE_GOODS, the game will try to find a town instead of an industry for the destination of a subsidy
13:45:46  <andythenorth> michi_cc: if I was smarter, I'd be able to explain the issues in terms of graph theory :P
13:46:23  <Yexo> planetmaker: that might require a special flag for nml in the makefile, it expects lang/english.lng as default file
13:46:31  <andythenorth> in theory, with yacd, supplies should work well with hubs + spokes
13:46:37  <planetmaker> Terkhen, let me commit my four fund industry strings first. But yes
13:46:46  <Yexo> and imo the number are not really useful, maybe remove them altogether from the filename?
13:46:54  <Terkhen> ok, tell me when that's done :)
13:46:58  <michi_cc> No idea what TTDPatch makes of TE_GOODS tough, with its heap of town growth settings :)
13:47:08  <andythenorth> stockpiling supplies at hubs + trickling them to destination industries 1 unit at a time should work, but kind of...doesn't
13:47:09  <planetmaker> and indeed... yexo has a point: do we need the numbers?
13:48:56  <michi_cc> My personal take on supplies: Industries should do some stockpiling and probably use more supplies with higher production, that unburdens the player from doing just-in-time logistics.
13:49:34  <andythenorth> JIT is fun :P
13:49:52  <andythenorth> inventory is waste :P
13:50:06  <michi_cc> Or maybe use more supplies if the stockpile is higher so the stockpile won't grow infinitely.
13:50:18  <andythenorth> eddi suggested maths for that
13:51:08  <planetmaker> michi_cc, I'm working on such change ;-)
13:51:35  <planetmaker> I'm thinking of using like max(half pile, production_level) or similar
13:52:04  <planetmaker> maybe only a few steps instead of production level... dunno yet :-)
13:52:14  <Ammler> Terkhen: maybe you can add something like the loop to the script?
13:52:23  <Terkhen> what loop?
13:52:23  <Ammler> check_lang all
13:52:31  <Ammler> like I pasted above
13:52:47  <Ammler> for i in $(ls -1 sprites/nfo/lang/ | grep '.pnfo$' | grep -v '.new.' | grep -v 'cleanup' | grep -v 'nfo_lang' | grep -v 'untranslated' | grep -v 'remove'); do
13:53:21  <Ammler> oh, and do not use ls
13:53:33  <Terkhen> hmm... it should be a different script IMO, if I call it locally I don't want to check all languages
13:53:35  <Ammler> use find instead or direct bash globs
13:53:37  <Terkhen> just mine :P
13:53:45  <Ammler> true
13:54:00  <Ammler> well, then it isn't needed
13:54:11  <Ammler> can be done again in the spec
13:54:19  <Brot6> openttd.grf water-features - Revision 41:71fa1beb6ec4: Change: reduce 'too green' arctic tile (andythenorth) @
13:54:25  <Terkhen> hmm... I could also put everything on a function and treat the "all" parameter specifically
13:54:42  <Ammler> whatever :-P
13:54:55  <Ammler> ah no
13:55:10  <Ammler> I need to pipe the output to different logfiles
13:55:16  <andythenorth> ah
13:55:24  <andythenorth> the suggested supplies behaviour from eddi
13:55:27  <Webster> Title: Transport Tycoon Forums View topic - FIRS Industry Replacement Set - Development & Translations (at
13:55:47  <planetmaker> yes. And V. And michi and me. It's all very similar actually
13:56:34  <andythenorth> "if the limit is exceeded, throw away the surplus [but pay the company for transporting]"
13:56:37  <andythenorth> is appealing
13:57:25  <planetmaker> I don't like eddi's idea to introduce a stockpile limit actually, but the rest is IMHO all fine
13:57:36  <Terkhen> I agree with planetmaker
13:58:14  <andythenorth> there was some technical reason a limit was required iirc
13:58:18  <andythenorth> anyway
13:58:22  <andythenorth> back to yacd...
13:58:26  <planetmaker> a 64k limit per month or so
13:58:27  <andythenorth> so allowing that FIRS design shouldn't account for yacd
13:58:48  <andythenorth> any set that wants to specify how much cargo is delivered to a destination will conflict with yacd
13:58:58  <andythenorth> it's an issue of proper domain
13:58:59  <Terkhen> the absolute limit is about 64k, yes
13:59:44  <andythenorth> probably newgrfs should not be trying to specify how much cargo is delivered to destination x
14:00:01  <michi_cc> Sets can't really do that right now either (with the exception of the stockpile limit).
14:00:08  <andythenorth> FIRS tries though
14:00:19  <andythenorth> as will town sets if towncontrol gets out of the design swamp
14:00:26  <andythenorth> these are problems
14:00:34  <andythenorth> FIRS is basically wrong to try and do it
14:01:11  <andythenorth> I invented the requirement because the default economy is weak and I also wanted to adjust game balance
14:01:39  <andythenorth> these are not valid goals imho
14:02:00  <andythenorth> influencing primary production *is* a valid goal
14:02:06  <planetmaker> Terkhen, language update pushed
14:02:31  <Terkhen> ok, thanks :)
14:02:33  <Brot6> FIRS Industry Replacement Set - Revision 2474:9cf93a0e999d: Feature #2742: Hint on possible locat... (planetmaker) @
14:02:43  * andythenorth ponders
14:03:15  <andythenorth> planetmaker: your idea is something like 'industry maintains a stockpile, while stockpile is > 0, chance of increase' ?
14:03:18  <planetmaker> but better keep english.lng - I don't want to need to adjust the build system now ;-)
14:03:28  <planetmaker> andythenorth, yes, sort of
14:03:40  <andythenorth> so we remove the need for delivery frequency
14:03:46  * andythenorth has truly evil idea
14:03:54  <planetmaker> or rather: stockpile < x1: decrease. x1 < stockpile < x2: maintain. stockpile > x2: increase
14:03:55  <Ammler> planetmaker: firs does have custom spec anyway
14:03:58  <planetmaker> all with chances
14:04:17  <planetmaker> andythenorth, yes, that'd be the result. One needs not deliver every month then
14:04:19  <andythenorth> I am happy to try new algorithms, but I think if analysed, it turns out nothing significant changed
14:04:24  <planetmaker> which is the only really tedious thing
14:04:31  <andythenorth> but you still have to specify a consumption rate
14:04:38  <andythenorth> so deliveries must still be on frequency x
14:04:45  <andythenorth> just more generous
14:04:57  <planetmaker> which would solve the problem
14:04:59  <andythenorth> same outcome could be achieved by setting delivery window to 90 days
14:05:10  <planetmaker> not exactly
14:05:18  <planetmaker> <planetmaker> or rather: stockpile < x1: decrease. x1 < stockpile < x2: maintain. stockpile > x2: increase
14:05:35  <andythenorth> hmm
14:05:43  <andythenorth> I think the maths comes out the same at the end
14:05:52  <andythenorth> my evil idea was to make the consumption a random amount :P
14:06:03  <andythenorth> non-deterministic will really screw with players :D
14:06:17  <planetmaker> well...
14:06:28  <planetmaker> 10% randomness could work
14:06:51  <Terkhen> english.lng must be called exactly like that or can I modify the name somehow?
14:06:59  <planetmaker> keep it
14:07:03  <andythenorth> random is probably too evil
14:07:15  <Terkhen> it will not be consistent with the others then
14:07:23  <planetmaker> well... do we need the numbers?
14:07:27  <planetmaker> just german.lng
14:07:29  <planetmaker> spanish.lng
14:07:32  <planetmaker> dutch.lng
14:07:33  <Terkhen> hmm... ok
14:07:34  <planetmaker> is quite fine IMHO
14:07:58  <planetmaker> openttd has also no numbers ;-)
14:08:11  <andythenorth> random is at least better conceptually
14:08:21  <andythenorth> as it means the newgrf isn't trying to specify delivered amount
14:08:48  <planetmaker> andythenorth, the "delivered amount" issue is already solved with a higher latency. and / or a stockpile
14:08:57  <andythenorth> not really
14:09:04  <andythenorth> we still have to specify a constant somewhere
14:09:21  <planetmaker> what's bad about that?
14:09:30  <andythenorth> I'm thinking it's incorrect
14:09:43  <andythenorth> it's not the job of industry newgrf to determine economy / routing
14:10:08  <andythenorth> there's too much weak thinking about proper concerns of newgrfs, which is why we have certain....problems :P
14:10:11  <planetmaker> being random is worse in that respect
14:10:14  <andythenorth> he
14:10:16  <andythenorth> yes
14:10:44  <planetmaker> the idea I (and obviously others) have is to use supplies more fine-grained to control industry growth
14:10:52  <andythenorth> and that's valid I think
14:10:53  <planetmaker> which imho can be a nice challenge in itself
14:10:56  <andythenorth> put every previous idea aside
14:11:07  <andythenorth> how could supplies be consumed without specifying any constants?
14:11:15  <andythenorth> (it's just a maths question)
14:11:42  <andythenorth> what about abandoning monthly prod. change in favour of the random prod. change cb?
14:11:43  <planetmaker> er... like every other industry... input triggers output. in a way
14:12:07  <planetmaker> either could be used. But the random one is seldom in comparison
14:12:13  <planetmaker> and not much gained
14:12:19  <andythenorth> does anybody understand random prod. change except mr. frog?
14:12:25  <planetmaker> it could possibly be used to decide upon growth / not growth
14:12:27  <andythenorth> (he'll turn up now, he always comes when called)
14:12:49  <planetmaker> currently the random prod. change CB is used to increase / decrease prod. level or close the industries
14:13:02  <andythenorth> not in FIRS
14:13:05  <planetmaker> and the monthly is used to check for prod. ratios
14:13:09  <planetmaker> oh, of course in FIRS
14:13:12  <andythenorth> ?
14:13:17  <planetmaker> we use both CBs...
14:13:22  <andythenorth> random prod. change was turned off iirc
14:13:23  <planetmaker> did I mix up usage now?
14:13:29  <planetmaker> nope, each industry used it
14:13:31  <andythenorth> although it's a lot of code, I might misremember
14:14:01  <planetmaker> it's used to actually close an industry
14:14:12  <andythenorth> for primary and secondary?
14:14:16  <andythenorth> ah
14:14:18  <planetmaker> same for both
14:14:20  <andythenorth> there might be a reason for that
14:14:33  <andythenorth> I think I gave up trying to handle industry closure on a monthly cb
14:14:33  <planetmaker> monthly changes prod. level
14:14:36  <andythenorth> yeah
14:14:39  <andythenorth> that's all good
14:14:46  <planetmaker> and cargo arrival triggers production
14:14:49  <andythenorth> yes
14:14:56  <andythenorth> all is well
14:15:11  <Brot6> FIRS Industry Replacement Set - Revision 2475:d0497efdb073: Codechange: Rename language files. (Terkhen) @
14:16:03  <planetmaker> I wonder... should we ship 0.7.0 actually now?
14:16:14  <planetmaker> It feels like the right time wrt code changes
14:16:43  <planetmaker> then we could subsequently work for 0.8.0 with real changes and features and stuff
14:17:15  <Yexo> planetmaker: but current code has already broken compatibility with 0.6
14:17:27  <planetmaker> probably
14:17:33  <Yexo> shipping now would mean a game-breaking update now, and than another game-breaking update as 0.8
14:17:39  <andythenorth> there's no gain by shipping 0.7 early
14:17:44  <andythenorth> except you guys get prizes :P
14:17:51  <planetmaker> don't we? :-(
14:18:13  <andythenorth> well it's nearly finished, and I have yet to write nml, so you have prizes from me
14:18:53  <andythenorth> what if each instance of an industry has a constant demand for supplies (persistent storage), but that is randomised when constructing?
14:18:59  <andythenorth> this is slightly evil
14:19:06  <andythenorth> and might just work
14:19:16  <andythenorth> and we can argue realism :P
14:19:20  <andythenorth> 'wasteful farmer'
14:19:22  <andythenorth> 'bad soil'
14:19:24  <planetmaker> that might actually not be evil
14:19:27  <andythenorth> 'hard geology'
14:19:33  <planetmaker> we just need to display it in the extra text
14:19:40  <andythenorth> I don't think it's cowardice to duck setting a constant in FIRS code
14:19:55  * andythenorth overcomes moment of doubt
14:20:04  <andythenorth> pikka would probably just set a constant and be damned
14:20:09  <andythenorth> but FIRS isn't PBI
14:20:26  <andythenorth> 'logging here is easy'
14:20:30  <andythenorth> 'this coal almost mines itself'
14:20:36  <Terkhen> IMO we could do a few things before 0.7
14:20:47  <andythenorth> there is quite a lot to do I think :)
14:20:48  <Terkhen> no need to hurry :)
14:21:04  <Terkhen> for example, asking for translations once we are sure that strings won't be changed until release and giving them a week :P
14:21:06  <andythenorth> there are 16 open tickets for starters
14:21:09  <andythenorth> and we haven't tested yet
14:21:18  <andythenorth>
14:23:26  <Brot6> FIRS Industry Replacement Set - Feature #2296: Supplying Mechanism (andythenorth) @
14:23:42  * andythenorth discounts neko's suggestion
14:23:55  <andythenorth> that can be filed in the bin under 'parameters solve everything fallacy'
14:24:30  <planetmaker> I'm not sure the production / supplying mechanism should be much parametrized. It's a bear trap even without
14:26:44  <andythenorth> indeed
14:27:06  <andythenorth> and the idea that a single parameter turns off a bunch of industries whilst also screwing with prices....
14:27:13  <andythenorth> nvm
14:27:36  * andythenorth wonders 
14:27:47  <andythenorth> should the consumption frequency also be randomised
14:27:53  * andythenorth needs pencil and paper
14:27:58  <Terkhen> <--- how does it look?
14:28:18  <andythenorth> is it more fun if there are some industries where you *can* deliver 1,000t of supplies by boat
14:28:22  <andythenorth> and they are happy with that
14:28:50  <andythenorth> the amount, frequency, chance of increase, and size of increase are all factors
14:28:54  <andythenorth> who likes maths? :o
14:29:42  <planetmaker> :-) I actually do...
14:30:21  * andythenorth disappears into philosophy about 'flatness' and 'variety' in game design
14:30:26  <andythenorth> I won't post that
14:31:06  <andythenorth> basically if all industries followed same deterministic rules, but varied the amounts in interesting ways...
14:31:12  <andythenorth> I think players would accept it
14:31:24  <planetmaker> I do agree
14:31:31  <andythenorth> varying the rules is annoying
14:31:35  <planetmaker> a per-industry randomness of their levels would go a long way
14:31:40  <andythenorth> varying the amounts creates interesting challenge
14:31:43  <planetmaker> yup
14:31:57  <andythenorth> and honestly, connecting up primary industries does get boring
14:32:04  <planetmaker> maybe we should start with randomized primary production levels on game start ;-)
14:32:06  <andythenorth> 'add road stop, build 3 mogs, route'...
14:32:21  <andythenorth> planetmaker: it should all come together - in 0.8
14:32:43  <planetmaker> possibly. But doing it all at once is not necessarily the best approach
14:32:50  <planetmaker> as it's several "construction sites"
14:32:54  <andythenorth> releasing it all at once is ok
14:32:57  <planetmaker> esp. primary, secondary and black hole
14:33:02  <planetmaker> releasing it all at once - yes
14:33:06  <planetmaker> designing - maybe not
14:33:08  <andythenorth> FIRS release cycle is slow now
14:33:11  <planetmaker> writing... not sure
14:33:49  <andythenorth> michi_cc: ^ ideas above still involve industry specifying some optimum rate at which it wants to receive cargo.  How would yacd support that?
14:34:24  <andythenorth> planetmaker: we can do it order, one part at a time, sure ;)
14:34:36  <planetmaker> uhm... IMHO it doesn't... it just means that production levels rise or fall according to input with *some* rules
14:34:56  <planetmaker> but yes, it'd mean that general levels might be different
14:34:58  <andythenorth> doesn't need support?  or doesn't specify a rate
14:34:59  <andythenorth> ?
14:35:47  <planetmaker> the production_level is a 7-bit value with default=16 on game start
14:36:18  <planetmaker> thus there's much potential for using this as proxy to production-dependent supply requirements
14:36:24  <planetmaker> or cargo requirements
14:36:43  <andythenorth> yes
14:36:59  <planetmaker> what it currently does for primary: maybe increase level, if supplies. maybe decrease, if no supplies
14:37:06  <planetmaker> close, if prod. level < 4
14:37:19  <planetmaker> and 60 months nothing happend
14:37:23  * andythenorth ponders
14:37:38  <andythenorth> industry could have a counter for when to attempt the next increase, range 1:12
14:37:42  <andythenorth> randomised on construction
14:37:57  <andythenorth> i.e. some industries try to increase every month, others are more lax
14:38:00  <planetmaker> that's equivalent basically to randomized decision on the time it is made
14:38:25  <planetmaker> hm... maybe
14:38:38  <andythenorth> supplies could stockpile until such time as used
14:38:41  <planetmaker> I like the different supply levels with wastful farmer and efficient farmer better :-)
14:38:57  <andythenorth> I think frequency needs looking at
14:38:58  <planetmaker> they also make for nice and funny extra industry strings ;-)
14:39:01  <andythenorth> it seems to bother players a lot
14:39:24  <planetmaker> frequency of prod. decrease and increase?
14:39:31  <andythenorth> yes, i.e. monthly
14:39:44  <andythenorth> + that being tied to supply delivery within the month
14:40:05  <planetmaker> the tie to "within month of delivery" is gone with a stockpile
14:40:16  <planetmaker> And that's really the main issue. A month is early on very short
14:40:21  <planetmaker> esp. for very low input of supplies
14:40:23  <andythenorth> the one thing I'm 90% sure of: whenever the 'prod increase' chance calculation runs, it should clear 100% of any stockpile
14:40:38  <andythenorth> I can't explain why, but otherwise it's a headache
14:40:39  <Brot6> FIRS Industry Replacement Set - Revision 2476:44b93eb0465a: Feature: Update the language script t... (Terkhen) @
14:40:42  <Terkhen> Ammler: ^
14:41:34  <andythenorth> we should build a simulator online :P
14:41:42  <andythenorth> or a spreadsheet
14:41:55  <planetmaker> ah, that you mean...
14:42:21  <planetmaker> Not sure it should eat all stockpile. As it'd mean there's nothing left to support the future prod. level
14:42:35  <planetmaker> but increasing the prod. level could meant to "eat" a certain amount additionally
14:42:57  <planetmaker> but in my idea a higher level anyway means to demand more supplies monthly
14:42:59  *** ladyg has joined #openttdcoop.devzone
14:44:10  * andythenorth has brainache
14:44:33  <planetmaker> hm, btw, Yexo: I got a pm from zero.Eight. He's got a hg repo of ogfx+airports working and kinda implicitly asks for commit access so that he can update graphics and also asks where / how to continue. Should I give him access?
14:44:46  <andythenorth> what if nothing changed from current, except length of delivery window was randomised
14:44:46  <andythenorth> ?
14:45:00  *** ladyg has quit IRC
14:45:17  <planetmaker> stockpiling the supplies makes some things in the prod. callback easier...
14:45:19  <Yexo> planetmaker: zero.Eight is the one providing all the snow-graphics, right?
14:45:22  <planetmaker> yes
14:45:28  <Yexo> I have no problem with that
14:45:43  <Yexo> let's make him developer, we can always revoke that if there are any problems
14:45:50  <planetmaker> ok
14:46:01  <planetmaker> I'll copy the answer via forum mail to you
14:46:16  <Yexo> ok
14:50:29  <andythenorth> the rate of consumption of stockpile is randomised?  And delivery window no longer applies...
14:50:59  <planetmaker> could in principle be done. That's what I meant earlier with "could be randomized on a 10% level".
14:51:08  <planetmaker> Doing it completely random would be a royal pain
14:51:58  <andythenorth> each industry instance would have a random multiplier tied to the current production multiplier, I considered
14:52:15  <andythenorth> so stockpile consumption is prod. multiplier * random * some constant
14:53:30  <planetmaker> prod_multiplier * (constant * 1 + random(0...1)/10 - random(0...1)/5)
14:53:56  <planetmaker> or alike
14:53:57  <andythenorth> so if prod_multiplier is much is consumed?
14:54:13  <planetmaker> 16 +- 2
14:54:17  <andythenorth> so 14?
14:54:21  <andythenorth> or 18?
14:54:23  <andythenorth> etc
14:54:26  <planetmaker> yup
14:54:48  <andythenorth> so what's the optimum gameplay strategy?
14:55:03  <planetmaker> be generous ;-)
14:55:36  <andythenorth> so deliver 2,000t once every 10 years
14:55:45  <andythenorth> assuming you have 2,000t
14:56:02  <andythenorth> (this is a sub-optimal strategy, but many won't see why)
14:56:23  <andythenorth> it's optimal for any given industry, it's seriously sub-optimal for the map as a whole
14:56:45  <andythenorth> and the chance of increase should be?
14:57:21  <andythenorth> constant, or a factor of the stockpile | consumption rate
14:57:34  <andythenorth> factor / product /s
14:58:17  <planetmaker> I think we there's two issues which can be considered independent
14:58:31  <planetmaker> a) how supplies are consumed
14:58:38  <planetmaker> b) how supplies trigger growth
14:58:45  <planetmaker> c) where to add randomness
14:59:06  <andythenorth> agreed
14:59:36  <planetmaker> c) IMHO can be split off. It can (will!) be the salt in the soup but is not crucial for anything
14:59:52  <andythenorth> that leaves a & b...
14:59:52  <planetmaker> c) should not change the principle IMHO, thouhg
15:00:28  <planetmaker> wrt a): ~ production_level
15:01:45  <planetmaker> most likely to kill too big stock piles rather something like consume: max(prod_level, stockpile*10/prod_level)
15:01:47  <planetmaker> or similar
15:02:44  <planetmaker> wrt b) consider increase when there's a remaining stockpile. Possibly have a min. waiting time between increases
15:03:08  <andythenorth> and the chance of increase is increased by...?
15:03:22  <andythenorth> or do we discount that requirement
15:03:23  <andythenorth> ?
15:03:34  <andythenorth> i.e. players think delivering more == more production out
15:03:41  <andythenorth> somewhat like a secondary industry
15:03:51  <andythenorth> I discounted it every other time
15:03:57  <planetmaker> maybe only consider increase when there's enough stockpile to feed it at least n months or so
15:04:39  <planetmaker> I'd keep the random increase chance. Maybe make it slightly more likely if there's really abundant supplies
15:04:53  <planetmaker> but not sure that's a good approach. Just keeping that decision as now maybe
15:05:00  <planetmaker> pure random
15:05:05  <andythenorth> so chance of increase is constant?
15:05:15  <planetmaker> IFF there's a sufficient stockpile
15:05:30  <andythenorth> 'sufficient' is determined by...?
15:05:40  <planetmaker> production level
15:05:52  <andythenorth> so stockpile / prod. level > n
15:05:54  <planetmaker> monthly supply usage at its current level
15:05:59  <andythenorth> k
15:06:00  <planetmaker> something like that, yes
15:06:01  <andythenorth> what's n?
15:06:08  <planetmaker> 3?
15:06:10  <andythenorth> n is a parameter?
15:06:12  <planetmaker> no
15:06:17  <planetmaker> well. not for the player
15:06:19  <andythenorth> why not?
15:06:20  <planetmaker> for us: maybe
15:06:37  <andythenorth> it's requested by players, why are they wrong in this case?
15:06:46  <andythenorth> as opposed to wrong in the general case :P
15:07:33  <planetmaker> I've never seen anyone request a parameter to adjust the production increase chance
15:07:53  <andythenorth> they ask for delivery window adjustment which is ~= same thing
15:08:02  <andythenorth> maybe not
15:08:09  <planetmaker> nope. Completely different.
15:08:14  <planetmaker> imho
15:08:32  <planetmaker> they are just bothered that they don't manage to trigger the increase chance due to the 1-month window
15:08:37  <andythenorth> what does industry window text say?
15:08:44  <planetmaker> which needs micromanagement currently
15:08:54  <andythenorth> "Maintain stockpile above xxxxt for chance of production increase' ?
15:09:11  <planetmaker> text... production may increase, if sufficient supplies for n months are available
15:09:19  <andythenorth> ok
15:09:30  <andythenorth> so basically same as ECS?
15:09:35  <planetmaker> :-D
15:09:46  <planetmaker> maybe
15:09:56  <andythenorth> it is pretty much identical in one factor
15:10:08  <andythenorth> it doesn't account for transported amounts or such though
15:10:30  <andythenorth> it means FIRS should abandon attempts to change gamplay balance
15:10:42  <andythenorth> but that's probably an invalid idea anyway
15:10:43  <planetmaker> is this game play?
15:10:54  <planetmaker> in a way, certainly...
15:11:03  <planetmaker> but just another default industry set is boring
15:11:12  <andythenorth> it returns the emphasis to 'largest fastest vehicle wins'
15:11:22  <andythenorth> and removes requirement to build roads
15:11:36  <planetmaker> the simplest solution to the 1month problem currently is a stockpile and production-level-dependent consumption
15:11:37  <andythenorth> but an industry set shouldn't be trying to impose that anyway
15:11:54  <planetmaker> the 1 month is the really troublesome issue
15:12:02  <planetmaker> it's boring micromangement
15:12:18  <andythenorth> I don't think it is the issue
15:12:26  <andythenorth> there are probably multiple issues
15:12:35  <planetmaker> that's the only thing I consider an issue at all
15:12:45  <andythenorth> he
15:12:47  <planetmaker> timing vehicle deliveries is not possible really well
15:13:12  <planetmaker> thus... allow to deliver continuously and be more relaxed about timing when good care is taken
15:13:21  <planetmaker> just build a shed to store stuff ;-)
15:13:28  <planetmaker> hm.... :-)
15:13:33  <planetmaker> Idea for graphics!
15:13:44  <planetmaker> full barn. Empty barn
15:13:52  <Terkhen> micromanagement is boring, yes
15:14:15  <andythenorth> I have plenty of feedback about problem (b) above as well
15:14:25  <andythenorth> more supplies == higher chance of increase for many people
15:14:44  <Terkhen> that makes sense but up to a limit IMO; if you deliver more supplies than needed -> no increase
15:14:50  <planetmaker> yep
15:15:29  <planetmaker> thus it might even be an approach to just add a few increase probabilities... depending on supplies in stock.
15:15:58  <planetmaker> But that's not the real issue. It's just that people don't *know* how it works. While the one month thing is nothing they can do about with the best of knowledge
15:16:22  <andythenorth> in which case, why not just make it 90 days?
15:16:29  <andythenorth> or 365 days?
15:16:46  <Terkhen> deliver a single unit once :P
15:16:46  <planetmaker> there's no 90day callback or 365 day callback. That's why
15:16:46  <andythenorth> simpler to code, same result
15:16:52  <andythenorth> ach, that's trivial
15:16:53  <planetmaker> And that's where stockpiling comes into play
15:17:08  <planetmaker> it's not trivial. I tried that...
15:17:16  <andythenorth> there's no cb to handle combinatory secondary prod. either
15:17:20  <andythenorth> it's just a counter with a limit
15:18:32  <andythenorth> run it on the 'cargo recieved cb'
15:18:37  <andythenorth> or some other cb
15:18:48  <andythenorth> reset to 0 when cargo delivered
15:18:53  <andythenorth> allow to increment otherwise
15:19:00  <andythenorth> set a limit at 30 or 60 or 90 or whatever
15:19:22  <andythenorth> check the value is < limit when running prod. increase
15:21:43  <andythenorth> :)
15:21:50  <planetmaker> that is easy. But you loose the info of how many supplies are delivered in that period
15:21:57  <andythenorth> that might not matter...
15:22:24  <planetmaker> but kills any chance to use that as incentive for whatever.
15:22:57  <planetmaker> Thus IMHO the more interesting approach is to make use of a supply pile
15:23:33  <planetmaker> though... could be used concurrently
15:23:41  <planetmaker> last delivery < n day + supply pile
15:23:44  <planetmaker> both can be available
15:23:51  <planetmaker> both actually ARE available
15:24:04  <planetmaker> #define var_date_received_supplies 10 // date the last time supplies were delivered
15:24:23  <planetmaker> or actually for secondaries it's the last cargo delivery
15:24:34  <planetmaker> of cargo1
15:24:51  <planetmaker> sprites/nml/defines.pnml
15:25:40  <planetmaker> for primary ones we *could* even implement a pseudo-stockpile in the pers. storage.
15:25:44  <planetmaker> There's enough space...
15:29:39  <andythenorth> pseudo is maybe better
15:29:42  * andythenorth gtg
15:29:44  <andythenorth> biab
15:29:55  *** andythenorth has quit IRC
15:29:55  *** gggirl has joined #openttdcoop.devzone
15:31:47  *** gggirl has quit IRC
15:59:53  <Brot6> OpenGFX+ Road Vehicles - Bug #2134: very small 2cc patch in toyland climate (Terkhen) @
16:03:03  <Terkhen> oooh
16:03:15  <Terkhen> let's see if I understood this correctly
16:03:34  <Terkhen> if I use the vehicle callback cargo_capacity, it will take care of both capacity callbacks by itself?
16:08:57  <planetmaker> that's how it looks like, yes
16:09:09  <planetmaker> sounds convenient :-)
16:09:36  <planetmaker> sounds very much like ogfx+trains needs a *thorough* update anyway with all these new callback formats :-)
16:24:39  <Terkhen> I'm doing it now for ogfx-rv
16:31:30  <Terkhen> yes, it takes care of both :)
16:31:31  <Terkhen> awesome
16:32:13  <Terkhen> <--- and that's just for one truck model
16:35:36  <Terkhen> planetmaker: what about making use of cargo_age_period for refrigerated trucks? :)
16:38:46  <planetmaker> hm... sounds like a good idea :-)
16:38:59  <planetmaker> guard it by version check, though
16:39:56  <planetmaker> though the question is a bit: how utilize it?
16:40:06  <planetmaker> just make it age slower?
16:40:28  <planetmaker> it'd need balancing against some penalty IMHO
16:40:38  <planetmaker> dunno which :-)
16:41:08  <Terkhen> <--- feel free to join the discussion :)
16:41:20  <Brot6> OpenGFX+ Road Vehicles - Feature #2991 (New): Use cargo_age_period with refrigerated trucks (Terkhen) @
16:45:30  <Brot6> OpenGFX+ Road Vehicles - Revision 108:820b93ed67a1: Codechange: Update all callbacks to the new c... (Terkhen) @
16:47:36  *** Zuu has joined #openttdcoop.devzone
16:47:54  *** andythenorth has joined #openttdcoop.devzone
16:47:56  <Ammler> does cargo age in station?
16:48:07  <Ammler> (transfer)
16:48:10  *** Zuu has quit IRC
16:48:59  <Terkhen> probably
16:49:33  <planetmaker> answered :)
16:49:50  <Terkhen> planetmaker: <--- can you do the same here? :P
16:49:52  <Brot6> OpenGFX+ Road Vehicles - Feature #2991: Use cargo_age_period with refrigerated trucks (planetmaker) @
16:49:52  <Brot6> OpenGFX+ Road Vehicles - Bug #2684: Lumber in bulk and in flatbed (Terkhen) @
16:50:01  <Terkhen> I'm not sure of what should be done for that issue
16:50:28  *** Zuu has joined #openttdcoop.devzone
16:50:35  <planetmaker> hm... :-)
16:51:10  <planetmaker> more lumber in bulk than flatbed imho sounds a bit wrong
16:51:19  <planetmaker> lumber should be a prime cargo for flatbed
16:52:02  <Terkhen> yes, I agree
16:52:11  <Terkhen> I think that the flatbed should carry more, not equal
16:52:18  <planetmaker> rather, yes
16:52:25  <planetmaker> now it's vice versa with rv?
16:52:38  <Terkhen> yes
16:53:29  <Brot6> OpenGFX+ Road Vehicles - Feature #2991: Use cargo_age_period with refrigerated trucks (Terkhen) @
16:54:00  <planetmaker> WDPR is the label, right?
16:54:24  <Terkhen> yes
16:54:54  <planetmaker> default seems 30 for both train wagons.
16:54:59  <planetmaker> what about 25 and 30?
16:55:06  <planetmaker> or even 20 and 30?
16:55:27  <planetmaker> similar ratio for rv
16:55:49  <Terkhen> ok :)
16:56:00  <planetmaker> which one? :-P
16:56:05  * andythenorth considers cargo aging
16:56:09  <andythenorth> this is...interestink
16:56:35  <Terkhen> hmm...
16:56:38  <andythenorth> poses a FISH design challenge
16:56:43  <planetmaker> 20/30 I think.
16:56:48  <planetmaker> wood chips are light-weight ;-)
16:57:05  <andythenorth> that was a pointless CHIPS highlight :P
16:57:05  <Terkhen> for trucks: the maximum capacity for all cargos on the flatbed truck is equal to the minimum for the bulk truck :)
16:57:14  <planetmaker> :-D
16:57:36  <Terkhen> but yes, wood chips are light and take up much space in bulk
16:57:50  <planetmaker> what are RV capacities?
16:58:17  <andythenorth> this game would be better if wood chips were left out of it :P
16:58:21  <Terkhen>
16:58:25  <andythenorth> they're irritating
16:58:27  <Terkhen> left out of what?
16:58:33  <Terkhen> the bulk trucks?
16:58:34  <andythenorth> everything
16:58:47  <andythenorth> :P
16:58:53  <andythenorth> it's a long debate with MB I've had
16:59:35  <Terkhen> planetmaker: I'm thinking about 15 for the bulk truck (absolute minimum) and 18 for the flatbed (absolute maximum)
17:00:04  <Terkhen> andythenorth: that reminds me I found a fun post for you, let me get the link
17:00:28  <planetmaker> Terkhen: works for me. That's 25/30 for me then
17:02:10  <Terkhen> planetmaker: ok :)
17:02:50  <planetmaker> I'll commit it to trains right away... or I might forget :-)
17:03:05  <Brot6> OpenGFX+ Trains - Revision 249:4b71a24a55c9: Change: Decrease the capacity of the bulk wagon for ... (planetmaker) @
17:04:28  <Terkhen> ok, I'll do it now too :)
17:04:31  <Terkhen> andythenorth:
17:04:32  <Webster> Title: Transport Tycoon Forums View topic - ..,,;;:: Spain set ::;;,,.. 90% taster 1.24 available (at
17:04:48  <Terkhen> quite old post but... :P
17:07:30  <Brot6> OpenGFX+ Road Vehicles - Revision 109:def1d37a7152: Change #2684: Correct lumber capacity for the... (Terkhen) @
17:07:36  <planetmaker> :-)
17:08:40  <andythenorth> Terkhen: the answer appears to be "The Spanish set will be a complete, self-contained set! "
17:08:54  <andythenorth> which I think is the right attitude
17:08:55  <andythenorth> more of that please
17:09:03  <andythenorth> less of this interoperability crap
17:09:16  <Terkhen> somehow it ended up being a half baked train set, 6 years after that comment
17:11:01  <andythenorth> conceptually, 'one set to rule them all' is correct
17:11:07  <andythenorth> unfortunately, shipping code wins
17:11:16  <Brot6> nml: update from r1624 to r1625 done -
17:11:22  <andythenorth> and no-one has shipped a 'one set to rule them all'
17:11:32  <planetmaker> canset will :-P
17:11:43  <andythenorth> not if OzTrans loses the will to live first
17:11:55  <Terkhen> what keeps me from disabling all canset road vehicles and enabling opengfx+ ones? :P
17:12:11  <andythenorth> he'll disable his grfs in that case
17:12:16  <Terkhen> remove as in disable_item
17:12:32  <Terkhen> doesn't he need specific grfid for that?
17:12:44  <andythenorth> he'll disable if he finds anything that *isn't* a specific ID?
17:12:46  <Yexo> yes, and he won't provide updates for the grf anyway so he won't update canset for it :)
17:13:00  <Brot6> ogfx-rv: update from r107 to r109 done -
17:13:05  <andythenorth> but at least he won't have to decide what to do about supplies :P
17:14:03  <Terkhen> that's what I thought :)
17:14:20  <Terkhen> the only way to do a single-set NewGRF is to do something so crazy that nobody else would support it
17:14:40  <andythenorth> I think pikka is doing that
17:14:54  <Terkhen> that lunar thing?
17:15:05  <Terkhen> I'd love to see it actually
17:16:51  * andythenorth considers
17:16:57  <andythenorth> here's an idea
17:17:30  <planetmaker> the lunar thing will be supported by vactrains ;-)
17:17:32  <planetmaker> I'm sure
17:17:33  <andythenorth> industries use a pseudo stockpile of supplies
17:17:43  <andythenorth> *not* the ottd provided stockpile
17:18:03  <Terkhen> <--- what's the improvement? I can't see any difference between original opengfx sprites (the ones that ogfx-rv is currently using) and the new ones
17:18:18  <andythenorth> it's better referred to not as 'stockpile' but 'work to increase production'
17:18:31  <Terkhen> andythenorth: that sounds interesting :P
17:18:42  <andythenorth> when an industry receives supplies, it will try to increase production for next 90 days
17:18:49  <andythenorth> at whatever rate
17:18:57  <andythenorth> assume management just say 'three month project'
17:19:06  <andythenorth> and they'll use 1 digger, or 10 diggers, but for three months
17:19:11  <andythenorth> according to what is available
17:19:20  <Brot6> ogfx-trains: update from r248 to r249 done -
17:19:35  <planetmaker> Is there one or two pixels changed on the flatbed of the truck?
17:19:42  <andythenorth> the supplies are all 'put to use' as soon as delivered
17:19:55  <andythenorth> i.e. 100% consumption when cargo arrives
17:20:10  <andythenorth> so now you need to deliver every 90 days or so
17:20:26  <andythenorth> and you get three chances for an increase during that time
17:20:30  <Terkhen> planetmaker: I can't see them :)
17:20:43  <andythenorth> now for the interesting additions
17:20:46  <planetmaker> Nor I actually...
17:20:51  <Brot6> firs: update from r2460 to r2476 done -
17:20:58  <Terkhen> maybe... they are some shadows of brown that I can't distinguish myself
17:21:00  <andythenorth> we could provide a parameter to control the period - 30 days, 90 days, 240 days....
17:21:10  <Terkhen> but if you don't see them either I'm not going to bother with changing sprites
17:21:14  <planetmaker> :-)
17:21:46  <andythenorth> *or* we could allow that delivering more supplies in the 90 day period increases the chance
17:22:02  <andythenorth> any of you played one of those games where you use air or water to keep a ball in the air?
17:22:04  <Terkhen> both options make sense, I prefer the second one
17:22:22  <Brot6> dutchroadfurniture: update from  to r12 done -
17:22:48  <Brot6> OpenGFX+ Road Vehicles - Bug #2684 (Closed): Lumber in bulk and in flatbed (Terkhen) @
17:22:51  <andythenorth> chance of increase could reduce according to time since last delivery
17:22:55  <andythenorth> or according to amount
17:23:01  <Brot6> Following repos didn't need a nightlies update: narvs (ERROR r38), bros (r52), ogfx-industries (r122), opengfx (r727), ailib-tile (r16), foobarstramtracks (r23), transrapidtrackset (r28), 2cctrainset (r750), cets (r126), ailib-list (r32), opensfx (r97), ttdviewer (r34), worldairlinersset (r672), heqs (r638), openmsx (r97), basecosts (r25), nutracks (r208), nml (r1625), 32bpp-extra (r40), manindu (r7), newgrf_makefile (r305),
17:23:01  <Brot6> ailib-direction (r17), ailib-common (r21), snowlinemod (r49), dutchtramset (r87), ai-admiralai (r75), swisstowns (r22), metrotrackset (r56), spanishtowns (r10), frenchtowns (r6), grfpack (r279), ogfx-rv (r109), fish (r684), ogfx-landscape (r78), ttrs (r36), ogfx-trees (r51), swedishrails (r205), grfcodec (r833), ai-aroai (r39), german-townnames (r34), smts (r19), chips (r143), belarusiantowns (r8), indonesiantowns (r41), ailib-string
17:23:03  <Brot6> (r29), airportsplus (r107), comic-houses (r71)
17:23:13  <planetmaker> both could work concurrently
17:23:23  <Terkhen> it could have a % of increase counter
17:23:25  <Brot6> OpenGFX+ Road Vehicles - Feature #2982 (Rejected): Improved sprites for flatbed trucks (Terkhen) @
17:23:39  <Terkhen> first step requires a given amount of supplies, second a bigger amount and so on
17:23:40  <Brot6> narvs: compile of r38 still failed (#2983) -
17:23:44  <Terkhen> and the base amount depends on current max production
17:23:53  <andythenorth> probably
17:24:12  <andythenorth> "deliver n crates supplies every 90 days"
17:24:26  <andythenorth> n varies by prod_multiplier + * random_factor * constant
17:25:34  <andythenorth> now I just have to decide between:
17:25:36  <andythenorth> -increase more likely if frequent delivery
17:25:41  <planetmaker> sounds good
17:25:41  <andythenorth> -increase more likely if larger delivery
17:25:52  <planetmaker> sounds also good
17:26:07  <andythenorth> there might be someone way to merge both
17:26:10  <andythenorth> I need to figure the maths
17:26:35  <andythenorth> something like
17:26:50  <andythenorth> industry •needs* 30t delivered every 90 days
17:27:03  <andythenorth> but if you deliver 90t, chance of increase is higher
17:27:21  <andythenorth> so there's some factor for chance of increase
17:27:28  <andythenorth> like 30t: 1 in 5
17:27:32  <andythenorth> 60t: 1 in 4
17:27:39  <andythenorth> 90t: 1 in 3
17:27:44  <Terkhen> also, if the current max production is high enough, the first levels are negative; you need to keep a steady supply to keep high production levels
17:27:45  <Terkhen> :P
17:27:52  <andythenorth> yes probably
17:28:03  <andythenorth> there's some integer that handles chance of increase
17:28:11  <andythenorth> and that integer decreases over time unless supplied
17:28:22  <andythenorth> but it will take 3 months to decrease from limit to 0
17:28:28  <andythenorth> after that it goes negative
17:28:38  <andythenorth> so delivering supplies keeps the integer high
17:29:18  <andythenorth> and it's all tied to the prod. multiplier
17:29:36  <andythenorth> so compared to current scheme:
17:29:46  <andythenorth> - it eases the frequency required
17:29:56  <andythenorth> - it eases the chance of higher increase for more cargo
17:30:18  <andythenorth> - it adds difficulty by tying requirement to prod. multiplier
17:30:34  <andythenorth> - it continues to reward delivering smaller amounts every month
17:31:03  <andythenorth> - but allows delivering large amount less frequently
17:31:08  <andythenorth> I just need to work out the maths :P
17:32:42  <planetmaker> hm. so prod. increase chance ~ pile % prod_level
17:33:01  <planetmaker> "consumption" ~ pile % prod_level
17:33:14  <andythenorth> hm
17:33:16  <andythenorth> umm
17:33:19  <andythenorth> my maths is not good :)
17:33:29  <planetmaker> hm.. there's no negative offset :-)
17:33:48  <andythenorth> that would be floored at 0 anyway if the 'no decrease' parameter was set
17:34:10  <andythenorth> the 'production increase chance' is governed by something similar to prod. multiplier
17:34:24  <andythenorth> i.e. an int that increases or decreases according to some conditions
17:34:40  <planetmaker> hm...
17:34:45  * planetmaker gets pencil and paper
17:34:47  <andythenorth> I can write pseudo code
17:34:47  <FooBar> hmmm, how can I get the devzone to rebuild my release?
17:38:53  * andythenorth boggles brain
17:39:08  <planetmaker> we have: time since last delivery; piled supplies; prod. level; prod. change chance
17:39:14  <Terkhen> urgh, I should do something with ogfx-rv compilation times
17:39:22  <andythenorth> my scheme is slightly flawed currently
17:39:26  <andythenorth> I can fix it :P
17:40:11  <Terkhen> :)
17:41:38  <Brot6> OpenGFX+ Road Vehicles - Feature #2991: Use cargo_age_period with refrigerated trucks (Terkhen) @
17:41:45  <Terkhen> ^ it includes an example patch
17:41:47  <Terkhen> bbl
17:41:59  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: ogfx-industries (Diffsize: 747), foobarstramtracks, cets (436 warnings) (Diffsize: 462), manindu (Diffsize: 2), newgrf_makefile, dutchtramset, swisstowns, spanishtowns (Diffsize: 2), frenchtowns, ogfx-landscape (1 warnings), swedishrails, german-townnames (Diffsize: 1), belarusiantowns (Diffsize: 30), indonesiantowns (1 warnings) (Diffsize: 1),
17:41:59  <Brot6> airportsplus (2 warnings) (Diffsize: 45288)
17:43:07  <Ammler> FooBar: you need to retag
17:43:15  <Ammler> you can use the same tag :-)
17:43:23  <FooBar> ok, will do
17:43:27  <FooBar> thanks
17:43:34  <Ammler> or push something else
17:43:57  <Ammler> hmm, no tag needs new hash
17:44:26  <Ammler> but tag name can be same
17:44:29  <FooBar> Well, I can tag the revision that made the old tag I presume
17:44:34  <Ammler> yes
17:45:26  <Ammler> maybe nml devs will invent minnmlc, then you could use that
17:45:26  <Yexo> why not simply trigger a rebuild for the old tag?
17:45:49  <Ammler> Yexo: that needs to be done from an admin
17:46:02  <andythenorth> planetmaker:
17:46:03  *** frosch123 has joined #openttdcoop.devzone
17:46:03  <Ammler> ./scheduler -f -releases <repo>
17:46:15  <FooBar> you're an adming ;)
17:46:18  <FooBar> admin
17:46:41  <Ammler> hmm, I wonder if -e would work too
17:46:55  <Yexo> <Ammler> ./scheduler -f -releases <repo> <- it's that line that I keep forgetting ;)
17:47:43  <FooBar> if you replace <repo> with dutchroadfurniture you can try it out :P
17:48:00  <Ammler> yexo, I run it already
17:48:13  <Ammler> -e does not work
17:49:13  <andythenorth> hmm
17:49:23  <andythenorth> I can simplify that code in 1 line
17:49:27  <andythenorth> I distrust the constant :P
17:49:29  <andythenorth> also
17:49:29  <Ammler> I guess, I could script -e for releases too
17:49:45  <Brot6> dutchroadfurniture: update from  to 0.1.0 done -
17:50:08  <FooBar> thanks!
17:50:14  <andythenorth> I think this scheme would have to have some limits
17:50:15  <Ammler> Yexo: I have also added -h to the script :-P
17:50:31  <andythenorth> e.g. prod increase chance is in range (1 in 2) - (1 in 5) or such
17:50:43  <Ammler> or
17:50:44  <andythenorth> and if too much supplies are delivered they are just lost
17:51:13  <andythenorth> so if industry is working at '5x normal rate to increase production', and it's baseline requirement is 30t
17:51:19  <andythenorth> then delivering >150t is pointless
17:51:45  <andythenorth> although if you wish to waste supplies you can :P
17:52:46  <andythenorth> I think this works
17:53:19  <andythenorth> see, all that engineering argument wasn't wasted :P :)
17:53:45  <andythenorth> hmm
17:53:56  <andythenorth> if industry can go at up to 5x normal rate to increase production...
17:54:08  <andythenorth> and that level decreases by 1 for each month without supplies...
17:54:14  <andythenorth> then that's 5 months between deliveries
17:54:34  <andythenorth> maybe 'up to 3x' is enough
17:57:54  <Brot6> FIRS Industry Replacement Set - Feature #2296: Supplying Mechanism (andythenorth) @
17:58:18  <Terkhen> :)
17:58:38  <Brot6> FIRS Industry Replacement Set - Feature #2296: Supplying Mechanism (andythenorth) @
18:00:20  <andythenorth> there is still a flaw in my maths somewhere
18:00:26  <Brot6> FIRS Industry Replacement Set - Feature #2296: Supplying Mechanism (andythenorth) @
18:02:41  <andythenorth> solved I think
18:03:06  <Brot6> FIRS Industry Replacement Set - Feature #2296: Supplying Mechanism (andythenorth) @
18:04:00  <andythenorth> who wants to code it? :P
18:04:22  <planetmaker> I can do that and I'm willing to do that.
18:04:31  <planetmaker> But I probably won't have time before next week
18:04:57  <andythenorth> it's basically all the other ideas from v, eddi, planetmaker, with some edges knocked off
18:05:03  <andythenorth> and the hiding of the stockpile from the pile
18:05:20  <andythenorth> replaced by 'working at 2x rate to improve production' or similar
18:05:20  <planetmaker> yes, I see that, it's good, I think
18:05:28  <andythenorth> yay
18:05:33  <andythenorth> worth the pain
18:05:49  <Terkhen> for now I say post it at the thread and let people comment it
18:05:56  <Terkhen> I think it's good :)
18:05:58  <andythenorth> unlikely they'll understand it :P
18:06:10  <Terkhen> true
18:06:18  <Terkhen> just give eddi the link then :)
18:06:22  <andythenorth> there's enough feedback here to know if it sucks or not
18:06:24  <andythenorth> good point
18:09:33  <Brot6> FIRS Industry Replacement Set - Feature #2296: Supplying Mechanism (andythenorth) @
18:21:31  <andythenorth> hmm
18:21:31  <andythenorth> a
18:21:44  <andythenorth> also this method allows for some interesting stuff wrt economies
18:24:19  <Hirundo> "On monthly prod. cb." <- CB 35 ?
18:24:41  <Terkhen> andythenorth: for example?
18:24:55  <planetmaker> yes, Hirundo
18:25:39  <planetmaker> Terkhen: it could allow to adjust these parameters for different industry types accordingly
18:25:50  <Terkhen> oh, cool :)
18:25:54  <planetmaker> Like mining being easier to support than farming or vice versa
18:29:19  <andythenorth> so yes, in an economy, it could be easier or harder to grow mines etc
18:29:24  <andythenorth> or farms / whatever
18:35:43  <Brot6> OpenGFX+ Airports - Revision 108:fce7fb43741d: Feature: New graphics for modern hangar (dnicholls) @
18:41:26  <Brot6> OpenGFX+ Airports - Bug #2759 (Closed): add snowy version of 'modern' depot (dnicholls) @
18:43:09  <planetmaker> \o/
18:57:45  <frosch123> what? dalestan wants to work on ttdp again :o
18:58:35  <planetmaker> does he?
19:00:33  <planetmaker> I don't read that from his comment on the 7E procedures.
19:01:21  <frosch123> "(...) but the patch looks fine to me. I'll try to shove it in sometime this weekend."
19:01:54  <planetmaker> oh :-)
19:02:48  *** FooBar has quit IRC
19:03:51  <Brot6> clientpatches: compile of r22759 still failed (#2964) -
19:05:42  *** FooBar has joined #openttdcoop.devzone
19:08:28  <Hirundo> an actual reply from dalestan... awesome :o
19:09:14  <Brot6> openttd-vehiclevars: update from r22758 to r22759 done -
19:11:05  <Brot6> serverpatches: compile of r22759 still failed (#2966) -
19:11:28  <Ammler> orudge: could you please make pm moderator of graphics
19:11:42  <Ammler> it is so annoying...
19:12:18  <Ammler> or whoever likes to be, but there is so much a lack of moderation there
19:12:40  <Brot6> 32bpp-ez-patches: compile of r22759 still failed (#2446) -
19:13:17  <Ammler> (stupid user question in releases)
19:16:47  <planetmaker> FooBar: with the road "furniture": what about making some road tiles which actually feature these / similar objects?
19:16:56  <planetmaker> they could become part of ogfx+landscape
19:17:14  <FooBar> hmmm...
19:17:31  <FooBar> do we have roadtypes yet?
19:17:41  <frosch123> FooBar: is the road furniture actually dutch specific?
19:17:42  <planetmaker> no. it'd have to fit ground tiles
19:17:54  <planetmaker> but opengfx roads are known
19:18:07  <FooBar> but wouldn't you end up with unusable roads then?
19:18:10  <planetmaker> thus every t-shaed corner would have the same thing
19:18:14  <frosch123> i wondered why you want to force it into a separate menu with a specific dutch object label, instead of using the generic road stuff label
19:18:15  <planetmaker> but unusable?
19:18:20  <FooBar> I agree it would look better /on/ the road tile
19:18:36  <planetmaker> would it hurt if each curve had a curve sign?
19:18:42  <FooBar> frosch123: yes, these are specifically Dutch. I intend to add more dutch stuff later
19:18:50  <FooBar> hence the separate class
19:19:08  <FooBar> of course you can also use them if you just like them :P
19:19:35  <frosch123> ok :)
19:19:41  <planetmaker> if I may criticise the graphics slightly: the way sign poles seem to hover somehow.
19:20:01  <planetmaker> not sure it can be improved or how, though
19:20:02  <FooBar> planetmaker: curve signs (like: wouldn't hurt I guess
19:20:13  <planetmaker> that's what I thought, yes
19:20:26  <planetmaker> or low-level way signs on t-junctions
19:20:31  <planetmaker> not the high ones
19:21:25  <FooBar> yes, that's also possible; it "just" needs drawing :P
19:22:14  <FooBar> Might look good actually. I'll look into drawing something when I find time somewhere in the future
19:23:27  <FooBar> the hovering can probably be fixed by adding some dirt or something around the pole
19:26:53  *** JVassie has joined #openttdcoop.devzone
19:33:55  *** FooBar has quit IRC
19:35:21  *** FooBar has joined #openttdcoop.devzone
20:37:40  <Brot6> openttd.grf water-features - Revision 42:af3b1a6b216e: Change: work in progress on arctic river s... (andythenorth) @
20:38:08  <andythenorth> I thought I had solved all palette problems years ago :|
20:41:10  <andythenorth> hey ho
20:41:59  <Brot6> openttd.grf water-features - Revision 43:5db9689e36a3: Fix: palette issued resolved for arctic sn... (andythenorth) @
20:51:35  <andythenorth> good night
20:51:36  *** andythenorth has quit IRC
21:06:39  *** andythenorth has joined #openttdcoop.devzone
21:07:46  <andythenorth> michi_cc: so if an industry had a specific (monthly) required amount for a cargo, could it provide that to YACD (as the result of a new cb)?
21:09:05  <michi_cc> That would require YACD to have demand coordination between supplying industries first though :)
21:12:48  <michi_cc> Industry demand behavior will change for the next version to give serviced demand links a gradually increasing weight (up to some limit). A required cargo amount could be used in assigning the initial link weight.
21:14:08  <andythenorth> hmm
21:14:20  <andythenorth> I need to understand links and such a little more
21:14:23  <andythenorth> that can wait :)
21:16:57  *** FooBar has quit IRC
21:17:30  <michi_cc> Cargo is allocated to the demand links (== what you see in the industry/town window) by randomly choosing a number 0..<sum of link weights>. This means that the theoretical cargo amount for each link is total_cargo*link_weight/weight_sum.
21:19:20  <andythenorth> ok thanks
21:19:23  * andythenorth -> bed
21:19:28  <andythenorth> :)
21:19:33  *** andythenorth has quit IRC
21:20:37  *** frosch123 has quit IRC
21:23:52  *** Sylf has quit IRC
21:30:58  *** JVassie has quit IRC
21:41:43  *** Sylf has joined #openttdcoop.devzone
21:56:10  *** JVassie has joined #openttdcoop.devzone
22:00:54  *** LordAro has quit IRC
22:08:15  *** Lakie has quit IRC
23:13:37  *** JVassie has quit IRC
23:43:28  *** Zuu has quit IRC

Powered by YARRSTE version: svn-trunk