Times are UTC Toggle Colours
06:11:53 *** andythenorth has joined #openttdcoop.devzone 06:37:37 <Brot6> DictatorAI - Revision 129:7164ebc9ebb6: - Change jobIndexer to record last date job infos were re... (krinn) @ http://dev.openttdcoop.org/projects/ai-dictator/repository/revisions/7164ebc9ebb6 07:12:06 *** frosch123 has joined #openttdcoop.devzone 07:14:42 <Brot6> DictatorAI - Revision 130:16bfd8df4e40: - correct bugs (krinn) @ http://dev.openttdcoop.org/projects/ai-dictator/repository/revisions/16bfd8df4e40 08:11:47 *** bodis has joined #openttdcoop.devzone 08:22:34 *** andythenorth has quit IRC 08:28:35 *** andythenorth has joined #openttdcoop.devzone 08:54:27 *** andythenorth has quit IRC 09:56:53 <Brot6> FIRS Industry Replacement Set - Feature #2936 (New): Review substitute type in order to help AIs (planetmaker) @ http://dev.openttdcoop.org/issues/2936 10:37:03 *** andythenorth has joined #openttdcoop.devzone 10:43:21 *** Brot6 is now known as Guest5013 10:43:33 *** Brot6 has joined #openttdcoop.devzone 10:44:27 *** Brot6 has quit IRC 10:45:12 *** Brot6 has joined #openttdcoop.devzone 10:45:43 <Brot6> OpenGFX - Revision 709:e5e6945f6ee8: Add (#717): source files for rail/road stations, rail fences... (foobar) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/e5e6945f6ee8 10:46:53 <Brot6> HEQS "Heavy Equipment" Set - Revision 637:83210cdeb4da: Fix: Railmotor using wrong smoke type (andythenorth) @ http://dev.openttdcoop.org/projects/heqs/repository/revisions/83210cdeb4da 10:46:54 <Brot6> HEQS "Heavy Equipment" Set - Revision 638:0abf1a424ae8: Change: corrected some comments about s... (andythenorth) @ http://dev.openttdcoop.org/projects/heqs/repository/revisions/0abf1a424ae8 10:49:37 *** Guest5013 has quit IRC 10:57:56 <Brot6> OpenGFX - Revision 710:5b8e74807f4d: Change: reorder sprites/source files in directories (foobar) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/5b8e74807f4d 10:58:06 *** FooBar has joined #openttdcoop.devzone 10:58:32 *** FooBar is now known as Guest5015 10:59:22 *** FooBar has joined #openttdcoop.devzone 11:00:25 <FooBar> DJNekkid: you on here? 11:07:28 *** andythenorth has quit IRC 11:29:50 *** andythenorth has joined #openttdcoop.devzone 11:34:29 <Ammler> FooBar: long time not seen 11:34:31 <Ammler> @seen DJNekkid 11:34:31 <Webster> Ammler: DJNekkid was last seen in #openttdcoop.devzone 20 weeks, 2 days, 12 hours, 48 minutes, and 59 seconds ago: <DJNekkid> for example, the IC pax wagons will be a combination of 2nd class, 1st class, diner and sleeper 11:34:53 <FooBar> yeah, he is/was on vacation I believe 11:35:12 <FooBar> but I thought I saw a post of him recently on the forums, so I give it a try :) 11:37:17 <Ammler> FooBar: I do not like the term source as directory name :-) 11:37:27 <FooBar> it's not my idea 11:37:39 <FooBar> it was there, it was a mess, I just cleaned it up a bit 11:37:53 *** andythenorth has quit IRC 11:37:53 <FooBar> now I'm cleaning up the main png dir 11:38:23 <FooBar> but if you have a better name for that dir, just go ahead and rename it ;) 11:38:29 <Ammler> yeah, I know, still 11:39:12 <FooBar> I don't know a better name. It's basically the source of the source. "source^2" :P 11:39:36 <Ammler> "work" maybe 11:40:00 <FooBar> I used to name the files with all intermediate drawings "working file" 11:40:23 <FooBar> so yes, "work" or "work files" would be appropriate 11:44:21 <Brot6> OpenGFX - Revision 711:60be3583d0bd: Codechange: reorder sprites/png houses files in houses direc... (foobar) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/60be3583d0bd 11:51:36 <Brot6> OpenGFX - Revision 712:46ea6e557122: Codechange: reorder sprites/png gui files in gui directory (foobar) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/46ea6e557122 11:51:40 * Hirundo is overwhelmed by swedishrails, while trying to reduce it to example-sized code 11:58:07 <Brot6> OpenGFX - Revision 713:3f5f0b240215: Codechange: reorder sprites/png infrastructure files in infr... (foobar) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/3f5f0b240215 12:12:31 <Hirundo> planetmaker: disabling level crossings in swedishrails currently has a rather awkward side effect of showing caternary for non-electrified rails 12:13:00 <Hirundo> the disabling effect itself is smoke-and-mirrors only, btw :) 12:15:43 <Brot6> OpenGFX - Revision 714:8a6ba7068ea1: Codechange: reorder sprites/png remaining files in directories (foobar) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/8a6ba7068ea1 12:16:46 <FooBar> does anybody know why egrvts.png is in opengfx/sprites/png? It isn't used by anything... 12:17:25 <FooBar> I'm inclined to remove it, but maybe it should go to the "source" (or whatever it's going to be called) dir 12:18:53 <FooBar> hmmm, it's also decoded using the wrong palette. Lots of magic pink 12:18:55 <Brot6> NewGRF Meta Language - Revision 1578:2a3e0d3febc0: Fix: Some typos in railtype docs. (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/2a3e0d3febc0 12:19:00 <Brot6> Swedish Rails - Revision 205:3063a8262a0d: Fix: Use bitmask() for railtype_flags, also set the ca... (Hirundo) @ http://dev.openttdcoop.org/projects/swedishrails/repository/revisions/3063a8262a0d 12:27:43 <Brot6> OpenGFX - Revision 715:fa4a5e5a70ce: Cleanup: make sprites/png/gui/medfont.png obsolete and remov... (foobar) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/fa4a5e5a70ce 12:32:12 <FooBar> #1959 12:32:12 <Brot6> FooBar: #1959 is http://dev.openttdcoop.org/issues/show/1959 "OpenGFX - Feature #1959: toyland road vehicles - #openttdcoop Development Zone" 12:35:00 <Brot6> OpenGFX - Revision 716:3f70ea51f746: Cleanup: remove sprites/png/egrvts.png, obsoleted by sprites... (foobar) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/3f70ea51f746 12:35:13 <FooBar> well, that's that. Let's now keep it tidy :) 12:49:07 *** andythenorth has joined #openttdcoop.devzone 12:57:12 *** andythenorth has quit IRC 13:04:49 *** Rubidium_ has joined #openttdcoop.devzone 13:05:15 *** Rubidium has quit IRC 13:05:43 *** Rubidium_ is now known as Rubidium 13:14:26 <Brot6> OpenGFX - Bug #2576 (Closed): Forest ground tile (foobar) @ http://dev.openttdcoop.org/issues/2576#change-7358 13:14:26 <Brot6> OpenGFX - Revision 717:fadbed63ece6: Fix #2576: new forest ground tile shows holes where trees us... (foobar) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/fadbed63ece6 13:16:19 *** andythenorth has joined #openttdcoop.devzone 13:41:01 <Brot6> OpenGFX - Code Review #2119 (Closed): New Sprites for Guru X2 Helicopter (foobar) @ http://dev.openttdcoop.org/issues/2119#change-7359 13:41:01 <Brot6> OpenGFX - Revision 718:ce570ce6c90c: Feature (closes #2119): revised GuruX2 helicopter (DanMacK) (foobar) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/ce570ce6c90c 13:53:07 <Hirundo> planetmaker: Why does one of the underlay sprites have a differing offset? 13:53:25 <Hirundo> (swedishrails) 13:57:49 <Ammler> FooBar: nice catch up :-) 13:57:57 <FooBar> thanks :) 14:01:33 <Brot6> FIRS Industry Replacement Set - Revision 2235:8d956e14dcdc: -Codechange: Use the relative_coord h... (Terkhen) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/8d956e14dcdc 14:01:46 <Terkhen> ^ I finally managed to stop playing civilization :P 14:01:47 <Terkhen> bbl 14:06:01 <Brot6> OpenGFX - Code Review #2573 (Closed): Check sprite #4462 (foobar) @ http://dev.openttdcoop.org/issues/2573#change-7360 14:06:01 <Brot6> OpenGFX - Revision 719:17daf2da5835: Feature (closes #2573): show outline of arctic church on gro... (foobar) @ http://dev.openttdcoop.org/projects/opengfx/repository/revisions/17daf2da5835 14:07:33 <andythenorth> Terkhen: I've started playing a game called openttd 14:07:38 <andythenorth> you might enjoy it :p 14:18:33 *** andythenorth is now known as Guest5054 14:18:34 *** andythenorth has joined #openttdcoop.devzone 14:24:12 *** Guest5054 has quit IRC 14:35:34 <Terkhen> andythenorth: I was taking a break from that too ;) 14:39:51 <Brot6> NewGRF Meta Language - Revision 1579:81ac02a1da88: Doc: Fix documentation about railtype recolour... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/81ac02a1da88 14:40:42 <Brot6> NewGRF Meta Language - Revision 1580:f772adcba46f: Add: Railtype example. (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/f772adcba46f 15:39:54 <Brot6> FIRS Industry Replacement Set - Feature #2937 (New): Consider supporting YACD explicitly (andythenorth) @ http://dev.openttdcoop.org/issues/2937 16:09:54 <Brot6> FIRS Industry Replacement Set - Bug #2938 (Confirmed): Stockyard accepts FMSP instead of LVST (andythenorth) @ http://dev.openttdcoop.org/issues/2938 16:17:59 *** bodis has quit IRC 16:27:33 <Brot6> FIRS Industry Replacement Set - Revision 2236:5c09ca790cbb: -Codechange: Make prospect_chance mor... (Terkhen) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/5c09ca790cbb 16:31:44 <Brot6> Central European Train Set - Feature #2763: track classes / railtype support (Eddi) @ http://dev.openttdcoop.org/issues/2763#change-7361 16:34:52 <Terkhen> hmm... will NML simplify switches that always call another switch? 16:35:00 <Terkhen> s/simplify/remove/ 16:35:22 <Terkhen> oh, no need, I should just use a var in the spriteset 16:58:58 <Hirundo> Terkhen: No, it's not smart enough for such optimizations 16:59:10 <Terkhen> ok, thanks :) 16:59:16 <Terkhen> I'm taking a look at the advanced spritelayout example now 16:59:47 <Terkhen> what I need to do is similar to what the example does, but I wonder if it is possible to use variables directly inside the spritelayout 17:00:15 <Terkhen> the intro text seems to hint that it is possible but there are no examples about it, and I suppose it is using temporal registers to store which sprite to use for a reason 17:01:17 <andythenorth> Terkhen: from what I recall of spec, you can't use vars in it 17:01:23 <andythenorth> relies on storage 17:01:32 <andythenorth> (registers, not permanent) 17:01:55 <Terkhen> "While parameters cannot yet be assigned explicitly to a spritelayout, variables, temporary storage and parameters can be used inside of a layout nevertheless. A common usage for such parametrized spritelayout is taking care of the tile slope and ground type as illustrated in this example:" <--- that's what I thought too, but the intro text says this 17:02:02 <andythenorth> http://wiki.openttd.org/Frosch/Advanced_Sprite_Layout 17:02:38 <frosch123> Terkhen: planetmaker yesterday coded an example in nml 17:02:49 <frosch123> he switches fences around objects 17:02:58 <Terkhen> oh, nice, thanks :) 17:03:02 * Terkhen goes to the logs 17:03:10 <frosch123> pull ogfx+landscape 17:03:48 <Terkhen> ok :) 17:04:18 <frosch123> src/company_land.pnml 17:04:36 <frosch123> the purchase list preview will not work though due to a nml bug (as far as we could tell) 17:05:30 <frosch123> oh, and you will also need ottd trunk head :p 17:07:00 <Terkhen> thanks, your advertence prevented an inminent failure :P 17:08:27 <frosch123> andy highlighted me :) 17:09:20 <Terkhen> :) 17:10:18 <Brot6> nml: update from r1577 to r1580 done - http://bundles.openttdcoop.org/nml/nightlies/r1580 17:15:39 *** andythenorth has quit IRC 17:18:15 <Brot6> ogfx-trains: update from r246 to r248 done - http://bundles.openttdcoop.org/ogfx-trains/nightlies/r248 17:20:19 <Brot6> firs: update from r2233 to r2236 done (37 warnings) - http://bundles.openttdcoop.org/firs/nightlies/r2236 17:22:04 <Brot6> opengfx: update from r708 to r719 done - http://bundles.openttdcoop.org/opengfx/nightlies/r719 17:23:29 <Brot6> heqs: update from r636 to r638 done - http://bundles.openttdcoop.org/heqs/nightlies/r638 17:25:04 <Brot6> swedishrails: update from r204 to r205 done - http://bundles.openttdcoop.org/swedishrails/nightlies/r205 17:25:26 <Brot6> Following repos didn't need a nightlies update: narvs (r37), bros (r52), ogfx-industries (r122), ailib-tile (r16), foobarstramtracks (r23), transrapidtrackset (r28), 2cctrainset (r750), cets (r126), ailib-list (r32), opensfx (r97), ttdviewer (r34), worldairlinersset (r672), openmsx (r97), basecosts (r25), nutracks (r202), nml (r1580), 32bpp-extra (r40), manindu (r7), newgrf_makefile (r305), ailib-direction (r17), ailib-common (r21), 17:25:26 <Brot6> snowlinemod (r49), dutchtramset (r87), ai-admiralai (r75), swisstowns (r22), metrotrackset (r56), spanishtowns (r10), frenchtowns (r6), grfpack (r279), ogfx-rv (r107), fish (r684), ogfx-landscape (r75), ttrs (r36), ogfx-trees (r51), grfcodec (r833), ai-aroai (r39), german-townnames (r34), smts (r19), chips (r143), belarusiantowns (r8), indonesiantowns (r41), ailib-string (r29), airportsplus (r107), comic-houses (r71) 17:26:08 <Brot6> narvs: compile of r37 still failed (#2789) - http://bundles.openttdcoop.org/narvs/nightlies/ERROR/r37 17:41:59 *** Sylf has quit IRC 17:42:46 <Brot6> German town names - Bug #2939 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/2939 17:42:46 <Brot6> Belarusian Town Names - Bug #2940 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/2940 17:43:34 <Brot6> Indonesian Town Names - Bug #2941 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/2941 17:43:39 <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: ogfx-industries, foobarstramtracks, cets (436 warnings), manindu (Diffsize: 2), newgrf_makefile, dutchtramset, swisstowns, spanishtowns (Diffsize: 2), frenchtowns, ogfx-rv (Diffsize: 4775), ogfx-landscape 17:44:46 <Brot6> OpenGFX+ Airports - Bug #2942 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/2942 17:49:39 *** Sylf has joined #openttdcoop.devzone 17:50:32 <Terkhen> hmm... I remember asking this but I forgot 17:50:57 <Terkhen> what values are the defaults for xoffset, xextent? (same for y, z) 17:51:29 <Terkhen> ah, found them, sorry :) 17:52:24 <Terkhen> meh, I also found some cases that break my template for spritelayouts 17:52:32 * Terkhen looks for a different way of defining them 17:55:23 <Terkhen> I find too many special cases, templating is probably not worth the effort when the template needs 23 parameters 17:57:14 <Hirundo> Terkhen: Using variables in a spritelayout is possible 17:58:02 <Hirundo> NML just creates an intermediate varaction2 to put *stuff* in registers, so there's no reason why you couldn't use variables tehre 17:58:26 <Terkhen> Hirundo: that's really nice :) 17:58:30 <Terkhen> I got it working: hide_sprite: terrain_type == TILETYPE_SNOW; 17:58:47 <Terkhen> but I did not know the magic that nml does to implement it :P 17:59:17 <Hirundo> NML does lots of magic under the hood :P 17:59:26 <Brot6> Belarusian Town Names - Bug #2940 (Rejected): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/2940 17:59:26 <Brot6> Belarusian Town Names - Bug #2940 (Rejected): DevZone compile failed (Ammler) @ http://dev.openttdcoop.org/issues/2940#change-7362 18:00:34 <Hirundo> frosch123: What bug in NML messes up the purchase list? 18:04:19 <Terkhen> sprite: (terrain_type != TILETYPE_SNOW) ? sprite_normal_food_market : sprite_snow_food_market; <--- I wonder if there would be any way to make this code work (nml complains that the ternary operator should only receive integers) 18:04:38 <Terkhen> defining each building only once would save me a lot of parameters 18:07:16 <Hirundo> No, currently there's no easy way to make that work 18:08:22 <Hirundo> First of all the ?: operator is currently implemented in terms of arithmetic which cannot operate on references 18:08:43 <Terkhen> ok :) 18:08:46 <Hirundo> also, selecting a spriteset dynamically is not possible within the spec 18:09:09 <Hirundo> you can, however, put both sprites in a single spriteset and use an offset to select one of them 18:10:05 <Terkhen> sprite: sprite_set + (terrain_type == TILETYPE_SNOW) <--- something like this? :) 18:10:11 <frosch123> Hirundo: is there no issue? :o 18:10:37 <frosch123> if you take ogfx+landscape tip, the "company land" object will not display something in the purchase list 18:10:43 <Hirundo> I know of no issue, that's why I ask 18:11:27 <frosch123> problem is that it accesses an variable which is not available in the purchase list,so it continues to the wrong chain or so 18:11:36 <frosch123> though it should actually not need to read that variable 18:11:47 <frosch123> (though unpatched tip might be wrong in itself) 18:11:51 <Hirundo> trying to access a variable in the purchase chain leads to undefined behaviour 18:11:53 <Brot6> Central European Railway Track Set - Code Review #2943 (New): Alternate rail type label OTTD patch (michi_cc) @ http://dev.openttdcoop.org/issues/2943 18:12:19 * Hirundo checks code 18:13:07 <frosch123> http://devs.openttd.org/~frosch/diffs/purchaselist.diff <- with that diff it works 18:13:16 <frosch123> if you switch the // on the last two lines it fails 18:13:59 <Terkhen> bbl 18:13:59 <frosch123> as the purchase list chain then enters a huge advvaract2 which belongs to the default chain 18:15:44 <Hirundo> The normal layout accesses variables, which is not possible 18:16:06 <frosch123> the normal layout works fine 18:16:26 <frosch123> but the computation for the normal layout is also processed for the purchase list case 18:16:51 <Hirundo> The normal layout uses nearby_object_tile(..) and such 18:17:02 <Hirundo> you need a computation to read that and store in registers 18:17:50 <frosch123> yes, but that computation is only needed for the default case, not for the purchase list case 18:18:18 <frosch123> and nearby_object_tile is not available in purchase list, at which point it starts to fail 18:20:31 <Hirundo> Let me see... 18:27:06 *** andythenorth has joined #openttdcoop.devzone 18:27:09 <Hirundo> frosch123: OK, I have Seen (tm) 18:27:24 <frosch123> :) 18:27:30 <Hirundo> there are 3 in-between switches 18:27:47 <Hirundo> one for purchase, one for normal, and one that belongs to the spritelayout 18:28:09 <Hirundo> that third one is called always, because the spritelayout needs variables in the computation 18:29:01 <Hirundo> However it aborts almost instantly, because it tries and fails to access the nearby_tile_object_type var 18:29:25 <Hirundo> At that point it continues to the spritelayout itself, but all registers written there still contain 0 at that point 18:29:46 <Hirundo> 0 means 'skip sprite' in this context, so no sprites are drawn 18:31:39 <Hirundo> Until NML checks and verifies that no variables are accessed in the P-list, there is little to do about it except documentation 18:34:08 <frosch123> so it fails due to the usage of STORE_TEMP ? 18:39:12 <Brot6> NewGRF Meta Language - Revision 1581:498693a47e13: Doc: Document that variables may not be used i... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/498693a47e13 18:39:12 <Hirundo> no 18:39:22 <Hirundo> due to nearby_tile_object_type 18:43:58 <Hirundo> hmm... time to optimize the ternary op a bit 18:49:45 <frosch123> i don't know about the internal processes in nml. but if nearby_tile_object_type is only uses in the layout, shoudn't it be read just before the layout instead of some earlier switch? 18:53:10 <Hirundo> It is read just before the layout 18:54:15 <Hirundo> Those ternary ops are really bogus btw, (a == b) returns 0 or 1 already 18:55:01 <Hirundo> Those nearby tile variables are read in the last switch before the layout 18:55:44 <frosch123> and where would it decide between company_land_purchase_layout and company_land_layout? 18:56:49 <Hirundo> With your diff applied, or with your modified diff applied, or with current ogfx+landscape? 18:57:00 <frosch123> with the modfied diff 18:57:15 <frosch123> that tip fails is ok :) 18:58:48 <Brot6> NewGRF Meta Language - Revision 1582:43b049c032bf: Codechange: Optimize ternary operator operatin... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/43b049c032bf 19:00:43 <Hirundo> So graphics block contains this ? 19:00:45 <Hirundo> purchase: company_land_purchase_layout; 19:00:46 <Hirundo> company_land_terrain_switch; 19:02:15 <frosch123> yes 19:02:56 <Hirundo> ah, indeed a bug in NML 19:03:30 <Hirundo> After I got the correct nfo output, it took around 2 secs :) 19:05:21 <planetmaker> 14:16 FooBar: does anybody know why egrvts.png is in opengfx/sprites/png? It isn't used by anything... <-- it is the 'source' of lots of road vehicles, especially in toyland. But it can go 19:05:36 <Brot6> clientpatches: update from r22727 to r22729 done (6 warnings) - http://bundles.openttdcoop.org/clientpatches/testing/r22729 19:06:11 <planetmaker> Hirundo: can you be more specific which underlay sprite? 19:07:34 <Hirundo> the last sloped underlay sprite 19:08:12 <Hirundo> It has -30,-9, where I expected -31, -8 like the first sprite of that set 19:10:12 <FooBar> planetmaker: it already went ;). I went through it's history and it was used once for toyland road vehicles, but these have since been replaced by new work of DanMacK. And it had lots of magic pink in it anyways. I don't know how much of egrvts DanMacK used for the vehicles, but if he did we might want to consider keeping a version (without pink) in the sprites/source dir instead. 19:10:30 <Brot6> openttd-vehiclevars: update from r22727 to r22729 done - http://bundles.openttdcoop.org/openttd-vehiclevars/testing/r22729 19:10:34 <planetmaker> yes, I saw it later , it's fine 19:11:03 <planetmaker> Hirundo: possibly it's a manual fix to how it should look - and I rather fixed the template than the gfx 19:11:24 <planetmaker> though I'm not sure, I'll have to look. 19:11:33 <planetmaker> Wrt the purchase view of objects / company_land: 19:12:03 <planetmaker> I don't get anything there even when I directly reference the simplest spritelayout one can imagine, with a singe ground tile 19:12:08 <Hirundo> Bug fix is on its way 19:12:20 <planetmaker> I didn't yet add it to anything as I wasn't yet sure... 19:12:22 <planetmaker> ok :-) 19:12:33 <Hirundo> There was a quite bad assumption, that cargo-specific gfx exist only for features <= 04 19:12:56 <Hirundo> Which fails in this only and exact case 19:13:08 <planetmaker> hm, but even that didn't solve it for me... 19:13:29 <planetmaker> I allowed cargo-type 0xFF but... oh well. Maybe more than one line of fix needed 19:14:56 <Brot6> serverpatches: update from r22727 to r22729 done (10 warnings) - http://bundles.openttdcoop.org/serverpatches/testing/r22729 19:15:05 <Hirundo> In fact it should work even now, if you remove the additional_text callback 19:15:26 <planetmaker> hm... the additional_text callback? why does it work then? 19:15:51 <Hirundo> Because then, no intermediate varaction2 for callbacks is needed after the actino3 19:16:00 <Hirundo> bugs can be intricate :) 19:17:05 <Brot6> 32bpp-ez-patches: compile of r22729 still failed (#2446) - http://bundles.openttdcoop.org/32bpp-ez-patches/testing/ERROR/r22729 19:17:21 <Hirundo> In fact that was one of the reasons why I couldn't find the bug at first, I commented out that line because I didn't have that string 19:17:40 <planetmaker> "nice" ;-) 19:19:16 <Hirundo> I'll push as soon as regression stops complaining 19:22:24 <Brot6> NewGRF Meta Language - Revision 1583:193d73d47ef9: Fix: Really check if there are cargo-specific ... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/193d73d47ef9 19:23:31 * planetmaker re-compiles ogfx-landscape 19:24:36 <andythenorth> hmm 19:24:39 <andythenorth> can't pull :P 19:25:44 <planetmaker> hm? 19:26:34 <frosch123> Hirundo: did your optimsation of ? : invert the result? 19:27:00 <frosch123> while the purchase list works now, i get fences exactly where no fences shall be and vice versa :) 19:29:11 <Terkhen> planetmaker, andythenorth: I plan to unify all layout / relative_pos code and use advanced spritelayouts instead 19:29:18 <Terkhen> http://devs.openttd.org/~terkhen/patches/index.php?source=010_food_market_example.diff <--- here is a toy example 19:29:20 <Terkhen> what do you think? 19:29:36 <planetmaker> Terkhen: go for it. But we have to be clear that it requires openttd newer than yesterday 19:29:50 <Hirundo> frosch123: yes :( 19:29:53 <andythenorth> planetmaker: that's going to happen sometime soon anyway 19:29:55 * Hirundo feels ashamed 19:29:56 <andythenorth> Terkhen: go for it 19:30:14 <andythenorth> I don't understand nml enough to know if it's a bad pattern or not 19:30:19 <planetmaker> Terkhen: I wonder: should the snow be a child of the building? 19:30:32 <andythenorth> planetmaker: I've thought of doing that before 19:30:33 <planetmaker> But I guess it's better a building on its own as might be larger than the building itself 19:30:58 <andythenorth> ys 19:30:59 <planetmaker> Terkhen: and yes, I had the very same idea about layouts 19:31:09 <planetmaker> it'll make extending them MUCH nicer :-) 19:31:10 <frosch123> planetmaker: Terkhen: it should definitely be a child, don't put bounding boxes over each other 19:31:19 <frosch123> their sorting order is basically undefined 19:32:01 <frosch123> oh, wait, you always only draw one of those :) 19:32:56 <Brot6> NewGRF Meta Language - Revision 1584:b3dec8e699a1: Fix: Things that aren't broken shouldn't be fi... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/b3dec8e699a1 19:33:33 <Terkhen> yes, it only draws one of the buildings 19:33:55 <Hirundo> You can also put both sprites in the same spriteset, and select the one to draw by specifying an offset 19:33:55 <Terkhen> once the code is templated, the template could add an additional switch to store the sprite into a register 19:34:03 <Terkhen> also ^ 19:34:19 <Terkhen> I'm still thinking the best way to template the code :P 19:34:42 <planetmaker> Hirundo: IMHO it's better to draw snow only as overlay 19:34:46 <Terkhen> but I wanted to know how you feel regarding the "big" changes on unduplicating layout, relative_pos, etc code 19:34:48 <Terkhen> :) 19:34:51 <planetmaker> then it can be drawn as exactly that: just the snow 19:35:03 <planetmaker> it's an easy thing to extract that layer 19:36:14 <Hirundo> snow as overlay is indeed best 19:36:28 <andythenorth> most of FIRS is overlay 19:36:37 <Terkhen> now you lost me :P 19:37:37 <planetmaker> Terkhen: groundtile: terrain_type == SNOW ? GROUNDTILE_SNOW : <whatever> 19:37:41 <planetmaker> what about that ^ 19:37:53 <planetmaker> though... maybe not 19:37:57 <Terkhen> the food market also has snow on the roof :) 19:38:13 <planetmaker> yes. But the concret ground tile will be snowed anyway... 19:38:25 <planetmaker> thus it only needs a snowy house. Not the ground additionally on that sprite 19:38:38 <planetmaker> and... snowy ground is needed for transparency anyway 19:38:52 <Terkhen> also, in the food market case, the ground sprite for the snow version is still GROUNDSPRITE_CONCRETE 19:38:58 <Terkhen> so I'm guessing that the ground is part of the building sprite 19:39:01 <planetmaker> should it? 19:39:13 <Terkhen> I don't know but it looks with snow ingame :P 19:40:02 <planetmaker> one more reason IMHO to allow the ground tile to become snowy 19:40:14 <planetmaker> though... well, not important here 19:40:46 <Terkhen> the template could accept a parameter for that too 19:41:20 <planetmaker> But you could template this ASL: with two alternate ground tiles (snowy / non-snowy overlays to the default ground) + building + snow overlay 19:41:40 <planetmaker> thus my idea: ground + child which modifies it + building 19:41:59 <planetmaker> the child and building in snowy and non-snowy version 19:42:20 <planetmaker> the ground sprite would always be terrain-dependent 19:42:32 <planetmaker> if it needs complete replacement... then the child does that 19:42:46 <planetmaker> *complete custom replacement 19:42:57 <planetmaker> that should cover 90% of the tiles 19:43:06 <planetmaker> i.e. simple building 19:43:18 <planetmaker> on non-slope thingy 19:44:51 <Terkhen> any existing industry tile uses snow as an overlay? 19:45:33 <andythenorth> nothing from nfo FIRS 19:46:31 <Terkhen> for example, in the food market case... would drawing the building twice (once as building without snow, again with childsprite -> building with snow) break something? 19:47:05 <andythenorth> not as far as I am aware 19:47:16 <andythenorth> try it :P 19:47:55 <Terkhen> hmm... 19:48:02 <frosch123> planetmaker: http://devs.openttd.org/~frosch/diffs/fenceboundingboxes.diff <- makes the bounding boxes not extent out of the tile, and fit under bridges 19:48:03 <Terkhen> but openttd will be drawing the "same" sprite twice, right? 19:48:45 <frosch123> ideally the southern bounding boxes would not have a width of 0, but putting them at position 15 instead of 16 would require separate sprites 19:50:12 <planetmaker> he, thanks frosch123, I was just about to add a separate purchase layout with fences, too :-) 19:53:16 <Terkhen> if using building + childsprite would draw the industry tile twice then I prefer using building + building 19:54:21 <planetmaker> hm? 19:54:29 <Terkhen> read back :P 19:54:41 <planetmaker> ah, you mean as there's no snow overlay yet? 19:54:51 <planetmaker> I guess we can and should use different templates / layouts for that then 19:55:30 <planetmaker> so first indeed go one building or the other 19:57:32 <Terkhen> right now all industries follow that pattern 19:57:49 <Terkhen> the layout chains are triplicated 19:57:57 <Terkhen> once for normal, another time for snow, another time for desert 20:00:18 <Brot6> OpenGFX+ Landscape - Revision 76:d638bb15a09d: Change: Nicer purchase list preview for company la... (planetmaker) @ http://dev.openttdcoop.org/projects/ogfx-landscape/repository/revisions/d638bb15a09d 20:00:37 <planetmaker> ^^ frosch123 :-) thanks 20:02:21 <andythenorth> is it just me devzone is timing out for? 20:02:35 <andythenorth> intermittently 20:02:47 <planetmaker> as in sometimes? 20:02:54 <andythenorth> yes 20:03:03 <andythenorth> like....right now 20:03:25 <planetmaker> works for me. But with intermittent errors... 20:03:52 <planetmaker> we had like 2 days ago the issue that something in the datacentre was subject to dDOS - which affected our availabiltiy, too 20:04:31 <andythenorth> I can't push 20:04:49 <andythenorth> hey go 20:04:54 <andythenorth> nvm 20:05:11 <andythenorth> I fixed a FIRS issue, but it can wait 20:05:29 <planetmaker> andythenorth: do you push to the correct address? 20:05:35 <planetmaker> like https or via ssh? 20:05:43 <andythenorth> I changed nothing recently 20:05:57 <andythenorth> I can't view devzone either 20:06:10 <planetmaker> that works for me 20:06:20 <planetmaker> quite fast today even 20:06:27 <Terkhen> I can open the devzone, but it has a lot of lag 20:06:28 <Terkhen> :P 20:06:35 <planetmaker> he 20:06:38 <planetmaker> strange 20:07:21 <andythenorth> I can view devzone root page, but not FIRS page 20:07:38 <andythenorth> is root page cached? 20:07:48 <planetmaker> http://bundles.openttdcoop.org/german-townnames/nightlies/ERROR/r34/german-townnames-r34-devzone.err.log <-- Ammler, invalid? 20:09:07 <Terkhen> http://paste.openttdcoop.org/show/420/ <-- this will need spritesets with duplicate sprites for industrytiles that use the same ground sprite for all versions 20:09:56 <Brot6> German town names - Bug #2939 (Rejected): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/2939 20:09:56 <Brot6> German town names - Bug #2939 (Rejected): DevZone compile failed (planetmaker) @ http://dev.openttdcoop.org/issues/2939#change-7363 20:10:23 <Terkhen> http://paste.openttdcoop.org/show/421/ <--- also, some spritelayouts have "extra" buildings... those will need a special template (with parameters for (x, y, z)(extent, offset) 20:10:58 <Terkhen> some industries have also zextent for the "real" building, that would need another parameter 20:11:05 <Brot6> OpenGFX+ Airports - Bug #2942 (Rejected): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/2942 20:11:05 <Brot6> OpenGFX+ Airports - Bug #2900 (Closed): DevZone compile failed (planetmaker) @ http://dev.openttdcoop.org/issues/2900#change-7364 20:11:05 <Brot6> OpenGFX+ Airports - Bug #2942 (Rejected): DevZone compile failed (planetmaker) @ http://dev.openttdcoop.org/issues/2942#change-7365 20:11:07 <Terkhen> this has a lot of cases :) 20:12:36 <planetmaker> Terkhen: sprite layouts with two buildings IMHO need no template 20:12:41 <planetmaker> they're special 20:12:53 <planetmaker> and probably all individually arranged 20:13:22 <andythenorth> if you're looking at FIRS, the 'special' cases are relatively common... 20:14:09 <planetmaker> hm, Terkhen, could we make the templates not in this macro form but as #include which uses some THIS_GROUND defines etc? 20:14:17 <planetmaker> it's much better debug-able and readable later 20:14:32 <planetmaker> (I know, I did that myself, but it's really ugly to read the generated NML) 20:15:04 <Terkhen> there are a lot of instances of "spritelayout with two buildings" 20:15:04 <planetmaker> thus in that case rely on THIS_GROUND and THIS_BUILDING being defined 20:15:16 <planetmaker> well, then make one for two buildings, too :-) 20:15:24 <Terkhen> I still have not checked a lot of files, but at least on the aluminium plant they seem even more common than normal ones 20:15:35 <planetmaker> ok ok :-) 20:15:52 <Terkhen> and that #define THIS_GROUND thing sounds a lot more confusing than parameters 20:16:13 <Terkhen> how does it improve readability? 20:16:41 <planetmaker> Terkhen: the macro as now will be expanded to one line. Very bad to read 20:16:49 <planetmaker> while an include keeps the structure 20:16:55 <planetmaker> as it doesn't use \ 20:17:00 <Terkhen> oh, you mean readability of the generated nml file 20:17:03 <planetmaker> yup 20:17:09 <planetmaker> which sometimes is very helpful :-) 20:17:09 <Terkhen> but at the cost of decreasing the readability of normal files :P 20:17:18 <planetmaker> I don't think that that is decreased 20:17:37 <planetmaker> #define THIS_GROUND GROUNDSPRITE_NORMAL 20:18:18 <planetmaker> #define THIS_BUILDING blubber 20:18:22 <Terkhen> http://paste.openttdcoop.org/show/422/ 20:18:29 <Terkhen> ^ that 20:18:30 <planetmaker> #include "path/to/template" 20:18:41 <Terkhen> hmm... I guess the include could do the undefs 20:18:44 <planetmaker> #undef is done in the one #undef which exists 20:18:48 <planetmaker> just add it there 20:18:57 <planetmaker> there's a special undef.pnml file 20:19:00 <planetmaker> in templates 20:19:08 <planetmaker> everything for one industry is undef'ed there 20:19:14 <Terkhen> hmm... 20:19:18 <planetmaker> unless it needs immediate undef, then in the template 20:19:29 <planetmaker> like for location checks... 20:19:34 <Terkhen> I'm going to use includes but for another reason: it will allow me to use conditional code in the template :P 20:19:43 <planetmaker> see :-) 20:19:51 <planetmaker> and... you can check for preconditions: 20:19:58 <planetmaker> #ifndef THIS_GROUND 20:20:06 <planetmaker> #error "You stupid fool! 20:20:07 <planetmaker> #endif 20:20:19 <Terkhen> but then... it would be better to create each template in its own file 20:20:26 <planetmaker> yes, of course 20:20:31 <planetmaker> no problem 20:20:33 <Terkhen> ok :) 20:20:54 <Terkhen> BTW, someone broke livestock 20:20:58 <Terkhen> no industry can accept it 20:21:21 <planetmaker> could have been me. I did many things... :-) 20:22:12 <Terkhen> I'm not going to check which revision caused the problem because on windows it would take an awful amount of time :P 20:22:18 <Terkhen> I probably should get a VM again 20:25:11 <Brot6> FIRS Industry Replacement Set - Bug #2944 (New): Livestock is not accepted by any industry (Terkhen) @ http://dev.openttdcoop.org/issues/2944 20:26:17 <andythenorth> Terkhen: I have a fix for that - if only I could push :P 20:26:27 <Terkhen> oh, ok :) 20:27:19 <Terkhen> change_production_level_primary looks awesome, I'll use that one as an example :P 20:28:08 <planetmaker> :-) 20:29:13 <planetmaker> Terkhen: checkout produce_secondary ;-) 20:30:03 <Terkhen> I already checked that one, but I did not notice it was on a separate file back then :P 20:30:10 <Terkhen> I just checked the switch blocks 20:30:57 <planetmaker> the produce_secondary only has one ;-) 20:31:12 <Terkhen> it looks like twenty or so :P 20:31:24 <planetmaker> :-D 20:32:37 <Terkhen> did you make any template with parameters already? 20:32:59 <Terkhen> I'd like to use the same format for the documentation if that's the case 20:33:14 <planetmaker> with parameters as THIS_XY? 20:33:54 <Terkhen> yes 20:33:59 <planetmaker> hm... I have to check whether I already commited the location code 20:34:23 <planetmaker> http://paste.openttdcoop.org/show/423/ 20:34:35 <planetmaker> I didn't... it's not yet done 20:34:59 <planetmaker> but it has not yet a good comment 20:35:06 <Terkhen> ok, I'll improvise then :P 20:35:27 <planetmaker> hm... the secondary production code uses lots of defines 20:35:36 <planetmaker> produce_secondary as such 20:36:20 <planetmaker> checkout templates/produce_secondary.pnml and undefs.pnml 20:36:55 <Terkhen> ok :) 20:37:04 <planetmaker> http://paste.openttdcoop.org/show/424/ 20:37:10 <planetmaker> ^ conflicting industry check 20:37:46 <planetmaker> but that needs to change... there can be more than 3 - thus I did not commit that 20:43:05 <planetmaker> andythenorth: where's actually your river sprites? 20:43:39 <andythenorth> somewhere on devzone iirc 20:43:49 <andythenorth> http://dev.openttdcoop.org/projects/water-features 20:44:57 <Terkhen> planetmaker: there is a problem with using undefs.pnml on my case 20:45:07 <Terkhen> I would need to call it multiple times, as each industry needs multiple spritelayouts 20:45:19 <planetmaker> Terkhen: yes, then #undef locally 20:47:20 <Terkhen> sprites/nml/industries/../templates/spritelayout_template.pnml:18:2: error: #error "SPRITELAYOUT_NAME has not been defined" <--- hmm... error messages regarding missing parameters are not very useful if it only displays the line on the template 20:48:22 <planetmaker> http://paste.openttdcoop.org/show/425/ 20:48:30 <planetmaker> uhm... you're unfortunately right 20:48:54 <planetmaker> but the same is actually similarily true when you have a 5000 character line with an error 20:49:01 <Terkhen> still better than nothing, yes :P 20:49:21 <Terkhen> and I'm going to make a single template 20:49:30 <Terkhen> depending on the parameters, it will include a different code 20:49:44 <planetmaker> :-) with #ifdef? 20:49:56 <Terkhen> yes 20:49:59 <planetmaker> nice :-) 20:49:59 <Terkhen> although... 20:50:10 <planetmaker> might be easier to use... maybe :-) 20:50:16 <Terkhen> for spritelayouts with an extra building, the code will look really ugly 20:50:30 <Terkhen> and using #ifdef might cause copypaste errors if you define too much / too less 20:50:43 <andythenorth> sometimes templates are a template too far :P 20:50:55 <Terkhen> it might be better to have different templates so they can check their parameters accordingly 20:52:43 <Terkhen> http://paste.openttdcoop.org/show/426/ <--- also, this is a huge mess too 20:52:47 <Terkhen> hmmm... not nice 20:53:39 <planetmaker> that's not really nice... I wonder whether it can be made nicer 20:53:59 <planetmaker> can one combine macros and include maybe nicely? 20:54:11 <Terkhen> probably not 20:54:30 <planetmaker> hm, did you check how NFO templates did it? 20:54:52 <Terkhen> yes, each industry has a huge file with all layout / relative_pos code 20:54:58 <planetmaker> :-) 20:55:05 <Terkhen> then it is included three times with a few parameters 20:55:18 <planetmaker> ok... 20:55:45 <planetmaker> but we could just define the few parameters and use them in the layout directly, right? 20:55:59 <planetmaker> After all... the layout itself is rather small 20:56:08 <planetmaker> but each value is custom to each layout 20:56:17 <planetmaker> with just a few variables like the ground 20:56:25 <Terkhen> depends on how do you want to template it 20:56:27 <planetmaker> so... write the layout in the industry file directly? 20:56:31 <planetmaker> without template really? 20:56:42 <Terkhen> I want to template each spritelayout separately, and place them all in the industry file 20:56:44 <planetmaker> after all an ASL is really a big template in itself 20:56:53 <Terkhen> nfo created a huge file with all code related to layouts and so on 20:57:01 <Terkhen> and included it three times, one for normal, another for desert, another for snow 20:57:09 <Terkhen> templates for each sprite layout require a lot of parameters 20:57:11 <planetmaker> Which now is one layout 20:57:21 <Terkhen> (x, y, z)(extent, offset) 20:57:24 <planetmaker> Yes. Maybe no template 20:57:38 <planetmaker> One layout per tile is enough 20:57:48 <planetmaker> With ASL you use the required parameters directly 20:58:02 <Terkhen> what's an ASL? :P 20:58:09 <planetmaker> advanced sprite layout ;-) 20:58:15 <Terkhen> ok 20:58:16 <planetmaker> i.e. what you write :-P 20:58:30 <planetmaker> sorry, I'm too lazy with my language obviously :-) 20:59:11 <Terkhen> the issue here is: it is not worth the effort to template industry tile layout code again because we now only need it once 20:59:21 <Terkhen> spritelayouts are also not triplicated now, but they have a lot of common code 20:59:26 <Terkhen> the conditions that check for snow, desert, etc 20:59:33 <planetmaker> yes. Then don't template it :-) 20:59:38 <planetmaker> Just write the layouts 20:59:52 <andythenorth> I was staying out of this because I don't understand the nml 21:00:07 <andythenorth> but I didn't like the tile templates in nfo 21:00:15 <andythenorth> it was necessary, but a bad pattern 21:00:23 <planetmaker> and skip sprite layout templating. It might be "the template too much" indeed 21:00:25 <andythenorth> ASL renders them unnecessary 21:00:47 <Terkhen> yes, the template would be for the ASL themselves :P 21:00:54 <Terkhen> check for example the beginning of aluminium_plant.pnml 21:01:03 <Terkhen> you will see a huge amount of almost identical sprite layouts 21:01:08 <planetmaker> 22:52 Terkhen: http://paste.openttdcoop.org/show/426/ <--- also, this is a huge mess too <-- this is no template really anymore. It's as long as the original code 21:01:22 <Terkhen> yes, but with normal macros it would be a one liner :P 21:01:42 <planetmaker> well. Then try the macro approach :-) 21:01:47 <planetmaker> We already use both 21:02:11 <Terkhen> back to the aluminium_plant.pnml file: after the identical sprite layouts we get a lot of sprite layouts with an extra building (I'm guessing it is the smoke) 21:02:13 <planetmaker> But don't make the hidden code too long. Then it gets very ugly to parse 21:02:21 <Terkhen> those are the problematic ones 21:02:39 <Terkhen> hmm... ok, I know how I'm going to do it :) 21:02:47 <planetmaker> how? :-) 21:03:54 <Terkhen> http://paste.openttdcoop.org/show/427/ <--- hmm..., probably the "missing" { makes it looks very wrong 21:04:48 <Terkhen> http://paste.openttdcoop.org/show/428/ <--- IIRC I did something like this in ogfx-industries 21:05:04 <Terkhen> where MACRO_END is just the missing } 21:05:24 *** frosch123 has quit IRC 21:05:41 * planetmaker checks out that code 21:06:07 <andythenorth> bye 21:06:10 *** andythenorth has quit IRC 21:06:16 <Terkhen> I don't see anything like this on ogfx-industries, so I probably did it differently 21:07:45 * planetmaker doesn't see that there either 21:08:30 <Terkhen> well, if we allow to write custom stuff inside the macro itself, then you can add whatever you want to it and still be able to template the code for snow/desert/normal 21:08:47 <Terkhen> it just looks... wrong :) 21:16:54 <planetmaker> does the code with MACRO(...) normal bla MACRO_END() work that way? 21:17:00 <planetmaker> It's a syntax I don't yet know :-) 21:26:00 <Terkhen> it's just two macros 21:27:03 <Terkhen> http://paste.openttdcoop.org/show/429/ 21:31:30 <planetmaker> ah, yes, I've seen that somewhen from you. Sounds like a good solution to this case 21:32:20 <planetmaker> but... the 1st building sprite, shouldn't it already have varying sprites, xoffsets etc? 21:32:34 <planetmaker> but possibly there's a HUGE number of cases where it has not? 21:36:02 <Terkhen> in all the cases I have seen, the first building sprite only uses zextent 21:36:12 <Terkhen> I'll need to check that better though :) 21:36:44 <Terkhen> I'm afraid of creating a template, start using it, and later realize that it is not good for some cases :P 21:43:06 <planetmaker> there's no catch-all template for tile layouts 21:44:39 <Terkhen> tile layouts or sprite layouts? 21:45:15 <Terkhen> I wasn't planning on templating industry tile layouts at all 21:49:36 <planetmaker> uhm... tile 21:50:01 <planetmaker> ach... no. sorry, I'm too tired :-) 21:50:08 <planetmaker> the one we talked about 21:50:33 <planetmaker> which is spritelayout 21:50:55 <planetmaker> and I should go to bed before I really start talking non-sense ;-) 21:54:04 <Terkhen> me too :P 21:54:06 <Terkhen> good night 21:54:39 <planetmaker> good night indeed :-) 22:10:39 *** FooBar has quit IRC