Times are UTC Toggle Colours
01:58:41 *** KenjiE20 has quit IRC 05:53:56 *** Ruudjah has left #openttdcoop.devzone 06:43:12 *** andythenorth has joined #openttdcoop.devzone 06:51:17 <Brot6> FISH - Bug #2644 (New): Lighting wrong on small vehicle ferry (andythenorth) @ http://dev.openttdcoop.org/issues/2644 06:56:41 *** andythenorth has quit IRC 07:35:25 *** ODM has joined #openttdcoop.devzone 07:40:07 *** andythenorth has joined #openttdcoop.devzone 07:41:17 <Brot6> FISH - Feature #1140 (Rejected): Convert Utility Vessels to cpp offsets (andythenorth) @ http://dev.openttdcoop.org/issues/1140#change-6746 07:42:27 <Brot6> FISH - Feature #1138 (Rejected): Show some cargos in graphics? (andythenorth) @ http://dev.openttdcoop.org/issues/1138#change-6747 07:43:33 <Brot6> FISH - Feature #2360 (Closed): Add variety to fishing boats (andythenorth) @ http://dev.openttdcoop.org/issues/2360#change-6748 07:43:33 <Brot6> FISH - Feature #1411 (Rejected): Lumber and Wood graphics for Coasters, Traders (andythenorth) @ http://dev.openttdcoop.org/issues/1411#change-6749 07:45:37 <Brot6> FISH - Feature #2645 (New): Graphics for 12t utility vessel (andythenorth) @ http://dev.openttdcoop.org/issues/2645 07:45:37 <Brot6> FISH - Feature #2646 (New): Graphics for 52t utility vessel (andythenorth) @ http://dev.openttdcoop.org/issues/2646 07:46:47 <Brot6> FISH - Feature #2647 (New): Medium utility tug (fast) (andythenorth) @ http://dev.openttdcoop.org/issues/2647 07:49:50 <Brot6> FISH - Feature #2648 (New): Tweak shading on puffer graphics (andythenorth) @ http://dev.openttdcoop.org/issues/2648 07:55:06 *** frosch123 has joined #openttdcoop.devzone 09:25:50 <planetmaker> hm, so no cargo sprites for ships, andythenorth ? 09:27:11 *** andythenorth has quit IRC 09:27:11 *** andythenorth_ has joined #openttdcoop.devzone 09:38:47 *** andythenorth_ has quit IRC 09:38:47 *** andythenorth has joined #openttdcoop.devzone 09:39:51 *** andythenorth_ has joined #openttdcoop.devzone 09:42:09 <andythenorth_> I think not 09:42:28 <andythenorth_> too many other things I could do instead 09:45:42 <planetmaker> hm... cargo sprites add a lot to a set's beauty 09:49:37 *** KenjiE20 has joined #openttdcoop.devzone 11:56:28 *** andythenorth_ is now known as anybody 11:57:05 *** anybody is now known as andythenorth 13:00:19 <Brot6> FISH - Revision 644:5ebf8518d36b: Change: work in progress to improve lighting of coasters (andythenorth) @ http://dev.openttdcoop.org/projects/fish/repository/revisions/5ebf8518d36b 13:29:17 *** LordAro has joined #openttdcoop.devzone 14:27:38 *** andythenorth_ has joined #openttdcoop.devzone 14:33:52 *** andythenorth has quit IRC 15:23:46 *** andythenorth_ has quit IRC 16:25:29 <Brot6> nutracks.clone: update from to 1.1.0 done - http://bundles.openttdcoop.org/nutracks.clone/releases/1.1.0 16:27:37 <Brot6> nutracks.clone: update from to r195 done - http://bundles.openttdcoop.org/nutracks.clone/push/r195 16:27:45 <Brot6> nutracks.clone: compile of r195 failed - http://bundles.openttdcoop.org/nutracks.clone/releases/ERROR/r195 16:27:56 <Ammler> hmm 16:29:00 *** andythenorth has joined #openttdcoop.devzone 16:29:27 <planetmaker> "interesting" 16:33:19 <Brot6> nutracks.clone: update from r195 to r196 done - http://bundles.openttdcoop.org/nutracks.clone/push/r196 16:33:29 <Brot6> nutracks.clone: compile of r196 failed - http://bundles.openttdcoop.org/nutracks.clone/releases/ERROR/r196 16:36:52 <Brot6> nutracks.clone: update from r196 to r197 done - http://bundles.openttdcoop.org/nutracks.clone/push/r197 16:37:02 <Brot6> nutracks.clone: compile of r197 failed - http://bundles.openttdcoop.org/nutracks.clone/releases/ERROR/r197 16:38:24 <planetmaker> what is this "unknown revision r197"? 16:41:16 *** LordAro has quit IRC 16:45:20 <Ammler> ? 16:46:09 <planetmaker> in the error log 16:46:17 <Ammler> it does compile default as release but I wasn't able to reproduce it with test 16:46:25 <Ammler> so I play with a nutracks clone 17:02:29 *** andythenorth has quit IRC 17:18:28 <Brot6> fish: update from r638 to r644 done - http://bundles.openttdcoop.org/fish/nightlies/r644 17:18:43 <Brot6> german-townnames: update from r33 to r34 done - http://bundles.openttdcoop.org/german-townnames/nightlies/r34 17:19:18 <Brot6> nutracks: update from r190 to r193 done - http://bundles.openttdcoop.org/nutracks/nightlies/r193 17:19:46 <Brot6> nutracks.clone: update from r92 to r197 done - http://bundles.openttdcoop.org/nutracks.clone/nightlies/r197 17:19:54 <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 (r75), basecosts (r25), belarusiantowns (r8), bros (r52), chips (r141), comic-houses (r71), firs (r1994), frenchtowns (r6), grfcodec (r829), grfpack (r279), heqs (r605), indonesiantowns (r41), manindu 17:19:54 <Brot6> (r7), metrotrackset (r56), narvs (r37), newgrf_makefile (r289), nml (r1349), ogfx-industries (r105), ogfx-landscape (r68), ogfx-rv (r107), ogfx-rv.clone (r103), ogfx-trains (r241), ogfx-trees (r44), opengfx (r669), 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 17:19:56 <Brot6> (r36), worldairlinersset (r671) 17:20:35 <Brot6> sub-landscape: compile of r66 still failed (#2616) - http://bundles.openttdcoop.org/sub-landscape/nightlies/ERROR/r66 17:21:21 <Brot6> sub-opengfx: compile of r666 still failed (#2586) - http://bundles.openttdcoop.org/sub-opengfx/nightlies/ERROR/r666 17:37:56 <Terkhen> ... this town is too small for having {STRING} industries of this type (there can be only one of these industries for every 10 houses) <--- it is possible to set a parameter that receives an integer? (nml) 17:47:22 <Terkhen> hmm... the newgrf specs hint that it is not possible to return error strings with numerical parameters 17:47:44 *** andythenorth has joined #openttdcoop.devzone 17:48:25 <Terkhen> will it work if I set 0x100 to STR_JUST_INT and 0x101 to the numerical value I want to show? 17:49:53 <Yexo> why not just set 0x100 to the numerical value and use {DWORD_S} instead of {STRING} ? 17:52:08 <Terkhen> Yexo: thanks, that shows a number :) 17:52:27 <Terkhen> it's showing -1, but that's probably because my code is wrong :P 18:04:30 <Terkhen> http://paste.openttdcoop.org/show/210/ <-- what could be causing the "always show -1" issue? 18:25:04 <Terkhen> hmm... no matter what I put inside 0x100 I get the same result 18:44:31 <Yexo> Terkhen: sorry, got a phone call 18:44:35 <Yexo> do you have a small test case? 18:45:05 <Terkhen> no problem :) 18:45:07 <Terkhen> I'll code one 18:45:45 <Brot6> OpenGFX+ Industries - Bug #2578 (Closed): Power plants can close even if serviced (Terkhen) @ http://dev.openttdcoop.org/issues/2578#change-6751 18:45:45 <Brot6> OpenGFX+ Industries - Revision 106:c581b908bae1: Fix #2578: Banks now close after a random interv... (Terkhen) @ http://dev.openttdcoop.org/projects/ogfx-industries/repository/revisions/c581b908bae1 19:09:25 <Terkhen> heh, in my test case the parameter actually works 19:09:37 <Terkhen> so I managed to create some working code to compare :P 19:10:50 <Terkhen> http://paste.openttdcoop.org/show/211/ <--- this is the working code, 210 has the "broken" one 19:11:07 <Terkhen> TEMP variables are not preserved between different switches called on the same callback? 19:18:09 <Terkhen> hmm... they are conserved, otherwise the other store would not work 19:20:34 <Terkhen> ok, I got it :) 19:20:39 <Terkhen> http://paste.openttdcoop.org/show/212/ <--- this works, 210 does not 19:20:52 <Terkhen> I need to set the parameters inside 0x100 in the same switch that uses them :) 19:29:47 <Terkhen> planetmaker: http://devs.openttd.org/~terkhen/patches/index.php?source=ogfxplus/single_industry_template.diff <--- IMO 50 houses is too small... at least for really big towns 19:35:09 <planetmaker> @calc sqrt(50) 19:35:09 <Webster> planetmaker: 7.07106781187 19:35:19 <planetmaker> that's also not a big area ;-) 19:36:28 <planetmaker> and yes, I do agree, 50 seems too small 19:36:42 <planetmaker> a random start town of 2500k people already had 60 19:37:37 <planetmaker> maybe 100 or 150 19:38:06 <planetmaker> make it an easy define in header.pnml ;-) 19:49:01 <Terkhen> planetmaker: diff updated, it is IMO looking good for big towns with 150 :) 19:54:03 <Yexo> <Terkhen> I need to set the parameters inside 0x100 in the same switch that uses them :) <- that shouldn't be necessary 19:54:25 <Hirundo> Yexo: wrt. your earlier comment, changing the sorting order doesn't really help I think, as sorting matters little if you try to allocate 300 action2 ids in one go 19:55:10 <Yexo> Hirundo: suppose we have action2's A, B, C and D. C refers to A and B. Both C and D are referred to from the same action3 19:55:21 <planetmaker> looks nice 19:55:46 <Yexo> we can assign A=1, B=2, C=1 (reuse id from A), D=2 (reuse from B, since it's not referenced after here) 19:55:48 <Terkhen> Yexo: I can create a small example that reproduces the issue if necessary 19:55:54 <Hirundo> Are you aware, that only action1 and real action2s are involved there (action1.py) ? 19:56:01 <Yexo> if the order was A, B, D, C it's impossible to assign 2 to D 19:56:03 <Terkhen> but once I moved the store_temp to the switch using the string, it started working 19:56:31 <Yexo> Hirundo: no, but that makes sense :) 19:58:05 <Hirundo> I think parsing of any action1/2 should be deferred to the latest possible moment 19:58:06 <Yexo> Terkhen: I'll test myself with the diffs you already uploaded and if I can find the problem 19:58:28 <Yexo> Hirundo: isn't that done already? 19:58:33 <Hirundo> i.e. only start parsing stuff upon encountering an action3 and work backwards from there 19:58:35 <Yexo> if not, how would that help in this case? 19:58:50 <Terkhen> planetmaker: ok, I'll commit :) 19:58:50 <Hirundo> Currently action1/real2 is done upon hitting the first spriteset 19:59:00 <planetmaker> sweet :-) 19:59:06 <Yexo> hmm, ok 19:59:06 <Hirundo> And produce/switch/random is done wherever they're declared by the user 19:59:07 <Terkhen> note that this changes the requirement to 1.1.1-RC1 or greater :) 19:59:23 <Yexo> problem with the current language is that we cannot move the switch blocks around 19:59:46 <Yexo> since you can use param[x] in switch blocks, and the value of that can change between switch blocks, so it's invalid to move them around 19:59:47 <planetmaker> Our placement control? What'll happen, in 1.1.0? 19:59:52 <Hirundo> hmmm indeed 19:59:56 <Hirundo> didn't think of that 20:00:19 <Hirundo> perhaps, we should change that :) 20:00:37 <Yexo> not being able to use param[x] in switch-blocks is _very_ inconvenient 20:00:51 <planetmaker> quite. Then I rather have the current situation 20:01:08 <Hirundo> of course, but we could let param[x] refer to the 'final' value instead (using var 7F) 20:01:20 <planetmaker> it'd break most if not all of my grfs 20:01:49 <Yexo> that is a possible solution, but imo that is very counter-intuitive 20:02:02 <Hirundo> That depends on your intuition :) 20:02:42 <Yexo> param[x]=0; switch (..., param[x]) {...} param[x]=3; <- I'd definitely think param[x] is 0 inside the switch 20:03:31 <Hirundo> Global variables tend to work the other way round 20:03:52 <Hirundo> Stuff like lambda functions in python work like you describe 20:03:59 <Yexo> good point 20:06:31 <Hirundo> Even without moving switch blocks, I think there's a lot to gain by handling everything (including real action2) as late as possible 20:07:51 <Yexo> I agree 20:08:28 <Hirundo> 'everything' being spritesets/groups/layouts 20:09:20 <Yexo> handling the action1/real action2 at the location where it's now is no problem, as long as the action2's are only prepared and not directly written to the output 20:12:24 <Brot6> OpenGFX+ Industries - Revision 107:df53a952da30: Feature #2622: Limit the number of certain types... (Terkhen) @ http://dev.openttdcoop.org/projects/ogfx-industries/repository/revisions/df53a952da30 20:12:37 <Terkhen> Yexo: http://devs.openttd.org/~terkhen/patches/ogfxplus/ogfx_industries_string_switch_issue.diff <--- this diff file over OpenGFX+ Industries allows to reproduce the string parameter issue 20:16:57 <Yexo> Terkhen: how to reproduce the problem in-game? 20:17:42 <Terkhen> build water towers in a small town, when you build the second one it will display an error message 20:18:02 <Yexo> ok, thanks 20:18:04 <Terkhen> without the diff, the parameters will be correct, with the diff the number of industries will be -1 and the number of houses 256 20:24:05 <Yexo> Terkhen: the nfo code generated with your patch applied is totally bogus 20:24:11 <Yexo> so that's definitely a bug in nml 20:25:20 <Terkhen> ok, should I open a proper bug report? 20:25:38 <Yexo> doesn't really matter, I'm trying to fix it now 20:25:43 <Terkhen> ok :) 20:26:42 <Yexo> oh, it's not something nml can fix 20:26:50 <Yexo> industry_town_count uses register 0x100 and 0x101 20:27:47 <Yexo> so we'll need some extra documentation and you'll have to fix ogfx-industries yourself 20:29:33 <planetmaker> hm... sounds interesting... Still I'm dead tired and wish you a good night. 20:29:58 <Hirundo> Yexo: spritelayouts are a) capable of accessing parameters to set sprite numbers and b) they need to be moved around to comply with action1/action2 restrictions 20:30:01 <Yexo> night planetmaker 20:30:08 <Hirundo> ergo, we are in trouble already even without moving switches 20:30:12 <Hirundo> goodnight pm 20:30:24 <Terkhen> oh, true :/ 20:30:30 <Terkhen> I forgot about that 20:30:43 <Yexo> Hirundo: indeed, that's bad :( 20:30:57 <Yexo> it's starting to look like your suggestion of using var 7F for parameters is the best option 20:31:05 <Hirundo> That won't fix layouts, though 20:31:48 <Yexo> oh, right, it's impossible to move layouts around :( 20:32:58 <Hirundo> If you don't re-use parameters all will be fine due to the various grf loading stages 20:33:35 <Yexo> but not re-using parameters is a lot to ask 20:33:41 <Yexo> and almost impossible to track automatically 20:34:10 <Hirundo> whoever made the design decision about action1/2 relationship... 20:34:17 <Hirundo> :S 20:35:47 <Yexo> so currently we have spritelayouts (=real action2's) which can't be moved around at all (but currently are), switch-blocks which depending on a design decision whether to use var 7F or action6 can or cannot be moved around, and action1's which can be duplicated/moved at will 20:36:16 <Hirundo> duplicating action1s means duplicating real sprites 20:36:26 <Yexo> yes, but that's sometimes the only option 20:36:44 <Hirundo> Perhaps, we should just do away with action1 for layouts entirely and resort to GRM 20:37:10 <Yexo> imagine spritelayouts A, B and C where B is a different feature from A and C. A and C both use the same realsprite. All of them use at least one param[x] as sprite so they can't be moved 20:37:29 <Yexo> C can't refer to the same action1 as A because B is in the middle, and you can't use a single action1 for multiple features 20:38:02 <Yexo> using GRM for everything is a bad idea 20:38:03 <Hirundo> currently that just throws an error, but we can fix that 20:38:10 <Hirundo> bad idea because? 20:38:23 <Yexo> there is a limit to the number of sprites that can be allocated via GRM 20:38:40 <Hirundo> also in OpenTTD or only in TTDP? 20:38:44 <Yexo> the limit is IIRC 65535-baseset sprites for all grf's together 20:38:49 <Yexo> also in openttd 20:39:00 <Yexo> actually the limit might be 2**14 20:39:03 <Hirundo> are action1 sprites exempt from that limit? 20:39:05 <Yexo> yes 20:39:12 <Yexo> in OpenTTD, not in TTDPatch 20:40:05 <Yexo> spritelayouts refer to the sprite number with 14 bits, grm allocated sprite are global for all grfs, so there is a limit of 2**14 of those 20:40:48 <Yexo> internally openttd uses 32 bits to identify sprites 20:41:22 <Hirundo> 16k sprites... 20:41:57 <Hirundo> newgrf.cpp:5811 if (_cur_spriteid + count >= 16384) { 20:42:01 <Hirundo> indeed 20:42:52 <Hirundo> Alternatively, just dump all sprites in one action1 20:43:05 <Hirundo> And only allocate the action2s later as needed 20:43:17 <Hirundo> but that might break horribly when using more than one feature 20:43:19 <Yexo> each action1 can only use sprites for a single feature 20:45:50 <Brot6> NewGRF Meta Language - Revision 1350:0e8b479f5e99: Doc: using some industry variables trashes the... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/0e8b479f5e99 20:47:06 <Hirundo> I have no clue on how to fix this in a nice way in all (edge) cases 20:48:54 <Brot6> FISH - Revision 645:554033be3851: Add: graphics for canal boat 1 (andythenorth) @ http://dev.openttdcoop.org/projects/fish/repository/revisions/554033be3851 20:49:54 <Brot6> NewGRF Meta Language - Revision 1351:354bfd7221f5: Codechange: Split parse_sprite_set() into mult... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/354bfd7221f5 20:49:54 <Brot6> NewGRF Meta Language - Revision 1352:f1d27249f42b: Fix: Always call prepare_output for sprite sets. (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/f1d27249f42b 20:53:47 <Brot6> FISH - Revision 646:e15fcdb73121: Cleanup: remove unneeded file (andythenorth) @ http://dev.openttdcoop.org/projects/fish/repository/revisions/e15fcdb73121 20:53:47 <Brot6> FISH - Revision 647:ebc42f0f0014: Change: work in progress on new utility vessel (andythenorth) @ http://dev.openttdcoop.org/projects/fish/repository/revisions/ebc42f0f0014 20:53:47 <Brot6> FISH - Revision 648:7f4db9cca985: Change: work in progress on canal boat 1 (andythenorth) @ http://dev.openttdcoop.org/projects/fish/repository/revisions/7f4db9cca985 20:55:45 <Yexo> Hirundo: http://paste.openttdcoop.org/show/213/ 20:57:33 <Hirundo> TTDP is 64k total, 16k for general (including GRM), right? 20:57:59 <Yexo> yes 20:59:45 <Hirundo> I think 3) should work, with the added comment that all GRM'ed sprites should go in one block (else we run out of params really fast) 21:00:04 <Yexo> I did think of that, just didn't write it down :) 21:00:07 <Yexo> so yes, indeed 21:03:49 <Brot6> NewGRF Meta Language - Bug #2649 (New): allocation sprites/spritelayouts (yexo) @ http://dev.openttdcoop.org/issues/2649 21:03:59 <Yexo> ^^ for reference of the problem 21:04:24 <Hirundo> 'adding parameters to values' has various problems of its own 21:04:56 <Hirundo> since the adding is done repeatedly for each activation, at least in TTDP 21:04:57 <Yexo> it might not be necesary, but it'll save a lot of actions 21:05:11 <Yexo> that can be worked around easily 21:05:32 <Yexo> see the example on this page: http://wiki.ttdpatch.net/tiki-index.php?page=Action6 21:05:38 <Yexo> which I've also implemented in CHIPS 21:06:54 <frosch123> just disable putting different features in one grf :) monolithic grfs are bad anyway :) 21:07:08 <Yexo> cargos + industries 21:07:23 <frosch123> do cargos have more than one icon sprite? 21:07:24 <Hirundo> airports + tiles 21:07:38 <Yexo> Hirundo: bad example, airports don't have real graphics (so no action1, hence no problem) 21:07:44 <Yexo> frosch123: no 21:07:53 <Hirundo> the airport icon in the build menu? or was that changed? 21:08:02 <Yexo> ah, indeed 21:08:14 <Yexo> it's only for the baseset that that's done via action5 21:08:24 <Hirundo> andy's HEQS contains a rail vehicle 21:08:27 <frosch123> anyway, i guess it is quite unlikely that different features use the same sprites, so those few can either be duplicated or use grm 21:08:35 <Hirundo> agreed 21:08:46 <Yexo> currently we require that the users duplicates those manually 21:09:00 <Yexo> which is imo fine, since the chance is so small that you want to reuse the same sprite for different features 21:09:14 <frosch123> http://devs.openttd.org/~frosch/diffs/ExtendedSpriteLayout_v2.diff <- wrt. adding offsets 21:09:31 <frosch123> should commit that in the next days, unless i find some big trouble 21:11:03 <Yexo> + grfmsg(1, "ReadSpriteLayoutSprite: Spritelayout specifies var10 value for non-action-1 sprite"); <- so no variable baseset sprites? 21:11:32 <Hirundo> too long to read for me now 21:11:50 <frosch123> Yexo: "!(flags & TLF_SPRITE_REG_FLAGS)" <- if that is not the case, specifying an var10 value makes no sense 21:11:57 <Hirundo> I should get some sleep, goodnight folks 21:12:02 <Yexo> gn Hirundo 21:13:40 <Yexo> frosch123: allocate a bunch of sprites via GRM, pick one via varaction2->register instead of having to create 16 real action2's 21:13:57 <Yexo> no special var10 value required, no action1 sprite either 21:14:13 <frosch123> yes, should work as well 21:15:45 <Yexo> ah, I finally got it :) 21:24:05 *** andythenorth has left #openttdcoop.devzone 21:29:06 *** ODM has quit IRC 21:30:36 <Yexo> frosch123: it looks good :) 21:30:52 <Yexo> I'll try to create a test grf for it sometime soon 21:35:00 <frosch123> the wiki page is up to date 21:40:13 <frosch123> night 21:40:17 *** frosch123 has quit IRC