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 http://pastebin.com/3JK2kGby ? 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) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/a03401cb8525 14:36:09 <Brot6> NewGRF Meta Language - Revision 1469:3b76fb64ddba: Codechange: Rework the way action7/9 skipping ... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/3b76fb64ddba 14:36:09 <Brot6> NewGRF Meta Language - Revision 1470:c87902a55ea3: Change: Mark action2 as not needing to be skip... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/c87902a55ea3 14:44:34 <Brot6> NewGRF Meta Language - Revision 1471:47df520d8c9e: Codechange: always reference the unknown_id_fa... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/47df520d8c9e 15:23:18 <Brot6> NewGRF Meta Language - Revision 1472:dcc08c928afe: Fix: print real sprite labels to nml output (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/dcc08c928afe 15:23:18 <Brot6> NewGRF Meta Language - Revision 1473:8dc2672f795c: Add: regression test for advanced sprite layouts (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/8dc2672f795c 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 - http://bundles.openttdcoop.org/nml/nightlies/r1473 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) - http://bundles.openttdcoop.org/narvs/nightlies/ERROR/r37 17:23:47 <Brot6> OpenGFX+ Industries - Bug #2792 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/2792 17:23:47 <Brot6> OpenGFX+ Landscape - Bug #2793 (New): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/2793 17:25:58 <Brot6> sub-landscape: compile of r66 still failed (#2616) - http://bundles.openttdcoop.org/sub-landscape/nightlies/ERROR/r66 17:26:53 <Brot6> sub-opengfx: compile of r666 still failed (#2586) - http://bundles.openttdcoop.org/sub-opengfx/nightlies/ERROR/r666 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) @ http://dev.openttdcoop.org/issues/2794 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) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/85d640b7d326 17:57:44 <Brot6> NewGRF Meta Language - Revision 1475:4c4aaf31d8d3: Fix r1461: the 'layouts' property of industrie... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/4c4aaf31d8d3 17:57:44 <Brot6> NewGRF Meta Language - Revision 1476:3cf40f9221bd: Fix r1465: basic math values didn't reduce the... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/3cf40f9221bd 17:58:38 <Brot6> OpenGFX+ Industries - Bug #2792: DevZone compile failed (yexo) @ http://dev.openttdcoop.org/issues/2792#change-6951 17:58:38 <Brot6> OpenGFX+ Landscape - Bug #2793: DevZone compile failed (yexo) @ http://dev.openttdcoop.org/issues/2793#change-6952 18:03:47 <Brot6> NewGRF Meta Language - Revision 1477:8f1196a688fc: Fix r1465: another failure due to reducing at ... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/8f1196a688fc 18:04:06 <Brot6> Swedish Rails - Bug #2794: DevZone compile failed (yexo) @ http://dev.openttdcoop.org/issues/2794#change-6953 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> http://bundles.openttdcoop.org/firs/releases/0.6.5-beta-3/ 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: http://newgrf-specs.tt-wiki.net/wiki/Action14#GRF_version_.28.22INFO.22_-.3E_.22VRSN.22.29 20:35:21 <Webster> Title: Action14 - GRFSpecs (at newgrf-specs.tt-wiki.net) 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> http://www.tt-forums.net/viewtopic.php?f=67&t=44177&p=953635#p953635 21:07:24 <Webster> Title: Transport Tycoon Forums View topic - FIRS Industry Replacement Set - v0.6.5(beta-3) 24 June (at www.tt-forums.net) 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