Log for #openttdcoop.devzone on 3rd November 2010:
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>
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>
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>
10:52:37  <dih>
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) @
12:07:23  <Brot6> NewGRF Meta Language - Revision 981:fd17de8b1b36: Cleanup: Remove unneeded parts of register / re... (Hirundo) @
12:07:23  <Brot6> NewGRF Meta Language - Revision 979:7fe1e7f8468a: Add: A new abstract base class for sprite group... (Hirundo) @
12:07:25  <Brot6> NewGRF Meta Language - Revision 982:150fec6d685b: Codechange: Strip the spriteblock down to nothi... (Hirundo) @
12:07:29  <Brot6> NewGRF Meta Language - Revision 983:ed557d48df56: Feature #1695: Allow placing sprite sets and gr... (Hirundo) @
12:07:33  <Brot6> NewGRF Meta Language - Revision 985:8c6dc4fd4c29: Change #1695: Deprecate spritblock and emit a w... (Hirundo) @
12:07:37  <Brot6> NewGRF Meta Language - Revision 986:3b8137c4c3ac: Doc: Remove references to sprite blocks from th... (Hirundo) @
12:07:41  <Brot6> NewGRF Meta Language - Revision 984:e6fc0a21e3e0: Change: Remove spriteblock from the regression ... (Hirundo) @
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: :-)
13:01:22  <Webster> Title: Dashboard [Hudson] (at
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) @
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 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) @
15:16:52  <Brot6> Swedish Rails - Revision 188:118dc636cecc: Change: Remove deprecated use of sprite blocks (planetmaker) @
15:20:21  <Brot6> OpenGFX+ Airports - Revision 66:a4b1abaf6071: Change: Remove deprecated use of sprite blocks and ... (planetmaker) @
15:26:01  <Brot6> OpenGFX+ Road Vehicles - Revision 24:6824664c46d2: Change: Remove deprecated use of sprite blocks (planetmaker) @
15:58:10  *** Lakie has joined #openttdcoop.devzone
16:38:28  <Brot6> 2cc train set - Feature #1749 (New): EMD DDA40X (Voyager1) @
16:38:28  <Brot6> 2cc train set - Feature #1749: EMD DDA40X (Voyager1) @
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) @
17:10:53  <Brot6> Grapes - Revision 2:c821a1ff5134: Doc: javadoc for PluginManager (dih) @
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) @
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) @
18:45:27  <Brot6> NewGRF Meta Language - Revision 988:58f85de4753c: Add: spritelayout to the parser and AST. (Hirundo) @
18:46:21  <Brot6> NewGRF Meta Language - Revision 989:1bcccfd7b44e: Fix: Remove a small, obsolete bit of code. (Hirundo) @
18:49:38  <Brot6> NewGRF Meta Language - Revision 990:e6e1bed4ef48: Doc: Document the non-existence of the pre_proc... (Hirundo) @
19:01:48  <Brot6> NewGRF Meta Language - Revision 991:a3572eca63f3: Doc: Document actions/ (Hirundo) @
19:09:27  <Brot6> 32bpp-ez-patches: update from r21076 to r21077 done -
19:18:34  <Brot6> clientpatches: update from r21076 to r21077 done -
19:19:38  <Brot6> serverpatches: compile of r21077 still failed (#1658) -
20:14:36  <Brot6> GRFCodec - Feature #1751 (New): How to use escape for a part of a field? (George) @
20:26:58  <Brot6> NFORenum - Feature #1751 (New): How to use escape for a part of a field? (George) @
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) @
20:44:24  <Brot6> Grapes - Revision 5:59c8af4a7052: Fix: @Inherit does not work like that ^^ (dih) @
20:44:24  <Brot6> Grapes - Revision 6:7685565e574b: Fix: forgot to remove the old Plugin interface (dih) @
20:44:24  <Brot6> Grapes - Revision 7:3039748f8a13: Fix: parts of loading, invoking and getting a Plugin in PluginM... (dih) @
20:44:28  <Brot6> Grapes - Revision 8:a270230160e0: Add: give Grapes some more ... (dih) @
20:44:31  <Brot6> Grapes - Revision 9:d9f37baa146e: Change: Run but not without the Grapes (dih) @
20:44:34  <Brot6> Grapes - Revision 10:8aad1c2b503b: Change: we need a jar which includes the dependencies (dih) @
20:48:05  <Brot6> Java OpenTTD Admin Library - Revision 31:b75cf70c2335: Change: print the exception that caused th... (dih) @
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 "NewGRF Meta Language - Feature #1395: sprite layouts - #openttdcoop Development Zone"
21:21:48  <Brot6> Hirundo: #1695 is "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 "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) @
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> <- 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) @
22:44:12  <Brot6> Grapes - Revision 12:e7fa8404bd31: Fix: PluginManager should initialize the Plugins (dih) @
22:44:12  <Brot6> Grapes - Revision 13:e205ecf66a1a: Change: visibility of members of GrapePluginImpl (dih) @
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 "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) @
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) @
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> modified example from #1395
23:13:15  <Brot6> Yexo: http: #1395 is "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>
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> <- extended planetmaker example with a reference to a spriteset that is not a parameter
23:23:58  <planetmaker> <-- 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: 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

Powered by YARRSTE version: svn-trunk