Log for #openttdcoop.devzone on 18th July 2012:
Times are UTC Toggle Colours
00:00:14  <Brot6> NewGRF Meta Language - Revision 1917:44abd75cf3fb: Fix #4063: Don't use a string instead of a positi... (Hirundo) @
01:39:00  *** Rubidium has quit IRC
01:40:34  *** Rubidium has joined #openttdcoop.devzone
06:31:19  <Brot6> OpenGFX+ Trains - Revision 718:13364904fee3: Feature #3491: Removed track_type redefinition inconsis... (Xotic750) @
06:46:37  <Ammler> rhodecode would not replace redmine
06:46:46  <Ammler> it doesn't have a tracker
06:52:17  <Ammler> dihedral: just now, there are around 2-3 projects, who someone would like to fork
06:52:36  <Ammler> also every openttd patch hosted on devzone would be a fork
06:53:19  <Ammler> every experimental feature would be a fork
06:55:06  <Ammler> every contribution to a project you don't have commit permission would be a fork and pull request
06:55:42  <Ammler> no ugly patch thing anymore :-)
06:57:19  <Ammler> do the tools you listed yesterday support forking?
06:57:34  <Brot6> OpenGFX+ Trains - Revision 719:a43e5e48551f: Fix #4070: Purchase list shows graphics in their loadin... (Xotic750) @
06:57:35  <Brot6> OpenGFX+ Trains - Bug #4070 (Closed): Purchase list shows graphics in their loading state (Xotic750) @
07:07:34  <Brot6> OpenGFX+ Trains - Revision 720:456eba145a1b: Feature #4068: Early bulk wagons now have an 80km/h spe... (Xotic750) @
07:22:51  *** Alberth has joined #openttdcoop.devzone
07:54:55  <dihedral> Ammler, I see - thank you for helping me understand what you plan and how you see it work together :-)
07:55:17  <dihedral> in that case the tools i mentioned yesterday are totally unfit :-P
07:55:28  <Brot6> OpenGFX+ Trains - Bug #2284: Make use of special sprites for the purchase list (Xotic750) @
07:55:37  * dihedral kicks Brot6 
07:55:44  <dihedral> aw, no response :-P
07:55:55  <dihedral> Brot6, i could kick you :-P
07:56:00  <dihedral> aw :-(
08:29:38  <Alberth> hopefully it doesn't kick you :p
08:59:09  <dihedral> :-P
10:38:36  <planetmaker> meh, I don't like an nfo baseset, Alberth
10:38:47  <planetmaker> it sounds tempting for the simple sprites
10:39:06  <planetmaker> but one will regret and have to re-write much stuff when other stuff is needed
10:39:25  <Alberth> I won't write that manually
10:39:32  <planetmaker> don't throw away the benefits of NML
10:39:40  <planetmaker> you WILL write manually rivers. etc.
10:39:58  <planetmaker> the extra grf is a normal newgrf
10:40:01  <Alberth> good point
10:40:29  <planetmaker> nor do you need then to re-invent letters, window decorations etc.
10:40:34  <planetmaker> they exist as NML code already
10:40:47  <planetmaker> and they make no sense as 32bpp
10:41:23  <planetmaker> and, tbh, creating this as NFO reduces the chance that _I_ will port it to OpenGFX as a joint set to about < 1%
10:41:49  <planetmaker> but would make it also generally more difficult to merge them
10:42:19  <Alberth> merging is going to be a mess anyway
10:42:36  <Alberth> the data is not simple accessible
10:42:40  <planetmaker> yes. But I've done the conversion nfo->nml for OpenGFX once. I'm not doing it twice
10:43:12  <Alberth> I was planning on generation whatever we decide to use
10:43:15  <planetmaker> nmlc allows to write nfo code. Which then can be used to have grfcodec encode all stuff
10:43:33  <planetmaker> that's reasonably fast (as only encoding sprites is slow)
10:43:37  <Alberth> so to me it amounts to producing "foor <numbers>" or "bar <numbers>"
10:43:39  <planetmaker> and keeps a legible source code
10:43:56  <planetmaker> as in nml source
10:44:38  <Alberth> why are there so few templates?
10:45:08  <planetmaker> The most-used ones are templated
10:45:10  <Alberth> btw, I am working on a cunning plan, that I want to show you later
10:45:28  <planetmaker> might not be used everywhere. Due to not-templated graphics
10:45:44  <Alberth> where you ditch most real sprite code, it seems
10:45:46  <planetmaker> and like tmwftlb when it's just code beautification and no graphics change
10:46:06  <planetmaker> s/code beautification/adding use of templates/
10:46:07  <Brot6> planetmaker meant: "and like tmwftlb when it's just adding use of templates and no graphics change"
10:46:20  <Alberth> go away Brot6
10:46:47  <Alberth> yeah, most graphics are coded once and never ever touched again
10:47:14  <planetmaker> yes. So no templates used in many places. As it was somewhat auto-converted from nfo to nml
10:47:35  <planetmaker> and I only made use of templates where I also added auto-generation to the sprites so that they were in a templatable format
10:48:23  <planetmaker> but you can't template industries and houses easily
10:48:36  <planetmaker> planes and ships hardly
10:48:43  <planetmaker> trains and vehicles... depends
10:48:44  <Alberth> planetmaker: I have no opinion about nml vs nfo here. For just real sprites, they seem largely equivalent. I expect it to be trivial to write either output form
10:49:17  <planetmaker> well. as said. Personally I'm not interested in dealing with an nfo project
10:49:41  <Alberth> I know, and I think that is a valid point not to do nfo
10:49:48  <planetmaker> I converted OpenGFX for a reason
10:50:13  *** KenjiE20 has quit IRC
10:50:17  <planetmaker> "just because" was not my only one ;-)
10:50:49  <Alberth> but I am feeling things are too experimental at this time, I am not doing things "for real" in a sense
10:50:52  <planetmaker> for the plain real sprites - without templates - it's equivalent. The details make the difference (and work) though
10:51:35  <Alberth> it is all just throw away experimental stuff
10:52:12  <Alberth> I think we need a simpler system to collect all the numbers needed for a sprite
10:52:22  <Alberth> +filenames
10:53:57  <Alberth> when you have that, it should be trivial to output whatever you like
10:55:35  <planetmaker> a simpler system than "sprite#, filename, x, y, width, height, offsetx, offsety"? How can that be?
10:56:00  <planetmaker> basically both NML and NFO source is already a kind of csv for that
10:56:06  <planetmaker> for the plain base sprites
10:56:14  <Alberth> your forgetting 3 more such sets of data for each sprite
10:56:16  <planetmaker> (with a bit of sugar)
10:56:45  <planetmaker> but the only difference there really is that the sprite# is duplicate
10:57:22  <Alberth> yep, and the 32bpp are much more regular in structure, except for the filename
10:58:00  <planetmaker> 32bpp is as regular as 8bpp in principle
10:58:02  <Alberth> and you want some simple macro-ish expansion to exploit structure
10:58:42  <Alberth> no, the sprites are all the same size, and the x/y centre is always (hopefully) at the same place
10:59:05  <planetmaker> err. sprite all the same size?
10:59:17  <planetmaker> the file maybe
10:59:44  <planetmaker> but sprite sizes must differ the same way as 8bpp
11:00:27  <Alberth> but that's what NML does, it is not in the input, so I don't have to deal with different ysizes etc
11:02:11  <planetmaker> different slopes of groundtiles still need different y-offset wrt their centre
11:03:15  <Alberth> that's what NML does too. the renderer has the northern point of the flat tile always at the same point in the image (I hope so, at least)
11:03:19  <planetmaker> (what's the centre? mean(y_i)? 1/n_y * sum (y_i * n_x) ?
11:03:45  <Alberth> -(y/2)
11:04:36  <Alberth>  eg -31, -32  for 64,   -63, -64 for 128, etc
11:05:00  <planetmaker> that's the x-shift. That's relatively easy for ground tiles
11:05:08  <planetmaker> but the y-shift?
11:07:00  <Alberth> I don't know exactly, but I currently assume that the northern tile point is at the same spot in all images.
11:07:59  <Alberth> so if some structure floats in the air, it should be renderer more to the top of the image
11:08:15  <Alberth> s/rer/red
11:09:49  <Alberth> during cropping, the minimal image size + its offsets are then computed
11:10:12  <Alberth> but I may be extremely na-ive in thinking that :p
11:10:57  <planetmaker> I think the assumption that the Northern most point is the same everywhere is wrong
11:11:05  <planetmaker> otherwise ground tiles would need no y-offset
11:11:13  <planetmaker> see the slopes
11:11:41  <Alberth> northern flat tile point
11:12:02  <planetmaker> so to get the y-offset you need the (additional) slope info...
11:13:17  <Alberth> no idea, the zbase.nml file I generated had all the yoffsets equal and the terrain looked fine, except for some small shifts
11:13:18  <planetmaker>
11:13:51  <planetmaker> then they're shifted in the image file. That's of course nice
11:14:32  *** KenjiE20 has joined #openttdcoop.devzone
11:14:33  <Alberth> yep, it saves a lot of parameters to decide :)
11:28:17  <planetmaker> very handy. Should always have been that way ;-)
11:29:49  <planetmaker> Would also be feasible with 8bpp tbh... Just a common rectangle to fit in the sprite... and then place it accordingly
11:30:19  <Alberth> planetmaker:  I make irreversible decisions always only after consulting everybody involved (or at least, that's what I try to do). I was not planning on doing it otherwise here
11:30:48  <planetmaker> I didn't want to imply that you do or did :-)
11:30:58  <planetmaker> I just happen to have a strong opinion about nfo :-P
11:31:36  <planetmaker> as written in tt-forums, as secondary to actually encode the sprites - that's currently the best solution
11:32:38  <Alberth> yep, have a simple template-ish system, generate nml, generate nfo, generate grf, everybody happy :D
11:33:01  <planetmaker> that's my preferred solution. Yes
11:33:42  <Alberth> it makes the most sense for the future imho
11:34:23  <Alberth> or you have to always live with some grfs in nfo, and others in nml, and no simple way to merge them
11:35:34  <Alberth> btw, I snooped around in the m4 code, and it does not look very convincing to me at first sight
11:36:01  <Alberth> maybe I looked at the wrong files though
11:36:17  <planetmaker> I did not look at it so far more than really a brief glimpse
11:37:10  <Alberth> it looks a lot more programcode-ish to me
11:42:54  <planetmaker> there's a lot of code which can be shared between vehicles. So... maybe it's a good idea. Maybe not
11:43:19  <planetmaker> it needs create many switches which look similar, but with different name and actual numbers for the decision
11:44:49  <Alberth> and the "template" in NML is just a special case mechanism for real sprites?
11:46:42  <planetmaker> in a way yes. It allows you to define templates (with as many parameters) for (set of) real sprites
11:47:15  <planetmaker> and to then actually use that template where needed with the parameters defined as needed by the actual real sprite (e.g. just giving other filenames when coding temperate ground vs. desert)
11:47:33  <planetmaker> thus one-time definition of offsets. Multiple use
11:47:51  <planetmaker> You can also use arithmetics in the template. Thus you can make a template which deals with zoom levels
11:48:02  <planetmaker> offset = -31 * zoom_level
11:48:07  <planetmaker> where zoom_level is a template parameter
11:48:31  <planetmaker> I use it e.g. for trains to use the same alignment for differently heigh trains
11:48:54  <planetmaker> I haven't dared yet make one template for all zoom levels. But should be feasible, if it's the same sprite scaled
11:51:48  <planetmaker> <-- probably over-engineered. Maybe not
11:52:52  <planetmaker> foobar found it too complicated, the attempt at an jack-of-all-trades template for trains :-P
11:53:11  <Alberth> it looks quite detailed yeah
11:53:30  <planetmaker> like first a generic one. Which then more specific templates build on
11:53:39  <planetmaker> thus you can use / reference templates in templates
11:53:43  <planetmaker> which makes it IMHO very useful
11:54:05  <Alberth> the hard problem with templates is when to stop leaning on one, and make a new one :)
11:54:17  <planetmaker> quite so
11:54:41  <planetmaker> and that's where this *might* have gone too far. Though... maybe not. The alignment is the really important thing to keep consistent. Hard to tell :-)
11:54:55  <planetmaker> alignment = xoffset, yoffset
11:55:12  <Alberth> it works now, don't touch it any more :)
11:55:23  <planetmaker> yes-ish :-P
11:55:32  <planetmaker> I know that it can be improved
11:55:54  <planetmaker> and the real issue here is that it actually serves different graphics templates. Just dealing with one would *greatly* uncomplicate it
11:56:31  <Alberth> these graphics just have too many parameters to tweak :p
11:56:52  <planetmaker> the issue there is the different placement of the sprites in the graphics files
11:57:00  <planetmaker> choosing only one, would make it much easier
11:57:18  <planetmaker> as foobar did with dutchtrains
11:57:22  <planetmaker> he's great in that :-)
11:57:36  <planetmaker> as he's generally a fellow I like quite a lot
11:57:48  <planetmaker> probably "great minds think alike" :-P
11:58:32  <planetmaker> like I compliment him on how he handled this whiny person on the forums today / yesterday
12:00:27  <Alberth> yep, he usually has the right answer :)
12:00:53  <Alberth> ok, my template-ish system:
12:02:00  <Alberth> is the trivial example. Basically, you need a lot of values for a sprite, and you just make an INI section for each sprite. sections can inherit data from other sections with the "parent = ..." entry
12:02:43  <Alberth> obviously this doesn't help much in defining all the sprites, but wait, step 2:
12:02:56  <Alberth>
12:03:59  <Alberth> the [terrain] section has several parents, which means you have a 'new' section, one for every parent, and all sections referencing this [terrain] are also duplicated
12:03:59  <planetmaker> neat
12:04:55  <Alberth> so you have a bit of a template-ish idea. The construction of the values is still somewhat magic
12:05:35  <planetmaker> it can't be made entirely un-magic. After all the offsets or so are intrinsically magic
12:05:48  <planetmaker> back to first principles they "just are what they are"
12:06:33  <Alberth> but adding sprite-base and sprite-offset to get sprite-number  could be perhaps be made unmigical
12:06:50  <Alberth> s/mig/mag
12:07:10  <Alberth> but perhaps tmwftlb :)
12:07:34  <Alberth> do you think this could work for a siginificant part of the base set?
12:07:56  <Alberth> I don't have code to process this stuff yet
12:08:11  <Alberth> but it looks very trivial to make
12:09:30  <planetmaker> there are a few hundret ground sprites: temp, arctic, desert, snow, desert transition, 3 snow transitions, toyland, rock (*4), rough (*4), fields (*19?)
12:09:43  <planetmaker> and every of those is 19 sprites, thus one use of that template
12:09:52  <Alberth> s/dret/dred/  please :)
12:09:52  <Brot6> Alberth: You did something wrong... Try s/you/me/ or tell me "help sed"
12:09:53  <planetmaker> oh. I forgot water :-)
12:11:16  <planetmaker> and similar, but new summary template (not for individual sprites) is needed for tracks and road
12:11:29  <planetmaker> offsets for individual sprites is the same there
12:12:03  <Alberth> s/you/me/
12:12:03  <Brot6> Alberth: You did something wrong... Try s/you/me/ or tell me "help sed"
12:13:29  <Alberth> ok, so for the parts where it makes a real difference, it would probably work
12:13:39  <planetmaker> that's another 6 ground types * 3 tracks + 8 road types
12:14:45  <planetmaker> canals and rivers are not ground tiles, but... are many sprites, too, as they also need 9 ground types (if you want also the snow transition)
12:14:49  <Alberth> vehicles, industries, depots, are all unique for each instance?
12:15:19  <planetmaker> yes and no. Industries also have ground tiles. But the houses probably can't be templated
12:15:25  <planetmaker> Depends a bit on how it's made
12:15:48  <Alberth> ok, let's worry about that later :)
12:15:58  <planetmaker> Vehicles can be templated, when they're standard size. Which works in a base set quite well
12:16:31  <planetmaker> For trains we actually do have that done. It "just" needs copying. And maybe rendering with the same light setup, if they#re different
12:16:49  <planetmaker> With planes I didn't find a good way to template it
12:16:55  <planetmaker> Ships, neither
12:18:05  <planetmaker> tunnels, depots, stations. They can be partly templated. But it might approach border case of tmwftlb
12:18:49  <planetmaker> but you might figure out something to scale the offsets for the zoom level, independent of the actual alignment
12:19:39  <Alberth> for composed sprites (eg back and front of depots and tunnels etc), are those coded in the game, or do you need to make special sprites for them too?
12:19:41  <planetmaker> In any case: I first suggest the easy stuff
12:20:17  <planetmaker> a depot has two sprites: back wall and front (which includes basically everything, also roof)
12:20:50  <planetmaker> they're aligned such that they fit manually
12:20:52  <Alberth> but are 2 real sprite definitions sufficient to make it work, or does it need something extra?
12:21:10  <planetmaker> two real sprites per depot view where you see the door
12:21:18  <planetmaker> one real sprite for the back view of the depots
12:21:27  <planetmaker> thus a depot has 6 sprites
12:21:44  <Alberth> ok, that's nothing new thus :)
12:21:49  <planetmaker> 2 for exit to SE, 2 for exit to SW, 1 for exit to NW, 1 for exit NE
12:22:49  <planetmaker>
12:22:58  <Alberth> LOL, for a moment I thought "SE" ? relative to what?   I forgot for a moment, OpenTTD has no rotation  :)
12:23:09  <planetmaker> :-)
12:23:28  <Alberth> too much FreeRCT :)
12:23:39  <planetmaker> that's got free rotation?
12:23:55  <Alberth> 4 directions of view
12:24:16  <Alberth> so not really free :p
12:24:22  <planetmaker> :-D
12:25:04  <planetmaker> with all this HUGE amount of sprites generated from blender files I sometimes wonder whether it might not be "easier" to use a 3D engine for OpenTTD and combine it there from the models :-P
12:25:48  <Alberth> so in FreeRCT you think 1 depot, 4 directions of view.  In OpenTTD you think 4 depots :p
12:26:20  <planetmaker> hm. I didn't quite think that way, tbh :-)
12:26:35  <planetmaker> I always thought of it as one depot with different views :-)
12:26:43  <planetmaker> Just works badly for industries and houses and stations
12:26:57  <planetmaker> otherwise rotation is "done"
12:27:24  <Alberth> oh, 3d engine would be nice, but NewGRF callbacks kills any chance of getting it off the ground afaik
12:27:51  <planetmaker> possibly
12:29:10  <planetmaker> a pity actually
12:29:21  <Alberth> ha, we sohould make a rotated baseset :)
12:29:46  <planetmaker> totally feasible and little extra cost with 100% blender files
12:31:06  <Alberth> or in a newgrf, and publish a savegame at 1/4 :)
12:31:31  <planetmaker> at 1/4?
12:31:32  <Brot6> Dutch Track Set - Revision 79:81889d98a016: Temporary: Remove Future tracks (issue #4071) (Transportman) @
12:31:32  <Brot6> Dutch Track Set - Revision 80:d5bf07070cb0: Fix #4071: filename was future.pnml on devzone instead o... (Transportman) @
12:31:33  <Brot6> Dutch Track Set - Bug #4071 (Closed): DevZone compile failed (Transportman) @
12:31:45  <Alberth> april 1st :p
12:32:06  <planetmaker> oh
12:32:19  <Alberth> preferably a newgrf with an innocent name :p
12:32:22  <planetmaker> :-)
12:33:32  <Alberth> special version of ogfx-industries :p
12:34:29  <Alberth> also known as   seirtsudni-xfgo    :)
12:36:11  <planetmaker> :-D
12:36:26  <planetmaker> now, that would be a truely cunning thing :D
12:37:09  <planetmaker> would need a special OpenTTD version, too.
12:38:44  <Brot6> Dutch Track Set - Bug #4072 (New): DevZone compile failed (compiler) @
12:42:56  <Alberth> why? Wouldn't changing the graphics + tile layout be enough ?
12:45:14  <planetmaker> openttd would need to allow rotation then, not?
12:48:56  <Alberth> we are speaking out of alignment it seems :p
12:48:56  <Alberth> I was thinking just to make an industry (or whatever) newgrf with rotated default industries graphics, and use that in the save game
12:49:34  <planetmaker> oh :-) Yes. that would be relatively easy feasible
12:49:42  <Alberth> so it looks rotated, but it isn't
12:49:56  <planetmaker> easy as in "just needs doing" :-P
12:50:38  <Alberth> I don't know what zephyris is doing here, I would not spend effort in making a nice back part
12:51:31  <planetmaker> yeah. I'd not do that either, I guess
12:52:07  <Alberth> but for airports we need it already
12:54:26  <planetmaker> quite so :-)
13:00:46  <Brot6> Dutch Track Set - Bug #4072: DevZone compile failed (Transportman) @
13:13:50  <Brot6> Dutch Track Set - Revision 81:f835a1e55d9f: Temporary: Remove some graphics files due to missing cap... (Transportman) @
13:13:50  <Brot6> Dutch Track Set - Revision 82:6a448bfc5669: Update #4072: Correct capitalization of file names, shou... (Transportman) @
13:20:56  <Brot6> dutchtracks: update from r75 to r82 done -
13:21:03  <Brot6> Metro Track Set - Revision 96:9f16e02947f2: Codechange: make signal code look more professional (Edd... (foobar) @
13:36:19  <Brot6> Dutch Track Set - Bug #4072 (Closed): DevZone compile failed (compiler) @
13:36:19  <Brot6> Dutch Track Set - Bug #4072 (Closed): DevZone compile failed (Transportman) @
14:27:17  <Brot6> NewGRF Meta Language - Revision 1918:1b2f8aa72839: Feature #3828: Unit conversions for non-constant ... (Hirundo) @
14:36:32  <Brot6> NewGRF Meta Language - Feature #3828: Make unit conversions work with non-constant values (Hirundo) @
14:44:51  <planetmaker> nice, Hirundo :-)
14:48:15  <Terkhen> indeed :D
14:52:13  <planetmaker> hola, the regression nfo shows again the big advantage of nml :-)
14:58:54  <Alberth> :)
15:05:14  <Hirundo> Currently RV speed does not work for non-const values, since it is a 'special' property
15:08:03  <planetmaker> Hirundo: doesn't NML always use the word-sized property? And couldn't one then assume that?
15:11:32  <Brot6> Metro Track Set - Revision 97:8a10dc8608ce: Fix: avoid "attempt to use invalid ID" errors when railt... (foobar) @
15:11:33  <Brot6> Metro Track Set - Revision 98:4dbc17bc9030: Feature: inform user if there are no or not enough railt... (foobar) @
15:11:33  <Brot6> Metro Track Set - Revision 99:7e69db3e0b87: Feature: allow engines on other track types also when re... (foobar) @
15:11:35  <Brot6> Metro Track Set - Revision 100:fa2582793528: Docs: prepare for release (foobar) @
15:11:39  <Brot6> Metro Track Set - Revision 101:9b299260405a: Release: 2.1.0 (foobar) @
15:12:27  <Hirundo> Currently NML sets both prop 08 (old) and 15 (new)
15:13:11  <planetmaker> Hirundo: yes, it does. But for things like callbacks, the word-sized value is only important. iirc
15:14:08  <Hirundo> Callbacks use only prop 15
15:14:58  <planetmaker> yup. So... one could simply assume that? Or do I miss some traps?
15:15:09  <Hirundo> The only disadvantage of using only prop 15 is that it's slightly less accurate for speeds < 128 km/h
15:15:37  <planetmaker> hm, I see
15:15:58  <planetmaker> which might matter for RV
15:16:32  <planetmaker> like horses. oxen carts and royal litters
15:19:00  <Hirundo> The resolution is approximately 0,5 km/h for prop 08 and 2 km/h for prop 15
15:19:30  <planetmaker> hm, yes...
15:21:07  <planetmaker> can they both be set to the accuracy as needed?
15:35:41  <Hirundo> Currently prop08 is set to min(speed, 255) and prop15 is set to speed/4 iff speed > 255
15:41:19  <Brot6> OpenGFX+ Trains renders - Revision 28:7365100006e7: Add: Blender models and render run for early wag... (Xotic750) @
15:41:46  <planetmaker> Hirundo: can't both be set (in the same manner)?
15:42:11  <Hirundo> yes, prop08 is always set
15:42:31  <Hirundo> but currently NML has no easy way of setting both properties, if they aren't a compile-time constant
15:42:41  <Hirundo> perhaps I should change that...
16:16:04  *** ODM has joined #openttdcoop.devzone
16:36:56  <Brot6> OpenGFX+ Trains - Revision 721:1e6bbefa3024: Add: Sprites for early wagons; passenger, mail, valuabl... (Xotic750) @
16:38:45  *** LordAro has joined #openttdcoop.devzone
16:42:52  <Brot6> OpenGFX+ Trains - Revision 722:45b99313aa15: Feature: Use sprites for early wagons; passenger, mail,... (Xotic750) @
16:47:08  <Brot6> OpenGFX+ Trains - Revision 723:3ce1cc9ba121: Merge with default (Xotic750) @
16:48:35  *** FooBar has joined #openttdcoop.devzone
16:49:27  <FooBar> Hi, it appears that the devzone build server isn't working?
16:50:33  <FooBar> I pushed a release about 1.5 hours ago, but it hasn't been built yet.
16:52:31  <Terkhen> hi FooBar
16:56:41  *** frosch123 has joined #openttdcoop.devzone
17:00:07  <planetmaker> hi FooBar
17:00:13  *** Xotic750 has quit IRC
17:03:21  <planetmaker> which project, FooBar?
17:04:40  <planetmaker> hm, nvm
17:05:30  <FooBar> planetmaker: at the risk of that you already found out: metrotrackset :)
17:05:58  <planetmaker> yeah. reading backlog was enlightening ;-)
17:11:29  <Brot6> Metro Track Set - Bug #4073 (New): DevZone compile failed (compiler) @
17:14:01  <planetmaker> seems the build had not run at all, FooBar
17:14:07  <planetmaker> no idea why
17:14:13  <planetmaker> Ammler: any idea?
17:14:17  <Brot6> nml: update from r1916 to r1918 done -
17:14:30  <FooBar> hmm, ok
17:15:00  <FooBar> It also seems that I made a bad. Forgot that Hirundo renamed the LOADINGSTAGE_ constants :P
17:15:57  <planetmaker> :-) And you knew! ;-)
17:16:14  <FooBar> Apparently not, but I should have known
17:16:26  <FooBar> didn't realize it, as I hadn't updated my local nml
17:18:01  <planetmaker> :-)
17:25:20  <FooBar> now this should do the trick
17:25:39  <Brot6> Metro Track Set - Revision 102:7929153bd8eb: Removed tag 2.1.0 (foobar) @
17:25:39  <Brot6> Metro Track Set - Revision 103:49abffdb83d2: Fix (r97): NML constant changed. Code now requires NML ... (foobar) @
17:25:39  <Brot6> Metro Track Set - Revision 104:123285b8af2d: Docs: prepare for release (foobar) @
17:25:39  <Brot6> Metro Track Set - Revision 105:878562cee17c: Release: 2.1.0 (foobar) @
17:26:16  <Brot6> fish: update from r780 to r781 done -
17:33:58  <Ammler> as you see, it works
17:34:57  <Ammler> why always blame my lovely devzone compiler script first? :'-(
17:35:07  <FooBar> I do wonder if me reusing the same tag was such a good idead though...
17:35:25  <Ammler> should be no issue from compiler view
17:35:48  <Ammler> it just matters for you if you already published the (buggy) version
17:35:48  <FooBar> but will it trigger?
17:35:52  <Ammler> yes
17:36:02  <Ammler> it does check the hash
17:36:25  <FooBar> the buggy version didn't build, so that shoudn't be the problem. It did try to build it however
17:36:37  <FooBar> but if it check the hash, it should be fine indeed :)
17:57:45  *** Xotic750 has joined #openttdcoop.devzone
18:11:52  <FooBar> Hmmm, it's still not built...
18:21:10  <Brot6> friss: rebuild of r43 done (Diffsize: 2160) (DiffDiffsize: 997) -
18:22:03  <Ammler> FooBar: bad time to be unpatient
18:22:17  <FooBar> :)
18:22:33  <FooBar> I'm not that impatient, just curious :P
18:22:54  <FooBar> I have time
18:23:07  <Alberth> Brot6 should report what it is doing, like every minute :p
18:23:40  <FooBar> maybe not every minute, but every 10 or 15 might be useful actually
18:25:00  <FooBar> anyways, I'll be watching some tv, I'll check back in 50 minutes or so
18:26:20  <Alberth> implement the next feature :)
18:26:50  <FooBar> which one is that?
18:27:33  <frosch123> translated readme
18:28:12  * frosch123 has a fair chance that there is none :)
18:28:29  <FooBar> bananas already supports that?
18:28:40  <frosch123> since saturday or so
18:28:47  <Brot6> make-nml: compile of r14 still failed (#4048) -
18:28:50  <FooBar> ah, good!
18:34:59  <Brot6> metrotrackset: update from r95 to r105 done -
18:37:54  <Brot6> dutchroadfurniture: rebuild of r145 done (Diffsize: 203965) (DiffDiffsize: 539) -
18:38:40  <Brot6> frenchtowns: compile of r6 still failed (#4058) -
18:43:24  <Rubidium> Alberth: for OpenGFX + zBase, wouldn't it be easier (for the non-extra GRF) to have a list with the sprite number for each of the (extra) 32bpp sprites? Then with some script you can append the 32bpp sprites to an already compiled OpenGFX compile
18:44:18  <Rubidium> furthermore, how hard is/would it be to clone OpenGFX and just do it the right way from the start?
18:44:54  <Rubidium> i.e. with additional/extra sprites in the main NMLs, or am I missing some important point here?
18:45:59  <Alberth> making that list is what you need to do anyway, I don't see an easy mapping from zbase file to sprite number other than manually
18:46:56  <Alberth> I was do far thinking to rip the 8bpp graphics data from the opengfx source, but perhaps it is easier to rip them from the generated nfo
18:47:54  <Rubidium> I'd just iterate over the generated nfo and insert extra 32bpp sprites whenever I encounter a place where they would be suitable (if you're making a 32bpp base set)
18:48:01  <Alberth> merging them at sprite level is the easiest, but perhaps not the best maintainable?
18:48:01  <Rubidium> instead of a NewGRF
18:48:18  <Rubidium> that's true
18:48:41  <Rubidium> but the next step seems to be adding them to the NML
18:49:32  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: ogfx-industries (Diffsize: 129404), firs (2 warnings) (Diffsize: 43339), opengfx (Diffsize: 26), foobarstramtracks (Diffsize: 28769), bandit (1 warnings) (Diffsize: 7930), cets (195 warnings) (Diffsize: 27765), manindu (Diffsize: 2), newgrf_makefile (Diffsize: 1), dutchtrains, rust (15 warnings) (Diffsize: 7633), dutchtramset (21 warnings) (Diffsize:
18:49:32  <Brot6> 24503), swisstowns (Diffsize: 51), britrains (10 warnings) (Diffsize: 62948), spanishtowns (Diffsize: 8), ogfx-rv (Diffsize: 8301), dutchtracks, ogfx-landscape (2 warnings) (Diffsize: 1314), swedishrails (Diffsize: 1836), german-townnames (Diffsize: 5042), dach (104 warnings) (Diffsize: 30898), belarusiantowns (Diffsize: 72), indonesiantowns (1 warnings) (Diffsize: 350), debugveh, airportsplus (Diffsize: 6970)
18:49:33  <Alberth> the question is perhaps whether you need opengfx anymore; ie generate or convert some 8bpp sprites in zbase, and you have everything
18:50:47  <Alberth> I don't really understand "clone OpenGFX and just do it the right way from the start?"   entire opengfx is NML
18:51:11  <Alberth> I am sure planetmaker had a reason to do it the way he did it
18:52:00  <Alberth> perhaps it has to do with being a baseset, and staying compatible with the TTD CD files
18:52:27  <planetmaker> hu?
18:52:53  <Alberth> I am making a newgrf as that's easier for testing
18:53:25  <planetmaker> Well... is it?
18:53:42  <Rubidium> Alberth: you know that you then can only test temperate, right?
18:53:57  <Alberth> no, I didn't
18:54:07  <planetmaker> each climate has a grf itself
18:54:25  <planetmaker> in base sets (base, hot, cold, toyland, + logos + extra)
18:54:45  <planetmaker> base has actually stuff which should go to hot, cold or toyland, but that's as it is
18:54:57  <planetmaker> in NewGRFs you need to use a parameter to query the climate
18:55:12  <planetmaker> and skip the others non-needed sprites
18:55:27  <Rubidium> well, not completely true... but... only the main base GRF's indices are the same as the spriteids in game. For the other climates there's a magic table that causes the extra grfs (not the extra grf) to overwrite the temperate/main sprites with climate specific sprites
18:55:27  <Alberth> k
18:55:43  <planetmaker> yep
18:56:28  <Rubidium> so you can't say: arctic.grf's sprite numbers are off by CONSTANT, but there is some magic mapping
18:56:37  <Rubidium> that differs for sprites
18:57:06  <planetmaker> Rubidium: for a NewGRF it's easiest to just use base spritenumbers and replace according to climate
18:57:28  <planetmaker> the constant from arctic to base is iirc not constant for all sprites in the arctic grf
18:57:51  <Rubidium> planetmaker: didn't I say that?
18:58:15  <planetmaker> I didn't read it that way
18:59:11  <Rubidium> "you can't say: XYZ" ;)
18:59:12  <Alberth> well, I am mostly just trying to have a file format where you can easily state what belongs together. If you say that is the wrong approach, I am open for suggestions. Both of you are infinite more acquainted with the area
19:01:12  <Alberth> the problem with zBase is that its file numbering is very inconvient to impossible in CPP, the current OpenGFX pre-processing
19:01:19  <Rubidium> did he already make almost 7000 sprites?
19:01:21  <planetmaker> Alberth: I think the nice thing would be to get a base set straight away
19:01:33  <Rubidium> hmm, no...
19:01:37  <planetmaker> with all the not-yet-existing 32bpp simply not included
19:01:56  <Rubidium> only 3283 sprites...
19:01:56  <Rubidium> still a lot
19:01:56  <Alberth> planetmaker: by doing what?
19:02:17  <planetmaker> Alberth: how do you get the 8bpp sprites currently?
19:02:21  <planetmaker> in the newgrf?
19:02:35  <Rubidium> rip them from opengfx
19:02:52  <Alberth> write "../opengfx/path/into/opengfx/x.png" in the nml
19:03:04  <planetmaker> so... why not rip everything? And add 32bpp where available?
19:03:21  <planetmaker> then writing base grf would work
19:03:28  <Brot6> OpenGFX+ Trains - Revision 724:fa351d3fa4c4: Fix: Display correct period sprite in purchase GUI (Xotic750) @
19:03:34  <Alberth> ah, right
19:04:16  <Alberth> but the problem is to find "add 32bpp where available"
19:05:16  <planetmaker> brb, 10 minutes. Then I'll get an update / clone of yours...
19:09:39  <Rubidium> oh, was there already something for 32bpp sprites with base graphics?
19:09:53  <Rubidium> cause that seems to fail now
19:09:59  <Rubidium> Hirundo: do you know that?
19:10:48  <Hirundo> Rubidium: 32bpp base graphics should work in NML
19:11:00  <Hirundo> In what sense does it fail?
19:11:18  <Rubidium> base_graphics(1011, "sprites/png/infrastructure/infra06.png") { [  82,   40,  64,  31, -31,   0] }
19:11:21  <Rubidium> alternative_sprites(1011, ZOOM_LEVEL_NORMAL, BIT_DEPTH_32BPP, "terrain/terrain_temperate/64_0001.png") { [0, 32, 64, 31, -31, 0] }
19:11:31  <Rubidium> not quite the right syntax I guess
19:11:46  <Rubidium> no idea how to fix that though
19:11:56  <Alberth> base_graphics foo(...)     alternative_sprites(foo, ZOOM...)
19:12:42  <Rubidium> base_graphics spr1011(1011, "sprites/png/infrastructure/infra06.png") { [  82,   40,  64,  31, -31,   0] }
19:12:46  <Rubidium> alternative_sprites(spr1011, ZOOM_LEVEL_NORMAL, BIT_DEPTH_32BPP, "terrain/terrain_temperate/64_0001.png") { [0, 32, 64, 31, -31, 0] }
19:12:49  <Rubidium> fails as well
19:13:02  <Rubidium> "alternative_sprites parameter 1 'name' must be an identifier"
19:16:02  <Hirundo> spr1011 is definitely an identifier...
19:17:09  <Hirundo> gtg now, will come back later
19:19:48  <planetmaker> back
19:20:36  <planetmaker> base_sprites foo(...)
19:20:44  <planetmaker> alternativ_sprites (foo, ...)
19:20:58  <planetmaker> hm
19:21:19  <Rubidium> gives the same issue
19:21:20  <planetmaker> why was it raining just when I wanted to go home
19:21:40  <Rubidium> ML
19:23:46  <Rubidium> hmm...
19:24:14  <Alberth>     this works for me with the newest nml
19:24:14  <Rubidium> the issue I'm hitting is more NML's depcheck hitting the error, which makes depcheck fail, as such the file is not rebuilt?!?
19:24:29  <planetmaker> Rubidium: opengfx?
19:24:49  <Rubidium> yes
19:24:58  <Brot6> cets: update from r681 to r700 done (195 warnings) -
19:25:38  <Rubidium> oh, the cpp step is not done
19:26:03  * planetmaker investigates
19:26:05  <Rubidium> there, that's better: ENOFILE
19:27:19  <FooBar> am I still impatient if I say that the metrotrackset release isn't built yet?
19:27:35  <Rubidium> interestingly, now OpenGFX is doing the CPP call ?!?
19:30:32  <Rubidium>,%201999-05-03.png <- success! ;)
19:31:20  <Rubidium> almost 100% guarantee it does not work out-of-the-box for anyone though
19:31:44  <planetmaker> I guess you're not impatient then, FooBar
19:31:48  <planetmaker> Ammler: ^
19:32:00  <Rubidium> ;)
19:32:46  <planetmaker> :-)
19:35:08  <planetmaker> interesting makefile, Alberth :-)
19:35:15  <Brot6> clientpatches: update from r22148 to r22148 done (6 warnings) -
19:36:03  <Alberth> it's somewhat overkill :)
19:36:25  * planetmaker builds grf
19:37:07  <Alberth> the NML generation process is the interesting part and that's done in less than a second
19:37:39  <Alberth> nml compilation to grf takes ages
19:37:39  <planetmaker> yes. so it will help a lot, if each base sprite gets an identifier like rubi suggested above?
19:38:05  <Alberth> what do you suggest to do concretely?
19:38:20  <Brot6> metrotrackset: update from 2.0.0 to 2.1.0 done -
19:38:23  <Alberth> do what rb just did, for every sprite explicitly ?
19:38:30  <Alberth> FooBar: ^^
19:38:48  <FooBar> ah, there it is :)
19:38:55  <planetmaker> Alberth: no. it would suffice to just write the alternative sprite blocks like you do
19:39:12  <planetmaker> the 8bpp could remain totally untouched. And the 32bpp could be added in a separate, generated file
19:39:37  <planetmaker> iirc the alternative_sprites block need not follow the base_sprite immediately. That's what we got the naming for
19:40:17  <planetmaker> thus one could basically take the generated nml of yours. remove all replace(...) and add it as additional pnml to opengfx base grf
19:40:21  <planetmaker> voila. done
19:40:37  <Alberth> ok, that reduces the 8bpp problem to just sprite numbers
19:40:42  <planetmaker> it *will* need some changes to the base grf as to make sprites separate again
19:40:58  <planetmaker> i.e. to let go the templates somewhat
19:41:07  <planetmaker> hm...
19:41:26  <Alberth> you have no desire for templated stuff here?
19:41:32  <planetmaker> I do very much
19:41:46  <planetmaker> but the nml of zbasebuild uses none so far
19:41:56  <planetmaker> I was just going by that in my argument above
19:42:46  <Alberth> why do you want templated stuff?  the zbasebuild output is generated
19:43:09  <planetmaker> to keep together one set of ground sprites
19:43:28  <planetmaker> but it's not mandatory
19:43:41  <Alberth>  line 25 and further?
19:43:43  <planetmaker> the 8bpp is not generated, is it?
19:44:07  <planetmaker> yes, like that line 25ff
19:44:25  <planetmaker> it would then count up to 19 or so, yes?
19:44:36  <planetmaker> that's imho exactly what it (only) needs
19:44:51  <planetmaker> with probably a slightly different output (let me mock up)
19:46:20  <Brot6> 32bpp-ez-patches: compile of r23237 still failed (#3251) -
19:49:44  <planetmaker> <-- like that, a spriteset per zoom-level which contains 19 sprites
19:49:49  <planetmaker> for terrain
19:49:57  <planetmaker> does that make sense?
19:50:31  <Alberth> it does, it's just a lot more complicated to generate :p
19:51:20  <planetmaker> Well. It's also feasible to change all 8bpp to not use a common template anymore for all terrains
19:51:30  <Alberth> possibly up to the point of making it more complicated than simply writing it directly
19:51:31  <planetmaker> But it means adding there a lot of duplicate code actually
19:52:55  <planetmaker> well. Maybe. Yes
19:53:22  <planetmaker> the file name numbers don't quite look consecutive?
19:54:12  <Brot6> chillpp: update from r22555 to r22555 done (15 warnings) -
19:54:23  <Alberth> opengfx has the wrong order for sprites :p
19:54:47  <planetmaker> TTD has
19:54:53  <planetmaker> opengfx can't choose
19:55:00  <Alberth> if you look in bin/, there is a list of slope definitions
19:55:42  <Alberth> the last number is the offset in sprite file number
19:56:52  <planetmaker> lol
19:57:02  <planetmaker> excellent choice of filenames it seems
19:57:26  <Alberth> but, what do you gain by having it like your mockup? isn't it enough to have the definitions? you won't ever edit it, right?
19:57:54  <planetmaker> which definitions├č
19:57:56  <planetmaker> ?
19:58:21  <planetmaker> the gain from my mockup is that such layout would immediately work when added to opengfx
19:58:44  <planetmaker> you just need to name the base_sprite of 8bpp accordingly
19:59:12  <Alberth> ah, ok, you are aiming for additional source code in NML
19:59:20  <planetmaker> base_graphics(3924, "sprites/png/terrain/bare-03-temperate.png") { tmpl_groundtiles(1, 1) }
19:59:27  <Alberth> rather than an additional generation step
19:59:28  <planetmaker> ^^ that you want to supply sprites for
19:59:48  <planetmaker> it just needs a slight modification to base_graphics spr3924(3924, "sprites/png/terrain/bare-03-temperate.png") { tmpl_groundtiles(1, 1) }
20:00:03  <planetmaker> which is a sed-replacement thing to do
20:00:23  <Alberth> yep, that's the easy part :p
20:00:29  <planetmaker> yup :-P
20:00:38  <planetmaker> but you generate source as well, don't you?
20:01:25  <Alberth> I do currently, I thought the aim was to generate all nml from <something>
20:01:55  <Alberth> but apparently, you want a one-time generation step
20:02:04  <planetmaker> well. But from what do you want in the general sense generate the 8bpp?
20:02:14  <Alberth> which of course defeats the entire idea of generating
20:03:07  <Alberth> current idea is to have 4 sprite sets, one 8bpp, and 3 32bpp
20:03:14  <planetmaker> yup
20:03:21  <planetmaker> and the 8bpp... basically cannot be generated
20:03:34  <Alberth> all that data would then be in the data files
20:03:56  <Alberth> ie you don't have nml source, you generate it
20:04:33  <planetmaker> so... basically you transform the whole 8bpp into some other data format in order to then generate the 4-spriteset version from it?
20:04:37  <Alberth> obviously, by tweaking the generation process you can have parts, merge with hand-coded stuff, etc
20:04:57  <Rubidium> won't that mean you're basically developing NMLML?
20:05:14  <planetmaker> if the 32bpp is very regular, won't a template look like...
20:05:35  <Alberth> that's the plan, rip 8bpp data from opengfx
20:05:39  <planetmaker> ... all lines the same. So just adding lines with filenames to the opengfx and job done?
20:06:15  <Alberth> Rubidium: just for realsprites in base sets :)
20:06:31  <Alberth> planetmaker: that breaks CPP processing
20:06:34  <Rubidium> 90% of the base sets is just real sprites
20:07:00  <Rubidium> too bad there are some recolour sprites (and a proper NewGRF)
20:07:13  <planetmaker>
20:07:22  <planetmaker> you always need tu supply the filename somewhat
20:07:23  <Alberth> planetmaker: unless you do it manually, which is then again what you have in mind
20:07:34  <planetmaker> s/tu/to/
20:07:34  <Brot6> planetmaker meant: "you always need to supply the filename somewhat"
20:07:41  <planetmaker> bah, shut up, Brot
20:08:25  <planetmaker> FooBar: seems that the CF has much to do. It might eventually reach metrotracks
20:08:52  <planetmaker> the backdraw is that you can't calculate the filenames. Which is the adv. of the generation
20:09:03  <Rubidium> 21:38 < Brot6> metrotrackset: update from 2.0.0 to 2.1.0 done -
20:09:08  <planetmaker> oh :-)
20:09:10  <FooBar> yes, that :)
20:09:35  <Alberth>  8bpp is highly irregular in sizes/offsets, and zbase has nasty filenames
20:09:40  <FooBar> but it was simply very busy? Good to know for next time, I'll be even more patient then :)
20:10:13  <planetmaker> FooBar: some projects take... very long. e.g. opengfx takes certainly dozens minutes
20:12:19  <michi_cc> I do wonder how much sense it makes to have a single base set with two completely different looks (which an OpenGFX zbase hybrid would be). Manually switching blitters in the config file doesn't seem to be very useful.
20:12:47  <planetmaker> michi_cc: that's somewhat beside the point. it needs 8bpp sprites :-)
20:13:13  <Alberth> I mostly use opengfx because of 8bpp sprite requirements
20:13:30  <michi_cc> Use the favourite batch image editor of your choice.
20:13:54  <planetmaker> michi_cc: if you want to keep it playable, you need *all* sprites
20:13:59  <Rubidium> michi_cc: then you still miss a fair share of sprites as those are never zoomed (font, gui)
20:14:03  <planetmaker> thus an editor won't help you much further either
20:15:00  <Alberth> planetmaker: so you consider the data file idea with sections as too complicated, and prefer simple direct adding of 32bpp sprites into the nml source?
20:15:14  <michi_cc> Rubidium: How is zoom relevant to automatic palette conversion?
20:16:07  <Rubidium> do we support 32bpp font sprites?
20:16:23  <planetmaker> Alberth: this generation - it works for terrain. Thus another will be needed for tracks, a 3rd algorithm for roads. Maybe vehicles
20:16:46  <planetmaker> michi_cc: window decorations in 32bpp?
20:16:51  <planetmaker> font sprites?
20:16:54  <Alberth> planetmaker: generation for just 1 time is silly
20:16:55  <planetmaker> recolour sprites?
20:17:21  <planetmaker> Alberth: yes.
20:17:23  <Alberth> copy/paste is almost just as quick then
20:17:38  <michi_cc> With a table/script driven build you could just fill all missing sprites some (empty) default sprite, makes for a nice visual progress indicator. Font, recolour and mapgen can be manually cherry-picked from OpenGFX.
20:17:46  <Rubidium> alternatively, you just generate the 8bpp sprites from the 32bpp sprites (use same offsets/size), and replace the whole sprite from opengfx's nfo and hook the compilation in between
20:18:53  <planetmaker> michi_cc: the difference 32bpp vs 8bpp is a good indicator but makes also for a good playing experience.
20:19:07  <planetmaker> no-one will want to play with 50% black boxes. especially vehicles
20:19:48  <planetmaker> and imho it's important to give people something which they can actually play with
20:20:41  <planetmaker> hm... can nml concatenate strings?
20:21:22  <planetmaker> like template(filename, no) { [a, b, c, d, e, f, filename + string(no + 3) ] }
20:21:53  <planetmaker> that would solve the whole issue mostly :-)
20:22:06  <planetmaker> concatenation of strings and number-string conversion in NML templates
20:22:20  <Alberth> truncation to 4 digits?
20:22:57  <planetmaker> template(filename, no) { [a, b, c, d, e, f, filename + string(no + 3,format=%04d) ] }
20:23:06  <Alberth> wow :)
20:23:16  <planetmaker> it can't. But would be nice :-)
20:23:36  <planetmaker> and would solve it IMHO very elegant. Also for other people
20:23:52  <Alberth> can you take the last n characters?
20:24:11  <planetmaker> I don't know really. I'm toying ideas now :-)
20:24:27  <planetmaker> but after all... NML can be modified by us, too. Can't it?
20:24:39  <planetmaker> And NewGRFs might need the exact same solutions as the base set eventually
20:25:04  <Alberth> renaming the .png files is also an option
20:25:21  <planetmaker> sure is
20:26:28  <Alberth> hmm, that might break re-generation
20:26:38  <planetmaker> re-generation? where?
20:26:49  <planetmaker> you mean renaming on the fly?
20:26:58  <Alberth> no, in the repo
20:27:10  <planetmaker> yes. It needs a change by Zephyris
20:27:28  <Alberth> but if zephyris changes the model and generates the .png files again, you're stuck with the broken file names again
20:27:37  <planetmaker> yup
20:28:06  <planetmaker> hm... but I like the idea to sponsor some slight string generation to NML
20:28:24  <planetmaker> then we add 3 templates for ground and are basically done
20:28:56  <Alberth> *cough* yeah *cough* *cough*
20:29:59  <planetmaker> :-D
20:35:53  <Alberth>   <-- posted a warning of this change
20:35:54  <Webster> Title: Transport Tycoon Forums View topic - zBase (32bpp base set by Zephyris) - Coder needed! (at
20:36:21  <Alberth> good night
20:37:23  *** Alberth has left #openttdcoop.devzone
20:43:27  *** FooBar has quit IRC
20:56:03  <Brot6> repository /home/hg/zbaseopengfx registered in Redmine with url /home/hg/zbaseopengfx
20:56:03  <Brot6> repository /home/hg/zbaseopengfx created
21:13:23  *** ODM has quit IRC
21:31:47  *** Xotic750 has quit IRC
21:44:34  <Brot6> Berries - Revision 32:01006ffcfe34: Change: highlight the client's name (dih) @
21:44:34  <Brot6> Grapes - Revision 150:d8568b92964e: Change: create the MessageContext as soon as possible for the ge... (dih) @
21:44:34  <Brot6> Grapes - Revision 151:7514195e951b: Change: for the sake of development enable debug logging (dih) @
22:02:36  <Hirundo> !logs
22:02:42  <Hirundo> @logs
22:02:43  <Webster> #openttdcoop IRC webstuff - IRC Log Viewer -
22:09:12  <planetmaker> Hirundo: you know that you can configure logs of desired length with the bouncer?
22:09:38  <planetmaker> (it won't play back what you know, irrespective of configured length)
22:10:04  <Hirundo> Currently I have configured a length of 100 IIRC
22:10:33  <planetmaker> I use 500 or 1000, I think
22:10:34  <Hirundo> Which is usually sufficient, but just short in this case
22:10:48  <planetmaker> did the logs help (are they present)?
22:12:04  <planetmaker> Hirundo: can i compose filenames in NML templates? Like
22:12:05  <Hirundo> they were, and they told me that I hadn't missed that much
22:12:26  <planetmaker> filename + string(num + 3, format='04d')
22:12:38  <planetmaker> that would be awesome :-P
22:13:07  <planetmaker> where num is a compile-time integer and filename a compile time string
22:13:17  <planetmaker> which would be composed to give the complete filename
22:13:32  <planetmaker> like templating the filename in a template
22:13:39  <Hirundo> Ideally you'd want sprintf-like stuff
22:13:50  <planetmaker> yes. ideally
22:13:54  <Hirundo> Though %d and %s are probably sufficient
22:14:04  <planetmaker> would work for me, yes
22:14:23  <planetmaker> if concatenation works
22:14:51  <Hirundo> That works already ("a" +"b")
22:15:00  <planetmaker> ok :-)
22:15:36  <planetmaker> then it needs "just" a formatted output of a number to a string
22:15:49  <planetmaker> and zBase can be added to OpenGFX easily
22:16:02  <planetmaker> with templates referencing the proper file numbers
22:18:43  <Hirundo> In principle, I could just use the python string formatting stuff, which would give more goodies that you'll ever need
22:19:36  <planetmaker> is there a backdraw?
22:19:40  <Hirundo> in pseudo-python: def string_format(args) return args[0] % args[1:]
22:20:05  <Hirundo> backdraw is that it's quite complicated:
22:20:06  <Webster> Title: 3.6.2 String Formatting Operations (at
22:20:23  <planetmaker> I don't care so much, if the formatting is a bit complex
22:20:52  <planetmaker> and... it doesn't look more complex than similar solutions for formatted printing
22:25:58  <planetmaker> now time for bed though.
22:26:01  <planetmaker> good night :-)
22:26:07  <Brot6> Dutch Trains 2 - Support #4062 (Feedback): some train have change their power after buying them. (foobar) @
22:32:23  <Brot6> NewGRF Meta Language - Feature #4074 (New): sprintf-like functionality (Hirundo) @
22:46:32  *** LordAro has quit IRC
22:50:03  *** frosch123 has quit IRC

Powered by YARRSTE version: svn-trunk