Log for #openttdcoop.devzone on 22nd June 2011:
Times are UTC Toggle Colours
00:28:59  <Brot6> nml: [nightlies] openSUSE API (osc) not reachable, sleep an hour and try again...
00:29:16  <Brot6> feed NewGRFs had 12 updates, showing the latest 10
00:29:16  <Brot6> Central European Train Set - Feature #2763: track classes / railtype support (michi_cc) @
00:29:16  <Brot6> Central European Train Set - Revision 1:609b5096ffdf: Add: Dummy engine for testing purposes, alo... (planetmaker) @
00:29:16  <Brot6> Central European Train Set - Revision 2:7724ea8c41ea: Add: Support for compile farm (planetmaker) @
00:29:19  <Brot6> Central European Train Set - Revision 3:ba623d6444e8: add **~ to .hgignore (Eddi) @
00:29:22  <Brot6> Central European Train Set - Revision 4:1723668d602c: add 32px vehicles and depot offset (Eddi) @
00:29:26  <Brot6> French Town Names - Bug #2565 (Closed): DevZone compile failed (Ammler) @
00:29:29  <Brot6> FIRS Industry Replacement Set - Revision 2082:aa0e1d601055: Added tag 0.6.5-beta1 for changeset c... (yexo) @
00:29:33  <Brot6> FIRS Industry Replacement Set - Revision 2083:bd9cf8bdc5a7: Fix: fix version in grf name (yexo) @
00:29:39  <Brot6> FIRS Industry Replacement Set - Revision 2084:194a7d3e5f79: Cleanup: remove special .spec file an... (yexo) @
00:29:43  <Brot6> FIRS Industry Replacement Set - Revision 2085:206e787bc851: Added tag 0.6.5-beta2 for changeset 1... (yexo) @
00:29:47  <Brot6> NewGRF Meta Language - Revision 1431:50253e37650e: Cleanup: Remove the possibility to define real... (Hirundo) @
04:53:36  *** bodis has joined #openttdcoop.devzone
05:39:00  *** bodis has quit IRC
05:56:25  *** andythenorth has joined #openttdcoop.devzone
06:04:31  *** andythenorth has quit IRC
06:16:28  *** andythenorth has joined #openttdcoop.devzone
06:20:02  *** andythenorth has quit IRC
07:08:58  <Brot6> Central European Train Set - Support #2784 (New): graphics template (planetmaker) @
07:12:24  <Brot6> Central European Train Set - Support #2784 (New): graphics template (planetmaker) @
07:57:49  <Yexo> thanks Ammler for fixing the firs build :)
08:00:03  *** JVassie has joined #openttdcoop.devzone
09:56:38  <Brot6> Central European Train Set - Support #2784: graphics template (Eddi) @
11:23:51  <Ammler> Yexo: I had to revert the "fix", need to rething again
11:24:05  <Ammler> maybe I will do a devzone 1.5
11:24:38  <Ammler> (cleanup the current script)
11:27:35  <Brot6> NewGRF Meta Language - Revision 1437:ab8b0d19adac: Fix: track spriteset labels properly throughou... (yexo) @
11:27:35  <Brot6> NewGRF Meta Language - Revision 1438:e8ebbf41815e: Fix/Feature: support ASL bits 1/2 (yexo) @
11:29:28  <Brot6> NewGRF Meta Language - Feature #2739 (Closed): Advanced sprite layouts (yexo) @
13:04:47  <Brot6> NewGRF Meta Language - Bug #2785 (New): problem with spritelayout parameters (yexo) @
13:05:01  <Yexo> Hirundo / planetmaker: I'd like your input on #2785
13:05:01  <Brot6> Yexo: #2785 is "NewGRF Meta Language - Bug #2785: problem with spritelayout parameters - #openttdcoop Development Zone"
13:10:09  <Brot6> NewGRF Meta Language - Bug #2785: problem with spritelayout parameters (Hirundo) @
13:11:38  <Yexo> Hirundo: 20 for both?
13:12:59  <Yexo> an alternative way is to avoid the issue and only allow constant numbers and spriteset references as parameters
13:17:46  <Hirundo> It is implemented via ASL bits 1/2, right?
13:18:04  <Yexo> depends on what the parameters are used for
13:18:50  <Yexo> spritelayout my_layout(a) { ground {sprite 3; hide_sprite: a; } } <- that would requite ASL bit 0 for example
13:19:10  <Hirundo> Yexo: I added some clarification
13:19:10  <Yexo> and most likely a duplication "my_layout' in the final grf for each different set of parameters
13:19:14  <Brot6> NewGRF Meta Language - Bug #2785: problem with spritelayout parameters (Hirundo) @
13:19:31  <Hirundo> I think, parameters should be evaluated and put in a register at the switch block
13:19:59  <Hirundo> So the passed parameter is always a (computed) constant, not an expression
13:21:18  <Hirundo> So passing parameters for stuff that has to be a constant (recolour_mode, always_draw, x/y/zextent) is not possible, but that's not a big loss IMO
13:21:20  <Yexo> that would make it a register, not a constant
13:21:31  <Hirundo> That's what ASL is for, right?
13:22:15  <Yexo> yes
13:22:56  <Yexo> this will be tricky for stations though
13:23:10  <Yexo> since the spritelayout is put in the action0, the groundsprite might end up having value 20 instead of 10
13:24:27  <Hirundo> That'd need temporary parameters
13:24:50  <Yexo> which in turn needs detecting when parameters are changed
13:25:04  <Yexo> and probably disallowing param[x] where x is not a constant number
13:26:18  <Hirundo> Can't we always allocate a temp parameter, or would that use too many?
13:27:22  <Yexo> would easily use too many
13:31:29  <Hirundo> I'm not opposed to disallowing param[x!= constant], it's nice to have, but not that useful and a burden to support
13:31:56  <Yexo> disallowing that for writing only would already make things a lot easier I think
13:32:04  <Yexo> for reading we don't care, that's the problem of the user
13:33:04  <Hirundo> If you can't write it, then what's the use?
13:33:46  <Yexo> param[0] = a; param[1] = b; param[2] = c; something = param[d];, where d is non-constant
13:34:37  <Yexo> not sure if that's an actual use case though
13:35:57  <Yexo> yesterday you said something about reviewing which blocks could be skipped / looped
13:36:06  <Yexo> are any projects using a loop at all?
13:36:14  <Yexo> I think we might want to disallow looping completely
13:36:24  <Yexo> there are too many ways things can break with a loop
13:37:25  <Hirundo> It might be useful in some cases
13:37:46  <Yexo> true, but are those important enough to accept all other cases were it breaks things?
13:38:01  <Hirundo> such as?
13:39:23  <Yexo> not sure exactly, but the parameter handling inside a loop is far from ideal
13:39:37  <Yexo> not sure exactly, but the parameter handling inside a loop is far from ideal
13:48:46  <Brot6> NewGRF Meta Language - Bug #2785: problem with spritelayout parameters (planetmaker) @
13:49:05  *** ODM has joined #openttdcoop.devzone
13:56:34  <Brot6> NewGRF Meta Language - Revision 1439:6faeeb30e5ba: Fix: raise a proper error when using spriteset... (yexo) @
13:56:34  <Brot6> NewGRF Meta Language - Revision 1440:aabf03a714a4: Change: if LOAD_TEMP(x) with x=ConstantNumeric... (yexo) @
13:58:04  <Yexo> I'm thinking of making SpritegroupRef an Expression (and as such resolving it as such)
13:58:15  <Yexo> I think that'd make a lot of code easier that now has special cases for it
13:59:37  <planetmaker> if it adds to readability - sure :-)
14:14:55  <Hirundo> Yexo: That was in my mid-long term plans already
14:15:05  <Yexo> ok, great :)
14:17:36  <Brot6> NewGRF Meta Language - Revision 1441:eb7c31efed21: Codechange: simplify the TempRegister code a bit (yexo) @
14:21:59  <Hirundo> Currently I'm working on getting a basic, common structure (base classes) for statements and statement lists
14:22:11  <Yexo> ok, good :)
14:22:32  <Yexo> I'm trying to simplify the varaction2 code a bit
14:22:54  <Yexo> first by changing the type of members of VarAction2Var from ConstantNumeric to int
14:24:32  <Hirundo> Currently stuff like this "works", because only the order of processing is considered:
14:24:56  <Yexo> yes, indeed
14:25:22  <Hirundo> I would want to add a concept of semantic (not lexical) position
14:26:13  <Yexo> This will be a lot harder to detect
14:26:42  <Yexo> and that is exactly the problem we'll face with #2766 I think
14:26:43  <Brot6> Yexo: #2766 is "NewGRF Meta Language - Feature Request #2766: Option to define town names conditionally - #openttdcoop Development Zone"
14:26:44  <Hirundo> I've been thinking about that
14:27:38  <Hirundo> One solution would be to adopt c-style scoping, so x is not defined in the outer (main) scope unless you declare it there
14:28:51  <Yexo> I think that's a good idea
14:44:42  <Brot6> NewGRF Meta Language - Revision 1442:4833d1bd671c: Codechange: use int instead of ConstantNumeric... (yexo) @
15:30:49  *** Lakie has joined #openttdcoop.devzone
16:02:25  <Hirundo> incoming...
16:02:52  <Brot6> feed grftools had 11 updates, showing the latest 10
16:02:52  <Brot6> NewGRF Meta Language - Revision 1444:b86d0b59c3cc: Codechange: Make graphics block position info ... (Hirundo) @
16:02:52  <Brot6> NewGRF Meta Language - Revision 1445:e6c8e54d5e30: Add: Base classes for statements and statement... (Hirundo) @
16:02:52  <Brot6> NewGRF Meta Language - Revision 1448:0206add6d646: Codechange: Validate the block structure as pa... (Hirundo) @
16:02:58  <Brot6> NewGRF Meta Language - Revision 1447:a8bf38d4a5b5: Codechange: Make the main AST node also a Base... (Hirundo) @
16:03:02  <Brot6> NewGRF Meta Language - Revision 1446:17ce0dc7ab5d: Codechange: Let all statements in the AST inhe... (Hirundo) @
16:03:06  <Brot6> NewGRF Meta Language - Revision 1449:858e13de118d: Cleanup: Remove the distinction between skipab... (Hirundo) @
16:03:10  <Brot6> NewGRF Meta Language - Revision 1451:faa13f8b5680: Cleanup: Remove general.print_script as it's n... (Hirundo) @
16:03:14  <Brot6> NewGRF Meta Language - Revision 1450:4adb26ccbdb8: Cleanup: Remove unused function validate_item_... (Hirundo) @
16:03:18  <Brot6> NewGRF Meta Language - Revision 1452:9cc1ac810e2b: Change: Make the grf-block non-skipable. (Hirundo) @
16:03:22  <Brot6> NewGRF Meta Language - Revision 1453:b0e50c5bf52b: Cleanup: remove unneeded (empty) declarations ... (Hirundo) @
16:11:43  <planetmaker> regression test successful ;-)
16:14:31  <Yexo> is it me or is nml now significantly slower?
16:18:31  <planetmaker> 18.129s vs. 17.501s on OpenGFX+Trains here
16:18:38  <planetmaker> (user)
16:18:40  <Yexo> so it was me
16:18:43  <Brot6> NewGRF Meta Language - Revision 1454:77e8ad47f04e: Feature: allow multiple values for each entry ... (yexo) @
16:19:05  <Ammler> Yexo: maybe different -j behavior?
16:19:11  <Yexo> no, I don't know
16:19:20  <Yexo> it's now approximately as fast as it was before
16:23:21  <planetmaker> @calc 18.129/17.501
16:23:21  <Webster> planetmaker: 1.03588366379
16:23:43  <planetmaker> @calc 38.662/37.878
16:23:43  <Webster> planetmaker: 1.02069803052
16:23:51  <planetmaker> consistently about 3% :-)
16:24:11  <planetmaker> the latter being ogfx+airports
16:27:30  <planetmaker> or not. Swedishrails got faster ;-)
16:27:46  <planetmaker> @calc 24.170/25.214
16:27:46  <Webster> planetmaker: 0.958594431665
16:32:14  <Yexo> very nice work Hirundo!
16:35:51  *** bodis has joined #openttdcoop.devzone
16:51:36  <Brot6> NewGRF Meta Language - Revision 1455:53385865a22f: Doc: new railtypetable syntax (yexo) @
16:52:16  <planetmaker> ho ho :-)
16:52:54  <Yexo> it's not tested that well (actually only by looking at the resulting nfo output) :p
16:53:05  <planetmaker> be sure I'll test it :-P
16:53:32  <planetmaker> hm... proper English probably is "rest assured that I'll test it"
16:55:06  <planetmaker> Yexo, s/than/then/ ;-)
16:55:20  <planetmaker> if then else. Earlier than
16:55:23  <Yexo> hmm?
16:55:38  <Yexo> ah
16:56:01  <planetmaker> seems to be your weak point these two words ;-)
16:56:28  <Yexo> yes
16:57:05  <Yexo> I know which I should use, however I have to consciously think about it to get it right
16:57:13  <Yexo> on autopilot it often goes wrong
16:57:20  <Brot6> NewGRF Meta Language - Revision 1456:163901baf49c: Doc: than->then (planetmaker) (yexo) @
17:10:14  <Brot6> nml: update from r2081
17:10:14  <Brot6> r1436 to r1456 done -
17:20:20  <Brot6> nml: update from r2081
17:20:20  <Brot6> r1456 to r1456 done -
17:20:31  <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r750), 32bpp-extra (r40), ai-admiralai (r75), ai-aroai (r39), ailib-common (r21), ailib-direction (r17), ailib-list (r32), ailib-string (r29), ailib-tile (r16), airportsplus (ERROR r105), basecosts (r25), belarusiantowns (r8), bros (r52), cets (r4), chips (r143), comic-houses (r71), firs (r2081), firs.nml (r2081), fish (r653), frenchtowns (r6), german-townnames (r34), grfcodec
17:20:31  <Brot6> (r832), grfpack (r279), heqs (r605), indonesiantowns (r41), manindu (r7), metrotrackset (r56), narvs (r37), newgrf_makefile (r296), nutracks (r202), ogfx-industries (ERROR r120), ogfx-landscape (ERROR r70), ogfx-rv (r107), ogfx-trains (r245), ogfx-trees (r50), opengfx (r678), openmsx (r97), opensfx (r97), smts (r19), snowlinemod (r49), spanishtowns (r10), sub-landscape (ERROR r66), sub-opengfx (ERROR r666), swedishrails (r202),
17:20:33  <Brot6> swisstowns (r22), transrapidtrackset (r15), ttdviewer (r34), ttrs (r36), worldairlinersset (r672)
17:20:51  <Brot6> airportsplus: compile of r105 still failed (#2768) -
17:21:08  <Brot6> belarusiantowns: compile of r8 still failed (#2769) -
17:21:23  <Brot6> cets: compile of r4 still failed (#2770) -
17:22:05  <Brot6> firs.nml: compile of r2081 failed -
17:22:14  <Brot6> FIRS Industry Replacement Set - Bug #2786 (New): DevZone compile failed (compiler) @
17:22:17  <Brot6> frenchtowns: compile of r6 still failed (#2771) -
17:22:29  <Brot6> german-townnames: compile of r34 still failed (#2772) -
17:22:30  <planetmaker> uhm... hm.
17:22:37  <planetmaker> that doesn't look right
17:22:44  <Brot6> indonesiantowns: compile of r41 still failed (#2773) -
17:22:57  <Brot6> manindu: compile of r7 still failed (#2774) -
17:23:12  <Brot6> narvs: compile of r37 still failed (#2775) -
17:23:24  <Brot6> newgrf_makefile: compile of r296 still failed (#2776) -
17:23:40  <Brot6> ogfx-industries: compile of r120 still failed (#2777) -
17:23:53  <Brot6> ogfx-landscape: compile of r70 still failed (#2778) -
17:24:05  <Brot6> ogfx-rv: compile of r107 still failed (#2779) -
17:24:18  <Brot6> ogfx-trains: compile of r245 still failed (#2780) -
17:24:38  <Brot6> spanishtowns: compile of r10 still failed (#2781) -
17:24:51  <Brot6> sub-landscape: compile of r66 still failed (#2616) -
17:25:48  <Brot6> sub-opengfx: compile of r666 still failed (#2586) -
17:25:56  <planetmaker> :-(
17:25:59  <Brot6> swedishrails: compile of r202 still failed (#2782) -
17:26:12  <Brot6> swisstowns: compile of r22 still failed (#2783) -
17:26:29  <planetmaker> Ammler, ^^
17:26:35  <planetmaker> all that is a CF failure
17:26:53  <planetmaker> r1456/rpms is not a valid repository, use one of: CentOS_5, Debian_6.0, Fedora_14, Fedora_15, Mandriva_2010, Mandriva_2010.1, openSUSE_11.3, openSUSE_11.4, openSUSE_Factory, openSUSE_Tumbleweed, RedHat_RHEL-6, RHEL_5, SLE_10_SDK, SLE_11, SLE_11_SP1, xUbuntu_11.04
17:27:24  <Ammler> no that are "Ammler is trying to add special wishes for you" failures :-P
17:27:42  <planetmaker> :-D
17:27:44  <Ammler> I guess, I already deleted the tickets
17:27:58  <planetmaker> ponies! More ponies! A whole pony breed!
17:28:24  <Ammler> something went wrong with the revert it seems
17:31:05  *** frosch123 has joined #openttdcoop.devzone
19:01:48  *** andythenorth has joined #openttdcoop.devzone
20:08:51  <Brot6> FIRS Industry Replacement Set - Bug #2786 (Rejected): DevZone compile failed (compiler) @
20:08:51  <Brot6> FIRS Industry Replacement Set - Bug #2786 (Rejected): DevZone compile failed (andythenorth) @
20:28:48  <Brot6> FIRS Industry Replacement Set - Revision 2086:efc0c3cf9043: Feature: enhanced snow support (greeb... (andythenorth) @
20:28:49  <Brot6> FIRS Industry Replacement Set - Feature #2757 (Closed): Forest greeble tile needs snow graphics (andythenorth) @
20:30:27  <Brot6> firs: update from r2081 to r2086 done -
20:53:54  <Lakie> planetmaker: if I was to define a value like "#define FOO 257", could I later use things like "#if FOO < 255 ... #else ... #endif"?
20:57:57  <planetmaker> I'm not sure, IIRC it's not treated as value
20:58:05  <planetmaker> but as string
20:58:09  <planetmaker> but I might err
20:58:21  <Lakie> I've not tried unfortunetly.
20:58:31  <Lakie> And preprocessing isn't my strong point
21:00:06  <Brot6> FIRS Industry Replacement Set - Revision 2087:a62875cb45f7: Feature: snow graphics for Forge (clo... (andythenorth) @
21:00:06  <Brot6> FIRS Industry Replacement Set - Feature #1791 (Closed): Forge needs snow graphics (andythenorth) @
21:00:50  <Lakie> Still thinking I'd like to also see thw \<size>(<rpn>) implemented in renum. ;)
21:01:44  <Lakie> Ah well, I'll have a play with it locally, hopefully I'l put something onto the online system soon. :)
21:02:55  <planetmaker> the make manual doesn't give any hint that defines are treated as numerics
21:03:42  <Lakie> Ok, I was thinking such things would be more important to how gcc treats them
21:04:28  <planetmaker> hm, you can of course use it in the C code... but that's not what you want?
21:04:40  <Lakie> I was hoping to write this.
21:05:31  <Lakie> #if YEAR < 1920, 00  setyear(w, YEAR),#else, 00 \w0, #endif.
21:05:38  <Lakie> Or something to the equivlent
21:06:44  <Lakie> setyear being _setyear(w, YEAR), leading to \ ## <size> ## <year> ## -01-01
21:06:58  <Lakie> Which should in theory come out right
21:10:07  <Yexo> Lakie: defines are treated like integers, so things like that are possible
21:10:21  <Lakie> Cool, thanks. :)
21:11:59  <planetmaker> hm... ok :-)
21:14:08  <Yexo> planetmaker: openttd uses that too for things as compiler versions
21:14:11  <Yexo> see stdafx.h
21:14:36  <planetmaker> hm... right :-)
21:19:12  *** andythenorth has left #openttdcoop.devzone
21:24:59  <Yexo> <Lakie> Still thinking I'd like to also see thw \<size>(<rpn>) implemented in renum. ;) <- I'd like that too :)
21:25:38  <Lakie> Well, I implemented it locally but never got the OK for actually pushing it...
21:25:49  <Yexo> why not?
21:25:51  <Yexo> who stopped you?
21:26:07  <Lakie> Hense my plans for \w(0x8000 VEH_ID +) work here
21:26:22  <Lakie> Never got a reply, but I accept people are busy
21:26:51  <Yexo> if it works you can go ahead and push it
21:27:21  <Lakie> I'll probably make a ticket for it, that way it cn be vetted properly, I wouldn't want to break renum
21:27:38  <Yexo> that's also good :)
21:28:29  <Lakie> Adding it to both was too much work, so it basically just rewrote the \<size>(<rpn>) yo \<size><result>
21:28:39  <Yexo> it's a feature I've been thinking about a long time, just never bothered to implement it since with NML I don't use renum that often
21:28:50  <Lakie> Which it good for the current processing, similar to the let vqriables
21:29:06  <Yexo> never used those "let variables"
21:29:11  <Yexo> but imo that's fine
21:29:12  <Lakie> Heh, yeah, renum does a lot of nice things like that for you
21:29:17  <Lakie> nml*
21:29:30  <Lakie> They are for use in rpn's primarily
21:30:15  <Lakie> /@@LET <var> = <val>|(<rpn>), then later either in a sprite line <var> or (<rpn using var>) instead of a number
21:30:43  <Yexo> the big limitation is that it only works in sprite lines
21:30:45  <Yexo> not in any actions
21:30:59  <Lakie> Well, that was what I planned to alter...
21:31:20  <Yexo> yes :)
21:31:20  <Lakie> though it'd be \<size>(<var>) due to simplicities
21:33:19  <Yexo> I thought of exactly the same syntax
21:33:26  <Lakie> Hopefully I'll get this all worked out so it doesn't just continously error when I finally get round to setting up the repot on devzone...
21:33:41  <Lakie> repo*
21:34:05  <Yexo> all nfo projects on the devzone are recompiled when there is a new nforenum nightly, so you have a lot of testcases
21:34:45  <Lakie> Well, in theory, unless they use let or that particular syntax, I don't think they'll be harmed
21:35:03  <Yexo> that's what the testing is for, to make sure they're not
21:37:26  * Lakie kind of wishes nml's templates existed for nfo, and that sprite authors wouldn't break from the templates...
21:37:51  <Yexo> the sprite templates are something you can easily emulate by including files
21:37:56  <Yexo> where each included file holds one template
21:38:18  <Yexo> sprite authors adhering to templates is just something you have to be very clear about when you start coding a set
21:38:54  <Lakie> Well, most of the sprites have been around for a long time.
21:39:17  <Lakie> I think templates with some rpn's might work for the small adjustments, maybe
21:40:04  *** ODM has quit IRC
21:41:00  <Yexo> did you see btw?
21:41:50  <Brot6> OpenGFX - Bug #2787 (New): Graphical bug in OpenGFX company headquarters (nivlac) @
21:42:06  <Lakie> No?
21:43:13  <Yexo> it's a proposal by frosch for a new action1 format
21:43:24  <Yexo> to allow accessing not only the last action1 but also the ones before that
21:45:17  <Lakie> I see, it could be quite useful.
21:46:12  <Yexo> is that feasible to support in ttdpatch at all?
21:47:52  <Brot6> OpenGFX - Bug #2787: Graphical bug in OpenGFX company headquarters (nivlac) @
21:48:26  <Lakie> You'd have to ask Oskar, no-one knows the TTDPatch sprite system like him, sorry.
21:49:04  <Yexo> np, was just a quick question. I don't have much hope of it getting implemented in TTDPatch anyway
21:49:06  <Brot6> OpenGFX - Bug #2787 (Closed): Graphical bug in OpenGFX company headquarters (nivlac) @
21:49:06  <Brot6> OpenGFX - Bug #2787 (Closed): Graphical bug in OpenGFX company headquarters (yexo) @
21:54:08  <frosch123> Yexo: ttdp resolves the spritenumbers on activation and stores them in the action2
21:54:37  <frosch123> (that's why the action2 references are 16bit, though 8 bit would be enough)
21:54:44  <Yexo> so, using some extra memory during activation, it should be possible to support
21:54:57  <planetmaker> [23:38]	Yexo	sprite authors adhering to templates is just something you have to be very clear about when you start coding a set <-- yes, indeed. I somehow start to question how far that's feasible ;-)
21:55:03  <planetmaker> and sorry, was afk
21:55:18  <frosch123> yes, you only need to write the map in assembler :p
21:55:47  <Lakie> Heh
21:56:15  <Lakie> I thought quite a number of TTDPatch structures were pretty much crude map implementations anyway
21:56:17  <Yexo> an implementation like OpenTTD SmallMap is easy enough
21:56:45  <Yexo> not that I'd like to code it in assembler, but that's another matter :p
22:00:26  <planetmaker> he, thanks for looking at the OpenGFX issue, Yexo :-)
22:00:41  <planetmaker> Global Warming... those were the times ;-)
22:00:59  <planetmaker> good ol' wwottdgd2 map is what he's been playing
22:01:18  <Yexo> didn't look that far
22:01:25  <planetmaker> I recall that name ;-)
22:01:37  <Yexo> saw a huge list of newgrfs, removed a bunch and narrowed it down to a single grf
22:01:39  <planetmaker> it's the real[TM] map ;-)
22:01:59  <planetmaker> probably the same guy who asked me a couple of days earlier about that map
22:02:25  <frosch123> night
22:02:28  *** frosch123 has quit IRC
22:08:04  *** bodis has quit IRC
22:11:08  <Lakie> Hmm... I'm not sure wjich is the greater evil, having lots of specific templates or writing a generic one with factors.
23:35:58  <Brot6> NewGRF Meta Language - Revision 1457:9336d1b5a16c: Fix: various fixed pointed out by pylint (yexo) @
23:56:18  *** Lakie` has joined #openttdcoop.devzone

Powered by YARRSTE version: svn-trunk