Log for #openttdcoop.devzone on 7th August 2011:
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) @
07:12:06  *** frosch123 has joined #openttdcoop.devzone
07:14:42  <Brot6> DictatorAI - Revision 130:16bfd8df4e40: - correct bugs (krinn) @
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) @
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) @
10:46:53  <Brot6> HEQS "Heavy Equipment" Set - Revision 637:83210cdeb4da: Fix: Railmotor using wrong smoke type (andythenorth) @
10:46:54  <Brot6> HEQS "Heavy Equipment" Set - Revision 638:0abf1a424ae8: Change: corrected some comments about s... (andythenorth) @
10:49:37  *** Guest5013 has quit IRC
10:57:56  <Brot6> OpenGFX - Revision 710:5b8e74807f4d: Change: reorder sprites/source files in directories (foobar) @
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) @
11:51:36  <Brot6> OpenGFX - Revision 712:46ea6e557122: Codechange: reorder sprites/png gui files in gui directory (foobar) @
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) @
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) @
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) @
12:19:00  <Brot6> Swedish Rails - Revision 205:3063a8262a0d: Fix: Use bitmask() for railtype_flags, also set the ca... (Hirundo) @
12:27:43  <Brot6> OpenGFX - Revision 715:fa4a5e5a70ce: Cleanup: make sprites/png/gui/medfont.png obsolete and remov... (foobar) @
12:32:12  <FooBar> #1959
12:32:12  <Brot6> FooBar: #1959 is "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) @
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) @
13:14:26  <Brot6> OpenGFX - Revision 717:fadbed63ece6: Fix #2576: new forest ground tile shows holes where trees us... (foobar) @
13:16:19  *** andythenorth has joined #openttdcoop.devzone
13:41:01  <Brot6> OpenGFX - Code Review #2119 (Closed): New Sprites for Guru X2 Helicopter (foobar) @
13:41:01  <Brot6> OpenGFX - Revision 718:ce570ce6c90c: Feature (closes #2119): revised GuruX2 helicopter (DanMacK) (foobar) @
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) @
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) @
14:06:01  <Brot6> OpenGFX - Revision 719:17daf2da5835: Feature (closes #2573): show outline of arctic church on gro... (foobar) @
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) @
14:40:42  <Brot6> NewGRF Meta Language - Revision 1580:f772adcba46f: Add: Railtype example. (Hirundo) @
15:39:54  <Brot6> FIRS Industry Replacement Set - Feature #2937 (New): Consider supporting YACD explicitly (andythenorth) @
16:09:54  <Brot6> FIRS Industry Replacement Set - Bug #2938 (Confirmed): Stockyard accepts FMSP instead of LVST (andythenorth) @
16:17:59  *** bodis has quit IRC
16:27:33  <Brot6> FIRS Industry Replacement Set - Revision 2236:5c09ca790cbb: -Codechange: Make prospect_chance mor... (Terkhen) @
16:31:44  <Brot6> Central European Train Set - Feature #2763: track classes / railtype support (Eddi) @
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>
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 -
17:15:39  *** andythenorth has quit IRC
17:18:15  <Brot6> ogfx-trains: update from r246 to r248 done -
17:20:19  <Brot6> firs: update from r2233 to r2236 done (37 warnings) -
17:22:04  <Brot6> opengfx: update from r708 to r719 done -
17:23:29  <Brot6> heqs: update from r636 to r638 done -
17:25:04  <Brot6> swedishrails: update from r204 to r205 done -
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) -
17:41:59  *** Sylf has quit IRC
17:42:46  <Brot6> German town names - Bug #2939 (New): DevZone compile failed (compiler) @
17:42:46  <Brot6> Belarusian Town Names - Bug #2940 (New): DevZone compile failed (compiler) @
17:43:34  <Brot6> Indonesian Town Names - Bug #2941 (New): DevZone compile failed (compiler) @
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) @
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) @
17:59:26  <Brot6> Belarusian Town Names - Bug #2940 (Rejected): DevZone compile failed (Ammler) @
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) @
18:12:19  * Hirundo checks code
18:13:07  <frosch123> <- 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) @
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) @
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) -
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 -
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) -
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) -
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) @
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> <--- 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) @
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: <- 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) @
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> <-- Ammler, invalid?
20:09:07  <Terkhen> <-- 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) @
20:09:56  <Brot6> German town names - Bug #2939 (Rejected): DevZone compile failed (planetmaker) @
20:10:23  <Terkhen> <--- 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) @
20:11:05  <Brot6> OpenGFX+ Airports - Bug #2900 (Closed): DevZone compile failed (planetmaker) @
20:11:05  <Brot6> OpenGFX+ Airports - Bug #2942 (Rejected): DevZone compile failed (planetmaker) @
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>
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) @
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>
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>
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>
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>
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> <--- 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: <--- 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> <--- hmm..., probably the "missing" { makes it looks very wrong
21:04:48  <Terkhen> <--- 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>
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

Powered by YARRSTE version: svn-trunk