Times are UTC Toggle Colours
00:00:25 <Brot6> NewGRF Meta Language - Revision 1661:015c9793c50e: Add: properly encode gender commands refering ... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/015c9793c50e 00:23:47 *** JVassie has quit IRC 06:16:10 <Brot6> Revived US Trainset - Revision 13:ac7bdd4ad0a3: OTTD FS#2521 needed a test GRF. This is set up fo... (EyeMWing) @ http://dev.openttdcoop.org/projects/rust/repository/revisions/ac7bdd4ad0a3 06:35:41 *** andythenorth has joined #openttdcoop.devzone 06:48:24 <Brot6> FIRS Industry Replacement Set - Revision 2590:eba9760e5f71: Codechange: prepare Petrol Pump for g... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/eba9760e5f71 07:21:31 <Brot6> FIRS Industry Replacement Set - Revision 2591:364abbf0e6bf: Codechange: prepare Brewery for groun... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/364abbf0e6bf 07:31:54 *** frosch123 has joined #openttdcoop.devzone 07:36:36 <Brot6> FIRS Industry Replacement Set - Revision 2592:8e85b1039cb3: Codechange: prepare Textile Mill for ... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/8e85b1039cb3 07:42:54 <frosch123> is "vehicle_is_reversed" var c8 or ff bit 0 (resp. fe bit 8) ? 07:44:56 <frosch123> ah, it is fe 07:45:45 <frosch123> does the nml spec state in some way, which variables are only valid for "parent" scope? 07:47:29 <frosch123> c8 does not seem to be available in nml 07:48:41 <frosch123> suggestion: turn "vehicle_is_reversed" into var c8, and name fe bit 8 as "train_is_reversed"? 07:51:50 <Brot6> FIRS Industry Replacement Set - Revision 2593:c935f100d3eb: Codechange: prepare Metal Foundry for... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/c935f100d3eb 08:02:37 <frosch123> hmm, maybe c8 is under-specified :p 08:03:04 <planetmaker> var 0xc8? 08:03:12 <frosch123> yes 08:03:25 <frosch123> it is not what is was in ttd 08:03:41 <planetmaker> hm, not? 08:03:44 <planetmaker> what was it there? 08:04:42 <frosch123> some arbitrary index into some tables, which list the spritenumber, the number of orientations, and whether it is the reversed back-head of a dual-headed engine 08:05:13 <planetmaker> so much more 08:05:45 <frosch123> but ttdp changed it into something which specifies whether the vehicle has an action3, is reversed, and maybe also keeps the old meaning for non-newgrf engines 08:05:55 <frosch123> and likely everything is different for trains, rv, ship and aircraft :p 08:06:07 <planetmaker> :-D 08:06:48 <planetmaker> do you have plans for that var? 08:07:12 <frosch123> see above? 08:07:27 <frosch123> i suggested to make it the base of "vehicle_is_reversed" 08:07:40 <frosch123> as fe bit 8 does not fit that name 08:09:41 <planetmaker> hm, I see 08:10:38 <Brot6> FIRS Industry Replacement Set - Feature #2755: Grain Mill snow sprites need finishing (andythenorth) @ http://dev.openttdcoop.org/issues/2755#change-7830 08:11:59 <andythenorth> planetmaker: I wonder if spritelayouts_groundaware is just calculating snowline incorrectly? 08:12:08 <planetmaker> might be 08:14:49 <Brot6> Revived US Trainset - Revision 14:4c723cd248be: Added stock cars. (EyeMWing) @ http://dev.openttdcoop.org/projects/rust/repository/revisions/4c723cd248be 08:26:40 <andythenorth> meh 08:27:43 * andythenorth wonders if the hide sprite conditions are correct 08:30:14 <planetmaker> probably not 08:31:38 <andythenorth> nml can output nfo? :P 08:31:42 <andythenorth> I could check it 08:32:25 <frosch123> good luck with validating nml output :p 08:33:12 <andythenorth> ok 08:33:17 <andythenorth> something is wrong with those conditions 08:33:18 <planetmaker> andythenorth: I think they aren't 08:33:51 <andythenorth> why are they conditional between two values? 08:34:03 <andythenorth> oh I get it 08:34:28 <andythenorth> unless I misunderstand, they're not going to work as expected 08:35:29 <andythenorth> why don't these snow sprites appear in temperate / tropic? 08:35:35 <andythenorth> the logic implies they should 08:35:41 <andythenorth> unless hide_sprite means 'show sprite' 08:39:51 *** JVassie has joined #openttdcoop.devzone 08:47:07 *** FooBar has joined #openttdcoop.devzone 09:14:02 <planetmaker> hide_sprite means hide. 09:14:11 <planetmaker> Didn't I post a patch attempt yesterday evening? 09:14:22 <andythenorth> yes 09:14:27 <andythenorth> it broke the build :) 09:14:50 <planetmaker> sure it wasn't your local mods? 09:17:19 <andythenorth> no 09:17:23 <andythenorth> does it build for you? 09:17:39 <planetmaker> I didn't try 09:17:50 <V453000> is there any simple way how to guess the offsets without seeing it in the game? Like (width/2)*(-1) for the xofs? 09:18:05 <Yexo> copy from similar-sized sprites? 09:18:09 <Yexo> that's what I do 09:18:30 <V453000> yes, I copied them from Pikka in the end 09:18:46 <V453000> is there any difference between nfo and nml offsets? 09:18:51 <Yexo> no 09:18:59 <V453000> awesome :) thanks 09:19:14 <Yexo> just mind the different order when writing them 09:20:34 <FooBar> offsets are in the same order. width/height are the other way round in nfo 09:22:21 <FooBar> and remember that nml has commas between values and nfo doesn't. So that you don't go Y U NO WORK?! like I once did :P 09:37:05 <andythenorth> toop toop toop 09:37:08 * andythenorth goes out 09:37:10 *** andythenorth has quit IRC 09:37:55 <Ammler> V453000: why do you care about nfo, not enough nml examples? 09:47:11 <FooBar> who, me? Well, if you have existing nfo code that you want to port to nml, you need to care about nfo too 09:47:41 <FooBar> oh, misread, not me :) 09:48:17 <FooBar> but I guess the same reasoning applies: if you want to use pikka's vehicle templates then you need to care about nfo :P 09:48:25 <frosch123> do you sometimes wake up and think you are V453000? 09:49:11 <FooBar> in fact I didn't even see that V was highlighted :$ 09:50:55 <planetmaker> FooBar: why would one need to care about NFO when using pikka templates? 09:51:12 <planetmaker> And... why not use the nml-ified version of them I have somewhere in my projects (opengfx or opengfx+trains)? 09:51:26 <FooBar> because those are in nfo. So you need to do the switching of width/height 09:51:42 <planetmaker> well, that's why I nml-ified them for my use ;-) 09:51:48 <FooBar> have you seen the ones in opengfx? Those are really confusing and I couldn't find which is which :P 09:52:10 <planetmaker> I've written them :-P 09:52:14 <FooBar> I know 09:52:36 <planetmaker> thus I've definitely seen them. Even though I can type blind with 10 fingers ;-) 09:53:49 <planetmaker> well, I guess you're right, though, FooBar 09:54:14 <planetmaker> Basically it looks complicated, though, as one template references the other, more general one. In several places. Same for reversed etc 09:54:19 <Rubidium> planetmaker: but does it go right when you don't watch the screen/output? 09:54:35 <planetmaker> Rubidium: in the majority of the cases: yes 09:54:47 <planetmaker> Thus I can type like now without looking what I actually write. 09:55:02 <planetmaker> The only difficulty is when I sense that I did a typo. Correcting doesn't really work without looking 09:55:59 <FooBar> yes, that's why I gave up on those. If I can't tell which is which directly from looking at it I don't want to invest too much time. Must say that the templates in opengfx+ look much more clear 09:56:17 <planetmaker> :-) 09:56:31 <planetmaker> they're 'prior art' ;-) 09:57:03 <FooBar> they sure are 09:57:17 <FooBar> that's why I did this why I needed something different: http://dev.openttdcoop.org/projects/opengfx/repository/diff/sprites/nml/templates/tmpl_trains.nml?rev=1dba75fb6a13&rev_to=583ca3264b73 09:57:27 <FooBar> didn't dare to touch the art :P 10:01:07 <FooBar> but feel free to add those to your art structure 10:01:27 <planetmaker> only when I feel like doing train alignment again 10:01:42 <planetmaker> Which is... something I'd rather outsource to you ;-) 10:02:05 <planetmaker> I re-did the whole alignment at least twice for all rail vehicles 10:02:11 <planetmaker> And it was not fun 10:02:47 <planetmaker> thus: thanks, but no thanks for now :-) 10:06:57 <FooBar> you're welcome :) 10:29:46 <Brot6> NewGRF Meta Language - Revision 1664:e2d91543fd9a: Feature #2977: support for town variables (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/e2d91543fd9a 10:53:59 *** andythenorth has joined #openttdcoop.devzone 10:59:02 <Yexo> if anyone could write a better description for the NML town_zone_*_radius_square variables than linking to http://newgrf-specs.tt-wiki.net/wiki/TownZones they're very welcome :) 10:59:11 <Yexo> in here btw: http://newgrf-specs.tt-wiki.net/wiki/NML:Towns 10:59:57 <Brot6> NewGRF Meta Language - Feature #2977 (Closed): town variables (yexo) @ http://dev.openttdcoop.org/issues/2977#change-7831 11:02:50 <frosch123> why should it be different to the TownZones page? 11:04:08 <Yexo> it doesn't have to be different 11:14:31 <Hirundo> The radii on http://newgrf-specs.tt-wiki.net/wiki/TownZones aren't squared, are they? 11:14:53 <planetmaker> they aren't 11:15:34 <Yexo> so NML:Towns should include a note about that 11:15:51 <andythenorth> how does spritelayouts_groundaware do the terrain specific tiles 11:15:55 <andythenorth> it appears to be magic 11:16:22 <andythenorth> draw default ground. Then stack more tiles on top to increase specifity? 11:16:34 <planetmaker> yup 11:16:37 <andythenorth> ok 11:16:41 <Hirundo> Yexo, could you change percentages to do *101/256 instead of *100/256? 11:17:03 <Hirundo> That's what the GUI does as well IIRC 11:17:12 <planetmaker> i.e. you always get the ground as it was without industry. Then stack on it what you want 11:17:35 <andythenorth> except that's the bug I'm trying to fix :P 11:17:39 <andythenorth> ground is wrong 11:19:06 <Yexo> Hirundo: gui doesn't display these percentages at all 11:19:47 <planetmaker> which industry should I check, andythenorth? 11:19:51 <Yexo> AIs get the value *101/256 indeed 11:19:56 <Hirundo> no? then what are they used for? 11:20:00 <andythenorth> planetmaker: grain mill 11:20:02 <andythenorth> but let me fix it 11:20:06 <Yexo> AIs and NewGRFs 11:20:08 <planetmaker> k 11:20:10 <andythenorth> it means I learn the code of the underlying template 11:20:22 <andythenorth> without that, I can't write industry code, it's all just magic 11:20:28 <Yexo> I'm actually wondering why the value is stored at all and not computed on the fly when necessary 11:20:43 <andythenorth> does drawing / hiding tile sprites have any performance side-effects? 11:21:18 <Yexo> andythenorth: yes, but unless proven otherwise we assume it's not significant 11:21:40 <andythenorth> is there ever a case where not-snow will reappear above snowline? 11:21:53 <Hirundo> What a waste of bytes...apparently even in TTDP as it's a 80+x var 11:21:54 <Yexo> bulldozing snow? 11:21:57 <andythenorth> i.e. bare ground, snow, bare ground again 11:22:04 * andythenorth doubts it's valid 11:22:14 <Yexo> Hirundo: yes, that means it was a var in TTD (which may have used it somewhere) 11:22:32 * andythenorth thinks a simpler set of conditions can be used 11:22:50 <andythenorth> it's just a stack, and the order/conditions are deterministic 11:22:54 * andythenorth likes stacks 11:23:33 <Brot6> NewGRF Meta Language - Revision 1665:cda3d3a99f14: Fix-ish: multiply 'percentages' by 101 instead... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/cda3d3a99f14 11:27:37 <andythenorth> why does the ground aware template only apply full snow for snowline + 16? 11:27:56 <andythenorth> it should be snowline + 8 iirc, unless we're measuring in half-tile heights 11:29:19 <planetmaker> iirc +16 is correct 11:29:44 <planetmaker> but I might remember wrong. But I tested it somehow 11:29:59 <planetmaker> just not the revers conditions 11:30:04 <andythenorth> the docs probably know the answer :P 11:30:11 <planetmaker> hardly :-) 11:30:17 <planetmaker> docs know snow yes/no 11:31:42 <andythenorth> is it the case that snowline floor is 8 tiles below where snowline starts being drawn? 11:31:56 <andythenorth> floor / tile height /s 11:33:11 <planetmaker> only sure answer can be 'test' 11:33:24 <planetmaker> but that's how I figured it 11:37:41 <andythenorth> in that case, why not just change definition of snowline constant? 11:37:43 * andythenorth will test 11:37:58 <planetmaker> it's a variable which is ingame 11:38:13 <planetmaker> and changing that would be bad as it often defines the black/white transition 11:38:17 <planetmaker> thus it should be in the middle 11:39:23 <andythenorth> but if the variable needs an offset, surely we just do var-8 as the constant? I'm guessing btw - still working on a test :P 11:41:16 * andythenorth wishes for a faster compile :D 11:41:29 <andythenorth> nvm 11:42:48 <planetmaker> The variable doesn't need an offset 11:42:58 <planetmaker> for snow yes/no it is exactly correct 11:43:24 <planetmaker> e.g. for showing snow on a building you still check for TILETYPE_SNOW which is equivalent to height >= snowline 11:43:48 <planetmaker> just the transition is centred around. 11:44:56 <andythenorth> why is GROUNDSPRITE_SNOW a constant, but the intermediate snow stages aren't? Overkill? 11:46:07 <Yexo> are the intermediate snow stages TTD sprites or are those included in the newgrf? 11:46:29 <planetmaker> TTD sprites 11:46:34 <planetmaker> for the ground 11:47:02 <planetmaker> of course it only works, if there's not another ground 11:47:03 <andythenorth> can't nml handle this? 11:47:32 <planetmaker> GROUNDSPRITE_SNOW is also just 4550 11:47:38 <andythenorth> indeed 11:47:40 <planetmaker> the others could get constants as well 11:48:06 <andythenorth> hmm 11:48:10 <andythenorth> my logic is broken 11:48:34 * planetmaker has something which seems to work 11:48:58 * andythenorth keeps hacking 11:49:38 <andythenorth> is there anything significant about whitespace in calculation? 11:49:49 <andythenorth> e.g. is 'snowline_height-8' valid? 11:50:05 <Yexo> whitespace is insignificant 11:50:33 <Yexo> "snowline_height-8" is the same as "snowline_height -8" and "snowline_height \n\n - 8" (where \n is newline) 11:50:42 <andythenorth> in which case I am sulking 11:50:49 <andythenorth> hide_sprite: (climate == CLIMATE_ARCTIC) && (nearby_tile_height(0, 0) < (snowline_height - 8)); \ 11:50:52 <andythenorth> fails to do what it should 11:51:27 <andythenorth> I don't have to wrap the condition in extra brackets? 11:51:29 <planetmaker> hides the sprite in arctic climate below snow 11:51:55 <andythenorth> except it doesn't 11:51:57 <andythenorth> it should 11:53:54 <andythenorth> hmm 11:54:07 * andythenorth inspects the conditional ground overlay 11:54:35 <andythenorth> this will be fun 11:54:45 <andythenorth> planetmaker CONDITIONAL_GROUND_SPRITE_OVERLAY need to be better educated about snowline 11:54:57 <Yexo> <andythenorth> hide_sprite: (climate == CLIMATE_ARCTIC) && (nearby_tile_height(0, 0) < (snowline_height - 8)); \ <- are you sure that is what you want? 11:55:06 <Yexo> that will mean "show sprite in temperate" for example 11:55:24 <planetmaker> andythenorth: as I said: conditions are probably wrong. Actually they are 11:55:43 <planetmaker> they are reversed mostly 11:56:27 <andythenorth> is there a show_sprite equivalent of hide_sprite? 11:56:53 <andythenorth> although extending the conditions is fine too 11:56:58 <Yexo> if you want to write "show_sprite: some_expression;" write "hide_sprite: !(some_expression);" instead 11:57:16 <Yexo> perhaps NML should allow "show_sprite" too and do that automatically 11:57:17 <andythenorth> doesn't matter if these expressions are complex, as long as it's understandable logic 11:57:19 <Yexo> Hirundo: ? ^^ 11:57:44 <andythenorth> the conditions for snow transition etc. are *not* simple, so the code won't be 11:57:59 <Yexo> andythenorth: which templates are you looking at? 11:58:12 <andythenorth> spritelayouts_groundaware 11:58:14 <planetmaker> spritelayout_groundaware.pnml 11:58:15 <andythenorth> in FIRS 11:58:27 <planetmaker> I wrote it basically as show_sprite indeed 11:58:38 <Yexo> yes, I see 12:00:06 <planetmaker> may I fix it? 12:00:13 <planetmaker> after all I broke it ;-) 12:00:43 <planetmaker> http://devs.openttd.org/~planetmaker/patches/snowawareness.diff <-- should do the trick 12:00:54 <planetmaker> best test here actually is the builder's yard. It shows the actual ground 12:02:02 <andythenorth> give a man a fish, feed him for a day. teach a man to fish... 12:02:03 <andythenorth> :P 12:02:14 <andythenorth> except you can't teach me this, I have to hack at it for myself 12:02:19 <planetmaker> :-) 12:02:20 * andythenorth tests the diff 12:02:34 <planetmaker> it's only about logic... it's nothing fancy really 12:03:19 <andythenorth> the snow is now accurate for grain mill wrt height 12:03:29 <andythenorth> the yard tile overlay should be better educated about snow 12:03:38 <planetmaker> as said: test builder's yard works perfect 12:03:53 <planetmaker> that's what I test it on as it shows the ground sprite directly 12:04:15 <planetmaker> grain mill hides it in many cases by the cobble stones 12:04:27 <andythenorth> yes 12:05:28 <andythenorth> I'm not planning to draw partial-snow cobbles 12:05:35 <planetmaker> so I thought 12:05:43 <planetmaker> would be a pain, too ;-) 12:06:09 <planetmaker> though... andy, what one could do: take the full cobble stone and add transparent blue sprinkles 12:06:11 <andythenorth> in that case, the yard overlay stops being drawn one level too soon 12:06:13 <planetmaker> easy 12:06:39 <andythenorth> planetmaker: it would look bad with the other ground overlay - e.g gardens etc 12:06:45 <planetmaker> hm? 12:06:50 <planetmaker> it = ? 12:08:55 <Hirundo> show_sprite makes sense 12:09:02 <planetmaker> yes, it does 12:10:25 <andythenorth> planetmaker: it = snow overlay 12:10:29 <andythenorth> partial 12:13:41 <Brot6> FIRS Industry Replacement Set - Revision 2594:2cdc6abcd4fa: Fix: Grain Mill building snow off-by-... (andythenorth) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/2cdc6abcd4fa 12:13:50 <Hirundo> planetmaker: What's the use for the climate checks in the desert ground tile code? there isn't any desert in non-tropical, right? 12:14:37 <andythenorth> at least 9,000 questions for planetmaker today :) 12:14:49 <planetmaker> Hirundo: but in tropical 12:14:53 <planetmaker> err... in arctic 12:15:06 <planetmaker> snow = desert 12:15:13 <andythenorth> terrain_type != TILETYPE_SNOW is not a viable condition for yard tiles 12:15:19 <andythenorth> it will have to be a snowline height check 12:15:32 <planetmaker> for? 12:16:02 <planetmaker> for me the builder's yard works as it should 12:16:05 <planetmaker> with my diff 12:16:17 <andythenorth> I'll paste screenie in 5 mins :) 12:16:34 * andythenorth -> pizza 12:19:49 <Hirundo> desert sprites occupy the same slots (GROUNDSPRITE_SNOW == GROUNDSPRITE_DESERT) as snow sprites, but TILETYPE_SNOW != TILETYPE_DESERT 12:20:19 <planetmaker> hm, ok. Still. It's cleaner IMHO to check for climate, too 12:20:46 <Yexo> for snow that's not needed 12:21:03 <Yexo> snowline_height in temperate/tropic is high above the max map height 12:23:24 <planetmaker> unless it ever gets changed ;-) 12:23:32 <planetmaker> with an all-climates thing ;-) 12:24:30 <Yexo> in which case checking the climate doesn't help either 12:24:43 <Yexo> you'll have to check for tiletype in that case 12:24:54 <Hirundo> ^^ including assumptions about climate in your NML is probably a bad idea then 12:25:43 <Yexo> climate is a global grf thing, it's the same for all tiles, while tiletype is per tile and as such can support multiple climates in one game 12:26:16 <andythenorth> it's frustrating that tiletype is not canonical 12:26:24 <andythenorth> it's the usual hysterical raisins :P 12:28:26 <Hirundo> "tiletype is not canonical" <- in what sense? 12:28:28 <andythenorth> presumably the tile type is canonical within ottd 12:29:04 <andythenorth> the tiletype exposed to newgrf is insufficient to determine what the tile type is 12:29:31 <Hirundo> you can choose between normal, tropical, desert and snow. What else would you want? 12:29:59 <andythenorth> snowline + coasts are very difficult cases 12:30:14 <andythenorth> I haven't tried anything with rivers, but they are probably equally different 12:30:19 <andythenorth> different / difficult /s 12:30:23 <planetmaker> check waterclass 12:30:46 <andythenorth> does that fix the coast madness? 12:31:23 <planetmaker> not really or entirely 12:31:33 <planetmaker> depends though what you mean with 'madness' 12:31:37 <andythenorth> working with tiletype is typically "if it's tuesday it must be blue, expect if it's raining, then it's red, or if there is an r in the month it will be green' 12:32:05 <andythenorth> it gives a false impression of being definitive. It isn't 12:32:37 <planetmaker> it gives you the type. Not the details 12:33:15 <planetmaker> but agreed, could be nicer 12:33:44 <andythenorth> anyway 12:33:55 <andythenorth> here is the case where yard tile is missing (last partial level of snow) 12:33:55 <andythenorth> http://tt-foundry.com/misc/snowline_partial_incorrect.png 12:34:18 <andythenorth> meanwhile the snow ground overlay is show and shouldnt' be 12:34:34 <andythenorth> also, building snow needs to start 1 or 2 levels higher 12:34:40 <andythenorth> this means more specific checks 12:36:19 <andythenorth> partial snow with buildings is basically a massive headache :) 12:38:03 <andythenorth> planetmaker: do you want to commit your diff anyway? 12:43:03 <planetmaker> yes, on the last partial snow level there's an issue. Thus one could (should?) show the snowy ground with the condition height >= snowline_height + 16 or similar instead of TILETYPE_SNOW 12:43:14 <planetmaker> or provide an additional conditional groundsprite ;-) 12:43:48 <andythenorth> planetmaker: the default game just draws full snow for buildings at that level 12:43:56 <planetmaker> but that's not an issue so much of the ground awareness as of the conditions of the "user-supplied" sprites 12:43:56 <andythenorth> FIRS should do same 12:44:10 <planetmaker> andythenorth: yes, as it ignores snow transition 12:44:27 <planetmaker> of course one could also just draw full snow there and ignore the 3/4 snow level 12:44:52 <planetmaker> Not sure it's good in all cases... 12:44:53 <andythenorth> ignoring snow transition might be correct approach (except for terrain tile) 12:45:01 <planetmaker> well. That's it :-) 12:45:20 <planetmaker> just add in the cases you need it an additional, conditional full snow ground tile 12:45:22 <andythenorth> most non-organic industries don't show terrain 12:45:23 <planetmaker> easy 12:45:27 <planetmaker> with a height check 12:45:30 <planetmaker> in the spritelayout 12:45:42 <andythenorth> ok 12:45:46 <planetmaker> i.e. as 100% opaque overlay 12:46:07 <planetmaker> then builder's yard doesn't need it, but grain mill does 12:46:30 <planetmaker> I'll commit it then as-is. 12:46:40 <andythenorth> thankjs 12:47:28 <Brot6> FIRS Industry Replacement Set - Revision 2595:ab7afbf770bb: Fix: Conditions for ground awareness ... (planetmaker) @ http://dev.openttdcoop.org/projects/firs/repository/revisions/ab7afbf770bb 12:52:07 <Brot6> FIRS Industry Replacement Set - Bug #3057 (New): Forest - greeble tile offsets wrong (andythenorth) @ http://dev.openttdcoop.org/issues/3057 13:30:07 <andythenorth> bbl 13:30:08 *** andythenorth has quit IRC 14:17:48 *** ODM has joined #openttdcoop.devzone 14:27:08 <Brot6> Dutch Road Furniture - Revision 37:cc293c2aa1b4: Feature: motorway signs (foobar) @ http://dev.openttdcoop.org/projects/dutchroadfurniture/repository/revisions/cc293c2aa1b4 14:32:02 *** andythenorth has joined #openttdcoop.devzone 15:00:29 <Brot6> Dutch Road Furniture - Revision 38:2f81c3f83f00: Change: rework strings (foobar) @ http://dev.openttdcoop.org/projects/dutchroadfurniture/repository/revisions/2f81c3f83f00 15:11:30 <Yexo> would people get very mad if NML would start creating output for OpenTTD r22926 and later only? :p 15:11:42 * planetmaker wouldn't 15:11:58 <planetmaker> My NewGRFs are meanwhile anyway all for OpenTTD 1.2.0-alpha 22780+ 15:12:19 <planetmaker> so no difference for me 15:12:27 <frosch123> someone cares about nforenum? 15:12:35 <planetmaker> But I guess there are people who do care 15:12:52 <planetmaker> Well... I guess ogfx+trains or so would be nice to continue to work 15:13:04 <Yexo> frosch123: shouldn't be too hard, right? 15:13:08 <Yexo> I can take a look if you don't want to 15:13:38 <Yexo> <planetmaker> Well... I guess ogfx+trains or so would be nice to continue to work <- that was the mean reason I asked ;) 15:13:52 <Yexo> guess nml will have to wait with this until openttd 1.2 (maybe -beta1) is out 15:14:02 <Yexo> or else have a way of disabling it 15:14:15 <planetmaker> hm... I'd like it for FIRS and ogfx+industries ;-) 15:14:37 <Yexo> are you sure you understand the feature? I'm not sure you'd notice anything 15:15:30 <planetmaker> if I understood it correctly, I could then do without the all equal numbers in spritesets 15:16:12 <planetmaker> but I'm not entirely sure I understood it all :-) 15:16:18 <Yexo> you understood that right 15:16:33 <Yexo> I forgot about that part 15:16:49 <Yexo> and merely thought about referencing earlier spritesets after using sprites from another feature 15:16:56 <Yexo> that just means less duplication in some cases 15:17:08 <planetmaker> :-) Yes. Both sprites and code actually :-) 15:17:41 <Yexo> I don't think that'll result in code or sprite deduplication, at least not at nml-code level 15:17:45 <Yexo> just in the final grf output 15:18:54 <planetmaker> iirc I could remove some sprites from spritesets in some cases in FIRS 15:23:15 <planetmaker> on the other hand, another release of ogfx+trains could either be done with current nmlc 15:23:29 <planetmaker> but I'm sure other people will mind actually if it doesn't work with stable OpenTTD 15:25:00 <FooBar> I'd wait until the next stable release before making such thing mandatory 15:25:42 <FooBar> Don't get me wrong, I like the feature (I was just duplicating sprites myself for that very reason), but people also like to make grfs that work with a stable 15:26:25 <FooBar> Once there is an OpenTTD 1.2.0 I don't care. Let it be an incentive for people to upgrade their game if they want the newest grfs 15:27:43 <frosch123> though that idea fails, if ottd is left untested :p 15:28:34 <Yexo> nah, I think FooBar has a good point 15:28:35 <FooBar> you have a point there... Then it must be made optional in NML 15:28:50 <Yexo> lets finish NML 0.2.0 as soon as possible and after that make it mandatory in nml trunk 15:28:51 <FooBar> but I don't mind patching NML and testing the feature here 15:29:03 <Yexo> people writing grfs for openttd 1.1 could use nml 0.2, others can use nml trunk 15:29:16 <FooBar> I have 99% for the code to test it here, just needs a bit of renaming and some removing 15:29:32 <FooBar> Yexo: that sound like a plan! 15:30:28 <planetmaker> sounds like a good plan with 0.2, Yexo :-) 15:30:52 <frosch123> so nml x would required ottd (x+0.9) :p 15:31:23 <Yexo> nml already supports advanced sprite layouts, which are not supported by openttd 1.1 15:31:38 <Yexo> but that feature is optional, if you know what it is you can avoid using it 15:31:40 <FooBar> true, but you don't have to use those 15:31:44 <FooBar> :) 15:31:58 <FooBar> anyways, dinner 15:34:07 <planetmaker> sounds like a good plan actually :-) 16:28:10 *** FooBar has quit IRC 17:11:47 <Brot6> nml: update from r1663 to r1665 done - http://bundles.openttdcoop.org/nml/nightlies/r1665 17:13:26 *** andythenorth has left #openttdcoop.devzone 17:20:17 <Brot6> OpenGFX+ Airports - Feature #3058 (New): Snow grades: vary amount of snow depending on height abo... (dnicholls) @ http://dev.openttdcoop.org/issues/3058 17:26:02 <Brot6> OpenGFX+ Airports - Feature #3058: Snow grades: vary amount of snow depending on height above sno... (yexo) @ http://dev.openttdcoop.org/issues/3058#change-7832 17:28:39 <Brot6> OpenGFX+ Airports - Feature #3058: Snow grades: vary amount of snow depending on height above sno... (planetmaker) @ http://dev.openttdcoop.org/issues/3058#change-7833 17:40:01 *** andythenorth has joined #openttdcoop.devzone 17:51:26 *** andythenorth has quit IRC 18:51:22 <Brot6> Central European Train Set - Feature #2924: Prussian steam engines - sprites (oberhuemer) @ http://dev.openttdcoop.org/issues/2924#change-7834 19:04:06 <Brot6> clientpatches: compile of r22927 still failed (#2964) - http://bundles.openttdcoop.org/clientpatches/testing/ERROR/r22927 19:09:29 <Brot6> openttd-vehiclevars: update from r22916 to r22927 done - http://bundles.openttdcoop.org/openttd-vehiclevars/testing/r22927 19:11:09 <Brot6> serverpatches: compile of r22927 still failed (#2966) - http://bundles.openttdcoop.org/serverpatches/testing/ERROR/r22927 19:12:57 <Brot6> 32bpp-ez-patches: compile of r22927 still failed (#2446) - http://bundles.openttdcoop.org/32bpp-ez-patches/testing/ERROR/r22927 20:46:29 *** frosch123 has quit IRC 20:59:03 <Brot6> Central European Train Set - Feature #2924: Prussian steam engines - sprites (oberhuemer) @ http://dev.openttdcoop.org/issues/2924#change-7835 21:34:19 <Brot6> Central European Train Set - Support #2750: Tracking Table (oberhuemer) @ http://dev.openttdcoop.org/issues/2750#change-7837 21:39:22 *** JVassie has quit IRC 21:41:33 *** ODM has quit IRC 21:55:20 <Brot6> Central European Train Set - Support #2750: Tracking Table (Eddi) @ http://dev.openttdcoop.org/issues/2750#change-7838 22:20:03 <Brot6> Central European Train Set - Support #2750: Tracking Table (oberhuemer) @ http://dev.openttdcoop.org/issues/2750#change-7839 22:26:31 <Brot6> Central European Train Set - Support #2750: Tracking Table (Eddi) @ http://dev.openttdcoop.org/issues/2750#change-7840 22:28:55 <Brot6> Central European Train Set - Support #2750: Tracking Table (Eddi) @ http://dev.openttdcoop.org/issues/2750#change-7840