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) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/44abd75cf3fb 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) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/13364904fee3 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) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/a43e5e48551f 06:57:35 <Brot6> OpenGFX+ Trains - Bug #4070 (Closed): Purchase list shows graphics in their loading state (Xotic750) @ http://dev.openttdcoop.org/issues/4070#change-11153 07:07:34 <Brot6> OpenGFX+ Trains - Revision 720:456eba145a1b: Feature #4068: Early bulk wagons now have an 80km/h spe... (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/456eba145a1b 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) @ http://dev.openttdcoop.org/issues/2284#change-11154 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> http://dev.openttdcoop.org/projects/opengfx/repository/entry/sprites/templates/sprite_templates.pnml#L18 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> http://hg.openttdcoop.org/opengfx/file/e319ab416ba1/sprites/templates/tmpl_trains.nml <-- 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: http://paste.openttdcoop.org/show/1552/ 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> http://paste.openttdcoop.org/show/1553/ 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> http://hg.openttdcoop.org/swedishrails/file/b64de63355ba/src/gfx/depot_electric.png 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) @ http://dev.openttdcoop.org/projects/dutchtracks/repository/revisions/81889d98a016 12:31:32 <Brot6> Dutch Track Set - Revision 80:d5bf07070cb0: Fix #4071: filename was future.pnml on devzone instead o... (Transportman) @ http://dev.openttdcoop.org/projects/dutchtracks/repository/revisions/d5bf07070cb0 12:31:33 <Brot6> Dutch Track Set - Bug #4071 (Closed): DevZone compile failed (Transportman) @ http://dev.openttdcoop.org/issues/4071#change-11155 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) @ http://dev.openttdcoop.org/issues/4072 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) @ http://dev.openttdcoop.org/issues/4072#change-11156 13:13:50 <Brot6> Dutch Track Set - Revision 81:f835a1e55d9f: Temporary: Remove some graphics files due to missing cap... (Transportman) @ http://dev.openttdcoop.org/projects/dutchtracks/repository/revisions/f835a1e55d9f 13:13:50 <Brot6> Dutch Track Set - Revision 82:6a448bfc5669: Update #4072: Correct capitalization of file names, shou... (Transportman) @ http://dev.openttdcoop.org/projects/dutchtracks/repository/revisions/6a448bfc5669 13:20:56 <Brot6> dutchtracks: update from r75 to r82 done - http://bundles.openttdcoop.org/dutchtracks/nightlies/r82 13:21:03 <Brot6> Metro Track Set - Revision 96:9f16e02947f2: Codechange: make signal code look more professional (Edd... (foobar) @ http://dev.openttdcoop.org/projects/metrotrackset/repository/revisions/9f16e02947f2 13:36:19 <Brot6> Dutch Track Set - Bug #4072 (Closed): DevZone compile failed (compiler) @ http://dev.openttdcoop.org/issues/4072 13:36:19 <Brot6> Dutch Track Set - Bug #4072 (Closed): DevZone compile failed (Transportman) @ http://dev.openttdcoop.org/issues/4072#change-11157 14:27:17 <Brot6> NewGRF Meta Language - Revision 1918:1b2f8aa72839: Feature #3828: Unit conversions for non-constant ... (Hirundo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/1b2f8aa72839 14:36:32 <Brot6> NewGRF Meta Language - Feature #3828: Make unit conversions work with non-constant values (Hirundo) @ http://dev.openttdcoop.org/issues/3828#change-11158 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) @ http://dev.openttdcoop.org/projects/metrotrackset/repository/revisions/8a10dc8608ce 15:11:33 <Brot6> Metro Track Set - Revision 98:4dbc17bc9030: Feature: inform user if there are no or not enough railt... (foobar) @ http://dev.openttdcoop.org/projects/metrotrackset/repository/revisions/4dbc17bc9030 15:11:33 <Brot6> Metro Track Set - Revision 99:7e69db3e0b87: Feature: allow engines on other track types also when re... (foobar) @ http://dev.openttdcoop.org/projects/metrotrackset/repository/revisions/7e69db3e0b87 15:11:35 <Brot6> Metro Track Set - Revision 100:fa2582793528: Docs: prepare for release (foobar) @ http://dev.openttdcoop.org/projects/metrotrackset/repository/revisions/fa2582793528 15:11:39 <Brot6> Metro Track Set - Revision 101:9b299260405a: Release: 2.1.0 (foobar) @ http://dev.openttdcoop.org/projects/metrotrackset/repository/revisions/9b299260405a 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) @ http://dev.openttdcoop.org/projects/ogfx-trains-render/repository/revisions/7365100006e7 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) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/1e6bbefa3024 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) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/45b99313aa15 16:47:08 <Brot6> OpenGFX+ Trains - Revision 723:3ce1cc9ba121: Merge with default (Xotic750) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/3ce1cc9ba121 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) @ http://dev.openttdcoop.org/issues/4073 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 - http://bundles.openttdcoop.org/nml/nightlies/r1918 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) @ http://dev.openttdcoop.org/projects/metrotrackset/repository/revisions/7929153bd8eb 17:25:39 <Brot6> Metro Track Set - Revision 103:49abffdb83d2: Fix (r97): NML constant changed. Code now requires NML ... (foobar) @ http://dev.openttdcoop.org/projects/metrotrackset/repository/revisions/49abffdb83d2 17:25:39 <Brot6> Metro Track Set - Revision 104:123285b8af2d: Docs: prepare for release (foobar) @ http://dev.openttdcoop.org/projects/metrotrackset/repository/revisions/123285b8af2d 17:25:39 <Brot6> Metro Track Set - Revision 105:878562cee17c: Release: 2.1.0 (foobar) @ http://dev.openttdcoop.org/projects/metrotrackset/repository/revisions/878562cee17c 17:26:16 <Brot6> fish: update from r780 to r781 done - http://bundles.openttdcoop.org/fish/nightlies/r781 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) - http://bundles.openttdcoop.org/friss/nightlies/r43/log 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) - http://bundles.openttdcoop.org/make-nml/nightlies/ERROR/r14 18:28:50 <FooBar> ah, good! 18:34:59 <Brot6> metrotrackset: update from r95 to r105 done - http://bundles.openttdcoop.org/metrotrackset/nightlies/r105 18:37:54 <Brot6> dutchroadfurniture: rebuild of r145 done (Diffsize: 203965) (DiffDiffsize: 539) - http://bundles.openttdcoop.org/dutchroadfurniture/nightlies/r145/log 18:38:40 <Brot6> frenchtowns: compile of r6 still failed (#4058) - http://bundles.openttdcoop.org/frenchtowns/nightlies/ERROR/r6 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) @ http://dev.openttdcoop.org/projects/ogfx-trains/repository/revisions/fa351d3fa4c4 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> http://paste.openttdcoop.org/show/1554/ 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) - http://bundles.openttdcoop.org/cets/push/r700 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> http://rbijker.net/openttd/Vysok%C3%BD%20Odst%C5%99edec%20Transport,%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> http://rbijker.net/openttd/ogfx.diff ;) 19:32:46 <planetmaker> :-) 19:35:08 <planetmaker> interesting makefile, Alberth :-) 19:35:15 <Brot6> clientpatches: update from r22148 to r22148 done (6 warnings) - http://bundles.openttdcoop.org/clientpatches/releases/r22148 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 - http://bundles.openttdcoop.org/metrotrackset/releases/2.1.0 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> http://paste.openttdcoop.org/show/1553/ 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) - http://bundles.openttdcoop.org/32bpp-ez-patches/releases/ERROR/r23237 19:49:44 <planetmaker> http://paste.openttdcoop.org/show/1555/ <-- 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) - http://bundles.openttdcoop.org/chillpp/releases/r22555 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/terrain_funcs.py, 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> http://paste.openttdcoop.org/show/1556/ 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> http://www.tt-forums.net/viewtopic.php?p=1034658#p1034658 <-- 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 www.tt-forums.net) 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) @ http://dev.openttdcoop.org/projects/berries/repository/revisions/01006ffcfe34 21:44:34 <Brot6> Grapes - Revision 150:d8568b92964e: Change: create the MessageContext as soon as possible for the ge... (dih) @ http://dev.openttdcoop.org/projects/grapes/repository/revisions/d8568b92964e 21:44:34 <Brot6> Grapes - Revision 151:7514195e951b: Change: for the sake of development enable debug logging (dih) @ http://dev.openttdcoop.org/projects/grapes/repository/revisions/7514195e951b 22:02:36 <Hirundo> !logs 22:02:42 <Hirundo> @logs 22:02:43 <Webster> #openttdcoop IRC webstuff - IRC Log Viewer - http://webster.openttdcoop.org/ 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: http://docs.python.org/release/2.5.2/lib/typesseq-strings.html 22:20:06 <Webster> Title: 3.6.2 String Formatting Operations (at docs.python.org) 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) @ http://dev.openttdcoop.org/issues/4062#change-11159 22:32:23 <Brot6> NewGRF Meta Language - Feature #4074 (New): sprintf-like functionality (Hirundo) @ http://dev.openttdcoop.org/issues/4074 22:46:32 *** LordAro has quit IRC 22:50:03 *** frosch123 has quit IRC