Times are UTC Toggle Colours
00:02:08 *** Zuu has quit IRC 06:25:26 <Brot6> FIRS Industry Replacement Set - Bug #2901 (New): Sugar refinery can have oil refinery disaster (andythenorth) @ http://dev.openttdcoop.org/issues/2901 06:39:55 <Brot6> FIRS Industry Replacement Set - Revision 2199:3d5b2860e388: Codechange: Give better names to the ... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/3d5b2860e388 07:11:58 <Brot6> FIRS Industry Replacement Set - Revision 2200:65ef1b08bb14: Codechange: Re-align strings in langu... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/65ef1b08bb14 07:24:35 <Terkhen> Hirundo: http://devs.openttd.org/~terkhen/patches/index.php?source=builtin_coord.diff <--- this should be ready now 07:33:30 <Brot6> FIRS Industry Replacement Set - Revision 2201:bdf6d5cfc2b9: Codechange: Use production template f... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/bdf6d5cfc2b9 07:35:06 <planetmaker> Terkhen: I'd say again 'nice'. But as yesterday, Hirundo or Yexo have a better insight into the NML depths 07:35:18 <Terkhen> ok, thanks :) 07:36:08 <Terkhen> http://paste.openttdcoop.org/show/386/ <--- this is an example of how it improves readability of the code 07:36:42 <Terkhen> I'll just apply it to all industries now 07:39:30 <planetmaker> :-) 07:39:57 <Brot6> FIRS Industry Replacement Set - Code Review #2902 (New): Check production template for sugar refi... (planetmaker) @ http://dev.openttdcoop.org/issues/2902 07:56:56 <Brot6> FIRS Industry Replacement Set - Revision 2202:2aa3a7ed2777: Codechange: Use the same template nam... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/2aa3a7ed2777 08:18:12 <Terkhen> there are a lot of industries with duplicated sprites/spritelayouts/etc than I expected 08:18:25 <Terkhen> I'll create a list while I'm correcting the relative_pos stuff 08:31:09 <planetmaker> Terkhen: that's then the snow / no-snow issue, I guess? 08:31:36 <Terkhen> probably, because the forest has even more duplications :P 08:31:37 <Terkhen> 5 or so 08:31:42 <planetmaker> they've probably been using a template but no snowy sprites yet available? 08:31:52 <planetmaker> yes, forest has about 5 layouts? 08:32:18 <planetmaker> forest should definitely use the adv. parametrized thing; iirc it uses slopes in a lengthy manner 08:33:02 <Terkhen> at first glance they only differ on the ground sprite 08:33:16 <Terkhen> so yes, a condition there 08:33:35 <planetmaker> yes, ground sprite. which is a different slope, I guess 08:33:48 <planetmaker> well, you'll figure it :-) 08:34:51 <Terkhen> at least I found the smallest industry with duplicate code... I'll use the food market and later fix the others in the same way 08:34:57 <Terkhen> but for now, relative positions :) 08:35:14 <planetmaker> :-) 08:41:33 <Terkhen> http://devs.openttd.org/~terkhen/patches/index.php?source=forest.diff <--- I found some switches that always return the same value on the forest... is this cleanup ok? 08:42:04 <planetmaker> uhm... rather not - if it's in the production code 08:42:17 <Terkhen> it's only layout code 08:42:34 <Terkhen> hmm... but yes, being part of a template might explain those 08:42:37 <planetmaker> but it is not... Dunno. Is there a pattern of the same type for other industries? 08:43:08 <Terkhen> I'll leave the switches then, but I'll simplify the value and default -> same action into default only 08:43:33 <planetmaker> nah, simplify it as you can. 08:43:42 <planetmaker> But I wonder whether it's a thing which can be templated :-) 08:44:12 <Terkhen> probably not... the relative_pos switches are dependent on the industry layout itself 08:44:14 <planetmaker> or rather: should be templated. As it looks... not 08:44:18 <planetmaker> yeah 08:44:47 <Terkhen> ok, I'll test that I did not break forests and commit this cleanup :) 08:45:13 <planetmaker> :-) 08:50:23 <planetmaker> hm... debug text handling seems to be part of the production templates in NFO 08:52:45 <Brot6> FIRS Industry Replacement Set - Revision 2203:cc69a4fcac3e: Cleanup: Remove "empty" switches from... (Terkhen) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/cc69a4fcac3e 08:54:33 <Terkhen> I never understood that part of FIRS :P 08:55:46 <planetmaker> I still don't :-P 08:56:04 <planetmaker> I only got pieced out the rough structure there 08:56:52 <planetmaker> btw, if you touch files... could you add the GPL header? Like in the primary production template or the primary industries I touched? 08:57:09 <planetmaker> Not that important, but I think it'd be nice :-) 09:02:26 <Terkhen> ok :) 09:03:00 *** Zuu has joined #openttdcoop.devzone 09:28:02 <planetmaker> hm... does NML know modulo? 09:39:20 <Hirundo> it should 09:51:04 <planetmaker> yes, according to the source it's % 09:51:22 <planetmaker> I'm trying to write the production magic from scratch ;-) 09:51:30 <planetmaker> and I don't want to waste fractional deliveries 09:54:11 <Terkhen> :P 09:55:03 <planetmaker> well, it currently doesn't either - and doing so was (rightfully) considered a bug. So I'll have to consider that :-) 10:09:56 <Hirundo> Terkhen: relative_coord is added, thanks for the patch 10:10:19 <Brot6> NewGRF Meta Language - Revision 1558:42342543d7be: Add: Builtin function relative_coord(x,y) (Ter... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/42342543d7be 10:10:19 <Brot6> NewGRF Meta Language - Revision 1559:35764c039fe2: Fix: Some small fixes to the documentation. (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/35764c039fe2 10:11:02 <Terkhen> great, thank you :) 10:43:03 <planetmaker> how many temporary storage does an industry have? 10:53:36 <Hirundo> an industry does not have its own temporary storage 10:54:14 <Hirundo> there are 16 persistent registers per industry, and 256 temporary ones that are valid only during a single callback 10:54:37 <planetmaker> ok, that's enough. As a callback is only used by one industry at a time 10:54:53 <planetmaker> and no other thing uses the (same) temporary storage at that time, right? 10:55:19 <Hirundo> no, there is always only one callback running at a time 10:55:39 <Hirundo> openttd is not multi-threaded :) 10:56:16 <planetmaker> yes, that's what I meant :-) 10:56:30 <planetmaker> during one callback I can assume all those 256 temp storages to be 'mine' 10:56:45 <Terkhen> yes, IIRC it's mentioned on the specs 10:56:55 <planetmaker> :-D 10:57:32 <Terkhen> http://newgrf-specs.tt-wiki.net/wiki/Storages <--- actually it is not mentioned explicitly, I'll add a note 10:57:33 <Webster> Title: Storages - GRFSpecs (at newgrf-specs.tt-wiki.net) 10:59:32 * planetmaker has the feeling the newgrf specs are much faster improved now we have the new wiki :-) 11:03:20 <Terkhen> I'm suscribed to the rss feed of updates, I can guarantee you they have been improved a lot :P 11:07:01 <planetmaker> :-P 11:07:25 <planetmaker> I don't use the rss feed. But 'all recent changes' is usually a long list ;-) 11:08:29 <Ammler> shall brot announce the changes here? 11:08:29 * planetmaker wonders whether I just should cut out the old production code and plug in my new one... 11:08:41 <planetmaker> it *should* be the same... 11:08:43 <planetmaker> Ammler: no 11:09:03 <planetmaker> I don't think that's needed :-) 11:09:13 <Terkhen> no, there are enough changes already :P 11:09:27 <Terkhen> maybe you should create #openttdcoop.notice 11:10:07 <planetmaker> nah, I don't think that's needed 11:10:56 <planetmaker> But maybe we should consider to have the devzone not announce successful re-compiles. Only new compiles (successful and failures) and failures to recompile 11:12:03 <Hirundo> IMO it's fine as-is 11:16:02 <Ammler> does someone of you watch #openttd.notice? 11:16:11 <Ammler> it is quite useless channel, imo 11:17:11 <Ammler> it does not make sense to have irc channel just for announcing, the idea is to be able to discuss the announcements 11:17:42 * planetmaker doesn't use it 11:18:03 <Ammler> if you want announcing only, you could use the rss feeds 11:18:56 <Terkhen> I follow openttd.notice, it gives far more info 11:19:06 <Terkhen> and then only the most important things go to openttd 11:19:37 <Terkhen> also, announcements would not spam existing discussions :P 11:20:10 <Ammler> well, that is how irc works 11:23:40 <Ammler> planetmaker: the compile announcements are once a day, you really think, that should be filtered? 11:24:22 <Ammler> also thought about but then it isn't something regulary 11:25:55 <planetmaker> http://devs.openttd.org/~planetmaker/patches/produce_secondary.pnml <-- my current production code template for secondary industries 11:26:00 <planetmaker> is it somewhat understandable? 11:26:31 <planetmaker> hm... the input to the produce call might be wrong 11:26:49 <Brot6> DevZone Help Center - Membership #2897 (Closed): Applying for project: Japanese town names & US M... (Sylf) @ http://dev.openttdcoop.org/issues/2897 11:26:49 <Brot6> DevZone Help Center - Membership #2897 (Closed): Applying for project: Japanese town names & US M... (Ammler) @ http://dev.openttdcoop.org/issues/2897#change-7170 11:27:02 <Ammler> http://dev.openttdcoop.org/projects/home/issues <-- we have some open tickets here, 11:30:53 <planetmaker> updated file 11:31:33 <Brot6> DevZone Help Center - Bug #2813 (Feedback): grep error log before creating a ticket (Ammler) @ http://dev.openttdcoop.org/issues/2813#change-7171 11:40:29 <Brot6> NewGRF Meta Language - Feature #1031: support for houses (Hirundo) @ http://dev.openttdcoop.org/issues/1031#change-7172 11:46:00 *** FooBar has joined #openttdcoop.devzone 11:52:47 <Hirundo> planetmaker: looking at the production template now 11:52:54 <Hirundo> again, the 0: IND_ID(simple_produce) line is not needed, NML is smart enough to add that for you 11:53:33 <planetmaker> ok :-) 11:55:56 <Hirundo> I guess, permanent registers are used to facilitate debugging? 11:56:03 <planetmaker> yes 11:56:13 <planetmaker> otherwise a few of them could become temporary 11:56:29 <planetmaker> some are also needed for production increase / decrease decisions, IIRC 11:56:46 <Hirundo> How is var_production_span set? 11:58:14 <planetmaker> http://devs.openttd.org/~planetmaker/patches/index.php?source=produce_secondary.diff <-- explains it somewhat. 11:58:26 <planetmaker> That permanent variable will need to be set on construction 11:58:39 <planetmaker> or I keep it as compile-time constant for now. 11:58:49 <planetmaker> But I got the fancy idea to make it a variable ;-) 11:59:10 <planetmaker> which would allow longer 'concurrency time scales' in early times where delivery with horses is difficult 12:00:54 <Hirundo> hmm ok 12:01:03 <Hirundo> I do have my doubts about the modulo thingie, though 12:01:22 <Hirundo> Is it supposed to round up? 12:01:23 <planetmaker> The idea is that you always produce 1 12:02:12 <planetmaker> or rather NUM_INPUT_CARGOS 12:02:41 <planetmaker> if you deliver each cargo 12:02:53 <Hirundo> I'd say the Right Thing is to keep unprocessed cargo in stock, either visibly (in waiting_cargo_x) or in an internal register 12:04:12 <planetmaker> if I keep in waiting_cargo_x I cannot check whether it was delivered now 12:04:35 <planetmaker> thus that's not a too good approach. The only other option is another three registers, yes... 12:04:56 <planetmaker> and make temporary one of the current permanent ones 12:05:15 <planetmaker> but... that means to do different debugging messages. But that's ok, I guess 12:05:31 <planetmaker> I first went that way, discarded it for that reason, though 12:05:55 <planetmaker> But I still consider it preferable. 12:06:06 <planetmaker> But not identical with what we had ;-) 12:06:09 * Hirundo ponders desyncs, caused by GUI callbacks writing to permanent registers 12:06:16 <planetmaker> hu? 12:06:21 <planetmaker> gui callback? 12:06:40 <planetmaker> you mean generally, not here? 12:08:22 <Hirundo> yes in general 12:08:24 <Hirundo> I assume, the GUI code does no writing in this case :) 12:09:39 <planetmaker> dunno :-) 12:09:46 <planetmaker> Maybe we should evily just do that :-P 12:10:30 <Hirundo> If you decide to keep the current system, you could replace the (a / b) + (a % b) > 0 with (a + (b - 1)) / b 12:11:35 <planetmaker> I'll write an alternative version 12:11:42 <Terkhen> IMO the constant spam is quite annoying, but it's up to you :P 12:11:48 <Terkhen> planetmaker: should I check it or wait for new version? 12:11:55 <planetmaker> constant spam? 12:12:09 <Terkhen> regarding the Brot talk, I was away :P 12:12:18 <planetmaker> oh 12:13:09 <planetmaker> hm, I prefer what Hirundo suggested. I just didn't 'dare' to change the principle yet. 12:13:16 <planetmaker> But I guess we can. It's nothing fundamental 12:17:21 <Terkhen> I'll continue with the relative coord fix 12:24:06 <planetmaker> http://devs.openttd.org/~planetmaker/patches/index.php?source=produce_secondary2.diff <-- alternative version 12:25:58 <Terkhen> \ No newline at end of file <-- 12:26:37 <Terkhen> "Needed defines" are used as parameters for the template? 12:26:43 <Terkhen> if so, that should be clarified IMO 12:27:20 <planetmaker> those defines must be in the industry's pnml using the template 12:27:33 <planetmaker> so yes, a parameter of sorts 12:28:03 <planetmaker> changed it 12:28:40 <planetmaker> and I decided to not make IND_PRODUCTION_SPAN a variable. For now 12:29:01 <planetmaker> we can do that when we've converted the thing to NML somewhat more completely 12:29:13 <Terkhen> some comments at the huge block of STORE_x commands would improve readability, for example /* Update date of the last unit of cargo received */ for the first three 12:30:03 <Terkhen> where are var_reveived_timely_1 values defined? also it seems to have a typo 12:30:06 <Terkhen> bbl 12:34:39 <planetmaker> updated with comments 12:55:27 <Terkhen> it seems to be the same to me 13:00:16 <planetmaker> he. forgot to upload :-) 13:00:18 <planetmaker> http://devs.openttd.org/~planetmaker/patches/index.php?source=prod_template.diff 13:04:21 <Terkhen> var_reveived_timely_2 <--- reveived is not a typo? 13:04:49 <Terkhen> I also don't see it declared anywhere else in the diff file 13:08:58 <planetmaker> you're right, it needs definition; it's a temporary variable 13:09:09 <planetmaker> but where's the typo? 13:10:02 <planetmaker> I generally forgot to define the temp. variables... 13:14:10 <Terkhen> s/reveived/received/ probably 13:14:28 <planetmaker> oh :-) 13:15:05 <planetmaker> of course. Diff updated 13:18:03 <Terkhen> looks nice :) 13:18:29 <planetmaker> it needs also a concurrent update of the extra text callback handling... 13:18:37 *** Lakie has joined #openttdcoop.devzone 13:18:41 <planetmaker> via la mq ;-) 13:24:16 <Brot6> Central European Train Set - Support #2784: graphics template (Eddi) @ http://dev.openttdcoop.org/issues/2784#change-7173 13:26:34 <Brot6> Central European Train Set - Revision 98:2a7c64c3ca14: offset correction for 12lu template (Eddi) @ http://dev.openttdcoop.org/projects/cets/repository/revisions/2a7c64c3ca14 13:30:16 <planetmaker> Terkhen: what do you think of s/IND_ID/THIS_ID/ 13:30:34 <planetmaker> then all industry-local stuff could be called THIS_XXX 13:30:45 <planetmaker> might be more intuitive to grasp the local-ness than IND_XXX 13:30:59 <planetmaker> (especially as the nfo code also handled it that way) 13:43:42 <Brot6> Central European Train Set - Revision 99:c17d3dbcab79: various additions to tracking table (Eddi) @ http://dev.openttdcoop.org/projects/cets/repository/revisions/c17d3dbcab79 13:54:34 <Terkhen> I agree, THIS_ID sounds better 13:56:48 <Brot6> Central European Train Set - Revision 100:0308dee20efd: resolve duplicate ID# (Eddi) @ http://dev.openttdcoop.org/projects/cets/repository/revisions/0308dee20efd 13:57:48 <planetmaker> ok, then I'll commit that change, unless you have something which should go first 14:02:52 <Brot6> Central European Train Set - Revision 101:d93959ce5bd9: add new callback files (Eddi) @ http://dev.openttdcoop.org/projects/cets/repository/revisions/d93959ce5bd9 14:08:18 <Brot6> Central European Train Set - Revision 102:677139740868: add availability define for kkStB (Eddi) @ http://dev.openttdcoop.org/projects/cets/repository/revisions/677139740868 14:08:18 <Brot6> Central European Train Set - Revision 103:186c4d4c1cd0: add missing tender (Eddi) @ http://dev.openttdcoop.org/projects/cets/repository/revisions/186c4d4c1cd0 14:12:14 <Terkhen> I'm taking a break, go ahead :) 14:15:11 <Brot6> FIRS Industry Replacement Set - Revision 2205:417222072980: Add: Production template for secondar... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/417222072980 14:15:11 <Brot6> FIRS Industry Replacement Set - Revision 2204:96b39155a20e: Codechange: Rename the THIS_ID templa... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/96b39155a20e 14:15:11 <Brot6> FIRS Industry Replacement Set - Revision 2206:1a5975b8ae9f: Add: Template for showing extra text ... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/1a5975b8ae9f 14:15:13 <Brot6> FIRS Industry Replacement Set - Revision 2207:2973c8b1f8dc: Codechange: Apply production and extr... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/2973c8b1f8dc 14:29:58 <Brot6> FIRS Industry Replacement Set - Revision 2208:42812a82d498: Codechange: Apply production and extr... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/42812a82d498 14:35:48 <Brot6> FIRS Industry Replacement Set - Revision 2209:38135d7541be: Codechange: Apply production and extr... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/38135d7541be 15:04:55 <Brot6> DictatorAI - Revision 118:4cdc64308db1: - Still terraforming work (krinn) @ http://dev.openttdcoop.org/projects/ai-dictator/repository/revisions/4cdc64308db1 16:26:56 <Brot6> FIRS Industry Replacement Set - Revision 2210:814b975971d1: Codechange: Apply production and extr... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/814b975971d1 16:34:41 <Brot6> FIRS Industry Replacement Set - Revision 2211:2abdeae71e70: Codechange: Apply production and extr... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/2abdeae71e70 16:38:19 <planetmaker> nice ad in the forums, Hirundo :-) 16:39:13 <FooBar> was just reading that 16:39:37 <FooBar> Shouln't the 0xFF be CB_FAILED? 16:39:39 <FooBar> In articulated_part: return (extra_callback_info1 <= 3) ? some_articulated_tram : 0xFF; 16:43:09 <FooBar> I'd better gonna have dinner now... 17:01:34 <Brot6> FIRS Industry Replacement Set - Revision 2212:62ec7063ead0: Codechange: Apply production and extr... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/62ec7063ead0 17:05:53 <Hirundo> FooBar: It doesn't matter much really, both have the same effect 17:06:21 <Hirundo> "if (callback == CALLBACK_FAILED || GB(callback, 0, 8) == 0xFF) return INVALID_ENGINE;" <- from ottd source 17:08:07 <Brot6> FIRS Industry Replacement Set - Revision 2213:9bbe8d0c34a1: Codechange: Apply production and extr... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/9bbe8d0c34a1 17:10:13 <Brot6> nml: update from r1556 to r1559 done - http://bundles.openttdcoop.org/nml/nightlies/r1559 17:12:08 <Brot6> firs: update from r2194 to r2213 done (37 warnings) - http://bundles.openttdcoop.org/firs/nightlies/r2213 17:16:45 <planetmaker> @base 10 16 1024 17:16:45 <Webster> planetmaker: 400 17:20:08 <Brot6> cets: update from r95 to r103 done (442 warnings) - http://bundles.openttdcoop.org/cets/nightlies/r103 17:21:27 <Brot6> Following repos didn't need a nightlies update: ogfx-trains (r245), narvs (r37), bros (r52), ogfx-industries (r122), firs (r2213), sub-landscape (r72), opengfx (r681), ailib-tile (r16), transrapidtrackset (r28), 2cctrainset (r750), ailib-list (r32), opensfx (r97), ttdviewer (r34), worldairlinersset (r672), heqs (r605), openmsx (r97), basecosts (r25), nutracks (r202), nml (r1559), 32bpp-extra (r40), manindu (r7), newgrf_makefile (r305), 17:21:27 <Brot6> ailib-direction (r17), ailib-common (r21), snowlinemod (r49), dutchtramset (r84), ai-admiralai (r75), swisstowns (r22), metrotrackset (r56), spanishtowns (r10), frenchtowns (r6), grfpack (r279), ogfx-rv (r107), fish (r669), ogfx-landscape (r71), ttrs (r36), source-test (r2), ogfx-trees (r51), swedishrails (r203), grfcodec (r832), ai-aroai (r39), german-townnames (r34), smts (r19), chips (r143), belarusiantowns (r8), indonesiantowns 17:21:29 <Brot6> (r41), ailib-string (r29), airportsplus (r107), comic-houses (r71) 17:22:50 <Brot6> narvs: compile of r37 still failed (#2789) - http://bundles.openttdcoop.org/narvs/nightlies/ERROR/r37 17:24:16 <Brot6> sub-landscape: compile of r72 still failed (#2892) - http://bundles.openttdcoop.org/sub-landscape/nightlies/ERROR/r72 17:25:25 *** frosch123 has joined #openttdcoop.devzone 17:27:03 <Brot6> dutchtramset: compile of r84 still failed (#2899) - http://bundles.openttdcoop.org/dutchtramset/nightlies/ERROR/r84 17:38:47 <Brot6> airportsplus: rebuild of r107 done (2 warnings) (Diffsize: 30186) (DiffDiffsize: 33481) - http://bundles.openttdcoop.org/airportsplus/nightlies/r107/log 17:38:48 <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: ogfx-trains (Diffsize: 2319), ogfx-industries, manindu (Diffsize: 2), newgrf_makefile, swisstowns, spanishtowns (Diffsize: 2), frenchtowns, ogfx-rv (Diffsize: 4775), ogfx-landscape (Diffsize: 471), source-test (6 warnings), swedishrails (50 warnings) (Diffsize: 392), german-townnames (Diffsize: 1), belarusiantowns (Diffsize: 30), indonesiantowns (1 17:38:48 <Brot6> warnings) (Diffsize: 1) 17:47:11 <planetmaker> question for understanding: http://paste.openttdcoop.org/show/388/ <-- the return value "4" of e.g. action2_6512 indicates a custom error string? 17:47:34 <planetmaker> if that whole code is part of the industry location permissibility check 17:49:09 <frosch123> yes, text D004 17:50:07 <planetmaker> ok, thanks. I wonder though which text that might be :-) 17:50:13 <frosch123> 0..56: return 1025; <- there should be a constant for 0x401 17:50:20 <planetmaker> in terms of this actual newgrf. 17:50:24 <planetmaker> yes, there is 17:50:24 <Brot6> Project nml-dot-wine removed from finger 17:50:31 <Brot6> Project nml-wine removed from finger 17:50:36 <planetmaker> CB...UNSUITABLE or so 17:50:36 <Brot6> Project nml-pypi removed from finger 17:50:54 <frosch123> ah, i guess this is from nfo2nml, right? 17:52:33 <planetmaker> yes, it is. 17:52:38 <planetmaker> And I try to make it legible :-) 17:52:47 <planetmaker> rather grf2nml 17:52:53 <planetmaker> but yes :-) 17:55:58 <Hirundo> planetmaker: check the industry documentation 17:56:41 <planetmaker> I did :-). It says string. Not number ;-) 17:57:00 <planetmaker> But I also missed that line in plain sight :-) 18:03:46 <frosch123> [19:52] <planetmaker> rather grf2nml <- yeah, grf is a lot easier to read than nfo :) (same for grf2html) 18:20:12 <planetmaker> :-) 18:20:43 <planetmaker> though I think yexo read the sprites somehow from the nfo... dunno exactly how 18:24:36 <Brot6> Central European Train Set - Revision 104:28ee36a3e722: offset correction for 10lu template (Eddi) @ http://dev.openttdcoop.org/projects/cets/repository/revisions/28ee36a3e722 18:24:36 <Brot6> Central European Train Set - Revision 105:bc93ce270d28: switch 10lu wagons from 4+4+2 to 4+6 (Eddi) @ http://dev.openttdcoop.org/projects/cets/repository/revisions/bc93ce270d28 18:31:23 <FooBar> Hirundo: yeah, 0xFF and CB_FAILED are indeed the same thing, but given the high-levelness of NML I figured CB_FAILED would be more suitable. 19:05:53 <Brot6> clientpatches: update from r22691 to r22692 done (6 warnings) - http://bundles.openttdcoop.org/clientpatches/testing/r22692 19:10:46 <Brot6> openttd-vehiclevars: update from r22691 to r22692 done - http://bundles.openttdcoop.org/openttd-vehiclevars/testing/r22692 19:12:02 <FooBar> What does this mean: /nmlc: Real sprite parameters should be compile-time constants./ ? 19:12:02 <FooBar> with this code: http://pastebin.com/bv8gE6jW 19:12:24 <FooBar> By the way, openttdcoop pastes gives a 500 19:13:18 <FooBar> i.e. internal server error 19:15:23 <Brot6> serverpatches: update from r22691 to r22692 done (10 warnings) - http://bundles.openttdcoop.org/serverpatches/testing/r22692 19:15:57 <planetmaker> FooBar: delete your cookies 19:16:01 <planetmaker> (for that page) 19:16:21 <planetmaker> And tell Ammler to fix the application that it accepts invalid sessions / cookies without a 500 ;-) 19:16:33 *** JVassie has joined #openttdcoop.devzone 19:17:30 <FooBar> Ammler: what planetmaker just said ;) 19:17:31 <Brot6> 32bpp-ez-patches: compile of r22692 still failed (#2446) - http://bundles.openttdcoop.org/32bpp-ez-patches/testing/ERROR/r22692 19:17:43 <FooBar> but yes, that helped, thanks 19:18:21 <FooBar> as for my NML error, I get the strangest feeling that I can't use parameters for the filename. 19:19:43 <FooBar> Maybe I'd better set up the repo such that someone can has a look 19:20:06 <FooBar> and by repo I mean at the devzone, I obviously have one locally 19:20:59 <planetmaker> hm? what parameter where? 19:21:41 <FooBar> this: http://pastebin.com/bv8gE6jW 19:21:59 <FooBar> gives me a nmlc: Real sprite parameters should be compile-time constants. 19:28:03 <Brot6> repository /home/hg/foobarstramtracks registered in Redmine with url /home/hg/foobarstramtracks 19:28:03 <Brot6> repository /home/hg/foobarstramtracks created 19:29:21 <Brot6> FooBar's Tram Tracks - Revision 0:f61965bf9339: Set up repo (foobar) @ http://dev.openttdcoop.org/projects/foobarstramtracks/repository/revisions/f61965bf9339 19:29:22 <Brot6> FooBar's Tram Tracks - Revision 1:6f132ede3290: Add: initial code and graphics and license file (foobar) @ http://dev.openttdcoop.org/projects/foobarstramtracks/repository/revisions/6f132ede3290 19:29:59 <planetmaker> hm... new newgrf, eh? 19:30:25 <planetmaker> FooBar: of course the sprite filename must be constant 19:30:29 <Brot6> Central European Train Set - Revision 106:a4d3b89c0e4d: adjust movement pattern of 10lu template ... (Eddi) @ http://dev.openttdcoop.org/projects/cets/repository/revisions/a4d3b89c0e4d 19:30:46 <planetmaker> may I ask what is your aim? 19:30:51 <FooBar> what's not constant about a string? 19:31:35 <planetmaker> a parameter to a template can be variable 19:31:49 <FooBar> Well, the aim is that I can have 1 template for 48 variations of my tram tracks 19:31:55 <planetmaker> hm... though it depends of course 19:32:02 <planetmaker> well, yes? 19:32:24 <planetmaker> you can use one template with many filenames 19:32:39 <planetmaker> you'll still have to define the spritesets 19:32:52 <planetmaker> hm, ah, I see 19:33:00 <planetmaker> Well, make that more than one template. 19:33:04 <planetmaker> it's different spritesets 19:33:55 <FooBar> I feel I have to do this through gcc 19:34:33 <FooBar> But it would be much cleaner if it could be done directly through NML 19:34:36 <planetmaker> FooBar: IMHO the proper way is: one template per spriteset, i.e. one for GUI sprites, one for road overlays, one for road stops,... 19:34:43 <planetmaker> and there you need no gcc 19:34:51 <JVassie> hi planetmaker 19:34:58 <Ammler> planetmaker: why should I care about your broken systems? 19:35:02 <planetmaker> putting that in one template doesn't make it easier 19:35:08 <Ammler> but well, tell me how :-) 19:35:11 <planetmaker> Ammler: it's not MY. Two other people have the same 19:35:36 <planetmaker> I needed to start telling people how to work around it 19:36:05 <planetmaker> ask FooBar. Ask JVassie. They have the same issues with paste as I. From time to time 19:36:06 <FooBar> Hmmm... I still need to define the filename as parameter then 19:36:14 <JVassie> wha wha? 19:36:18 <Ammler> hmm 19:36:18 <planetmaker> FooBar: that's done in the spriteset itself 19:36:28 <planetmaker> JVassie: the error 500 on the paste service 19:36:32 <planetmaker> or wasn't that you the other day? 19:36:37 <JVassie> doubt it 19:36:43 <JVassie> havent been on my pc for nearly a week 19:36:48 <planetmaker> well, then it was another :-) also 'hi' :-) 19:36:48 <JVassie> let alone irc 19:36:50 <JVassie> :p 19:37:09 <FooBar> planetmaker: I can only set 1 filename there; I need to set 4 in one spriteset (or replacenew in this case) 19:37:14 <JVassie> the unfortunateness of no longer working from home 19:37:40 <Ammler> FooBar: you have any clue what caused it? 19:37:43 <planetmaker> FooBar: you plan to use anyway different filenames for gui, tracks etc. 19:37:57 <FooBar> planetmaker: yes 19:38:08 <planetmaker> then you can just as well use a separate sprite template for each 19:38:16 <planetmaker> and call that with the appropriate filename 19:38:17 <Ammler> it is just becasue I can't reproduce it :-( 19:38:20 <planetmaker> it's not more nor less work 19:38:25 <planetmaker> than using one big template 19:38:25 <Ammler> and I use our paste quite a lot too 19:38:28 <planetmaker> and it remains readable 19:38:36 <FooBar> Ammler: one or two cookies got stuck somewhere. After I removed them it was fine 19:39:01 <Ammler> hmm, I should ask the nginx people 19:39:10 <FooBar> planetmaker: care to create a quick example? As I don't really follow how it could work... 19:39:31 <planetmaker> the long example is swedishrails 19:39:42 <FooBar> I can make a template for each graphics file I have, but that sort of defeats the purpose of templates... 19:40:17 <FooBar> I'll have a look at swedischrails 19:40:21 <FooBar> -c 19:40:28 <planetmaker> uhm... A template needs no filename 19:40:41 <planetmaker> you can re-use the same template for zillions of filenames 19:40:52 <planetmaker> just don't template the filename. But use the filename with the spriteset 19:41:18 <planetmaker> look at sprite_templates.pnml and railtypes.pnml in swedishrails 19:41:21 <FooBar> Then I still only have one filename per spriteset. I need 4 filenames per spriteset... 19:41:26 <FooBar> I'll have a look 19:42:19 <planetmaker> FooBar: there's IMHO no reason to put spritesets into one template. Simply as what you write there, it's several spritesets: GUI, tracks, stations,... 19:42:21 <planetmaker> each warrants a separate template 19:42:32 <planetmaker> and each of those templates can work without filename 19:42:48 <FooBar> Can I use spriteset inside replacenew() then? 19:42:53 <planetmaker> and then a single tram track type uses those spritesets: 19:43:48 <planetmaker> spriteset(tram_track_fancy_gui, "path/to/gfx.png") { tmpl_template } 19:44:17 <planetmaker> you can of course replacenew with a template 19:44:50 <planetmaker> see also swedishrails. 19:45:02 <planetmaker> It does it also the traditional style. It's fully ttdp compatible 19:45:30 <planetmaker> just skip the file railtypes.pnml. 70% of the code is ttdp dedicated... I wonder whether it was worth it and whether it has been ever used there 19:45:40 <planetmaker> replace (1005, "src/gfx/rails_overlays.png") { 19:45:40 <planetmaker> tmpl_overlay_TTD(20,198) 19:45:40 <planetmaker> } 19:45:45 <planetmaker> ^ likethat 19:45:57 <planetmaker> ok, and replacenew probably works the same 19:46:49 <FooBar> well, Action5 is more picky than ActionA: Action5 needs all sprites at once, where with ActionA you can have as much separate replacements as you want... 19:47:17 <FooBar> I can give the spriteset thing a go, but I doubt it works to be honest... 19:47:42 <FooBar> I appreciate the help, but I just don't see it :( 19:49:59 <planetmaker> hm... there's no offset in the action5 possible? 19:50:32 <FooBar> not for tramways 19:50:50 <FooBar> only for the features (or what you call it) TTDPatch doesn't have 19:51:25 <FooBar> I complained about that years ago :P 19:51:32 <FooBar> But to no avail 19:51:52 <planetmaker> :-) the new allow that. 19:52:04 <planetmaker> ok, the only solution I see in that case: use nested templates 19:52:17 <planetmaker> though... hm... fixed variable names 19:52:28 <planetmaker> yes... then GCC can be used to make it variable 19:52:44 <planetmaker> but then you need no template. Sorry, I understand now :-) I wasn't aware of the replacenew issue 19:55:14 <FooBar> ok, no problem 19:55:30 <planetmaker> nasty corner cases ;-) 19:55:32 <FooBar> glad we're on the same page and that I didn't make some stupid mistake :P 19:55:35 <planetmaker> and YOU found it :-P 19:55:54 <FooBar> I'm gonna make a feature request out of this... 19:57:50 <planetmaker> the question is: where? It mostly needs to be an openttd feature (offsets) or an NML feature (filenames as parameter) 19:58:05 <planetmaker> i.e. interpreting them as compile-time constant in templates 19:58:18 <planetmaker> the latter would already help, I guess 19:59:21 <FooBar> I'm going for the NML feature. As the OpenTTD feature would only break ttdpatch compatibility such that I still wouldn't be able to use it 19:59:42 <FooBar> Now I don't care much about ttdpatch any more, but I like people to think that I do :P 20:01:48 <Brot6> NewGRF Meta Language - Feature Request #2903 (New): Allow graphics filenames as parameter for tem... (foobar) @ http://dev.openttdcoop.org/issues/2903 20:02:39 <FooBar> Also, could somebody move the FooBar's Tram Tracks project to the Track sets subproject? As I'm not allowed/able to do that 20:11:10 <planetmaker> yep, consider it done 20:13:51 <FooBar> thanks 20:14:09 <planetmaker> 21:59 FooBar: Now I don't care much about ttdpatch any more, but I like people to think that I do :P <-- hehe :-) 20:14:17 <FooBar> :) 20:16:42 <FooBar> Where OpenTTD managed to catch up with TTDPatch a while ago, now TTDPatch doesn't catch up with OpenTTD. That's a shame really. And really annoying if you're trying to make something that uses the more advanced features of OpenTTD 20:17:33 <Ammler> you can safely forget ttdpatch 20:17:38 <Ammler> the time is gone for it 20:18:09 <FooBar> With this set it's not much of a problem. But with the Dutch Tram Set I don't think I have the energy to make it compatible 20:18:29 <Ammler> just do not announce it 20:23:28 <planetmaker> :-) 20:23:49 <FooBar> anyways, I'm gonna hit the shower. Not too hard though, as that's probably painful :P 20:23:58 <planetmaker> :-D 20:24:04 <planetmaker> good luck ;-) 20:30:02 <planetmaker> hm, time to close my ~30 XCode windows for today ;-) 20:33:04 *** bodis has joined #openttdcoop.devzone 20:49:25 <frosch123> firs has a nice grfid, you can identify it without needing to search for it :p 20:49:43 <Rubidium> FIRS? 20:50:06 <frosch123> yes F1250005 20:50:56 <Rubidium> ah yes, now I remember 20:55:13 <FooBar> Hmpf... Why is it that if I disable network time synchronizing in Fedora that it thinks it's a good idea to automatically enable it again :S 20:55:46 <Rubidium> you didn't disable it hard enough 20:56:18 <Brot6> Central European Train Set - Revision 107:5f751564e76a: adjust movement pattern of 12lu template ... (Eddi) @ http://dev.openttdcoop.org/projects/cets/repository/revisions/5f751564e76a 20:56:18 <Rubidium> ln -fs /usr/bin/true /usr/local/bin/ntpdate ? 20:58:03 <FooBar> don't know what that's supposed to do, but it doesn't work 20:59:23 <Rubidium> hopefully start bin/true instead of ntpdate, but it might be running ntpd in which case that doesn't work 20:59:30 <FooBar> also, there's no such thing as bin/true 20:59:54 <Rubidium> there ought to be, maybe in /bin though 21:00:06 <Rubidium> but try true in the console. I doubt it returns 'command not found' 21:00:13 <Rubidium> or whereis true 21:00:17 <Rubidium> or man true 21:00:20 <FooBar> yes, there's one in /bin 21:00:28 * FooBar tries again 21:02:04 <FooBar> well, that seems to have done something. Now to wait if it changes the time or not 21:04:54 <FooBar> just to be safe I symlinked both 21:09:56 <FooBar> oh thanks by the way :) 21:16:35 <Brot6> SuperLib - Revision 5:4cd3e78e7b10: Airport upgrading (Zuu) @ http://dev.openttdcoop.org/projects/superlib/repository/revisions/4cd3e78e7b10 22:24:09 *** frosch123 has quit IRC 22:48:52 *** bodis has quit IRC 22:48:57 *** FooBar has quit IRC 23:07:23 *** JVassie has quit IRC 23:52:25 *** Lakie has quit IRC