Log for #openttdcoop.devzone on 11th September 2011:
Times are UTC Toggle Colours
00:00:25  <Brot6> NewGRF Meta Language - Revision 1661:015c9793c50e: Add: properly encode gender commands refering ... (yexo) @
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) @
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) @
07:21:31  <Brot6> FIRS Industry Replacement Set - Revision 2591:364abbf0e6bf: Codechange: prepare Brewery for groun... (andythenorth) @
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) @
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) @
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) @
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) @
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:
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) @
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 they're very welcome :)
10:59:11  <Yexo> in here btw:
10:59:57  <Brot6> NewGRF Meta Language - Feature #2977 (Closed): town variables (yexo) @
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 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) @
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> <-- 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) @
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>
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) @
12:52:07  <Brot6> FIRS Industry Replacement Set - Bug #3057 (New): Forest - greeble tile offsets wrong (andythenorth) @
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) @
14:32:02  *** andythenorth has joined #openttdcoop.devzone
15:00:29  <Brot6> Dutch Road Furniture - Revision 38:2f81c3f83f00: Change: rework strings (foobar) @
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 -
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) @
17:26:02  <Brot6> OpenGFX+ Airports - Feature #3058: Snow grades: vary amount of snow depending on height above sno... (yexo) @
17:28:39  <Brot6> OpenGFX+ Airports - Feature #3058: Snow grades: vary amount of snow depending on height above sno... (planetmaker) @
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) @
19:04:06  <Brot6> clientpatches: compile of r22927 still failed (#2964) -
19:09:29  <Brot6> openttd-vehiclevars: update from r22916 to r22927 done -
19:11:09  <Brot6> serverpatches: compile of r22927 still failed (#2966) -
19:12:57  <Brot6> 32bpp-ez-patches: compile of r22927 still failed (#2446) -
20:46:29  *** frosch123 has quit IRC
20:59:03  <Brot6> Central European Train Set - Feature #2924: Prussian steam engines - sprites (oberhuemer) @
21:34:19  <Brot6> Central European Train Set - Support #2750: Tracking Table (oberhuemer) @
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) @
22:20:03  <Brot6> Central European Train Set - Support #2750: Tracking Table (oberhuemer) @
22:26:31  <Brot6> Central European Train Set - Support #2750: Tracking Table (Eddi) @
22:28:55  <Brot6> Central European Train Set - Support #2750: Tracking Table (Eddi) @

Powered by YARRSTE version: svn-trunk