Log for #openttdcoop.devzone on 28th July 2011:
Times are UTC Toggle Colours
00:44:02  <Brot6> DevZone Help Center - Membership #2897 (New): Applying for project: Japanese town names & US Midw... (Sylf) @
00:51:35  <Ammler> Sylf: it does not make much sense to host a project on devzone with closed source license :-)
00:55:36  <Brot6> DevZone Help Center - Membership #2897: Applying for project: Japanese town names & US Midwest to... (admin) @
00:56:33  <Brot6> DevZone Help Center - Membership #2897: Applying for project: Japanese town names & US Midwest to... (admin) @
01:07:04  <Brot6> repository /home/hg/jptowns registered in Redmine with url /home/hg/jptowns
01:07:04  <Brot6> repository /home/hg/jptowns created
01:25:01  *** Sylf has quit IRC
01:30:58  *** Sylf has joined #openttdcoop.devzone
02:07:26  <Brot6> Central European Train Set - Revision 94:da6ae48d4c44: apply offset correction for 6lu template (Eddi) @
03:15:37  *** Brot6 has quit IRC
03:15:37  *** avdg has quit IRC
03:15:37  *** DJNekkid has quit IRC
03:15:37  *** V453000 has quit IRC
03:16:02  *** V453000 has joined #openttdcoop.devzone
03:16:02  *** DJNekkid has joined #openttdcoop.devzone
03:16:14  *** Brot6 has joined #openttdcoop.devzone
03:16:32  *** avdg has joined #openttdcoop.devzone
04:16:42  *** Sylf has quit IRC
04:21:21  *** Sylf has joined #openttdcoop.devzone
05:18:58  *** andythenorth has joined #openttdcoop.devzone
05:58:48  *** andythenorth has quit IRC
06:13:05  <Brot6> DevZone Help Center - Feature #2724 (Closed): Applying for project: <Lithuanian Town Names> (planetmaker) @
06:16:17  <Brot6> DevZone Help Center - Membership #2897: Applying for project: Japanese town names & US Midwest to... (planetmaker) @
07:54:53  *** ODM has joined #openttdcoop.devzone
08:19:43  *** Zuu has joined #openttdcoop.devzone
10:01:17  *** TheODM has joined #openttdcoop.devzone
10:06:02  *** ODM has quit IRC
10:10:29  *** TheODM has quit IRC
10:23:35  *** ODM has joined #openttdcoop.devzone
11:33:05  *** ODM has quit IRC
12:00:48  <Brot6> Central European Train Set - Revision 95:b7bc85cf6255: change axle weight -> track class calculat... (Eddi) @
12:20:26  <Terkhen> hmmm... no andy
12:22:52  <Terkhen> after getting all nml dependencies using buildout, I get this error while trying to compile FIRS
12:22:53  <Terkhen>
12:23:08  <Terkhen> it looks PIL related...
12:25:48  <Terkhen> ogfx-trains compiles fine, so it seems that PIL is not prepared to deal with pcx files :/
12:26:00  * Terkhen looks for a script to convert all pcx files to png
12:26:35  <Ammler> Terkhen: did you run the regression test?
12:26:56  <Ammler> isn't Hirundo still a windows user?
12:27:08  <Hirundo> I am "still", yes
12:27:25  <Ammler> and for you, pcx works, right?
12:27:28  <Terkhen> Ammler: yes, it is executed as part of the buildout
12:27:46  <Hirundo> does the pcx file have a pcx extension?
12:28:04  <Terkhen> Hirundo: yes
12:28:12  <Ammler> Hirundo: could you try to build firs
12:28:16  <Terkhen> if you can compile FIRS on windows, then this is an issue with buildout
12:28:43  <Terkhen> but I'm going to mass convert pcx to png anyways, andy wanted to do it and it would let me use the nmlc.exe which is way simpler
12:29:38  <Hirundo> I'm currently in the middle of some NML changes so I can't compile anything
12:29:41  <Ammler> I guess a tool like irfanview is good for such on windows
12:29:57  <Hirundo> Terkhen: Could you post a stack trace (run nml with -s) ?
12:30:38  <Ammler> Terkhen: I don't see why buildout should be the issue
12:30:48  <Ammler> it is just "a installer"
12:30:51  <Terkhen> Ammler: wrong / incomplete PIL
12:30:57  <Terkhen> but let's see the stack trace
12:31:53  <Ammler> which PIL did it install?
12:31:56  <Ammler> nmlc --version
12:32:16  <Terkhen> PIL: 1.1.7
12:32:32  <Ammler> same here
12:33:07  <Terkhen> Hirundo:
12:34:47  <Ammler> cx_freeze?
12:34:56  <Ammler> isn't that part of nmlc.exe?
12:37:05  <Hirundo> pcx does not work on windows, according to r1308
12:38:53  <Hirundo> PIL just doesn't eat pcx on windows for some reason
12:39:04  <Hirundo> *someone* could create a separate pcx loader to work around that, the format is quite simple
12:40:01  <Ammler> hmm, I am sure, yexo was able to run the regression test on windows
12:40:53  <Ammler> we searched quite a long time to find the issue until we decided nmlc.exe does not support pcx, but we never said, nml does not support pcx
12:42:01  <Terkhen> Ammler: I ran the regression test with my current nml too
12:42:26  <Ammler> there is a pcx too
12:51:27  <Terkhen> bbl
12:55:01  <Brot6> feed grftools had 11 updates, showing the latest 10
12:55:01  <Brot6> NewGRF Meta Language - Revision 1545:31544fa93f8a: Feature: Allow re-use of spritegroups and spri... (Hirundo) @
12:55:01  <Brot6> NewGRF Meta Language - Revision 1546:87d8a1a35704: Codechange: Store all used spritesets when add... (Hirundo) @
12:55:01  <Brot6> NewGRF Meta Language - Revision 1547:a71e56f9130c: Codechange: Rename spritegroup to spritelayout... (Hirundo) @
12:55:05  <Brot6> NewGRF Meta Language - Revision 1548:c05f80d8bfe8: Feature #2896: Allow referring to spritesets d... (Hirundo) @
12:55:09  <Brot6> NewGRF Meta Language - Revision 1549:80fbe05a42ad: Change: Deprecate support for spritegroups for... (Hirundo) @
12:55:13  <Brot6> NewGRF Meta Language - Revision 1550:bc7bcdf3966c: Doc: Update and improve documentation of sprit... (Hirundo) @
12:55:17  <Brot6> NewGRF Meta Language - Revision 1551:24a686a287bb: Change: Make vehicle spritegroups require at l... (Hirundo) @
12:55:21  <Brot6> NewGRF Meta Language - Revision 1552:2eaa2bd8d114: Fix: Configuring x/y pixeloffset for childspri... (Hirundo) @
12:55:25  <Brot6> NewGRF Meta Language - Revision 1553:810653eeddbb: Doc: Document default palettes better. (Hirundo) @
12:55:31  <Brot6> NewGRF Meta Language - Feature #2896 (Closed): Allow spriteset to act as spritegroup with single ... (Hirundo) @
12:57:12  <Brot6> NewGRF Meta Language - Revision 1554:2e27c85574d7: Cleanup: Remove deprecated support for 'ttdspr... (Hirundo) @
12:58:20  <Hirundo> Vehicle and railtype grfs can now do with some less boilerplate ^^
13:06:52  *** FooBar has joined #openttdcoop.devzone
13:26:34  <Terkhen> nice :)
13:35:22  <Hirundo> I can compile firs here, using the nmlc from my repo (make struggles somewhat, but PIL has no errors)
13:36:15  <Brot6> NewGRF Meta Language - Bug #2898 (New): text in nml-language.html turns green (foobar) @
13:36:38  <Ammler> Hirundo: which PIL?
13:36:50  <Ammler> maybe it matters the version
13:37:21  <Hirundo> 1.1.7 also
13:37:25  <Ammler> I think, Terkhen is still "infected" by nmlc.exe though
13:37:38  <Terkhen> something on my end then
13:40:13  <Brot6> NewGRF Meta Language - Bug #2898 (Closed): text in nml-language.html turns green (foobar) @
13:40:13  <Brot6> NewGRF Meta Language - Bug #2898 (Closed): text in nml-language.html turns green (Hirundo) @
13:40:13  <Brot6> NewGRF Meta Language - Revision 1555:9d17bfa07e7b: Fix #2898: Missing html tag in (Hirundo) @
13:41:03  <Hirundo> as a side note, I have 'alias nmlc=path_to_nmlc' defined in my cygwin shell, but make doesn't seem to recognize this
13:41:37  <Hirundo> so FIRS compilation failed halfway, I had to run 'nmlc firs.nml' manually
13:41:43  <Hirundo> how do I fix this?
13:42:13  <Hirundo> (me == total noob when it comes to configuration, build scripts, make, whatever)
13:42:59  <Terkhen> what does "which nmlc" says?
13:43:13  <Terkhen> (running that command also confirmed that I was still using nmlc.exe :P)
13:44:21  <Ammler> Hirundo: I would symlink nmlc to ~/bin
13:44:27  <Ammler> instead alias
13:51:53  <Hirundo> trying now...
13:53:27  <Ammler> else you can also define path with makefile for as parameter make NMLC="/path/to/nmlc"
13:54:03  <Ammler> (Makefile.local)
14:01:15  <Terkhen> meh, now I'm sure that I'm using the correct nml after buildout and it is still missing pil/ply
14:01:32  <Terkhen> I'm going to install everything by myself, this has taken too long already
14:10:10  <Terkhen> there, done
14:10:11  <Terkhen> :P
14:10:41  <Terkhen> "sprites/nml/cargo_graphics.pnml", line 153: Sprite groups for feature 0B will not be supported in the future, as they
14:10:42  <Terkhen>  are no longer needed. Directly refer to sprite sets instead. <--- I suppose this warning is caused by the latest nml commits
14:11:23  <Hirundo> Ammler: The makefile.local trick (setting NML, not NMLC) worked, thanks
14:11:34  <Hirundo> Terkhen: yes
14:11:49  * Terkhen just added C:\Python27\scripts to the path and installed nmlc using
14:11:51  <Terkhen> ok :)
14:12:46  <Terkhen> which was the url for push using ssh?
14:13:43  <Hirundo> Terkhen: Are you working on it right now? else I'll fix it
14:15:00  <Terkhen> on FIRS? I'm still checking the documentation to see the new syntax :P
14:16:07  <Terkhen> oh, I suppose I just have to remove the spritegroup blocks and use the spriteset ID at graphics block
14:16:27  <Terkhen> don't worry, I'll fix it and also give them proper names while I'm at it
14:17:11  <Ammler> Terkhen: you see the different urls on the devzone repo page
14:22:10  <Hirundo> Terkhen: You may want to use this template:
14:23:07  <Terkhen> thanks :)
14:23:52  <Hirundo> Mind that the waste icon is currently unused, so spriteset_2205 doesn't have a corresponding action2/3
14:23:59  * Hirundo wonders, why NML doesn't warn about that
14:25:06  <Terkhen> ok, I'm checking all spritegroups while I'm at it
14:25:20  <Terkhen> this is a small file, I'll try to get it done
14:27:47  <Terkhen> planetmaker: do you have any list of completed files? how should I note that this one is "done"?
14:27:57  <Terkhen> (when it is done of course)
14:56:30  <Terkhen> which url should I use for pushing with ssh? I don't have it at hand at the moment
14:56:55  <planetmaker> Terkhen, FIRS? and completed in what sense?
14:57:04  <planetmaker> I guess none of the files is so far really completed
14:57:11  <Terkhen> everything has a correct name, it uses templates, etc
14:57:18  <Terkhen> "this file does not need any more work"
14:57:19  <planetmaker> at least not that I know. All still use the ugly action2_xyza
14:57:30  <planetmaker> no, such list doesn't exist afaik
14:57:41  <planetmaker> maybe now it'd be time to make issues - one per industry?
14:57:44  <Terkhen> I have a local copy of cargo_graphics.pnml which is complete in that sense :P
14:57:58  <planetmaker> good :-)
15:05:26  <Terkhen> no one enlightens me regarding the push url? :P
15:07:09  <Hirundo> Meanwhile, I have made some enhancements to cargo_props.pnml and fixed a bug, I'll wait with committing
15:08:19  <Terkhen> nice :)
15:08:20  <Ammler>
15:08:27  <Terkhen> thanks
15:08:53  <Ammler> or on every repository page
15:11:13  <planetmaker> uhm... why do you want to use ssh?
15:11:43  <Terkhen> IIRC that's what I always used
15:11:49  <planetmaker> :-D
15:11:50  <Terkhen> I had a hgrc file with a default-push that worked for me
15:12:10  <planetmaker> "normal" is via https and with your user name and login pw
15:12:28  <Terkhen> this one does not so I was using something differently
15:12:30  <planetmaker> I use sometimes this, in another project that ;-)
15:12:38  <Terkhen> hmm... so I have to input my password every time?
15:12:42  <planetmaker> no
15:12:58  * Hirundo has always used ssh IIRC :o
15:12:58  <planetmaker> well, it doesn't matter what you use
15:13:10  <planetmaker> yeah... the "oldies" of the devzone ;-)
15:13:30  <planetmaker> ssh works around redmine project affiliation ;-)
15:13:52  <planetmaker> via ssh you can commit to every project, whether the manager likes or not ;-)
15:13:54  * Terkhen does not want to use anything that forces to write the password everytime or that stores it as a text file somewhere
15:15:06  <Ammler> there is keyring extension
15:15:19  * Hirundo ponders
15:15:30  <Terkhen> ah, found it :)
15:15:37  <Hirundo> should NML warn on unused spritesets or not?
15:16:08  <Terkhen> IMO it should
15:16:21  <Terkhen> it makes it easier to spot errors :)
15:16:23  <Hirundo> or unused templates/tilelayouts/... for that matter, albeit coding it is significantly easier for spritesets since the code is already there, just not called currently
15:17:39  <planetmaker> Hirundo, yes, it should warn on unused stuff
15:18:02  <planetmaker> no matter what actually ;-)
15:18:19  <Brot6> FIRS Industry Replacement Set - Revision 2192:1fca59122bad: Codechange: Correct (Terkhen) @
15:18:23  <planetmaker> maybe at some stage NML could get a --warn-level=XY command line option
15:18:46  <planetmaker> where different warn-levels could indicate different seriousness...
15:19:54  <Brot6> NewGRF Meta Language - Revision 1556:68ab195d9c52: Change: Re-enable warning messages about unuse... (Hirundo) @
15:19:54  <Hirundo> agreed
15:21:14  <Terkhen> that would be nice, but it should not be a great priority :)
15:21:20  <planetmaker> ^^ agreed
15:21:37  <planetmaker> first it should support also houses and stations ;-)
15:21:41  * Terkhen looks for more easy stuff to correct
15:22:05  <Terkhen> my brain is still a bit fried :P
15:22:29  <planetmaker> fried? give us some of the summer weather... it's like spring or autumn here...
15:23:05  <Terkhen> nah, fried because of the stress I had two weeks ago
15:23:13  <Terkhen> you end up growing accustomed to this weather :P
15:23:24  <Terkhen> but yes, it's all yours if you want it
15:23:25  <planetmaker> :-)
15:23:51  <planetmaker> nah, not too much. My body works best in Scandinavian temperatures :-)
15:24:24  <Brot6> FIRS Industry Replacement Set - Revision 2193:84def1c1e32a: Fix: wrong interpretation of map_size... (Hirundo) @
15:24:24  <Brot6> FIRS Industry Replacement Set - Revision 2194:37db67960ea6: Codechange: Make cargo_props.pnml som... (Hirundo) @
15:25:05  <Terkhen> mine too, at least in summer scandinavian temperatures :P
15:25:10  * Terkhen is not so sure about winter ones
15:25:24  <Rubidium> planetmaker: so 25-30 C? ;)
15:25:50  <planetmaker> :-P
15:25:54  <Terkhen> oh, I'm going to prepare that nml script for highlighting
15:26:06  <planetmaker> that's about Tmax for me, Rubidium ;-)
15:26:19  <planetmaker> at least given the humidity which comes usually along with it in this region
15:26:41  <planetmaker> I have to say the day or two in the outback in Australia were not that bad - but the humidity must have been VERY low
15:27:16  <Rubidium> it's 24 C now, but terribly sweaty :(
15:27:53  <Terkhen> 35 C now, but humidity is always quite low here
15:28:04  <Terkhen> that's a blessing :P
15:28:28  <Rubidium> so it's likely better where you are then where I am, although... incoming (thunder)storm
15:40:46  <planetmaker> Hirundo, can you remind me please: what does "var[0x93, 0, -1]" mean when used as variable in a switch statement?
15:41:30  <planetmaker> I didn't exactly find that syntax documented - but we don't want users to use it anyway... but maybe we should document it nevertheless
15:41:46  <planetmaker> some test newgrfs might need it for not yet nml-ified variables or so...
15:43:52  <Hirundo> var[...] is basically hard-coded access to variables
15:44:41  <Hirundo> planetmaker: It's really low-level, I wouldn't want anyone to use it
15:45:18  <Hirundo> Low-level to the point that supplying the wrong (number of) arguments may simply crash NML or provide bogus output
15:45:19  <planetmaker> well. But if I write a new variable in openttd that nml doesn't yet know?
15:45:30  <planetmaker> that's what I meant
15:45:34  <Hirundo> Then it's added to NML, usually the same or next day :)
15:45:46  <planetmaker> yes, but I couldn't write a test grf myself ;-)
15:45:59  <planetmaker> still: FIRS uses it - what does that three-argument thing mean?
15:46:21  <Hirundo> it's var[varnum, shift, and-mask]
15:46:29  <Hirundo> -1 == 0xFFFFFFFF in this case
15:46:37  <Brot6> DevZone Help Center - Document: Syntax list script for NML (Terkhen) @
15:46:37  <Brot6> DevZone Help Center - (Terkhen) @
15:46:47  <Hirundo> I'll look up what it means
15:47:12  <planetmaker> var, shift, and-mask was what I needed. Thank you :-)
15:47:27  <planetmaker> I'll figure out the rest ;-)
15:48:12  <planetmaker> hm... though.... shift 0 with mask 0xFFFFFFFF is... strange
15:48:22  <Hirundo> better not use that in TTDP indeed :)
15:48:23  <planetmaker> maybe the original did that
15:48:25  <Terkhen> sounds like do nothing
15:48:29  <planetmaker> ^
15:48:41  <planetmaker> maybe some template ended up doing nothing the long way ;-)
15:48:44  <Hirundo> it'll read var 0x94-0x96
15:48:58  <planetmaker> it's ottd only anyway. So it's safe :-P
15:49:17  <Hirundo> It's industry::prod_level, quite a useful var
15:49:57  <planetmaker> yeah, that's part of the production code...
15:50:10  <planetmaker> which needs templating. But therefor I need to understand all details ;-)
15:50:40  <planetmaker> maybe the conversion script didn't know it
15:50:48  <Hirundo> NML doesn't know it (yet)
15:50:54  <planetmaker> :-O
15:51:18  <planetmaker> that I didn't expect
15:51:34  <planetmaker> do you or shall I? ;-)
15:54:11  <planetmaker> hm... nor is it documented in the newgrf specs.
15:54:26  <Hirundo> I will do, and I'll add a lot of other industry vars as well
15:54:32  <planetmaker> ok :-)
15:54:45  <planetmaker> hm... do you add them to the newgrf specs page then, too?
15:54:49  <Hirundo> basically most of the 80+x stuff in openttd is useful, but only a minority is currently implemented
15:54:52  <planetmaker> or shall I?
15:55:25  <Hirundo> did you already change anything?
15:55:32  <planetmaker> no
15:55:46  <planetmaker> except that I have an uncommited change with var93 in NML
15:55:53  <planetmaker> which is one line. so nothing worth keeping
15:56:07  <Hirundo> could you copy the line here?
15:56:22  <planetmaker> +       'production_level': {'var': 0x93, 'start': 0, 'size': 8},
15:57:03  <Hirundo> k, then I suggest you just keep working with your locally modified NML for now, I'll commit it later tonight
15:57:30  <planetmaker> I don't need that right now, so yes, no issue
15:59:43  <Brot6> DevZone Help Center - Document: Syntax highlighter for Geany (Terkhen) @
15:59:43  <Brot6> DevZone Help Center - filetypes.NML.conf (Terkhen) @
16:00:02  <planetmaker> well, I'll add some then to the NewGRF specs and leave you the nml patch, ok, Hirundo ?
16:00:17  <Terkhen> there, done
16:04:49  * Terkhen tries to fix aluminium plant now
16:07:38  <Terkhen> hmm... andy used substitute: 0 for all industries and industry tiles, right?
16:08:54  <FooBar> yes, most industries don't have a suitable TTD-alternative, so why bother...
16:09:18  <Terkhen> indeed
16:09:59  <planetmaker> well. bother for the reason of advanced scenarios which allow replacement of industry sets
16:10:09  <planetmaker> then a very rough replacement makes perfect sense
16:10:22  <planetmaker> and not having replacement by coal mine everywhere
16:10:44  <planetmaker> and aluminum plant imho is best replaced by steel mill
16:11:04  <FooBar> It will still mess up the graphics, so users shouldn't be encouraged to try that.
16:11:32  <Terkhen> that's far enough to be ignored for now :P
16:11:50  <Terkhen> once we have the conversion done we could look into it
16:11:53  <planetmaker> Terkhen, why, if we touch everything?
16:12:02  <planetmaker> imho having substitute coal everywhere is... boring
16:12:18  <planetmaker> I mean... it's an easy fix once it's open anyway ;-)
16:12:18  <Terkhen> I prefer to do the conversion with as less changes as possible
16:12:41  <Terkhen> also, the "substitutes" should be given some thinking so it is not that easy
16:12:54  <Terkhen> prospect_chance: 0.749999999942; <--- heh
16:14:16  <Terkhen> the aluminium plant uses a tile defined on basetiles; since I have no idea of what name to use for it I'll leave it for someone else to mass replace it in every file
16:19:13  <Terkhen> bbl
16:28:50  *** frosch123 has joined #openttdcoop.devzone
16:35:09  <Brot6> Central European Train Set - Support #2784: graphics template (oberhuemer) @
16:49:54  <planetmaker> hm, do we want to document more town variables?
16:51:26  <Hirundo> in NML or the grf specs?
16:51:41  <planetmaker> grfspecs for now.
16:55:57  <Hirundo> If there are some more useful variables, go ahead
16:58:41  <Hirundo> FYI, I added a few more to industries and fixed a comment on production level
16:59:09  <planetmaker> ok
16:59:45  * planetmaker -> dinner
17:09:57  <Brot6> nml: update from r1543 to r1556 done -
17:18:42  <Brot6> ogfx-industries: update from r121 to r122 done -
17:20:31  <Brot6> firs: update from r2183 to r2194 done (37 warnings) -
17:23:19  <Brot6> cets: update from r90 to r95 done (482 warnings) -
17:24:28  <Brot6> Following repos didn't need a nightlies update: ogfx-trains (r245), narvs (r37), bros (r52), 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 (r1556), 32bpp-extra (r40), manindu (r7), newgrf_makefile (r305), ailib-direction (r17), ailib-common
17:24:28  <Brot6> (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 (r41), ailib-string (r29), airportsplus
17:24:30  <Brot6> (r107), comic-houses (r71)
17:25:11  <Brot6> ogfx-trains: rebuild of r245 done (Diffsize: 2319) (DiffDiffsize: 1727) -
17:25:51  <Brot6> narvs: compile of r37 still failed (#2789) -
17:26:36  <Brot6> sub-landscape: compile of r72 still failed (#2892) -
17:27:40  <Brot6> manindu: rebuild of r7 done (Diffsize: 2) (DiffDiffsize: 5) -
17:29:57  <Brot6> Dutch Tram Set - Bug #2899 (New): DevZone compile failed (compiler) @
17:30:57  <Brot6> spanishtowns: rebuild of r10 done (Diffsize: 2) (DiffDiffsize: 5) -
17:33:38  <Brot6> ogfx-rv: rebuild of r107 done (Diffsize: 4775) (DiffDiffsize: 1952) -
17:34:49  <Brot6> NewGRF Meta Language - Revision 1557:541a06a674c8: Add: Some more industry 80+x variables. (Hirundo) @
17:35:37  <Terkhen> I was thinking on adding some template for industry spritelayouts, but there are too many special cases
17:36:11  <Terkhen> for aluminium plant it would need three templates: ground only, ground and building, ground and two buildings
17:38:32  <Brot6> ogfx-landscape: rebuild of r71 done (Diffsize: 471) (DiffDiffsize: 419) -
17:38:56  <Terkhen> hmm... I think I'm going to complete the aluminium plant first, and then think about templates for spritelayouts
17:39:03  <Terkhen> it would reduce greatly the size of industry files
17:39:55  <Brot6> swedishrails: rebuild of r203 done (50 warnings) (Diffsize: 392) (DiffDiffsize: 334) -
17:39:56  <Hirundo> ^^ You'd need parametrized sprite layouts for that to work really well
17:40:46  <Terkhen> spritelayout_two_buildings(ground_sprite, building_sprite_1, zextent_1, building_sprite_2, zextent_2) <--- and similar templates for "one building" and "ground only"
17:40:50  <Terkhen> it is kind of messy, yes
17:41:15  <Terkhen> it would still turn 16 lines into a single one :P
17:41:58  <Hirundo> you mean "templates" as in cpp?
17:42:05  <Terkhen> bad idea, I just found a spritelayout using xoffset and xextent
17:42:07  <Terkhen> Hirundo: yes
17:42:36  <Hirundo> The functionality is planned to be included in NML also, but not yet done
17:42:49  <Terkhen> that would be great :)
17:43:00  <Terkhen> ogfx-rv and ogfx-trains use a lot of cpp templates too
17:43:38  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: newgrf_makefile, swisstowns, frenchtowns, source-test (6 warnings), german-townnames (Diffsize: 1), belarusiantowns (Diffsize: 30), indonesiantowns (1 warnings) (Diffsize: 1)
17:43:57  <Brot6> OpenGFX+ Airports - Bug #2900 (New): DevZone compile failed (compiler) @
17:46:21  <Hirundo> I've been pondering templates for items also
17:48:08  <Terkhen>
17:48:33  <Hirundo> Yes, something like that, but more smart
17:49:23  <Hirundo> with templates that can extend other templates to partially extend/override them, while still working correctly for graphics blocks that must be defined in one go
17:50:21  <Hirundo> I do not expect that to be done while _cur_year == 2011, though :)
17:50:30  <Terkhen> :)
17:52:20  <Terkhen> aluminium_plant.pnml has about 500 lines of sprite layouts :P
17:52:55  <planetmaker> :-)
17:53:07  <planetmaker> I'm sure sprite layouts can be somewhat templated
17:53:28  <Terkhen> is there any helper function for relative_pos values? (industrytile variable)
17:53:52  <Terkhen> planetmaker: aluminium plant would need four templates: "ground only", "ground and building", "ground and two buildings", "ground, building, ttd sprite"
17:54:33  <Terkhen> if you think that scheme would be useful, I can implement them and apply them to the aluminium plant after it is done without templates
17:55:49  <planetmaker> I do think it's useful, yes :-)
17:55:56  <planetmaker> Terkhen: have a look at opengfx+airports
17:56:06  <planetmaker> it implements ground and ground+building already somewhat
17:56:29  <planetmaker> though I'd like to use templates slightly different here. Also via include
17:56:59  <Terkhen> yes :)
17:57:02  <planetmaker> via #include (instead of macro) gives better readable gcc output: not everything in one line ;-)
17:57:11  <Terkhen> IMO different files for each type of template
17:57:21  <Terkhen> spritelayout_templates, industry_templates, etc
17:57:34  <planetmaker> yes
17:59:07  <Terkhen> hmm... if there is no helper function for relative_pos I'll need to add a template for it too
17:59:17  <Terkhen> for now I'll leave the ugly, meaningless values :P
18:00:07  <Terkhen> urgh
18:00:22  <Terkhen> why are sprites being defined twice on the aluminium plant file?
18:00:59  <Terkhen> and yet another huge amount of spritelayouts... which I suspect to be the same than the first ones
18:02:37  <planetmaker> ok, so you're dealing with sprite layouts, right?
18:02:55  <Terkhen> right now I'm just giving pretty names to everything
18:02:59  <Terkhen> after that I'll deal with the templates
18:03:36  <planetmaker> that might be double work
18:03:50  <Terkhen> maybe, but I will only do that for the aluminium plant
18:03:56  <Terkhen> I need a nice file to know which templates it should use :P
18:04:37  <Terkhen> ok, luckily other industries don't seem to have duplicated sprite information
18:04:55  <Terkhen> it seems that I chose which file to edit badly :P
18:07:56  <Terkhen> indeed, sprite layouts are duplicated too
18:08:42  <Terkhen> hmm... in this case I'll implement the templates now, that will make it easier to fix this issue
18:08:46  <Terkhen> but I wonder why they are duplicated
18:22:44  <planetmaker> exactly same sprites?
18:22:55  <planetmaker> then it might be a templating effect... who knows
18:22:57  <Terkhen> same sprites defined twice, same layouts defined twice
18:23:39  <Terkhen> <-- check line 14 and line 733
18:24:03  <Terkhen> is it wrong to give a recolour_mode and a palette to a standard tile? for example GROUNDSPRITE_CLEARED
18:24:27  <planetmaker> I don't think it's wrong
18:24:47  <Terkhen> ok :)
18:24:59  <Terkhen> another question: if a sprite has no zextent, adding a zextent: 0 changes it?
18:25:05  * Terkhen is flying blind right now :P
18:25:21  <Rubidium> bad pilot ;)
18:25:36  <Terkhen> indeed :)
18:26:27  <planetmaker> Terkhen: I don't quite know, though I tend to answer 'no effect' ;-)
18:26:52  <Terkhen> we'll know if it is true once I finish
18:27:07  <planetmaker> have you comitted anything?
18:27:17  <planetmaker> or can I push primary production template?
18:27:40  <Terkhen> go ahead
18:27:55  <Terkhen> this will still take some time
18:28:34  <Hirundo> Terkhen: with zextent == 0, you mean the sprite has no height?
18:28:43  <planetmaker> ok, and I'll stay away from the aluminum plant ;-)
18:29:24  <Hirundo> palette : 0; should be replaced with PALETTE_USE_DEFAULT
18:29:34  <Terkhen> Hirundo: hmm... if I understood it correctly that would be zoffset
18:29:40  *** andythenorth has joined #openttdcoop.devzone
18:29:42  <Brot6> FIRS Industry Replacement Set - Revision 2195:38fbb607bcdb: Add: Template for primary production (planetmaker) @
18:30:06  <Hirundo> zoffset = min_z, zextent = max_z - min_z
18:30:10  <Terkhen> thanks, I'll replace palette 0 in the templates too :)
18:30:35  <Terkhen> hmm... then setting zextent to zero makes no sense
18:30:37  <Terkhen> hi andythenorth
18:30:45  <andythenorth> bonjour
18:30:47  <Hirundo> to correct my statement replace only the 0, not the entire declaration with PALETTE_USE_DEFAULT
18:31:31  <Terkhen> extent makes spritelayout templating quite complicated :/
18:33:02  <Hirundo> planetmaker: NML avoids the nvar == 0 bear trap for you, there is no need to do that yourself
18:33:04  <Terkhen> <--- the problem is with blocks like this one... what if some layouts need a zextent on the first building and another ones not? then we need two templates
18:33:36  <Hirundo> you can pass zextent as a parameter
18:33:56  <Terkhen> but what to pass if that building is supposed to not declare a zextent at all?
18:33:57  <Hirundo> default is 16
18:34:08  <Terkhen> oh, always? nice :)
18:35:14  <Terkhen> andythenorth: do you have any idea why sprites and spritelayouts are defined twice for the aluminium plant? maybe some template?
18:35:28  <andythenorth> snow sprites
18:35:39  <andythenorth> if you read the nfo all will make sense :)
18:35:58  <andythenorth> probably *all* of those need rebuilding to advanced layouts
18:36:00  <andythenorth> have fun :P
18:36:10  <Terkhen> hmm... but they seem to be using the same sprite
18:36:25  <Terkhen> <--- check for example lines 14 and 733
18:36:42  <Terkhen> same file, same position in the file
18:37:05  <Brot6> FIRS Industry Replacement Set - Revision 2196:2d8bce5bcc01: Add: undef template. And use it in ir... (planetmaker) @
18:37:33  <andythenorth> Terkhen: not sure without checking the nfo...
18:37:36  <andythenorth> 1 min
18:37:44  <Terkhen> ok
18:37:45  <Brot6> Dutch Tram Set - Bug #2899: DevZone compile failed (foobar) @
18:38:26  <andythenorth> Terkhen: most of the industries had built-in-but-unused support for both Tropic + Temperate climates
18:38:29  <andythenorth> separately
18:38:44  <andythenorth> if you look at the nfo template for aluminium plant - it's obvious
18:38:52  <Terkhen> I have opened 5 or 6 random industries, only the aluminium plant has duplicates (I have only checked nml)
18:38:55  <andythenorth> even if you can't read the nfo, the defines are trivial
18:39:06  <Terkhen> where can I check that?
18:39:13  <andythenorth> sprites/nfo/industries
18:39:24  <andythenorth> most industries should exhibit this pattern
18:39:47  <Terkhen> which one for example?
18:40:48  <Terkhen> ah, I see the error now
18:41:03  <Terkhen> <--- normal layouts are defined twice, then another time for snow
18:41:13  <andythenorth> yes
18:41:21  <Terkhen> so I can erase the second copy :P
18:41:21  <andythenorth> it's not an error - it's intended
18:41:28  <Terkhen> really? I don't understand it then
18:41:32  <andythenorth> depends how we're handling climate support
18:42:14  <andythenorth> try a more complex case first
18:42:16  <andythenorth> e.g. quarry
18:42:21  <andythenorth> or forest
18:42:32  <andythenorth> after the complex case, the simple cases will be more obvious
18:42:38  <andythenorth> or fruit plantation
18:42:47  <andythenorth> forest + fruit plantation are most complex iirc
18:43:01  <andythenorth> although you may have solved those for opengfx industries
18:43:54  <Terkhen> <--- this is what I don't understand
18:44:11  <Terkhen> my understanding of nfo is kinda sketchy so it might be wrong :P
18:46:28  <andythenorth> Terkhen: it could change, but then it's less copy-paste
18:46:33  <Terkhen> I don't understand why you need duplicate sprite definitions and duplicate sprite layout definitions
18:46:41  <andythenorth> writing nfo is all about making it easy to write code
18:46:49  <Terkhen> if the reason is nfo templating then I understand :P
18:46:56  <andythenorth> the efficiency or optimisation of the actual code is near-irrelevant
18:47:12  <andythenorth> this way industries can be copy pasted at will, and tropic support used if needed
18:48:13  <Terkhen> ok, then I'll unduplicate it on nml
18:48:26  <Terkhen> but given that sprite layouts need to be defined at least twice, this scheme makes a lot of sene
18:48:28  <Terkhen> sense*
18:48:38  <Hirundo> why twice?
18:48:48  <Terkhen> once for snow, once for normal
18:49:03  <Terkhen> I guess I have to look into advanced sprite layouts before doing it
18:49:24  <Hirundo> you may want to look into the spritelayout documentation I wrote today :)
18:49:34  <Terkhen> oh, thanks :)
18:49:34  <andythenorth> we almost certainly should swap *all* of it to advanced layouts
18:49:48  <Terkhen> there goes my hope of mindless conversion :P
18:49:54  <andythenorth> no chance
18:50:02  <Terkhen> meh
18:50:07  <andythenorth> one of the reasons for nml conversion is that advanced layouts are unsupported in nfo
18:50:16  <Hirundo> The most mindless part has been done by nfo2nml already
18:50:34  * Terkhen just hoped for lots of stuff_23489 -> nice_readable_name :P
18:51:32  <Hirundo> That can still be done :P if you want the name to be nice and meaningful, it's not mindless though
18:51:48  <andythenorth> unfortunately FIRS-> nml is a *huge* project
18:52:24  <Terkhen> it would be close enough for me :P
18:53:17  * Hirundo wants templated sprite layouts
18:54:02  * Hirundo doesn't want to implement templated sprite layouts
18:54:13  <Terkhen> :P
18:56:06  <planetmaker> I'm not entirely sure *how* much they need templating
18:57:29  <Terkhen> hmm...
18:57:58  <planetmaker> but I haven't looked at sprite layouts in FIRS really
18:58:05  <Hirundo> did I say templated
18:58:09  <planetmaker> nor am I'm currently exactly sure how the adv. ones would work
18:58:10  <Hirundo> I meant parametrized
18:58:48  <planetmaker> :-)
18:58:55  <Terkhen> so I should define all sprites (snow, no snow) in the same spritelayout and conditionally use hide_sprite? sprites always confuse me :/
18:59:13  <Rubidium> go nml meta language ;)
18:59:25  <planetmaker> Terkhen: I think you should always assume to have the choice snow / no snow. yes
18:59:44  <planetmaker> though... in the sprite layout. hm
18:59:48  <Hirundo> I'd just do "sprite: if_show ? sprite_a : sprite_b;"
19:00:00  <planetmaker> he. nifty. does that work?
19:00:02  <Hirundo> arggh .. show->snow
19:00:07  *** bodis has joined #openttdcoop.devzone
19:00:15  <Hirundo> I'm taking a break right now :)
19:00:16  <planetmaker> hadn't you corrected yourself, I hadn't noticed ;-)
19:00:39  <Hirundo> and yes it works, and yes you can use industry tile vars as part of is_snow
19:00:45  * Hirundo now really takes break
19:00:55  <Terkhen> thank you, enjoy :)
19:01:03  <planetmaker> enjoy, indeed :-)
19:01:25  <Brot6> FIRS Industry Replacement Set - Revision 2197:80b1e5688639: Codechange: Use the primary productio... (planetmaker) @
19:01:46  <planetmaker> Terkhen: if you need a name: use IND_ID(name)
19:01:51  <planetmaker> that'll be industry-specific then
19:02:01  <Terkhen> a name for what?
19:02:05  <planetmaker> where name is the name of the switch / layout / whatever
19:02:09  * andythenorth estimates that converting FIRS will take about 15% as much effort as creating nfo FIRS took
19:02:09  <planetmaker> identifier in general
19:02:14  <planetmaker> preceeded by the industry name
19:02:20  * andythenorth estimates ~3 months
19:02:34  <planetmaker> possible, yes
19:02:44  <Terkhen> is that a macro defined somewhere?
19:02:56  <planetmaker> Terkhen: yes, each industry does / will / should
19:03:04  <planetmaker> #define IND_ID(...) oil_rig ## __VA_ARGS__
19:03:15  <planetmaker> I'll start making use of it much more often
19:03:20  <Terkhen> where is it? I can't find it
19:03:23  <planetmaker> and it's the first define in each
19:03:33  <Terkhen> s/I/grep/
19:03:33  <planetmaker> in the respective industry pnml file
19:03:36  <planetmaker> not all have it
19:03:47  <planetmaker> only the 15 primaries I "fixed" now
19:04:00  <Terkhen> ah, right, I should update
19:04:06  <planetmaker> :-)
19:04:31  <planetmaker> andythenorth: I still think that's time well-spent, though
19:04:33  <andythenorth> templating the production code should bring / have brought the lines count down by a lot
19:04:48  <planetmaker> andythenorth: not of the primary ones ;-)
19:05:00  <andythenorth> I haven't pulled recently or looked at commits
19:05:01  <planetmaker> that were 6 lines or so
19:05:07  <andythenorth> ?
19:05:17  <planetmaker> and the other production code is still in its prestine state ;-)
19:05:19  <Brot6> clientpatches: update from r22689 to r22691 done (6 warnings) -
19:05:23  <Terkhen> templating spritelayouts will reduce the count a lot too: for aluminium plant they are about 1000 lines or so
19:05:27  <andythenorth> 6 lines sounds short
19:05:33  <andythenorth> gah
19:05:35  <andythenorth> merges
19:05:37  <planetmaker> andythenorth: yes... primary IS short
19:06:15  <planetmaker> but... you might consider a larger part of the code part of the prod. template. Dunno
19:06:23  <planetmaker> Cloasure and opening is excluded there
19:07:00  <Terkhen> planetmaker: I like the IND_ID idea
19:07:10  <Terkhen> item(FEAT_INDUSTRIES, arable_farm, 26) { <--- shouldn't this be  IND_ID()?
19:07:12  <planetmaker> I stole it from Eddi / cets
19:07:20  <planetmaker> eventually yes
19:07:47  <planetmaker> I only touched the production code though
19:08:19  <Terkhen> I'm going to leave the aluminium plant for now and start correcting layouts for a simpler file
19:08:32  <planetmaker> :-)
19:08:39  <Terkhen> this is getting too big, and I want to get the process right without many distractions :P
19:08:56  <Terkhen> the arable farm is nice for that, I'll use it :P
19:09:02  <planetmaker> :-D
19:09:10  <planetmaker> that's probably the file which I tidied most so far
19:09:18  <Terkhen> yes, I'm lazy as that :P
19:09:23  <planetmaker> fair enough :-)
19:09:29  <Terkhen> I'll start with a macro for relative_pos
19:09:36  <planetmaker> hm...
19:09:39  <Terkhen> tomorrow I'll finish sprite layouts
19:09:52  <Terkhen> instead of 256 -> coord (0, 1)
19:10:07  <Brot6> openttd-vehiclevars: update from r22689 to r22691 done -
19:11:17  <planetmaker> ah, that
19:12:08  <Terkhen> hmm...
19:12:18  <Terkhen> maybe my time would be better spent coding it as a helper function in nml itself
19:12:37  <Terkhen> why does everything always get bigger and bigger? :P
19:12:52  <planetmaker> :-D
19:12:57  <andythenorth> probably a fallacy :P
19:13:06  <andythenorth> some kind of anti-pattern
19:13:08  * Terkhen just wanted to do some name conversions today
19:13:17  <Terkhen> and I end up touching python code :P
19:13:27  <planetmaker> lool :-)
19:13:42  <andythenorth> @2188
19:13:44  <Brot6> Central European Train Set - Revision 96:2c9ab8ec3d13: Templates for 14/8, 3/8 and 7/8 (oberhuemer) @
19:13:45  <Brot6> Central European Train Set - Revision 97:865809dad4ed: merged changes (needs a commit?) (oberhuemer#) @
19:13:50  <andythenorth> hmm
19:13:59  <andythenorth> nvm
19:14:14  <andythenorth>
19:14:18  <andythenorth> planetmaker: ^ shared IDs? :o
19:14:39  <Brot6> serverpatches: update from r22689 to r22691 done (10 warnings) -
19:14:45  <planetmaker> andythenorth: shared? where?
19:14:51  <andythenorth> in your commit message
19:15:00  <andythenorth> action2 IDs
19:15:14  <planetmaker> you mean the IND_ID() macro?
19:15:51  <planetmaker> IND_ID(...) is defined per industry. Thus gives always the proper industry's name within all includes in that file
19:16:04  <andythenorth> hmm
19:16:08  <andythenorth> maybe I read the code
19:16:09  <Terkhen> IND_ID(_layout_1) = "arable_farm_layout_1"
19:16:14  <Brot6> Central European Train Set - Support #2784: graphics template (oberhuemer) @
19:16:14  <Brot6> FIRS Industry Replacement Set - Feature #2823 (Closed): Split god_object.pnml into separate files... (andythenorth) @
19:16:21  <andythenorth> I don't follow why the order of industries would be significant
19:16:47  <Brot6> 32bpp-ez-patches: compile of r22691 still failed (#2446) -
19:16:53  <planetmaker> and that makes sure that the identifiers needed for layouts, spritesets, action2s, action3s, ... are unique per industry
19:17:07  * andythenorth much to learn has
19:17:22  <planetmaker> it's not that much an NML thing as the need to come up with unique names
19:17:35  <planetmaker> and an easy naming scheme then is industryname_switchname
19:17:46  <planetmaker> then switchname can be templated to use industryname macro
19:19:09  <planetmaker> I only learnt that trick / kind of macro usage recently. But I find it VERY helpful :-)
19:19:46  <planetmaker> nml needs unique names for each switch. In nfo you could just re-use the same numbers in the templates
19:19:54  <andythenorth> oh
19:20:20  <Terkhen> then we actually need this trick to template industries more easily :)
19:20:26  <planetmaker> yup
19:21:00  <Terkhen> s/more easily/as done in nfo/
19:21:02  <planetmaker> in comparison, templates/industry_templates.pnml originates from before I learnt that trick
19:21:08  <planetmaker> it looks ugly in comparison ;-)
19:21:19  <planetmaker> and less readable
19:23:23  <andythenorth> hmm
19:23:56  * andythenorth ponders
19:24:17  <andythenorth> nvm
19:26:13  <andythenorth> so replicating the nfo template structure - not helpful I guess
19:27:09  <planetmaker> yes and no
19:28:36  <planetmaker> the templates kinda can be re-created.
19:28:48  <planetmaker> that's what the IND_ID() macro allows
19:28:53  <Hirundo> Terkhen: I guess the relative_pos thingy is quite general, it might be useful for other industry/airport/object grfs also
19:29:18  <Hirundo> So if you have a generic solution, it could be implemented (probably as some built-in function) in NML
19:29:32  <Terkhen> I'm trying to implement it as a bultin function now :)
19:39:05  * andythenorth needs 'nml for dummies'
19:40:24  <Hirundo> As soon as FIRS conversion is finished, a small section (like 1 industry + cargo) of it could be used as example code :)
19:40:54  <Terkhen> andythenorth: I learned by checking other people's code :P
19:41:02  <Terkhen> you might want to give ogfx-industries a look
19:41:08  <andythenorth> that's slightly how I learned nfo
19:41:31  <andythenorth> I should probably write some nfo from scratch
19:41:45  <andythenorth> nml / nfo /s
19:42:40  <Terkhen> do a simple addon for firs :P
19:43:54  <Terkhen> <--- this seems to work
19:44:00  <Terkhen> I'll write documentation after dinner :)
19:44:02  <Terkhen> bbl
19:47:27  <planetmaker> looks fine, Terkhen
19:47:47  * planetmaker is off to an early bed, though :-)
19:47:49  <planetmaker> good night
19:52:49  <Hirundo> Terkhen: IMO the function should not be restricted to constants
20:08:20  <Terkhen> hmm... true, I forgot that you can use non constant stuff at switch blocks too
20:08:33  <Terkhen> I'll recode it :)
20:11:21  <Hirundo> for the range check, you will want to use generic.check_range and apply it only on constant parameters
20:14:52  <Hirundo> <- afk
20:16:11  <Terkhen> thanks :)
20:16:17  <Terkhen> I think I'm on the right path now
20:42:27  <Brot6> FIRS Industry Replacement Set - Revision 2198:149144d9c1b9: Add: Template for secondary industry ... (planetmaker) @
20:47:56  <Terkhen> or not, I was using and instead of or :P
20:51:57  <andythenorth> ho
20:52:12  <andythenorth> I realise one reason why nml is hard for me to read
20:52:20  <andythenorth> my brain is no good at all-caps
20:52:36  <andythenorth> :)
20:52:47  <Terkhen> nice template, I remember those from the nfo code :P
20:53:04  <Terkhen> switch(FEAT_INDUSTRIES, SELF, IND_ID(simple_produce), [STORE_TEMP(STORE_PERM(STORE_TEMP(STORE_PERM(0, 11), 11), 10), 10), 1]) { <--- wow :P
20:53:40  <Terkhen> even with nice names it still looks like magic
20:53:42  <andythenorth> umm yeah
20:53:48  <andythenorth> it looks very magic to me
20:53:49  <planetmaker> that's not nice names
20:53:55  <planetmaker> it's cut and paste
20:54:05  <planetmaker> I just wanted it out of the industry
20:54:27  <Terkhen> oh :P
20:54:48  <planetmaker> I'm too tired to understand it now
20:54:53  <planetmaker> But I can template it ;-)
20:55:05  <planetmaker> *move it to a template
20:55:06  <Terkhen> it still makes sense, get every template out of the way and fix them later
20:55:10  <andythenorth> yes
20:55:26  <andythenorth> simplify, then beautify
20:55:29  <planetmaker> ^^
20:55:31  <andythenorth> sometimes both are the same
20:55:37  <Terkhen> :)
20:56:19  <planetmaker> you see very well in the template where I capitulated to the code understanding ;-)
20:56:22  <planetmaker> read backwards
20:56:35  <Terkhen> Hirundo: <--- I'm going to write the documentation now :)
20:59:23  <Hirundo> Terkhen: There is a copy paste error in the position argument of the second range check
20:59:53  <Terkhen> thanks, I missed that one :)
21:00:09  <Hirundo> Is there any specific reason to use 'reduce' on the last line, when the number of arguments is always 2 ?
21:02:29  <Terkhen> hmm... too much copy paste I guess
21:27:50  <Hirundo> Terkhen: How is it coming along?
21:28:22  <Terkhen> I think it's okay now, but right now I'm using the function in more places at FIRS to be sure
21:28:28  <Terkhen> I don't think it'll be ready for today :)
21:28:51  <andythenorth> good night
21:28:51  *** andythenorth has left #openttdcoop.devzone
21:31:58  *** bodis has quit IRC
21:33:26  <Hirundo> It's quite nasty that NFO (and thus NML) contains both signed and unsigned 0xYX offsets also, so it's impossible to devise a function that works always
21:36:05  <Terkhen> hmm... true, I also forgot to check other variables in which it might be useful too
21:36:18  <Terkhen> let's see if any of those uses signed offsets
21:37:09  <Terkhen> oh
21:38:15  <Terkhen> I was understanding the object relative_pos variable wrong, it is identical to the industrytile variable
21:38:36  *** frosch123 has quit IRC
21:40:59  <Terkhen> regarding values contained in item variables, I don't see any case in which signed offsets would be useful... maybe for variable parameters, but those don't need a helper function
21:42:14  <Hirundo> no, that's not what I meant
21:43:00  <Hirundo> The function as-is should remain restricted to the 0xYYXX format
21:44:26  <Hirundo> it is arguably useful within industry, object and airport code
21:44:52  <Hirundo> perhaps though, the name should be changed to reflect that, 'coord' might be a bit too generic
21:45:39  <Terkhen> maybe relative_coord?
21:47:00  <Hirundo> I guess that'd be fine
21:47:12  <Hirundo> for now, goodnight
21:47:18  <Terkhen> good night Hirundo
22:02:52  *** FooBar has quit IRC

Powered by YARRSTE version: svn-trunk