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) @ http://dev.openttdcoop.org/issues/2986#change-7498 07:05:02 <Brot6> DictatorAI - Revision 149:7e23b0243112: - Now connect the station directly when building the IN p... (krinn) @ http://dev.openttdcoop.org/projects/ai-dictator/repository/revisions/7e23b0243112 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) @ http://dev.openttdcoop.org/issues/2989 09:26:31 <Brot6> FIRS Industry Replacement Set - Bug #2989: Define all spritelayouts correctly (planetmaker) @ http://dev.openttdcoop.org/issues/2989#change-7499 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) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/dd6fa9b7885c 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) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/7dea52ba415a 10:18:45 <Brot6> FIRS Industry Replacement Set - Revision 2471:77628e3c4682: Codechange: Sugar Refinery uses advan... (Terkhen) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/77628e3c4682 10:21:03 <Terkhen> http://paste.openttdcoop.org/show/482/ <--- 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: http://paste.openttdcoop.org/show/483/ 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) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/647bd3ca6ea4 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> http://hg.openttdcoop.org/nml/raw-file/tip/docs/industries.html#industrytiles-callbacks <-- 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> http://paste.openttdcoop.org/show/484/ <--- 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> http://bugs.openttd.org/task/4736 <-- 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) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/989ddb29faa0 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) @ http://dev.openttdcoop.org/issues/1236#change-7500 12:31:31 <Brot6> FIRS Industry Replacement Set - Feature #2296: Supplying Mechanism (planetmaker) @ http://dev.openttdcoop.org/issues/2296#change-7501 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) @ http://dev.openttdcoop.org/projects/dutchroadfurniture/repository/revisions/c36336135362 13:08:53 <Brot6> Dutch Road Furniture - Revision 5:9bf81107629d: Feature: 4-way fingerposts (foobar) @ http://dev.openttdcoop.org/projects/dutchroadfurniture/repository/revisions/9bf81107629d 13:08:53 <Brot6> Dutch Road Furniture - Revision 6:1f4484defb7a: Feature: 1-way fingerposts (foobar) @ http://dev.openttdcoop.org/projects/dutchroadfurniture/repository/revisions/1f4484defb7a 13:08:57 <Brot6> Dutch Road Furniture - Revision 7:ef7e243f4dfd: Feature: 2-way fingerposts (foobar) @ http://dev.openttdcoop.org/projects/dutchroadfurniture/repository/revisions/ef7e243f4dfd 13:09:01 <Brot6> Dutch Road Furniture - Revision 8:f0e4d6d1f353: Doc: add documentation for release (foobar) @ http://dev.openttdcoop.org/projects/dutchroadfurniture/repository/revisions/f0e4d6d1f353 13:09:02 <FooBar> heh :) 13:09:05 <Brot6> Dutch Road Furniture - Revision 9:19a1daf44d24: Change: enable DevZone nightly and release builds (foobar) @ http://dev.openttdcoop.org/projects/dutchroadfurniture/repository/revisions/19a1daf44d24 13:09:09 <Brot6> Dutch Road Furniture - Revision 10:f23e5cad96aa: Change: add changelog.txt to .hgignore (foobar) @ http://dev.openttdcoop.org/projects/dutchroadfurniture/repository/revisions/f23e5cad96aa 13:09:13 <Brot6> Dutch Road Furniture - Revision 11:89bad89f39e2: Update: note that fingerposts are Dutch in objec... (foobar) @ http://dev.openttdcoop.org/projects/dutchroadfurniture/repository/revisions/89bad89f39e2 13:09:14 *** andythenorth has joined #openttdcoop.devzone 13:09:17 <Brot6> Dutch Road Furniture - Revision 12:b1e59569f937: Release: 0.1.0 (foobar) @ http://dev.openttdcoop.org/projects/dutchroadfurniture/repository/revisions/b1e59569f937 13:09:20 <Brot6> FIRS Industry Replacement Set - Feature #2289 (Closed): String IDs could be refactored (planetmaker) @ http://dev.openttdcoop.org/issues/2289#change-7502 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) @ http://dev.openttdcoop.org/issues/2990 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 http://bundles.openttdcoop.org/dutchroadfurniture/releases/ERROR/0.1.0/PACKAGES 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) @ http://dev.openttdcoop.org/issues/2990 13:21:23 <Brot6> Dutch Road Furniture - Bug #2990 (Rejected): DevZone compile failed (foobar) @ http://dev.openttdcoop.org/issues/2990#change-7503 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 http://dev.openttdcoop.org/issues/show/2989 "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 http://dev.openttdcoop.org/issues/show/2455 "FIRS Industry Replacement Set - Bug #2455: Updated Polish translation. - #openttdcoop Development Zone" 13:27:07 <andythenorth> #2744 13:27:07 <Brot6> andythenorth: #2744 is http://dev.openttdcoop.org/issues/show/2744 "FIRS Industry Replacement Set - Feature #2744: Esperanto translation - #openttdcoop Development Zone" 13:27:12 <andythenorth> #2736 13:27:12 <Brot6> andythenorth: #2736 is http://dev.openttdcoop.org/issues/show/2736 "FIRS Industry Replacement Set - Feature #2736: Hungarian Translation - #openttdcoop Development Zone" 13:27:20 <andythenorth> #2662 13:27:20 <Brot6> andythenorth: #2662 is http://dev.openttdcoop.org/issues/show/2662 "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> http://paste.openttdcoop.org/show/485/ <-- 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/check_language.sh $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: http://paste.openttdcoop.org/show/486/ <--- 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) @ http://dev.openttdcoop.org/projects/water-features/repository/revisions/71fa1beb6ec4 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 http://www.tt-forums.net/viewtopic.php?p=954566#p954566 13:55:27 <Webster> Title: Transport Tycoon Forums View topic - FIRS Industry Replacement Set - Development & Translations (at www.tt-forums.net) 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) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/9cf93a0e999d 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) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/d0497efdb073 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> http://dev.openttdcoop.org/projects/firs/issues?fixed_version_id=145&set_filter=1&status_id=o 14:23:26 <Brot6> FIRS Industry Replacement Set - Feature #2296: Supplying Mechanism (andythenorth) @ http://dev.openttdcoop.org/issues/2296#change-7509 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> http://devs.openttd.org/~terkhen/patches/index.php?source=firs/language_script.diff <--- 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) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/44b93eb0465a 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 16....how 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) @ http://dev.openttdcoop.org/issues/2134#change-7510 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> http://devs.openttd.org/~terkhen/patches/index.php?source=example.diff <--- 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> http://dev.openttdcoop.org/issues/2991 <--- feel free to join the discussion :) 16:41:20 <Brot6> OpenGFX+ Road Vehicles - Feature #2991 (New): Use cargo_age_period with refrigerated trucks (Terkhen) @ http://dev.openttdcoop.org/issues/2991 16:45:30 <Brot6> OpenGFX+ Road Vehicles - Revision 108:820b93ed67a1: Codechange: Update all callbacks to the new c... (Terkhen) @ http://dev.openttdcoop.org/projects/ogfx-rv/repository/revisions/820b93ed67a1 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: http://dev.openttdcoop.org/issues/2684 <--- can you do the same here? :P 16:49:52 <Brot6> OpenGFX+ Road Vehicles - Feature #2991: Use cargo_age_period with refrigerated trucks (planetmaker) @ http://dev.openttdcoop.org/issues/2991#change-7511 16:49:52 <Brot6> OpenGFX+ Road Vehicles - Bug #2684: Lumber in bulk and in flatbed (Terkhen) @ http://dev.openttdcoop.org/issues/2684#change-7512 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) @ http://dev.openttdcoop.org/issues/2991#change-7513 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> http://paste.openttdcoop.org/show/488/ 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) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/4b71a24a55c9 17:04:28 <Terkhen> ok, I'll do it now too :) 17:04:31 <Terkhen> andythenorth: http://www.tt-forums.net/viewtopic.php?p=353188#p353188 17:04:32 <Webster> Title: Transport Tycoon Forums View topic - ..,,;;:: Spain set ::;;,,.. 90% taster 1.24 available (at www.tt-forums.net) 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) @ http://dev.openttdcoop.org/projects/ogfx-rv/repository/revisions/def1d37a7152 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 - http://bundles.openttdcoop.org/nml/nightlies/r1625 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 - http://bundles.openttdcoop.org/ogfx-rv/nightlies/r109 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> http://dev.openttdcoop.org/projects/opengfx/repository/revisions/ee8790e26acd <--- 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 - http://bundles.openttdcoop.org/ogfx-trains/nightlies/r249 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 - http://bundles.openttdcoop.org/firs/nightlies/r2476 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 - http://bundles.openttdcoop.org/dutchroadfurniture/nightlies/r12 17:22:48 <Brot6> OpenGFX+ Road Vehicles - Bug #2684 (Closed): Lumber in bulk and in flatbed (Terkhen) @ http://dev.openttdcoop.org/issues/2684#change-7516 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) @ http://dev.openttdcoop.org/issues/2982#change-7517 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) - http://bundles.openttdcoop.org/narvs/nightlies/ERROR/r38 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) @ http://dev.openttdcoop.org/issues/2991#change-7518 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: http://paste.openttdcoop.org/show/489/ 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 - http://bundles.openttdcoop.org/dutchroadfurniture/releases/0.1.0 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 http://dev.openttdcoop.org/projects/home/wiki/ManagingCF 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) @ http://dev.openttdcoop.org/issues/2296#change-7519 17:58:18 <Terkhen> :) 17:58:38 <Brot6> FIRS Industry Replacement Set - Feature #2296: Supplying Mechanism (andythenorth) @ http://dev.openttdcoop.org/issues/2296#change-7519 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) @ http://dev.openttdcoop.org/issues/2296#change-7519 18:02:41 <andythenorth> solved I think 18:03:06 <Brot6> FIRS Industry Replacement Set - Feature #2296: Supplying Mechanism (andythenorth) @ http://dev.openttdcoop.org/issues/2296#change-7519 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) @ http://dev.openttdcoop.org/issues/2296#change-7519 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) @ http://dev.openttdcoop.org/projects/airportsplus/repository/revisions/fce7fb43741d 18:41:26 <Brot6> OpenGFX+ Airports - Bug #2759 (Closed): add snowy version of 'modern' depot (dnicholls) @ http://dev.openttdcoop.org/issues/2759#change-7520 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) - http://bundles.openttdcoop.org/clientpatches/testing/ERROR/r22759 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 - http://bundles.openttdcoop.org/openttd-vehiclevars/testing/r22759 19:11:05 <Brot6> serverpatches: compile of r22759 still failed (#2966) - http://bundles.openttdcoop.org/serverpatches/testing/ERROR/r22759 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) - http://bundles.openttdcoop.org/32bpp-ez-patches/testing/ERROR/r22759 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: http://www.hansvanbaren.nl/Bochtschild1.jpg) 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) @ http://dev.openttdcoop.org/projects/water-features/repository/revisions/af3b1a6b216e 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) @ http://dev.openttdcoop.org/projects/water-features/repository/revisions/5db9689e36a3 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