Log for #openttdcoop.devzone on 16th June 2011:
Times are UTC Toggle Colours
05:35:20  *** bodis has quit IRC
06:16:25  *** ODM has joined #openttdcoop.devzone
09:57:30  *** ODM has quit IRC
14:05:55  *** ODM has joined #openttdcoop.devzone
14:26:45  <Brot6> NewGRF Meta Language - Revision 1406:06172003d8ed: Codechange: Create a separate AST node for sto... (Hirundo) @
14:26:45  <Brot6> NewGRF Meta Language - Revision 1407:6938276b9030: Feature #2738: Validate that persistent storag... (Hirundo) @
14:26:45  <Brot6> NewGRF Meta Language - Revision 1408:e576bc74a535: Feature #2738: For town register accesses, sto... (Hirundo) @
14:26:47  <Brot6> NewGRF Meta Language - Revision 1409:c3cfeac94560: Doc #2738: Improve documentation of temporary ... (Hirundo) @
14:27:41  <Brot6> NewGRF Meta Language - Feature #2738 (Closed): Proper support of persistent storage (Hirundo) @
14:27:56  <planetmaker> :-)
14:31:32  <Terkhen> nice :)
14:31:42  <Brot6> NewGRF Meta Language - Revision 1410:ed2e615f955e: Doc: Explicitly mention that accessing town re... (Hirundo) @
14:31:44  <Terkhen> now we can start to implement crazy stuff
14:31:55  <Hirundo> Lots of code added, just to keep users from doing stupid stuff
14:32:20  <planetmaker> :-)
14:32:31  <planetmaker> that'll be virtually impossible, I guess
14:33:24  <Terkhen> STORE_PERM for towns just uses always 0xFFFFFFFF?
14:33:43  <Hirundo> yes
14:34:39  <Terkhen> ok :)
14:36:09  <Yexo> nice changes :)
14:42:31  <Brot6> NewGRF Meta Language - Feature #2739: Advanced sprite layouts (yexo) @
14:42:57  <Brot6> NewGRF Meta Language - Feature #2739: Advanced sprite layouts (yexo) @
14:56:39  *** frosch123 has joined #openttdcoop.devzone
15:12:08  <Hirundo> For NML stations, how about putting all sprites in a single action1 set, basically making CB 0 a dummy and doing the entire layout / sprite selection via CB 14 and extended sprite layouts
15:13:54  <planetmaker> if that works and makes it easier: why not :-)
15:14:22  <Yexo> Hirundo: the problem is more how the nml syntax should look
15:14:44  <Hirundo> The same as for current industry tiles
15:15:03  <Yexo> but for industry tiles the "spritelayout" block refers to actual sprites
15:15:04  <Hirundo> NML should fix it under the hood
15:15:22  <Yexo> for stations you can have one "spritelayout" (in other words, the bounding boxes) block and use different real sprites
15:15:30  <Yexo> since the bounding boxes are in action0, not action2
15:15:36  <Yexo> the action2 is just to link to action1's
15:15:50  <Hirundo> I know
15:16:19  <Hirundo> The layout is put (internally) in an action0 property
15:16:58  <Hirundo> The sprite selection is not done via CB0/action2 but entirely via the ESL registers
15:17:09  <planetmaker> If it would use the same syntax, it'd be awesome
15:17:19  <Yexo> Hirundo: again, that's the nfo side of the story
15:17:21  <planetmaker> unless it looses (many) options
15:17:25  <Yexo> I think the nml side is the problem here
15:18:53  <Hirundo> You'd need to define all sprite layouts in all stations (using the 'copy' property if possible)
15:19:38  <Yexo> Hirundo: could you write an example nml file that uses your proposed syntax?
15:19:49  <Yexo> we can worry about how to implement it exactly later
15:20:57  <Hirundo> I'll put something together
15:32:02  <Hirundo> Yexo:
15:36:32  <Yexo> Hirundo: you're interpreting the specs in the wrong way, this is not how stations work
15:36:51  <Yexo> callback 14 only selects the spritelayout, not the actual graphics (for stations graphics and bounding boxes are not linked)
15:37:18  <Yexo> cb 0 (=no callback) choses the appropriate action1
15:37:28  <Hirundo> yes
15:37:34  <Yexo> so where yo put CB_FAILED (line 31 of the pastebin) should actually be some varaction2 to select the actual graphics
15:37:52  <Hirundo> notice the comment in the graphics block
15:38:20  <Yexo> I do, but like this it means nmlc would have to semantically analyze all switch-block expressions
15:38:40  <Hirundo> why?
15:38:47  <Yexo> if you make it a named callback (#1555) it might work
15:38:48  <Brot6> Yexo: #1555 is "NewGRF Meta Language - Feature Request #1555: Explicitly define callbacks - #openttdcoop Development Zone"
15:38:58  <Hirundo> That'd be a nicer solution indeed
15:39:13  <Yexo> Hirundo: cb14 can't refer (even indirectly) to any spriteset
15:39:22  <Hirundo> but for now, emitting an extra varaction2 along with the action3 is no problem, right?
15:39:32  <Hirundo> There is only one sprite set in my proposal
15:39:40  <Yexo> the CB_FAILED on line 31 has to be changed to something that indicates the proper set from the action1, which is something nml can't do automatically
15:40:08  <Yexo> oh, everything in a single action1 set?
15:40:12  <Hirundo> yes
15:41:36  <Yexo> so every CB_FAILED for FEAT_STATIONS can be rewritten to the same action1 reference
15:41:59  <Yexo> that limits nml to 65k real sprites for all stations together :p
15:42:35  <planetmaker> that'll be WAY too few ;-)
15:44:53  <Hirundo> The only limit I can see so far, is that the convenience of action3 (easy selection of cargo type to show) is gone.
15:45:16  <Yexo> Hirundo: tricky case: the value of ttd_sprite can be set to param[3]. param[3] can be changed before the next spritelayout, which also sets ttd_sprite to param[3]
15:45:38  <Hirundo> You can use var 60 for that purpose, but it's a bit cumbersome and probably slow
15:45:39  <Yexo> expected behavior by an nml user would be two different spritelayouts, although you have to define all spritelayouts at once in an action0
15:45:42  <Hirundo> Yexo: good point
15:46:01  <Yexo> <Hirundo> The only limit I can see so far, is that the convenience of action3 (easy selection of cargo type to show) is gone. <- that is a very big limitation
15:46:23  <Yexo> it doesn't look like it, but there is no other good way to select the cargo type with the highest amount of cargo on the station
15:46:44  <Hirundo> Implementation of action3 is quite ugly, though, it just loops through all cargo types and selects the first non-empty one
15:48:06  <Hirundo> Getting that information by means of a variable would be a feature request
15:48:14  <Ammler> planetmaker: would that suiffice as cleaner for the "nml nfos"? rm $(ls sprites/nml/*/*.pnml | sed s/nml/nfo/g)
15:48:49  <Hirundo> Then you'd also get the one with the highest amount, instead of the one with the lowest cargo id
15:49:03  <Yexo> Hirundo: even than it feels like we're trying to cram some completely different featuresin the same nml structure
15:49:09  <Yexo> it just doesn't fit so well in this case
15:49:26  <planetmaker> Ammler: the files have the same name except nfo and nml differ both in path and extension
15:49:48  <Ammler> planetmaker: so you agree?
15:50:00  <Ammler> then we don't need a rename to nml.nfo
15:50:14  <Yexo> Hirundo: where in the openttd code do I find that loop for station action3?
15:50:30  <Hirundo> I'd totally support a different approach, if its benefits outweigh the lesser consistency
15:50:39  <planetmaker> Ammler: the CF may do that. The makefile itself should not
15:50:44  <Hirundo> newgrf_station.cpp:573
15:50:52  <Ammler> planetmaker: target mainainter-clean
15:51:02  <planetmaker> yes, ok
15:51:07  <planetmaker> that may do that, too
15:51:12  <Ammler> well, I don't care
15:51:24  <planetmaker> maintainer-clean is better place indeed
15:51:25  <Ammler> could add it the the build spec only, if you prefer
15:51:38  <Ammler> :-)
15:51:40  <planetmaker> I only thought about the normal clean (again)
15:52:21  <Ammler> I'll add it to the
15:52:38  <Ammler> only accessable with NML2NFO
15:53:35  <Yexo> frosch123: is it intended that action3 for stations picks the first cargo that has an amount > 0 at the station instead of the cargo with the greatest amount of cargo?
15:53:45  <planetmaker> :-)
15:53:57  <Yexo> I always thought it'd pick the highest amount of cargo, but Hirundo just pointed out some code that proves me wrong
15:54:16  <Hirundo> The param[3] issue is a nasty one....
15:54:35  <Ammler> hmm, what is distclean again?
15:54:54  <Yexo> Hirundo: it can be worked around by assigning the value to a temporary parameter that is freed after the action0
15:55:09  <Yexo> that might use too many registers though
15:55:13  <Hirundo> ^My thoughts exactly
15:55:30  <Yexo> what we would need for that is something that follows register to see when they're used
15:55:37  <Ammler> like mrproper
15:55:46  <Hirundo> At compile-time, I suppose?
15:55:56  <Yexo> yes, that'd also benefit named parameters
15:56:02  <frosch123> Yexo: no idea, i would guess most grfs only know one cargo
15:56:26  <Yexo> frosch123: chips knows a lot of cargos for each station tile
15:56:39  <planetmaker> Ammler: distclean is for distribution builders
15:56:39  <Hirundo> frosch123: same for ISR
15:56:45  *** ODM has quit IRC
15:57:17  <Yexo> it can be implemented in nfo by a very long varaction2 using var 60 for each cargo type, but that is definitely not the way to go
15:57:24  <frosch123> should we check what ttdp does?
15:57:32  <Yexo> yes please :)
15:57:40  <Yexo> can't find anything specific about it in the specs
15:59:21  <Ammler> shouldn't I be able to run "make clean all" ?
16:00:12  <planetmaker> in principle, yes
16:00:20  <planetmaker> but... it might mix order of execution
16:00:24  <Ammler> hmm, maybe I call is simply nml-clean
16:01:14  *** TheODM has joined #openttdcoop.devzone
16:01:23  <planetmaker> is there already a maintainer clean?
16:01:38  <planetmaker> then it should be among that
16:01:48  <planetmaker> it could become a double colon rule:
16:01:55  <planetmaker> maintainer-clean::
16:01:56  <Ammler> no, but I am not sure, it would be spec conform
16:02:14  <planetmaker> it would be
16:02:24  <planetmaker> that's IMHO exactly what a maintainer-clean should do
16:02:36  <planetmaker> delete everything, really everything which can be re-built
16:03:07  <Ammler> is there something else?
16:04:25  <Hirundo> Yexo: Each sprite within the sprite layout should also get an "axis: AXIS_[X|Y];" property to easily enable/disable certain sprites depending on orientation
16:04:55  <Ammler> what does the double colon mean?
16:05:00  <Yexo> yes, indeed
16:05:06  <Ammler> maintainer-clean could depend on distclean
16:05:09  <Hirundo> Due to the way layouts / CB 14 work, we need to double all layouts anyway so it's no big issues
16:05:16  <Yexo> can you please wait with implementing this? I want to see if I can come up with a better solution this weekend
16:05:19  <frosch123> Yexo: ttdp also seems to pick the first one found
16:05:34  <frosch123> but, i guess we should change it nevertheless
16:06:13  <frosch123> (newsprit.asm:287 for reference)
16:06:16  <Hirundo> Yexo: I'll do, I got enough exams to keep me busy anyways
16:06:35  <Yexo> frosch123: great :)
16:06:47  <Yexo> still can't think of a use for picking the first over the one with most cargo
16:06:56  <Hirundo> Easier coding? :)
16:07:22  <Ammler> planetmaker: btw. mostlyclean looks like mrproper
16:07:31  <Hirundo> Now, I'm going to eat something first
16:07:33  <frosch123> yeah, "jnz .gotcargo" vs. remembering the maximum and comparing it every time
16:07:52  <Terkhen> :P
16:18:07  *** TheODM has quit IRC
16:18:46  *** ODM has joined #openttdcoop.devzone
16:37:12  *** bodis has joined #openttdcoop.devzone
16:37:53  <Ammler> planetmaker: also wyh does opengfx need USE_NML2NFO and not simply scan for nmlc?
16:38:28  <planetmaker> good question
16:48:34  <Ammler> planetmaker: this doulbe colon means, I can have multiple maintainer-clean?
16:48:56  <planetmaker> exactly
16:48:59  <Ammler> so if you ever add a maintainer-clean to the framework, opengfx would still work?
16:49:04  <planetmaker> yep
16:49:15  <planetmaker> see the test target
16:49:30  <planetmaker> the order of execution is undefined, but that doesn't matter here
16:49:56  <Ammler> might also be useful for .PHONY
16:50:26  <planetmaker> hm?
16:50:32  <planetmaker> what does that have to do with it?
16:50:43  <planetmaker> maintainer-clean of course is a hphony target, but...?
16:57:20  <Ammler> because .PHONY is in framework
16:57:25  <Ammler> but the target I add isn't
16:58:53  <planetmaker> well... maintainer-clean as phony should go to the framework
16:59:04  <planetmaker> but adding it there is not that important really
16:59:24  <planetmaker> it only avoids that maintainer-clean will ever be interpreted as filename
16:59:42  <planetmaker> thus make maintainer-clean would fail, if a file with that exact name exists
17:08:33  <Brot6> OpenGFX - Revision 675:eaf6e57f26c8: Change/Fix: force to rebuild pnfo from nml and compare results (Ammler) @
17:08:49  <Ammler> I'll add it to the spec temporarly, maybe we want to "reorganize" nml anyway
17:10:08  <Ammler> is it a but that installed nmlc doesn't work without english.lng, but local nmlc does
17:10:13  <Ammler> a bug*
17:10:42  <Ammler> or it it a bug that local nmlc does work wihtout english.lng? :-)
17:12:18  <Yexo> Ammler: there is no difference between an installed and a local nml
17:12:27  <Yexo> at least if the version is exactly the same
17:12:31  <Ammler> Yexo: I have learned there are lots :-)
17:12:51  <Yexo> please tell
17:13:28  <Ammler> Yexo: to reproduce, build opengfx with USE_NML2NFO
17:13:38  <Ammler> once with local nmlc it works
17:13:43  <Ammler> with installed nmlc it doesn0t
17:13:48  <Ammler> hmm
17:15:56  <Yexo> works fine with installed nml here
17:18:23  <Yexo> local nml also works
17:18:28  <Yexo> but both need lang/english.lng
17:21:59  <Ammler> I got this: nmlc: Default language file "lang/english.lng" doesn't exist
17:22:10  <Ammler> but not on local nmlc
17:22:57  <Ammler> hmm
17:22:59  <Ammler> strange
17:23:49  <Ammler> well, then I am sorry
17:29:17  <Ammler> I can't reproduce
17:31:58  <Brot6> firs: update from r2056 to r2059 done -
17:35:48  <Brot6> nml: update from r1405 to r1410 done -
17:37:01  <Brot6> OpenGFX - Bug #2745 (New): DevZone compile failed (compiler) @
17:37:01  <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:37:01  <Brot6> indonesiantowns (r41), manindu (r7), metrotrackset (r56), narvs (r37), newgrf_makefile (r294), nutracks (r202), ogfx-industries (r119), ogfx-landscape (r69), ogfx-rv (r107), ogfx-trains (r242), ogfx-trees (r50), openmsx (r97), opensfx (r97), smts (r19), snowlinemod (r49), spanishtowns (r10), sub-landscape (ERROR r66), sub-opengfx (ERROR r666), swedishrails (r202), swisstowns (r22), transrapidtrackset (r15), ttdviewer (r34), ttrs (r36),
17:37:06  <Brot6> worldairlinersset (r672)
17:43:37  <Brot6> sub-landscape: compile of r66 still failed (#2616) -
17:44:30  <Brot6> sub-opengfx: compile of r666 still failed (#2586) -
17:45:22  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: airportsplus (Diffsize: 12), belarusiantowns (Diffsize: 30), frenchtowns, german-townnames, indonesiantowns (1 errors) (Diffsize: 1), manindu (Diffsize: 1), narvs, newgrf_makefile, ogfx-industries (Diffsize: 57), ogfx-landscape (Diffsize: 21), ogfx-rv, ogfx-trains, spanishtowns (Diffsize: 1), swedishrails (Diffsize: 385), swisstowns
17:59:18  *** andythenorth has joined #openttdcoop.devzone
18:20:25  <Ammler> dev:/usr/src/packages/BUILD/opengfx> nmlc --nfo sprites/nfo/extra/extra-plus-arctic-rail-vehicles.pnfo sprites/nml/extra/extra-plus-arctic-rail-vehicles.pnml
18:20:26  <Ammler> Language file "lang/english.lng" does not contain a ##grflangid pragma
18:20:28  <Ammler> Illegal character '#' at "input", line 1
18:21:07  <Ammler> is that illegal character error from nml or make?
18:23:17  <Hirundo> It's an error from the NML lexer
18:24:02  <Hirundo> Ammler: It means, there's an (unquoted) # somewhere in the NML file
18:26:52  <Ammler> oh, I see, there is #include there
18:26:59  <Ammler> can't run it that way
18:38:04  <Ammler> I really hate those errors I can't reproduce locally :-(
18:43:33  <Ammler> dev:/usr/src/packages/BUILD/opengfx> make
18:43:35  <Ammler> [DEP] ogfxe_extra.src.dep
18:43:36  <Ammler> <stdin>:25:66: fatal error: sprites/nfo/extra/extra-plus-arctic-rail-vehicles.pnfo: No such file or directory
18:43:45  <Ammler> of course it is missing, since I need to build it first
18:43:52  <Ammler> but why doesn't it build?
18:48:44  <Ammler> planetmaker: NML2NFO doesn't work from the source bundles
18:49:05  <planetmaker> hm?
18:49:24  <Ammler> the only explaination I have :-)
18:52:09  <Ammler> well, if you ask me, mercurial could be a requirement anyway
18:52:24  <Ammler> the additional work you have around it is by far not worth
18:56:42  <Ammler> I mean, if we add gimp as build requirement, hg is peanuts :-)
18:59:15  <Ammler> the error might be the dep check
18:59:27  <Ammler> afaik you use hg there, right?
19:08:56  <Brot6> NewGRF Meta Language - Feature #2746 (New): station support (Hirundo) @
19:42:52  <Brot6> OpenGFX - Revision 676:b6184f609175: Fix (r675): NML2NFO doesn't work with source bundles (Ammler) @
19:44:31  <Brot6> opengfx: compile of r676 still failed (#2745) -
19:53:28  *** andythenorth has quit IRC
19:53:51  *** andythenorth has joined #openttdcoop.devzone
19:59:45  <Ammler> I very much regret enabling this
20:00:41  <planetmaker> what?
20:01:28  <Ammler> this nml2nfo stuff, It is just confusing... :-)
20:33:52  *** ODM has quit IRC
20:34:17  *** ODM has joined #openttdcoop.devzone
20:42:14  <Ammler> planetmaker: I found the bug
20:42:28  <Ammler> you added a dummy english.lng to the opengfx repo
20:42:43  <Ammler> you are a very mean guy
20:43:53  <Ammler> that explains now, why it worked sometimes :-P
20:44:12  <Yexo> I thought you new that ;)
20:44:16  <Yexo> +k
20:45:00  <Ammler> well, that is just ugly
20:45:38  <planetmaker> hm, doesn't it always work with the dummy lng file?
20:45:49  <planetmaker> I guess I added it as it didn't work without...
20:46:02  <Yexo> for me it always works with the dummy lng file and never without
20:46:20  <planetmaker> thus... what's mean about a dummy file?
20:46:21  <Ammler> yep, but you could also build a dummy file with the Makefile
20:46:24  <Brot6> FIRS Industry Replacement Set - Revision 2060:8c4ecb532f66: Feature: complete snow support for Bu... (andythenorth) @
20:46:47  <Yexo> or fix nml so it no longer requires a dummy file :)
20:46:52  <Ammler> planetmaker: the issue is that you want to support systems which you self never test :-P
20:47:27  <Ammler> and I test the systems I never want :-)
20:47:38  <planetmaker> I don't understand...
20:49:06  <Ammler> you want makefile framework to work without mercurial but you don't test it
20:49:21  <Ammler> I test it but don't think, it is worth :-P
20:50:13  <Brot6> NewGRF Meta Language - Revision 1411:be5a9ce32781: Change: not having a default langauge file now... (yexo) @
20:50:22  <Yexo> the dummy language file is no longer needed as of nml r1411
20:50:32  <Ammler> I check, but I assume, you forgot to add the dummy lng file to the source bundle
20:50:58  <Ammler> Yexo: could you release 0.1.1 then ;-)
20:53:30  <Brot6> OpenGFX - Revision 677:05c5f8a96c4d: Fix (r676): the dummy language file is not always missing (Ammler) @
20:54:35  <planetmaker> :-) good night now also here
20:54:46  <Ammler> good night planetmaker
20:55:12  <Brot6> opengfx: update from r674 to r677 done (18 errors) -
20:55:26  <Ammler> finally :-P
20:55:43  <Yexo> Ammler: there you are :)
20:56:17  <Yexo> no changelog or anything though, no other changes, just r1411 backported to 0.1
20:56:27  <Brot6> NewGRF Meta Language - Revision 1412:b7e6d30c9445: Change: not having a default langauge file now... (yexo) @
20:56:27  <Brot6> NewGRF Meta Language - Revision 1413:58da39c1df56: Added tag 0.1.1 for changeset b7e6d30c9445 (yexo) @
20:58:43  <Brot6> nml: update from 0.1.0 to 0.1.1 done -
20:59:09  <Ammler> hmm
20:59:29  <Ammler> I wanted to test if this dummy file was also the cause of the source bundle failing
21:06:37  <Brot6> FIRS Industry Replacement Set - Bug #2747 (New): Plastic Plant snow sprites out of date (andythenorth) @
21:09:31  <Ammler> autsch
21:14:39  <Ammler> maintainer-clean causes a M in the revision :-)
21:15:10  <Brot6> FIRS Industry Replacement Set - Feature #2748 (New): Revisit idea of lighthouse - as addon/optional? (andythenorth) @
21:22:28  <Brot6> CHIPS Station Set - Feature #2749 (New): Consider adding snow support (andythenorth) @
21:29:54  *** andythenorth has quit IRC
21:47:05  *** ODM has quit IRC
22:27:22  *** frosch123 has quit IRC

Powered by YARRSTE version: svn-trunk