Times are UTC Toggle Colours
00:45:58 *** KenjiE20 has quit IRC 01:40:38 *** thgergo has quit IRC 02:49:19 *** Lakie has quit IRC 05:23:20 *** Brot6 has quit IRC 05:52:29 *** Brot6 has joined #openttdcoop.devzone 06:26:53 *** Brot6 has quit IRC 06:27:31 *** Brot6 has joined #openttdcoop.devzone 06:30:52 *** Brot6 has quit IRC 06:31:30 *** Brot6 has joined #openttdcoop.devzone 06:32:24 *** Brot6 has quit IRC 06:32:50 *** Brot6 has joined #openttdcoop.devzone 07:53:38 *** ODM has joined #openttdcoop.devzone 07:56:58 <dih> hello ODM 07:57:03 <dih> have a look at grapes ^^ 08:07:43 <ODM> yoho 08:07:46 <ODM> and a bottle of rum 08:14:38 <ODM> looks quite nice from a quick overview 08:15:48 <dih> i'll add a protected <P extends GrapePlugin> P getPlugin(Method m) method to avoid invoking static methods only ^^ 08:16:27 <dih> then it can return the Instance stored under m.getClass() 08:21:27 <planetmaker> moin 08:29:53 <Rubidium> moi 09:02:19 <dih> i was thinking of creating a subproject of grapes, which may hold all plugins we write, if that is not too many projects for the host ;-) 09:03:05 <dih> it would be a multi project maven setup, so that all plugins are in one repo 09:43:06 <planetmaker> usually every project has its own repo 10:01:20 <dih> http://188.64.43.14:8080/hudson 10:01:21 <dih> :-P 10:03:57 <dih> just have an issue getting that stupid reverse proxy to work as desired 10:34:42 <dih> planetmaker, :-) 10:34:43 <dih> http://hudson.dihedral.de/ 10:35:29 <planetmaker> page not found? 10:35:46 <dih> oh - shoot :D 10:35:48 <dih> dns :-P 10:36:31 <dih> there is a redmine plugin for hudson and a hudson plugin for redmine - i think they kind of go together 10:38:22 <planetmaker> and it only seems to support cvs and svn 10:39:07 <dih> ho no :-P 10:39:15 <dih> i already have jones and grapes setup 10:39:18 <dih> *joan 10:39:54 <dih> dns should be working 10:43:14 <Ammler> dih: Hudson plugin installed 10:43:24 <dih> \o/ 10:43:30 <dih> you are a star ^^ 10:45:10 <Ammler> mäh, you are second telling me that this morning :-P 10:45:31 <Ammler> I am not sure, if that is a compliment :-) 10:46:57 * Rubidium thought that planetmaker was the star 10:47:48 <planetmaker> :-P planets are made at the same time as stars ;-) 10:48:04 <planetmaker> Once the star is made, the planets either are done or they're 'aborted' :-P 10:50:25 <dih> lol 10:50:51 <dih> Ammler, it was a "mere" gratitude to the work you do :-) 10:51:04 <dih> by the way, the hudson plugin for redmine - how 'configurable' is it? 10:52:27 <Ammler> http://dev.openttdcoop.org/hudson_settings/edit/grapes 10:52:37 <dih> http://dev.openttdcoop.org/hudson_settings/edit/grapes 10:52:43 <dih> eh. sorry 10:52:50 <Ammler> I should not know more than you about it :-P 10:52:53 <dih> i wanted to give you the 403 error - not Authorized 10:53:01 <Ammler> hmm 10:53:31 <Ammler> does that need admin? 10:53:37 <Ammler> oh, wait 10:53:46 <Ammler> maybe I need to setup rules 10:54:08 <Ammler> try again :-P 10:54:24 <dih> \o/ 10:54:37 <dih> you are a star ? :-D 10:54:39 * dih hides 10:59:14 <Rubidium> oh, so planetmaker is Ammler's daddy? :) 10:59:42 <planetmaker> :-P 11:05:13 <dih> Ammler, can the hudson tab be publicly visible (not the build button though) 11:08:15 *** Brot6 has quit IRC 11:08:40 *** Brot6 has joined #openttdcoop.devzone 11:18:34 <Ammler> it could 11:21:32 <Ammler> building is active for manager and dev 11:21:43 <Ammler> and settings for manager 11:22:16 <Ammler> but then you might need to setup user in the hudson settings 11:27:28 <dih> i will - still need to get the redirecto working properly :-( 11:30:33 *** KenjiE20 has joined #openttdcoop.devzone 11:48:36 *** KenjiE20 has quit IRC 12:07:23 <Brot6> NewGRF Meta Language - Revision 980:57085d42165b: Codechange: Use ASTSpriteGroup for sprite group... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/57085d42165b 12:07:23 <Brot6> NewGRF Meta Language - Revision 981:fd17de8b1b36: Cleanup: Remove unneeded parts of register / re... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/fd17de8b1b36 12:07:23 <Brot6> NewGRF Meta Language - Revision 979:7fe1e7f8468a: Add: A new abstract base class for sprite group... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/7fe1e7f8468a 12:07:25 <Brot6> NewGRF Meta Language - Revision 982:150fec6d685b: Codechange: Strip the spriteblock down to nothi... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/150fec6d685b 12:07:29 <Brot6> NewGRF Meta Language - Revision 983:ed557d48df56: Feature #1695: Allow placing sprite sets and gr... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/ed557d48df56 12:07:33 <Brot6> NewGRF Meta Language - Revision 985:8c6dc4fd4c29: Change #1695: Deprecate spritblock and emit a w... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/8c6dc4fd4c29 12:07:37 <Brot6> NewGRF Meta Language - Revision 986:3b8137c4c3ac: Doc: Remove references to sprite blocks from th... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/3b8137c4c3ac 12:07:41 <Brot6> NewGRF Meta Language - Revision 984:e6fc0a21e3e0: Change: Remove spriteblock from the regression ... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/e6fc0a21e3e0 12:07:44 <planetmaker> o_O... newgrf breaker ahead ;-) 12:07:52 <Hirundo> It's just warnings, for now 12:12:24 <planetmaker> that's just support for lazyness ;-) 12:13:25 <planetmaker> But I think it's a very nice change to not require the spriteblocks :-) 12:24:31 <Yexo> nice work Hirundo :) 12:55:29 <ODM> wooo...wondering why your testrun takes so long, then finding out youre working on the big dataset, not the tiny one for testing:P 13:00:20 <planetmaker> lol 13:01:21 <dih> ODM: http://hudson.dihedral.de :-) 13:01:22 <Webster> Title: Dashboard [Hudson] (at hudson.dihedral.de) 13:03:45 *** Brot6 has quit IRC 13:04:07 *** Brot6 has joined #openttdcoop.devzone 13:13:21 <ODM> who's hudson?:D 13:13:48 <planetmaker> the one who discovered the river, you know ;-) 13:13:56 <ODM> cheers....:D 13:13:57 <planetmaker> and the bay 13:13:59 <planetmaker> :-) 13:14:16 <ODM> note to self: clustering is boring 13:14:56 <dih> hudson is a build server 13:14:58 <planetmaker> Hm. Hudson didn't discover it. It was only named after him 13:15:14 <ODM> aah 13:20:43 <Brot6> GRFCodec - Revision 786:ca2407df7b85: Change: 5.0.0 is released, so the nightly version needs to ... (Ammler) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/ca2407df7b85 13:37:01 *** KenjiE20 has joined #openttdcoop.devzone 13:37:08 <dih> oh, ODM i still have something for you :) 13:37:34 <dih> there is a SimplePlugin source jar 13:37:48 <dih> if you look into it, you will see what must be done to create a plugin 13:58:08 <dih> i am still thinking of an addition which allows specifying an 'invoke' method to an annotation, in case the 'general' invoke method will not do 14:00:55 <dih> which would definately be the case for defining a command 14:01:06 <Brot6> Unable to connect to http://dev.openttdcoop.org/sys/: execution expired 14:01:15 <planetmaker> :-| 14:02:41 <dih> you look pretty there planetmaker ^^ 15:09:30 <Brot6> OpenGFX+ Trains - Revision 87:18fd0b11cd2d: Change: Remove deprecated use of sprite blocks (planetmaker) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/18fd0b11cd2d 15:16:52 <Brot6> Swedish Rails - Revision 188:118dc636cecc: Change: Remove deprecated use of sprite blocks (planetmaker) @ http://dev.openttdcoop.org/projects/swedishrails/repository/revisions/118dc636cecc 15:20:21 <Brot6> OpenGFX+ Airports - Revision 66:a4b1abaf6071: Change: Remove deprecated use of sprite blocks and ... (planetmaker) @ http://dev.openttdcoop.org/projects/airportsplus/repository/revisions/a4b1abaf6071 15:26:01 <Brot6> OpenGFX+ Road Vehicles - Revision 24:6824664c46d2: Change: Remove deprecated use of sprite blocks (planetmaker) @ http://dev.openttdcoop.org/projects/ogfx-rv/repository/revisions/6824664c46d2 15:58:10 *** Lakie has joined #openttdcoop.devzone 16:38:28 <Brot6> 2cc train set - Feature #1749 (New): EMD DDA40X (Voyager1) @ http://dev.openttdcoop.org/issues/1749 16:38:28 <Brot6> 2cc train set - Feature #1749: EMD DDA40X (Voyager1) @ http://dev.openttdcoop.org/issues/1749#change-4498 16:51:51 *** frosch123 has joined #openttdcoop.devzone 16:52:53 *** thgergo has joined #openttdcoop.devzone 17:10:53 <Brot6> Grapes - Revision 1:660bb16ebff6: Change: invoke plugins correctly (dih) @ http://dev.openttdcoop.org/projects/grapes/repository/revisions/660bb16ebff6 17:10:53 <Brot6> Grapes - Revision 2:c821a1ff5134: Doc: javadoc for PluginManager (dih) @ http://dev.openttdcoop.org/projects/grapes/repository/revisions/c821a1ff5134 17:11:04 <dih> ODM, are you familiar with log4j? 17:11:42 <ODM> uh no 17:12:21 <dih> hehe 17:13:11 <dih> shame ^^ 17:14:56 <dih> how about jUnit? 17:15:05 <dih> or some other unit testing? 17:45:19 <ODM> i have used junit once, but hat was a while ago 17:49:58 <Hirundo> planetmaker: Are the NML projects you fixed all affected projects on the devzone? 17:57:04 <Hirundo> Yexo: What is the next priority? spritelayouts? 17:57:39 <Brot6> Grapes - Revision 3:4452a123d7d2: Change: GrapePluginImpl implements GrapePlugin (dih) @ http://dev.openttdcoop.org/projects/grapes/repository/revisions/4452a123d7d2 18:01:33 *** ODM has quit IRC 18:27:39 *** Lakie has quit IRC 18:37:00 <Brot6> NewGRF Meta Language - Revision 987:37ad4ef92c95: Codechange: Move SpriteSet and [Layout]SpriteGr... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/37ad4ef92c95 18:45:27 <Brot6> NewGRF Meta Language - Revision 988:58f85de4753c: Add: spritelayout to the parser and AST. (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/58f85de4753c 18:46:21 <Brot6> NewGRF Meta Language - Revision 989:1bcccfd7b44e: Fix: Remove a small, obsolete bit of code. (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/1bcccfd7b44e 18:49:38 <Brot6> NewGRF Meta Language - Revision 990:e6e1bed4ef48: Doc: Document the non-existence of the pre_proc... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/e6e1bed4ef48 19:01:48 <Brot6> NewGRF Meta Language - Revision 991:a3572eca63f3: Doc: Document actions/action1.py (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/a3572eca63f3 19:09:27 <Brot6> 32bpp-ez-patches: update from r21076 to r21077 done - http://bundles.openttdcoop.org/32bpp-ez-patches/testing/r21077 19:18:34 <Brot6> clientpatches: update from r21076 to r21077 done - http://bundles.openttdcoop.org/clientpatches/testing/r21077 19:19:38 <Brot6> serverpatches: compile of r21077 still failed (#1658) - http://bundles.openttdcoop.org/serverpatches/testing/ERROR/r21077 20:14:36 <Brot6> GRFCodec - Feature #1751 (New): How to use escape for a part of a field? (George) @ http://dev.openttdcoop.org/issues/1751 20:26:58 <Brot6> NFORenum - Feature #1751 (New): How to use escape for a part of a field? (George) @ http://dev.openttdcoop.org/issues/1751 20:27:37 <Ammler> moved :-) 20:27:48 <planetmaker> :-) 20:36:38 *** frosch123 has quit IRC 20:44:24 <Brot6> Grapes - Revision 4:cc2a38d1fad7: Change: PluginManager can provide access to Grapes for Plugins (dih) @ http://dev.openttdcoop.org/projects/grapes/repository/revisions/cc2a38d1fad7 20:44:24 <Brot6> Grapes - Revision 5:59c8af4a7052: Fix: @Inherit does not work like that ^^ (dih) @ http://dev.openttdcoop.org/projects/grapes/repository/revisions/59c8af4a7052 20:44:24 <Brot6> Grapes - Revision 6:7685565e574b: Fix: forgot to remove the old Plugin interface (dih) @ http://dev.openttdcoop.org/projects/grapes/repository/revisions/7685565e574b 20:44:24 <Brot6> Grapes - Revision 7:3039748f8a13: Fix: parts of loading, invoking and getting a Plugin in PluginM... (dih) @ http://dev.openttdcoop.org/projects/grapes/repository/revisions/3039748f8a13 20:44:28 <Brot6> Grapes - Revision 8:a270230160e0: Add: give Grapes some more ... (dih) @ http://dev.openttdcoop.org/projects/grapes/repository/revisions/a270230160e0 20:44:31 <Brot6> Grapes - Revision 9:d9f37baa146e: Change: Run but not without the Grapes (dih) @ http://dev.openttdcoop.org/projects/grapes/repository/revisions/d9f37baa146e 20:44:34 <Brot6> Grapes - Revision 10:8aad1c2b503b: Change: we need a jar which includes the dependencies (dih) @ http://dev.openttdcoop.org/projects/grapes/repository/revisions/8aad1c2b503b 20:48:05 <Brot6> Java OpenTTD Admin Library - Revision 31:b75cf70c2335: Change: print the exception that caused th... (dih) @ http://dev.openttdcoop.org/projects/joan/repository/revisions/b75cf70c2335 20:48:06 <planetmaker> [18:49] <Hirundo> planetmaker: Are the NML projects you fixed all affected projects on the devzone? <-- I believe so. 20:48:41 <planetmaker> Hirundo: if therre's another one, I'll happily fix that, too. Technically there's the discontinued OpenGFX+ newgrf - but that was split, so it's not worth to fix that 20:49:04 <planetmaker> -r 20:49:53 <planetmaker> I didn't test the townname newgrfs. But... I don't think they have sprite blocks 20:51:06 <Hirundo> I rather hope not :) 20:51:24 <Hirundo> Yexo: around? 20:52:43 <Yexo> yes, just now 21:21:48 <Hirundo> Do you agree with the spritelayout concept as described in #1395 / #1695? 21:21:48 <Brot6> Hirundo: #1395 is http://dev.openttdcoop.org/issues/show/1395 "NewGRF Meta Language - Feature #1395: sprite layouts - #openttdcoop Development Zone" 21:21:48 <Brot6> Hirundo: #1695 is http://dev.openttdcoop.org/issues/show/1695 "NewGRF Meta Language - Feature Request #1695: sprite block restructuring - #openttdcoop Development Zone" 21:23:25 <Hirundo> There's something I don't like about the syntax, but I can't really put my finger on it 21:30:08 *** andythenorth_ has joined #openttdcoop.devzone 21:30:16 <andythenorth_> evenink 21:32:30 <Yexo> I don't like the "spritelayout_name, spriteset_name" syntax in the graphics block, but generally it looks ok 21:32:38 <Yexo> maybe "layout(sprites)" is better? 21:33:52 <andythenorth_> it is somewhat fun that a certain newgrf author...on the one hand is unhappy about changes in FIRS which cause incompatibility....and on the other has been sending recent pms asking for changes to FIRS cargos :P 21:35:00 <planetmaker> haha :-) 21:35:38 <Terkhen> maybe he is only unhappy about changes he don't like 21:35:41 <andythenorth_> to be fair, they are changes that wouldn't need a grfid bump 21:35:48 <andythenorth_> but anyway 21:36:07 <andythenorth_> 'FIRS is unstable' and 'FIRS is ill conceived and needs to change' seems inconsistent 21:36:14 <andythenorth_> what else happened? 21:36:45 <Terkhen> I added three additional patches to my speed patch queue 21:36:52 <planetmaker> Hirundo: Yexo : The solution layout(sprites) seems more logical to me 21:37:41 <Hirundo> agreed 21:37:51 <planetmaker> at least it is nicer in a way that it is clear in what way they're related 21:38:28 <planetmaker> and it's then easy to do something like 21:38:40 <planetmaker> std_layout(old_buildings) 21:38:46 <planetmaker> std_layout(new-buildings) 21:38:56 <planetmaker> which just updates the looks in the year 1967 :-) 21:41:01 <planetmaker> Yexo: Hirundo something which could maybe need a bit more elaborate solution are the sprite numbers in layouts 21:41:02 <Hirundo> Only thing I'm pondering is whether we should use a new keyword instead of spriteset 21:41:12 <planetmaker> and maybe that 21:42:23 <planetmaker> it'd be nice, if I could name the sprites in the spriteset, so that I don't have to follow an order. And could use that name to refer to in the layout 21:42:31 <Yexo> planetmaker: not sure about that, that would reintroduce the current syntax where you need a new spriteset for every sprite used for non-vehicles 21:42:32 <planetmaker> that seems to be the way it works everywhere else 21:42:56 <Yexo> just make multiple spritesets if you need multiple names 21:43:23 <Yexo> hmm, that means a layout should be able to accept more than one spriteset 21:43:38 <planetmaker> but how would I refer to them in the layout then? 21:43:55 <Yexo> example problem: 3 real sprites, one ground sprite, one "normal" building sprite and one building sprite with snow 21:44:20 <Yexo> the spritelayout combines the ground sprite with a building sprite 21:44:51 <Yexo> to use "group_sprite_layout(normal/snow)" syntax both the "normal" and the "snow" spritesets need to contain the ground sprite 21:45:38 <planetmaker> yes... 21:46:07 <Yexo> on the other hand currently you need to copy the spritelayout (=current spritegroup) code completely 21:46:11 <Yexo> which is also not nice 21:47:10 * planetmaker first reads existin nml code on airports 21:47:34 <planetmaker> how does a child sprite work? 21:49:08 <Yexo> same as buildingsprite/groundsprite 21:49:19 <Yexo> except it doesn't have a building box 21:49:47 <planetmaker> so basically a 'draw at offset' 21:50:18 <planetmaker> and ideally it's inside the building box 21:50:24 <Yexo> it uses the same building box as the "parent" sprite (=last buildingsprite before it), or if it's before the first buildingsprite it is an extra groundsprite 21:50:55 <planetmaker> ^ interesting information :-) 21:51:16 *** Lakie has joined #openttdcoop.devzone 21:51:24 <planetmaker> so... ground...childsprite...airportfence adds basically only an overlay over the ground? 21:51:36 <planetmaker> and then a fence on one side? 21:51:57 <Yexo> I'll have to look at the airport code too for that 21:52:13 <planetmaker> hm... it's called small_building... 21:55:01 <planetmaker> what about allowing: "sprite: spriteset_name(2)" in order to refer to the 2nd sprite in that set? If no argument given the first is used by default? 21:56:21 <Yexo> good idea 21:56:52 <Lakie> I had wondered about that myself... 21:57:18 <Lakie> Since otherwise I tended to end up with many spritesets, one for each sprite... 21:57:55 <Yexo> spritesets are nice for vehicles (and maybe railtypes) but not so good for the other features where you have only one sprite per spriteset 21:58:27 <Yexo> Hirundo: so it seems we need a more elaborate solution than you described in those two issues 22:00:35 <Yexo> what about a solution with parameters: a spritelayout can define as many parameter as it wants, each parameter has to refer to a spriteset. When you use the spritelayout you have to give as many spritesets as the spritelayou expects 22:00:45 <Hirundo> Industries / Houses may have more than one sprite per set 22:01:23 <Yexo> the spritelayout could than use "arg_name" or "arg_name(num)" to refer to the first sprite or not the first sprite from one of the spritesets 22:01:37 <Yexo> Hirundo: they can? 22:01:44 <Hirundo> Construction stages 22:03:22 <Yexo> ah, never read that part of the nfo documentation before 22:03:38 <Lakie> Ah yes, Objects just assume construction stage 3... 22:03:39 <planetmaker> hm, yes, they can. 1 - 4 22:03:50 <Lakie> 0 - 3 in code... 22:04:27 <Lakie> So it picks those from the spritesets? 22:04:46 <Hirundo> yes 22:04:54 <planetmaker> the amount of sprites given define the amount of constr. stages being used 22:05:11 <Yexo> ^^ that doesn't need to be true for nml 22:05:18 <planetmaker> yep 22:05:46 <Hirundo> We could also invert the relationship 22:06:03 <Hirundo> i.e. supply 1...4 sprite sets as parameter for the different construction stages 22:06:22 <planetmaker> I'd like that more actually 22:07:15 <planetmaker> usual way to work (graphics-wise): draw it in finished stage. Code, how it looks like. done 22:07:29 <planetmaker> And then it's easy to add a construction stage by just adding it as a new spriteset 22:07:50 <planetmaker> like layout(spriteset) 22:08:02 <planetmaker> or layout(construction_spriteset, finished_spriteset) 22:08:05 <planetmaker> and so on 22:08:29 <planetmaker> hm.... 22:08:58 <planetmaker> but then you are really bound to all those sprites being in one spriteset - again 22:09:30 <Hirundo> you can define some stuff in a template 22:10:05 <Yexo> hmm, if you use 2 building sprites in a house action2 and you want to support construction stages, you need exactly 2 building sprite for every construction stage, right? 22:10:30 <planetmaker> I guess... 22:11:20 <Hirundo> In the case of industries, I doubt that the same sprite layout is applicable to all construction stages 22:11:29 <Lakie> Can you not use a var to change the layout based on construction stage? 22:11:42 <Hirundo> ^ you'd indeed need to read a var 22:12:16 <Yexo> but if you read a var, you're not using the construction stage feature from the normal action2 22:12:37 <Yexo> I'm not saying that is a problem though, maybe we don't want to support that in nml anyway 22:13:28 <Yexo> if we're not supporting that, we can safely assume that all spritesets have exactly one real sprite (except vehicles and railtypes) 22:15:19 <Yexo> planetmaker: I'm now looking at the airportsplus code, the fence is a building sprite 22:15:37 <planetmaker> yes, that's to be assumed 22:15:51 <Yexo> the childsprite before that is an extra ground sprite, the default ground sprite is one of the ttd ground sprites, the childsprite is an overlay 22:16:17 * Hirundo writes a new spec proposal 22:16:32 <Lakie> Sounds logical. 22:16:35 <Yexo> childsprite { sprite: spr_small_building_3_snow; <- I assume that was confusing? it's indeed a ground sprite, not a building sprite 22:18:19 <planetmaker> he 22:21:35 <planetmaker> what about actually keeping the first idea: sprite: spriteset(n) 22:21:53 <planetmaker> and for construction stages: sprite: spriteset(n), otherspriteset(m) 22:22:29 <planetmaker> all sprites have to define the same amount of sprites or it's an error. 22:22:38 <planetmaker> within one layout 22:23:21 <Yexo> so an nml spriteset is nothing more than a collection of real sprites and has no collection anymore with an nfo spriteset 22:23:40 <planetmaker> hm... I guess so 22:23:54 <Hirundo> not in the case of buildings, yes 22:24:07 <Hirundo> see #1395 22:24:07 <Brot6> Hirundo: #1395 is http://dev.openttdcoop.org/issues/show/1395 "NewGRF Meta Language - Feature #1395: sprite layouts - #openttdcoop Development Zone" 22:24:11 <planetmaker> what does it in an industry context in NFO? there it holds the construction stages, right? 22:24:30 <Brot6> NewGRF Meta Language - Feature #1395: sprite layouts (Hirundo) @ http://dev.openttdcoop.org/issues/1395#change-4506 22:24:34 <Yexo> yes 22:25:17 <Yexo> in nfo for buildings each spriteset contains as many real sprites as there are construction stages 22:25:24 <Yexo> which is also the current nml implementation 22:25:54 <planetmaker> named sprites in the spriteset, Hirundo, as you propose, looks good :-) 22:26:25 <Hirundo> Lakie: Do you know why the the system of stations is not used for houses/industrytiles action1/action2? 22:28:32 <Lakie> Because stations was devised by Josed and Houses and industries by Csaboka? 22:28:36 <Lakie> Josef* 22:29:18 <Rubidium> free map bits? 22:29:34 <Lakie> Could be, 22:29:48 <Rubidium> 8 different (rail) station "tile" types vs 256 house/industry tile types 22:30:24 <planetmaker> to be unified in v8 :-P 22:30:35 <Rubidium> also, all tiles of a house/industry belong to the same "build", whereas parts of stations are built as individual areas 22:32:03 <Yexo> <planetmaker> to be unified in v8 :-P <- don't count on it 22:32:12 <Yexo> instead: something to abstract away with nml 22:32:21 <planetmaker> :-) 22:32:28 <planetmaker> both :-P 22:32:42 <planetmaker> but... if it's gone with NML, it's good enough for me 22:33:29 <Yexo> there are so many existing grfs that openttd/ttdpach will need to remain compatible with grf version 7, so while it might unify the documentation for nfo a bit the amount of code for openttd wouuld increase 22:33:42 *** Brot6 has quit IRC 22:34:07 <planetmaker> yes, sure 22:34:07 *** Brot6 has joined #openttdcoop.devzone 22:34:43 <planetmaker> but having a 'better' or leaner documented nfo would IMHO also be worth something 22:35:17 <Lakie> Feel free to fix the ttdpatch code for it whilst your unifying... ;) 22:35:19 <planetmaker> but then... once there's NML, there's no need to go back to pure NFO :-) 22:35:37 * Rubidium assigns planetmaker to that task while preserving backward compatability 22:35:55 *** planetmaker is now known as moonraker 22:36:02 <moonraker> to whom? :-P 22:36:15 <Yexo> to *aker 22:36:28 <Rubidium> http://rbijker.net/openttd/string_spec.txt <- that's already more than enough fun and obfuscation :) 22:38:29 *** moonraker is now known as planetmaker 22:44:12 <Brot6> Grapes - Revision 11:ce8cf5e2bf4c: Change: where did that come frome? (dih) @ http://dev.openttdcoop.org/projects/grapes/repository/revisions/ce8cf5e2bf4c 22:44:12 <Brot6> Grapes - Revision 12:e7fa8404bd31: Fix: PluginManager should initialize the Plugins (dih) @ http://dev.openttdcoop.org/projects/grapes/repository/revisions/e7fa8404bd31 22:44:12 <Brot6> Grapes - Revision 13:e205ecf66a1a: Change: visibility of members of GrapePluginImpl (dih) @ http://dev.openttdcoop.org/projects/grapes/repository/revisions/e205ecf66a1a 22:44:16 <planetmaker> back to layouts and spritesets: Hirundo's last suggestion is what looks quite easy to memorize and to grasp conceptually 22:46:31 <Hirundo> Do we agree on that? Then I can go to sleep :) 22:46:47 <andythenorth_> good night 22:46:57 *** andythenorth_ has quit IRC 22:46:59 <Yexo> what exactly is Hirundo's latest suggestion? 22:47:12 <Hirundo> Comment in #1395 22:47:13 <Brot6> Hirundo: #1395 is http://dev.openttdcoop.org/issues/show/1395 "NewGRF Meta Language - Feature #1395: sprite layouts - #openttdcoop Development Zone" 22:47:47 <dih> <Hirundo> Do we agree on that? Then I can go to sleep :) <- now he is starting that 'agreeing' thing too? :-P 22:47:57 <Yexo> what about my example where I have 1 groundsprite, 1 normal building sprite and 1 snow building sprite? It seems like with your suggestin I have to duplicate the groundsprite to both spritesets 22:48:28 <Hirundo> What type of item is that? 22:48:42 <Yexo> for example airport tiles 22:48:52 <Yexo> can also be industry tile or house 22:50:03 <Lakie> And thus objects? 22:50:10 <Yexo> yes 22:51:11 <Hirundo> Do they have var10 set to 0/1/2 like is done for stations, to resolve ground sprites separately? 22:51:42 <Yexo> no 22:52:09 <Hirundo> Then, I think your best option is to define the ground sprite as a template and include that 22:52:45 <Yexo> so indeed include it in both spritesets 22:52:56 <Hirundo> internally, that's always needed 22:53:37 <Yexo> not really 22:54:03 <Yexo> in nfo every spriteset is a single sprite, so the nfo code for my example only needs 3 real sprites 22:54:33 <Lakie> Yeah, you defined on action1 and then have it used by multiple action2s? 22:54:39 <Yexo> while with the groundsprite included in both nml spritesets it looks like 4 real sprites, where the nml compiler may (or may not) be smart enough to optimize 1 away 22:54:57 <Hirundo> Indeed 22:55:25 <Hirundo> Alternatively, we could allow including sprites directly into a sprite layout (like currently for sprite groups) 22:55:31 <Brot6> Grapes - Feature Request #1752 (New): Generic Configuration Support (dih) @ http://dev.openttdcoop.org/issues/1752 22:56:19 <Yexo> what if we make spritelayouts just like templates? ie accept one or more arguments (=spritesets) and also reference any arbitrary spriteset 22:56:30 <Hirundo> hmm... is it possible to load sprites via GRM, then include them as a TTD sprite? 22:56:47 * planetmaker never figured out GRM 22:57:02 <Hirundo> Yexo: how does that interact with construction stages? 22:57:05 <Yexo> if a certain spritelayout is always used with the same spriteset it could be defiend without any parameters and used like "spritelayout-name()", if it needs multiple spritesets it can use them 22:57:36 <Yexo> Hirundo: same as it does now, in the graphics block of an item-block you specify multiple spritelayouts (with possible different arguments), one for each construction stage 22:59:30 <Hirundo> You can't do anything with construction stages in action3/graphics block, currently 22:59:58 <Yexo> argh, I'm confusing things again :( 23:00:03 <Hirundo> you either handle that in action1 or varact2 23:00:13 <Brot6> NewGRF Meta Language - Revision 982:150fec6d685b: Codechange: Strip the spriteblock down to nothi... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/150fec6d685b 23:00:40 <Yexo> ok: so the construction stages are always handled via varaction2 23:01:32 <Hirundo> And each sprite set contains exactly one sprite? 23:02:05 <Yexo> no, as many as it wants. spritelayouts use them as "name(num)" (or just name if it contains a single sprite) 23:04:41 <Yexo> actually spritelayouts with parameters are easily combined with your suggested syntax for construction stages 23:06:34 <Hirundo> Arguments can be anything (constant expression or spriteset)? 23:06:34 <planetmaker> hm... 23:06:56 <Yexo> I was thinking about spriteset only 23:07:09 <Yexo> but constant expressions shouldn't be too much work 23:07:13 <Yexo> is there any use for those? 23:07:33 <Yexo> answering myself: there is, for switch between ttd sprites 23:07:46 <Hirundo> flexible bounding box height 23:13:15 <Yexo> http://pastebin.com/HafKEfdR modified example from #1395 23:13:15 <Brot6> Yexo: http: #1395 is http://dev.openttdcoop.org/issues/show/1395 "NewGRF Meta Language - Feature #1395: sprite layouts - #openttdcoop Development Zone" 23:14:34 <Hirundo> Do you want to keep the two-tier sprite set? 23:16:38 <Yexo> what do you mean? 23:16:49 <planetmaker> I like Hirundo's naming of individual sprites, too. I guess that can be combined? 23:17:16 <Yexo> planetmaker: where can I find that? 23:17:56 <Hirundo> Yexo: lines 5-8 in pastebin 23:18:20 <Yexo> I don't have anything against it, so why not? 23:18:48 <planetmaker> http://pastebin.com/7rHiWbuG 23:19:42 <Yexo> planetmaker: is the naming optional? 23:19:46 <planetmaker> yes 23:19:54 <Yexo> than it's fine :) 23:21:02 <planetmaker> question is whether the name could be an expression :-) 23:21:20 <planetmaker> or the sprite-refernece. Which would boil down to the same. When used in the layout 23:21:25 <planetmaker> I hope? 23:21:57 <Yexo> http://pastebin.com/9zPExJ1Z <- extended planetmaker example with a reference to a spriteset that is not a parameter 23:23:58 <planetmaker> http://pastebin.com/t0fYE31B <-- also like that? 23:24:09 <planetmaker> Note the different sprite number fallentree is in different sets 23:24:17 <Yexo> yes, that doesn't matter 23:24:23 <planetmaker> cool :-) 23:24:43 <Yexo> those spritesets have to be resorted/reordered to nfo spritesets anyway 23:25:01 <planetmaker> I guess we have a syntax then 23:25:07 <Yexo> the only requirement is that it always has the same number of construction stages 23:25:11 <Hirundo> planetmaker: your latest example has a duplicated definition of set2 23:25:22 <Hirundo> resulting in (yay) undefined behaviour 23:25:56 <Yexo> some open questions: is "sprite: set;" a valid way to refer to the first real sprite of the spriteset "set"? 23:26:20 <Hirundo> from a coding perspective, I'd prefer not 23:26:28 <Yexo> what is the syntax for a spritelayout without parameters? is it "spritelayout name () {" or "spritelayout name {" or are both valid? 23:26:45 <Hirundo> both could be valid 23:27:07 <planetmaker> Hirundo: spritelayout bar (set, set2) { // One argument <-- what are those set and set2 in that line exactly? 23:27:14 <Yexo> allowing "sprite: set;" and the spritelayout without () after it makes it almost compatible with the current syntax (except for spritegroup->spritelayout) 23:27:27 <Hirundo> planetmaker: Two arguments :) 23:27:36 <planetmaker> or what / where do you mean that set2 is defined twice? 23:27:41 <Hirundo> locally and globally 23:27:52 <Yexo> it's both an argument to the spritelayout and the name of a spriteset 23:28:08 <Yexo> notice that "otherset" is not a parameter to the spritelayout 23:28:38 <planetmaker> hm, so set and set2 in the spritelayout are just expressions? Or what are the meanings of those parameters? 23:28:49 <planetmaker> yes, otherset is a fixed spriteset, I think? 23:28:59 <Yexo> you can use bar like this; "bar(some_random_set, other_random_set)" and it'll take the realsprites from those (set will be some_random_set and set2 will be other_random_set), while otherset will always refer to the same spriteset no matter what arguments you give 23:29:30 <planetmaker> ah, right 23:29:40 <Yexo> planetmaker: not any expression, either an constant numeric (or something that can be optimized to a constant) or the name of a real spriteset 23:29:50 <Yexo> bar(param[2]) would be invalid, but bar(3) not 23:30:03 <Yexo> assuming a spritelayout that expects a number instead of a spriteset name of course 23:31:04 <planetmaker> so... bar(set, set2, offsets) ... sprite: set(offset) could work? 23:31:24 <Yexo> I don't see why not 23:31:30 <planetmaker> :-) nice 23:31:32 <Hirundo> yes, assuming you fix your singular/plural typo 23:31:36 <planetmaker> :-P 23:31:53 <Yexo> but I guess the prefered syntax in that case would be to name the sprites and use "sprite: set(name);" 23:31:57 <planetmaker> the ghosts haunting me in the ghost hour stole that, Hirundo ;-) 23:32:10 <Hirundo> I still have my doubts about the "two-tier" sprites, btw 23:32:20 <planetmaker> what are two-tier sprites? 23:32:42 <Hirundo> example: http://pastebin.com/9zPExJ1Z lines 5-8 23:33:21 <Yexo> Hirundo: I haven't seen better syntax for it yet 23:33:29 <Hirundo> All sprites in a single layout must have the same number of construction stages 23:33:34 <Yexo> but I'm fine with "don't support at all, force the varaction2 way" 23:33:35 <planetmaker> the construction stages definitions you mean, Hirundo ? 23:33:40 <Hirundo> yes 23:33:56 <Hirundo> we could end up quadruplicating an awful number of sprites 23:34:08 <Yexo> no way to avoid that I think 23:34:26 <Hirundo> I'm fine with forcing the varact2 way 23:34:28 <Yexo> if you want to support that syntax and not use varaction2 for it at least 23:34:49 <Yexo> of course we always have the option of abstracting that away a bit (like the plans for the callbacks) 23:34:55 <Hirundo> indeed 23:35:47 <planetmaker> maybe skip this two-tier syntax for now. 23:35:56 <Hirundo> I think the current proposals make it easy enough to do it with varaction2, and then tell the spritelayout about the spritesets or offsets to use 23:36:06 <Yexo> ok, seems we have an agreement than :) 23:36:07 <planetmaker> If there's desire to introduce that, it's easy to add later. At least it'd be backward-compatible 23:36:28 <planetmaker> otherwise varaction2 is fine 23:36:49 <Yexo> are we going with "spriteset" as name? 23:36:58 <Hirundo> I think it's most useful for hosues, and they don't work yet anyways 23:37:08 <planetmaker> why not spriteset? 23:37:32 <Yexo> because it supports naming the sprites, which is not useful at all for vehicles 23:37:36 <planetmaker> they're different from vehicles, but then... those aren't vehicles 23:38:31 <Yexo> and naming a vehicle real sprite doesn't matter either, because it's never used 23:38:32 <Hirundo> Using a different 'keyword' may have some advantages to both the user (clarity) and code 23:39:27 <Hirundo> although it's not really needed in any way 23:41:07 * Hirundo votes for keeping "spriteset" 23:41:53 * Yexo agrees 23:43:38 * planetmaker agrees, too 23:51:32 <Hirundo> Since we all agree, there is no [point to any] further discussion. Goodnight folks :) 23:51:45 <Yexo> goodnight Hirundo 23:54:19 <planetmaker> good night Hirundo 23:54:40 <planetmaker> and as it's a good time for bed, also good night Yexo - and any other person who might still be awake 23:54:49 <Yexo> night planetmaker 23:54:54 <Yexo> and me is off too for tonight