Log for #openttdcoop.devzone on 13th June 2011:
Times are UTC Toggle Colours
05:38:40  *** bodis has quit IRC
07:19:45  *** ODM has joined #openttdcoop.devzone
08:55:35  *** frosch123 has joined #openttdcoop.devzone
11:24:32  *** Lakie has joined #openttdcoop.devzone
12:22:53  *** andythenorth has joined #openttdcoop.devzone
12:42:49  <Yexo> andythenorth: I have an (almost completely automatic) conversion of firs to nml
12:44:06  <Terkhen> :)
12:46:46  <Brot6> FIRS Industry Replacement Set - Revision 2049:4aa62bb6561b: Codechange: use separate string ids f... (yexo) @
12:46:46  <Brot6> FIRS Industry Replacement Set - Revision 2050:e024060d307e: Add: nml conversion (yexo) @
12:47:48  <Yexo> it still uses the nfo code to build firs.grf, so manual invocation of nmlc is currently needed to build
12:48:04  <Yexo> planetmaker: would it be too much to ask you to take a look at the makefile and fix that?
12:48:59  <planetmaker> ho ho. I shall have a look. What exactly is the issue?
12:49:16  <Yexo> I've committed firs.nml and lang/*.lng files to firs (the 0.6 branch)
12:49:30  <Yexo> haven't edited the makefile yet, so it'll still use the original nfo files to build firs.grf
12:49:45  <planetmaker> oh, just the switch?
12:49:48  <Yexo> tried to do some minor modifications to the makefile, but that failed
12:49:48  <planetmaker> easy
12:49:56  <Yexo> for you, yes :)
12:49:58  <planetmaker> hm... just for the branch?
12:50:01  <Yexo> yes
12:50:05  <Yexo> not for trunk
12:50:11  <planetmaker> ok, not exactly easy, but feasible
12:50:26  <Yexo> hg up -r 2048, make changes, commit
12:50:36  <planetmaker> hm. of course, you're right
12:51:26  <Yexo> how does the cf figure out which revision to use as nightly?
12:51:47  <Yexo> because currently "tip" is the 0.6 branch
12:51:50  <planetmaker> I *think* it uses branch default. But I'm not sure. Ammler ?
12:54:15  <Yexo> I've done some very basic testing and it seems to work fine, but I don't have more time today to test
12:54:42  <Yexo> after the makefile changes it'll need a bit more testing, than it can be released as 0.6.5
12:55:39  <Terkhen> I'll be able to test this night
12:56:26  <planetmaker> sweet
12:58:15  <planetmaker> uhm... oh it's only firs.nml :-)
13:01:44  <Ammler> yes, nightlies are default only
13:02:00  <Ammler> (yet)
13:02:35  <Ammler> releases doesn't matter
13:03:17  <Ammler> so if you want cf to build 0.6 branch, you need to tag it, maybe as -beta or whatever
13:04:07  <Ammler> but, we have also bookmarks
13:04:48  <Ammler> and you could make a bookmark in the default branch and so you would have a kind of branch which would be build
13:05:07  <Ammler> (git-style branch)
13:06:24  <Ammler> [14:50] <Yexo> hg up -r 2048, make changes, commit <-- that doesn't look like named branching
13:07:24  <Ammler> also, IMO it is ugly to make a release brach for feature
13:09:10  * Ammler would have made a bookmark "nfo", then commit nml conversion, then add bookmark nml
13:09:30  <planetmaker> Yexo: things like "lang/38.lng", line 115: String commands don't match with english.lng
13:09:31  <planetmaker> "<stdin>", line 1445: Block 'action2_1935' is not referenced, ignoring.
13:09:33  <planetmaker> "<stdin>", line 1317: Block 'spriteset_1903' is not referenced, ignoring.
13:09:34  <planetmaker> "<stdin>", line 5527: Block 'action2_2398' is not referenced, ignoring.
13:09:36  <planetmaker> are expected?
13:10:07  <planetmaker> <-- full log
13:10:15  <Ammler> (or branch, if you don't like bookmarks)
13:10:35  <Ammler> but for sure, not branch 0.6 for experimental feature
13:10:57  <planetmaker> Further 0.6 commits are all experimental. so...
13:11:02  <Ammler> (just think how you would do it in openttd) :-)
13:11:41  <Ammler> planetmaker: would be like you rename openttd trunk in 1.2
13:12:20  <Ammler> what if you withdraw the nml convert?
13:12:38  <planetmaker> yes, so what?
13:13:26  <Ammler> oh well, it is your projects, I should really not need to explain you the workflow, so nevermind, just be aware, there will be no 0.6 nightly
13:14:43  <planetmaker> that's ok and that was the question :-)
13:18:00  <Ammler> if I ignore the ugly branch name, I might be able to investigate some time to check, how easy it is to extend current script to support it :-P
13:18:21  <planetmaker> eh?
13:18:27  <planetmaker> what is ugly with 0.6?
13:18:51  <Ammler> I would use such name for a release, not a maybe feature
13:19:14  <Ammler> so rather make branch 0.5 for the nfo code and nml in default
13:19:36  <Ammler> or make branch nml
13:19:50  <Ammler> you wouldn't do that in openttd either
13:20:22  <planetmaker> Nah, we don't want to change that. Using the 0.6 branch is the thing to do. Because it's what we change and only change
13:20:32  <Ammler> no
13:20:39  <Ammler> it might also be of use for 0.7
13:20:40  <planetmaker> and it's where the next release will take place
13:20:44  <planetmaker> Ammler: no
13:20:54  <Ammler> so 0.7 will again be nfo?
13:21:05  <Ammler> that sounds silly, sorry :-)
13:21:07  <planetmaker> There the conversion will be done anew. And any useful changes will be not backported but forward ported
13:21:23  <planetmaker> Ammler: it's simple: 0.6.5 = 0.6.4 if conversion is 100%
13:21:36  <planetmaker> and then, only then NML will be ported to trunk
13:22:24  <Ammler> oh wow
13:22:33  <Ammler> now, I got it
13:23:34  <Ammler> the 0.6 branch existed already
13:23:51  <Ammler> so why didn't you simply hg up 0.6, add changes, commit?
13:24:39  <Ammler> the command yexo wrote looked like he created 0.6 from a certain revision
13:25:31  <Ammler> sorry, then all is fine, we talked about different things
13:28:36  <planetmaker> Ammler: that's what we do... hg up 0.6 and commit
13:28:50  <andythenorth> Yexo: " I have an (almost completely automatic) conversion of firs to nml" < that sounds good
13:29:00  <Ammler> [14:50] <Yexo> hg up -r 2048...
13:29:05  <planetmaker> even if 0.6 was created for that... dunno... but doesn't matter. It's 0.6 branch after all
13:29:13  <planetmaker> Ammler: it should be -r2050
13:29:14  <Ammler> that confused me
13:29:35  <Ammler> planetmaker: it should have been 0.6, shouldn't?
13:29:53  <andythenorth> we can do something like diff to see if encoded grf is same for nfo / nml?
13:30:04  <Ammler> 2048 is default
13:30:18  <Ammler> you should not use revisions for such tasks :-)
13:31:15  <Ammler> andythenorth: build one, update to other, build it
13:31:15  <andythenorth> hmm
13:31:33  <Ammler> diff first.nfo second.nfo
13:31:52  <Ammler> maybe you need to tell nml to build the nfo
13:32:18  <Brot6> FIRS Industry Replacement Set - Revision 2051:6e087cfc9af3: Change [Makefile]: Build FIRS from nm... (planetmaker) @
13:32:23  <planetmaker> Yexo: I chose the easiest path: hg mv firs.nml sprites/firs.pnml
13:32:38  <Ammler> andythenorth: add NML_FLAGS="--nfo %{name}.nfo" to make
13:32:38  <planetmaker> pre-processing it doesn't do a thing, but makes sure nothing needs changing in the build script
13:32:55  <Ammler> but I guess, those are completely different
13:33:09  <Ammler> maybe better to decode the grf and compare those nfos
13:33:13  <andythenorth> not sure how this will get tested :P
13:33:21  <andythenorth> we can't play coop games until it's on bananas
13:33:29  <andythenorth> I don't want to put it on bananas until it's tested
13:33:39  <andythenorth> the best way to test is coop games :
13:33:45  <andythenorth> catch 22
13:33:47  <Ammler> andythenorth: you can add to bananas with version restirctions
13:33:57  <Ammler> e.g. for nightlies only
13:34:00  <andythenorth> that defies the point unfortunately
13:34:05  <andythenorth> hmm
13:34:18  <andythenorth> maybe not
13:34:18  <planetmaker> how so?
13:34:24  <andythenorth> maybe it's fine
13:34:29  <Ammler> or add a 2nd entry
13:34:39  <andythenorth> adding a 2nd entry means changing grfid
13:34:42  <planetmaker> don't tag it now though
13:34:44  <Ammler> yep
13:34:45  <andythenorth> which means we can't test it
13:34:48  * andythenorth bbl - work
13:34:52  <planetmaker> first we'll need to test it locally
13:35:00  * andythenorth (exciting)
13:35:05  <andythenorth> but got to go
13:35:05  <andythenorth> byt
13:35:07  *** andythenorth has left #openttdcoop.devzone
13:36:11  <Ammler> if the id is the only thing, which differs, the test can still succeed
13:47:26  <Hirundo> Yexo: Is register_names intended only for item names, or also for others?
14:19:01  <Yexo> only for item names
14:19:17  <Yexo> as you're able to forward-reference those, as opposed to most other names
14:19:29  <Yexo> if you can find more examples that need forward-referencing, they could be added there too
14:21:04  <Yexo> Ammler: sorry for the confusion, I never wanted a 0.6 nightly
14:21:20  <Yexo> I was only afraid that if the cf compiled "tip", it would compile the 0.6 branch instead of the default branch
14:24:39  <Ammler> yexa, yeah and I was thinking, you abused branch 0.6 for feature testing :-)
14:26:47  <Yexo> Ammler: how else to test it?
14:27:33  <Yexo> converting trunk would mean that 2 things at once would be tested: all changes done in trunk AND the conversion script
14:27:42  <Yexo> this way only the conversion script is tested
14:31:34  <Ammler> Yexo: e.g. with branch nml :-)
14:31:58  <Yexo> Ammler: and where should that branch start?
14:32:05  <Yexo> ie branch from 0.6 or from trunk?
14:32:52  <Ammler> well, in the case of firs, in 0.6
14:33:02  <Ammler> but usually you base that on trunk
14:33:12  <Ammler> why do you ask me? :-P
14:33:59  <Yexo> because you apparently disagreed on how it was done
14:34:20  <Yexo> planetmaker: those warnings are expected, these are actually "bugs" in the translations of those strings
14:34:33  <Ammler> well, you added features to a release branch, which is IMO quite ugly
14:34:49  <Yexo> didn't inspect all of them though, but it looks like those are all D0XX or DCXX strings that are in the final grf but never used
14:34:57  <Yexo> I didn't at any feature at all
14:35:01  <Ammler> and initially I thought, you created branch 0.6 for it
14:35:07  <Yexo> I just converted the source code from nfo to nml
14:35:25  <Ammler> quite big change :-P
14:35:37  <Yexo> a big change, yes, a feature, no
14:37:11  <Ammler> never mind, I should not care...
16:17:46  *** bodis has joined #openttdcoop.devzone
17:18:50  <Brot6> firs: update from r2047 to r2048 done -
17:19:08  <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 (r93), basecosts (r25), belarusiantowns (r8), bros (r52), chips (r141), comic-houses (r71), fish (r653), frenchtowns (r6), german-townnames (r34), grfcodec (r831), grfpack (r279), heqs (r605),
17:19:09  <Brot6> indonesiantowns (r41), manindu (r7), metrotrackset (r56), narvs (r37), newgrf_makefile (r294), nml (ERROR r1397), nutracks (r201), ogfx-industries (r119), ogfx-landscape (r69), ogfx-rv (r107), ogfx-trains (ERROR r242), ogfx-trees (r50), opengfx (r673), openmsx (r97), opensfx (r97), smts (r19), snowlinemod (r49), spanishtowns (r10), sub-landscape (ERROR r66), sub-opengfx (ERROR r666), swedishrails (r202), swisstowns (r22),
17:19:10  <Brot6> transrapidtrackset (r15), ttdviewer (r34), ttrs (r36), worldairlinersset (r672)
17:20:12  <Brot6> sub-landscape: compile of r66 still failed (#2616) -
17:21:02  <Brot6> sub-opengfx: compile of r666 still failed (#2586) -
17:45:14  *** Tloo-ZaRaZa has joined #openttdcoop.devzone
18:05:15  *** andythenorth has joined #openttdcoop.devzone
18:06:09  <andythenorth> evening
18:09:18  <Terkhen> hi andythenorth
18:09:18  <andythenorth> how is the FIRS -> NML conversion looking?
18:11:12  * andythenorth reads the commit logs
18:11:22  <planetmaker> working, but completely untested
18:11:35  <andythenorth> wrt 2049 - sugar beet / sugar cane overlap is stupid anyway
18:12:18  <andythenorth> it was one simplification too far - and it's not simpler
18:14:27  <V453000> release of FIRS coming anytime soon? :)
18:19:28  *** Brot6_ has joined #openttdcoop.devzone
18:19:49  <andythenorth> dunno :)
18:19:49  *** Brot6 is now known as Guest4471
18:19:50  *** Brot6_ is now known as Brot6
18:20:30  *** Brot6 has quit IRC
18:21:15  *** Brot6 has joined #openttdcoop.devzone
18:23:55  *** Brot6_ has joined #openttdcoop.devzone
18:24:16  *** Brot6 has quit IRC
18:24:43  *** Brot6_ is now known as Brot6
18:25:29  *** Guest4471 has quit IRC
18:25:58  *** Brot6 has joined #openttdcoop.devzone
18:36:11  <andythenorth> so how do I build FIRS with nml?
18:36:30  <Ammler> hg up 0.6
18:36:31  <Ammler> make
18:36:46  <Brot6> FIRS Industry Replacement Set - Revision 2045:61b0849896c4: Cleanup: forget deleted file (andythenorth) @
18:37:05  <andythenorth> ?
18:37:18  <andythenorth> where did that come from ^
18:37:36  <planetmaker> brot joined
18:37:41  <andythenorth> ah ok
18:37:53  <andythenorth> why am I going to 0.6?
18:37:59  <andythenorth> if we're already at 0.6.4?
18:38:09  <Terkhen> that is the 0.6 branch
18:38:16  <andythenorth> ok
18:38:34  <andythenorth> the make file thinks that grfcodec is being used
18:39:38  <planetmaker> hm
18:39:51  <planetmaker> hg parent gives you what?
18:40:38  <andythenorth> changeset 1717, branch 0.6
18:41:16  <andythenorth> also do I need to install nmlc?
18:41:42  <Ammler> hehe, you still don't have nmlc installed?
18:42:10  <andythenorth> no
18:42:12  <planetmaker> hm... 1717 is way too early
18:42:21  <planetmaker> you need to update to tip of that branch
18:43:02  <planetmaker> hg up tip
18:43:12  <planetmaker> is missing :-)
18:43:25  <andythenorth> that gets me 2051
18:43:32  <andythenorth> still on 0.6 branch
18:43:34  <planetmaker> that should work then
18:43:38  <planetmaker> yes, don't you want that?
18:43:50  <andythenorth> currently yes
18:43:53  <andythenorth> I do
18:43:57  <planetmaker> hg up default
18:43:58  <andythenorth> how do I switch back to trunk?
18:44:01  <andythenorth> oh thanks
18:44:02  <planetmaker> hg up
18:44:53  <Ammler> usually, hg up <branch> should update to branch head
18:45:27  <planetmaker> seems it doesn't
18:45:35  <planetmaker> rather to base of branch
18:45:49  <andythenorth> interestink
18:46:53  <Ammler> hmm
18:47:47  * andythenorth needs nmlc :P
18:50:51  <andythenorth> I was missing bin/buildout in my existing clone of nml
18:51:11  <andythenorth> can fail on certain edge cases
18:51:21  <andythenorth> typically if it has the eggs or parts I think
18:51:41  <andythenorth> it then forgets to fetch deps, even if they are missing on local file system
18:51:51  <andythenorth> anyway....
18:51:53  <andythenorth> I now have nmlc
18:52:01  <andythenorth> regression tests failed, but does that matter?
18:52:02  <Ammler> I guess, firs is broken
18:53:06  <Terkhen> why did they fail?
18:55:18  <planetmaker> regressions shouldn't fail
18:55:23  <Ammler>
18:55:24  <Webster> Title: StandardBranching - Mercurial (at
18:55:41  <Ammler> Terkhen: the main issue might be that firs has tag and branch with 0.6
18:56:06  <Terkhen> that does not seem related to nml regression tests failing
18:56:12  <Ammler> ah no
18:56:15  <Ammler> sorry
18:56:25  <Ammler> thought you asked me about why firs repo is broken
18:56:27  <planetmaker> yes, broken. tag name = branch name
18:56:45  <Terkhen> but the tag will be 0.6.5, right?
18:56:55  <Ammler> Terkhen: there is already a tag 0.6
18:57:06  <Terkhen> oh :P
18:57:12  <Terkhen> that one should have been 0.6.0
18:58:33  <Ammler>
18:58:34  <Webster> Title: StandardBranching - Mercurial (at
19:01:30  <Ammler> does someone fix that?
19:02:21  <Ammler> [21:01] <mpm> Ammller: Anyway, you should be able to 'hg up -r "branch(0.6)"'
19:02:50  <Ammler> planetmaker: but usually it does update to branch head
19:03:39  <Ammler> tags have just higher prio
19:05:37  <planetmaker> yup. I wasn't aware of that odditiy
19:06:04  <Ammler> shall I push the tag rename?
19:06:24  <planetmaker> no
19:06:34  <planetmaker> it's a release tag
19:09:18  <Ammler> well, you know it now :-)
19:09:30  <Ammler> you should have already :-P
19:11:17  <Ammler> also firs nml doesn't build here
19:11:54  <Ammler> "lang/07.lng", line 10: String commands don't match with english.lng
19:12:15  <Ammler> "<stdin>", line 1445: Block 'action2_1935' is not referenced, ignoring.
19:13:04  *** Tloo-ZaRaZa has quit IRC
19:25:54  <andythenorth> nmlc tests fail:
19:28:01  <planetmaker> nmlc --version ?
19:28:08  <planetmaker> you use nml head?
19:28:58  <andythenorth> r1335 (e58a0870d613)
19:29:23  <andythenorth> changeset is 1397
19:29:32  <andythenorth> for tip
19:29:36  <planetmaker> that's about ancient
19:29:38  <planetmaker> r1371 (e6ed9af9b7ba)
19:30:08  <andythenorth> hmm
19:30:14  <andythenorth> there's another nml repo somewhere?
19:31:17  <planetmaker> no. I didn't have head either ;-)
19:31:35  <planetmaker> missed 26 revisions
19:32:18  <andythenorth> how do I tell my system where nmlc is?
19:32:24  <andythenorth> should I just move it /bin or something?
19:32:35  <andythenorth> or do I need to export a path?
19:33:42  <Yexo> cp Makefile.local.example Makefile.local
19:33:55  <Yexo> edit Makefile.local, especially the line with NMLC = in it
19:34:08  <Yexo> at least, that's how I do it, but I never install nml
19:34:08  <andythenorth> I used to have a Makefile.local for FIRS
19:34:14  <andythenorth> wonder where it went :P
19:34:17  <andythenorth> maybe I deleted it
19:34:52  <andythenorth> I can't just make nmlc available system-wide?
19:35:00  <Yexo> sure you can, just install it
19:35:53  <Ammler> and install it again after pull
19:36:33  <andythenorth> ok so Makefile.local solves the path issue
19:36:47  <andythenorth> now nmlc fails on lang, so same issue as everyone else has?
19:37:10  <andythenorth> I also got: nmlc: "<stdin>", line 295: Syntax error, unexpected token "}"
19:37:13  <Yexo> does it fail or just spit out warnings?
19:37:23  * planetmaker has a symlink from /usr/local/bin/nmlc ot /path/to/nmlc
19:37:59  <andythenorth>
19:38:05  <andythenorth> might just be on the wrong rev?
19:38:21  <andythenorth> changeset:   2051:6e087cfc9af3
19:38:45  <Yexo> looks correct, and "nmlc --version" ?
19:38:56  <planetmaker> hg parent
19:38:58  <planetmaker> Ă„nderung:        2051:6e087cfc9af3 works for me
19:39:04  <Yexo> for me too
19:39:06  <planetmaker> with nmlc 1397
19:39:18  <Yexo> nmlc r1403 here, but you can't have that yet :p
19:39:43  <planetmaker> :-P
19:40:38  <Yexo> andythenorth: you'll get that error if you have an nml version < r1342
19:41:01  <Yexo> so it looks like that's still your problem
19:42:16  <Yexo> planetmaker: can you disable the "don't push .grf files" for nml?
19:42:41  <planetmaker> isn't it?
19:42:55  <Yexo> no, I can't push 2 new regression tests
19:43:14  <planetmaker> hm... I know how to disable it globally. But not per repo...
19:43:39  <Yexo> if you can explain that, I can do that temporarily whenever I need to push a new regression test
19:44:08  <planetmaker> there is a local solution to that, so much I know. And I *thought* it was installed
19:44:12  <planetmaker> Ammler said it was :-P
19:44:52  <Ammler> .devzone/hooks
19:44:58  <planetmaker> the global commit hook is as user hg found in ~/.hgrc
19:45:20  <Yexo> nml/.devzone/hooks/repo_check.ini doesn't have grf as bad-ending
19:45:38  <planetmaker> maybe it's a "both applies" setting?
19:45:42  <planetmaker> I disabled the global one
19:45:55  <Yexo> thanks, pushed now
19:46:00  <Yexo> so you can enable it again
19:46:04  <Brot6> NewGRF Meta Language - Revision 1398:3c182d2404c2: Change: remove if-blocks with expressions that... (yexo) @
19:46:04  <Brot6> NewGRF Meta Language - Revision 1399:79de6ebc5f96: Add: very basic regression test for conditionals (yexo) @
19:46:04  <Brot6> NewGRF Meta Language - Revision 1400:8ae0d7be719d: Fix: reduce the conditional of a loop before u... (yexo) @
19:46:06  <Brot6> NewGRF Meta Language - Revision 1401:c49986782407: Add: regression test for loop (yexo) @
19:46:09  <Brot6> NewGRF Meta Language - Revision 1402:accbd593b0c6: Doc: documentation for ast/loop (yexo) @
19:46:12  <Brot6> NewGRF Meta Language - Revision 1403:d1e22ba6877b: Doc: add some more documentation about AST-nodes (yexo) @
19:47:11  <planetmaker> oh, that sounds like a lot of nice fixes :-)
19:47:16  <Ammler> well, you made Alberth leaving, so we can't ask him, why it doesn't work anymore :-P
19:47:55  <Yexo> no "fixes" in the sense that something was broken
19:48:08  <planetmaker> I see that, yes
19:48:24  <Yexo> some docs and a few new tests, and a minor optimization for if(1) and if(0)
19:48:55  <Brot6> nml: update from r1396 to r1403 done -
19:51:54  * andythenorth wonders how to build a newer nmlc
19:53:10  <Yexo> do "hg pull -u" first
19:53:15  <Yexo> after that something with buildout
19:53:18  <andythenorth> I did :)
19:53:22  <andythenorth> it's a clean checkout of head
19:53:27  <andythenorth> or previous head :P
19:53:33  * andythenorth 1 minute
19:53:36  <Yexo> so what does "python2.6 nmlc --version" tell you?
19:53:59  <Yexo> in the directory where you checked out nml
19:54:25  <andythenorth> r1397
19:54:48  <andythenorth> the version placed in bin by buildout is 1335
19:55:00  <andythenorth> I have a completely other issue that hg can't pull right now for some reason :P
19:55:01  <andythenorth> but meh
19:55:03  <planetmaker> might be the issue
19:56:52  <andythenorth> hmm
19:56:58  <andythenorth> the buildout might need fine tuning
19:57:21  <andythenorth> it seems to be placing an old version of nmlc in bin
19:58:42  <andythenorth> wonder where it gets it from :P
19:58:45  <andythenorth> ?
19:59:15  <planetmaker> Yexo: totally different topic: doesn't our openttd wiki have the API access, too which mediawiki offers?
19:59:36  <Yexo> planetmaker: yes, the openttd wiki has API access, but only via https
19:59:46  <Yexo> that's all in the diff I uploaded earlier
20:00:00  <Yexo> that's how I run Yexo_bot doing the translations work
20:00:21  <Yexo> see
20:00:47  <planetmaker> hm, ok, then I must have mis-remembered / understood something
20:01:47  <Yexo> basically: download the pywikipedia framework (I use svn r9011 here), apply and you're good to go
20:02:02  <Yexo> to use it on another wiki you'll have to create your own family file
20:03:55  <andythenorth> hmm
20:05:36  <planetmaker> no worries, I can connect to the wiki and edit it, that works :-)
20:06:42  <andythenorth> python2.6 --version
20:06:48  <andythenorth> is r1335
20:07:16  <Yexo> and "hg parents" in the same directory?
20:07:28  <planetmaker> the only thing I need to teach it now are the advanced sed expressions ;-)
20:08:04  <andythenorth> parents is r1403
20:08:06  <planetmaker> but that's for another day... bed is calling, early morning ahead
20:08:12  <planetmaker> good night
20:08:36  <Yexo> andythenorth: can do you "rm" and after that try "python2.6 --version" again?
20:08:46  <Yexo> good night planetmaker
20:09:06  <andythenorth> r1335
20:09:09  <andythenorth> :|
20:09:50  <Yexo> and "hg -R . id -n -t -i" ?
20:10:19  <andythenorth> d1e22ba6877b 1403 tip
20:10:21  <Yexo> hmm, nvm
20:10:27  <Yexo> first do "cd .."
20:10:31  <Yexo> than try "python2.6 --version"
20:10:36  <Yexo> +nmlc
20:10:52  <Yexo> if you're inside the "nml" directory, it'll use the installed version of nml, not that local copy
20:11:20  * andythenorth might have nmlc somewhere else...?
20:11:37  <andythenorth> oops
20:15:55  <andythenorth> :D
20:16:01  <andythenorth> this is byzantine
20:16:57  * andythenorth gives in and edits the shebang for /nmlc in the checkout 
20:16:59  <andythenorth> :|
20:17:06  <andythenorth> this is not how I envisaged it :(
20:22:07  <andythenorth> I'll have to ask someone further how buildout works
20:22:11  <Lakie> Hmm. the callbacks page is  real mess.
20:22:23  <andythenorth> I don't see where buildout is getting nml r1335 from to install in bin
20:22:32  <andythenorth> it's nowhere on my local filesystem
20:39:49  <Brot6> NewGRF Meta Language - Bug #2649: allocation sprites/spritelayouts (yexo) @
20:40:13  <Yexo> Hirundo: whenever you have the time, please read / respond to #2649
20:40:14  <Brot6> Yexo: Hirundo: #2649 is "NewGRF Meta Language - Bug #2649: allocation sprites/spritelayouts - #openttdcoop Development Zone"
20:41:55  <Hirundo> I'm currently reading and processing
20:44:57  <andythenorth> FIRS compiles for me - with errors
20:45:23  <andythenorth> Yexo: the errors are string commands and unreferenced blocks
20:45:32  <andythenorth> is a paste useful?
20:45:32  <Yexo> both are "bugs" in firs
20:45:38  <andythenorth> :)
20:46:02  <andythenorth> so it builds etc.  It doesn't work in game
20:46:04  <Yexo> just ignore all that, those are actually warnings
20:46:09  <Yexo> it doesn't? it does for me
20:46:25  <andythenorth> it fails a compatibility check
20:46:31  <andythenorth> and disables itself
20:46:43  <Yexo> which openttd version?
20:46:53  <andythenorth> trunk tip I think
20:46:54  <andythenorth> let me check
20:47:17  <Yexo> "trunk" it good enough
20:50:29  <Ammler> Yexo: might it be the issue with hook is that nml hook ini has just one setting?
20:50:43  <Yexo> Ammler: no idea
20:51:10  <Yexo> andythenorth: hmm, I thought it worked before :(
20:51:17  <andythenorth> you get this error?
20:51:17  <andythenorth> 	"EE00: FIRS requires OpenTTD 1.1.0 / trunk r21208 or higher. Consult FIRS ReadMe: E\0D" 00 //message
20:51:18  <Lakie> I don't suppose this new wiki thing supports bullet points?
20:51:27  <Yexo> it does
20:51:42  <Yexo> just start each line with a "* "
20:51:51  <Yexo> see for example
20:52:06  <Lakie> Oh, ok, it must be rejecting them from the spaces it copied before
20:52:48  <Lakie> Trying to clean up some of the objects stuff.
20:53:15  <Lakie> What should I do about the links though, cause you have to put in .28<num>.29 for it to link correctly now
20:53:49  <Yexo> [[TextIDs]] creates a link to the TextIDs page
20:54:40  <Ammler> I am able to push .grf
20:54:47  <Ammler> hmm, very strange
20:54:49  <Yexo> oh, you want to link to separate properties
20:54:59  <Yexo> Ammler: pm disabled the check, not sure he enabled it again
20:55:17  <Brot6> Nutracks - Revision 202:9215e783d592: Added own fences for everything but monorail and maglev (oberhuemer) @
20:55:32  <Brot6> test: update from r104 to r105 done -
20:55:33  <Lakie> Yeah, and most of them have (<num>) which makes for interesting urls
20:55:49  <Yexo> yes, I don't see an easy way around that
20:56:05  <Yexo> where do you link to a property though?
20:56:08  <Ammler> Yexo: he enabled it again
20:56:12  <Brot6> nutracks: update from r199 to r202 done (9 errors) -
20:56:19  <Ammler> I got the reject
20:56:25  <Brot6> test: update from r105 to r107 done -
20:56:30  <Ammler> then I edit .devzone/hooks/repo_check.ini and can push
20:56:44  <Lakie>
20:56:45  <Webster> Title: VarAction2Objects - GRFSpecs (at
20:56:57  <Lakie> Quite a number reference other features variables
20:57:16  <Yexo> ah, right :)
20:58:47  * andythenorth -> bedtime
20:58:52  <andythenorth> goodnight ;)
20:58:55  <Lakie> Night
20:59:09  <Yexo> Lakie: you can use ( and ) in the url and the wiki software will rewrite it for you
20:59:10  <Lakie> I don't envy the person who tries to fix the callbacks page though
20:59:24  <Lakie> Oh really? tht makes my life easier
21:00:12  <Ammler> <-- worked fine
21:00:41  <Brot6> test: update from r107 to r109 done -
21:00:43  <Ammler> you can also add a .grf file with one commit, then change the ini with a later commit and it uses always that ini
21:01:31  <frosch123> Lakie: you can do a lot with scripts
21:01:42  <frosch123> industrydefaultprops was the most troublesome till yet :)
21:01:50  <Lakie> Thats true
21:02:06  <Lakie> Though about 3/4's of the page seems garbled slightly
21:04:25  <Yexo> it's not as bad as it looks
21:04:59  <Lakie> Thats probably true
21:05:12  <Brot6> NewGRF Meta Language - Revision 1404:e90e0302347a: [CF] Fix (r1238): local repo check ini wrong s... (Ammler) @
21:05:17  <frosch123> i think we converted around 10% today, let's see how it will look next week
21:05:44  <Lakie> Heh, well, I cleaned up Action0 Objects and Objects Action2 vars.
21:06:51  *** andythenorth has left #openttdcoop.devzone
21:08:47  <Yexo> thanks Ammler :)
21:09:32  <Ammler> yeah, it took some time to fiqure out that silly issue :-P
21:10:57  <frosch123> night
21:11:00  *** frosch123 has quit IRC
21:11:10  <Ammler> <-- this the hook script, since you are such python specialists, please feel free to commit changes and tell me to update local workcopy
21:12:09  <Yexo> I'm definitely not a python specialist, and I don't see a reason to change it as it works fine
21:12:22  <Ammler> :-)
21:13:01  <Ammler> yes, Alberth made good job
21:14:17  <Ammler> you can use it locally as commit hook btw.
21:14:41  <Yexo> too much work :p
21:14:44  <Yexo> it works fine as it is
21:27:49  <Hirundo> Yexo: wrt. #2649
21:27:49  <Brot6> Hirundo: Yexo: #2649 is "NewGRF Meta Language - Bug #2649: allocation sprites/spritelayouts - #openttdcoop Development Zone"
21:27:54  <Lakie> How does one span a column on media wiki?
21:28:08  <Hirundo> At what point are sprite sets actually emitted?
21:28:57  <Yexo> during step 6, but at the location allocated by the previous time the global storage was flushed (also step 6)
21:29:26  <Yexo> flush global storage = here starts a new action1, the contents of which can be filled at a later point
21:31:16  <Hirundo> Basically for each spritelayout, you check if the referenced spritesets can be added to the previous action1
21:31:34  <Hirundo> if so add them, if not create a new action1 (possibly duplicating sprites)
21:31:38  <Hirundo> right?
21:32:11  <Yexo> Lakie: instead of |- | column 1 || column 2 || column 3 use |- | rowspan="2"| column 1 and 2 || column 3
21:32:24  <Yexo> Hirundo: yes
21:32:28  <Lakie> Thanks. :)
21:32:40  <Yexo> see for more examples
21:32:41  <Webster> Title: Help:Table - Meta (at
21:32:56  <Hirundo> Yexo: Makes sense
21:33:46  <Hirundo> Then, at a later stage, we could detect duplicated sprites and possibly GRM those
21:34:05  <Yexo> not sure if that is a task for the compiler, but yet
21:34:19  <Yexo> not saying it isn't, we'll have to investigate that
21:34:50  <Hirundo> From a user POV it isn't his problem
21:36:12  <Hirundo> We'll see when/if we get a use case (FIRS ground tile?) where sprites are duplicated many times, so GRM is worth the coding effort on our part
21:36:28  <Brot6> NewGRF Meta Language - Feature #2739 (New): Advanced sprite layouts (yexo) @
21:38:07  <Yexo> Hirundo: I didn't exactly follow the commits / changes to persistent storage today
21:38:17  <Yexo> are grfs now able to store things in registers belonging to another grf?
21:38:27  <Yexo> (talking about #2738)
21:38:27  <Brot6> Yexo: #2738 is "NewGRF Meta Language - Feature #2738: Proper support of persistent storage - #openttdcoop Development Zone"
21:39:16  <Hirundo> only for towns
21:39:29  <Hirundo> AFAIK they can read all storages, but only write to its own
21:40:02  <Yexo> that sounds like I was expecting it
21:40:09  <Yexo> was just confused a bit by this: "STORE_PERM(value, register, grfid = own_grfid)"
21:40:53  <Hirundo> The grfid bit should only apply to LOAD_PERM, yes
21:41:29  <Hirundo> Storing still needs pushing 0xFFFFFFFF into register 0x100, though
21:42:08  <Yexo> why is that?
21:42:26  <Yexo> that sounds like a very silly requirement
21:44:06  <Hirundo> See newgrf_town.cpp:148
21:44:35  <Hirundo> Terkhen: Why is providing a grfid necessary for storage?
21:44:57  <Hirundo> (see short discussion above)
21:47:39  <Yexo> can't find anything in the logs about that (but as said, I didn't follow the discussion at all)
21:57:30  <Hirundo> goodnight folks
22:09:20  *** ODM has quit IRC
22:10:22  *** bodis has quit IRC
22:47:30  <Terkhen> Hirundo: it is only required for town storage
22:47:55  <Terkhen> we were concerned about a lot of newgrfs trying to access the same storage without knowledge of what else might be modifying it
22:48:17  <Terkhen> debugging games with multiple newgrfs that use town storage would become a nightmare
22:48:54  <Terkhen> that's why the newgrf must use the storage with some knowledge about what it is doing (by providing the grfid) instead of jumping blindly to the data
22:49:53  <Terkhen> for now we decided that two different newgrfs should not be able to access the same town storage, but that might change in the future
22:50:11  <Terkhen> if deemed necessary, useful and not prone to confusion after testing the current support :)
22:51:00  <Terkhen> it would not allow access to "real grfids", though, but to some common storages with predefined, known grfids (for example, the 0xF000000-0xFFFFFFFE range)
22:51:16  <Terkhen> but that should wait until we see how the new feature is used
22:52:37  <Terkhen> if something did not made sense, ask me again tomorrow :)
22:52:39  <Terkhen> good night
23:01:34  <Yexo> Terkhen: ah, so it's to allow extension in the future? that makes sense

Powered by YARRSTE version: svn-trunk