Log for #openttdcoop.devzone on 24th June 2011:
Times are UTC Toggle Colours
00:14:41  *** JVassie has quit IRC
04:56:00  *** bodis has joined #openttdcoop.devzone
05:48:30  *** bodis has quit IRC
06:23:58  *** andythenorth has joined #openttdcoop.devzone
06:38:18  *** andythenorth has quit IRC
06:45:41  *** andythenorth has joined #openttdcoop.devzone
07:25:22  *** JVassie has joined #openttdcoop.devzone
07:29:55  *** andythenorth has quit IRC
08:00:50  *** andythenorth has joined #openttdcoop.devzone
08:42:46  *** JVassie has quit IRC
09:25:21  *** JVassie has joined #openttdcoop.devzone
12:26:15  *** Tloo-ZaRaZa has joined #openttdcoop.devzone
13:40:38  *** Lakie has joined #openttdcoop.devzone
13:51:51  <Hirundo> Yexo: Could you take a look at ?
13:53:37  <Yexo> sure
13:53:55  <Hirundo> Basically, it's intended to add 'no skipping' as a third option, besides action 7/9
13:55:10  <Hirundo> Since a coding error would result in really hard-to-find bugs, I thought a quick review might be appropriate
14:07:13  <Yexo> you're missing one special case that I think the old code handled: (True, True, False), (False, True, True), (False, False, True)
14:07:30  <Yexo> you code inserts an action7 after the second action and need another action9 after the last action
14:07:43  <Yexo> while if you ignore the first action you can do with a single action9
14:08:03  <Yexo> basically "if length ==1 and not skip_needed()): start +=1; continue"
14:08:59  <Yexo> lines 23..25 in that pastebin
14:12:01  <Hirundo> true, will fix that
14:14:14  <Rubidium> what? I'm the author of the small airport preview sprite in opengfx+ airports? tss... it's just a cropped screenshot; if someone's the author of those graphics it's the one drawing the actual sprites, or even OpenTTD itself ;)
14:14:43  <Yexo> you did the work of cropping that screenshot :)
14:14:50  <Yexo> but I agree, that's a bit over the top
14:17:35  <Yexo> Hirundo: aside from that small issue, it looks fine
14:17:58  <Yexo> make sure to set action2 not only to "not skip_needed" but also disallow skip7 and skip9
14:18:18  <Hirundo> sure
14:18:30  <Hirundo> currently skip_needed, skip7 and skip9 are all false
14:19:19  <Hirundo> Change paste line 39 to "if any(new_opts) and not (skip_opts[0] and not new_opts[0]):" should do, right?
14:20:07  <Yexo> yes
14:20:33  <Yexo> or is that one "not" too many?
14:21:12  <Yexo> no, it's ok :)
14:24:38  *** andythenorth has left #openttdcoop.devzone
14:25:36  <Hirundo> The length == 0 is also handled correctly, but it could use a comment or two
14:36:09  <Brot6> NewGRF Meta Language - Revision 1468:a03401cb8525: Cleanup: Remove redundant skipping info from r... (Hirundo) @
14:36:09  <Brot6> NewGRF Meta Language - Revision 1469:3b76fb64ddba: Codechange: Rework the way action7/9 skipping ... (Hirundo) @
14:36:09  <Brot6> NewGRF Meta Language - Revision 1470:c87902a55ea3: Change: Mark action2 as not needing to be skip... (Hirundo) @
14:44:34  <Brot6> NewGRF Meta Language - Revision 1471:47df520d8c9e: Codechange: always reference the unknown_id_fa... (yexo) @
15:23:18  <Brot6> NewGRF Meta Language - Revision 1472:dcc08c928afe: Fix: print real sprite labels to nml output (yexo) @
15:23:18  <Brot6> NewGRF Meta Language - Revision 1473:8dc2672f795c: Add: regression test for advanced sprite layouts (yexo) @
15:30:59  <planetmaker> [17:26]	Yexo	[22:07:17] Hirundo: in switch-blocks, which syntax is preferred: "3: return 2;" or "3: 2;" <-- I prefer actually with return
15:31:06  <planetmaker> it makes it clear it's a return value
15:32:59  <Yexo> ok, so keep using that syntax
15:33:13  <Yexo> right now both are valid, but I think I'll disallow the syntax without return again
15:36:29  <planetmaker> I've not yet read all backlog, so if there's good reason for one or the other... :-)
15:36:48  <Yexo> spriteset references are now valid expressions
15:36:58  <Yexo> so "return some_spriteset;" currently works too
15:37:50  <planetmaker> oh, sweet
15:38:27  <Yexo> the question was about that: we allow it now, but do we actually want to allow that
15:38:46  <Yexo> or do we want to keep "return" for non-spritesets and without "return" for spritesets
15:38:58  <Yexo> to make it clear which of the two it is while glancing over the code
15:40:06  <Terkhen> keep "return" for non-spritesets and without "return" for spritesets <--- I prefer this too, IMO it makes the code more clear
15:40:30  <planetmaker> Might make sense to me, too. It's also as it was befor yesterday ;-)
15:41:03  <planetmaker> but mostly it makes it indeed clear what is a spriteset and what a callback return
15:50:16  *** bodis has joined #openttdcoop.devzone
15:59:36  *** Tloo-ZaRaZa has quit IRC
17:10:50  <Brot6> nml: update from r1458 to r1473 done -
17:18:35  <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 (r105), basecosts (r25), belarusiantowns (r8), bros (r52), cets (r5), chips (r143), comic-houses (r71), firs (r2087), firs.nml (r2081), fish (r653), frenchtowns (r6), german-townnames (r34), grfcodec
17:18:35  <Brot6> (r832), grfpack (r279), heqs (r605), indonesiantowns (r41), manindu (r7), metrotrackset (r56), narvs (r37), newgrf_makefile (r296), nml (r1473), nutracks (r202), ogfx-industries (r121), ogfx-landscape (r70), ogfx-rv (r107), ogfx-trains (r245), ogfx-trees (r50), opengfx (r678), openmsx (r97), opensfx (r97), smts (r19), snowlinemod (r49), spanishtowns (r10), sub-landscape (ERROR r66), sub-opengfx (ERROR r666), swedishrails (r202),
17:18:37  <Brot6> swisstowns (r22), transrapidtrackset (r15), ttdviewer (r34), ttrs (r36), worldairlinersset (r672)
17:19:29  *** andythenorth has joined #openttdcoop.devzone
17:22:34  <Brot6> narvs: compile of r37 still failed (#2789) -
17:23:47  <Brot6> OpenGFX+ Industries - Bug #2792 (New): DevZone compile failed (compiler) @
17:23:47  <Brot6> OpenGFX+ Landscape - Bug #2793 (New): DevZone compile failed (compiler) @
17:25:58  <Brot6> sub-landscape: compile of r66 still failed (#2616) -
17:26:53  <Brot6> sub-opengfx: compile of r666 still failed (#2586) -
17:27:47  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: airportsplus, belarusiantowns (Diffsize: 30), cets, frenchtowns, german-townnames, indonesiantowns (1 warnings) (Diffsize: 1), manindu (Diffsize: 1), newgrf_makefile, ogfx-rv (Diffsize: 4590), ogfx-trains, spanishtowns (Diffsize: 1), swisstowns
17:27:49  <Brot6> Swedish Rails - Bug #2794 (New): DevZone compile failed (compiler) @
17:30:01  <Hirundo> Yexo: I suspect NML r1465 is causing at least some of these regressions
17:30:29  <Yexo> yes, probably
17:57:44  <Brot6> NewGRF Meta Language - Revision 1474:85d640b7d326: Fix r1461: using independent/dependent in rand... (yexo) @
17:57:44  <Brot6> NewGRF Meta Language - Revision 1475:4c4aaf31d8d3: Fix r1461: the 'layouts' property of industrie... (yexo) @
17:57:44  <Brot6> NewGRF Meta Language - Revision 1476:3cf40f9221bd: Fix r1465: basic math values didn't reduce the... (yexo) @
17:58:38  <Brot6> OpenGFX+ Industries - Bug #2792: DevZone compile failed (yexo) @
17:58:38  <Brot6> OpenGFX+ Landscape - Bug #2793: DevZone compile failed (yexo) @
18:03:47  <Brot6> NewGRF Meta Language - Revision 1477:8f1196a688fc: Fix r1465: another failure due to reducing at ... (yexo) @
18:04:06  <Brot6> Swedish Rails - Bug #2794: DevZone compile failed (yexo) @
18:12:30  <Yexo> we need more regression tests :p
18:20:39  <planetmaker> Yexo: is there a list of which things need regression tests?
18:20:58  <Yexo> everything that doesn't have one yet? :p
18:21:01  <Yexo> so not really
18:22:04  <Ammler> every project is one :-)
18:22:13  <Yexo> in a way, yes
18:24:08  <planetmaker> well, if I don't fall immediately asleep when I'm back in the hotel... I might have some look
20:31:33  <andythenorth> Yexo: tis a pity we can't mark a bananas release as 'test'
20:31:35  <andythenorth> :|
20:31:53  <Yexo> just upload to the forum first?
20:31:55  <andythenorth> would it be wrong to push the tag, announce in forums, but not put on bananas yet?
20:31:59  <andythenorth> oh same
20:32:08  <Yexo> there is already a tag pushed
20:32:23  <Yexo> 0.6.5-beta-3
20:32:26  <Yexo> you could upload that on the forum
20:32:42  <Yexo> if there are no bugs, push a new tag "0.6.5" and upload that to bananas
20:32:53  <andythenorth> ok
20:32:54  <andythenorth> lets do that
20:33:03  <andythenorth> it's building ok on cf?
20:33:17  <Yexo> yes
20:33:36  <Yexo>
20:33:38  <andythenorth> great
20:33:42  <andythenorth>  I can link that
20:33:54  <Yexo> I just made a slight mistake while creating the tag, so it's "beta-3" instead of "beta3"
20:34:21  <Ammler> andythenorth: make an additional bananas entry with different grfid, does that hurt?
20:34:30  <Terkhen> if it is tagged clearly as beta, IMO it is not a problem to put it at the forum thread but not on bananas :)
20:34:30  <andythenorth> yes, horribly
20:34:54  <andythenorth> changing the grfid defeats the point of this :)
20:35:19  <Ammler> this?
20:35:20  <Terkhen> Ammler:
20:35:21  <Webster> Title: Action14 - GRFSpecs (at
20:35:41  <andythenorth> this = migrating FIRS 0.6.4 to nml with no new features ;)
20:35:45  <Ammler> Terkhen: you need another id to make a new bananas entry
20:36:01  * andythenorth will have a beer and then write a release announcement
20:36:13  <Ammler> and you need a new bananas entry if you want to have a testing release there
20:36:14  <Terkhen> what I'm trying to point is: if you lose savegame compatibility most people will not want to try it
20:37:26  <Ammler> well, I don't see how much you need it tested until you trust yourself :-P
20:38:07  <Yexo> Terkhen: I doubt that's true, as I really don't think many people will upgrade a grf version within a running game
20:38:10  <Yexo> given how hard that is
20:38:22  <Terkhen> isn't that done automatically?
20:38:31  <Yexo> only if the old grf is deleted
20:38:37  <Terkhen> oh, ok :P
20:38:43  <Yexo> and how many people are actually going to delete a tar file?
20:38:51  <Terkhen> Ammler: there is never enough testing :)
20:39:34  <Ammler> Terkhen: yes, but for community projects, you use community to test :-P
20:39:49  <Terkhen> that's the point of posting it to the forum thread, yes
20:40:05  <Ammler> there is no release without bananas
20:40:27  <Yexo> the final release will go there, just not the beta
20:40:30  <Terkhen> ^
20:40:44  <Ammler> yeah, it is up to you
20:41:17  <Ammler> you might get around a handful tester who will download from forum
20:41:19  <andythenorth> we are in a hurry to release 0.6.5 yes?
20:41:46  <Terkhen> I don't know, are we in a hurry? :P
20:41:53  <andythenorth> Yexo ?
20:41:55  <Yexo> I'll be going on holiday juli 7 for over a month
20:42:00  <Terkhen> then yes
20:42:01  <Terkhen> :P
20:42:10  <Yexo> so if you want any support from me converting firs trunk to nml, I'd say yes
20:42:19  <andythenorth> hokey dokey
20:42:31  * andythenorth doesn't understand the 'banans is community testing' case
20:42:34  <andythenorth> it's a nice theory
20:42:39  <andythenorth> but not sustainable
20:43:23  <andythenorth> what it actually means is 'releasing unfinished / broken newgrfs on an audience who mostly (a) don't care about helping test (b) don't have any way to provide feedback'
20:43:29  <andythenorth> reality beats theory imo
20:44:10  <Ammler> it is a pain to manually install newgrfs
20:44:17  <Ammler> also if you like to help testing,
20:44:33  <andythenorth> but there's no gain by making it easy to install a broken grf
20:45:06  <Ammler> of course no need to release it if you know it is broken
20:45:10  <Ammler> thought you need to test that
20:45:11  <andythenorth> I don't
20:45:17  <andythenorth> it needs testing
20:45:20  <Ammler> yep
20:45:30  <andythenorth> I can't solely test a large grf that might take two days to play a game
20:45:38  <andythenorth> with multiple possible edge cases
20:45:46  <Ammler> that is why you should release it on bananas
20:46:01  <andythenorth> no that is why I should *not* release it on banans
20:46:08  <Ammler> then you get people to test it, which play it in a way you don't know
20:46:11  <andythenorth> releasing untested code to a production system is very bad
20:46:25  <andythenorth> and releasing it to users who can't give feedback is just pointless
20:46:35  <Terkhen> the people interested enough in FIRS to know why 0.6.5-beta might have bugs and what kind of bugs are the ones that will check the forum thread anyways
20:46:39  <Ammler> well, we could give feedback
20:46:49  <Ammler> but we don't play it if need to manually install it
20:47:23  <Terkhen> then, once that most bugs are fixed, we can release 0.6.5 on bananas
20:47:32  <Terkhen> to find the really complicated ones :)
20:47:50  <Yexo> I doubt there will be any
20:47:59  <Yexo> most bugs will (in hindsight) be really obvious
20:48:34  <Ammler> well, you made the betas because there are no nightlies, I assume?
20:48:56  *** Lakie` has joined #openttdcoop.devzone
20:49:09  <Yexo> a bit, but a normal nightly wouldn't get the same amount of testing exposure as we want now
20:52:05  <Terkhen> I guess that small, well hidden bugs are unlikely because the conversion would then have bugs in a lot of similar parts instead
20:56:25  *** bodis has quit IRC
20:56:25  *** Lakie has quit IRC
20:56:25  *** andythenorth has quit IRC
20:56:25  *** tneo has quit IRC
20:56:25  *** avdg has quit IRC
20:56:25  *** SmatZ has quit IRC
20:56:25  *** dihedral has quit IRC
20:56:25  *** seberoth has quit IRC
20:58:29  *** andythenorth has joined #openttdcoop.devzone
20:58:29  *** bodis has joined #openttdcoop.devzone
20:58:29  *** tneo has joined #openttdcoop.devzone
20:58:29  *** avdg has joined #openttdcoop.devzone
20:58:29  *** SmatZ has joined #openttdcoop.devzone
20:58:29  *** seberoth has joined #openttdcoop.devzone
20:58:29  *** dihedral has joined #openttdcoop.devzone
21:07:22  <andythenorth>
21:07:24  <Webster> Title: Transport Tycoon Forums View topic - FIRS Industry Replacement Set - v0.6.5(beta-3) 24 June (at
21:09:09  <Terkhen> looks fine, I would add that all of those great new sprites won't be released until they test 0.6.5 :P
21:11:25  <andythenorth> ok
21:11:27  <andythenorth> done
21:11:55  * andythenorth maybe has done enough today
21:11:56  <andythenorth> bedtime
21:11:58  <andythenorth> :)
21:12:49  <Terkhen> good night andythenorth
21:13:02  *** andythenorth has left #openttdcoop.devzone
21:58:58  <Ammler> no prove me wrong :-P
21:59:04  <Ammler> now*
22:03:22  <Hirundo> Yexo: Could you explain to me, why r1465 was needed?
22:03:23  *** Lakie` has quit IRC
22:03:43  <Hirundo> (not reducing params before reducing a function call)
22:04:06  <Yexo> a spritegroup_ref with parameters is a functioncall first
22:04:13  <Yexo> since that is a general expression
22:04:31  <Yexo> in a switch-block we need to reduce such an expression to know whether it's a spritegroup_ref or not
22:04:47  <Yexo> while reducing we don't want to error out on the parameters, since we want to parse those later
22:04:58  <Yexo> the parameters could contain a label from the referenced spritegroup for example
22:05:13  <Yexo> but at the point of reducing the functioncall we don't know yet which spriteset that is, so we don't have those labels yet
22:05:31  <Hirundo> Are labels the only thing that breaks?
22:05:37  <Yexo> when we would reduce all parameters, it's throw an error and the functioncall would not be reduced to a spritegroup_ref
22:05:39  <Yexo> no, they are not
22:05:57  <Yexo> or maybe they are
22:06:27  <Yexo> actually no, in spritelayouts the varaction2 variables break it too
22:07:14  <Hirundo> Currently there's a problem with builtin functions, mostly the arguments are reduced to a constant in there
22:07:35  <Hirundo> However you have no access to the id_dicts in the caller scope
22:08:59  <Yexo> it's a bit of a mess now, yes
22:09:46  <Yexo> I have been thinking of removing the current behavior of the  "unknown_id_fatal" parameter to reduce and make it a recursive parameter instead
22:09:56  <Yexo> ie work on the given expression but also pass it to all subexpressions
22:10:33  <Yexo> that was the reason for r1471, to know when it's currently used
22:13:57  <Hirundo> Personally I'm more inclined to work the other way around, to make all identifiers known at the time of reducing
22:14:19  <Yexo> for spritegroup references that might be impossible
22:14:57  <Yexo> unless we make a special case for that in FunctionCall.reduce
22:15:33  <Hirundo> For the labels, you mean?
22:15:37  <Yexo> yes
22:16:36  <Hirundo> Yes, that'd be a special case since they are only defined in the scope of the referenced entity
22:17:07  <Hirundo> When I was working on that I already wondered whether that'd be a conceptual issue
22:22:32  <Yexo> make all identifiers known at the time of reducing <- if we can make that work, that'd certainly be the better approach
22:22:53  <Yexo> also in that case the unknown_id_fatal parameter should go
22:26:04  <Hirundo> Also, I think we should move away from having lots of separate dictionaries in various parts of the code
22:27:22  <Hirundo> Let's say the user defines a parameter max_speed, to use as value for that property
22:28:12  <Hirundo> Now if he wants to access this parameter in a switch block, he may not get quite the result he expects...
22:28:44  <Yexo> true
22:29:07  <Hirundo> I can see basically no valid use case to define the same identifier multiple times for different things, IMO we should error or at least warn on it
22:29:17  <Yexo> agreed
22:29:50  <Yexo> basically that means that we should warn on every user-defined name that clashes with a name in either global_constants or a variable name (in whatever feature)
22:31:57  <Hirundo> I'm not sure yet how to handle variables in this case
22:33:59  <Hirundo> They have to remain separate because they differ per-feature, but checking for them when registering identifiers might be best indeed
22:37:13  <Hirundo> goodnight
23:13:51  *** bodis has quit IRC
23:50:52  *** JVassie has quit IRC

Powered by YARRSTE version: svn-trunk