Log for #openttdcoop.devzone on 29th July 2011:
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) @
06:39:55  <Brot6> FIRS Industry Replacement Set - Revision 2199:3d5b2860e388: Codechange: Give better names to the ... (planetmaker) @
07:11:58  <Brot6> FIRS Industry Replacement Set - Revision 2200:65ef1b08bb14: Codechange: Re-align strings in langu... (planetmaker) @
07:24:35  <Terkhen> Hirundo: <--- this should be ready now
07:33:30  <Brot6> FIRS Industry Replacement Set - Revision 2201:bdf6d5cfc2b9: Codechange: Use production template f... (planetmaker) @
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> <--- 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) @
07:56:56  <Brot6> FIRS Industry Replacement Set - Revision 2202:2aa3a7ed2777: Codechange: Use the same template nam... (planetmaker) @
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> <--- 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) @
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) @
10:10:19  <Brot6> NewGRF Meta Language - Revision 1559:35764c039fe2: Fix: Some small fixes to the documentation. (Hirundo) @
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> <--- actually it is not mentioned explicitly, I'll add a note
10:57:33  <Webster> Title: Storages - GRFSpecs (at
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> <-- 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) @
11:26:49  <Brot6> DevZone Help Center - Membership #2897 (Closed): Applying for project: Japanese town names & US M... (Ammler) @
11:27:02  <Ammler> <-- 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) @
11:40:29  <Brot6> NewGRF Meta Language - Feature #1031: support for houses (Hirundo) @
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> <-- 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> <-- 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>
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) @
13:26:34  <Brot6> Central European Train Set - Revision 98:2a7c64c3ca14: offset correction for 12lu template (Eddi) @
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) @
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) @
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) @
14:08:18  <Brot6> Central European Train Set - Revision 102:677139740868: add availability define for kkStB (Eddi) @
14:08:18  <Brot6> Central European Train Set - Revision 103:186c4d4c1cd0: add missing tender (Eddi) @
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) @
14:15:11  <Brot6> FIRS Industry Replacement Set - Revision 2204:96b39155a20e: Codechange: Rename the THIS_ID templa... (planetmaker) @
14:15:11  <Brot6> FIRS Industry Replacement Set - Revision 2206:1a5975b8ae9f: Add: Template for showing extra text ... (planetmaker) @
14:15:13  <Brot6> FIRS Industry Replacement Set - Revision 2207:2973c8b1f8dc: Codechange: Apply production and extr... (planetmaker) @
14:29:58  <Brot6> FIRS Industry Replacement Set - Revision 2208:42812a82d498: Codechange: Apply production and extr... (planetmaker) @
14:35:48  <Brot6> FIRS Industry Replacement Set - Revision 2209:38135d7541be: Codechange: Apply production and extr... (planetmaker) @
15:04:55  <Brot6> DictatorAI - Revision 118:4cdc64308db1: - Still terraforming work (krinn) @
16:26:56  <Brot6> FIRS Industry Replacement Set - Revision 2210:814b975971d1: Codechange: Apply production and extr... (planetmaker) @
16:34:41  <Brot6> FIRS Industry Replacement Set - Revision 2211:2abdeae71e70: Codechange: Apply production and extr... (planetmaker) @
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) @
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) @
17:10:13  <Brot6> nml: update from r1556 to r1559 done -
17:12:08  <Brot6> firs: update from r2194 to r2213 done (37 warnings) -
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) -
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) -
17:24:16  <Brot6> sub-landscape: compile of r72 still failed (#2892) -
17:25:25  *** frosch123 has joined #openttdcoop.devzone
17:27:03  <Brot6> dutchtramset: compile of r84 still failed (#2899) -
17:38:47  <Brot6> airportsplus: rebuild of r107 done (2 warnings) (Diffsize: 30186) (DiffDiffsize: 33481) -
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: <-- 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) @
18:24:36  <Brot6> Central European Train Set - Revision 105:bc93ce270d28: switch 10lu wagons from 4+4+2 to 4+6 (Eddi) @
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) -
19:10:46  <Brot6> openttd-vehiclevars: update from r22691 to r22692 done -
19:12:02  <FooBar> What does this mean: /nmlc: Real sprite parameters should be compile-time constants./ ?
19:12:02  <FooBar> with this code:
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) -
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) -
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:
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) @
19:29:22  <Brot6> FooBar's Tram Tracks - Revision 1:6f132ede3290: Add: initial code and graphics and license file (foobar) @
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) @
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) @
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) @
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) @
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

Powered by YARRSTE version: svn-trunk